Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

From: Brian Dickson <[email-masked]>
Date: Thu, 8 Nov 2018 09:30:44 +0700

I'm going to start a clean, related thread, to discuss a bunch of
questions, that I think can help with the ongoing threads.

Rationale:
I think many of the viewpoints some folks have are skewed by pre-existing
familiarity with the protocol, and implementations (including browsers,
libraries, stubs, forwarders, resolvers, and authorities, plus "specials").

What we may be forgetting are the USERS of these systems, and the use
cases. These matter both in terms of their diversity in their technical
savvy, but also in terms of their respective numbers.

We can sometimes forget that registered domains (the entry point right
below the 'public suffix' level in the domain name system) number in the
100s of millions, and the user base is global.

Starting right from that point, it's safe to say that the vast majority of
registrants are not operating their own authority servers and editing zone
files.

This means that they are doing something else, and they are not all doing
one single "something else", either; it is a mixed bag with no dominant
"pie slice".

Why not SRV?
There are a number of reasons that SRV is not in widespread use, that have
to do with the mixed bag of ways those 100s of millions of registrants
operate their domains.

Even if registrants use systems that expose SRV to them to configure, as an
RRtype, the other parts of SRV are not at all novice-friendly. From the
wikipedia page:

_service._proto.name. TTL class SRV priority weight port target

This isn't at all friendly. The alternative is to put all of the above into
some kind of UI. But again, this puts several more roadblocks on uptake *by
users*. Regardless of the interface, the values need to be supplied, and
the input needs to be validated, with the ability for the user to
understand error messages and fix the input. There is no short cut for
understanding the values, and knowing about _service and _proto. If the
user doesn't get it right the first time, they are very likely to give up,
since there are so many variables. For HTTP as a use case, it is far too
complex.

In other words, SRV is really only suitable for a tiny fraction of the
registrants. For them, there's still a learning curve, but they have a need
that only SRV can fill, and an incentive to do so. Those are typically
enterprises, large institutions, entities with actual IT staff.

Yes, resolvers and authority software do SRV already, that isn't the point.

If you are an SRV proponent, here's my recommendation: Find someone you are
acquainted with, who doesn't have any DNS familiarity, show them CNAME and
SRV, and ask them for their opinions. Please.

Why is CNAME so abundantly used?
If we look at CNAME, it is much simpler, and probably one of the first
things anyone doing DNS every plays with.
(But even then, it isn't completely trivial, given the trailing dot problem
that pretty much everyone gets wrong at some point in their DNS career.)
Even for a novice: there is only one "variable", and lots of information
and advice on CNAMEs can be found online. The learning curve is gentle and
short.

Why not CNAME?
The secondary issue with CNAME isn't just the apex issue, it is the
non-coexistence issue (of which apex is merely the poster child).

Why a new RRtype?
Here's the TL;DR: on these issues, IMNSHO: browser vendors won't do stuff
that isn't really in widespread use, even if it is possibly easy to
implement. SRV isn't ever going to be truly widespread, as a percentage of
domains.

We want a solution that is easy to deploy, easy to understand, easy to use,
SOLVES THE COEXISTENCE PROBLEM, and doesn't change the primary rules on
"stupid DNS tricks", i.e. that the tricks are client-oriented by way of the
resolver (or possibly client-subnet).

This leads to the only logical outcome that is implementable, doesn't
require more than five minutes for any user to understand, doesn't require
(but supports optional) changes to resolvers, doesn't require any change to
authority serving beyond new RRtype(s), and thus can/will get brower
support (simply by the numbers): HTTP.

Why should HTTP be so simple?
Because it is simple to use.
It looks just like a CNAME.
It can chain with CNAMEs and DNAMEs.
It works with stupid DNS tricks.
It gets the job done.
It is a common denominator.
That is a feature, not a bug.

