Slashdot Mirror

← Back to Stories (view on slashdot.org)

ARIN Implements DNSSEC

Posted by Soulskill on from the takes-a-while-to-get-through-customs dept.

wmbetts writes with this quote from an announcement by the American Registry for Internet Numbers: "On 27 April, ARIN placed Delegation Signer (DS) records into in-addr.arpa and ip6.arpa. Now DNSSEC validation will occur from the root down if you properly set up your DNSSEC-aware recursive resolver. For most DNSSEC-aware recursive resolver operators, nothing needs to be done for this change to be in effect as long as you have configured your DNSSEC-aware server to use ICANN's trust anchor for the root zone."

32 of 44 comments (clear)

  1. Re:Excuse me.... by Chaymus · · Score: 2

    This is a rare article that is actually written for the intended audience.

  2. The real question is... by Zed+Pobre · · Score: 1

    ... is it actually a good idea to use ICANN's trust anchor for the root zone, given their history?

    Also, is this likely to make life harder for alternate roots?

    1. Re:The real question is... by Jeremiah+Cornelius · · Score: 1

      No and Yes.

      If, for your second question, you want to send mail to a Yahoo! user, from an alternatively name-rooted host.

      Now, can I interest you in finest quality and 99% pure, Monongahela all-vegetable ingots?

      --
      "Flyin' in just a sweet place,
      Never been known to fail..."
  3. DNS-SEC by Jeremiah+Cornelius · · Score: 1, Interesting

    Introducing the intractable problems of commercial CAs to the remediable problems of DNS.

    Great solution.

    --
    "Flyin' in just a sweet place,
    Never been known to fail..."
  4. ISP Hijacking by theshowmecanuck · · Score: 4, Interesting

    Will this stop ISP hijacking the 404 not found messages and redirecting us to their spam?

    --
    -- I ignore anonymous replies to my comments and postings.
    1. Re:ISP Hijacking by Anonymous Coward · · Score: 1

      No. But it is a step in that direction. When everything is secured with NSEC3, if you drop all unsecure answers, they will not be able to hijack NXDOMAIN.

    2. Re:ISP Hijacking by Necroman · · Score: 4, Informative

      It all depends on how the Hijacking works. All this (DNSSEC) does is validate that the DNS information (IP address) for a given hostname is correct. This will stop rogue DNS servers from reporting an incorrect IP address for a give hostname.

      From my understand of the ISP hijacking of web traffic, they are doing deep inspection of the packet data, looking for requests that are HTTP, and inserting data (be it a redirect or ads). They are performing a man-in-the-middle attack on unencrypted data.

      The only way to stop ISP hijacking is to use https everywhere. Even with that, ISPs could use man-in-the-middle and inject a new SSL cert, but it probably wouldn't be signed by a trusted source (so the user would get an evil warning message from their browser).

      --
      Its not what it is, its something else.
    3. Re:ISP Hijacking by Anonymous Coward · · Score: 1

      No, a 404 is 'DNS is found, HTTP URL is not found'.
      But, if you mean NXDOMAIN 'DNS is not found' responding, yes, if your ISP enables DNSSEC in their recursive resolver.

    4. Re:ISP Hijacking by Anonymous Coward · · Score: 1

      No, that's not how any of that works. First of all, the news is about the reverse lookup domains, which is what you use when you have an IP address and want to know its DNS name. This is somewhat important but doesn't affect typical client usage. Secondly, ISPs usually don't hijack 404s but NXDOMAIN errors: In case of a 404, the domain resolves, the server answers but the URL doesn't exist on the server. What ISPs actually intercept are unresolvable domains, and only if you use their recursive resolver. Particularly evil ISPs force every DNS request through their own resolver "transparently". DNSSEC will put an end to this practice. If ISPs should then actually go for the man in the middle attack that you described, DNSSEC will probably also stop that, because a standard for using DNSSEC to distribute SSL keys is being worked on. DNSSEC does not have the problem that an arbitrary CA can sign for any domain, so there's no way an ISP could get forged DNS records, including SSL keys, past a validating resolver.

    5. Re:ISP Hijacking by Necroman · · Score: 1

      We are both correct. I wish I could update my other post saying that you added the more common case (and easier to do for ISPs).

      In my post, I was talking about the shit Mediacom has been doing.

      --
      Its not what it is, its something else.
    6. Re:ISP Hijacking by kevmeister · · Score: 1

      The literal case of a 404 will not be affected.

      The more common case of re-directing queries to port 53 to their server which responds with the address of their internal advertizing page (such as the one Comcast uses) will be stopped and Comcast has already acknowledged that they will be forced to stop the practice. I do give them credit for agreeing to enable DNSSEC on their servers even though it does break this advertizing mechanism.

      --
      Kevin Oberman, Network Engineer, Retired
    7. Re:ISP Hijacking by tepples · · Score: 1

      If ISPs should then actually go for the man in the middle attack that you described, DNSSEC will probably also stop that, because a standard for using DNSSEC to distribute SSL keys is being worked on.

      TLS (formerly SSL) allows only one certificate per IP address. The solution used to be allocating an IP address for each distinct certificate, but that's a lot harder now that IPv4 addresses are exhausted. SNI, an extension to TLS, allows a separate certificate per hostname, but IE <= 8 doesn't know SNI and can therefore see the certificate of only the primary domain on that IP address.

  5. Re:DNSSEC by kevmeister · · Score: 5, Interesting

    You are confused. DNSSEC (no hyphen) does not use certificates nor CAs.

    DNSSEC uses an anchored chain of trust system applicable to only hierarchical systems. It is similar in may ways to PGP, but, as long as a DNS operator chooses to trust a root key (not cert), the rest of the trust is cryptographically chained to the bottom of the tree.

    The system does place a great deal of responsibility on the root, but, if you read the way the keys are handled, the actual "keys to the kingdom" are spread across a number of people, all well known and not a part of ICANN. A fair percentage are academics. It is a very elegant and very carefully thought out system and is cryptographically provable.

    Also, similar to SSH, only you hold the private keys for your zones. You don't give those to anyone.

    --
    Kevin Oberman, Network Engineer, Retired
  6. Maybe we should get some software support? by Anonymous Coward · · Score: 2, Interesting

    All of these stories on DNSSEC make me wonder about what software supports it. As far as I know, Windows 7 and the various *BSD and Linux operating systems have a resolver that supports DNSSEC. No browser I am aware of can tell you if the security status based on DNSSEC. There is not really a point for DNSSEC if you cannot indicate its status somehow to the user or have the browser reject spoofed pages, or have the browser force secure resolving, etc.

    1. Re:Maybe we should get some software support? by Anonymous Coward · · Score: 2, Informative

      Here's what I do on Windows XP: Use Unbound as a local recursive, caching and validating resolver that returns an error when a signature doesn't validate. The DNS in my network connections points to 127.0.0.1.

    2. Re:Maybe we should get some software support? by John+Hasler · · Score: 3, Informative

      No browser I am aware of can tell you if the security status based on DNSSEC.

      There is a plugin for Firefox.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
  7. Do I need to do anything? by rduke15 · · Score: 1

    I've been hearing about DNSSEC for quite a while now, but still don't understand if I need to find out more and possibly do something about it.

    I take care of about a dozen small zones under various TLDs. The DNS servers for these zones are all running Bind 9 on Debian. None of the domains has a real certificate, but they all use self-signed certs for things like mail with SSL/TLS, VPNs, etc.

    I also manage company DNS servers, which are the resolvers for the machines on the LANs.

    So, is there anything special that people like me need to know or should be doing? Or can we just ignore DNSSEC for now.

    1. Re:Do I need to do anything? by Lennie · · Score: 3, Informative

      There are 2 things you could do.

      1. The easiest thing you can do is to use a DNSSEC capable resolver and give it the 'root key material' and have it setup to update automatically. Every 6 or so months a new key will be generated, so it needs to be updated. Most of the software has a mechanism for that. The root key material is at: https://data.iana.org/root-anchors/ If you use Unbound, you just create a file with the right information and put in the configuration file: auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"

      That way, everything which can be checked will be checked and you will be less vulnerable to DNS attacks.

      2. Deploy DNSSEC for the zones you manage: The most used TLDs are all signed, although they may not all be available to the general public yet. You will obviously need DNSSEC-capable authoritive DNS-server software or use Phreebird as a proxy. When your zone data is signed, obviously clients/resolvers need to be able to check what you signed, you do this by communicating the 'DS'-record (dig +norec @ns1.zone.tld zone.tld DS) to your registrar or TLD-operator, the same people who you are paying for the domain/where you communicate the name and possibly IP-addresses of your DNS-zone. Some registrars might not be ready, but other are. You might need to shop around. Unfortunately you will need to that every X months as well.

      On desktops and so on, there currently are very little tools which make use of it.

      You could put the SSH-fingerprint in DNS which is signed by DNSSEC and enable VerifyHostKeyDNS, that way when you choose yes when connecting to a SSH-server the first time, you can have more confidence that what you are connecting to is the real server.

      There are efforts to make it available for the browsers and so on:

      https://os3sec.org/

      There is a DANE-proposal which makes it possible for the browser to check DNS/DNSSEC and use it for certificate-chain checking for HTTPS instead (or together with) the current CA-system.

      --
      New things are always on the horizon
    2. Re:Do I need to do anything? by Lennie · · Score: 1

      Yes, you can split the KSK/ZSK and all that, it is optional. Probably most will want to do so though.

      SSH needs a local validating resolver, yes. I don't know why I left that out, but it can forward to the network resolver for quick response.

      There are a lot of details I left out. ;-)

      --
      New things are always on the horizon
  8. Re:DNSSEC by Lennie · · Score: 1

    I mostly agree with your, but your last sentence.... well, let's have a look shall we ?:

    "Also, similar to SSH, only you hold the private keys for your zones. You don't give those to anyone."

    Which is similair to SSL/TLS protocols like HTTPS. ;-)

    --
    New things are always on the horizon
  9. North America like Europe ? by Lennie · · Score: 1

    I'm glad that North America (ARIN) is now doing what Europe (RIPE) did earlier this month.

    --
    New things are always on the horizon
    1. Re:North America like Europe ? by John+Hasler · · Score: 1

      So North America is *weeks* behind Europe? WEEKS!!??!?! That is soooo shameful.

      --
      Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
    2. Re:North America like Europe ? by OverlordQ · · Score: 1

      I'm glad that North America (ARIN) is now doing what Europe (RIPE) did earlier this month.

      So which zones does RIPE sign? None? So not the same.

      --
      Your hair look like poop, Bob! - Wanker.
  10. Re:Excuse me.... by darkpixel2k · · Score: 2

    What language was that, and what does that mean to all of us who have no clue what that means?

    ...then why are you reading Slashdot?

    Seriously--I don't barge into a lecture for 7th-year med students and say "WTF?!? What's a ganglia? What kind of language is this?!?!??!!one1."

    (especially in this day and age where Google is about 40msec away)

    --
    There's no place like ::1 (I've completed my transition to IPv6)
  11. Gonna kick it root down by Kargan · · Score: 1

    So how you wanna kick it?
    Gonna kick it root down!
    So how we gonna kick it?
    Gonna kick it root down!
    So how we gonna kick it?
    Gonna kick it root down!
    Break it on down, gonna kick it root down

    It's not a putdown, I put my foot down
    And then I'm makin' some love, I put my root down
    Like 'Sweetie Pie' by the Stone Alliance
    Everybody knows I'm known for droppin' science

    Beasties -- ahead of their time AND helping save Admins everywhere the trouble of statically configuring ARIN’s trust anchors.

    --
    Palaces, barricades, threats, meet promises
  12. DJB points out DNSSEC is insecurely administered by Burz · · Score: 1

    http://www.vimeo.com/18417770

    He also suggests DNSCurve as an alternative. Would be interesting to try setting up both on the same name server.

  13. Do you use them for your DNS root? by pavon · · Score: 2

    then you should use them for your DNSSEC root.

    Unless you are using an alternate DNS root then you are already trusting ICANN, and DNSSEC will help prevent you from man-in-the-middle attacks, decreasing the number of untrustworthy people who can mess with your DNS queries.

  14. Judgement Day by geekmux · · Score: 1

    I know this is pretty much unrelated, but I really wish they would figure out a way to write about DNSSEC that doesn't make it sound like we just got done turning on Skynet...

  15. Re:DJB points out DNSSEC is insecurely administere by DontLickJesus · · Score: 1

    Just wanted to say thanks for linking this. Great talk.

    --
    Where genius and insanity become confused true wisdom is found
  16. DNSSEC enables self-signed TLS by tepples · · Score: 1

    Which is similair to SSL/TLS protocols like HTTPS.

    The difference here is that with TLS, your CA-signed certificate is sold separately. DNSSEC in theory would let a domain owner store the fingerprint of a self-signed TLS cert in the domain's zone file because the domain registrar acts as the CA. The only problem left is lack of support for SNI (name-based virtual hosting extension for TLS) in IE <= 8 and Android <= 2.3.

    1. Re:DNSSEC enables self-signed TLS by Lennie · · Score: 1

      SNI is available for IE7 and IE8 on Vista and IE8 on Windows 7, it is actually the library which is part of Windows XP where the problems is with SNI, which also effects Safari on Windows XP.

      --
      New things are always on the horizon
    2. Re:DNSSEC enables self-signed TLS by tepples · · Score: 1

      SNI is available for IE7 and IE8 on Vista and IE8 on Windows 7

      IE 9 is also available for these platforms. The rule of thumb that I have been following is that in practice, IE <= 8 means IE on XP. Or how is this invalid?