3 ms·

I'll bet a comparable number of clients won't be able to reach DoH servers for one reason or another. Especially because there seem to be people who are going t

I'll bet a comparable number of clients won't be able to reach DoH servers for one reason or another. Especially because there seem to be people who are going to actively try to block them. Whenever you change anything, something will break. And it would have been relatively easy to put up a notice that said "your DNS server seems to be dropping all EDNS0 data or whatever stupid thing it's doing; would you like to switch servers"? Which would have avoided centralizing everybody by default. I know there were enterprise firewalls that broke DNSSEC on any packet that went through them... but frankly the sellers of those firewalls deserved to get heat, and any enterprise that would deploy that kind of broken crap isn't an organization I'd want to support as user. And that still doesn't justify putting DNS on top of HTTP of all things. But that's another story. As for Cloudflare doing DNSSEC checks, the fact that I shouldn't be trusting Cloudflare to do the validation for me is kind of the point. Validation (final validation, at least) belongs in the endpoint. If "oblivious DoH" is what it sounds like, it sounds like maybe I have to retract "zero interest in exotic anonymity". Which I am very happy to have to do.

tptacek 5y ago
DNSSEC has never validated at the endpoints. By design, validation occurs --- has to occur --- at the recursive server. The channel between you and your recursor is "secured" with a single bit, which says "yeah, sure, I did DNSSEC validation". Don't blame the systems software for this; it's a terrible protocol.
- Hizonner 5y ago
  I am typing this on an endpoint that does DNSSEC validation.
  - tptacek 5y ago
    You can also run default-free full-feed BGP4 on your endpoint, if you're just trying to make a point.
    - Hizonner 5y ago
      I don't run it to make a point. I run it because it's relatively easy to set up even with the presently available software, and it improves my confidence in what I get from the DNS. It would be even easier to set up on an endpoint if DNSSEC were something that people providing OSes cared about. In fact, there's no reason that setting it up intrinsically requires any user interaction at all; it could easily be the default. You claimed that it "by design, validation occurs -- has to occur -- at the recursive server". That is false, and it is false in a way that's important to the issues under discussion. Nothing forces validation to happen at servers other than laziness and inertia.
      - tptacek 5y ago
        I'm not sure you understand what I'm saying. DNSSEC validation occurs step by step through the recursive resolution process. You can't simply request records from a recursive server and then DNSSEC-validate them yourself. I don't think DNSSEC works the way you think it does. Basically the message here is "DNSSEC will work when customer DNS servers go away and everyone just runs their own". Ok, I'll add that to the (long) list of obstacles to its adoption.
        Hizonner 5y ago
        I understand exactly how DNSSEC works. It's been a while since I was really close to it, so I doubt I could sketch the packet formats any more, but I'm crystal clear on the structure... and I still admin it for multiple zones. Insofar as I can extract any meaning from what you say, what you say is false. DNSSEC validation does not take place "step by step through the recursive resolution process". You seem to be conflating the resolver tree with the zone tree. Any entity that can get access to the necessary DS, KEY, and RRSIG records (plus the actual data records) can do a complete local DNSSEC validation from the root to the leaf. It can get those records from anywhere. It doesn't even have to get all of them from the same place. It doesn't have to rely on any validation from the upstream servers, and is in a position to independently verify any validation they do do. In fact, that's a basic DNSSEC design feature. One of the design goals was that intermediate responders didn't have to know about DNSSEC at all. Otherwise it would have been impossible to ever deploy it. The protocol provides for asking a responder not to return invalid records, or even to return them but flag them as suspect. Clients don't have to use that functionality. Clients can always ask for all of data and for themselves. And any responder that does set any validation-related bits is expected to have verified the entire signature chain for itself, not deferred to any validation the next upstream responder claims to have done. There's nothing "step by step" about it. It's true that DNSSEC validation at the application end is <em>typically</em> done by a stub resolver, by which I mean a specific kind of limited DNS server that does recursive lookups and caches results for some defined population of clients, but is not authoritative for any zone. Unfortunately the word "resolver" is confusing, because it's used to refer both to stub resolvers and to more or less any software that does DNS lookups at a client, including libraries linked into application programs. Nonetheless, the validating entity does not have to be a stub resolver or any other kind of DNS responder. It can be a "resolver" in the sense of a library, or it can be something else. Applications don't have to use the DNS protocol to talk to it, and if they do, they can do so entirely locally on a single host. But you can still do on-endpoint validation using a stub resolver, just by using a local one that serves only applications on a single host. To head off your next load of FUD about "running your own DNS server", such a local stub resolver is a small thing that can be installed by default, because you can get it working with zero configuration or administration, beyond maybe a forwarder address that it can get from DHCP. Running an on-node caching resolver is nothing like running an authoritative DNS server, or even a stub resolver serving a whole network, and I know very well that you know that. Don't try to compare them. A local resolver process doesn't demand a lot of resources by post-1990s standards, and the end user doesn't even have to know it's there. In fact, operating systems typically have similar local server processes anyway, for performance reasons. That's exactly what nscd or systemd-resolved does. Indeed, systemd-resolved, even though it was introduced for unrelated reasons, can be told to do DNSSEC validation, removing any need at all for a separate DNS-based stub resolver process. I have trouble believing you're confused about any of this. What you're writing here, and what you've written elsewhere, sounds too much like the output of somebody trying to generate FUD that will convince the half-informed. And, yes, I did read that enormous screed you wrote a few years ago, with all the other gross, and suspiciously convenient, misunderstandings and mischaracterizations.
