Subject: Re: [Add] draft-schwartz-svcb-dns-01

From: Daniel Migault <[email-masked]>
Date: Tue, 1 Dec 2020 18:04:41 -0500

Thanks for the response. Please see additional information / comment
inline.

Yours,
Daniel

On Mon, Nov 30, 2020 at 2:57 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Wed, Nov 25, 2020 at 5:10 PM Daniel Migault <[email-masked]>
> wrote:
>
>> Hi,
>>
>> Please find my comments below for draft-schwartz-svcb-dns-01
>>
>
> Thanks for the detailed review.
>
> Yours,
>> Daniel
>>                 Service Binding Mapping for DNS Servers
>>                        draft-schwartz-svcb-dns-01
>> [...]
>>
>> 1.  Introduction
>>
>>    The SVCB record type [SVCB] provides clients with information about
>>    how to reach alternative endpoints for a service, which may have
>>    improved performance or privacy properties.
>>
>> <mglt>
>> It is unclear to me if "alternative"
>> means "various flavors of DNS resolvers"
>> or if it assumes the previous knowledge
>> of one flavor of the resolver. I do not
>> believe the latest is appropriated.
>>
>
> This is a general summary of SVCB.  When using SVCB, there is a single
> logical "service" that can be accessed via different "endpoints".  I'm not
> sure what you mean by "flavor", but SVCB assumes that the service's
> behavior does not greatly depend on which endpoint you use to access it.
>
> <mglt>
Maybe I am using unappropriated language, but I see the dns resolution
service as being declined into different "flavors" or "(sub) services" like
Do53, DoH, DoT.  But I think my question was regarding the term
"alternate". It i sunclear if alternate hee means "different" or if they
are taking the place of something in which case who they are taking the
place to.
 </mglt>

</mglt>

> The input of a SVCB query is a FQDN, and
>> that FQDN is not necessarily related to
>> a Do53 resolver for example. It could
>> typically an entry point used to
>> discover all different flavors of DNS
>> resolvers. Assuming a previous knowledge
>> of one resolver seems to preclude some
>> assumption on the FQDN, which seems
>> independent from the description of SVCB
>> fro DNS.
>> </mglt>
>>
>
> Sorry, I'm still not understanding, possibly because I do not understand
> the idea of a "flavor".  The draft assumes a DNS server (or "service")
> identified by a domain name, with Do53 service available via A and AAAA
> records for that name (if a Do53 service exists, which seems likely to be
> common but is not required).
>

<mglt>
It seems to me that the draft considers as the entry point the FQDN
associated to the Do53 server, that is in your example below.
resolver.example is the Do53 service and requesting resolver.example/AAAA
will give me the IP address I need to send the DNS requests to.

  $ORIGIN example.
         _dns.resolver 7200 IN SVCB 1 resolver (
           alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} )
         _dns.resolver 7200 IN SVCB 2 resolver (
           port=8530 echconfig=... )
         _dns.resolver 7200 IN SVCB 3 fooexp.resolver ( port=5353
           echconfig=... alpn=foo no-default-alpn foo-info=... )

If my understanding is correct, there are two questions I am wondering:

1) Why do we mandate that the input of the SVCB query - in your example
resolver.example - needs to be associated to the Do53 server. I do not
think that should be in the specification as mandatory and and would
consider this as simply good to know.

I do see the following hierarchy:
DNS resolution
      v                    v                      v
DoH resolvers  DoT resolvers, Do53 resolvers
      v                          v                      v
IPs,                      IPs,                 IPs

In this case I would consider the  _dns.example, _53._dns.foo,
_853._dns.foobar .. as services.

A request for all DNS servers associated to the FQDN example would be
_dns.example
A request for all DoT servers associated to the FQDN foorbar would be
_853._dns.foobar
A request for all Do53 servers associated to the FQDN foo would be
_53._dns.foo

I seems to me that a request for foo AAA is configured to return the IP
addresses of one server under _53._dns as a feature to provide some sort of
retrocompatibility with legacy Do53 resolvers but it seems unclear to me
why this should be required.

Just to make myself clear, I do see the FQDN example as representing the
input for searching the various available services. an example is then - at
least to me - different than the FQDN associated to the terminating Do53
server.  Having them equal is "nice" if we want to provide a FQDN to a
device that may do requests of type SVCB or AAAA. Unless I am missing
something, it seems that legacy devices take an IP address - not an FQDN -
and so we do not need to have such compatibility with legacy devices.

