Subject: [Add] Default port for classic DNS and draft-schwartz-svcb-dns-03

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Apr 2021 22:15:53 +0000

Greetings again. draft-schwartz-svcb-dns-03 got rid of DoT as the default secure transport. After doing that, _5353._dns.<ns-name> means, approximately, "the nameserver that does not run classic DNS on port 53, but instead runs on port 5353". That seems like a truly bizarre query, because the querier has no idea what ports an authoritative server would use for classic DNS.

Proposal: get rid of "Port Prefix Naming" for this draft, switch to normal SVCB naming (first paragraph of Section 2.3 of draft-ietf-dnsop-svcb-https-05). This would mean changing Section 3 of this document, and "Name prefix" in Table 3. This will simplify the implementation a bit, and won't prevent anyone from getting the data they need.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 26 Apr 2021 15:37:24 -0700

On Mon, Apr 26, 2021 at 3:16 PM Paul Hoffman <[email-masked]> wrote:

> Greetings again. draft-schwartz-svcb-dns-03 got rid of DoT as the default
> secure transport. After doing that, _5353._dns.<ns-name> means,
> approximately, "the nameserver that does not run classic DNS on port 53,
> but instead runs on port 5353". That seems like a truly bizarre query,
> because the querier has no idea what ports an authoritative server would
> use for classic DNS.
>

An authoritative server discovered via an NS record would always use the
default port for classic DNS, so the name would always be "_dns.$NSNAME".

Proposal: get rid of "Port Prefix Naming" for this draft, switch to normal
> SVCB naming (first paragraph of Section 2.3 of
> draft-ietf-dnsop-svcb-https-05). This would mean changing Section 3 of this
> document, and "Name prefix" in Table 3. This will simplify the
> implementation a bit,

Why?  If your use case (like most DNS use cases) doesn't support
non-default ports, then you don't need to implement any of this.  You can
just use a fixed "_dns" prefix.

> and won't prevent anyone from getting the data they need.

While it's certainly unusual, and often impossible, to run classic DNS on
non-default ports, it is defined, e.g. in RFC 4501.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Apr 2021 22:46:48 +0000

On Apr 26, 2021, at 3:37 PM, Ben Schwartz <[email-masked]> wrote:
> An authoritative server discovered via an NS record would always use the default port for classic DNS, so the name would always be "_dns.$NSNAME".

Exactly.

>> Proposal: get rid of "Port Prefix Naming" for this draft, switch to normal SVCB naming (first paragraph of Section 2.3 of draft-ietf-dnsop-svcb-https-05). This would mean changing Section 3 of this document, and "Name prefix" in Table 3. This will simplify the implementation a bit,
>> 
> Why?  If your use case (like most DNS use cases) doesn't support non-default ports, then you don't need to implement any of this.

Implementers need to write code for everything in the protocol, not just the use cases they predict.

>  You can just use a fixed "_dns" prefix.

That's what would be used, yes.

> While it's certainly unusual, and often impossible, to run classic DNS on non-default ports, it is defined, e.g. in RFC 4501.

This misses the point: if the querier can't know what non-default classic ports the authoritative server is running on, it can't know what to prepend to the _dns. Even if it had prior knowledge of some non-default classic port, what value is that in the request? The response will be a full RRset for the encrypted transports anyhow.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 26 Apr 2021 16:25:01 -0700

On Mon, Apr 26, 2021 at 3:46 PM Paul Hoffman <[email-masked]> wrote:
...

> > While it's certainly unusual, and often impossible, to run classic DNS
> on non-default ports, it is defined, e.g. in RFC 4501.
>
> This misses the point: if the querier can't know what non-default classic
> ports the authoritative server is running on, it can't know what to prepend
> to the _dns.

This specification is not specific to recursive or authoritative servers.
It applies to any DNS services, including recursive and forwarding DNS
servers.  In the context of recursive resolution, the authoritative
server's port number is always the default, so this text is moot, and
implementations that focus on that use case can use a fixed prefix of
"_dns".

Even if it had prior knowledge of some non-default classic port, what value
> is that in the request?

It is relevant if DNS services with distinct behaviors are (or could be)
available on different port numbers (e.g. experimental or debugging
behavior on a non-default port).

> The response will be a full RRset for the encrypted transports anyhow.

 In principle, the RRSets for each port number could be different,
especially if the DNS services operating on different port numbers are in
fact different.

I interpret your suggestion as declaring that, if multiple DNS services are
operating on a single IP address at different UDP port numbers, they must
all have the same behavior in order to use this specification.  I am open
to imposing that requirement, but I don't think it's a requirement that
exists in any RFC today.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Apr 2021 03:10:10 +0000

On Apr 26, 2021, at 4:25 PM, Ben Schwartz <[email-masked]> wrote:
> This specification is not specific to recursive or authoritative servers.  It applies to any DNS services, including recursive and forwarding DNS servers.  In the context of recursive resolution, the authoritative server's port number is always the default, so this text is moot, and implementations that focus on that use case can use a fixed prefix of "_dns".

Sorry, I didn't know that this spec was for use cases beyond DPRIVE and ADD. I apologize for my narrow view.

Having said that, the document should thus be more explicit about not needing "_53." in the case that the target is responding using classic DNS on port 53. In the -03 draft, that's hinted at but not said. 

But then it is not clear whether the authoritative server that is responding for _dns.FQDN MUST also respond for _53._dns.FQDN. That needs to be made explicit as well. I would be surprised if the zone file examples in the -03 would cause the authoritative server to respond for _53._tcp.

>>  In principle, the RRSets for each port number could be different, especially if the DNS services operating on different port numbers are in fact different.
> 
> I interpret your suggestion as declaring that, if multiple DNS services are operating on a single IP address at different UDP port numbers, they must all have the same behavior in order to use this specification.  I am open to imposing that requirement, but I don't think it's a requirement that exists in any RFC today.

Fair point, but few if any protocols have names that change when there is a default value.

This feels awfully messy, but likely fixable.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 27 Apr 2021 14:33:57 -0700

I've updated the editor's copy of the draft to address the confusion here
[1].  Hopefully this text makes the behavior and motivation clearer.

[1]
https://github.com/bemasc/svcb-dns/commit/b71df7a491e27a07f4f389a111c7c1fa36c448c7?short_path=fa7f3e1#diff-fa7f3e1a35e71eb51131c0ee67ab2d48b19975403de71b9464b900c6a4250961

On Mon, Apr 26, 2021 at 8:10 PM Paul Hoffman <[email-masked]> wrote:

> > This specification is not specific to recursive or authoritative
> servers.  It applies to any DNS services, including recursive and
> forwarding DNS servers.  In the context of recursive resolution, the
> authoritative server's port number is always the default, so this text is
> moot, and implementations that focus on that use case can use a fixed
> prefix of "_dns".
>
> Having said that, the document should thus be more explicit about not
> needing "_53." in the case that the target is responding using classic DNS
> on port 53. In the -03 draft, that's hinted at but not said.
>
> But then it is not clear whether the authoritative server that is
> responding for _dns.FQDN MUST also respond for _53._dns.FQDN. That needs to
> be made explicit as well. I would be surprised if the zone file examples in
> the -03 would cause the authoritative server to respond for _53._tcp.
>
> > I interpret your suggestion as declaring that, if multiple DNS services
> are operating on a single IP address at different UDP port numbers, they
> must all have the same behavior in order to use this specification.  I am
> open to imposing that requirement, but I don't think it's a requirement
> that exists in any RFC today.
>