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