[dns-operations] FreeBSD and the slaving of the root zone

Mark Andrews Mark_Andrews at isc.org
Wed Aug 1 00:39:16 UTC 2007


> On Tue, 31 Jul 2007, Patrik Fltstrm wrote:
> > - We need a distribution mechanism for the root zone that scales
> 
> No argument there.  AXFR from existing root servers is a non-starter.
> 
> > - We need the root zone signed with DNSSEC (tsig is not enough for me)
> 
> Well, TSIG is good enough for the root operators: the root zone is
> protected via TSIG as it travels from the stealth master servers
> operated by VeriSign to the various root servers.

	Plain TSIG is clearly inappropriate.  TKEY would work but would
	put excessive load on the roots.

	What will work is re-introducing zone signatures.  See the
	early DNSSEC work.

	If we had "glue" signature (signatures for the NS and all
	records below delegations) validating the zone post transfer
	would also work.
 
> I further note that the canonical publicly available root zone on
> ftp.rs.internic.net is PGP signed.
> 
> > - We need to know that the actual level of broken queries to the root  
> > servers will go down (if people today query for "localhost.", that  
> > indicate a broken full service resolver, so how will a similarly  
> > broken slave for root zone behave?)
> 
> I think we can safely attribute such queries not to broken full
> service resolvers but to inappropriate queries issued/leaking from
> upstream applications and stub resolvers.  Having a local recursive
> name server authoritative for the root would absolutely stop such
> queries from reaching the roots.
> 
> > I.e. I have no idea what *real* problem this solves.
> 
> Crap to the roots.  Although, as John Crain pointed out, the root
> operators really need to provision for attack scenarios, and attack
> traffic dwarfs the crap by orders of magnitude.  So this may be
> solving a non-problem, but it doesn't hurt to discuss the idea.

	It also improves response times and reduces cache sizes for
	recursive clients.  NXDOMAIN responses, especially signed
	responses, are large blobs of data that need to be cached.

> Matt
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.oarci.net
> http://lists.oarci.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the dns-operations mailing list