8 ms·

"... because DNS, invented in 1983 before the public consumption of the Internet, does not perform any authentication." Authentication of what? An end point?

by gwu78 11y ago

"... because DNS, invented in 1983 before the public consumption of the Internet, does not perform any authentication." Authentication of what? An end point? No. A domainname? OK, I'll play along. And why would "authentication" of a dommainname be necessary? Maybe because the end user is communicating with a shared DNS cache operated by a third party instead of using their own? But I do not use shared DNS caches. I use my own cache. Moreover I use CurveDNS which provides encryption of DNS packets in transit and is at least as good at "authenticating" the proper authoritative server for each domainname as DNSSEC. How would DNSSEC serve me? DNSSEC could be a way for certain groups to maintain control over the use of DNS. Similar to the way SSL CA system has been used to control the use of encryption. Both the use of domainnames and SSL certificates are each commercial in nature (pay to play). They do not have to be, but schemes like CA system and DNSSEC allow for this to occur via centralisation of authority.

talideon 11y ago
Authentication of whether the records have been tampered with or not. That includes the very authoritative nameserver you fetched them from in the first place, which might have been compromised. This is why DNSSEC allows zones to be signed offline by the zone's owner rather than trusting the nameserver. Even if you run your own DNS cache, some bad actor between you and zone owner (including the aforementioned authoritative DNS server) can still potentially provide you with bad data. DNSCurve gives you _encrypted traffic_, but DNSSEC gives you _accurate results_. They solve two different problems.
- gwu78 11y ago
  "They solve two different problems." Well-known fact. And truthfully the most sensible approach would be to use both. Yet I never see anyone doing that. Given the choice between the two problems, I know which one I consider more serious. The results might be "accurate" when stored on the nameserver but if they get tampered with in transit went sent over the wire then they are not "accurate" when they are received. In that case DNSSEC does not give me accurate results. Moreover I am not keen on the widepread sniffing of DNS traffic. Name lookups and other DNS requests and responses are just as important as HTTP traffic. Why encrypt one and not the other? Finally, I could be wrong but I think getting redirected to a bogus nameserver run by a "bad actor" seems (easier for the bad actor and) more likely than accessing the correct nameserver without the knowledge it has secretly been compromised.
  - netheril96 11y ago
    Most of the time the domain name will be sent in the clear anyway. For example, when you connect to a plain HTTP site, the domain name will probably be included in the "Host" field. When connecting to a HTTPS site, it will probably be included in the Server Name Indication extension field during TLS handshake. Of course there are many times the domain name will remain hidden, if the DNS record is encrypted, but that is not a fraction of total use cases, and I doubt there will be great force pushing for DNS encryption.
    - gwu78 11y ago
      I try to avoid SNI and thankfully find a very small percentage of SSL-enabled sites using it, overall. I sniff my own SSL traffic and can see all the domain names for which SNI is being used. Are you saying SSL leaks the domainname in every request? What is the justifcation for SNI? Does it have to do with conserving IP address space? Not sure I understand your comment about HTTP Host: field and plain text HTTP traffic. My question was that if HTTP traffic is encrypted (e.g., via SSL) then why not encrypt DNS, too?
      - talideon 11y ago
        SNI is useful because it's less of a headache than setting up multiple network interfaces. Conserving IP address space is simply something really nice you get for free.
  - talideon 11y ago
    > The results might be "accurate" when stored on the nameserver but if they get tampered with in transit went sent over the wire then they are not "accurate" when they are received. In that case DNSSEC does not give me accurate results. Here's where you're wrong. A zone isn't just signed in isolation. If it was, then DNSSEC would indeed be completely useless. Rather, there's a chain of trust from the root nameservers up to the nameservers for the domain in question, and in each case you can request a DS (delegation signer) record to show that a zone served by a subordinate nameserver hasn't been tampered with. Now, this has its own issues if you're not a fan of the hierarchical nature of DNS, but it guarantees that even though the data is sent in the clear, some bad actor can't modify it in transit without breaking everything. DNSCurve is a nice bonus, but the guarantee that the records being served cannot have been tampered with given by DNSSEC is much more fundamentally important.
