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 <[email protected]> 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 <[email protected]> > Date: Thursday, October 23, 2014 at 17:30 > To: "[email protected]" <[email protected]>, "[email protected]" < > [email protected]> > 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 > >
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
