4 ms·

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

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

by gwu78 11y ago

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.

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.