5 ms·

Wow, this is terribly misleading DNSSEC propaganda. It tells me: "Protected from redirection to false IP addresses (DNSSEC)" What does that mean? It means tha

by hannob 10y ago

Wow, this is terribly misleading DNSSEC propaganda. It tells me: "Protected from redirection to false IP addresses (DNSSEC)" What does that mean? It means that whatever other DNS server I use seems to verify DNSSEC signatures (I use Google's DNS fwiw). Yet this doesn't provide any reasonable sense of protection, as the connection to that DNS server may very well be compromised. This would very well show DNSSEC protection in an open public wifi if the provider decided to enable DNSSEC.

mdavids 10y ago
You are right, but the wordings are chosen with the average internet user in mind. Luckily the 'DNSSEC'-word between brackets at the end let's you, the more tech savvy user, know what was really ment.
phicoh 10y ago
Yes. I like what they are trying to do, but they don't seem to actually think things through. It took me forever to get some of the server tests fixed, where it would report that my server didn't properly support IPv6 (in DNS) when in fact it did and just their test was wrong. For me it says now 'your DNS service providers are:' and then the name of the netblock owner. The actual name server is in my network.
- okket 10y ago
  Currently the page is also showing a false negative in this case. My local DNS recursor validates DNSSEC: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 But the test result says: Not protected from redirection to false IP addresses (DNSSEC)
  - mdavids 10y ago
    What does the 'detailed report' say at the DNSSEC-part?
minxomat 10y ago
The question for many residential internet users is: Just because I set my DNS to Google's, do my request really arrive there? Or does my ISP use transparent DNS proxies? I know that for many ISPs around here (Telekom especially), setting your DNS doesn't have any effect unless you run a local resolver (or DNScrypt). More info and how to test if you are affected by this: https://news.ycombinator.com/item?id=13037858 https://news.ycombinator.com/item?id=13037858
- pornel 10y ago
  Just because you've securely looked up an IP address, do your packets really arrive there? That's why DNSSEC without DANE seems pointless (and with DANE/TLS seems redundant).
  - phicoh 10y ago
    It's a different threat model. Classical DNS (i.e. without port randomization and a whole host of other tricks) is very easy to spoof from all over the internet. Inserting yourself between a client and a server is way more difficult. Note that from the point of traffic analysis, you still don't want your TLS traffic to go through a third party. So if your thread model mostly includes nation-state attackers then DNSSEC is only useful for DANE. If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense.
    - lmns 10y ago
      > If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense. The fun part begins when you realize you can't validate DNSSEC because your time drifts too much. So how do you get your initial sync from pool.ntp.org with DNSSEC validation enabled?
      - okket 10y ago
        Also, at the moment you do not get much by checking their broken DNSSEC entries: http://dnsviz.net/d/pool.ntp.org/dnssec/ http://dnsviz.net/d/pool.ntp.org/dnssec/
pjc50 10y ago
I thought DNSSEC was supposed to be verifiable by the client? If it isn't then it's pointless in the way that you suggest, but I find it hard to believe that hole was left.
- Toizi 10y ago
  It can be verified by the client [1] (wikipedia link also has RFC source), but typically the verification is done by the resolver, which introduces the problem that a client has to trust the resolver and the network from resolver to the client (last mile problem) 1: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...
- hannob 10y ago
  Congratulations, you've understood the main hole of dnssec. The thing is: you can verify dnssec on the client. In theory. It's just that 99,9% (rough estimate, may be higher) of people don't. You'd have to run your own resolver. Which might work, if your ISP isn't doing funny things with your DNS traffic. Which some ISPs do. Which means it can't be deployed widely. This thing was built in the 90s when people assumed you have some dns that some admin you trust manages in some trusted network. Moving it to today's internet is pretty much impossible.
  - ribasushi 10y ago
    ( serious question - I might not know something ) If I run my own resolver, with a hardcoded [1] trust anchor, how could an ISP affect me regardless of what funny things it does with my DNS traffic...? [1] https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/bind.keys/#L35-L45 https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/b...
    - lmns 10y ago
      It'll just break and you won't have a working DNS.
    - hannob 10y ago
ak217 10y ago
OK, so for those of us naive about DNS security, can someone summarize the current best practice for DNS on gateway routers and roaming endpoints (laptops)? I know Google has supported an HTTPS bridge for DNS for a while (https://developers.google.com/speed/public-dns/docs/dns-over-https https://developers.google.com/speed/public-dns/docs/dns-over...) but I'm not aware of any router firmware or Mac/Windows/Linux software that supports it, is it out there?
- tptacek 10y ago
  The short answer is: pretty much everyone uses normal DNS, because the many show-stopping problems with DNSSEC includes the insane design decision not to protect the "last mile" between the stub resolver on your own machine and the "DNS server" (technically: recursive cache) that DHCP configures. If you're using Google's DNS, it will (pretty much pointlessly) validate DNSSEC records for you --- but the link between your computer and Google's DNS servers are completely unprotected (any attacker could simply trick your browser into believing there was no such thing as DNSSEC). This doesn't much matter because only a tiny, tiny fraction of all DNS records are DNSSEC-signed. The modal experience for companies that do take the trouble to sign their DNS records is "taken offline completely by DNSSEC configuration mistakes". There is virtually no upside to participating. The good news about all of this is that there's really nothing you need to do to have good DNS OPSEC. Just do what everyone else does, including pretty much all security people: delegate security to a higher layer of the Internet stack.
  - ak217 10y ago
    What about https://dnscrypt.org/ https://dnscrypt.org/?
  - ak217 10y ago
    Thanks for your response!
- phicoh 10y ago
  Google of course wants people to continue to use their DNS resolvers. So it is in their interest to focus only on techniques to improve access to their resolvers. One thing that happened in recent years is that a very nice library called 'getdns' has been developed. Getdns does local DNSSEC validation but also contains various ways of accessing DNS servers and resolvers ("Roadblock Avoidance") I use getdns in ssh for SSHFP, to obtain SSH key fingerprints from DNS. If DNSSEC doesn't work then SSH fails (or complains about an insecure connection). So far my experience is that is works. The problem with DNSSEC local validation is that it doesn't protect your privacy. So there are two techniques under development to address that. One is to run DNS directly over TLS. The second is to run DNS over HTTPS. Running DNS over TLS has to advantage that the semantics are clear (just DNS over TCP but then encrypted) but the downside that the port may be blocked. DNS over HTTPS is unlikely to get blocked, but there are too many ways to transmit DNS over HTTPS, so it may take some time for that to get sorted out. Of course, moving DNS from a lightweight UDP exchange to TLS or HTTPS requires quite a bit more resources on the server side. So, local DNSSEC validation works. It is just matter of turning it on. Server side, if the admins are behind a DNSSEC validating resolver then they quickly figure how to avoid breaking it. When it comes to privacy, if you send all your DNS queries to Google, who else do you care about who might be watching your DNS traffic?
ycmbntrthrwaway 10y ago
In my case it falsely report that everything is ok because I have uMatrix enabled, which prohibits outside requests. When I disable it, it shows "not protected".

by hannob 10y ago

mdavids 10y ago

You are right, but the wordings are chosen with the average internet user in mind. Luckily the 'DNSSEC'-word between brackets at the end let's you, the more tech savvy user, know what was really ment.

phicoh 10y ago

Yes. I like what they are trying to do, but they don't seem to actually think things through. It took me forever to get some of the server tests fixed, where it would report that my server didn't properly support IPv6 (in DNS) when in fact it did and just their test was wrong. For me it says now 'your DNS service providers are:' and then the name of the netblock owner. The actual name server is in my network.

okket 10y ago
Currently the page is also showing a false negative in this case. My local DNS recursor validates DNSSEC: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 But the test result says: Not protected from redirection to false IP addresses (DNSSEC)
- mdavids 10y ago
  What does the 'detailed report' say at the DNSSEC-part?

minxomat 10y ago

The question for many residential internet users is: Just because I set my DNS to Google's, do my request really arrive there? Or does my ISP use transparent DNS proxies? I know that for many ISPs around here (Telekom especially), setting your DNS doesn't have any effect unless you run a local resolver (or DNScrypt). More info and how to test if you are affected by this: https://news.ycombinator.com/item?id=13037858 https://news.ycombinator.com/item?id=13037858

pornel 10y ago
Just because you've securely looked up an IP address, do your packets really arrive there? That's why DNSSEC without DANE seems pointless (and with DANE/TLS seems redundant).
- phicoh 10y ago
  It's a different threat model. Classical DNS (i.e. without port randomization and a whole host of other tricks) is very easy to spoof from all over the internet. Inserting yourself between a client and a server is way more difficult. Note that from the point of traffic analysis, you still don't want your TLS traffic to go through a third party. So if your thread model mostly includes nation-state attackers then DNSSEC is only useful for DANE. If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense.
  - lmns 10y ago
    > If you also want to secure a lookup of, for example, pool.ntp.org then DNSSEC for A and AAAA records also makes sense. The fun part begins when you realize you can't validate DNSSEC because your time drifts too much. So how do you get your initial sync from pool.ntp.org with DNSSEC validation enabled?
    - okket 10y ago
      Also, at the moment you do not get much by checking their broken DNSSEC entries: http://dnsviz.net/d/pool.ntp.org/dnssec/ http://dnsviz.net/d/pool.ntp.org/dnssec/

pjc50 10y ago

I thought DNSSEC was supposed to be verifiable by the client? If it isn't then it's pointless in the way that you suggest, but I find it hard to believe that hole was left.

Toizi 10y ago
It can be verified by the client [1] (wikipedia link also has RFC source), but typically the verification is done by the resolver, which introduces the problem that a client has to trust the resolver and the network from resolver to the client (last mile problem) 1: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#Stub_resolvers https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex...
hannob 10y ago
Congratulations, you've understood the main hole of dnssec. The thing is: you can verify dnssec on the client. In theory. It's just that 99,9% (rough estimate, may be higher) of people don't. You'd have to run your own resolver. Which might work, if your ISP isn't doing funny things with your DNS traffic. Which some ISPs do. Which means it can't be deployed widely. This thing was built in the 90s when people assumed you have some dns that some admin you trust manages in some trusted network. Moving it to today's internet is pretty much impossible.
- ribasushi 10y ago
  ( serious question - I might not know something ) If I run my own resolver, with a hardcoded [1] trust anchor, how could an ISP affect me regardless of what funny things it does with my DNS traffic...? [1] https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/bind.keys/#L35-L45 https://sources.debian.net/src/bind9/1:9.10.3.dfsg.P4-10.1/b...
  - lmns 10y ago
    It'll just break and you won't have a working DNS.
  - hannob 10y ago

ak217 10y ago

OK, so for those of us naive about DNS security, can someone summarize the current best practice for DNS on gateway routers and roaming endpoints (laptops)? I know Google has supported an HTTPS bridge for DNS for a while (https://developers.google.com/speed/public-dns/docs/dns-over-https https://developers.google.com/speed/public-dns/docs/dns-over...) but I'm not aware of any router firmware or Mac/Windows/Linux software that supports it, is it out there?

tptacek 10y ago
The short answer is: pretty much everyone uses normal DNS, because the many show-stopping problems with DNSSEC includes the insane design decision not to protect the "last mile" between the stub resolver on your own machine and the "DNS server" (technically: recursive cache) that DHCP configures. If you're using Google's DNS, it will (pretty much pointlessly) validate DNSSEC records for you --- but the link between your computer and Google's DNS servers are completely unprotected (any attacker could simply trick your browser into believing there was no such thing as DNSSEC). This doesn't much matter because only a tiny, tiny fraction of all DNS records are DNSSEC-signed. The modal experience for companies that do take the trouble to sign their DNS records is "taken offline completely by DNSSEC configuration mistakes". There is virtually no upside to participating. The good news about all of this is that there's really nothing you need to do to have good DNS OPSEC. Just do what everyone else does, including pretty much all security people: delegate security to a higher layer of the Internet stack.
- ak217 10y ago
  What about https://dnscrypt.org/ https://dnscrypt.org/?
- ak217 10y ago
  Thanks for your response!
phicoh 10y ago
Google of course wants people to continue to use their DNS resolvers. So it is in their interest to focus only on techniques to improve access to their resolvers. One thing that happened in recent years is that a very nice library called 'getdns' has been developed. Getdns does local DNSSEC validation but also contains various ways of accessing DNS servers and resolvers ("Roadblock Avoidance") I use getdns in ssh for SSHFP, to obtain SSH key fingerprints from DNS. If DNSSEC doesn't work then SSH fails (or complains about an insecure connection). So far my experience is that is works. The problem with DNSSEC local validation is that it doesn't protect your privacy. So there are two techniques under development to address that. One is to run DNS directly over TLS. The second is to run DNS over HTTPS. Running DNS over TLS has to advantage that the semantics are clear (just DNS over TCP but then encrypted) but the downside that the port may be blocked. DNS over HTTPS is unlikely to get blocked, but there are too many ways to transmit DNS over HTTPS, so it may take some time for that to get sorted out. Of course, moving DNS from a lightweight UDP exchange to TLS or HTTPS requires quite a bit more resources on the server side. So, local DNSSEC validation works. It is just matter of turning it on. Server side, if the admins are behind a DNSSEC validating resolver then they quickly figure how to avoid breaking it. When it comes to privacy, if you send all your DNS queries to Google, who else do you care about who might be watching your DNS traffic?

ycmbntrthrwaway 10y ago

In my case it falsely report that everything is ok because I have uMatrix enabled, which prohibits outside requests. When I disable it, it shows "not protected".