Re: [dns-privacy] WGLC : draft-ietf-dprive-unilateral-probing

[Florian Obser <[e-mail]>]

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.