3 ms·

DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop s

by phicoh 8y ago

DNSSEC validation has nothing to do with 'servers'. Maybe you want to take a look at, for example, https://getdnsapi.net/ https://getdnsapi.net/ Please stop spreading misinformation. Another example, openssh can locally do DNSSEC validation of SSHFP records (using the ldns library). Unfortunately, it doesn't really work, but that is a different story. All of the validation code is there.

tptacek 8y ago
You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].
- deleted 8y ago
  [deleted]
- Abekkus 8y ago
  You can run a local resolver that forwards all queries to 8.8.8.8 while still running dnssec validation, and get both the speed benefit of a caching infrastructure, and the authentication of dnssec. With only one trusted key.
  - tptacek 8y ago
    Yes, DNSSEC works fine for endpoints if we eliminate globally the concept of a DNS client and a shared cache and just have everyone run their own DNS servers.
    - Abekkus 8y ago
      The configuration I spoke of does not eliminate a shared cache, it uses the existing shared cache. In addition, a validating endpoint resolver is no more a "dns server", than a stub resolver is.
      - tptacek 8y ago
        Your proposal drastically changes the role of all mainstream endpoint resolvers, which today delegate the recursive part of the lookup to "DNS servers" and which, in the world you're thinking of, would own that lookup completely and use DNS servers, if at all, as mere request forwarders. Not for nothing, but even the IETF doesn't want you to do this.

by phicoh 8y ago

tptacek 8y ago

You don't seem to understand the difference between the resolver in a DNS cache server and a stub resolver. The stub DNS resolver on your desktop computer, as a general rule, does not do lookups from the DNS root all the way down to whatever leaf authority server holds the record it's trying to find. That's the job of caching resolvers --- the ones that live in servers like 8.8.8.8 and 1.1.1.1 (or whatever janky server your ISP or IT department sets you up with). If you're talking to a "DNS server" from your desktop --- like, you know, almost everyone on the Internet does --- you're not doing DNSSEC and, obviously, can't, because you've delegated to your DNS server the job of making all the intermediate requests needed to validate the chain of signatures to the root. A search term you might find helpful: [DNS header AD bit].

deleted 8y ago
[deleted]
Abekkus 8y ago
You can run a local resolver that forwards all queries to 8.8.8.8 while still running dnssec validation, and get both the speed benefit of a caching infrastructure, and the authentication of dnssec. With only one trusted key.
- tptacek 8y ago
  Yes, DNSSEC works fine for endpoints if we eliminate globally the concept of a DNS client and a shared cache and just have everyone run their own DNS servers.
  - Abekkus 8y ago
    The configuration I spoke of does not eliminate a shared cache, it uses the existing shared cache. In addition, a validating endpoint resolver is no more a "dns server", than a stub resolver is.
    - tptacek 8y ago
      Your proposal drastically changes the role of all mainstream endpoint resolvers, which today delegate the recursive part of the lookup to "DNS servers" and which, in the world you're thinking of, would own that lookup completely and use DNS servers, if at all, as mere request forwarders. Not for nothing, but even the IETF doesn't want you to do this.