2) I am wondering how Do53 server are represented in SVCB. It seems to me
that different Do53 DNS server may still be offered with different
SvcParameters and so should be listed with SVCB RRsets. In addition, I
would favor Do53 is explicitly mention so that went it is not deployed, the
DNS client can actually knows this explicitly.

</mglt>

>
> The service is
>>    identified by a "scheme" indicating the service type, a hostname, and
>>    optionally other information such as a port number.  A DNS server is
>>    often identified only by its IP address (e.g. in DHCP), but in some
>>    contexts it can also be identified by a hostname (e.g.  "NS" records,
>>    manual resolver configuration).
>>
>> <mglt>
>> I like the paragraph, but I believe it
>> might help the reader to add that DNS
>> servers can be authoritative or resolver
>> which are quite common term. I am
>> wondering however, if there are any
>> reasons for not mentioning them.
>>
>> </mglt>
>>
>
> This is a deliberate omission: this draft is concerned only with DNS as a
> protocol, not with the types of queries and responses that are encoded.  In
> principle, this SVCB mapping can be applied independently of whether the
> server is authoritative for any names, or supports recursion.
>
<mglt>
Ok so that is an editorial choice. I am wondering though, if that would be
a nosense to have a SvcParameter saying whether the end point is a
resolver, authoritative, forwarder - either here or somewhere else.

</mglt>

>
>
>>    Names are formed using Port-Prefix Naming ([SVCB] Section 2.3).  For
>>    example, a DNS server with the name "dns1.example.com", listening
>>    (unusually) on non-default port number 5353, would be represented as
>>    "_5353._dns.dns1.example.com.".
>>
>> <mglt>
>> While this seems conform to the SVCB
>> spec ;-) I would have envisioned the
>> port number prefix as designating the
>> service rather that actual port on which
>> the service is run. Typically in Do53
>> would be designated as _53._dns and if
>> that service is run on port 5353 I would
>> expected the number being provide by the
>> port SvcParameter.
>>
>
> The port SvcParam is also supported, but its meaning is different.  The
> port prefix identifies the service.  The port SvcParam provides the
> location of the alternative endpoint.
>
<mglt>
This seems to be my understanding. , but then "_5353._dns.dns1.example.com."
seems to me misleading as 5353 represents while the text mentions the
server is listening to an unusual port. My expectation was that a DNS
server was listening on 5353 instead of 53. From my understanding of the
text I would have expected to have 5353 in the SvcParameter.
I think more text is needed here to disambiguate the signification of the
port. Currently what we designate as the port does not seem to be the port.
I would expect some clarification on where the port is defined.
</mglt>

>
> One specific reason for doing so is that
>> the unconventional port cannot be
>> guessed without previous knowledge.
>>
>
> If the client has not been specifically informed that the service's
> identity contains an unconventional port, it will assume the default port
> (53), and query for SVCB records at _dns.$SERVER_NAME (no port prefix).
> Each SVCB record returned may contain a port SvcParamKey indicating where
> to find that alternative service endpoint.
>
<mglt>
This requires so two entries _dns.${server} and _5353._dns.${server} -
probably CNAMed. I think the notation is mixing service and implementation
of the service, and I am wondering if there are any reasons we need to do
that here in this spec.

Similarly, it seems to me that the convention to have port 53 as a default
port is a convention that is specified in this document and that we could
define it otherwise. If so, given that the service can be DoT, DoH, DoQ. I
am wondering why couldn't we define _dns as the service abstraction of DNS
that could be declined in DoT, DoH Do53.... without precluding a default
port.

I also believe that the port needs to explicitly mention how the port value
is handled in _port._dns
</mglt>

>
> I believe that some specific convention
>> should considers that _dns may designate
>> the DNS service including all flavors.
>>
>
> As above, I don't understand what is meant by a "flavor".
>
<mglt>
flavor meant to me DoT, DoQ, DoH, Do53...
</mglt>

>
>
>>    This key is used to indicate the target port for connection.  If
>>    omitted, the client SHALL use the default port for each transport
>>    protocol: 853 for DNS over TLS and 443 for DNS over HTTPS.
>>
>> <mglt>
>> I have the impression some text is needed to define how the transport is
>> determined.
>> I favor that port is being specified in
>> this field as opposed to in the prefix.
>> I also believe that the port number
>> should not be defined at two distinct
>> places.
>>
>
> These two port numbers have separate meanings: the prefix is an "input"
> identifying the service, and the SvcParam is an "output" that locates the
> endpoint.
>
> <mglt>
I agree, what I was trying to say is that the default port is defined from
the transport, but the text does not indicate how transport is derived. I
suppose that a reference to the alpn section could be added as well as an
order in which the parameters needs to be looked at.
</mglt>

