Subject: [Add] Fwd: New Version Notification for draft-schwartz-svcb-dns-00.txt

From: Ben Schwartz <[email-masked]>
Date: Tue, 4 Aug 2020 13:53:54 -0400

Hi ADD and DPRIVE,

I've noticed three recent drafts that propose to use the SVCB format:
draft-mglt-add-rdp, draft-tapril-ns2, and
draft-pauly-add-resolver-discovery.  These drafts, across multiple
working groups, consider distinct use cases and architectures, but they all
propose using SVCB (in very different ways) to convey information about a
DNS server that supports encrypted transport.

In the interest of harmonizing these proposals, creating a solid
foundation, and separating concerns, I've written a short draft that
specifies _only_ a minimal SVCB mapping for DNS URIs*, and does not address
any specific use case.

I hope this draft can enable each of these proposals to focus more on their
goals, and worry less about the SVCB encoding.  (It also serves as an
interesting test of the SVCB design.)

Please review,
Ben Schwartz

*SVCB is based on URIs like https://, so for a DNS mapping we start with
dns:// URIs.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Aug 4, 2020 at 1:38 PM
Subject: New Version Notification for draft-schwartz-svcb-dns-00.txt
To: Benjamin Schwartz <[email-masked]>

A new version of I-D, draft-schwartz-svcb-dns-00.txt
has been successfully submitted by Benjamin Schwartz and posted to the
IETF repository.

Name:           draft-schwartz-svcb-dns
Revision:       00
Title:          Service Binding Mapping for DNS URIs
Document date:  2020-08-04
Group:          Individual Submission
Pages:          8
URL:
https://www.ietf.org/internet-drafts/draft-schwartz-svcb-dns-00.txt
Status:         https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/
Htmlized:       https://tools.ietf.org/html/draft-schwartz-svcb-dns-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-schwartz-svcb-dns

Abstract:
   The SVCB DNS record type expresses a bound collection of endpoint
   metadata, for use when establishing a connection to a named service.
   DNS itself can be such a service, when the server is identified by a
   hostname in a "dns:" URI.  This document provides the SVCB mapping
   for name-based DNS URIs, allowing DNS servers to indicate support for
   new transport protocols.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 4 Aug 2020 20:40:44 -0400

Moving DPRIVE and DNSOP to BCC to avoid cross-posting.

On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz <[email-masked]> wrote:

> I hope this draft can enable each of these proposals to focus more on
> their goals, and worry less about the SVCB encoding.  (It also serves as an

---

From: Steffen Nurpmeso <[email-masked]>
Date: Wed, 05 Aug 2020 16:36:04 +0200

[dropping the DNS only lists i am not subscribed to]

Ben Schwartz wrote in
 <CAHbrMsDtFNDB5TDz=HNejVi_RMbq_8Q6=o6iW_gyDr=[email-masked]>:
 |Hi ADD and DPRIVE,
 |
 |I've noticed three recent drafts that propose to use the SVCB format:
 |draft-mglt-add-rdp, draft-tapril-ns2, and
 |draft-pauly-add-resolver-discovery.  These drafts, across multiple

I do not want to be counterproductive, having read only one of
those drafts, and having read all of DNS except for zone transfer
related RFCs >15 years ago in order to create a caching stub
resolver, but i "like" DNS, and am fascinated of this protocol
that is in use for such a long time, and still scales and is
omnipresent.
-Today- Yesterday i have reread RFC 6763 and RFC 2782 and really
like all of it.  Is there a "benefit in changing established
practice".

  I never liked IDNA, i would have imposed a policy to rise the
  length limit by then, using UTF-8 (or UTF-7, maybe, as still in
  IMAP, though not have read the draft of v2 yet) and as of today
  i would presume all in-use name servers could serve those
  requests, aka even long domain names could be assigned all over
  the world.  Its version 2 introduced the incompatibilities that
  ought to be avoided.

I personally do not see an improvement in introducing yet another
RR in order to support this.  Maybe i should look in bind code or
so and test whether it would be harder to return the favoured or
desired set of RR combinations for a RR type or a question for
a specific SRV.  But even a clause that says "if that RR is
provided HTTPS transport is a MUST" does not justify that for me.
I.e., you could ask for "dnss://" and get A/AAAA for http[123]://
in combination also.  Of course SVCB is more explicit.  But

   o  Address a set of long-standing issues due to HTTP(S) clients
   not implementing support for SRV records, as well as due to
   a limitation that a DNS name can not have both CNAME and NS RRs
   (as is the case for zone apex names))

