On Wed, Oct 30, 2019 at 2:37 AM Watson Ladd <[email protected]> wrote:
> > The root zone is data: whether one distributes it via DoT, DoH, IPv6, or > carrier pigeon is irrelevant to the policies that goven what's in it. > That is arguably true, but I think we are having this discussion primarily because of RFC 4035 Section 2.2: 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 Some of the proposals being discussed here would bootstrap ADoT from the contents of the NS record at the delegation point. The problem is that this record is not signed. As a result, an attacker could inject a forged version of these records into a recursive cache, breaking ADoT to the child. The ideas floated here about ADoT to the root are not, in my view, about privacy (directly). They're about using ADoT to protect the integrity of (currently) unsigned data in the root zone. An alternative solution is to get ADoT bootstrap info from the child zone, where it could be signed, before making a query that reveals the next label. This could work, but at the cost of an extra roundtrip. (How often this latency penalty applies depends on the details of the construction.)
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
