Interactions between web clients and the DNS

[Ray Bellis <[e-mail]>]

As some of you know, on Sunday I published
draft-bellis-dnsop-http-record-00.  It's already being discussed in
DNSOP, but this message is my attempt to explain what I think is needed
to this community.  Apologies in advance for the length of it.

The draft is something of a strawman document, based on what I heard at
the side meeting in Montreal, to see whether there's a way forward for
the Web and DNS communities to "meet in the middle" on resolving (no pun
intended) some issues with how some people would like to deploy web
related records in the DNS.

The primary issue is the impossiblity of placing a CNAME record at
the apex of a zone cut such that e.g. example.com indirects to a CDN
host.  Marketing folks want "bare" domain names in URLs, technical
people want those names hosted in a CDN somewhere.

This is however just a corollary of the fact that you can't place a
CNAME record alongside _any_ other DNS resource record.   If I want to
use a CNAME record to direct the web content for foo.example.com to a
CDN I can't also place an MX record there.

Back in 2009, the IAB published RFC 5507 "Design Choices When Expanding
the DNS".  The title is perhaps misleading, but in general it discusses
the issue of the different ways that the DNS can be used to map from a
_service_ to the information about that service.   In general there are
three ways that a service identifier can be used in the DNS:

1.  append a prefix to the domain name (e.g. SRV underscore records)
2.  put something service specific in the data (e.g. TXT SPF records)
3.  use a service-specific resource record (RR) type.

Generally, the document recommends the latter course.  It's far easier
to obtain new RR types than is used to be.

Now back in the "good old days", web traffic did #1, but did it kind of
by accident.   It wasn't part of any standard, but it was a very widely
used convention, and it worked.   The service identifier was "www".  It
was a pretty big hint that the A and AAAA records there were for web use.

However when you do a `gethostbyname()` for any other domain name,
you've lost that service identifier - you're asking for a hostname but
you're still really looking for a _service_.   The A and AAAA records
will be returned, but if you got them via a CNAME, that domain name
_cannot be used for any other service_.

There's a proposal for an "ANAME" record which has some of the "magic"
behind the scenes stuff that CNAME does where the CNAME chain is
followed by the resolver which eventually returns the address record
the client originally asked for, but it doesn't solve the service
identifier issue.  Nor, as far as I can see, would it work well with
CDNs, which is kind of the whole point of wanting apex CNAMEs for many
people.

My proposal then, is a type #3 service identifier for web use - the HTTP
resource record.  Its format looks exactly like a CNAME, but it can
exist alongside other resource records.  Think of it as an "MX record
for web clients", albeit without the priority field.

It is expected (albeit not mandatory) that when asked for an HTTP record
that DNS resolvers would return any corresponding A and AAAA records
from cache.  If the data isn't already in cache, resolvers may go ask
for it before returning the HTTP answer[*].

All that said, there are two downsides to my proposal, but the long term
result should be a much cleaner architecture that is consistent with RFC
5507 and also solves all of the issues with CNAME.

The first downside is that clients would have to explicitly ask for the
HTTP record, and that means client codebase changes.  That said, I think
the implementation effort would be significantly less than that needed
for a DoH client, and it's a one-time hit.

The second downside is that if an HTTP record is returned but the
additional A and AAAA records from cache are not, the web client then
has to make a second A / AAAA request for the hostname returned by the
HTTP record.   I expect this to be only a short term issue, though - 
most resolver implementors deploy new RR types very quickly after IANA 
assignment of the code point.

On that note, the real reason for this message.  Notwithstanding all the
above, in order to make an RFC 6895 early allocation application for the
RR type via expert review, I have to be sure that the structure and
format of the proposed record is fit for purpose, and that's the
feedback I need from you folks.  That question is independent of whether
it's considered deployable or not.

With an early allocation, I can get this implemented in BIND (I work at
ISC), and I'm sure the other OSS resolver vendors would do likewise.
I've already got an offer from GoDaddy to support this for their 75M
domains.  Next I plan to start working on getting one or two of the big
CDNs onboard.

I know this won't be painless, but I honestly believe that there is no
way to fix this just by making changes in the DNS layer - web clients
need to use an application specific service identifier in the DNS just
like every other internet service.

thanks for your time,

Ray

[*] - the -00 draft says that recursive resolvers MAY return the A and
AAAA records from cache or perform iterative resolution of those
records.  The next version will say SHOULD return records if they're in
the cache, and MAY perform iterative resolution to get them if they're
not.  If the above processing was at "MUST" requirement level it
wouldn't be possible to use the RFC 6895 expert review process.