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

[Robert Edmonds]

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.

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?

> 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 overdue 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.

-- 
Robert Edmonds