[dns-operations] Agile countermeasures

[Mark Andrews]

> Paul Vixie wrote:
> >
> >   nick weaver and masataka ohta
> > have each made some non-modal proposals about noncaching of data, and i
> > think the WG should seriously investigate, and prefer, non-modal proposals.
> 
> I've been giving some thought to some of the underlying vulnerabilities, 
> where the following intersect:
> - the protocols involved
> - the strategies of resolvers
> - the data in the root and TLD *zones* (emphasis on zone vs domain)
> 
> At the root of the Kaminsky vulnerability is the ability to feed data 
> into a cache, where the data in question
> is provided in the "Additional" section.
> 
> If we ignore, for the moment, when/whether/what referrals are provided 
> by servers in "Authority" sections,
> and consider only the case of "if there *is* an authority section", then:
> 
> The Question:
> When is it strictly necessary that Additional section data be provided 
> *and* used (cached)?
> 
> 
> (Undoubtedly there are cases where it is absolutely necessary, to bridge 
> the gap at a zone cut.
> If you have "example.com    NS    ns1.example.com", the only possible 
> way for an empty cache to resolve the address of ns1.example.com, is via 
> glue A/AAAA RR's.)
> 
> But first, a quick sidebar...
> 
> 
> Sidebar: namespace congruity and phantom namespace
> 
> The main axiom of "the Domain Name System", is the "the".  (At least, 
> for the public DNS sanctioned by ICANN et al.) There is only one.
> The name space is hierarchical, and delegations occur at zone cuts.
> Any legitimate, actual leaf in the name space must be reachable by 
> starting at the root, and possibly crossing one or more zone cuts, 
> reaching a terminal node in the label space of some leaf zone.
> 
> Depending on the domain names of NS RR's used in delegations (at zone 
> cuts), with attendant glue A/AAAA records, it may be possible to 
> establish "phantom leaf" labels in the name space which are not 
> reachable via top-down tree walking, because one or more parent domains 
> of the NS RR's do not exist.
> 
> If there were, for example, "example.com     NS    example.bar" with 
> "example.bar    A    10.1.2.3", if the caching resolver accepted that 
> delegation, a new, non-existent TLD, "bar." with one leaf entry, 
> "example.bar", would suddenly exist in the resolver's cache.
> 
> Obviously, this is not something intentional, nor is it something that 
> should generally be considered acceptable practice.
> 
> (end of sidebar)
> 
> If we exclude, axiomatically, the legitimacy of such "phantom" namespace 
> elements, then we can then say the following are true:
> - every leaf entry in the public DNS exists (and is served 
> authoritatively) in one zone only
> - every legitimate zone is delegated from its parent zone at a zone cut 
> boundary
> - every legitimate zone is served by one or more name servers, who serve 
> that zone authoritatively
> - every legitimate zone is anchored directly or indirectly at the root 
> "." of the public DNS
> 
> Taking the above together, then, it would be sufficient for resolving 
> anything legitimate in the public DNS, for glue A/AAAA RR's to exist 
> only in the immediate parent's zone.
> (I can elaborate on this if anyone wants, but I'm trying to keep this 
> short).
> 
> Thus, The Answer:
> If the *actual* glue A/AAAA RR's in (at a minimum) the root and all TLD 
> zones met this condition, then the only time a resolver would ever 
> *need* to accept "Additional" data would be in those exact cases, where 
> the "Additional" data were given in the answer to a query for an A/AAAA 
> RR, where the "Question" was for the RHS of a delegation, which was 
> subordinate to (i.e. a child of) the LHS of the delegation.
> 
> What this means:
> That the "Additional" section could be ignored in all other cases.
> 
> And I *think* this would, in turn, result in the "birthday attack" race 
> only being run when the TTL of glue A/AAAA RR's expires.
> 
> Note also, that there will generally be orders of magnitude more NS 
> entries pointing to the same RHS, and thus many fewer such races being 
> run generally.
> 
> As a data point, I examined a pretty big TLD (org), and verified that no 
> out-of-zone glue A/AAAA RR's exist - only subordinate A/AAAA glue RR's 
> exist.
> (If other TLD operators wouldn't mind checking this, and providing 
> similar data points, I think we could possibly consider standardizing 
> the non-use of Additional data.)
> 
> Brian Dickson
> 
> P.S. There is an important Corollary to the above:
> There is nothing in the naming of nameservers (in NS records) that 
> restricts the levels of indirection that can occur, between the names of 
> zones served, and the names of the nameservers serving those zones.
> As a practical matter, operators of nameservers *SHOULD* make reasonable 
> efforts to limit the actual levels of indirection.
> And, ideally, nameservers *should*, if possible and practical, be 
> authoritative for their own names. If I have ns1.foo.example.com, and 
> ask it for the A RR for ns1.foo.example.com, life is easier if it gives 
> the answer, and does so authoritatively, *and* is itself listed in the 
> NS RR set for the domain foo.example.com.
> 
> --
> to unsubscribe send a message to namedroppers-request at ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>

	I can create delegations that REQUIRE glue from "DE" for
	zones under "COM" and glue in "COM" for zones under "DE"
	for the delegations to work.

	e.g.
		example.de	NS ns1.example.com
		example.com	NS ns1.example.de

	Back about BIND 4.9.[23] I configured named to stop accepting
	glue that wasn't under the parent zone.  I did this so I
	could chase down bad glue.  If there was bad glue I knew
	it had to come for a parent, grandparent etc.  I also knew
	that it would break delegations like the one I'm describing
	above but I also knew they were rare.

	I could have been stricter and only allowed glue under the
	delegation but that would have broken configurations like
	this

		example1.com	NS ns1.example2.com
		example2.com	NS ns1.example1.com

	and not made the job of finding bad glue any easier.  One
	would still have to check all the parents.

	The TLD's know named and other servers don't accept cross
	zone and they also know that they won't emit it so they
	don't bother collecting it.

	DE and some TLD's don't event collect sibling glue.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org