[dns-operations] resolvers considered harmful

[George Michaelson]

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.

-George





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
> side.
>
>  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.
>
>  Regards
> Jason Livingood
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141024/dbcfb57c/attachment.html>