draft-jennings-http-srv never made it.  _https._tcp is no option
therefore as of today.  I really had to read the possibly one year
plus IETF discussion history on why this did not make it.

But i think the above is unfair, it misses the context.  I could
imagine they did not implement it because it is still unnecessary
as of today in practice, there is /etc/service or an equivalent,
and since port numbers are part of the standards the answer you
get by getservbyname(3) aka getservent(3), as of today, is
sufficient.  It comes from BSD 4.3 or even BSD 4.2 (commit by
Kirk McKusick dating 1985-05-15 says "manual page first
distributed with 4.2BSD", "+.TH GETSERVENT 3N "9 February 1983",
i did not look for code).

And, wow!, this is not far from 40 years!  And it still serves.

Also, HTTP is often accompanied with hypertext aka HTML++, where
URLs are a vivid part, so that special needs for port numbers
etc. can simply be fed into the machinery via href= etc. etc.  And
i think almost everybody who uses the web ("normal users") for
some time "has already seen" port numbers 80, 8080, and
increasingly 443 "sometime".  But especially the former two.

So i do not get your thing above at all.
If, with IPv6 and the IoT, the above does no longer SRV, then what
is missing to SRV, port etc it can all carry along.

  o  Provide an HSTS-like indication signaling for the duration of
  the DNS RR TTL that the HTTPS scheme should be used instead of
  HTTP (see Section 7.6).

I mean that can very well be bundled with anything that needs to
be implemented anew.  But sure, non-S is leaving.

  ...
   1.  Issue parallel AAAA/A and SVCB queries for the name HOST.

Maybe just another reason why this is not yet implemented widely
for such omnipresent things like HTTP.  But noone cares no more
about increasing packet sizes etc., so "just bundling" and getting
more in return without additional roundtrips is surely a nice
thing, EDNS is also 20 years or more.  Just like OCSP stapling
etc., it is just increasingly used (one more thing _i_ have to
do), whereas just a few years ago the additional cost of OCSP was
the reason it was not implemented in a widely used OSS HTTP
server (i use myself).

The draft also talks about "anticipating protocols", therefore
envisions simply replacing the established SRV with this new RR.
You know, i do not like TXT, being explicit is better, but then
again the TXT answers are standardized, so i guess that is ok.
It surely can serve another defined format for SRV.

...

For a different draft, i like the X.509 constraint option for the
"MUD" way of RFC 8520, to resolve the "refrigerator" hang of mine.
From a user point of view i like the idea that all devices
identify themselves "cryptographically save".  Even if all light
bulbs pass the very same client certificate along.  I could
imagine they contact my DHCP/DTLS server, and if i ok the
certificate further connections are allowed to invoke a dhcpcd
hook here, for example.  If the constraints are so that really
nothing more than an URL can be passed along, initiating "MUD" via
DHCP hook i can imagine.  Hard to believe the industry wants to
flood the world with tiny devices which cannot do D?TLS handshakes
aka present at least a X509 certificate.
Here i personally would be fine with just using a subjectAltName
addition or a defined nsComment content, these are available for
a long time.

I only wanted to add this.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Steffen Nurpmeso <[email-masked]>
Date: Wed, 05 Aug 2020 16:59:12 +0200

P.S.:

Steffen Nurpmeso wrote in
 <[email-masked]>:
 |[dropping the DNS only lists i am not subscribed to]
 ..
 |>From a user point of view i like the idea that all devices

I wrote "^From", it was silently and unwantedly converted (from
quoted-printable), and (needlessly) mangled via "From_"-quoting
along the way.

--steffen
|

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 5 Aug 2020 11:48:27 -0400

Thanks for your comments, Steffen.  The primary list for discussing SVCB is
DNSOP, so I would encourage you to direct most of your comments there.  A
few comments below.

On Wed, Aug 5, 2020 at 10:36 AM Steffen Nurpmeso <[email-masked]> wrote:
...

> RR in order to support this.

I think the need for SVCB is already well-motivated by other use cases, so
I see this the other way.  Several drafts in ADD have proposed new RR types
to convey this kind of information (in addition to those that suggest using
SVCB in different ways).  Reusing SVCB to convey DNS transport info might
reduce the need for additional RR types.

...

> Maybe i should look in bind code or
> a specific SRV.

Note that SVCB implementation is already under way in BIND (thank you BIND
authors!): https://gitlab.isc.org/isc-projects/bind9/-/issues/1132

...

> But even a clause that says "if that RR is
> in combination also.

I don't think using "dnss://" instead of "dns://" makes a significant
difference here.  Clients still need a way to discover metadata about the
server, such as which protocols it offers and how to access them.

---

From: Steffen Nurpmeso <[email-masked]>
Date: Thu, 06 Aug 2020 16:31:12 +0200

Ben Schwartz wrote in
 <[email-masked]>:
 ...
 |I think the need for SVCB is already well-motivated by other use cases, so
 |I see this the other way.  Several drafts in ADD have proposed new RR types
 |to convey this kind of information (in addition to those that suggest using
 |SVCB in different ways).  Reusing SVCB to convey DNS transport info might
 |reduce the need for additional RR types.
 |
 |...
 |
 |> Maybe i should look in bind code or
 |> so and test whether it would be harder to return the favoured or
 |> desired set of RR combinations for a RR type or a question for
 |> a specific SRV.
 |
 |Note that SVCB implementation is already under way in BIND (thank you BIND
 |authors!): https://gitlab.isc.org/isc-projects/bind9/-/issues/1132

..but interesting that supporting this requires adding contextual
information to be passed along the call chain which was not
necessary before.

 |...

--steffen
|

---

From: Eric Orth <[email-masked]>
Date: Fri, 7 Aug 2020 17:10:46 -0400

I like the idea overall, but can you further explain the decision to use
dns: URIs to describe DNS servers? Seems a bit funky since that URI scheme
is designed for DNS data, not a DNS server.  What we want here seems to
match more with just the optional "authority" section of a dns: URI.

Do we need a new URI scheme for DNS servers? Wasn't there a recent proposal
for that?

On Tue, Aug 4, 2020 at 8:41 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> On Tue, Aug 4, 2020 at 1:53 PM Ben Schwartz <[email-masked]
> <bemasc@google..com>> wrote:
>
>> Hi ADD and DPRIVE,
>>
>> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 9 Aug 2020 15:03:05 -0400

On Fri, Aug 7, 2020 at 5:11 PM Eric Orth <ericorth=
[email-masked]> wrote:

> dns: URIs to describe DNS servers?
>

I wouldn't say that's what's happening here.

The SVCB/HTTPS record describes a way to perform connection establishment
when attempting to retrieve a resource by its URI.  (Use of a URI with SVCB
is recommended but not required.)  The SVCB draft only defines a mapping
for "http://" and "https://" URIs; this draft provides the mapping for
"dns://".

For both "https://" and "dns://" URIs, SVCB serves the same function: the
URI provides an authority, and SVCB provides some information on how to
enhance your connection to that authority, in pursuit of the indicated
resource.  Ultimately, the client must want to access some resource (i.e.
an HTTP resource or a DNS record, indicated by the URI's path in both
cases), or there's no need to connect to the authority at all.