Why service-specific?
As Ray points out, MX is already there as a service-specic RRtype.
Other service-specific RRtypes may be needed, and new RRtypes are easy to
get now.
(Perhaps we can anticipate what some of those are, and include those in the
draft?)

Brian

---

From: p vixie <[email-masked]>
Date: Wed, 7 Nov 2018 18:38:24 -0800 (PST)

If additional data is optional, so most resolvers can just pass it through, the DNS techs will say yes but the HTTP techs will say no.

----- Original Message -----
From: Brian Dickson <[email-masked]>
Sent: 2018-11-07 - 18:30
To: "[email-masked] WG" <[email-masked]>
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Nov 2018 03:00:22 +0000

> If additional data is optional, so most resolvers can just pass it through, the DNS techs will say yes but the HTTP techs will say no.

We have a bad track record of predicting what other groups will want from the DNS or use it for. Specifying what "HTTP techs" will say seems premature before a fully-fleshed proposal is taken to them.

--Paul Hoffan

---

From: Dan York <[email-masked]>
Date: Thu, 8 Nov 2018 03:06:38 +0000

Brian,

> On Nov 8, 2018, at 9:30 AM, Brian Dickson <[email-masked]> wrote:
> 
> I'm going to start a clean, related thread, to discuss a bunch of questions, that I think can help with the ongoing threads.

DY> Thank you for doing so.

> What we may be forgetting are the USERS of these systems, and the use cases. These matter both in terms of their diversity in their technical savvy, but also in terms of their respective numbers.

DY> This was something I was trying to capture in https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view <https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view> - I definitely welcome comments, feedback and text from others.

> Starting right from that point, it's safe to say that the vast majority of registrants are not operating their own authority servers and editing zone files.

DY> Thomas Peterson did some great data gathering on this point. From a previous message:

