Slashdot Mirror


Root DNS Zone Now DNSSEC Signed

r00tyroot writes with news that slipped by yesterday, quoting from the Internet Systems Consortium's release: "ISC joined other key participants of the Internet technical community in celebrating the achievement of a significant milestone for the Domain Name System today as the root zone was digitally signed for the first time. This marked the deployment of the DNS Security Extensions (DNSSEC) at the top level of the DNS hierarchy and ushers the way forward for further roll-out of DNSSEC in the top level domains and DNS Service Providers."

13 of 94 comments (clear)

  1. Software development like the good old days... by Anonymous Coward · · Score: 5, Insightful

    “ISC has been intimately involved with the development of DNSSEC for more than fourteen years..." "Today's milestone marked the final step in a seven month process of evaluation and incremental deployment, assuring operational readiness of systems, software, and processes necessary for any significant change to the DNS root."

    Just like the good old days. Not like the Rapid Application Development that pushes crap out the door that goes obsolete before all the bugs are fixed. I miss those days.

    1. Re:Software development like the good old days... by mcrbids · · Score: 3, Insightful

      Things have changed, a bit. The once radical idea of domain names have become so infrastructural that the failure of the DNS system would cause a DOS attack on the global economy. Basically, there probably isn't a single system that is more critical to the global economy than DNS except perhaps the IMF.

      So, 7 months to roll out... pretty aggressive, if you ask me! I can't imagine the pressure that people in these positions actually have to endure...

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    2. Re:Software development like the good old days... by phyrexianshaw.ca · · Score: 4, Insightful

      though your toilet may continue to work without DNS being there, the company that keeps your water flowing would likely slow to a crawl if they were unable to e-mail/call the partners they do business with.

      Voip servers, when calling other voip servers, will make DNS lookups to get IP's to establish such calls, though anything that's done over the PSTN just goes through the phone companies version of DNS, the CO.

      E-mail would fall apart inside the TTL of the cache entries. web browsing would quickly deteriorate, most debit machines that I've installed are hand coded with Static IP's, though most ABM's were DNS names. (because the service cost for ABM's is much higher than just leading the business owner/tech through changing IP's on a terminal over the phone)

      However, as the DNS system follows the CO ideology, the ISP's all along the way would have the simple ability to just switch away from the CO stored root zone, and only provide certain names resolvability. this would allow ISP's the ability to offer "services like Google! something not all providers are able to say!" as a promo, attracting people that don't know better.

      in my city, the vast majority of DNS names for city locations/devices are internal names anyways. none of them are accessible via the root zone. to systems like these the aforementioned changes would make no difference in the world.

  2. Re:OS Support by Anonymous Coward · · Score: 4, Informative

    DNSSEC is generally optional. You can now speak DNSSEC to your local DNS server and now it can stay DNSSEC all the way to the root domain (assuming there are no breaks). Prior to this you could authenticate your own DNS server's response, but you were never sure that it was talking to the right person. If you send a standard DNSSEC request out it will respond in a standard, albeit insecure, way. DNSSEC's sole purpose in life is to prevent DNS hijacking.

  3. Re:For the rest of us... by h4rr4r · · Score: 3, Informative

    8.8.8.8 or another dns provider. Clients should not talk to the roots. That or setup your own DNS server.

  4. Re:Too complicated: designed by ISC for ISC? by h4rr4r · · Score: 3, Interesting

    http://blog.techscrawl.com/2009/01/13/enabling-dnssec-on-bind/

    Looks pretty easy at least as easy as setting up bind and a few zones.

  5. Re:What should DNS server administrators do? by darkpixel2k · · Score: 3, Funny

    What should DNS server administrators do to sign our own domains, and configure our servers to pay attention to DNSSEC when performing lookups?

    I learned how to configure BIND a decade ago, and it's mostly just been smooth sailing since then. I have no idea what's involved in setting up DNSSEC, whether it's something I can figure out how to enable in 20 minutes or a huge project that really won't be feasible for me to undertake at all. Can somebody point me in the right direction?

    It's apparently been over a decade since you've tried to look up information on the internet too. We no longer use gopher. There's this new thing called HTTP and WWW. There's also an upstart new search engine company that'll probably die out in a few years--but you can use them here.

    ;)

    --
    There's no place like ::1 (I've completed my transition to IPv6)
  6. Re:For the rest of us... by Hes+Nikke · · Score: 4, Informative

    here is a tool that lets you figure out which are the best DNS servers to use for your internet connection.

    --
    Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
  7. Re:What should DNS server administrators do? by mcrbids · · Score: 5, Funny

    What is this gopher thing you write about?

    Is it newer than telnet?

    --
    I have no problem with your religion until you decide it's reason to deprive others of the truth.
  8. Re:Too complicated: designed by ISC for ISC? by TheRaven64 · · Score: 3, Insightful

    DNSSEC has always seemed to me as being overly complex for what it is actually doing (I'd say the same thing about the DNS protocol in general).

    Given that the DNS protocol is about the simplest protocol currently deployed on the Internet, and yet has managed to scale to the insane degree demanded of it, I can't help think that this implies that you have absolutely no idea what you are talking about.

    --
    I am TheRaven on Soylent News
  9. Re:Say goodbye to... by TheRaven64 · · Score: 3, Informative

    The Internet is not an Ethernet network. The Internet Protocol guarantees that datagrams under 576 bytes (including packet header) are not fragmented, but a 1500 byte Ethernet frame still will be. You don't find Ethernet anywhere other than the edges of the Internet. The backbones still use a variety of other standards.

    Fragmentation is a problem for a UDP-based protocol, which is why pretty much any UDP-based protocol tells you not to use packets bigger than the network MTU (1500 bytes for Ethernet, 576 for the Internet).

    --
    I am TheRaven on Soylent News
  10. Re:One More Error Message For Users To Ignore by Anonymous Coward · · Score: 4, Informative

    Wrong. A bad signature will make the hostname unresolvable.

  11. Re:Say goodbye to... by wayne · · Score: 3, Informative

    The "packets of 576 bytes can't be fragmented" is a commonly stated reason, but it is wrong. It is a myth/misunderstanding. It is, in practice, true has has been true since probably the late 1980s, but DNS was around long before that. Indeed, if you read some of the earlier RFCs, it is quite clear that packets of any size could be fragmented, down to something like 16 bytes of payload per fragment. No,the reason for the 512 byte payload size is much more basic than that. Back in the early 80s, memory was tight, you could have mainframes supporting dozens of users on a machine with maybe 1MB of memory, each of user could have more than one active network connection. IP supports packets sizes up to around 64k, but it would be unreasonable to expect every host to be able to accept such a large packet size. It would mean that they could get fragments from all those packets piecemeal and out of order, so reconstructing each packet would require holding lots of 64k buffers, each of those buffers would be 6% of all available memory. It would be very unreasonable to expect every host on the internet to be able to accept any size packet, even if those packets came in fragment that wouldn't saturate your connection. Now, protocols like TCP have the ability to negotiate the packet size, but for UDP, it gets messy and slow. So, it is a *requirement* that each host on the internet can accept a packet with 512 bytes of payload. That packet can be fragmented, but it has to be accepted.

    --
    SPF support for most open source mail servers can be found at libspf2.