There was some discussion in last night's meeting about encoding keys in
the DNS name of a nameserver, similar to DNSCurve. There are at least
some issues with it:

1. The RDATA of an NS record has to be a hostname, so it would limit the
amount of data that can be encoded within the NSDNAME. As an example,
base32 encoding is not possible.

2. It would have to work for nameservers that are within a domain with a
very long name already.

3. Let's assume it takes about 10 years for resolver->auth privacy
transport to trickle into widespread operational availability. It is
expected that quantum computers capable of obsoleting traditional crypto
will be available in as few as 15-20 years from now. It is unclear if
the limited length of keys that can be encoded into a subset of a DNS
name would be sufficient for post-quantum crypto algorithms.

4. NS records returned as part of delegations are unsigned, so for a
resolver to trust key information in the RDATA of such NS records in a
delegation, it would require the delegation to be returned using secure
transport to the parent-side nameserver of the zone cut. During last
night's conversation, there was some talk about fallback to plain
transports - it will not be useful unless the entire delegation from
root is followed with secure transports.

                Mukund

_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to