[dns-operations] resolvers considered harmful
ggm at apnic.net
Fri Oct 24 03:26:17 UTC 2014
I am probably a contrarian, but having lived the time of not having DNS,
into the time of having a simple DNS, to the time of a complex DNS I can't
understand, I yearn for a simpler DNS.
The web obviously works. It works without "resolvers" as the assumed norm.
Caches and Proxies exist but the basics are written to assume they aren't
there, and what I _love_ is that well behaving proxies and caches intrude
X-Trace lines into the thing so you can tell who is in the loop for debug
and analysis. (I am simplifying)
If we return to a world where people ask questions, and agents forwarding
on their behalf, or answering on the authoritative source's behalf tell you
so, then I'd be happy.
I liked the various proposals to re-state DNS in JSON. Precisely because it
would trivially work as a service over HTTP(s) and would be arguably no
worse than what we have.
On 24 October 2014 11:46, Edward Lewis <edward.lewis at icann.org> wrote:
> Talk about a DNS amplification attack - a seven page paper getting 60+
> messages. I didn’t do the math, but I bet more was written about the paper
> than in the paper. With all this list traffic, I feel compelled to join
> in. If you have work to do, you might want to skip the rest of the message.
> Most of my thoughts are in Jason’s reply below. To extend #2 - besides
> the small sample size, the patterns used in the initial data set represent
> only one class of use cases (the home user). Inside enterprises, recursion
> is used in many imaginative (I’ll go with that word) ways, from having to
> live with legacy set ups, non-standard services using not-quite cookie
> cutter implementations. If I were to judge the paper, I’d first complain
> that the input data set was way too restrictive. (Not every use of the
> Internet is from a Google Ad running flash in a browser ;) - sorry a poor
> jab at Geoff.) (Look, seriously, I’m kidding.)
> The DNS is not a client-server protocol, it is a system composed of a
> lot of client-server relationships (e.g., a Notify client is tied to an
> AXFR server and a notify server is tied to an AXFR client - one example of
> how the system twists and turns the notion of client-server around). I
> mention this because “removing” the recursive elements is forcing DNS in to
> a client-server model - one should be wary of trying to do such a
> retrofit. DNS is a query-response protocol, but not a client-server
> protocol. (I’d say it might even pre-date client-server as a normal way to
> write protocols. I’m not sure of that, I do recall lecturing on what
> “client-server” meant well after RFC 1034/RFC 1035 were published.)
> Suggesting removing the caches isn’t even really a change to the
> protocol, as the “service” of iteratively finding answers still needs to be
> done somewhere. (If you shoved the iteration the other way, away from the
> edges, towards the core, you back to the POTS.) One of the points I want
> to highlight is that “specialization is good” - having one implementation
> specialize in finding information is better than breaking this work load
> amongst a lot of not-as-well-written-for-the-job code fragments. (I think
> I may have seen that appear in one reply.) Beside the blue-sky statement
> that specialization is good, there was a recent thread on this list where
> someone found a set of servers that gave answers to specific questions -
> but dig +trace failed. I’d once seen this - my code to poke at servers
> failed to get answers, but a well-written BIND recursive server managed to
> navigate the muddy waters and find the answer. What heuristics BIND uses
> to find answers are a lot more developed than a causal observer might
> assume. Loosing caching loses concentration of well-written code.
> The DNS is not an easy system to dissect. There are so many aspects to
> its architecture. It’s ugly in a lot of places and one wonders how it
> functions at all. Believe me, I’ve had this thing up on the lift and the
> undercarriage is a mess. The astounding thing is that it works at all -
> and it works so well there’s a huge industry built to operate it. I still
> can’t believe that specialists cross oceans on nearly a monthly basis just
> to talk about it. I.e., when anyone thinks they can improve the system by
> one little tweak, they will probably be in for a rude awakening. Still, I
> wouldn’t build another protocol like this.
> (Time for the showing my age comment.) The only thing I find annoying
> about academic papers is the two-column style. I have to blow the font
> size up so big I have to read down one and then scroll back up the other
> Won’t we want caching on the Interplanetary Network? ;)
> From: <Livingood>, Jason <Jason_Livingood at cable.comcast.com>
> Date: Thursday, October 23, 2014 at 17:30
> To: "mallman at icir.org" <mallman at icir.org>, "dns-operations at dns-oarc.net" <
> dns-operations at dns-oarc.net>
> Subject: Re: [dns-operations] resolvers considered harmful
> Interesting paper – thanks for giving the list a heads up. My comments:
> 1 – I think the claim “First, removing resolvers simplifies the overall
> system” is a matter of opinion. I may even argue the opposite, that the
> prevalence of large scale resolvers simplifies the overall system (but as
> an operator of one, I am admittedly biased).
> 2 – The sample size of a resolver serving 100 home users seems small.
> You may want to try to collect data from larger networks.
> 3 – I am not sure that authoritative server operators would be prepared
> for the large increase in query volumes, and not sure they’d be prepared to
> mitigate that by compromising with longer TTLs.
> Jason Livingood
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dns-operations