3 ms·

For the vast majority of DNSSEC-enabled end user systems, the user's device is not doing its own DNSSEC validations. It's using a DNSSEC-enabled resolver and tr

by akerl_ 4y ago

For the vast majority of DNSSEC-enabled end user systems, the user's device is not doing its own DNSSEC validations. It's using a DNSSEC-enabled resolver and trusting the bit set on the DNS query response where the recursive resolver says "yup, I confirm that DNSSEC is good here". Given that these resolvers are generally provided by the user's ISP, if the ISP wants to lie about DNSSEC, they can just fudge the results and set that bit to "yup, we're good". The only way around this is for local systems to do their own recursive resolution, which isn't the default configuration on any OS or distribution that I'm aware of.

marcosdumay 4y ago
Honestly, this is something I shouldn't have to say. But getting a DNS response with a flag saying "yep, trust me, it's valid" is not DNSSEC. What is it with DNSSEC that people have to pollute discussions saying that stupid stuff that isn't DNSSEC isn't secure?
- akerl_ 4y ago
  Are there any operating systems or distributions that actually ship with DNSSEC validation via local recursive resolution? The reason I'm describing local stub resolvers that check the dnssec bit of their upstream recursive resolver is because that's how DNSSEC is implemented in every OS/distro I'm aware of. So that configuration is what actually matters when we talk about users being protected (or not) by DNSSEC.
- tptacek 4y ago
  It's an interesting flavor of "No True Scotsman" when you've managed to argue that every resolver on every OS in the world is "stupid stuff that isn't DNSSEC". If DNSSEC only works if you're using a custom fully-recursing resolver, not present on any mainstream operating system or built into a single piece of software you install on your machine, what exactly is the point of signing a zone? So far as you're concerned, nothing is doing DNSSEC validation in the first place.
  - marcosdumay 4y ago
    DNSSEC has a very clear specification a few widespread implementations. What you are talking about fit to those? Are you really making FUD about it, by claiming unrelated logical fallacies in a non-boolean discussion? How does a "no true Scotsman" even applies to something that has a published standard? I know you don't like it, yet, I have never seen any proposal that brings you the assurances DNSSEC brings. AFAIK, your favorites all wither solve different problems (relevant problems, yes, but not the same) or have strictly lower assurances (AKA, they are subject to the exact same flaws, and are either worse or not better of for each one of them).
    - akerl_ 4y ago
      It feels like you're not as familiar with the spec as you think you are. DNSSEC defines stub resolvers, both validating and non-validating. Validating stub resolvers do their own supplemental recursive lookups to confirm DNSSEC validation. Non-validating stub resolvers do not: they strictly determine DNSSEC trust by checking for the "ad" header bit in the response from their upstream recursive resolver. Every operating system, Linux distribution, and application that I'm aware of defaults to having a non-validating stub resolver (if it enables DNSSEC validation at all). This renders DNSSEC validation as performed by the overwhelming majority of systems vulnerable to the risk we're flagging here.

by akerl_ 4y ago

marcosdumay 4y ago

Honestly, this is something I shouldn't have to say. But getting a DNS response with a flag saying "yep, trust me, it's valid" is not DNSSEC. What is it with DNSSEC that people have to pollute discussions saying that stupid stuff that isn't DNSSEC isn't secure?

akerl_ 4y ago
Are there any operating systems or distributions that actually ship with DNSSEC validation via local recursive resolution? The reason I'm describing local stub resolvers that check the dnssec bit of their upstream recursive resolver is because that's how DNSSEC is implemented in every OS/distro I'm aware of. So that configuration is what actually matters when we talk about users being protected (or not) by DNSSEC.
tptacek 4y ago
It's an interesting flavor of "No True Scotsman" when you've managed to argue that every resolver on every OS in the world is "stupid stuff that isn't DNSSEC". If DNSSEC only works if you're using a custom fully-recursing resolver, not present on any mainstream operating system or built into a single piece of software you install on your machine, what exactly is the point of signing a zone? So far as you're concerned, nothing is doing DNSSEC validation in the first place.
- marcosdumay 4y ago
  DNSSEC has a very clear specification a few widespread implementations. What you are talking about fit to those? Are you really making FUD about it, by claiming unrelated logical fallacies in a non-boolean discussion? How does a "no true Scotsman" even applies to something that has a published standard? I know you don't like it, yet, I have never seen any proposal that brings you the assurances DNSSEC brings. AFAIK, your favorites all wither solve different problems (relevant problems, yes, but not the same) or have strictly lower assurances (AKA, they are subject to the exact same flaws, and are either worse or not better of for each one of them).
  - akerl_ 4y ago
    It feels like you're not as familiar with the spec as you think you are. DNSSEC defines stub resolvers, both validating and non-validating. Validating stub resolvers do their own supplemental recursive lookups to confirm DNSSEC validation. Non-validating stub resolvers do not: they strictly determine DNSSEC trust by checking for the "ad" header bit in the response from their upstream recursive resolver. Every operating system, Linux distribution, and application that I'm aware of defaults to having a non-validating stub resolver (if it enables DNSSEC validation at all). This renders DNSSEC validation as performed by the overwhelming majority of systems vulnerable to the risk we're flagging here.