In message <20131128000148.ga20...@mycre.ws>, Robert Edmonds writes:
> David Conrad wrote:
> > Ed,
> >
> > On Nov 27, 2013, at 6:00 AM, Edward Lewis <ed.le...@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@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: ma...@isc.org
_______________________________________________
dns-operations mailing list
dns-operations@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