roca 5y ago
> And it would have been relatively easy to put up a notice that said "your DNS server seems to be dropping all EDNS0 data or whatever stupid thing it's doing; would you like to switch servers"? Which would have avoided centralizing everybody by default. Would you really expect ordinary users to understand that and respond appropriately?

tptacek 5y ago

DNSSEC has never validated at the endpoints. By design, validation occurs --- has to occur --- at the recursive server. The channel between you and your recursor is "secured" with a single bit, which says "yeah, sure, I did DNSSEC validation". Don't blame the systems software for this; it's a terrible protocol.

Hizonner 5y ago
I am typing this on an endpoint that does DNSSEC validation.
- tptacek 5y ago
  You can also run default-free full-feed BGP4 on your endpoint, if you're just trying to make a point.
  - Hizonner 5y ago
    I don't run it to make a point. I run it because it's relatively easy to set up even with the presently available software, and it improves my confidence in what I get from the DNS. It would be even easier to set up on an endpoint if DNSSEC were something that people providing OSes cared about. In fact, there's no reason that setting it up intrinsically requires any user interaction at all; it could easily be the default. You claimed that it "by design, validation occurs -- has to occur -- at the recursive server". That is false, and it is false in a way that's important to the issues under discussion. Nothing forces validation to happen at servers other than laziness and inertia.
    - tptacek 5y ago
      I'm not sure you understand what I'm saying. DNSSEC validation occurs step by step through the recursive resolution process. You can't simply request records from a recursive server and then DNSSEC-validate them yourself. I don't think DNSSEC works the way you think it does. Basically the message here is "DNSSEC will work when customer DNS servers go away and everyone just runs their own". Ok, I'll add that to the (long) list of obstacles to its adoption.
      - Hizonner 5y ago
        I understand exactly how DNSSEC works. It's been a while since I was really close to it, so I doubt I could sketch the packet formats any more, but I'm crystal clear on the structure... and I still admin it for multiple zones. Insofar as I can extract any meaning from what you say, what you say is false. DNSSEC validation does not take place "step by step through the recursive resolution process". You seem to be conflating the resolver tree with the zone tree. Any entity that can get access to the necessary DS, KEY, and RRSIG records (plus the actual data records) can do a complete local DNSSEC validation from the root to the leaf. It can get those records from anywhere. It doesn't even have to get all of them from the same place. It doesn't have to rely on any validation from the upstream servers, and is in a position to independently verify any validation they do do. In fact, that's a basic DNSSEC design feature. One of the design goals was that intermediate responders didn't have to know about DNSSEC at all. Otherwise it would have been impossible to ever deploy it. The protocol provides for asking a responder not to return invalid records, or even to return them but flag them as suspect. Clients don't have to use that functionality. Clients can always ask for all of data and for themselves. And any responder that does set any validation-related bits is expected to have verified the entire signature chain for itself, not deferred to any validation the next upstream responder claims to have done. There's nothing "step by step" about it. It's true that DNSSEC validation at the application end is <em>typically</em> done by a stub resolver, by which I mean a specific kind of limited DNS server that does recursive lookups and caches results for some defined population of clients, but is not authoritative for any zone. Unfortunately the word "resolver" is confusing, because it's used to refer both to stub resolvers and to more or less any software that does DNS lookups at a client, including libraries linked into application programs. Nonetheless, the validating entity does not have to be a stub resolver or any other kind of DNS responder. It can be a "resolver" in the sense of a library, or it can be something else. Applications don't have to use the DNS protocol to talk to it, and if they do, they can do so entirely locally on a single host. But you can still do on-endpoint validation using a stub resolver, just by using a local one that serves only applications on a single host. To head off your next load of FUD about "running your own DNS server", such a local stub resolver is a small thing that can be installed by default, because you can get it working with zero configuration or administration, beyond maybe a forwarder address that it can get from DHCP. Running an on-node caching resolver is nothing like running an authoritative DNS server, or even a stub resolver serving a whole network, and I know very well that you know that. Don't try to compare them. A local resolver process doesn't demand a lot of resources by post-1990s standards, and the end user doesn't even have to know it's there. In fact, operating systems typically have similar local server processes anyway, for performance reasons. That's exactly what nscd or systemd-resolved does. Indeed, systemd-resolved, even though it was introduced for unrelated reasons, can be told to do DNSSEC validation, removing any need at all for a separate DNS-based stub resolver process. I have trouble believing you're confused about any of this. What you're writing here, and what you've written elsewhere, sounds too much like the output of somebody trying to generate FUD that will convince the half-informed. And, yes, I did read that enormous screed you wrote a few years ago, with all the other gross, and suspiciously convenient, misunderstandings and mischaracterizations.

roca 5y ago

> And it would have been relatively easy to put up a notice that said "your DNS server seems to be dropping all EDNS0 data or whatever stupid thing it's doing; would you like to switch servers"? Which would have avoided centralizing everybody by default. Would you really expect ordinary users to understand that and respond appropriately?