> It seems that the default values depends
>> on other SvcParameters - alpn or absence
>> of it.
>>
>
> Correct: in this draft, there is no single default value for "port".
> Instead, in the absence of a specified port, each transport uses its own
> default port.  This enables a single SVCB record to represent both DNS over
> TLS on port 853 and DNS over HTTPS on port 443, as in the draft's first
> example:
>
>          _dns.resolver 7200 IN SVCB 1 resolver alpn=h2,h3 echconfig=...
> dohpath=/dns-query{?dns}
>
> (This example enables DNS over TLS on port 853 implicitly.)
>
> We could change default behavior for "port", but it would likely make
> typical usages more verbose.
>
<mglt>
I am fine with this, this matches my understanding.
</mglt>

>
>    This key is automatically mandatory if present.
>>
>> <mglt>
>> I might be missing some context here,
>> but the latest sentence is a bit hard
>> for me to understand.
>>
>> The condition " if present" seems
>> contradicting the term "mandatory". I
>> cannot figure out also what
>> automatically mandatory means.
>>
>> </mglt>
>>
>
> Yes, "automatically mandatory" is a specific term from the SVCB draft:
> https://tools.ietf.org/html/draft-ietf-dnsop-svcb-https-02#section-7.
> I've added a cross-reference for clarity:
> https://github.com/bemasc/svcb-dns/commit/535df722c9404413020af34d3d0e7209e3a206c1
>
>
>>
>> <mglt>
ok, will look at it.
</mglt>

> 4.2.  alpn and no-default-alpn
>>
>>    These keys indicate the set of supported protocols.  The default
>>    protocol is "dot", indicating support for DNS over TLS [DOT].
>>
>>    If the protocol set contains any HTTP versions (e.g. "h2", "h3"),
>>    then the record indicates support for DNS over HTTPS [DOH], and the
>>    "dohpath" key MUST be present (Section 5.1).  All keys specified for
>>    use with the HTTPS record are also permissible, and apply to the
>>    resulting HTTP connection.
>>
>> <mglt>
>> I believe the text may specify the
>> absence of alpn means DNS over UDP.
>>
>
> If the "alpn" key is absent, the default is "dot".
>
>
>> I am
>> unsure whether no-default-alpn means
>> that alpn key is omitted or not, but if
>> that is the case, it does not seem
>> necessary to introduce its designation.
>>
>
> The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is not
> supported".  If the "alpn" key is then omitted, the record is useless/null:
> it indicates no supported protocols at the alternative endpoint, so no
> client will ever attempt to make use of that record.
>
>
<mglt>
I think some text could be added to specify the meaning of no-default-alpn
in the context of this spec.

I am wondering in light of comments provided earlier, if one could not
consider alpn mandatory and when omitted meaning Do53. This would remove
the need to define no-default and include Do53 as a potential service.
</mglt>

> Instead it might be clear enough to
>> mention the alpn default value considers
>> DNS over UDP.
>>
>
> This draft does not currently offer any way to describe a DNS over UDP
> alternative endpoint.
>
<mglt>
I think I start seeing this, but I am still not convinced this is
appropriated to consider Do53 as different from other services.
</mglt>

>
> It also worth mentioning that alpn needs
>> to be parsed before port and potential
>> dohpath.
>> </mglt>
>>
>
> I expect that a client would parse a record completely before attempting
> to make use of it, so I'm not concerned with this dependency.
>
<mglt>
Parsing was maybe inappropriate, but I would say start looking at alpn
before looking at port.
</mglt>

