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.