Subject: Re: [ietf-dkim] New issue: Upward query vs. wildcard publication

From: John L <[email-masked]>
Date: Wed, 18 Apr 2007 17:48:17 -0400 (EDT)

>percentages are "normal" vs. "unusual", but my cursory look a
>long time ago suggested that it met the 80-20 rule.

You are certainly correct that most zones are pretty flat, but this
sounds like a DOS attack waiting to happen, send out junk with long
bogus addresses and watch the system on the other end chew up its
cache crawling up to the SOA.  That's why we arbitrarily limited the
walk in CSV to five levels.

R's,
John

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Wed, 18 Apr 2007 16:55:42 -0700

John L wrote:
> bogus addresses

I'm just raising this as a discussion point; what if we said that the 
SSP record must (at least) exist at the registry cut-point?

It's not particularly pretty, but you (only) need about a 1,000 entry 
database to define all the registry cut-points today. I know the size 
because we've built this sort of database for other reasons. I think 
SpamAssassin has something similar as well.

That "root" SSP record could tell us max-depth within it's balliwick, if 
that's of use.

I'm kindof a fan of the registry cut-point because that segues nicely 
into a responsible and hopefully knowable entity.

Mark.

---

From: "Daryl C. W. O'Shea" <[email-masked]>
Date: Wed, 18 Apr 2007 20:09:08 -0400

> SpamAssassin has something similar as well.

FWIW, here's what we use for cut points:

http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/SpamAssassin/Util/RegistrarBoundaries.pm?view=co

surbl.org and uribl.com use the same cut points since they're mostly 
used by SA.

Daryl

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Apr 2007 18:17:34 -0700

On Apr 18, 2007, at 5:09 PM, Daryl C. W. O'Shea wrote:
> Mark Delany wrote:
>> John L wrote:
>>> You are certainly correct that most zones are pretty flat, but  
>>> this sounds like a DOS attack waiting to happen, send out junk  
>>> with long bogus addresses
>>
>> I'm just raising this as a discussion point; what if we said that  
>> the SSP record must (at least) exist at the registry cut-point?  
>> It's not particularly pretty, but you (only) need about a 1,000  
>> entry database to define all the registry cut-points today. I know  
>> the size because we've built this sort of database for other  
>> reasons. I think SpamAssassin has something similar as well.
>
> http://svn.apache.org/viewvc/spamassassin/trunk/lib/Mail/ 
> SpamAssassin/Util/RegistrarBoundaries.pm?view=co
>
> surbl.org and uribl.com use the same cut points since they're  
> mostly used by SA.

This provides a good starting point.  Should this document remain in  
its current form, or perhaps published using a different template?

Would IANA be interested in acting a repository for such highly  
useful information?

Perhaps it could be called "List of Registering Domains (LRD)."  The  
terms TLD SLD, etc could then reference LDR instead.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 19 Apr 2007 14:24:52 -0700

> walk in CSV to five levels.

No, it circumvents that problem. It goes like this:

1) query for the name _policy._domainkey.sub.domain.attack.foo.com
2) if you don't get a ssp rr, check to see if it gave
    you a NS or SOA authority records.

    o If they're available and it's a parent domain of domain
      you're querying from, query that label.
3) done.

Thus for:

[email-masked]

query: _policy._domainkey.sub.domain.attack.foo.com

which returns:

 >> NXDOMAIN or NODATA and an authority section SOA of
foo.com.              10800   IN      SOA     dns-rtp2-2-l. 
postmaster.foo.com. 8004725 7200 1800 86

Take the authority domain and try again:

policy._domainkey.sub.foo.com

 >> v=DKIM1; o=~; t=y;  r=[email-masked]

You never go any further than this.

		Mike

---

From: John L <[email-masked]>
Date: Thu, 19 Apr 2007 18:06:02 -0400 (EDT)

> foo.com.              10800   IN      SOA     dns-rtp2-2-l. > postmaster.foo.com. 8004725 7200 1800 86

The problem here is that not all DNS caches return the authority record. 
Maybe they should, but they don't.  This means you're back to a tree walk.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 19 Apr 2007 18:50:21 -0400