In truth, I don't think the "dns: URI" part is really important here; it's
mostly just a nice conceptual framework for the draft.  The real question
is: if we distribute information in this form, will it work well as a
component of the systems we're trying to build?

Seems a bit funky since that URI scheme is designed for DNS data, not a DNS
> server.  What we want here seems to match more with just the optional
> "authority" section of a dns: URI.
>

Yes; this is the SVCB design generally.  Note that the "authority" section
is also optional in "https" URIs.

> for that?

I believe those proposals are principally inspired by DNS Stamps
https://dnscrypt.info/stamps-specifications. With SVCB, the URI (normally)
identifies the authority by name, and the protocol is negotiated at
connection time.  With DNS Stamps, all protocol and connection parameters
are encoded into the URI itself.

I think the SVCB approach is more suitable for our purposes, because it
separates the simple, important question (who am I sending queries to?)
from the complicated, boring question (how do I perform connection
establishment?).  This is similar to HTTPS: I wouldn't want to encode QUIC
vs. TLS, or ECH public keys, into the HTTPS URI, where the info could get
out of sync or distract from the important question (who is the authority?).

>>> *SVCB is based on URIs like https://, so for a DNS mapping we start
>>> with dns:// URIs.
>>>
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-schwartz-svcb-dns/

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 10 Aug 2020 10:44:31 +1000

I wasn't going to respond and then I saw this...

On Mon, Aug 10, 2020, at 05:03, Ben Schwartz wrote:
> Note that the "authority" section is also optional in "https" URIs.

This is not true in any way I can discern.  Authority is mandatory in HTTP.

But then I realized that I don't like what this draft implies.

Eric's question is entirely fair. I also believe that that your response is accurate based on the definition of the dns: scheme.  RFC 4501 defines the authority component as optional, and uses it to indicate a resolver.  It's a little vague on this point, but it strongly implies that it refers to a recursive resolver.

This is deeply awkward, because it uses URI terms to imply that the zone is not the authority for the data provided.  That suits the SVCB usage perfectly here, but it completely breaks my conception of what authority in a URI is.  I hope that I'm not the only one.

My model for URIs says that there is an entity that controls a portion of the namespace established for the scheme.  That entity is identified by the authority component.  The authority gets to say whatever it likes about resources that exist in the part of the namespace it controls.

It would have been clearer for me if dns://example.com/ was tied to the QNAME and the authority were the authoritative server for the name.  

Authority == authoritative has a nice bit of symmetry.  And QNAME as authority would still allow dns:// URIs to be locators, but it would have only required either recursion or use of a recursive.  And you could authenticate the results with DNSSEC.  All very neat.  But that's not what RFC 4501 defines.

Resolver as authority is convenient for this particular use case, but it implies that the resolver somehow confers authority.  

That RFC 4501 fails to define a means of authenticating resolvers further undermines the utility of the scheme.

I'm inclined to suggest that we NOT use dns:// URIs.  Not because they aren't suitable - they fit surprisingly well to the use case - but because they are not good.

---

From: Eric Orth <[email-masked]>
Date: Mon, 10 Aug 2020 11:53:38 -0400

Clarification question: Is the draft intended for finding alternate DNS
servers given a query identifying one DNS server? Or is it intended as a
generalization of the proposals for finding a designated DNS server given
something like a webpage? Or both or more?

My reading of the draft was that it was targeting just the first, but from
your response and considering the three drafts referenced in your original
email, I'm thinking I may have read the intent too narrowly.

On Sun, Aug 9, 2020 at 3:03 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> Seems a bit funky since that URI scheme is designed for DNS data, not a
>> DNS server.  What we want here seems to match more with just the optional
> Do we need a new URI scheme for DNS servers? Wasn't there a recent
>> proposal for that?
>>
>
> https://dnscrypt.info/stamps-specifications. With SVCB, the URI
> (normally) identifies the authority by name, and the protocol is negotiated
> at connection time.  With DNS Stamps, all protocol and connection
> parameters are encoded into the URI itself.
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 10 Aug 2020 11:56:41 -0400

