2 ms·

I am typing this on an endpoint that does DNSSEC validation.

by Hizonner 5y ago

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.
      - tptacek 5y ago
        This is a long description of how an endpoint can do much of the work a recursive cache does for itself. We all understand that it can. You've clarified, you understand how DNS servers do lookups; I won't suggest that you don't again. It was never my claim that every server in the DNS topology needed to be DNSSEC-aware (though, obviously, every authority from leaf to root needs to be). You haven't made any headway in your argument about how everyone is going to run DNS software that does this stuff. It's "easy" to do this stuff, in the same sense that it's trivial to run a local djbdns instance on your laptop instead of relying on your ISP's server. My point is: that's not how DNS is normally deployed.

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.
    - tptacek 5y ago
      This is a long description of how an endpoint can do much of the work a recursive cache does for itself. We all understand that it can. You've clarified, you understand how DNS servers do lookups; I won't suggest that you don't again. It was never my claim that every server in the DNS topology needed to be DNSSEC-aware (though, obviously, every authority from leaf to root needs to be). You haven't made any headway in your argument about how everyone is going to run DNS software that does this stuff. It's "easy" to do this stuff, in the same sense that it's trivial to run a local djbdns instance on your laptop instead of relying on your ISP's server. My point is: that's not how DNS is normally deployed.