- Impact
- 177
https://dlv.isc.org/
DNSSEC - what it is: The DNS system was designed before security was a major consideration. As a result, the DNS system is rather insecure, it is relatively easy to pull a MITM attack and give forged DNS responses. This is common on open wifi networks, sometimes called the "Coffee House Attack"
DNSSEC addresses that issue by using private/public key cryptography to sign the DNS records. With a client that supports DNSSEC, it can verify that the DNS record it received has not been altered, forged, or otherwise tampered with.
The root server signs keys for the TLDs and the TLDs sign keys for the zones, creating a verifiable chain of trust.
However not all TLDs have records signed in the root zone. That's where the ISC DLV came in.
Instead of using the chain of trust from the ICANN root, you could have your DS records signed by the ISC DLV and most (all?) DNSSEC aware clients would trust it.
That is coming to an end, largely because now the vast majority of TLDs are signed by the ICANN root.
If you have domain(s) on TLDs that don't have records signed in the ICANN root, and DNSSEC is something you want, it is time to pressure your TLD to get their act together and participate because the ISC DLV is going away, and I don't believe any others exist that don't require the client specifically accept them.
All ngTLDs are already required to participate in DNSSEC, it is mostly ccTLDs that still need to get with the program and may be affected by this. There may be a few older gTLDs that don't, I don't know.
Some people also used the ISC DLV who didn't need to use the service, those people need to get their TLD to sign their DS records instead of the ISC DLV.
DNSSEC - what it is: The DNS system was designed before security was a major consideration. As a result, the DNS system is rather insecure, it is relatively easy to pull a MITM attack and give forged DNS responses. This is common on open wifi networks, sometimes called the "Coffee House Attack"
DNSSEC addresses that issue by using private/public key cryptography to sign the DNS records. With a client that supports DNSSEC, it can verify that the DNS record it received has not been altered, forged, or otherwise tampered with.
The root server signs keys for the TLDs and the TLDs sign keys for the zones, creating a verifiable chain of trust.
However not all TLDs have records signed in the root zone. That's where the ISC DLV came in.
Instead of using the chain of trust from the ICANN root, you could have your DS records signed by the ISC DLV and most (all?) DNSSEC aware clients would trust it.
That is coming to an end, largely because now the vast majority of TLDs are signed by the ICANN root.
If you have domain(s) on TLDs that don't have records signed in the ICANN root, and DNSSEC is something you want, it is time to pressure your TLD to get their act together and participate because the ISC DLV is going away, and I don't believe any others exist that don't require the client specifically accept them.
All ngTLDs are already required to participate in DNSSEC, it is mostly ccTLDs that still need to get with the program and may be affected by this. There may be a few older gTLDs that don't, I don't know.
Some people also used the ISC DLV who didn't need to use the service, those people need to get their TLD to sign their DS records instead of the ISC DLV.