>  I took the Alexa top 1 million websites and queried for A* and CNAME against the www records for the top 10 000 domains. What I found is that approximately 44% returned CNAME records, 56% returning A records.  (his code is at https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649 <https://gist.github.com/thpts/eb5cec361867170a0ffd6ede136c6649> )

DY> I played with his data from the top 10K Alexa users and the majority of those CNAMEs looked like they were going to CDNs of different sorts.  Plus, a sizable portion of the A* records are probably cases where the CDNs are also DNS hosting operators and so they are returning to the clients the A* records *after* doing their CDN lookups to point people to the best CDN edge server. (Using one of the various DNS techniques here - or other database techniques.)

> Why not SRV?
> There are a number of reasons that SRV is not in widespread use, that have to do with the mixed bag of ways those 100s of millions of registrants operate their domains.
> 
> Even if registrants use systems that expose SRV to them to configure, as an RRtype, the other parts of SRV are not at all novice-friendly. From the wikipedia page:
> _service.._proto.name <http://proto.name/>. TTL class SRV priority weight port target
> 
> This isn't at all friendly. The alternative is to put all of the above into some kind of UI. But again, this puts several more roadblocks on uptake by users. Regardless of the interface, the values need to be supplied, and the input needs to be validated, with the ability for the user to understand error messages and fix the input. There is no short cut for understanding the values, and knowing about _service and _proto. If the user doesn't get it right the first time, they are very likely to give up, since there are so many variables. For HTTP as a use case, it is far too complex.

DY> Additionally, *at the current time*, the user is typically told by their CDN provider to just "point your domain to <long-CDN-address>" under the assumption that the user is doing a CNAME. The CDN wants to keep it as simple as possible to reduce the possibility of user errors entering the info.  

DY> This is not to say the CDN couldn't tell the user the other info for priority, weight, port, etc.  They could. And I am sure they *would* if that was the only or best way to configure the records.

DY> But from a technical support point of view, the fewer pieces of info you have to give to the end user, the fewer chances are that they will screw it up when entering the data with the DNS operator. Which means happier customers and fewer technical support calls.

DY> The *design* of SRV offers great flexibility and power. But with greater power comes greater deployment configuration issues.

> If you are an SRV proponent, here's my recommendation: Find someone you are acquainted with, who doesn't have any DNS familiarity, show them CNAME and SRV, and ask them for their opinions.. Please.

+1

> If we look at CNAME, it is much simpler, and probably one of the first things anyone doing DNS every plays with.

DY> Yes.

> Why not CNAME?
> The secondary issue with CNAME isn't just the apex issue, it is the non-coexistence issue (of which apex is merely the poster child).

DY> Agreed.

> This leads to the only logical outcome that is implementable, doesn't require more than five minutes for any user to understand, doesn't require (but supports optional) changes to resolvers, doesn't require any change to authority serving beyond new RRtype(s), and thus can/will get brower support (simply by the numbers):

DY> This to me is a good design statement.

> HTTP.

DY> A good summary, although the counterpoint I can see from the SRV/URI side is that those records are already out there and supported in the existing DNS infrastructure. 

DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still massively distributed and decentralized (even though we do have ongoing centralization/consolidation), getting a new RRTYPE deployed means:

- upgrading all the authoritative servers to support the new RRTYPE
- upgrading all the *provisioning software* at the thousands of DNS registries, DNS registrars, DNS hosting operators to support the new RRTYPE
- upgrading the *millions* of recursive resolvers to know what to do they receive the new RRTYPE in a query response

DY> A group of us wrote about these issues in https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06 <https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-06> and while that was talking about deploying new DNSSEC crypto algorithms, the situation is very similar for new RRTYPEs.

DY> Which is NOT to say we should NOT do a new RRTYPE.  I can see many of the benefits of HTTP.

DY> But it is to say that deployment will take a lllllllllooooooooooooonnnnnnnnnnnnnggggggggggggg time.

DY> Which does means we do need to get started NOW ... but it also means that it will be a significant number of years before it is widely available and deployed. (But if we don't start, of course, it will never happen.)

DY> (And even if were to decide to change the behavior of CNAME, for instance, to allow it to co-exist at the apex, it would take a long time for that support to roll out into the millions of recursive resolvers.)

DY> I'm just pointing out that the counter-argument FOR the use of SRV/URI is that they are out there now and would not have the same significant deployment lag. (But they still have the same user deployment issues I mentioned above.)

> Other service-specific RRtypes may be needed, and new RRtypes are easy to get now. 
> (Perhaps we can anticipate what some of those are, and include those in the draft?)

DY> Let's keep any drafts simple and focused on a single RRTYPE.  We need RFCs to be as easy as possible for someone to *understand* and then *implement*.

Thanks for bringing this all together,
Dan

--
Dan York
Director, Content & Web Strategy, Internet Society
[email-masked]   +1-802-735-1624 
Jabber: [email-masked]  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Brian Dickson <[email-masked]>
Date: Thu, 8 Nov 2018 10:30:58 +0700

On Thu, Nov 8, 2018 at 10:06 AM Dan York <[email-masked]> wrote:

> Brian,
>
> DY> Upgrading our DNS infrastructure is VERY difficult. Because it is
> still massively distributed and decentralized (even though we do have
> ongoing centralization/consolidation), getting a new RRTYPE deployed means:
>
> - upgrading all the *provisioning software* at the thousands of DNS
> registries, DNS registrars, DNS hosting operators to support the new RRTYPE
> - upgrading the *millions* of recursive resolvers to know what to do they
> receive the new RRTYPE in a query response
>
>
Actually, for this specific case, the only places that require support (at
least initially) are:

   - Authority servers (because, duh), unless they already support it, via
   hard-coded types and RDATA generically (maybe not overly relevant, but
   covering all cases)
   - Authority provisioning systems for DNS hosting services (at least one
   hosting service has to do so before the type is "live") (also possibly
   supported by the hard-coded mechanism?)
   - Clients (because someone has to request the new type)

For new RRtypes, registries, registrars, and their provisioning services do
NOT need to support them; the new types are in the zones only.
New RRtypes which do not require any "additional" processing, do NOT
strictly speaking require resolver support, since resolvers handle unknown
RRtypes. (Mark A can quote you the RFC, and I think has recently.)

On the plus side, I can confirm at least one hosting/authority service will
do this as soon as a stable spec is available (i.e. HTTP and a code point
early allocation).

That should take what, a couple of weeks or so?

It'd be nice to ask the browser folks to start using something that is
already deployed (however small the initial user base is, with the
expectation of viral uptake.)

> DY> Which does means we do need to get started NOW [...]
>

You're welcome, and thanks for participating in the discussion.

Brian

---

From: Dan York <[email-masked]>
Date: Thu, 8 Nov 2018 04:47:49 +0000

Brian,

> On Nov 8, 2018, at 10:30 AM, Brian Dickson <[email-masked]> wrote:
> 
> For new RRtypes, registries, registrars, and their provisioning services do NOT need to support them; the new types are in the zones only.

DY> (Experiencing a "DUH!" moment.)  Yes, of course. It's zone data so only those entities handling zone data need to care.  In my still-annoyingly-jet-lagged mind, I made the classic mistake of equating "registrars" with "DNS hosting operators" because so many registrars are *also* DNS hosting providers.

> New RRtypes which do not require any "additional" processing, do NOT strictly speaking require resolver support, since resolvers handle unknown RRtypes. (Mark A can quote you the RFC, and I think has recently.)

DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar to the CNAME record, my assumption would be that resolver software would need to know what to do once it receives the record.  For that reason, wouldn't all the resolvers (or at least an extremely high %) need to be upgraded to support the new record?

> On the plus side, I can confirm at least one hosting/authority service will do this as soon as a stable spec is available (i.e. HTTP and a code point early allocation).

DY> :-)   Good to know!

Dan

---

From: Ray Bellis <[email-masked]>
Date: Thu, 8 Nov 2018 11:56:03 +0700

On 08/11/2018 11:47, Dan York wrote:

> For that reason, wouldn't all the resolvers (or at least an extremely high %) need to be upgraded to support the new record?

They don't _have_ to be, but performance is improved when they are 
(since only an upgraded resolver will include the A and AAAA answers in 
the additional section).

The critical path is the browsers, since none of this works unless they
start looking up the HTTP record.

As a transition mechanism, site operators would still need to publish 
their existing A and AAAA records by whatever means they currently do 
(even if that's e.g. a CNAME flattening on the authority server).

Ray

---

From: Brian Dickson <[email-masked]>
Date: Thu, 8 Nov 2018 12:04:35 +0700

On Thu, Nov 8, 2018 at 11:47 AM Dan York <[email-masked]> wrote:

> > For new RRtypes, registries, registrars, and their provisioning services
> do NOT need to support them; the new types are in the zones only.
>
> DY> (Experiencing a "DUH!" moment.)  Yes, of course. It's zone data so
> only those entities handling zone data need to care.  In my
> still-annoyingly-jet-lagged mind, I made the classic mistake of equating
> "registrars" with "DNS hosting operators" because so many registrars are
> *also* DNS hosting providers.
>
>
No problem - it's very easy to mix up the pure math relationships "one to
one" and "onto". (Don't try to, BTW, my brain still hurts from 3rd year
pure math in 1986.)

> DY> Ah, interesting. Where the proposed HTTP RRtype has behavior similar
> to the CNAME record, my assumption would be that resolver software would
> need to know what to do once it receives the record.  For that reason,
> wouldn't all the resolvers (or at least an extremely high %) need to be
> upgraded to support the new record?
>
>
Yes and no. It requires EITHER the resolver OR the client to handle the
name it gets back, and do another query for A/AAAA on that, for whatever
the client originally was looking for.
I.e. an upgraded client (e.g. browser) could bootstrap the system prior to
widespread resolver upgrades.
Resolver upgrades would lower their own load, by making the parallel/serial
re-queries un-necessary.
Thus, it puts at least a modest incentive on resolvers to upgrade.

It's kind of like DIY CNAME, except for only one iteration. (If you do a
lookup on a name for A or AAAA, and the name is a CNAME-only thing in DNS,
resolvers handle that already.)
So, if the resolver is upgraded, it would return the HTTP answer plus A and
AAAA records.
If the resolver was not upgraded, it would return just the HTTP answer (an
FQDN), and the client would have to ask for A and/or AAAA records at that
name. (The resolver would still handle the chaining if the FQDN was a
CNAME.)

