On 27. 03. 23 8:00, Florian Obser wrote:
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.
TL;DR: From my point of view the text is good as it is.
I would feel really uneasy in the opposite case, i.e. if the requirement
was dropped.
Doing probing **per zone** adds lots of state and attempts. Right now
most transport-level state in BIND is currently tied to peer's IP
address (as opposed to [IP, zone] combination) and I don't see
compelling reason to change that.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