Dylan16807 11y ago
The CA system is in a bad place, and adding more centralization would actually help. If there are entities that can arbitrarily tell me if a .com certificate is valid, I want there to be as few as possible.
- talideon 11y ago
  Funnily enough, DNSSEC would help with that, if DANE was more widely supported.

gwu78 11y ago
"Here's where you're wrong." Are you sure? If the plain text packet used in DNSSEC is tampered with then how does DNSSEC ensure I get an "accurate result"? Are you saying failure is an "accurate result"? How is this superior to encrypting the packet to protect against tampering? "A zone isn't just signed in isolation." This is why I do not care for DNSSEC. Where is control being placed? This smells much like SSL and the CA system. I obtain zone files from official zone file access programs and run them in my own authoritative nameservers, locally. I can also get zone information from the scans offered at scans.io "... if you're not a fan of the hierarchical nature of DNS..." After many years of workarounds, I can deal with that. It's the hierarchical nature of "trust" in DNSSEC (as in SSL) that is a problem. I guess we just differ in what we see as more important. I find it rather absurd that you are actually advising someone running their own cache to use DNSSEC. The entire raison d'etre for trying to bring DNSSEC back to life again circa 2008 was cache poisoning. There are commercial interests pushing DNSSEC. Its advocates will make any argument necessary to try to justify adoption. Alas, end users are not the intended beneficiaries.
- talideon 11y ago
  > Are you sure? Yes, very sure. Because I actually had to sit down and read the relevant RFCs way back because it's part of my job as somebody who works for a domain registrar. Here's a quick overview for anybody who hasn't had the time to You can't tamper with a record that's been signed. It won't validate against the matching RRSIG record, and the only way you can generate those is if you have the private key. And how do you validate those? Well, that's what the DNSKEY record is for: it contains the public key, and is used to validate the signatures in the RRSIG records. Now, assuming you trust that modern crypto works, all that assures that records published in the zone cannot possibly be tampered with, but it doesn't prevent two things: the insertion of additional records and that the DNSKEY record is legit. For the former problem, NSEC/NSEC3 records exist. [I'm not going to go into how NSEC/NSEC3 records work, because they're without a doubt the single most complicated part of DNSSEC. The rest of DNSSEC is trivial compared them, especially the mechanisms in NSEC3 records that mitigate against zone enumeration.] So far so good, but while all that allows you to verify the integrity of the records you've queried, an intermediary could strip all those additional records that allow you to check their integrity or spoof them. You need to ask somebody, and given the inherently hierarchical nature of DNS, that somebody is the parent zone, which is where DS records come in: they prove that (a) the zone is meant to be signed and (b) that the DNSKEY record in the zone is legit. The same process is used right up to the root servers, whose contents is verified using the trust anchors supplied with your OS. > If the plain text packet used in DNSSEC is tampered with then how does DNSSEC ensure I get an "accurate result"? Are you saying failure is an "accurate result"? Failure tells you that the results you've got back have been tampered with. And that's a good thing. If somebody's feeding you poison, you need to know that. I'll take a denial of service over somebody draining my bank account, and even then it needn't result in a DOS if you choose to ignore the fact that you've gotten bogus data. > Where is control being placed? This smells much like SSL and the CA system. Your problem isn't with DNSSEC, but with DNS. > I obtain zone files from official zone file access programs and run them in my own authoritative nameservers, locally. Which registries do you have agreements for zone file access with? And even if you have access to that information, you still have to get the zonefiles for the individual domains published in the registry's zone. How do you fetch those? I'm pretty sure that you don't have access to, say, the zones published on ns-22.awsdns-28.com, unless you happen to work for Amazon. So you're trusting somebody to fetch that likely incomplete that data for you from the real authoritative nameservers. What you're running isn't an authoritative nameserver, not in the normal sense. You might be using it in authoritative mode to serve some scraped data locally, but effectively you have have is a little more than sophisticated /etc/hosts file and a bunch of blind faith that the sources you got the data from originally didn't tamper with it. > I can also get zone information from the scans offered at scans.io In other words, a third party who happens to have gathered the data, but who may just have tampered with it, and you have no way of knowing. All you have is blind trust that they're giving you good data. They could be feeding you complete junk for all you know. But DNSCurve makes sure that junk is transmitted super securely. > After many years of workarounds, I can deal with that. It's the hierarchical nature of "trust" in DNSSEC (as in SSL) that is a problem. It's DNS whose nature is hierarchical. The hierarchical nature of DNSSEC is a consequence of DNS being hierarchical. > I guess we just differ in what we see as more important. Yes, we do. I want to make sure the DNS records being served to me aren't junk. You want to fetch them using a gold-plated pipe, even if they happen to be total junk. As I wrote before, DNSSEC and DNSCurve solve two totally different problems. In an ideal world, we'd be using both. > I find it rather absurd that you are actually advising someone running their own cache to use DNSSEC. When did I write that? The only thing I've talked about is the importance of being able to verify the integrity of the data you've fetched. > There are commercial interests pushing DNSSEC. Its advocates will make any argument necessary to try to justify adoption. For what benefit? What do they get out of it? DNS hosting providers don't get much out of it except having to serve more data. Registrar's don't get much out of it except of yet another EPP extension to implement that no registry implements the same way and yet another obligation if they're on the 2013 RAA. Registries don't get anything out of it except having to serve more data. Registries don't charge for DNSSEC, and it's no more in a registrar's interest to charge to send DNSSEC requests up to the registry than it is to charge for nameserver or contact updates. DNS hosting providers could charge, and some do, but given the choice between using using the likes of OpenDNSSEC and stabbing yourself in the eye with a pencil, the latter will typically win out. And if you're a masochist like me, you can use a hidden primary and treat all the visible authoritative nameservers as secondary nameservers, so if your DNS hosting provider allows zone transfers, you don't have to pay anything extra because the DNS hosting provider doesn't have deal with securing the private key and all the implied expense of doing so. So, who is actually benefiting here? The manufacturers of hardware security modules? As far as I can see, they're the only ones who potentially win big from a financial point of view from DNSSEC.
  - gwu78 11y ago
    You should read my initial comment. I wrote that I use my own cache bound to the loopback, and not shared with anyone. I asked what benefit I would get from DNSSEC. Also, registrars, in general, are not known for their trustworthiness. This is a system for disseminating public data (i.e., it should be very boring), yet it has been turned into a "business". This is a recipe for deceit and that's why it is such a headache for ICANN or anyone else trying to police registrars. Now, please do not misunderstand, I am not suggesting your employer is not trustworthy. The sad truth, as revealed in com.zone and other large zone files, is that most of the domains registrars sell (rent) are garbage and only used for "domain parking" and serving ads. Indeed, the people selling DNS hardware, not to mention consulting, are benefitting financially from pushing DNSSEC. To me, that "gold-plated pipe" that I have full control over is far more important than any third party purporting to "sell" me an entry in a public zone file or to "authenticate" some public data on my behalf. I can create, retrieve and manage my own data. What I cannot control is the hostile network over which it is transferred. I like software that is aimed at that problem.
    - talideon 11y ago
      No, no, I read it. The question is, where did you get that data in the first place, and how can you trust that it hasn't been tampered with between the authoritative nameservers and your local cache? That's where the benefit of DNSSEC is: it allows you to detect tampering, and you don't have to trust any intermediaries to do so. With DNSSEC, you don't have to trust the registrar, you don't have to trust the registry, you don't have to trust the recursive caches. In fact, you barely have to trust the root nameservers. The only individual you have to trust is the domain's owner. If any party along the way tries to play silly buggers, then you get a red flag. > This is a system for disseminating public data (i.e., it should be very boring), yet it has been turned into a "business". It's been turned into a business because somebody needs to run those nameservers and, like it or not, that costs money. > The sad truth, as revealed in com.zone and other large zone files, is that most of the domains registrars sell (rent) are garbage and only used for "domain parking" and serving ads. If a registrar has parked a domain, it's because the owner has done nothing with them, or the owner themselves has parked them for revenue. > Indeed, the people selling DNS hardware, not to mention consulting, are benefitting financially from pushing DNSSEC. Not that much: one of the strengths of DNSSEC is offline signing. The only benefit is that DNSSEC requires more traffic, but not dramatically much once a zone is cached. > To me, that "gold-plated pipe" that I have full control over is far more important than any third party purporting to "sell" me an entry in a public zone file or to "authenticate" some public data on my behalf. A gold-plated pipe full of slurry isn't much good. Again, all the encryption in the world isn't much good if you can't trust the data itself.