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

[Hallam-Baker, Phillip]

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: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] 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.
> > 
> > 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.
> 
> 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.
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>