>
> 4.3.  Other applicable SvcParamKeys
>>
>>    These SvcParamKeys apply to the "dns" scheme without modification:
>>
>>    *  echconfig
>>
>>    *  ipv4hint
>>
>>    *  ipv6hint
>>
>> <mglt>
>> not sure we need this section as the
>> document is limited on the DNS
>> transport.
>>
>
> Yes, this is perhaps redundant.  We could instead adjust the wording in
> the SVCB draft to indicate that these keys are assumed to be broadly
> applicable.  However, I don't think it hurts to remind the reader of other
> keys that they can use in this context.
>
> I am however wondering if we should
>> distinguish between authoritative and
>> resolver.
>>
>
> This draft is not intended to be specific to one server role or the
> other.  This is noted in Section 6.
>
> <mglt>
>> I am wondering if ther is any room for
>> searching specifically doh server by
>> requesting:
>>
>> _443._dns.resolver 7200 IN SVCB 1 resolver (
>>            alpn=h2,h3 echconfig=... dohpath=/dns-query{?dns} )
>>
>> If that is not the case, it seems we
>> should clarify this.
>> The same case occurs with DoT, Do53.
>>
>> The advantage would be that it enables
>> to narrow down the search and prevents
>> the search of non supported transports.
>>
>
> This is an interesting idea, but the SVCB framework does not support this
> approach.  With SVCB, the client sends a request that describes a logical
> service, and receives an RRSet of alternative endpoints covering all the
> service's supported protocols.
>
<mglt>
I understand that _443._dns does not represent DoH for example. but instead
a service DNS can could (eventually) be DoT.   In other words, with
standard ports _443._dns does not exist.
I am wondering if this a choice we make - and that could be otherwise - or
if there are a higher philosophy that makes us take this path - from
svcb-https. If so, and for clarification, I am wondering if the definition
of DoH as a service would require the definition of _doh for example. I do
not necessarily thinks here this is a good idea.

One thing that remains unclear to me is the relation between URL scheme and
service. Currently the port indicate sthe protocol (DoT, DoH,  ) which
makes it difficult to have DoT on port 6777. I am wondering how this
matters.
<mglt>

>
> The downside is that it requires some
>> synchronization between SVCB RRsets and
>> when multiple supports are supported by
>> one client multiple queries may be
>> performed. It also may require to define
>> some preference across SVCB RRsets over
>> multiple domains.
>>
>
> Personally, I expect that servers will typically implement only a small
> number of protocols (at most ~4), and clients will often support more than
> one, so transferring the entire configuration in a single RRSet seems
> likely to be more efficient overall than issuing multiple queries.
>
> <mglt>
One aspect that I have not seen in the spec is the SVCB 0 and I expect this
to be used to delegate to third parties that will host multiple instances
of the service. What I think my increase the size of the number of service
instances is the services associated to the DNS resolution service.

</mglt>

> </mglt>
>>
>> 9.  Security Considerations
>>
>> 9.1.  Adversary on the query path
>>
>>    This section considers an adversary who can add or remove responses
>>    to the SVCB query.
>>
>>    Clients MUST authenticate the server to its name during secure
>>    transport establishment.  This name is the hostname used to construct
>>    the original SVCB query, and cannot be influenced by the SVCB record
>>    contents.
>> <mglt>
>> I understand that after the SVCB
>> exchange, the DNS client sets a TLS
>> session with the DNS server. I think
>> this is only valid when TLS is
>> supported and Do53 woudl not fit in this
>> category.
>>
>
> Yes.  This draft does not provide a way to describe a Do53 alternative
> endpoint.
>
> It sounds to me difficult to have a
>> requirement that says, when a https
>> server supports https the session must
>> be authenticated.
>>
>
> I'm not sure I understand.  Authenticated transport is a requirement for
> HTTPS.
>
<mglt>
I do not think it is possible not to authenticate either, so it might not
be necessary to require such authentication. It is a nit.
</mglt>

>
>
>> I am tempted to say
>> that the https server should not serve
>> non secure sessions. On the other hand,
>> one can also envisioned the case where
>> a given IP/FQDN is shared by DoH and
>> Do53, which makes such assumption
>> difficult.
>> Unless I am missing something, it sounds
>> to me the MUST statement is difficult to enforce.
>>
>
> This section is only meant to tell clients to perform SSL certificate
> validation in the usual way.
>
>
>> I think it is good to specify what name
>> must be present in the certificate.
>> Though what is unclear to me is why the
>> name should be the one of the query as
>> opposed as the one in the RDATA.
>>
>
> The RDATA is potentially untrusted.  In the absence of DNSSEC, an
> intermediary could rewrite the RDATA to contain any name.
>
<mglt>
I think the reasoning should be provided with a recommendation as it
assumed the input is provided in a trusted way and that DNSSEC is not
enabled.
</mglt>

