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

44 comments

  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 Anonymous Coward · · Score: 0

      This will stop rogue DNS servers from reporting an incorrect IP address for a give hostname.

      This will not stop rogue DNS servers or MitM attacks from a client to server standpoint. You must be able to trust your local DNS server and the communication path to it. This stops your local DNS server from having MitM attacks performed against it when it asks other DNS servers (and when the zones it asks about are DNSSEC-signed zones).

      However, if it were built into your local client resolver, then you could validate, but it is not. This is why, as someone else pointed out, we need more client-side tools with DNSSEC validation built-in. The only exception is when on a trusted network where you can trust the DNS server you are using (and then that DNS server will do all the DNSSEC validation for you).

      Again, this does not protect server-to-client DNS traffic as client stub resolvers do not do any DNSSEC validation (presently).

    6. 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.
    7. 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
    8. 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 Anonymous Coward · · Score: 0

      I concur that browsers need this built in, and it should be an option you can enable to restrict communications with non-DNSSEC sites, or at least with sites whose DNSSEC validation has a problem (bad keys, or man-in-the-middle attack).

      Firefox has an Add-on called DNSSEC Validator, which will tell you after a page loads if it is DNSSEC secured, not secured, or has invalid/bad DNSSEC information (possibly tampered with).

      The problem with the add-on is that you could be redirected via a MitM attack to a bogus page (other than what you typed in or the link you clicked) and you'd never know it (since DNSSEC Validator takes a few seconds to verify and you'll never see it indicate anything for a page that you are quickly redirected from). The bogus page could easily be secured with DNSSEC, but if you don't mind the URL you'll not know. It also doesn't help if the page isn't SSL-encrypted as any of the contents could be manipulated.

      However, it does prevent against bogus DNS + fraudulent SSL at the same time. Right now if you don't have both DNSSEC and SSL, you could be sent to a bogus IP address with SSL using one of those recently issued SSL certs (which were revoked, and browsers have had updates put in to never trust them and not need to check CLRs). So going forward you'd be saved from those during a "zero day" breach of a CA. Mind you, it would only save you for sites with DNSSEC enabled and which you know to check the DNSSEC Validator status.

      It's a step in the right direction, and the next step is to have it built into the tools. Mostly we need it built into the client tools because we cannot trust our ISPs and coffee shop resolvers. In an enterprise setting where you can trust your DNS resolver, you don't need this built into your client tools for DNSSEC-enabled sites.

    3. 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 Anonymous Coward · · Score: 0

      Good overview of the effort required for both the consumer and publisher. Thanks :)

      Some slight errors tho:
      - you don't need to republish your DS keys every few months if you use key signing keys (KSK) that sign zone signing keys (ZSK). That way you can reuse your KSK for between 2 to 4 years, and roll your ZSKs every few (3?) months.

      - applications need to be updated to actually look at the signatures OR you need to run a validating resolver locally. SSH still relies on the AD (authenticated data) flag, which you of course can't trust from the network.

      - the os3sec.org plugin does all that, but isn't quite production grade stuff yet :-). It also lags behind the DANE proposals quite a bit.

    3. 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.
    3. Re:North America like Europe ? by Anonymous Coward · · Score: 0

      RIPE has been signing its reverse zones (which is what this is about for ARIN) for quite some time.

      Here's a thought, when you know nothing whatsoever about a topic, instead of posting to show off how little you know, why not read?

    4. Re:North America like Europe ? by Anonymous Coward · · Score: 0

      Well, it's actually pretty impressive. NA is still not on metric and just wait and see how long it'll take until they standardize on micro usb for cellphones. I'm sure that'll only happen by extension, because products that are also produced for the EU market will end up on NA store shelves.

  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 Anonymous Coward · · Score: 0

    Beware that there are fourteen minutes of administrivia before DJB's talk begins.

  16. 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
  17. cheap handbags by Anonymous Coward · · Score: 0

    A great post but How to select a cool handbags. we sell cheap handbags We are the best store provided various cheap designer handbags but only a little white to make coach handbags online

  18. 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?

  19. Bypass DNS servers then 4 your fav. sites... apk by Anonymous Coward · · Score: 0

    The way I make sure I am getting the CORRECT sites for the URL's (domains/hosts) I go to is VERY simple - I use a custom HOSTS file with my favorite 200++ or so sites resolved in it already (which gives me information necessary to get to them, verified by whois &/or ping here usually). This is actually FASTER than DNS, bypassing it, totally for said fav. sites of mine:

    "This will stop rogue DNS servers from reporting an incorrect IP address for a give hostname." - by Necroman (61604) on Friday April 29, @06:04PM (#35980096)

    Well, that's good (IF it works), but I know, FOR SURE, that my methods do & for my favorite sites online I probably spend a GOOD 90% of my internet surfing time on.

    APK

    P.S.=> And, IF I use external DNS servers (and, yes, I do because I cannot "hardcode the entire internet" in my HOSTS file)? I rotate between:

    1.) OpenDNS
    2.) ScrubIT DNS
    3.) GoogleDNS

    ... apk

  20. Re:DJB points out DNSSEC is insecurely administere by Anonymous Coward · · Score: 0

    One of the few times that DJB doesn't come off as batshit crazy. DNSCurve needs more of a push, but DJB's reputation has cemented it into an early grave.

  21. Re:DJB points out DNSSEC is insecurely administere by Anonymous Coward · · Score: 0

    Is DNSCurve really an alternative to DNSSEC? One seems to secure communications between parties, the other just authenticates the information it has. It seems to me that both can be a layer in a security situation. But then again, he spends most of his time bitching about DNSSEC, rather than going through the same points saying how DNSCurve and CurveCP is any better. This is especially so for any job where they overlap. But maybe he is just terrible at saying what DNSCurve does, opposed to CurveCP.