NB: client stub OS libraries for getaddrinfo return lists of A, AAAA, or
both, depending on the AF_* parameter (AF_INET, AF_INET6, AF_ANY). Those
might be multiple (parallel, possibly) DNS queries, but the API-calling
code would be simple enough.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Thu, 8 Nov 2018 16:12:11 +1100

> On 8 Nov 2018, at 2:30 pm, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> Actually, for this specific case, the only places that require support (at least initially) are:
> 	• Authority servers (because, duh), unless they already support it, via hard-coded types and RDATA generically (maybe not overly relevant, but covering all cases)
> 	• Authority provisioning systems for DNS hosting services (at least one hosting service has to do so before the type is "live") (also possibly supported by the hard-coded mechanism?)
> 	• Clients (because someone has to request the new type)

It's RFC 1034 and RFC 1035.  AKA STD 13.

The only components that have *ever* needed upgrading for a new type from the very beginning for a where the authoritative servers for the zone as they needed to be able to load the record. Recursive servers and stub resolvers where all supposed to treat unknown record types and blobs of data.  DNS records are named TVLs, name compression was only every valid on well known types and the only possible well known types are those listed in STD13.  Anything that dropped or blocked unknown types was not STD 13 compliant.

RFC 3597 reduced the list of components that needed to be updated to NONE though it was still desirable to update the primary server and provisioning systems.