>
> I understand the text as saying that
>> connecting to fooexp.resolver.example, the
>> certificate should have
>> resolver.example.
>>
>
> Correct.
>
>
>> If that is correct,
>> and unless I am missing something, I
>> would be more inclined to authenticate
>> fooexp.resolver.example.
>> One case I see is an ISP delegating to a
>> DNS resolver provider - like akamai. It
>> should rather let the user authenticate
>> akamai than the ISP hostname. Other
>> scenario could ignore the hostname and
>> use a footprint or the entire
>> certificate.
>> Of course this would require DNSSEC.
>>
>> It seems such recommendation is limited
>> to the case when DNSSEC is not used and
>> when the SVCB name is provisioned in a
>> trusted manner.
>>
>
> Yes.  However, the service provider does not know that the name was
> provisioned insecurely, and it does not know that the client is validating
> DNSSEC, so it has to include the service name in its certificate.  Since
> all service providers will place the service name in the certificate,
> clients should check for this name, regardless of whether they validate
> DNSSEC.
>

<mglt>

Unless I am missing something, it seems to me the responsibility of the DNS
client to perform the appropriated checks. If the service provider is
resolver.com, it's responsibility seems limited to serve the request it
receives.
The responsibility of the DNS client is to make sure there is a trusted
delegation to the provider. That the service name isp.resolver is in the
certificate is only one way to do so and put the constraints too high on
the service provider - in my opinion. I would add this as a recommendation.

A typical use case may be a resolver redirecting to public resolvers.
</mglt>

>
>
>> If an attacker is likely
>> to update the SCVB content, he might
>> potentially have provided the false
>> entry to initiate the SVCB query, in
>> which case there may not be any need to
>> update the SVCB parameters.
>>
>> I believe the primary recommendation should be
>> to use DNSSEC and then consider the very
>> specific use case where DNSSEC cannot be
>> used with a trusted SVCB entry.
>> </mglt>
>>
>
> This draft's approach to authentication is inherited from SVCB, which
> similarly does not rely on DNSSEC.  In both cases, I think the current
> drafts are taking the best approach.  In many or most of the anticipated
> applications, DNSSEC is not widely deployed, and we do not need it in order
> to deploy SVCB securely.
>
<mglt>
I do not believe that seems appropriated in the scope of DNS to explicitly
not consider DNSSEC not being used. The application is question is the
discovery of resolvers and there is no specific reasons it does not
implement DNSSEC. Though I admit it is unclear to me why the browser
industry is so reluctant to DNSSEC.
</mglt>

>
>    Although this adversary cannot alter the authentication name of the
>>    server, it does have control of the port number and "dohpath" value.
>>    As a result, the adversary can direct DNS queries for $HOSTNAME to
>>    any port on $HOSTNAME, and any path on "https://$HOSTNAME", even if
>>    $HOSTNAME is not actually a DNS server.  If the DNS client uses
>>    shared TLS or HTTP state, the client could be correctly authenticated
>>    (e.g. using a TLS client certificate or HTTP cookie).
>>
>>    This behavior creates a number of possible attacks for certain server
>>    configurations.  For example, if "https://$HOSTNAME/upload" accepts
>>    any POST request as a file upload, the adversary could forge a SVCB
>>    record containing "dohpath=/upload", causing the client to upload
>>    every query, resulting in unexpected storage costs.
>>
>>    As a mitigation, a client of this SVCB mapping MUST NOT provide
>>    client authentication for DNS queries, except to servers that it
>>    specifically knows are not vulnerable to such attacks.  Also, if an
>>    alternative service endpoint sends an invalid response to a DNS
>>    query, the client SHOULD NOT send more queries to that endpoint.
>>
>> <mglt>
>> The attack is limited to DoH and DoT is
>> not concerned.
>>
>
> Correct.
>
> This attack is targeting the https
>> server, but in general the motivation
>> for the client to authenticate the
>> server is to protect its privacy. It
>> seems this should be added or clarified.
>> </mglt>
>>
>
> OK, I've added an explanation of why this is privacy-relevant and
> strengthened the recommendation:
> https://github.com/bemasc/svcb-dns/commit/e311a4e94edd67e17724e693ad2038396fba8b4f
>

-- 
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 2 Dec 2020 16:26:50 -0500

> are taking the place of something in which case who they are taking the

The word "alternative" here means "in addition to some default".  You're
right that it's not strictly necessary for there to be a default, but
presumably a default will be present when adding SVCB to any use case
that already exists, because existing clients will not support SVCB.

> associated to the Do53 server, that is in your example below.

