Hi Paul, Warren,
On 4 July 2014 at 16:50:08, Paul Hoffman (paul.hoff...@vpnc.org) wrote:
Greetings. Warren and I have done a major revision on this draft, narrowing
the design
goals, and presenting more concrete proposals for how the mechanism would
work. We welcome
more feedback, and hope to discuss it in the WG in Toronto.
I think there is much in the language of this draft that could be tightened up,
but this is an idea for discussion so I'll avoid a pedantic line-by-line
dissection. But I can give you the full pedantry if you like :-)
On the pros and cons, however (crudely pasted below), see below.
TL;DR: there are way more cons than pros to this proposal. The pros listed are
weak; the cons listed are serious. I don't see a net advantage to the DNS (or
to perceived performance of the DNS for any client) here. This proposal, if
implemented, would represent non-trivial additional complexity with minimal or
no benefit. I am not in favour of it, if that's not obvious.
As noted previously, I am not against documenting and discussing the merits of
slaving the root zone on resolvers (in some fashion). My preference would be
for a draft called something like
draft-ietf-dnsop-slaving-root-on-resolvers-harmful, which could borrow much
of your section 5.1 and 5.2 to make its argument.
I remain very much *not* in favour of making changes to the DNS specification
that don't have a clear benefit to balance their costs.
---
5.1. Pros
o Junk queries / negative caching - Currently, a significant number
of queries to the root servers are junk queries. Many of these
queries are TLDs that do not (and may never) exist in the root
Another significant source of junk is queries where the negative
TLD answer did not get cached because the queries are for second-
level domains (a negative cache entry for foo.example will not
cover a subsequent query for bar.example).
I think a better way to accommodate the second point is to implement qname
minimisation in recursive server logic.
I don't know that the first point is much of a pro. Root server operators need
to provision significant spare capacity in order to accommodate flash crowds
and attack traffic, and compared to that spare capacity the volume of junk
queries is extremely small. There's no obvious operational benefit to root
server operators in reducing their steady-state query load (in fact, it would
make it harder in some cases to obtain the exchange point capacity you need to
accommodate flash crowds, on exchanges where higher-capacity ports are reserved
for those that have demonstrable need based on steady-state traffic.)
I'm also a little concerned about the word junk. It's a pejorative term that
implies assumptions about the intent of the original query. If my intent is to
confirm that a top-level label doesn't exist, then BLAH/IN/SOA is a perfectly
reasonable query for me to send to a root server. We might assume that a query
Joe's iPhone/IN/SOA sent to a root server is not reasonable, but we're only
assuming; we don't actually have a way of gauging the actual intent with any
accuracy.
o DoS against the root service - By distributing the contents of the
root to many recursive resolvers, the DoS protection for customers
of the root servers is significantly increased. A DDoS may still
be able to take down some recursive servers, but there is much
more root service infrastructure to attack in order to be
effective. Of course, there is still a zone distribution system
that could be attacked (but it would need to be kept down for a
much longer time to cause significant damage, and so far the root
has stood up just fine to DDoS.
If I was to paraphrase this advantage with malicious intent :-), you mean that
we don't have to rely upon the root server system to continue to perform under
attack, because we don't need the root server system any more, although we do
need the new bits of the root server system we are specifying, and if those
bits are not available we do need the conventional root server system after
all, but that's probably ok because the root server system is pretty
resilient. That sounds a bit circular.
o Small increase to privacy of requests - This also removes a place
where attackers could collect information. Although query name
minimization also achieves some of this, it does still leak the
TLDs that people behind a resolver are querying for, which may in
itself be a concern (for example someone in a homophobic country
who is querying for a name in .gay).
There's an implication here that a recursive resolver sending a query to a root
server is potentially impinging upon the privacy of its anonymous clients. I
find that a bit difficult to swallow.
I'm surprised not to see improves performance for clients in this list, on
the general principle that every cache miss
