In article <[email protected]> you write: >> That's per-zone, though, whereas DoT support is per-server. > >Maybe that's ideal, but one would expect that a zone only rolls this >out once all their nameservers support it.
Most of my zones have a secondary run by somebody else, whose software is never in sync with mine. It's also fairly common for large operators to mitigate their DNS risk by spreading DNS across multiple providers. If you have to wait until every server can do ADoT rather than until some of them can, that will make deployment a lot slower. > Otherwise, whether or not >resolvers do DoT to authoritative servers would be an odd game of >russian roulette depending on which NS record was followed, something >that could even be tweaked by an attacker, like by stripping glue from >the ones that did support it. There are plenty of signal schemes that don't fail that way. See my recent draft. >> DS records that somehow encode NS target names in their rdata might >> work... > >That still leaves too much control at the parent to change it against >the child's wishes. A DNSKEY flag commits the child zone using publication >at its parent without giving the parent a veto. The parent zone always has a veto. It can remove the NS or DS records if it doesn't like what the child is doing. R's, John _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
