Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
The Internet

DNS Complexity 93

Posted by kdawson
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.

DNS Complexity

Comments Filter:
  • Taking a risk (Score:5, Insightful)

    by Anonymous Coward on Tuesday May 29, 2007 @11:07PM (#19317863)
    I'm going to risk sounding like an idiot and say that I think it's inhuman that somebody could write an article explaining how DNS works without having at least one diagram in it. I mean, c'mon, I can wade through piles of opaque text with the best of them, but just throw me a bone here, alright?
    • That's the IETF Way (Score:5, Informative)

      by Kadin2048 (468275) * <`ten.yxox' `ta' `nidak.todhsals'> on Tuesday May 29, 2007 @11:26PM (#19317993) Homepage Journal
      Well, it was written by Paul Vixie, better known for writing a whole bunch of RFCs ... they're not known for being exactly graphics-heavy, either.

      (Although some of them do have some neat ASCII art.)


    • He's the guy that inadequately describes complex systems then gets into arguments about how they ought to be implemented because his implementations and his protocol descriptions don't always overlap.

      That said, he's a fairly important player in the Internet world, despite needing a bit of a rethink on how he writes RFCs.
    • While the DNS definition is defined in RFCs. Paul's BIND implementation, as well as various commercially hardened versions he has worked on over the years are part of the glue we depend on to hold the Internet together. His code runs in more Unix/Linux systems than you can imagine today. I am a Real Vixie fanboi. The DNS paradigm sits on top of the address resolution paradigm and has added the flexibility we have need to grow the Internet over the last several decades. My hat is off to Paul.
    • Judging from that one article, Paul Vixie is a terrible writer. His thoughts are very unorganized. And, like many people with little understanding of how to write well, he is obviously not aware of the need to have an editor.

      James Michener, the famous writer (South Pacific), was very intense about having his writing edited before he would present it to readers. With one of his books he said he and an editor read every word 5 times together.

      This is NOT a comment about his achievements and contributions
      • by svanstrom (734343)
        Writing style is often a habit formed by the understanding, or lack thereof, by the ones you are writing for/to; when questioning a persons style you must ask yourself a lot of quite hard (to answer) questions regarding both yourself, your understanding of the text/style and also the writer.

        So, is he really "a terrible writer" limiting himself by his "inability to communicate", or was it just a case of an article written in a style not prefered/suitable for you (and/or the general reader of where the articl
  • by m0nkyman (7101) on Tuesday May 29, 2007 @11:15PM (#19317919) Homepage Journal
    Been a while since I've seen one of these.
  • DNS DNS DNS DNS (Score:4, Insightful)

    by mcrbids (148650) on Tuesday May 29, 2007 @11:18PM (#19317929) Journal
    While technically well written and clear, this is one of the most uninspiring pieces of work imaginable describing the values of DNS. It's so bad that I'd rather gouge my eyes out with a spoon. Highly technical and detailed while still being abstract, it's 100% accurate while still managing to be utterly devoid of any usefulness whatsoever.

    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.
    • Basically, Vixie's point in the whole article really isn't to rehash how DNS works (although he does basically do that), but to make a rather interesting point about complex systems.

      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.
      • Re: (Score:3, Interesting)

        by apathy maybe (922212)
        So, sort of like The Game of Life then? I've made the point before (not here though), that The Game of Life is a good example of simple rules creating a (potentially, very) complex situation. I then used it to make the analogy with the universe we live in.

        Take gliders for example, you could observe them, and work out how they work, but each type of glider works differently. As such, you would have a different set of rules for each. Unless you noticed that the same (fourish) rules worked all the time. And if
        • by amorsen (7485)
          I've made the point before (not here though), that The Game of Life is a good example of simple rules creating a (potentially, very) complex situation.

          Game of Life is Turing Complete. (Proved the boring way, by simply implementing logic gates.)
      • by CarpetShark (865376) on Wednesday May 30, 2007 @06:54AM (#19319805)

        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.


        It might be more accurate to say that systems can become unimaginably complex BECAUSE they have simple rules. The more rules, the more limitations.
    • by isaac (2852) on Wednesday May 30, 2007 @01:21AM (#19318503)

      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.


      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
      • Re: (Score:3, Insightful)

        by isaac (2852)
        To reply to myself...

        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.

        "Depressing" is the wrong word here - though it can certainly be frustrating to continually confront problems that wouldn't be problems if DNS weren't such a losely-defined protocol. When the scales truly fall from one's eyes, though, one realizes that it's not coincidental that the wid

        • by rthille (8526)
          Reminds me of the essay about C vs. Lisp and the Berkley UNIX hackers vs. the harvard OS implementors...

          but I'm too lazy to find a link.
    • Think about it - when's the last time there was any major DNS failure? Never? Me too.

      I remember when Network Solutions forgot to load about half the .com zone file one night [interesting-people.org], and most of the internet disappeared. That was only 10 years ago.

      Rich.

      • Re: (Score:2, Interesting)

        by pairo (519657)
        For me, it happens every other month or so, with the .ro registrar screwing things up on a regular basis. Last time, everything newer than 2002ish went AWOL for a almost a full day.
    • Weakness of DNS (Score:2, Interesting)

      by Anonymous Coward
      I'd rather say that DNS is damned weak. It's probably the weakest point in the Internet infrastructure as a whole, and that's a lot to say. DNS was chosen by SANS Institute as one of the top 20 Internet vulnerabilities in 2006:

      http://www.sans.org/top20/ [sans.org]

      Last time there was a major DNS failure? The DNS system relies on 13 servers. In 2002 nine of them went down due to a DDoS attack, the whole Internet was very slow or unreachable for an hour. This year in February almost three of the servers crashed due to an
      • This year in February almost three of the servers crashed due to another DDoS

        "Almost three"? Would that be "two"? Just funnin' ya, I assume you meant "almost crashed."

        DoD thinking about bombing the source of the DDoS is pretty crazy. I mean, what if it's a script kiddie in my neightborhood? ;-)

        Seriously though, I'm sure that was just "tough talk". I can't imagine any scenario where military action wouldn't backfire in an unprecedented way, and that's even given the context that this administration has r
      • by morcego (260031)

        By the way, remember that Paul Vixie's BIND is just one implementation and it's considered to be flawed by some wise people:

        http://cr.yp.to/djbdns/blurb/unbind.html [cr.yp.to]

        Just because he is wise doesn't mean he doesn't have an agenda of his own (he does).

        I get fairly pissed at DJB when he says bind is flawed, and parades his djbdns in front of us, without mentioning that djbdns only implements a tiny part of what bind does. Well, guess what ? dnsdns is not an option for 90% of the DNS servers (at least). His solu

      • The DNS system relies on 13 servers

        Ahhh, maybe not. It would be better to say the "root servers" are made up of quite a number of servers implementing some level of high availability which usually requires more than one server.

        For example, the F root server [isc.org], operated by Mr Vixie's ISC, is 40 distributed servers around the world accessed by a Hierarchical Anycast technique

        John

    • While technically well written and clear

      Well, is it? From the article:

      "The DNS namespace has a tree structure, where every node has a parent except the root node, which is its own parent."

      This isn't correct. The root node is no exception and DOES have a parent, which is named in the last clause of the quoted sentence.
      Sure, this sounds overly meticulous, as any good formal definition should be. Just rewrite:

      "The DNS namespace has a tree structure, where every node has a parent, with the root node being its own parent."

  • by Zombie Ryushu (803103) on Tuesday May 29, 2007 @11:37PM (#19318057)
    The Public DNS System has become corrupted. It used to be edu, com, org, net, and country codes.

    Then the bribes started, now we have .info, .tv, and god knows what else.

    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.ar pa,dc=0,dc=168,dc=192,dc=in-addr,dc=arpa

    (I'm the guy who wrote this.)

    http://slashdot.org/comments.pl?sid=235321&cid=191 90073 [slashdot.org]

    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.
    • by Anonymous Coward
      You lost me at "distinguished containers."
    • Re: (Score:3, Informative)

      by Rob_Warwick (789939)
      tv is the country code for Tuvalu.
    • I have a better idea: Let's open the process for making up a new TLD to everyone. A minor cost associated with the administrative overhead of setting up a new TLD, and that's it. True, we cheapen existing TLDs considerably, but then they're artificially overpriced anyway.

      It's not like it's a technical issue. The DNS system doesn't care how many TLDs there are, it's irrelevant to the immediate search.
      • by Tony Hoyle (11698)
        It is technical actually - the TLD server has to respond all of the time, every time, even when millions of people want it... caching reduces the load but doesn't eliminate it by any means.

        If a domain goes down it affects one company. If a TLD goes down it affects thousands, perhaps millions (if .com failed for example).

        You could argue that one server == one TLD is a bad model and I wouldn't disagree.. there's no reason for one of the TLD companies to start a couple of hundred of the things - but then can
        • by jesboat (64736)
          You... don't really sound like you know what you're talking about. (Sorry to be blunt.)

          One TLD != one server; on the contrary, TLDs tend to have many, many servers.

          The likes of Verisign, for example, run no less than 13 servers (a.gtld-servers.net through m.gtld-servers.net) for com and net, and, in reality, they almost certainly run many more, since each of those names is probably a cluster of actual machines.

          The GTLD is managed similarly, and I'd be surprised if any other TLDs have less than 6 obviously d
        • Re: (Score:3, Insightful)

          by grasshoppa (657393)
          As has already been pointed out, you can have a single TLD spread across several servers. You can also have multiple TLDs on a single server. More likely, you end up with a combination of these things: Multiple TLDs on a geographically disperse cluster of systems.
    • Re: (Score:3, Interesting)

      by bvankuik (203077)
      Who cares? Is something technically not right about the new TLDs? Or are you afraid someone else is making money off of it?
    • by Professor_UNIX (867045) on Wednesday May 30, 2007 @04:56AM (#19319327)
      Eliminate the domain squatters and you'll eliminate the push for alternative TLDs. I'm sure more than half the domain names in existence are typo-squatting domain hoarders. There's no legitimate reason we need to allow them to keep those domains. Get a posse together of people with a clue and start going through domains. When you come across one that is obviously a domain squatter, delete it and then put more emphasis on analyzing that guy's other domains and delete those if necessary too until you've cleaned up the system. It's not property, you're just leasing a label from the collective community and we can choose to take it back if you're being an asshat.
      • Re: (Score:3, Insightful)

        by MT628496 (959515)
        The problem is that depending on who does these reviews, there will be entirely different results. I don't think that we can legally take the names back, anyway. It sure would be nice though if the /. community got to decide on it. Actually, that would be terrible. We'd spend the whole time fighting amongst ourselves.
        • I don't think that we can legally take the names back, anyway.

          I'm pretty sure that ICANN. All puns aside, think about what that acronym means. Internet Corporation for Assigned Names and Numbers. They get to assign the names and numbers, and therefore they also have the authority to un-assign those names and numbers. ICANN giveth, ICANN taketh away. Ugh. That one wasn't intended. I'll stop now, but hopefully you get my point.
    • The Public DNS System has become corrupted. It used to be edu, com, org, net, and country codes. Then the bribes started, now we have .info, .tv, and god knows what else. Internally, I use DNS and I would never replace it. Just secure it.

      Problem here is that you're mixing two- if not three- distinct issues; the DNS specification (and its implementations) and the choice of top-level domains. That the latter may be badly-chosen is not an inherent flaw of DNS itself. DNS may have flaws, but the poor choice of names is not its fault, any more than poor-quality TV programming reflects a problem with the chosen transmission system or the TV sets.

    • by mcrbids (148650) on Wednesday May 30, 2007 @10:58AM (#19322757) Journal

      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.ar pa,dc=0,dc=168,dc=192,dc=in-addr,dc=arpa


      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)

    by iminplaya (723125) <iminplaya.gmail@com> on Wednesday May 30, 2007 @12:00AM (#19318167) Journal
    If more ISPs provided this, would it make traffic unbearable? How many dynamic domain name servers could we tolerate? Could we finally make the registrar problem go away?
    • Re: (Score:2, Informative)

      by Tony Hoyle (11698)
      It quite possibly would - dynamic dns domains have expiry times in the minute or even second range, making caching them impractical. A true domain expires in 24-36 hours.

      TBH I'd rather dynamic dns went away.. it's a hack from the dialup days when people got dynamic IP addresses. Everyone's 'always on' now so dynamic IP is pointless.
      • Re:Dynamic DNS (Score:4, Informative)

        by NickFitz (5849) <slashdotNO@SPAMnickfitz.co.uk> on Wednesday May 30, 2007 @07:01AM (#19319839) Homepage

        Everyone's 'always on' now so dynamic IP is pointless.

        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.

        • 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

          Or that in crowded Verizon territory you're going to get a 15 minute lease and your next IP won't be the same. Ugh, yes, I switched my folks to a cable modem because of it.

          as I don't want an electrical fire dest
          • Oh, don't worry about that - your receptacles are rated for a number of insertions too - just as you unplug one of your items to make sure it doesn't catch fire is the time that the spring metal finally weakens enough so that once you're halfway to the airport it finally develops a stress fracture and shorts out the wiring.

            About 25 years ago in the UK, it was common for wall outlets to have a switch built in to them. Don't know if they still do that.

            Also, TV networks (like the BBC) would sign off (at perhap
            • by @madeus (24818)

              About 25 years ago in the UK, it was common for wall outlets to have a switch built in to them. Don't know if they still do that.

              Yep, we still have that. Over-engineered monstrosities, solid 3 (rectangular, not round) pins and an on/off switch at every socket (but not typically on 4/8/12 bar extensions you buy at retail - some do, some don't) - with the exception of bathrooms which may only have the universal 12 volt 2 pin adapter in them.

              Earth on all of them, except certain devices - the exact criteria for which I'm sure of (typically applies to lightweight things like xmas tree decoration lights), they often just have a plastic pi

      • by iminplaya (723125)
        Everyone's 'always on' now so dynamic IP is pointless.

        I got a system that's always on, but the IP does change everyday. Don't know why while it's on. At home I shut down when out of the house(don't like leaving the door open), so there it always changes.
      • My DSL service has a dynamic IP. The lease length is about a week. Regardless of whether I leave it on or not, it gets a new IP at least once a week.
  • moving hosts blows (Score:5, Interesting)

    by weighn (578357) <weighn@QUOTEgmail.com minus punct> on Wednesday May 30, 2007 @12:01AM (#19318177) Homepage
    my website is in an internet backwater [wikipedia.org] and you wouldn't believe the crap we went through when our hosting provider changed the IP address of the server. We were given a weeks' notice of the new IP and the knobs at ozemail or uunet or iinet or whatever the fsck they are called for the moment still had us hanging for TWO DAYS after the address was changed (it wasn't due to dns caching - that added another 24-48 hours according to some lookups).

    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.

    • by totally bogus dude (1040246) on Wednesday May 30, 2007 @04:14AM (#19319181)

      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.

      • by amorsen (7485)
        (Except for people who configure their DNS proxies to ignore/override TTL values, but that's their problem.)

        Their problem, and a problem for all their customers. Some of the largest ISP's do it.
      • by weighn (578357)

        Not sure exactly what your rant was about, but it just sounds like you had crappy support from ISP staff.
        meh, half the time I don't even know - but I'd mod you informative if I could. The points you made re. TTL will come in handy next time this comes up. thanks !
      • tinydns [cr.yp.to] has a nice option to make one address expire at a specific time and another take its place (or just start serving a record at a specific time, or have a record stop working at a specific time). When it gets close to the expiry time, the existing record's TTL is reduced accordingly to prevent problems as well -- its quite a nice feature really for IP changes.
  • by amorsen (7485) <benny+slashdot@amorsen.dk> on Wednesday May 30, 2007 @04:34AM (#19319241)
    From the article: "To express multilingual symbol sets usually means Unicode, whose binary representation is not directly compatible with the upper/lowercase "folding" required for DNS labels."

    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".
  • 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 ha

    • use the include directive?
    • by benji fr (632243)
      You CAN use glue records, I mean just put your www.example.com A record into the .com root server, and it will answer pretty fast, but you SHOULDN'T do that of course, and nobody in big companies or big ISP do this isn't it -...-
  • by mutube (981006) on Wednesday May 30, 2007 @06:21AM (#19319685) Homepage
    When written in ltr language most hierarchies follow that direction. Numbers have the most significant bit(s) at the left, taxonomies are written species:subspecies:variety, pages are identified as home > category > page.

    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?

    • Re: (Score:3, Informative)

      by NickFitz (5849)

      Tim Berners Lee now thinks he got it wrong; [bcs.org] he now believes that URIs should have had the form http:com/example/blah/, rather than http://blah.example.com/.

      • That's a bad idea.

        With that, you can't tell where a host name begins and where the URI starts.

        And he even thinks that is GOOD:
        quote: "This would mean the BCS could have one server for the whole site or have one specific to members and the URL wouldn't have to be different."

        Doh.

        Say you have a conventional URL of http://blah.example.com/sub/foo
        If we do things he proposed in that page how does he expect the browser to find the IP address for the server to go to?

        With his suggestion the url will look like:

        http:c
        • "http:com/example/blah/sub/foo
          Now that's very nice in "dreamland" where the speed of light is infinite and everything is perfect.
          But in the real world, what domain name should the browser try in order to get the IP address to connect to?"

          Do you know a single word about DNS? I don't think so.

          First: we are talking about names, not service resources, so the basic example is looking for com.example.blah.sub.foo, which is just exactly the same than foo.sub.blah.example.com regarding its recursive search path: y
          • by TheLink (130905)
            I may be ignorant, but I'm not that ignorant. I know DNS and how it works. And I also know how lots of other stuff works too.

            You're wrong because it's not just about DNS. It's about how things work in real life and equally importantly it's about how things _FAIL_ in real life.

            TCP connections still take time to make, and there is a significant timeout if the other end is firewalled (ignores TCP/80).

            Try this on a linux/*BSD box: time wget http://www.microsoft.com:82/foo/bar/com/baz

            See how long that takes to t
            • "And remember after that times out, with the "New Berners" approach you will have to try to fetch:
              http://foo.www.microsoft.com:82/bar/com/baz [microsoft.com]
              http://bar.foo.www.microsoft.com:82/com/baz [microsoft.com]
              http://com.bar.foo.www.microsoft.com:82/baz [microsoft.com]
              http://baz.com.bar.foo.www.microsoft.com:82/ [microsoft.com]
              And only after all that should the browser give up."

              Why on hell? For one, it wouldn't be www.microsoft.com but com/microsoft/www. For second, assuming equivalent to current expansions, it would be "www" the one to expand to microsoft/www o
              • by TheLink (130905)
                You said: "Why on hell? For one, it wouldn't be www.microsoft.com but com/microsoft/www. For second, assuming equivalent to current expansions, it would be "www" the one to expand to microsoft/www or com/microsoft/www, exactly like now. I really don't see where the "prefixes for alternate searchs" in your example come from."

                Are you for real? I gave the example that way because all the following URLs are expressed in the same way in the "New Berners" approach.

                All these "conventional URLs":
                http://com:82/micro
    • Rob Pike and Peter Weinberger wrote a paper in 1985 called "The Hideous Name", arguing against DNS's naming order in favor of Plan 9's Unix-like order. Plan 9 very aggressively uses the file system naming structure for everything, and they argue that consistent naming systems are much better than the alternatives, including the relatively new Arpanet naming system that some people were starting to use for email. I haven't read it in a decade or more, but one issue besides the one you mention is that if y
  • Evolution (Score:2, Funny)

    by RancidMilk (872628)
    I hear that the root DNS servers are monkeys. After all, at the root of all tree based architectures is monkeys. (I also hear that if you go to the edge of the internet, you'll fall off the edge of it!)
  • DNS != BIND (Score:3, Informative)

    by RedHat Rocky (94208) on Wednesday May 30, 2007 @08:51AM (#19320817)
    *sigh*

    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!
  • I often find myself wondering why most internet standards are so complex in the first place. Let's face it: DNS looks up a name in a database and spits out a number. It's like a phone book for the internet (white pages, that is). So then, why the hell is it such a pain to configure with its weird-ass zone files that half the world seems to struggle with, and obscure vulnerabilities like cache poisoning. Why can't it be as simple as "domain = IP" or "I don't know, but server X might" because that's basic
    • by NateTech (50881)
      You're mixing up DNS with the implementation of DNS in software, specfically BIND.

      There *are* DNS systems that use relational databases which you can query and/or update with standard SQL statements.

      BIND and its syntax (while I'm fluent in it and very good at it, so I don't bother with above-mentioned RDBMS-based systems) is NOT DNS.

The only problem with being a man of leisure is that you can never stop and take a rest.

Working...