I agree: that's how it's described, and I expect that to be the main use
case.

> resolver.example - needs to be associated to the Do53 server.
>

I don't think the draft contains such a mandate, but I do think that's
likely to be true in most use cases.

> I do not think that should be in the specification as mandatory and and
> would consider this as simply good to know.
>

In SVCB's terminology, these are all endpoints of a single service, which
is defined by its ability to provide access to particular information.
These endpoints all represent the same service because they all provide the
same DNS behavior.  The choice of transport is hidden behind an abstraction
barrier: a DNS client does not care which transport is used, so the
transport can be selected independent of the query.  Just as the HTTP
content layer doesn't care whether the transport is HTTP/1.1, HTTP/2, or
HTTP/3, the DNS content layer doesn't care whether the transport is DoT,
DoH, etc.

> A request for all Do53 servers associated to the FQDN foo would be

This is a conceivable design, but it is not the design considered by SVCB.
I prefer the SVCB approach (a single query returns all options), which
seems conceptually and operationally simpler.

> why this should be required.

It is not required by this draft, but it is a common case, and may be
required in some use cases.  For example, authoritative DNS servers are
already identified in NS records by a name that resolves to the IPs of the
port 53 service.  If SVCB-for-DNS is applied there in some fashion,
backwards compatibility will require that Do53 service remain available on
the IPs for that name.

> and so we do not need to have such compatibility with legacy devices.

There are a variety of client types with different compatibility
requirements.  For example, Android phones allow the user to enter the
hostname of a DNS-over-TLS server, which the phone will resolve to an IP
and connect on port 853.  For backwards compatibility with that mode of
deployment, port 53 service is not required, but A/AAAA records (and port
853 TLS service on those IPs) are required.

This draft does not attempt to lay out all the compatibility requirements
for each potential use case.  It merely describes the format used for the
SVCB records, and leaves most of the questions of how they can be deployed
to other drafts (such as DEER).

2) I am wondering how Do53 server are represented in SVCB.

In the current draft, they are not.  The only way to use Do53 is when a
compatible SVCB record is not available.

> It seems to me that different Do53 DNS server may still be offered with
> different SvcParameters and so should be listed with SVCB RRsets.
>

This is a possible design, but I would prefer to avoid including Do53.
Do53 is not a secure or privacy-preserving transport, which makes it
radically different from DoT, DoH, DNS over QUIC, etc.  Just as SVCB does
not support insecure HTTP, I think it makes sense to avoid adding support
for insecure DNS transport.

When a service is identified by name, I think we should be ensuring that we
are actually communicating with the named service.  With Do53, we have no
ability to do this.  In some configurations, allowing Do53 in SVCB would
create a security vulnerability.

In addition, I would favor Do53 is explicitly mention so that went it is
> not deployed, the DNS client can actually knows this explicitly.
>

I don't think this is necessary.  The draft already says:

   A client that attempts a connection using an encrypted DNS transport
   from a SVCB record SHOULD NOT fall back to unencrypted DNS if
   connection fails.