> This is not true in any way I can discern.  Authority is mandatory in HTTP.

You're right, at least in the IETF, RFC 7230 is pretty clear that authority
is mandatory.  It turns out I am the latest victim of the WHATWG vs. IETF
URI/URL debacle. See e.g.
https://jsdom.github.io/whatwg-url/#url=aHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ==&base=aHR0cHM6Ly9leGFtcGxlLmNvbS8=

...

> My model for URIs says that there is an entity that controls a portion of
> the namespace established for the scheme.  That entity is identified by the
> authority component.  The authority gets to say whatever it likes about
> resources that exist in the part of the namespace it controls.
>

I think you might be disappointed by a lot of the defined URIs, e.g.
"ldap", "xmpp", "nntp".  (Not that I necessarily disagree.)

...

> I'm inclined to suggest that we NOT use dns:// URIs.  Not because they
> aren't suitable - they fit surprisingly well to the use case - but because
> they are not good.
>

OK, I've removed the dependency on dns:// URIs and cut a new version:
https://tools.ietf.org/html/draft-schwartz-svcb-dns-01.

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 10 Aug 2020 13:01:56 -0400

On Mon, Aug 10, 2020 at 11:53 AM Eric Orth <ericorth=
[email-masked]> wrote:

> servers given a query identifying one DNS server?
>

Pretty much, yeah.

Or is it intended as a generalization of the proposals for finding a
> designated DNS server given something like a webpage? Or both or more?
>

This is intended as a reusable component for converting "domain name of a
DNS server" into "instructions for contacting that server over an encrypted
transport".  How you learned that domain name, and what you use it for, are
outside the scope of this draft.  My hope is that this component allows
various other proposals to focus on those questions, and to share at least
the syntax of the encrypted transport parameters for different use cases.

It seems like the emphasis on "dns://" URIs was a source of some confusion,
so I've rephrased the text to avoid that dependency.

>> I wouldn't say that's what's happening here..
>>
>> when attempting to retrieve a resource by its URI..  (Use of a URI with
>> SVCB is recommended but not required.)  The SVCB draft only defines a
>> mapping for "http://" and "https://" URIs; this draft provides the
>> mapping for "dns://".
>>
>> For both "https://" and "dns://" URIs, SVCB serves the same function:
>> the URI provides an authority, and SVCB provides some information on how to
>> In truth, I don't think the "dns: URI" part is really important here;
>> it's mostly just a nice conceptual framework for the draft.  The real
>> question is: if we distribute information in this form, will it work well
>> as a component of the systems we're trying to build?
>>
>> Yes; this is the SVCB design generally.  Note that the "authority"
>> section is also optional in "https" URIs.
>>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 10 Aug 2020 10:34:33 -0700

> On Aug 10, 2020, at 8:56 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> On Sun, Aug 9, 2020 at 8:45 PM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> You're right, at least in the IETF, RFC 7230 is pretty clear that authority is mandatory.  It turns out I am the latest victim of the WHATWG vs. IETF URI/URL debacle. See e.g. https://jsdom.github.io/whatwg-url/#url=aHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ==&base=aHR0cHM6Ly9leGFtcGxlLmNvbS8= <https://jsdom.github.io/whatwg-url/#url=aHR0cHM6L3NlZ21lbnQxL3NlZ21lbnQyP2tleT12YWx1ZQ==&base=aHR0cHM6Ly9leGFtcGxlLmNvbS8=>
>  
> ...
> I think you might be disappointed by a lot of the defined URIs, e.g. "ldap", "xmpp", "nntp".  (Not that I necessarily disagree.)
> 
> ...
> OK, I've removed the dependency on dns:// URIs and cut a new version: https://tools.ietf..org/html/draft-schwartz-svcb-dns-01 <https://tools.ietf.org/html/draft-schwartz-svcb-dns-01>.

