In my limited experience, DNSSEC is only usable when your resolver is allowed to downgrade to insecure DNS. It just breaks too often. Strict DNSSEC is a pain.
So for me, SSHFP isn’t really much protection against MITM.
How does “it” break? Can some domains not be resolved because they have some form of brokenness in their DNSSEC setup?
I’m using a DNSSEC verifying resolver on my laptop and servers, and haven’t run into any issues yet.
With extended dns errors (EDE), you get details about DNS failures. So if an issue arises, it should be relatively easy to diagnose. I am a bit surprised at how new EDE is, seems like a pretty basic requirement for diagnosing issues…
Good reminder, I’m not using SSHFP, but it’s easy enough to setup and use.
DNSSEC needs support from all resolvers so that signatures are passed along correctly and so that DS records are queried in the parent zone. There are sadly a lot of resolvers that still lack basic support for a 19-year-old standard.
Yeah, I wouldn’t rely on the resolvers received through dhcp on random networks to implement dnssec. I run unbound locally. No other resolvers should be involved then (only the authoritative name servers). A local dnssec resolver also makes it more reasonable for software (that reads /etc/resolv.conf) to trust the (often still unverified) connection to the resolver.
If a network I’m on would intercept dns requests (from unbound) towards authoritative dns servers, and would break dnssec-related records, then that would cause trouble. I just checked, and it turns out my local unbound forwards to unbound instances on servers, over a vpn (to resolve internal names). Perhaps my experience would be worse when connecting directly to authoritative name servers on random networks.
On servers, I haven’t seen any dns(sec)-related request/response mangling, and would just move elsewhere when that happens.
I’m honestly not sure how it broke; that’s part of the problem. After all my time troubleshooting, I eventually decided to go back to plain-old DNS and get on with my life.
Maybe the tooling is better these days, and next time I set it up, it’ll go more smoothly.
In my limited experience, DNSSEC is only usable when your resolver is allowed to downgrade to insecure DNS. It just breaks too often. Strict DNSSEC is a pain.
So for me, SSHFP isn’t really much protection against MITM.
How does “it” break? Can some domains not be resolved because they have some form of brokenness in their DNSSEC setup? I’m using a DNSSEC verifying resolver on my laptop and servers, and haven’t run into any issues yet.
With extended dns errors (EDE), you get details about DNS failures. So if an issue arises, it should be relatively easy to diagnose. I am a bit surprised at how new EDE is, seems like a pretty basic requirement for diagnosing issues…
Good reminder, I’m not using SSHFP, but it’s easy enough to setup and use.
DNSSEC needs support from all resolvers so that signatures are passed along correctly and so that DS records are queried in the parent zone. There are sadly a lot of resolvers that still lack basic support for a 19-year-old standard.
Yeah, I wouldn’t rely on the resolvers received through dhcp on random networks to implement dnssec. I run unbound locally. No other resolvers should be involved then (only the authoritative name servers). A local dnssec resolver also makes it more reasonable for software (that reads /etc/resolv.conf) to trust the (often still unverified) connection to the resolver.
If a network I’m on would intercept dns requests (from unbound) towards authoritative dns servers, and would break dnssec-related records, then that would cause trouble. I just checked, and it turns out my local unbound forwards to unbound instances on servers, over a vpn (to resolve internal names). Perhaps my experience would be worse when connecting directly to authoritative name servers on random networks. On servers, I haven’t seen any dns(sec)-related request/response mangling, and would just move elsewhere when that happens.
I’m honestly not sure how it broke; that’s part of the problem. After all my time troubleshooting, I eventually decided to go back to plain-old DNS and get on with my life.
Maybe the tooling is better these days, and next time I set it up, it’ll go more smoothly.
If somebody is bored or wants to earn internet points, a PAKE for ssh would be a nice project.