29 ms·

Note: While educational, making a DNS query without DNSSEC verification in 2022 is like making a HTTP query without certificate verification (or without HTTPS

by teddyh 4y ago

Note: While educational, making a DNS query without DNSSEC verification in 2022 is like making a HTTP query without certificate verification (or without HTTPS support).

tptacek 4y ago
This is so wildly untrue I'm wondering if you wrote it just to prod someone to jump in here and start the DNSSEC argument. Less than 4% of North American names are signed. Virtually nobody uses DNSSEC. Further, this code implements a stub resolver querying 8.8.8.8 --- in that scenario, there is no DNSSEC verification, as you know. For stub resolvers, the kind your browser or OS uses, DNSSEC condenses down to a single bit in the header that the server uses to say "trust me, I did DNSSEC".
- teddyh 4y ago
  (I don’t need to prod you to comment on DNSSEC; you seem to be able to find any and all mentions of DNSSEC here quite well on your own.) > Further, this code implements a stub resolver Fair enough, but… > DNSSEC condenses down to a single bit in the header that the server uses to say "trust me, I did DNSSEC". …they did not ask (in the query) for DNSSEC verification, nor did they check the bit in the response.
  - eli 4y ago
    You ignored the part about nobody using it in the first place. There’s nothing to verify.
    - teddyh 4y ago
      He said “Less than 4% of North American names are signed.”. Don’t you wonder why he specified North American names?
      - tptacek 4y ago
        Because it's easy to grab that statistic and a lot more annoying to get the global one, especially because global deployment stats count "zones" and not delegations from TLDs. But there are almost twice as many signed domains in .COM (DNSSEC uptake: 1.6%) than there are in .NL, and the number of signed delegations drops rapidly after .NL (from 3.5MM to 1MM in .CH, to below 1MM in .BR; by the time we hit .UK, the graph is hard to read. My point being: adding up all the signed European names (which are signed automatically at registrars as security theater) isn't going to get you a more attractive uptake percentage. It's possible that the reason I said "less than 4% of North American domains" is that I simply made a mistake, and should instead have said "less than 4% of all domains". Again: .COM has a 1.6% uptake. There are years in the last ~4 where DNSSEC uptake fell in .COM. DNSSEC is moribund.
        teddyh 4y ago
        > DNSSEC is moribund. For how many years have you been saying that? Meanwhile, from what I can tell, DNSSEC usage keeps going up.
        tptacek 4y ago
        Not so much, no. Now, could you acknowledge the comment I just wrote? It's less than 4% of all domains. So: what were you trying to imply when you pointed out that I'd said "North American domains"? And, now that I've corrected the comment, would you still have said it?
        teddyh 4y ago
        I can’t find any good statistics either, so I did not comment on any specifics. I am simply wary of overly specific qualifications with no obvious reason for their specificity; most often, these sorts of arguments are made in order to mislead readers. I don’t know what the actual numbers are. All I can say is that from personal experience when working at a registrar and DNS service provider, the number of people asking about and requesting DNSSEC is increasing all the time, and show no signs of decreasing. Also, all registries (i.e. TLDs) are also all pushing for registrars and DNS service providers to provide DNSSEC, so there is demand from both sides. Note: I do not have any financial incentive to push DNSSEC; in fact, strictly speaking, DNSSEC makes my job harder. Also, as I have mentioned before, I have never seen anyone argue against DNSSEC with any persistence (in industry interest groups, at conferences, etc). Except you, here on HN. And you really seem to have it in for DNSSEC, even going so far as to keep making arguments against the crypto, not only while it was obvious that it could (and would) be fixed, but even making the same argument after it was actually fixed. You keep shifting your arguments, but keep arguing against DNSSEC with whatever you can find. This does not make you look credible. And your sole remaining argument, that DNSSEC has low usage, is not a very good one, if it is in fact the case that the usage is actually (on the whole) increasing.
  - fweimer 4y ago
    It's not unusual to validate unconditionally in recursive resolvers, even for clients that did not set the AD bit or the DO bit.
    - teddyh 4y ago
      Redirecting from HTTP to HTTPS is also quite common, but that does not make it OK to just make HTTP requests all the time.
chillfox 4y ago
I don't know much about DNSSEC, it's something I enable to get a green tick in whatever tool I use on the day to check that I configured DNS correctly. But HTTP without HTTPS is useful if you need to go really fast, same goes for taking DNS out of the loop and going straight to the IP. The way I see it, it's all about your threat model. Who/what are you defending against.
- teddyh 4y ago
  In a stub resolver like this, it’s setting a bit and checking a bit. Not worth arguing about threat models; just do it.

by teddyh 4y ago

Note: While educational, making a DNS query without DNSSEC verification in 2022 is like making a HTTP query without certificate verification (or without HTTPS support).

tptacek 4y ago

This is so wildly untrue I'm wondering if you wrote it just to prod someone to jump in here and start the DNSSEC argument. Less than 4% of North American names are signed. Virtually nobody uses DNSSEC. Further, this code implements a stub resolver querying 8.8.8.8 --- in that scenario, there is no DNSSEC verification, as you know. For stub resolvers, the kind your browser or OS uses, DNSSEC condenses down to a single bit in the header that the server uses to say "trust me, I did DNSSEC".

teddyh 4y ago
(I don’t need to prod you to comment on DNSSEC; you seem to be able to find any and all mentions of DNSSEC here quite well on your own.) > Further, this code implements a stub resolver Fair enough, but… > DNSSEC condenses down to a single bit in the header that the server uses to say "trust me, I did DNSSEC". …they did not ask (in the query) for DNSSEC verification, nor did they check the bit in the response.
- eli 4y ago
  You ignored the part about nobody using it in the first place. There’s nothing to verify.
  - teddyh 4y ago
    He said “Less than 4% of North American names are signed.”. Don’t you wonder why he specified North American names?
    - tptacek 4y ago
      Because it's easy to grab that statistic and a lot more annoying to get the global one, especially because global deployment stats count "zones" and not delegations from TLDs. But there are almost twice as many signed domains in .COM (DNSSEC uptake: 1.6%) than there are in .NL, and the number of signed delegations drops rapidly after .NL (from 3.5MM to 1MM in .CH, to below 1MM in .BR; by the time we hit .UK, the graph is hard to read. My point being: adding up all the signed European names (which are signed automatically at registrars as security theater) isn't going to get you a more attractive uptake percentage. It's possible that the reason I said "less than 4% of North American domains" is that I simply made a mistake, and should instead have said "less than 4% of all domains". Again: .COM has a 1.6% uptake. There are years in the last ~4 where DNSSEC uptake fell in .COM. DNSSEC is moribund.
      - teddyh 4y ago
        > DNSSEC is moribund. For how many years have you been saying that? Meanwhile, from what I can tell, DNSSEC usage keeps going up.
        tptacek 4y ago
        Not so much, no. Now, could you acknowledge the comment I just wrote? It's less than 4% of all domains. So: what were you trying to imply when you pointed out that I'd said "North American domains"? And, now that I've corrected the comment, would you still have said it?
        teddyh 4y ago
        I can’t find any good statistics either, so I did not comment on any specifics. I am simply wary of overly specific qualifications with no obvious reason for their specificity; most often, these sorts of arguments are made in order to mislead readers. I don’t know what the actual numbers are. All I can say is that from personal experience when working at a registrar and DNS service provider, the number of people asking about and requesting DNSSEC is increasing all the time, and show no signs of decreasing. Also, all registries (i.e. TLDs) are also all pushing for registrars and DNS service providers to provide DNSSEC, so there is demand from both sides. Note: I do not have any financial incentive to push DNSSEC; in fact, strictly speaking, DNSSEC makes my job harder. Also, as I have mentioned before, I have never seen anyone argue against DNSSEC with any persistence (in industry interest groups, at conferences, etc). Except you, here on HN. And you really seem to have it in for DNSSEC, even going so far as to keep making arguments against the crypto, not only while it was obvious that it could (and would) be fixed, but even making the same argument after it was actually fixed. You keep shifting your arguments, but keep arguing against DNSSEC with whatever you can find. This does not make you look credible. And your sole remaining argument, that DNSSEC has low usage, is not a very good one, if it is in fact the case that the usage is actually (on the whole) increasing.
- fweimer 4y ago
  It's not unusual to validate unconditionally in recursive resolvers, even for clients that did not set the AD bit or the DO bit.
  - teddyh 4y ago
    Redirecting from HTTP to HTTPS is also quite common, but that does not make it OK to just make HTTP requests all the time.

chillfox 4y ago

I don't know much about DNSSEC, it's something I enable to get a green tick in whatever tool I use on the day to check that I configured DNS correctly. But HTTP without HTTPS is useful if you need to go really fast, same goes for taking DNS out of the loop and going straight to the IP. The way I see it, it's all about your threat model. Who/what are you defending against.

teddyh 4y ago
In a stub resolver like this, it’s setting a bit and checking a bit. Not worth arguing about threat models; just do it.