Slashdot Log In
DNS Complexity
Posted by
kdawson
on Tue May 29, 2007 10:57 PM
from the loosely-specified dept.
from the loosely-specified dept.
ChelleChelle writes "Paul Vixie of Internet Systems Consortium guides us on a journey into the sublime details of the domain name system. Although it contains just a few simple rules, DNS has grown into a system of enormous complexity. This article explores the supposed and true definitions of DNS, and shows some of the tension between the two definitions through the lens of the philosophy of Internet development protocol."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Taking a risk (Score:5, Insightful)
That's the IETF Way (Score:5, Informative)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
(Although some of them do have some neat ASCII art.)
Wow. A real slashdot story (Score:5, Funny)
(http://www.aptenobytes.net/ | Last Journal: Saturday September 27 2003, @09:37PM)
DNS DNS DNS DNS (Score:4, Insightful)
Oh yeah, this is DNS we're talking about. Implementing it IS uninspiring and so abstract, it does make you rather gouge your eyes out with a rusty spoon.
But what DNS does is extremely exciting, and forms the foundation of what makes the Internet actually WORK for people. Think about it - when's the last time there was any major DNS failure? Never? Me too. Damned reliable, damned powerful, and damned easy to get you hooked up to the geek blogs, tunes, IRC, and whatever else we all crave.
Read this if:
A) You work with DNS regularly and want to know if you know enough for it to make some sense to you. (That's me)
B) You are thinking about implementing a DNS server.
Otherwise, move along, find something that might interest you, but take just a moment to reflect how difficult Internet life would be if DNS wasn't so well designed and crafted.
Here's the Cliffs' Notes version (Score:5, Interesting)
(http://kadin.sdf-us.org/ | Last Journal: Tuesday October 16, @01:46PM)
His point is that large systems can become unimaginably complex, even when they begin with a very simple set of rules. Particularly when those rules are vague.
Although he doesn't say it explicitly, I think there are probably some similarities between neutral networks and DNS -- both begin with very simple rules, and then the complexity comes out of the sheer number of connections when you scale it up. Likewise, with DNS, you can have a very simple implementation (say, for a home office) that's quite easy to understand and use. Everything makes sense. It's basically understandable. But then, take that same protocol, even some of the same software, and scale it up to a few billion nodes or whatever DNS has these days, and suddenly the whole thing is so complex, nobody can even begin to really understand it in its entirety. You can't even predict, exactly, how it's going to react to any change -- it's very much like a complex organic system at that point. You can perform experiments on it, and make hypotheses, but even though it's an entirely deterministic system (or ought to be), it acts mysteriously.
BECAUSE of simple rules (Score:5, Insightful)
It might be more accurate to say that systems can become unimaginably complex BECAUSE they have simple rules. The more rules, the more limitations.
Re:DNS DNS DNS DNS (Score:5, Insightful)
I admire Paul Vixie a real whole lot (from afar; when the day comes that I have something interesting to say to him directly I'll be sure to mention it but until then, I'm sure he gets enough email.) That said, this article isn't really interesting to someone who really does work intensively with DNS implementations, and for whom intermediate caching nameserver and client resolver behaviour on the wild-and-wooly internet is a matter of near-daily concern.
It's actually rather depressing insofar as it only confirms what those of us in this position have come to discover: that a system loosely defined has become an ecosystem incapable of complete definition. FTA: "Most of it is not written down anywhere, and some of it would still be considered arguable if you got two or three DNS implementers in a room to talk about it." Ain't that the truth.
No, this article should be read by smart technical users and managers who don't have much experience with DNS and who intuitively believe that the way DNS works in the real world is well-defined and handed down on high on stone tablets from some standards-making body - the sort of well-meaning people who haven't yet realized what "RFC" stands for, if you will. For these people, this article could be a useful eye-opener.
-Isaac
Public DNS is corrupt, but Private DNS is sublime. (Score:4, Interesting)
Then the bribes started, now we have
Internally, I use DNS and I would never replace it. Just secure it. All my Internal Updates for my home DNS System work like this. Using the LDAPDNS system, my reverse lookup zones become distinguished containers, like
relativeDomainName=1+zoneName=0.168.192.in-addr.a
(I'm the guy who wrote this.)
http://slashdot.org/comments.pl?sid=235321&cid=19
That. My zone updates are then wrapped up in SSL and replicated to my other Domain Controller. I would suggest that DNS return to its roots, restore the old Domain hierarchy and discontinue all these other TLDs, but they won't. There is too much money to be illegitimately made off the corruption of DNS.
Re:Public DNS is corrupt, but Private DNS is subli (Score:4, Informative)
(http://k-zone.org/)
So sometimes politics and DNS might be for a good cause.
Re:Public DNS is corrupt, but Private DNS is subli (Score:4, Interesting)
Re:Public DNS is corrupt, but Private DNS is subli (Score:4, Funny)
Internally, I use DNS and I would never replace it. Just secure it. All my Internal Updates for my home DNS System work like this. Using the LDAPDNS system, my reverse lookup zones become distinguished containers, like
relativeDomainName=1+zoneName=0.168.192.in-addr.a
You set this up for your freakin' home network!?!?!? Brother, there's this wild and wonderful thing out there called the world and you really, REALLY need to get a taste of it!
Some of the highlights that you'd do well to consider:
First, there's the Woman [google.com]. Life with a good woman is a life with greater extremes. Good moments are way better, bad moments are way worse.
Another good thing to try while roaming the wild, real world: Beer! This can be a good way to land a woman, if only for a night. [google.com]
Put the two together under the right circumstances, and you just might be able to experience perhaps the greatest pleasure of them all: SEX! Many would argue that this is the point of having a woman. [google.com] I'd argue instead that basic physiology has the point belonging to the man, but I digress...
Seriously, implementing an LDAP backend to DNS for a home network is about like using a jet engine for a ceiling fan. I'd love to know all the details of your implementation, since it would likely make a good candidate for submission to another good website. [thedailywtf.com]
Lastly, to do "secure" DNS updates is pretty simple. I keep the DNS zone files on my laptop. All my DNS nameservers are configured identically, as master servers. I use a script to SCP the files to the nameservers when I do a DNS update. Stupid simple, excellent security a la SSH.
Dynamic DNS (Score:3, Interesting)
(Last Journal: Friday November 09, @01:36AM)
Re:Dynamic DNS (Score:4, Informative)
(http://www.nickfitz.co.uk/)
I don't know who this "everyone" is of whom you speak, but I'm with one of the biggest ISPs in the UK and they use DHCP; I have no guarantee of what my IP address will be from one day to the next. I could probably pay extra for a static IP, but it's not worth the money.
If you mean "everybody leaves their home network running at all times so they never lose the IP address they got via DHCP when they first turned their cable modem on", then you're ignoring the effect of network outages, power failure, and the fact that if I'm going away I turn all electrical kit off, as I don't want an electrical fire destroying my home and endangering the lives and property of the other people who live in this building.
There aren't enough IPv4 addresses for every Internet user; I reckon that, in term of individual users, it's a small minority worldwide who have a static IP address.
moving hosts blows (Score:5, Interesting)
(http://localhost:5800/)
I eventually got onto their 'support' crew in Singapore who assured that their engineers were looking into it. I don't know how much looking you need to do to change a single entry on a DNS table from "nnn.nnn.nnn.42" to "nnn.nnn.nnn.38".
Oh and here's a single page [acmqueue.com] version of TFA.
Re:moving hosts blows (Score:5, Interesting)
Not sure exactly what your rant was about, but it just sounds like you had crappy support from ISP staff. Not really news, that. There's nothing about the DNS down under that makes it inherently slow. We moved our site recently to a different IP (different ISP, in fact), but we host our own DNS so we had control of the process. I reduced the TTL on the record a few days beforehand, and then really reduced it shortly before we launched the new site, and voila -- the updated record was visible to everyone pretty much instantly. (Except for people who configure their DNS proxies to ignore/override TTL values, but that's their problem.)
Obviously, relying on third parties to do the right thing by you is a crapshoot at the best of times. Not everyone has the luxury of hosting things themselves, though.
Article wrong about Unicode? (Score:3, Insightful)
UTF-8 should be perfectly compatible with the case folding. The character which get folded are in the US-ASCII subset of UTF-8 and therefore have their high bit unset. All multibyte-characters in UTF-8 have the high bit set in each byte, so they aren't subject to that case folding. The DNS standard is, as far as I know, completely UTF-8-compatible except in the places where it explicitly says that "only these particular characters are allowed here".
Optimising DNS lookup time (Score:1)
I've wondered about this for a while, but like any good slashdotter I haven't actually researched it myself, but figured I'd just post it here and see what sort of replies I get.
Where I work, we host a small number of websites, each usually with two or three domain names (one primary name, and the others redirected to that). These are in a variety of domains; the usual TLD's and a few country codes and special domains.
I've set them up so that each major domain has its own set of name servers; i.e. we have host servers defined under a .com name, which all of our .com domains use. .net has its own set, .com.au has its own, and so forth. These all point to the same IP addresses, they're just defined in different domains (i.e. a.ns.ourdomain.com is the same IP as a.ns.ourdomain.com.au).
My reason for doing this is to try to minimize the number of lookups needed. A lookup for "www.example.com" gets a reply saying "the nameservers are a.ns.ourdomain.com and b.ns.ourdomain.com, and their IP addresses are w.x.y.z and a.b.c.d". The resolver can then go straight to our name servers, rather than doing an extra one for ourdomain.com.
This is assuming the resolver is smart enough to realise it can trust the additional records with the IP addresses of [ab].ns.ourdomain.com, since they're coming from a server which is authoritative for .com, anyway.
While this is fine in theory, I don't know (and haven't tested) whether popular DNS servers actually do manage to make quicker lookups using this strategy. If not, then it's rather pointless -- there's a little bit more administrative overhead involved in maintaining separate NS host records.
Any DNS gurus out there have an answer to this? Anyone care to speculate wildly?
Domain Names sdrawkcaB? (Score:4, Interesting)
(http://www.mutube.com/)
Domain Names are the exception, with the "top level" domain on the right, while the left (most significant bit) can be stuffed with random chaff (a.k.a. subdomains).
I can't help but imagine that this has some impact on how easily people fall for spoofed websites (yourbank.somesite.com vs. com.somesite.yourbank). Being naturally lazy we only read as far down a list as as needed to confirm we have what we're looking for.
Does anyone knows of a historical basis for this decision & do you think it makes any difference?
Evolution (Score:2, Funny)
DNS != BIND (Score:3, Informative)
Once again, BIND is associated with DNS and I'm not even past the third paragraph.
Zone transfers are not DNS-related, they are BIND-related! For that matter, the term ZONE is mainly a BIND thing!
Gah!
Why is DNS so complicated anyway ? (Score:2, Interesting)
(http://fnarg.com/)
Here's one big pain in the butt: listing name servers for a domain. Why the hell don't we use IP addresses for those ? Instead you have a chicken and egg situation where you would need to contact ns1.something.tld to ask about its own address, so instead we cheat with "hints" in the parent server's records and end up listing the IP anyway, making the nameserver's name redundant. Things like that make me wonder what the designers were smoking that day. In the end, it's all just a big relational database, only the tables are each stored on different hosts but the links work the same way, so why the big headache ?