[dns-operations] chrome's 10 character QNAMEs to detect NXDOMAIN rewriting

[Paul Vixie]

Robert Edmonds wrote:
> i'm curious as to exactly what this root zone slaved resolver
> configuration looks like and how it would behave.  i don't believe i've
> ever set up a resolver like that before.

in BIND, you just make yourself a secondary server for ".", pulling from
192.5.5.241 (f-root has always been open to AXFR, and is very well
served through its global anycast network). do this in a view that is
also recursive. the impact will be two things:

1. answers to questions like "COM NS" will be AA=1, no matter whether
RD=0 or RD=1 is set in the query.

2. the recursive name server having this secondary for "." will never
forward a query to the root zone; it will either iterate internally for
top-level names which exist, or return authoritative NXDOMAIN for
top-level names which don't.

(there's an argument to be made for AA=0 on such answers and NXDOMAINs,
but BIND does not use its own hostname to determine whether it is a
declared NS RR for a zone, it just shoots from its data.)

> if i understand things right, this config could only be achieved with
> particular resolver implementations that combine authoritative and
> recursive service into the same server, and the only implementation i
> know of that does that is BIND 9. ...

this is true. and i am a strong opponent of mixed-mode (recursive plus
authoritative) servers, and i believe these are deprecated in later DNS
RFC's, and in any case not even BIND 10 will have that feature mix --
but RFC 1034 and RFC 1035 describe all name servers as working this way,
and i expect that if "root zone hidden slave" configuration became
widespread, then many name servers who don't support it today, would add
it in some form -- perhaps only in this particular (root zone) form.

> if such a config is possible, how is it supposed to work with DNSSEC?
> if the DNS server loads a bad copy of the root zone somehow during an
> AXFR, does it use its configured root trust anchor to determine that its
> copy of the zone doesn't validate, or does the act of configuring the
> root zone as an authoritative zone make it more trustworthy, thus
> overriding the need to do DNSSEC validation at the root level?

the latter -- if the zone is authoritative, then it's considered valid.
indeed, no slave validates the zone it fetches from its parent. the
intended protection for zone content is TSIG not DNSSEC. in that sense,
any wide-spread support for "root zone hidden slave" would have to deal
with this. TSIG isn't the answer since the signing key has to be secret
if we want to prevent MiTM attacks on hidden slave root zone content.

> ..., here's a crazy idea: now that the root zone is signed, add a 14th
> root letter, and allow AS112-style service for this new root's service
> addresses.  that way a local network could serve the root zone locally
> (not announcing the service prefixes to any of its peers or upstreams),
> and thus would still have at least one root server available in the case
> of a catastrophe, and it wouldn't be dependent on any implementation
> specifics or even configuration settings in the recursive DNS server in
> order to achieve.  it would require building a resilient AXFR network
> apart from the current root operators, though, as well as a set of
> public operators to backstop the service prefixes to serve networks that
> don't have local instances.

i loved that idea so much that i suggested it to ICANN's Identifier
Technology Innovation committee (of which i am also a member) a few days
before i saw the above-quoted text. see 3.(A). in the text located at:

http://mm.icann.org/pipermail/itipanel/2013-November/000017.html

vixie