[dns-operations] resolvers considered harmful

[Edward Lewis]

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/4a150cf4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141024/4a150cf4/attachment.bin>