RFC 1034

   3. General lookup function

      This function retrieves arbitrary information from the DNS,
      and has no counterpart in previous systems.  The caller
      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
      matching RRs.  This function will often use the DNS format
      for all RR data instead of the local host's, and returns all
      RR content (e.g., TTL) instead of a processed form with local
      quoting conventions.

When the resolver performs the indicated function, it usually has one of
the following results to pass back to the client:

   - One or more RRs giving the requested data.

     In this case the resolver returns the answer in the
     appropriate format.

   - A name error (NE).

     This happens when the referenced name does not exist.  For
     example, a user may have mistyped a host name.

   - A data not found error.

     This happens when the referenced name exists, but data of the
     appropriate type does not.  For example, a host address
     function applied to a mailbox name would return this error
     since the name exists, but no address RR is present.

It is important to note that the functions for translating between host
names and addresses may combine the "name error" and "data not found"
error conditions into a single type of error return, but the general
function should not.  One reason for this is that applications may ask
first for one type of information about a name followed by a second
request to the same name for some other type of information; if the two
errors are combined, then useless queries may slow the application.

> It'd be nice to ask the browser folks to start using something that is already deployed (however small the initial user base is, with the expectation of viral uptake.)
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 8 Nov 2018 10:16:55 +0100

> questions, that I think can help with the ongoing threads.

<snip "change is hard">

So, if we just invent something that can be whacked into a TXT record, all will be fine? 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
On the road, ZIPPY is a pinhead without a purpose, but never without a POINT.

---

From: Tony Finch <[email-masked]>
Date: Thu, 8 Nov 2018 18:27:02 +0000

