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

[Petr Špaček <[e-mail]>]

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