Michael,

The basic issue is that not all DNS servers handle unknown RR equally 
the same doing a recursion (how SERVFAIL, NOERROR, NXDOMAIN are handled).

RFC 3597 ("Handling of Unknown DNS Resource Record (RR) Types") touches 
base on this problem and offers the recommendation to handling unknown 
RR.  But not all servers support RFC 3597 and even if the end points do 
support 3597, you don't know how the middle servers are going to react.

Since this IETF document was published in 2003, there will be a lot of 
servers that still don't support it.  This is of NT 4.0, W2K and W3K3 
DNS servers.  Older versions of BIND also had issues.  Although, there 
are patches or undocumentated low level support for some to offer some 
support, this doesn't guarantee mixed DNS setups and/or request 
propagation would follow RFC 3597.

That said, I do support a primary RR type for SSP with a TXT fallback.

--
HLS

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 16:32:38 -0700

It does not necessarily work the way you think it will.

In the past the same server machines have supported both the root and the com registry. 

This might well return in the future now that the ATLAS cluster is aggressively multicast.

We also provide managed DNS service.

So it is quite possible that at some point someone makes the request for www.example.com and gets the A record back from what it thinks is the J-Root.

So no, assumptions as to what information can be extracted from the zone cut are not necessarily valid today and may cease to be valid in the future.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Mark Delany
> Sent: Wednesday, April 18, 2007 7:56 PM
> To: John L
> Cc: DKIM List
> Subject: Re: [ietf-dkim] New issue: Upward query vs. wildcard 
> publication
> 
> John L wrote:
> >> percentages are "normal" vs. "unusual", but my cursory look a long 
> >> time ago suggested that it met the 80-20 rule.
> > 
> I'm just raising this as a discussion point; what if we said 
> that the SSP record must (at least) exist at the registry cut-point?
> 
> It's not particularly pretty, but you (only) need about a 
> 1,000 entry database to define all the registry cut-points 
> today. I know the size because we've built this sort of 
> database for other reasons. I think SpamAssassin has 
> something similar as well.
> 
> That "root" SSP record could tell us max-depth within it's 
> balliwick, if that's of use.
> 
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 19 Apr 2007 22:21:37 -0400

>    you a NS or SOA authority records.

Michael:  Zones are not part of the user-visible DNS semantics.  They 
are strictly an administrative construct.  Using anything that relies on 
particular zone points breaks the semantics of the DNS.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 06:48:15 -0700

> particular zone points breaks the semantics of the DNS.

Dave: I don't see any reference to "zone" in what you quoted, or in the
algorithm I layed out, or in any other message I posted about this,
so I have no idea what your objection is.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Apr 2007 10:36:21 -0400

Michael Thomas wrote:
>> are strictly an administrative construct.  Using anything that relies 
>> on particular zone points breaks the semantics of the DNS.
> 

SOA and NS are zone constructs.  They are not constructs applicable to 
user-visible domain name semantics.  Rather they are part of the 
underlying distribution service.

The two are, effectively, entirely separate layers of service.

For example, see:

    <http://asg.web.cmu.edu/rfc/rfc1912.html>
    <http://support.microsoft.com/kb/163971>

d/

-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 08:16:30 -0700

>    <http://support.microsoft.com/kb/163971>

I just read both of these and I don't see how it contradicts anything
I've proposed. If the authority of a domain is a parent to the current
domain, it seems rather pointless to query all of the intermediate
labels in a treewalk. In this particular case, keeping query complexity
down is a lot more important than lots and lots and lots of unneeded
flexibility.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 20 Apr 2007 11:23:44 -0400

> down is a lot more important than lots and lots and lots of unneeded

You want user-visible information to be based on zone boundaries, 
although zone boundaries are not defined as a user-visible construct.

The real-world functional problems with this have already been 
explained, by others.

What I am trying to make clear is that the fact that some packages might 
give access to this information, it is nonetheless inappropriate for a 
user-visible function to be based on access to zone boundary information.

d/
-- 

   Dave Crocker