Thanks for making that update. I think this tightens up the scope of the proposal well. The use of the SVCB record for the DNS scheme makes sense, and this seems like the right building block to use.

Best,
Tommy
> 
> 
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
> -- 
> Add mailing list
> [email-masked]

---

From: Eric Orth <[email-masked]>
Date: Mon, 10 Aug 2020 14:25:34 -0400

Thanks for the new version.  Much better without relying on the dns: URI
scheme.

I would suggest taking the removal of dns: even further and just deleting
section 7 ("Relationship to DNS URIs").  The relationship is now that
they're just not related at all and I think any attempt to explain it can
only be more confusing than valuable.

But now that the draft is not rooted in another reference for naming, I
think the draft needs a bit more explanation on where the name comes from,
further expanding on section 3 ("Name form").  Most DNS servers currently
in use are known only by an IP address rather than a queryable name.  Need
text explaining how a name can be created for such servers or specifying
that _dns cannot be queried for them.  Also, I think we should set an
expectation for how the name corresponds with DNS servers that do have a
naturally queryable name from the DNS query URL, eg most DoT and DoH
servers.  Should we set the expectation that it will work if an
implementation takes a known DoT/DoH URL and tacks on the "_dns." prefix?

On Mon, Aug 10, 2020 at 1:34 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

