<div dir="ltr">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.<div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-George</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 24 October 2014 11:46, Edward Lewis <span dir="ltr"><<a href="mailto:edward.lewis@icann.org" target="_blank">edward.lewis@icann.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:16px;font-family:Calibri,sans-serif">
<div>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.</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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.)</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>(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.</div>
<div><br>
</div>
<div>Won’t we want caching on the Interplanetary Network? ;)</div>
<div><br>
</div>
<span>
<div style="font-family:Calibri;font-size:11pt;text-align:left;color:black;BORDER-BOTTOM:medium none;BORDER-LEFT:medium none;PADDING-BOTTOM:0in;PADDING-LEFT:0in;PADDING-RIGHT:0in;BORDER-TOP:#b5c4df 1pt solid;BORDER-RIGHT:medium none;PADDING-TOP:3pt">
<span style="font-weight:bold">From: </span><Livingood>, Jason <<a href="mailto:Jason_Livingood@cable.comcast.com" target="_blank">Jason_Livingood@cable.comcast.com</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, October 23, 2014 at 17:30<br>
<span style="font-weight:bold">To: </span>"<a href="mailto:mallman@icir.org" target="_blank">mallman@icir.org</a>" <<a href="mailto:mallman@icir.org" target="_blank">mallman@icir.org</a>>, "<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>" <<a href="mailto:dns-operations@dns-oarc.net" target="_blank">dns-operations@dns-oarc.net</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [dns-operations] resolvers considered harmful<br>
</div><div><div class="h5">
<div><br>
</div>
<blockquote style="BORDER-LEFT:#b5c4df 5 solid;PADDING:0 0 0 5;MARGIN:0 0 0 5">
<div>
<div style="word-wrap:break-word;color:rgb(0,0,0);font-size:16px;font-family:Calibri,sans-serif">
<div>Interesting paper – thanks for giving the list a heads up. My comments:</div>
<div><br>
</div>
<div>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).</div>
<div><br>
</div>
<div>2 – The sample size of a resolver serving 100 home users seems small. You may want to try to collect data from larger networks.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Regards</div>
<div>Jason Livingood</div>
</div>
</div>
</blockquote>
</div></div></span>
</div>
</blockquote></div><br></div>