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

[David Conrad]

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.

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.

Regards,
-drc


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20131127/1f6d6731/attachment.sig>