>
>
> On Aug 10, 2020, at 8:56 AM, Ben Schwartz <
> bemasc=[email-masked]> wrote:
>
>
>
> You're right, at least in the IETF, RFC 7230 is pretty clear
> that authority is mandatory.  It turns out I am the latest victim of the
> WHATWG vs. IETF URI/URL debacle. See e.g.
> https://tools.ietf..org/html/draft-schwartz-svcb-dns-01
> <https://tools.ietf.org/html/draft-schwartz-svcb-dns-01>.
>
>
> Thanks for making that update. I think this tightens up the scope of the
> proposal well. The use of the SVCB record for the DNS scheme makes sense,
> and this seems like the right building block to use.
>
> Best,
> Tommy
>
>
>
>> --
>> Add mailing list
>> [email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2020 11:25:48 -0700

Howdy,

I don't have a problem with this draft removing dns: URIs, but I do have
some comments on Martin's issues below.

On Sun, Aug 9, 2020 at 5:45 PM Martin Thomson <[email-masked]> wrote:

> Eric's question is entirely fair. I also believe that that your response
> is accurate based on the definition of the dns: scheme.  RFC 4501 defines
> the authority component as optional, and uses it to indicate a resolver.
> It's a little vague on this point, but it strongly implies that it refers
> to a recursive resolver.
>
>
This is deeply awkward, because it uses URI terms to imply that the zone is
> not the authority for the data provided.  That suits the SVCB usage
> perfectly here, but it completely breaks my conception of what authority in
> a URI is.  I hope that I'm not the only one.
>
>
> resources that exist in the part of the namespace it controls.
Unusually, RFC 4501 actually has a usage model set out in the document,
which describes how the  scheme is intended to be used (Section 2
<https://tools.ietf.org/rfc/rfc4501.html#section-2>).  The second paragraph
of that is pretty clear on the basic model:

   The URI scheme described in this document focuses on the data stored
   in the DNS.  As such, there is no provision to specify any of the
   fields in the actual DNS protocol.  This is intended so that the URI
   may be used even in situations where the DNS protocol is not used
   directly.  Two examples for this are zone file editors and DNS-
   related configuration files, which may use this URI scheme to
   identify data.  The application would not use the DNS protocol to
   resolve the URIs.

This is reinforced in Section 3:

   Intended usage: Whenever it is useful for DNS resources to be
   referenced by protocol-independent identifiers.  Often, this occurs
   when the data is more important than the access method.  Since
   software in general has coped without this so far, it is not
   anticipated to be implemented widely, nor migrated to by existing
   systems, but specific solutions (especially security-related) may
   find this appropriate.

The authority section is optional, but permitted, in this scheme for use in
cases where a specific hostname and port are to be accessed to retrieve the
data.  Even when those are supplied, the presumption remains that the
reference is to data as stored in the DNS.  The normal DNS chain of
delegation applies, and the hostname and port  have no necessary
relationship to the zone maintainer for the DNS delegation of the zones
related to the named data.   I have seen these used in the wild to
reference resources in a split DNS context where only the "internal"
resolver would have access to specific parts of the DNS, but even that
doesn't change the base model, which still presumes that the reference is
to the data stored whether or not it is currently accessible to you.

RFC 3986 says this in it discussion of the authority component:

   Many URI schemes include a hierarchical element for a naming
   authority so that governance of the name space defined by the
   remainder of the URI is delegated to that authority (which may, in
   turn, delegate it further).

I suspect this is the source of your discomfort.  But that use of the
hierarchical element is not the only use, as further reading in the
description of "host" would make clear.  There are cases where it is
intended to be the host you connect to and not the controller of a
subsidiary namespace.  Most of those cases, like telnet, have no subsidiary
namespaces,  but some, like XMPP,  allow references to resources expected
to be distinct from the server named in the authority (note that XMPP URIs
also have optional authorities).  There are also many cases where the URL
scheme references a namespace controlled elsewhere.   An example you may
remember is the skype scheme, where a phone number is permitted; skype
clearly is not the namespace authority for E164 numbers but it has the
ability to use them in its functioning.

It would have been clearer for me if dns://example.com/ was tied to the
> QNAME and the authority were the authoritative server for the name.
>
> As noted above, that would not have met some of the use cases desired.

> Authority == authoritative has a nice bit of symmetry.  And QNAME as
> authority would still allow dns:// URIs to be locators, but it would have
> only required either recursion or use of a recursive.  And you could
> authenticate the results with DNSSEC.  All very neat.  But that's not what
> RFC 4501 defines.
>
> Resolver as authority is convenient for this particular use case, but it
> implies that the resolver somehow confers authority.
>

I think it would be fairer to say that its use case and the one you are
concerned with overlap but are not congruent.  RFC 4501 presumes that you
are concerned with the data in the DNS, and it provides you a
protocol-agnostic way of referencing that.  You can use it to refer to the
DNS data required to do a DNSSEC validation; that is within scope even if
not one of the examples.  But it not only does not imply that the resolver
confers authority, it does not even imply which resolution method you are
using to get at the data.

regards,

Ted Hardie

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 11 Aug 2020 11:34:04 +1000

On Tue, Aug 11, 2020, at 04:25, Ted Hardie wrote:
> I suspect this is the source of your discomfort.  

Yep.

> But that use of the hierarchical element is not the only 
> use, as further reading in the description of "host" would make clear.  

I'm not picking up on anything there.  Care to point to it?  Interpreting this particular document has never been easy.

> There are cases where it is intended to be the host you connect to and 
> not the controller of a subsidiary namespace.

Skype doesn't appear to use the authority form, so that isn't relevant here.  But delegating to E.164 as part of a scheme is entirely reasonable.  (In this regard, I'm curious as to why tel: is not tel://; the syntax would seem to fit reg-name.)  The XMPP usage is a stronger example, so I guess it's good for my argument that it's now a defunct protocol.  telnet:// clearly indicates a resource with a clear authority, even if it can't be authenticated.  (The same might be said for ssh:// if the 2006 secsh draft is representative; and for vnc://, both of which fit your model here.)

> As noted above, that would not have met some of the use cases desired.

I personally see negative utility in those use cases, but I appreciate that others have those use cases.

> concerned with overlap but are not congruent.  

This is a fine conclusion :)

> But it not only does not imply that 
> the resolver confers authority, it does not even imply which resolution 
> method you are using to get at the data.  

That is clearly true for the definition of the scheme.  I still believe that it is a bad idea to define a scheme that way.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Aug 2020 19:08:49 -0700

On Mon, Aug 10, 2020 at 6:34 PM Martin Thomson <[email-masked]> wrote:

> I'm not picking up on anything there.  Care to point to it?  Interpreting
> this particular document has never been easy.
>
>
   The presence of a host subcomponent within a URI does
   not imply that the scheme requires access to the given host on the
   Internet.  In many cases, the host syntax is used only for the sake
   of reusing the existing registration process created and deployed for
   DNS, thus obtaining a globally unique name without the cost of
   deploying another registry.  However, such use comes with its own
   costs: domain name ownership may change over time for reasons not
   anticipated by the URI producer.

This implies to me that there are times when the scheme require access to a
given host for the relevant protocol operations.

> Skype doesn't appear to use the authority form, so that isn't relevant
> here.  But delegating to E.164 as part of a scheme is entirely reasonable.
> (In this regard, I'm curious as to why tel: is not tel://; the syntax would
> seem to fit reg-name.)  The XMPP usage is a stronger example, so I guess
> it's good for my argument that it's now a defunct protocol.

I prefer beer to bait, thanks.

best,

Ted

telnet:// clearly indicates a resource with a clear authority, even if it
> can't be authenticated.  (The same might be said for ssh:// if the 2006
> secsh draft is representative; and for vnc://, both of which fit your model
> here.)
>
> > > It would have been clearer for me if dns://example.com/ was tied to
> the QNAME and the authority were the authoritative server for the name.
> > >
> That is clearly true for the definition of the scheme.  I still believe
> that it is a bad idea to define a scheme that way.
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Aug 2020 21:47:37 -0700

On 8/10/2020 7:08 PM, Ted Hardie wrote:

> This implies to me that there are times when the scheme require access
> to a given host for the relevant protocol operations.

Not really. Supposes the Zoo of Example starts a registry of wild beasts
under net.zoo:, but then following some kind of name ownership dispute
the "zoo.net" domain gets transferred to the Zoo of Another Example.
Under the previous regimen, Zoo of Example had the authority to decide
whether "shipworm" could be registered in this zoo registry. Post
transfer, the Zoo of Another Example acquires that authority. It could
also change pre-existing registrations, and decide that "bigfoot" does
not belong there anymore.

-- Christian Huitema

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Aug 2020 09:48:52 -0700

Howdy,

On Mon, Aug 10, 2020 at 11:12 PM Christian Huitema <[email-masked]>
wrote:

> This implies to me that there are times when the scheme require access to
> a given host for the relevant protocol operations.
>
>
> under net.zoo:, but then following some kind of name ownership dispute the "
> zoo.net" domain gets transferred to the Zoo of Another Example. Under the
> previous regimen, Zoo of Example had the authority to decide whether
> "shipworm" could be registered in this zoo registry. Post transfer, the Zoo
> of Another Example acquires that authority. It could also change
> pre-existing registrations, and decide that "bigfoot" does not belong there
> anymore.
>
>
> I think perhaps I wasn't clear, so maybe a slightly different take will
help.  If you go back to RFC 1738 and look at some of the earliest
registered schemes, there are a number where the clear intent of the
authority is to name a specific network host at which an operation will
take place (ftp and gopher, for example).  There's also an interesting
split in news and nntp (sections 3.6 and 3.7), where news provides you a
reference to a newsgroup or message article that is location independent
and nntp provides a location-specific reference.  This distinction is
called out in RFC 1738.

The DNS scheme provides the ability to make a reference that is location
independent (and resolution independent).  It also provides the ability to
turn that reference into a location specific reference.  The first form has
no authority; the second form does. The second form doesn't reflect a
different authority.  Just like news and nntp share newsgroup names and
message ids, the two forms both refer to the data stored in the DNS.  One
simply provides a location specific version of the same reference.

regards,

Ted