Ray Bellis <[email-masked]> wrote:
> > For that reason, wouldn't all the resolvers (or at least an extremely high
> > %) need to be upgraded to support the new record?
>
> They don't _have_ to be, but performance is improved when they are (since only
> an upgraded resolver will include the A and AAAA answers in the additional
> section).
>
> As a transition mechanism, site operators would still need to publish their
> existing A and AAAA records by whatever means they currently do (even if
> that's e.g. a CNAME flattening on the authority server).

The transition mechanism is really important if zone publishers are going
to use HTTP records. It needs to be automated and invisible to the web
site admin. If you require people to provide both a target hostname and
the corresponding addresses, you are making it too hard. You aren't
removing the friction caused by the restrictions on CNAMEs.

At the moment the options for setting up 3rd party hosting are:

  * Just use address records. Lots of places prefer this because it
    always works, at the cost of less flexible static server setup.

  * Use a CNAME for www and address records for the bare domain. Maybe the
    address records refer to a server that is more limited in some way
    than the CNAME target (no geoIP, just a redirector, ...)

HTTP RRs risk adding a third option, where the web provider has to have
documentation asking whether the DNS provider supports HTTP RRs and if so
the site admin needs both these addresses and this hostname. And the
addresses can't refer to a redirector, so this thord option opens a new
trap for the unwary.

What I would like is to eliminate the wrong choices on the DNS provider
side of things, so that the web site admin can provide a target hostname
which will work on any name, just like they can with address records.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole: Cyclonic 5 to 7, becoming southerly or southwesterly 7 to
severe gale 9. Very rough or high. Rain or showers. Good, occasionally poor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 9 Nov 2018 07:13:47 +1100

> On 9 Nov 2018, at 5:27 am, Tony Finch <[email-masked]> wrote:
> 

The providers that use CNAME add HTTP to that description and say to add HTTP
at the zone apexes or anywhere else another record is published at the same name.  

> which will work on any name, just like they can with address records.

Providers that synthesis A and AAAA records using proprietary methods just add the
HTTP record as a complementary record.

Providers that use CNAME at the apex set the CNAME TTL to 0 and add HTTP along side
the CNAME.  This will allow them to be able to see which clients support HTTP if they
wish.  HTTP lookups needs to be made *before* A and AAAA lookups get the HTTP records
into the resolver’s cache.

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Nov 2018 00:14:01 +0000

> On 8 Nov 2018, at 20:13, Mark Andrews <[email-masked]> wrote:
> 
>> the site admin needs both these addresses and this hostname.
> 

[ I think you mean “web providers” here, i.e., not us. ] But remember: the goal is to make the DNS easier to use for people who don’t know about the restrictions on CNAMEs. Any time we say, “oh, those other people need to to explain things at greater length to make our stuff easier to use”, we are not solving the problem. The end goal is to simplify documentation used by non-experts that deals with 3rd party web providers and 3rd party DNS providers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Ray Bellis <[email-masked]>
Date: Fri, 9 Nov 2018 07:57:35 +0700

On 09/11/2018 07:14, Tony Finch wrote:
> But remember: the goal is to make the DNS easier to use for people
> who don’t know about the restrictions on CNAMEs.

I'd say the goal is to make the DNS *possible* to use for people who
don't know about the restrictions on CNAMEs.

I concede that ANAME perhaps makes that easier than HTTP does, but it 
does so at the expense of significant complexity in authority servers by 
still requiring A and AAAA lookups to be somehow "magic", and doesn't 
fix the architectural problem of lack of a service identifier.

My long-term goal would be to never have an A or AAAA record appear in 
the DNS other than at the owner name of an actual hostname.

Ray

---

From: Paul Vixie <[email-masked]>
Date: Thu, 08 Nov 2018 18:30:41 -0800

> don't know about the restrictions on CNAMEs.

i regret not adding ANY as an RR type (not just a Q type) back when the 
DNS was small and i supported 90% of it. what we actually needed is a 
wildcard on types so that if there's no more-specific type you get that 
one, which would have an rdata of the target name, but act like PTR 
(which the DNS requester has to follow) rather than like CNAME (which 
the recursive has to follow.)

> fix the architectural problem of lack of a service identifier.

i am loath to create per-service record types. that's why SRV. if you 
really want every client of a service to query for something other than 
AAAA/A, can you try to fix what's wrong with SRV regarding wildcards, 
but avoid a new type code for every new thing like MX and HTTP as they 
come along in the decades to follow? also, does SSH count as a service? 
what about FTP? Gopher? RSync? NNTP? IMAP(S)? it may not be too late to 
think architectural thoughts like "what will the internet engineering 
community think, 50 years from now, that we should have done for them?"

> the DNS other than at the owner name of an actual hostname.

i don't think you mean "actual". anycasted addresses act like host 
addresses in all ways (answering UDP, answering TCP SYN, answering ICMP) 
but are not "actual" hosts. i think i know what you _mean_ here and if 
so i agree with that. but 1.1.1.1 answers both HTTPS and DNS, and would 
surely get an AAAA and A in your model, but is not a "host", and its DNS 
owner would not be a "hostname". perhaps you mean "effective host" which 
could be real or virtual?

-- 
P Vixie

---

From: Ray Bellis <[email-masked]>
Date: Fri, 9 Nov 2018 09:54:15 +0700

On 09/11/2018 09:30, Paul Vixie wrote:

> i regret not adding ANY as an RR type (not just a Q type) back when 
> the DNS was small and i supported 90% of it. what we actually needed
>  is a wildcard on types so that if there's no more-specific type you
>  get that one, which would have an rdata of the target name, but act
>  like PTR (which the DNS requester has to follow) rather than like 
> CNAME (which the recursive has to follow.)

interesting... :)

