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

[Mark Andrews]

In message <20131128000148.GA20782 at mycre.ws>, Robert Edmonds writes:
> David Conrad wrote:
> > Ed,
> > 
> > On Nov 27, 2013, at 6:00 AM, Edward Lewis <Ed.Lewis at neustar.biz> wrote:
> > > My excuse is - operators limit "the effort expended in fighting
> > > entropy."  Imagine an average operations environment operating as most
> > > environments go.
> > > ...
> > > Eventually one day something breaks and then... .... ...include here
> > > "the only one who can fix it has left."
> >
> > I suspect this argument applies _far_ more to configuring/operating
> > DNSSEC than it does to slaving the root zone, particularly when you take
> > into account the rolling of the root key. For one thing, consider the
> > time intervals between change events that might cause problems.
> >
> > > I'd argue that the resolver admin is also incentivized to do a good
> > > or better job too.  Joe's right in general,
> >
> > Actually, he isn't... :)
> >
> > Slaving a zone is not (or perhaps should not be, despite BIND
> > configuration language) rocket science. Hand wringing about poor resolver
> > operators being unable to master the complexities feels like the "don't
> > look behind the curtain" scene of the Wizard of Oz.
> 
> 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.

	zone "." IN {
		type slave;
		file "slave/root";
		masters { 192.5.5.241; };
		notify no;
	};

> 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.  i believe unbound, powerdns, BIND 10,
> djbdns, etc. are all either recursive only, or split recursive and
> authoritative service into separate daemons, afaik.  but i'm not
> familiar with any of the closed source implementations.
> 
> 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?

You can do stuff like this (cut-and-pasted from a live config).

managed-keys {
        . initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=";
};

view "secure" {
        match-clients { localnets; };
        match-recursive-only yes;
        zone . {
                type static-stub;
                server-addresses { 127.0.0.1; };
        };
};

view "external" {
        match-clients { localnets; };
        recursion no;
        allow-recursion { none; };

	zone "." IN {
		type slave;
		file "slave/root";
		masters { 192.5.5.241; };
		notify no;
	};
};

The same trick can be used to validate data from other zones that
are locally served.

> > The root represents one of the few single points of failure on the
> > Internet. Continued reliance on that single point of failure,
> > particularly in the days of multi-hundred of gigabit DoS attack at the
> > flip of a switch potential, is ... questionable. Given the lack of
> > ability for the Internet operations community to effectively deploy BCP
> > 38, I anticipate this situation to only get worse.  Arguments along the
> > lines of "but anycast!" don't really help when the root instances you get
> > routed to have fallen over due to the latest DoS attack. Yes, the system
> > as a whole can still be said to be responsive, but you're SOL.
> >
> > I would agree that existing resolver technology makes it more
> > challenging than it should be to decentralize the root. Fixing that is
> > long over due IMHO.

> well, 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.

If everybody was validating that would be a great idea.

> -- 
> Robert Edmonds
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-jobs mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org