Hi there! first, there is a typo in section 4.5:
The recursive resolver SHOULD keep a record of the state for each authoritative server it contacts, indexed by the IP address of the authoritative server and the encrypted transports supported by the recursive resolver. Should be The recursive resolver SHOULD keep a record of the state for each authoritative server it contacts, indexed by the IP address of the authoritative server and the encrypted transports supported by the authoritative server. i.e. the s/recursive resolver/authoritative server/ in the last line Secondly, it has already been noted that it is OPTIONAL for an authoritative server to implement *this* protocol. I presume *this* protocol meaning support for unilateral probing. However unilateral probing restricts how DoT / DoQ can be deployed. This is first hinted at in "3.3. Server Name Indication": However, such a server MUST NOT serve resource records that differ based on SNI (or on the lack of SNI) provided by the client, because a probing recursive resolver that offers SNI might or might not have used the right server name to get the records it is looking for. And later in "4.2. Maintaining Authoritative State by IP Address": In designing a probing strategy, the recursive resolver could record its knowledge about any given authoritative server with different strategies, including at least: * the authoritative server's IP address, * the authoritative server's name (the NS record used), or * the zone that contains the record being looked up. This document encourages the first strategy, to minimize timeouts or accidental delays. This document does not describe the other two strategies because the first is strongly encouraged. An authoritative server operator might want to offer DoT/DoQ as a "premium service" to its customers, this drafts prevents them from doing so. Or they need to setup dedicated IP addresses for the premium zones. a.ns.example.net AAAA 2001:db::1:53 Normal zone: example.org NS a.ns.example.net Premium zone: example.com NS a.ns.example.net Querying a.ns.example.net for example.com SOA on Do53 and DoT will result in NOERROR, so the recursive resolver will assume that a.ns.example.net supports unilateral probing. Querying a.ns.example.net for example.org SOA on DoT however will result in REFUSED, while querying on Do53 would result in NOERROR. For the imagined authoritative server operator to be compliant with this draft they'd need to change their setup to something like this: a.ns.example.net AAAA 2001:db::1:53 b.ns.example.net AAAA 2001:db::2:53 Normal zone: example.org NS a.ns.example.net Premium zone: example.com NS b.ns.example.net I have no opinion on whether this is a sensible business strategy but it feels odd that this document normatively restricts what a DoT / DoQ authoritative server can do. At the very least this should be pointed out, e.g. at the end of 3. Guidance for Authoritative Servers: An authoritative server implementing DoT or DoQ MUST authoritatively server the same zones over all supported transports. This still makes me feel uneasy though. -- In my defence, I have been left unsupervised. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
