Open TomTervoort opened 3 years ago
If the parent zone is not signed, all bets are off, anyway, an attacker can always redirect you to the name servers of his choice. So, the solution is "do not expect any security when your parent zone is unsigned". (This is a consequence of the fact that DNS is tree-structured and DNSSEC follows this path. You need a trustable parent.)
For your last paragraph, note that some people believe that name servers should always be in the zone they serve, for security and control. (In France, it is in the official recommendations from ANSSI, the national cybersceurity agency.)
If the parent zone is not signed, all bets are off, anyway, an attacker can always redirect you to the name servers of his choice. So, the solution is "do not expect any security when your parent zone is unsigned". (This is a consequence of the fact that DNS is tree-structured and DNSSEC follows this path. You need a trustable parent.)
That's correct. But even a signed parent zone does not need to sign its delegation records. They just need to provide a signed DS record (or authenticated denial thereof). This means that DNSSEC allows attackers to alter nameserver names during delegation (which apparently was not considered to be problematic originally). Section 2.2 of RFC 4035 says the following:
The NS RRset that appears at the zone apex name MUST be signed, but
the NS RRsets that appear at delegation points (that is, the NS
RRsets in the parent zone that delegate the name to the child zone's
name servers) MUST NOT be signed. Glue address RRsets associated
with delegations MUST NOT be signed.
For your last paragraph, note that some people believe that name servers should always be in the zone they serve, for security and control. (In France, it is in the official recommendations from ANSSI, the national cybersceurity agency.)
I agree. Unfortunately as long as resolvers will accept nameservers that are not in the zones they serve, the attack I described should be possible. The upside is that if the majority of nameserver names are in their own zone, it will rarely be needed to query an additional NS
record to verify nameserver name authenticity.
This means that DNSSEC allows attackers to alter nameserver names during delegation
Yes, but because of the DS record, the responses obtained from the bad name servers will be bogus and therefore rejected by validating resolvers. So this attack cannot be a hijacking, it is "only" a DoS (something the attacker could do in other ways, anyway).
I agree
Not me. Because it makes you depend on glue records, which are one more possible way to error.
This means that DNSSEC allows attackers to alter nameserver names during delegation
Yes, but because of the DS record, the responses obtained from the bad name servers will be bogus and therefore rejected by validating resolvers. So this attack cannot be a hijacking, it is "only" a DoS (something the attacker could do in other ways, anyway).
Ah, I didn't intend to claim this would allow domain hijacking, just a confidentiality violation: an attacker can forward queries to the legitimate authoritative nameserver, and send the correct responses back along with a signature. What the attacker gains is that they can see exactly what subdomains the resolver is querying.
If I understood correctly, when in strict mode, an active man-in-the-middle attacker should not be able to read the queries from a resolver in strict mode to an authoritative nameserver, when both support this mechanism. This attack shows a way an attacker can break this requirement, when the parent (or parent's parent etc.) nameserver does not implement this mechanism itself.
I do not see a solution for this issue. Authentication of authoritative name servers is much more complicated than authentication of the resolvers because they are many and you don't have a preexisting relationship with them.
DNSSEC requires that authoratative nameservers store a signed NS record that binds them to the zone they serve. Couldn't that be used to validate the name used for nameserver DANE validation? Or is there a reason why this wouldn't work in practice?
It would require resolvers to be fully child-centric (revalidating the NS RRset they got from the parent) which is a long-standing debate...
I have a small remark about section 2 of draft-bortzmeyer-dprive-resolver-to-auth-01: it states that a resolver should use the domain name of the name server to construct TLSA queries. However, it doesn't specify a requirement for the resolver to verify the authenticity of the name.
Section 1 states that this name is "obtained from zone delegation", which I assume to mean it is taken from the NS record of the parent nameserver. This, however, would allow a man-in-the-middle attack (even in strict mode) when the parent server does not support TLS, but the child server does. This is because DNSSEC does not require the parent server to provide signatures along with delegation records, so an attacker could alter the name contained within NS records.
Assuming the nameserver of
example.com
supports encryption, such an attack could work as follows:secret.example.com
, and first performs an NS query forexample.com
to the TLD nameserver, which does not happen to support (authenticated) encryption.ns1.example.com
in the reply's NS record with the attacker-owned domain namens.evil.org
. Optionally they could also mess with the glue records._853._tcp.ns.evil.org
.evil.org
.secret.example.com
to the attacker-controlled nameserver.A solution would be to require the resolver to query the supposed authoritative nameserver for NS records for
example.com
and require them to be signed, so the resolver can verify the nameserver name in addition to DANE checking.This extra check would only be necessary if the nameserver domain name is not in the same zone it is supposed to be authoritative for: so it's fine when
ns1.example.com
claims authority forexample.com
, but when the nameserver's name isns.somethingelse.com
, it should be queried for a secure NS record forexample.com
that explicitly points tons.somethingelse.com
. If the result is bogus/missing/insecure, and the resolver is in strict mode, the resolver should stop querying this nameserver.I hope this recommendation was helpful.