Three items to respond to:
[-1-]
On Sep 5, 2004, at 6:33 AM, william(at)elan.net wrote:
-prefix does not solve the wildcard issue
Actually prefix helps wildcard issues and solves at least one of them.
It allows to avoid necessity to enter separate records for both
"example,com"
and for "*.example.com" while with prefix one record for
"*.example.com"
would suffice and cover both _prefix.example.com and anything else like
_prefix.subdonain.example.com.
Usually, the use of the wild-card record is to say "-all" for anything
in a subdomain, and hence this record is would not be the same as the
domain's record:
with prefix:
_prefix.example.com IN SPF2 "spf2.0/pra +mx +a -all"
*.example.com IN SPF2 "spf2.0/pra -all"
without prefix:
example.com IN SPF2 "spf2.0/pra +mx +a -all"
*.example.com IN SPF2 "spf2.0/pra -all"
There is no savings and no difference. On rare occasion when you want
the same record, a prefix fails to help:
with prefix:
*.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all"
without prefix:
example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all"
*.example.com IN SPF2 "spf2.0/pra +mx:mx.example.com -all"
It still makes no difference over-the-wire: Only one record would be
ever returned, so this savings is only one administrative entry. Not a
ringing endorsement in my mind.
[-2-]
On Sep 5, 2004, at 9:31 AM, Rand Wacker wrote:
The 480 byte limit is a limit of UDP.
As has been pointed out, this limit is not in UDP, but in the original
DNS spec, which was later removed with EDNS0. You can check what a
server's limit is with a dig command like:
dig +bufsize=1000 example.com txt
You will find a line in the results like:
; EDNS: version: 0, flags:; udp: 4096
The 'udp' number gives the maximum size the server can support before
falling over to TCP. If the resolver querying also does EDNS0, then
the min of the two numbers can be used. Finding a resolver's
advertised EDNS0 can be a bit tricky, involving tcpdump. On my
servers, running several year old Linux distributions, the EDNS0 sizes
were all either 2048 or 4096.
[-3-]
On Sep 5, 2004, at 11:24 AM, Peter Koch wrote:
this reference is questionable at best (read: DOC-BUG). RFC 3226
specifies
behaviour of RFC2874-conformant DNS implementations (A6 is kinda dead
now)
and for DNSSEC-aware DNS implementations. None of both is relevant to
the draft
in question and, more importantly, it is suboptimal to reference a
requirements document for DNS server implementations this way.
The actual text from the current draft is:
"Sender-ID compliant sites MUST use DNS recursive servers that support
EDNS0 [RFC2671] and [RFC3226] in order to be able to receive large DNS
RR sets."
This text, including the reference to RFC3226, came directly from
Ólafur of DNS-EXT.
- Mark
Mark Lentczner
http://www.ozonehouse.com/mark/
markl(_at_)glyphic(_dot_)com