> really want every client of a service to query for something other
> than AAAA/A, can you try to fix what's wrong with SRV regarding
> wildcards, but avoid a new type code for every new thing like MX and
> HTTP as they come along in the decades to follow?

Creating per-service record types is the IAB's preferred option (per RFC
5507).

Is fixing wildcards for SRV even possible without a major forklift 
upgrade to the DNS?

> also, does SSH count as a service? what about FTP? Gopher? RSync? 
> NNTP? IMAP(S)?

My line of thinking is that in this context a service is "a domain-wide
facility that's exposed to third parties where it is strongly preferred
that the third party use the bare domain name directly because that
domain name is used in end-user identities or to identify the endpoint".

For me, that would include:   SMTP, HTTP(s), SIP, XMPP

So, with respect to your list:

SSH - no, it's for managing a specific host

FTP - maybe, but is still well served by the "ftp." convention

Gopher - yes, if it still has any use?

Rsync - maybe - it's most often used for host-to-host transfers,
      but arguably a domain could offer file dist via rsync::,
      although again the "rsync." prefix would usually suffice.

NNTP - probably not, end users see the hostname in their config
      but "news." etc is fine.

IMAP - I believe there's already mechanisms for discovering IMAP
      servers via SRV, although AIUI it's usually a one-off
      configuration-time search, not per-session.

> it may not be too late to think architectural thoughts like "what 
> will the internet engineering community think, 50 years from now, 
> that we should have done for them?"

I hope that's what I'm trying to do.  It would be real bad if some
alternative to "the web" comes along in 10 years time but we can't
differentiate it in the DNS because too many A and AAAA records are
assumed (absent a service identifier) to be dedicated to "the web".

> addresses in all ways (answering UDP, answering TCP SYN, answering 
> ICMP) but are not "actual" hosts. i think i know what you _mean_ here
> and if so i agree with that. but 1.1.1.1 answers both HTTPS and DNS,
> and would surely get an AAAA and A in your model, but is not a 
> "host", and its DNS owner would not be a "hostname". perhaps you mean
> "effective host" which could be real or virtual?

Yes, indeed, that is a more accurate definition.

regards,

Ray

---

From: Matthijs Mekking <[email-masked]>
Date: Fri, 9 Nov 2018 10:50:03 +0100

> fix the architectural problem of lack of a service identifier.

Note that the latest draft of ANAME does not require the lookup to be in 
the authority servers.

Best regards,

Matthijs

