[dns-operations] Agile countermeasures

[Brian Dickson]

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.