Dnssec is just as vulnerable to mitm attacks, because you just strip the dnssec responses and the client has no way to know if it the resolver just doesn't support DNSSEC
The crypto ones don't even warrant a response, they are non compatible with anything that happens today.
2. Configure network settings to use 127.0.0.1 as the resolver
You now have end to end DNSSEC protected DNS (when the domain supports it. Where support is admittedly low). The best a MITM can do is block your lookups. In the same way they can also block your HTTPS connections.
[edit] Of course, the above will now fail by default in Firefox, because they wont use your local system resolver. Every other app on your system will be secured though. Until they also start getting their own custom made name resolution systems too.
Browsers tried to do DNSSEC validation. It didn't work. DNSSEC features in Chrome, OS X, and Firefox were rolled back.
Also: it is part of the architecture of DNSSEC for clients not to do full validation, which requires that they act as their own recursive resolvers and eliminates shared caches.
Any pointers to which browser versions did do DNSSEC validation and is there any documentation of what didn't work? My experience with running the validator plugin for a couple of years is that it just works.
Obviously, in the early days of DNSSEC there were more improperly signed zones. But since Google's public resolvers do DNSSEC validation, that is mostly a thing of the past.
Then there might be the rare case of middle boxes breaking DNSSEC, but as far as I can tell, that is extremely rare.
There is no connection between DNSSEC validation and being a full recursive resolver. You can easily have a stub resolver that does DNSSEC validation. Or, if it is easier, have a local validation recursive resolver that forwards to another recursive resolver.
I'm sure you are aware that Google has different results for different people. So for me the first 10 hits: don't seem to include any reference to browser versions that did DNSSEC validation. And didn't have any reference to studies using those browser versions to see what breaks.
In short, 'Just google it' often means that somebody doesn't actually have the relevant references.
There are tlds that are unsigned, and any domains that are unsigned. You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. You can maybe pin some of the tld keys, but you can't pin all the domains under them.
Comments
Ipns lookups take over a minute: https://github.com/ipfs/go-ipfs/issues/3860
Dnssec is just as vulnerable to mitm attacks, because you just strip the dnssec responses and the client has no way to know if it the resolver just doesn't support DNSSEC
The crypto ones don't even warrant a response, they are non compatible with anything that happens today.
1. sudo apt install unbound
2. Configure network settings to use 127.0.0.1 as the resolver
You now have end to end DNSSEC protected DNS (when the domain supports it. Where support is admittedly low). The best a MITM can do is block your lookups. In the same way they can also block your HTTPS connections.
[edit] Of course, the above will now fail by default in Firefox, because they wont use your local system resolver. Every other app on your system will be secured though. Until they also start getting their own custom made name resolution systems too.
The reason DNSSEC is vulnerable to that kind of MITM attack is because browsers refuse to do client side validation.
For privacy reasons, DNS over TLS and DNS over HTTPS are still a good idea. So even with DNSSEC you would need one of those.
Browsers tried to do DNSSEC validation. It didn't work. DNSSEC features in Chrome, OS X, and Firefox were rolled back.
Also: it is part of the architecture of DNSSEC for clients not to do full validation, which requires that they act as their own recursive resolvers and eliminates shared caches.
Any pointers to which browser versions did do DNSSEC validation and is there any documentation of what didn't work? My experience with running the validator plugin for a couple of years is that it just works.
Obviously, in the early days of DNSSEC there were more improperly signed zones. But since Google's public resolvers do DNSSEC validation, that is mostly a thing of the past.
Then there might be the rare case of middle boxes breaking DNSSEC, but as far as I can tell, that is extremely rare.
There is no connection between DNSSEC validation and being a full recursive resolver. You can easily have a stub resolver that does DNSSEC validation. Or, if it is easier, have a local validation recursive resolver that forwards to another recursive resolver.
Google [why not dane in browsers].
I'm sure you are aware that Google has different results for different people. So for me the first 10 hits: don't seem to include any reference to browser versions that did DNSSEC validation. And didn't have any reference to studies using those browser versions to see what breaks.
In short, 'Just google it' often means that somebody doesn't actually have the relevant references.
You can make your resolver verify the entire chain.
There are tlds that are unsigned, and any domains that are unsigned. You can not verify the entire chain, because it is possible that the domain you are looking up is infact unsigned. You can maybe pin some of the tld keys, but you can't pin all the domains under them.
Then you conclude that it's okay that the domain is unsigned. Else - hard fail.
I don't know what the figures are today, but in 2016, 89% of TLDS were signed using DNSSEC - https://www.internetsociety.org/blog/2017/01/state-of-dnssec...