---

From: "Patrik Fältström" <[email-masked]>
Date: Fri, 09 Nov 2018 11:31:07 +0100

Note changed subject...

Sure, I think of course the URI RR is the best thing since sliced bread, but same for each one of the proponents of the other RRs.

I think we could look at the various deployment scenarios and demonstrate what design features each one of the RRs have. And with such a description, including why the life of the web hosting provider and web site owner ends up being easier it is possible to have a better discussion with implementors of various libraries that do http fetch. Like libcurl.

When comparing the RRs I agree with the features the other records have, but I want to because of this mention why URI is defined as it is.

1. NAPTR did not scale as the size of the RRSet ends up being so large. The selection of the subset of potential records one want should be in the initial query (QNAME, CLASS, TYPE) and not on the client side. Originally URI was because of that designed to replace NAPTR for the ENUM service, to make the algorithm simpler. But that was not accepted as people already had implemented the (nasty) NAPTR algorithm.

2. URI is a RR type that do use a prefix. It is correct one can not have a wildcard, but instead must explicitly have records for all hostnames in the URI that is served. This is though a conscious choice. See [3].

3. URI is a RR type that do use a prefix and thanks to this one can delegate the _tcp.example.com domain name to a separate DNS server and that way delegate across administrative boundaries. Like we already today handle quite often Active Directory and service discovery based on the AD mechanisms Microsoft have deployed. That way the AD server do not have to be the one that faces the internet etc. XFR ends up being simpler and what not.

4. URI do have as RDATA a full URI and not only a new hostname, and that way can be part of the rewrite that is to happen. One do not have to follow whatever well known URI scheme is to be used, but can instead directly refer to the new URI.

4.1. http://www.example.se/path&kalle=1

4.2. Look up _http._tcp.www.example.se -> https://example.se/site3/

4.3. Fetch with HOST=www.example.se https://example.se/site3/path&kalle=1

This is why I still push URI because I feel 1, 3 and 4 together outweighs 3.

But as other writes, what we lack is code.

   Patrik

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 9 Nov 2018 13:28:25 +0100

Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date: Thu, Nov 08, 2018 at 06:30:41PM -0800 Quoting Paul Vixie ([email-masked]):

> i am loath to create per-service record types. that's why SRV. if you really
> want every client of a service to query for something other than AAAA/A, can
> you try to fix what's wrong with SRV regarding wildcards, but avoid a new

In my sometimes half-working brain a SRV or URI record can be a wildcard. 

If we look at it this way: The user is going to (unless they are
led by a search engine) type a domain name of the form "trademark.TLD"
into their client. Today, the client does matching to actual domain
names by asking for trademark.tld A/AAAA and www.trademark.tld
A/AAAA. (2 queries, not counting the CDN CNAME chain) 

We, or more specifically, people asking for data, can elect to treat the
URI record for 'trademark.tld' node as the default (wildcard) record for
any node that does not exist within the same domain. The semantics "change"
would be "if we ask for _http._tcp.asdf.trademark.tld and get NXDOMAIN
we'll check if _http._tcp.trademark.tld URI exists and return that."

As mentioned above, browsers today do this, but for "www" and "".
And it is done entirely in the client. 

No DNS changes required. 

We can be more specific upwards in the tree by asking  that such cache
hits can't be reused beyond a delegation point (by looking for SOA) if
we so desire. This, as well, is done as a behavioural change in the
client. It can be accelerated by anticipating the next shorter query
in the resolver and send that answer in the additional data section
(as we do with SOA on NXdomain) but it is not strictly necessary.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Pardon me, but do you know what it means to be TRULY ONE with your BOOTH!

---

From: Tony Finch <[email-masked]>
Date: Fri, 9 Nov 2018 14:03:04 +0000

Ray Bellis <[email-masked]> wrote:
> still requiring A and AAAA lookups to be somehow "magic",

That is not the case for the -02 draft.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
an equitable and peaceful international order