stuart at bmsi
Jan 4, 2008, 8:51 AM
Post #5 of 11
(1546 views)
Permalink
|
On Fri, 4 Jan 2008, Julian Mehnle wrote:
> > 2. Security software might block DNS records with unknown record types,
> > and might not know about AAAA.
>
> OK, so checking SPF for incoming IPv6 connections might fail. But that
> possibility has existed for years now, and there's nothing an SPF
> implementation can do about it, is there?
This change affects IPv4 lookups also. That is why the committee is
being so careful. Yes, the change may cause *all* SPF checks to fail
if a security filter doesn't like the "unknown" AAAA records.
I have already had to deal with SPF checks via pyspf failing because a security
appliance didn't like 0 in the TID field.
Your point on issue 1 is that an SPF implementation queries a local caching
name server, and doesn't need to worry about root DNS packet size.
That may be tree, however, a production implementation should find out whether
some part of the chain fails before Feb 4. The committee points out
that the UA, FR, JP, and HK top level domains have AAAA records and DNS
response packets exceeding 512 bytes. If an implementation can handle
lookups below those top level domains, it should be ok.
Again, this change can affect (and did affect in committee testing) some
(older) IPv4 implementations.
--
Stuart D. Gathman <stuart[at]bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/1007/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/1007/
Modify Your Subscription: http://v2.listbox.com/member/?member_id=1311533&id_secret=81839847-1db977
Powered by Listbox: http://www.listbox.com
|
