Subject: [dnsop] Revision available: draft-crocker-dns-attrleaf-02

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Oct 2006 06:51:50 -0400

Folks,

I have submitted a revised version of "DNS Scoped Data Through Attribute 
Leaves", draft-crocker-dns-attrleaf-02.

It reflects the discussions that took place on the list about version -01.  I 
would, as usual, appreciate any comments folks might have on this latest draft.

HTML and TXT are available at:

    <http://bbiw.net/specifications/draft-crocker-dns-attrleaf-02.html>

    <http://bbiw.net/specifications/draft-crocker-dns-attrleaf-02.txt>

Please note that the document is quite careful to focus on how to do 
registrations for an existing naming practice, rather than discuss the 
wonderfulness or evilness of having such a naming practice.  That discussion is, 
of course, important, but it is outside the scope of this document.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Oct 2006 10:34:14 -0700

On Oct 24, 2006, at 3:51 AM, Dave Crocker wrote:

> Folks,
>
>
> I have submitted a revised version of "DNS Scoped Data Through  
> Attribute Leaves", draft-crocker-dns-attrleaf-02.
>
> It reflects the discussions that took place on the list about  
> version -01.  I would, as usual, appreciate any comments folks  
> might have on this latest draft.
>

Per the experimental RFC4408, there is neither an expectation nor  
requirement any SPF related TXT RR use the "_spf" prefix.  This  
prefix is found in examples of continuation or secondary SPF  
records.  The prefix is declared within referencing SPF scripts and  
can be _any_ prefix.  Various invented prefixes are being used in  
practice already.  There are also other prefix examples not listed in  
this draft, should the desire be to cover these examples.  This RFC  
also represents an extremely serious and significant DoS threat to  
DNS.  A better approach would not further entrench a highly hazardous  
RFC, even in hopes this draft's examples somehow become normative.

-Doug
.