(https://tools.ietf.org/html/draft-schwartz-svcb-dns-01#section-9.2)

Therefore, the existence of a Do53 service is typically irrelevant to
SVCB-enabled clients when SVCB records are present: they will not use it,
whether or not it exists.

</mglt>
</mglt>

I think that is a possibility, but I don't see an immediate need for it, so
I haven't defined such a SvcParamKey.  In every existing use case, the
client already knows whether it is going to set the "recursion desired" bit
in its queries.  If we find a use case that requires such an indication, we
can extend the mapping at that time.

> I would expect some clarification on where the port is defined.

OK, I've attempted to clarify that we are speaking here about the port
number that identifies the service, as opposed to the port number used to
connect to the alternative endpoint:
https://github.com/bemasc/svcb-dns/commit/fb867ece57236028b8e78496429ef50f3100f1cb

> probably CNAMed.

The second entry would only exist if the operator has been advertising
${server}:5353 as a DNS service.  If this service is equivalent to the
service at ${server}:53, then the operator could simply publish a CNAME as
you describe.  However, if the two ports operate differently (e.g. with
different behaviors or policies), then they would need separate sets of
alternative endpoints.

> I think the notation is mixing service and implementation of the service,
> and I am wondering if there are any reasons we need to do that here in this
> spec.
>

I view this as clearly separating the identity of the service from its
implementation.  The service is identified by a hostname and a port number
(encoded in the QNAME), and its implementation is located by a hostname and
a port number (the TargetName, port=...).  These hostnames and port numbers
can be the same or different; they are independent.

> that could be declined in DoT, DoH Do53.... without precluding a default

I'm not sure I understand this, but the draft is indeed designed so that
the vast majority of operators will never need to use a port prefix name or
a port SvcParam.  An explicit port prefix is only needed when the DNS
service is identified by a non-default port number, and an explicit port
SvcParam is only needed when operating an alternative endpoint on a
non-default port number.

> is handled in _port._dns

I don't think I understand this question.

> the transport, but the text does not indicate how transport is derived.
>

OK, I've swapped the "alpn" and "port" sections so that the reader learns
how transports are selected before encountering that concept in the "port"
section (
https://github.com/bemasc/svcb-dns/commit/02c0c474bedab28f892d535a40a095fc3367ea52
).

> I suppose that a reference to the alpn section could be added as well as
> an order in which the parameters needs to be looked at.
> </mglt>
>

...

>> The default ALPN is "dot", so "no-default-alpn" means "DNS over TLS is
>> not supported".  If the "alpn" key is then omitted, the record is
>> useless/null: it indicates no supported protocols at the alternative
>> endpoint, so no client will ever attempt to make use of that record.
>>
>>
> <mglt>

I'd rather not duplicate the explanation of these keys, but I've added a
cross-reference to the original source:
https://github.com/bemasc/svcb-dns/commit/4c7509333b7d1279c6f59b1fd80531712e1010a0

> the need to define no-default and include Do53 as a potential service.

I think that would be possible, if we want to support insecure transports.

> Parsing was maybe inappropriate, but I would say start looking at alpn

I don't think there's a clear ordering requirement there.  A compliant
client must inspect both keys, and could do so in either order.

> I understand that _443._dns does not represent DoH for example. but
> instead a service DNS can could (eventually) be DoT.   In other words, with

I think we are trying to build a machine that takes three inputs -- (1) a
service identity, (2) a set of alternative endpoints, and (3) the client's
capabilities -- and arranges a successful connection.

1. The DNS service identity consists of a hostname and (very rarely) a port
number.
2. Each alternative endpoint consists of a hostname, a port number (often
default), various transport layers (DoT, DoH, HTTP/2, HTTP/3, etc.), and
potentially other parameters (e.g. echconfig)
3. The client's capabilities include the set of supported transports, the
set of supported protocols within those transports, and possibly other
relevant capabilities (e.g. ECH)

In SVCB, the client sends (1) in the QNAME, gets back (2), and applies (3)
locally to identify an optimal connection.

In your proposal, the client would send (1) and also part of (3) in the
QNAME, get back a subset of (2), and then apply any remaining filtering
locally.  That would work too, but I think it's more complicated.  It also
creates tricky possibilities for skew: operators would need to be careful
when changing their records, because changes are no longer atomic.

> makes it difficult to have DoT on port 6777. I am wondering how this

Yes, in my view you would need a QNAME that contains "_dns", "_dot", the
hostname, and the identifying port number (if non-default port number
identities are supported).

> One aspect that I have not seen in the spec is the SVCB 0 and I expect
> this to be used to delegate to third parties that will host multiple
> instances of the service. What I think my increase the size of the number
> of service instances is the services associated to the DNS resolution
> service.
>
> </mglt>
>

For these purposes I think SVCB 0 is the same as a CNAME, but at the apex
name.  Delegation is already possible with CNAME; SVCB 0 just allows the
use of shorter service names.

> be necessary to require such authentication. It is a nit.

Yes, the point of this sentence is only to identify the name used for
authentication: the service name, not the TargetName.

I am tempted to say
> assumed the input is provided in a trusted way and that DNSSEC is not

I don't think that's true.  The draft only assumes that the input _might_
be provided in a trusted way, and DNSSEC _might_ not be enabled.

> Unless I am missing something, it seems to me the responsibility of the
> DNS client to perform the appropriated checks.
>

Yes, but the client and server need to agree on what those checks are
_before_ they start communicating, so the standards need to tell them what
to do.

If the service provider is resolver.com, it's responsibility seems limited
> to serve the request it receives.
>

Note that the request it receives will be on a TLS connection whose SNI
indicates the original DNS service name.

> the service provider - in my opinion. I would add this as a recommendation.

The use case you are describing is equivalent to a standard HTTPS CDN (and
indeed may be an HTTPS CDN when the transport is DoH).  In this case, just
as in HTTPS, the CDN must present a certificate that is valid for the
customer's identity.  It is not enough for the customer to CNAME their name
to the CDN, because the CDN cannot assume that all customer zones are
signed and all stub resolvers are DNSSEC-validating.  (In fact, almost none
are.)

> </mglt>

I think the idea of "redirection" is interesting here.  SVCB is not a
"redirection" mechanism.  It provides alternative endpoints for the _same_
service; it does not redirect the user to a different service.  As such,
unlike HTTP 301, the client continues to validate the service's original
identity, regardless of which endpoint it is talking to.

> not consider DNSSEC not being used.
>

To be clear, nothing in this draft recommends against the use of DNSSEC.
DNSSEC might even be required for some future standards that use this
format, e.g. when using it in combination with DANE authentication.

The application is question is the discovery of resolvers and there is no
> specific reasons it does not implement DNSSEC. Though I admit it is unclear
> to me why the browser industry is so reluctant to DNSSEC.
> </mglt>
>

As long as there is little deployment of validating stub resolvers, it
should not be surprising that new drafts do not assume the opposite.  RFC
8027 lays out some of the common reasons why stub resolvers cannot enforce
DNSSEC validation.  (I would add performance considerations: the latency
cost of followup queries to chase the DNSSEC chain is considerably higher
for client devices (e.g. phones on GSM wireless) than for recursive
resolvers.)

However, I do think that SVCB for DNS can have a positive impact on DNSSEC
deployment via a mechanism like DEER.  By enabling clients to use encrypted
DNS, we can avoid the network problems that prevent stub resolvers from
relying on DNSSEC.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 4 Dec 2020 13:22:34 -0500

Hi Ben,

Thanks you very much for the responses and clarifications. I also agree
that some points raised are a bit out of scope of the URI resolution as I
tended to read the draft as more generic to the usage of SVCB in the
context of _dns. These clarification are however useful for me and
thank you for taking the time to respond.

Yours,
Daniel

> This is a conceivable design, but it is not the design considered by
> SVCB.  I prefer the SVCB approach (a single query returns all options),
> which seems conceptually and operationally simpler.
>
> When a service is identified by name, I think we should be ensuring that
> we are actually communicating with the named service.  With Do53, we have
> no ability to do this.  In some configurations, allowing Do53 in SVCB would
>>> This is a deliberate omission: this draft is concerned only with DNS as
>>> a protocol, not with the types of queries and responses that are encoded.
>>> In principle, this SVCB mapping can be applied independently of whether the
>> Ok so that is an editorial choice. I am wondering though, if that would
>> be a nosense to have a SvcParameter saying whether the end point is a
> I think that is a possibility, but I don't see an immediate need for it,
> so I haven't defined such a SvcParamKey.  In every existing use case, the
>> This seems to be my understanding. , but then "_5353._
>> dns.dns1.example.com." seems to me misleading as 5353 represents while
>> the text mentions the server is listening to an unusual port. My
>> expectation was that a DNS server was listening on 5353 instead of 53. From
>> my understanding of the text I would have expected to have 5353 in the
>> SvcParameter.
> I also believe that the port needs to explicitly mention how the port
>> value is handled in _port._dns
>>
>
>>>> I have the impression some text is needed to define how the transport
>>>> is determined.
>> I agree, what I was trying to say is that the default port is defined
>> from the transport, but the text does not indicate how transport is derived.
>>
>
>> I think some text could be added to specify the meaning of
>> no-default-alpn in the context of this spec.
>>
>
>>> This is an interesting idea, but the SVCB framework does not support
>>> this approach.  With SVCB, the client sends a request that describes a
>>> logical service, and receives an RRSet of alternative endpoints covering
>>> all the service's supported protocols.
>>>
>> <mglt>
>> I am wondering if this a choice we make - and that could be otherwise -
>> or if there are a higher philosophy that makes us take this path - from
> 1. The DNS service identity consists of a hostname and (very rarely) a
> port number.
> One thing that remains unclear to me is the relation between URL scheme
>> and service. Currently the port indicate sthe protocol (DoT, DoH,  ) which
> If the service provider is resolver.com, it's responsibility seems
>> limited to serve the request it receives.
>>
>
>> I do not believe that seems appropriated in the scope of DNS to
>> explicitly not consider DNSSEC not being used.
>>
>

-- 
Daniel Migault
Ericsson