Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet Technology

Dot-Org TLD Signed For DNSSEC 58

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

Comments Filter:
  • by fotbr ( 855184 ) on Wednesday June 23, 2010 @06:21PM (#32671592) Journal

    More likely simply that different companies/organizations are responsible for .org vs .com vs .net vs .whatever, and each of those had different plans (or no plans) and acted on them at various speeds.

  • by Anonymous Coward on Wednesday June 23, 2010 @06: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:Browsers (Score:4, Informative)

    by 6031769 ( 829845 ) on Wednesday June 23, 2010 @06:38PM (#32671726) Homepage Journal

    Browsers? They shouldn't care about DNSSEC either way, all of that should be handled by the local resolver. To be fair I'm presuming here that you mean web browsers as opposed to say DNS browsers.

  • by Dragoniz3r ( 992309 ) on Wednesday June 23, 2010 @06:50PM (#32671812)
    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.
  • 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. :(

  • by Anonymous Coward on Wednesday June 23, 2010 @07:06PM (#32671942)

    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
                                    dnZ9IMh0bwMcYaVUdzNAbVeJ8gd6jq1sR3VvP/SR36mm
                                    GssbV4Udl5ORDtqiZP2TDNDHxEnKKTX+jWfytZeT7d3A
                                    bSzBKC0v7uZrM6M2eoJnl6id66rEUmQC2p9DrrDg9F6t
                                    XC9CD/zC7/y+BNNpiOdnM5DXk7HhZm7ra9E7ltL13h2m
                                    x7kEgU8e6npJlCoXjraIBgUDthYs48W/sdTDLu7N59rj
                                    CG+bpil+c8oZ9f7NR3qmSTpTP1m86RqUQnVErifrH8Kj
                                    DqL+3wzUdF5ACkYwt1XhPVPU+wSIlzbaAQN49PU=
                                    ) ; key id = 21366

    Please note that due to the use of NSEC3 this key should not be used
    with BIND versions less than 9.6.0.

    Please refer to http://www.pir.org/dnssec/ for more information.

    As always, please report operational concerns with any Afilias-hosted
    zone to

    dave

    - --
    Dave Knight
    Director, Resolution Services
    Afilias

    PIR Technical Support
    URL: http://www.pir.org
    E-mail: techsupport at pir.org
    Phone: +1.416.646.3308
    Fax: +1.416.646.3305
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (Darwin)

    iEYEARECAAYFAkolicgACgkQVFeEx/p946ZMtgCfVzu5IWcE36CYtlb7EBwAgSRx
    AeoAoM6Wfxgi+Q5VR4ws6qDma5uzCLPr
    =CrQm
    -----END PGP SIGNATURE-----

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

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

  • by Timothy Brownawell ( 627747 ) <tbrownaw@prjek.net> on Wednesday June 23, 2010 @07:30PM (#32672116) Homepage Journal

    If you don't care whether the records for your domain(s) are secure, then no.

    If you do want to take advantage of the new functionality, then you need to serve some extra records and give some extra data to your registrar (I think it's just the public half of your key). I imagine the exact steps to do this would vary based on who your registrar is and which DNS server you're running.

  • by iburrell ( 537197 ) on Wednesday June 23, 2010 @07:52PM (#32672280)

    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.

  • by penguin359 ( 763783 ) on Wednesday June 23, 2010 @08:28PM (#32672604) Homepage
    OpenBSD has a flag to report DNSSEC status.
  • by Anonymous Coward on Wednesday June 23, 2010 @08: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.

  • by penguin359 ( 763783 ) on Wednesday June 23, 2010 @09:13PM (#32672874) Homepage
    Size does play some part in it. There are a number of smaller two-letter country code TLDs that were signed before .ORG as well as the fact that .GOV also beat .ORG to being signed with .GOV being signed in March of '09 and .ORG being signed since June of '09. I think the big news is that .ORG is now allowing regular domain owners to submit their keys into the .ORG database. VeriSign who runs both .COM and .NET plans to first sign the smaller .NET which is still larger than .ORG. before finally tackling .COM.
  • by penguin359 ( 763783 ) on Wednesday June 23, 2010 @09:15PM (#32672892) Homepage
    Actually, they've announced the date to now be July 15, 2010. http://www.root-dnssec.org/ [root-dnssec.org]
  • by penguin359 ( 763783 ) on Wednesday June 23, 2010 @09:21PM (#32672944) Homepage
    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.
  • by penguin359 ( 763783 ) on Wednesday June 23, 2010 @09:25PM (#32672966) Homepage
    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 crackers and in the absence of a signed parent, a decent alternative, IMHO.
  • by jroysdon ( 201893 ) on Thursday June 24, 2010 @02:27AM (#32674374)

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

"When the going gets tough, the tough get empirical." -- Jon Carroll

Working...