> On Fri, Feb 09, 2007 at 11:09:51AM -0500, Joe Abley wrote:
>
> > root nameservers is TSIG-signed access to the zone data. This seems
> > like it introduces an additional attack vector for someone who wants
> > to subvert the root zone; you could announce a bogus route which
> > covers a root server's address, answer AXFR requests for a short
> > period with a bogus zone, then withdraw the route; the hijack window
>
> The current root zone publication mechanism also involves a GPG signed
> copy made available via FTP. Of course, this involves more maintenance
> effort than inbound *XFR. However, I agree that any distribution mechanism
> adds another attack target.
>
> > I also don't know of any formal undertaking by any of the current
> > "real" root nameserver operators to leave un-authenticated [AI]XFR
> > access to their servers for the root zone open, so there's the
> > operational issue of needing to verify regularly that transfers to
> > the stealth slave are succeeding.
>
> Quote from RFC 2780:
>
> 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer,
> queries from clients other than other root servers. This
> restriction is intended to, among other things, prevent
> unnecessary load on the root servers as advice has been heard
> such as "To avoid having a corruptible cache, make your server a
> stealth secondary for the root zone." The root servers MAY put
> the root zone up for ftp or other access on one or more less
> critical servers.
>
> Also, I'm not sure there's really a problem to solve. Most of the assessments
> I read said that the root server system as a whole, if not single server
> clusters withstood the attack well. How many 'legitimate' queries to the root
> name servers would an average resolver send within, say, two hours?
> What problem does occur if 'garbage' questions just time out -- both in
> terms of lack of response and load on the recursive resolvers?
> Given the experience with root 'hints' (and others, like Pekka mentioned),
> which part of a potential target audience of a BCP can be assumed to apply
> changes frequently and consistently enough in the long run to have a
> real benefit?
> What are the requirements for a scalable zone distribution infrastructure?
>
> <co-chair-hat on>
> There's still some time left until the -00 cutoff date. Whether aiming at a
> BCP or just an Informational document discussing tradeoffs or acting as an
> archive for all the arguments that this or previous instances of the same
> discussion revealed -- if somebody cares enough, there's always the
> opportunity to submit an individual I-D.
> </co-chair-hat>
Well transfering the root zone was what I was going to
suggest to cove this paragraph of
draft-ietf-dnsop-default-local-zones.
This document has also deliberately ignored zones immediately under
the root. The author believes other methods would be more applicable
for dealing with the excess / bogus traffic these generate.
I actually think that axfr will put less load on the root
servers than all the junk (unqualified names, IPv4 and IPv6
addresses, .local etc.) UDP queries caches. Early versions
of DNSSEC have a zone SIG record which verified the contents
of the transferred zone matched that which was originally
published. There is no tecnological reason to that not to
happen.
Mark
> -Peter
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dnsop
