Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Security The Internet Technology

Dot-Org TLD Signed For DNSSEC 58

Posted by timothy from the not-passing-on-costs-is-a-neat-trick dept.
graychase writes "A major milestone is reached as the first major top-level domain (.org) is now secured with DNSSEC. The expense to .org for implementing DNSSEC on its infrastructure and operations has not been a small one. While specific figures as to the cost of DNSSEC implementation haven't been released, Afilias, which is the technical operator of the .org registry, told InternetNews.com in 2009 that the DNSSEC implementation would be a multi-million-dollar effort. The cost isn't going to be passed on by .org to domain registrars. The move toward securing the .org registry with DNS security started in September 2008, following the Kaminsky DNS flaw disclosure."
This discussion has been archived. No new comments can be posted.

Dot-Org TLD Signed For DNSSEC More

Dot-Org TLD Signed For DNSSEC

Comments Filter:

  • Seems odd, too many .com's perhaps?

  • There will be a lot more TCP (and IPv6) queries (Score:4, Informative)

    by Anonymous Coward on Wednesday June 23, 2010 @05:31PM (#32671658)

    Because of the size of the new DNS Resource Records, notably the RRSIG and DNSKEY RRs, and partly because of the (perhaps temporarily) short TTL of one day, there will be a lot more TCP queries because of the size limit on UDP ones. The .ORG nameservers are also IPv6ified, and there is even less space in UDPv6 queries, so hosts that do not exclusively or preferentially make DNS queries in IPv4 will now make TCPv6 queries. These are likely to be slower than UDPv4 queries before the signing and v6ification, and the UDPv6 queries before the signing.

    Scaling is helped by using anycast IP and IPv6 addresses, but the downside is that a routing flap that occurs any time after the first TCP/TCPv6 SYN from a client will cause a client to have to requery because of an RST fired back by the newly-closest anycast nameserver, or wait on a full TCP timeout (and then probably still see the RST) depending on the timing. (The worst case is probably having the final FIN segment being eaten by Shub-Internet or someone trying to do a devious (and probably pretty local in scope) denial-of-service consuming resources on possibly the client and two servers).

    In short, this is not a win for performance, and it will be a good idea to use long TTLs in the zone itself (and on 2nd level nameservers) once it appears safe to do so.

    • Re: (Score:3, Informative)

      by Dragoniz3r ( 992309 )
      It was never meant to be a win for performance o.O Of course it's going to be slower. The cryptographic checks alone will make it slower. It's intended to prevent DNS hijacking attacks.

      • Re: (Score:2)

        by abigor ( 540274 )

        I'm sure the gp knows that. Reread his post.

      • Re: (Score:1, Funny)

        by Anonymous Coward

        No shit sherlock. The AC was addressing the performance issue, not the intent. Crack open your MCSE manual again and do some more reading.

    • Re: (Score:3, Informative)

      by iburrell ( 537197 )

      DNSSEC requires EDNS. EDNS allows for UDP packets larger than the original 512-byte limit of DNS over UDP. There could be problems with fragmented packets which are larger than the MTU. Some experiments show that responses with DNSSEC and IPv6 are larger than 512-bytes but smaller than typical MTU of 1500 bytes.

      There are some old firewall equipment that mistakenly prohibits DNS packets longer 512 bytes over UDP but those have caused problems for a while.

    • Re: (Score:2, Interesting)

      by penguin359 ( 763783 )
      The DNS extension called EDNS0 allows larger UDP DNS queries so that TCP can be avoided. The size for UDP queries is now at 4096 bytes from the 512 byte limit without EDNS0. A lot of the preparation going into DNSSEC has been testing for resolvers with broken EDNS0 support. I find that the vast majority of my DNS queries with DNSSEC enabled are still successfully sent as UDP with EDNS0 currently.

  • As an end-user, is there some way to tell? (Score:4, Interesting)

    by JSBiff ( 87824 ) on Wednesday June 23, 2010 @05:41PM (#32671752) Journal

    As an end-user, is there some way for me to tell if a domain has been authenticated along the whole chain by DNSSEC? Do any of the web-browsers, for example, include DNSSEC support, to show that a domain has been verified? Or, is DNSSEC only a server-to-server tech, but doesn't extend to end users? If it does extend to the end-user computer, can I use DNSSEC on an un-trusted network, to connect securely to my ISP's DNS Server (or google dns, or OpenDNS, etc), to make sure I'm getting back the correct DNS info (I suppose the 'real' answer for such a situation, at least currently, is a VPN, although some organizations [like where I work] have VPN's that only tunnel traffic to the secured network, and won't tunnel any other traffic, so such a VPN doesn't protect you when visiting any other sites/hosts on the internet).

    I think it would be nice, if I don't have access to a real VPN connection, to at least be able to make sure that DNS is secured and trustworthy (although that, of course, doesn't guarantee that there aren't any man-in-the-middle attacks).

    • As an end-user, is there some way for me to tell if a domain has been authenticated along the whole chain by DNSSEC?

      Yes, that's actually the entire point. Your computer ("stub resolver", the library all your programs use to do DNS queries) can either (1) not care, in which case you're really no safer than with regular DNS; (2) ask your ISPs resolver whether the records were signed, in which case you're slightly safer but not very much; or (3) demand that your ISPs resolver send it all the signatures along with the actual result, in which case you're about as safe as can be (someone would have to break/steal the keys used to sign the records, in order to cause trouble).

      What you as the person using the computer see, is of course dependent on the particular programs you use and what they do with the extra information that's available. Probably most don't do anything with it yet. :(

      • Unfortunately, there don't yet seem to be standard APIs for the stub resolver to report DNSSEC info. POSIX03 introduced getaddrinfo(), which has some space for extra flags, so you could add a flag indicating that an address was resolved via DNSSEC without breaking binary compatibility, but I don't know that anyone has yet.

      • (3) is still not fully correct. You would only be as safe, as you
        1. know that the signer is who you think he is, and
        2. actually trust the signer.

        Since you don’t have the public keys for all the domains on the planet on your hard drive to check the actual correctness, point 1 already falls flat.
        And even then, I haven’t met them, I did no learn to know them, so I don’t trust them any more than any other crook who could highjack it, anyway. ^^

        • Re: (Score:2, Informative)

          by penguin359 ( 763783 )
          To help with this situation, there are a number of Trust Anchor Repositories (TAR) that do a certain amount of testing on the trust anchors to verify they are correct. I use ISC's DLV repository on my home servers, but there is also SecSpider that has a large database of keys as well. They run multiple resolvers around the planet that regularly pull for DNS keys and verify that they are consistent across all servers. It's less secure than trust provided by the parent, but still extremely difficult for cr

        • Re: (Score:2)

          by Tacvek ( 948259 )

          The signer is who you think he is. The signed root zone lets you know that the root zone has not been tampered with. If you don't trust the IANA, you might as well stop using the internet entirely, since the IANA decides what the root servers serve up. The root zone contains the public keys for the "org." domain. Only Afilias, who maintains the "org." domain can request the key for .org in the root zone to be changed. Thus if the root zone signature is good, we know that the key in it for "org." belongs to

      • Re: (Score:2, Informative)

        by penguin359 ( 763783 )
        Actually, any validating resolver should drop DNS data that failed to validate. Most DNS data is currently unsigned which means that is can't be validated. That does not mean it failed to validate, just that it the data is not secure. A stub resolver can notify it's calling process whether the data is secure or not, but data that should be secure and failed to validate will never be passed to the process.

      • Re: (Score:2)

        by Znork ( 31774 )

        someone would have to break/steal the keys used to sign the records, in order to cause trouble

        Or lean on the registrar. It's going to be a bit interesting to see how this will affect the DNS based government filters that are implemented on ISP level in a lot of countries.

      • Firefox should already be compliant (from what I've heard). It will pop up a warning if the known cert is different from a new one (if someone hijacked the domain). The key of course is: how do you guarantee that the original key is correct? by sending it through other means (USB key, mail etc.) and have the user install the cert manually.

    • Re: (Score:2, Interesting)

      by cybaz ( 538103 )
      There is a Firefox plugin that will give a key icon if the domain is signed with DNSSEC https://addons.mozilla.org/en-US/firefox/addon/64247/ [mozilla.org]
    • It is possibly to run a validating resolver on your own laptop which validates DNS data regardless of where you are connected to the Internet. You can be using any free Wi-Fi hotspot of your choosing and still be assured that the secured DNS data is accurate. Granted, this is only for zones to which you have valid trust. An unsigned zone, as most are currently, can still be spoofed.

    • Re: (Score:3, Informative)

      by jroysdon ( 201893 )

      FYI, OpenDNS does not and will not support DNSSEC. DNSSEC breaks their model of typo-squatting, and filtering in general.

    • There is a Firefox add-on, DNSSEC Validator [mozilla.org], which appears to work for the pir.org [pir.org] zone, as well as my own roysdon.net [roysdon.net] zone. Both are DNSSEC signed, although my roysdon.net is found in the DLV.

      You can point the tool to use Comcast's DNSSEC trial resolver which is DLV-enabled at 68.87.68.170.
      You can trial Comcast's DNSSEC trial resolved which does not have DLV support at 68.87.64.154 and rely only on the Root signature and previously published ccTLDs like .SE.

      pir.org is an example of a zone which you can ve

  • Old News, .ORG signed over a year ago (Score:1, Informative)

    by Anonymous Coward

    https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/003940.html

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Colleagues,

    On behalf of PIR Technical Support I would like to announce that as of
    today, 2009-06-02, at 16:00 UTC .ORG is DNSSEC signed.

    The following KSK is now valid for .ORG

    org. IN DNSKEY 257 3 7 (
    AwEAAYpYfj3aaRzzkxWQqMdl7YExY81NdYSv+qayuZDo

  • Do I need to do anything? (Score:4, Informative)

    by i_ate_god ( 899684 ) on Wednesday June 23, 2010 @06:18PM (#32672024)

    I have a .org domain hosted on my server. Is there something I need to do?

  • Slashdot (Score:2, Interesting)

    by Anonymous Coward

    When will slashdot.org be signed?

    • No, nor while it have ipv6 records. Why would they really care about tech? The real motive is profit. No profit in slowing down dns queries with DNSSEC or potential problems right now with broken ipv6 transit or clients.

    • Dude, they don't even have basic IPv6 deployed... Slashdot, for all it's "News for Nerds" BS is amazingly conservative when it comes to technology.

  • .org was signed over a year ago (Score:3, Informative)

    by Anonymous Coward on Wednesday June 23, 2010 @07:46PM (#32672718)

    Here's the announcement on the OARC DNS-Operations list
    https://lists.dns-oarc.net/pipermail/dns-operations/2009-June/003940.html

    What has happened this week is that .org domain holders who have signed their domain may now submit their DS record via their registrar for inclusion in the .org zone, assuming that their particular registrar supports that.

    Up until now only a handful of signed .org domains have had their DS records included in the zone and this was done manually at the registry in order to facilitate testing before opening this up to registrars.

  • Seriously ... how does it end up costing multiple millions of dollars to accomplish such a trivial change?

    You mean they spent 50k on the developers to update their systems and the rest on 'testing' right?

    Seriously, theres nothing to this upgrade other than changes to the management systems from there end.

    W T F?

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Close