Subject: Re: [DNSOP] Minimum viable ANAME

From: Erik Nygren <[email-masked]>
Date: Sat, 3 Nov 2018 16:12:21 -0400

How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it
more DNS-aligned (e.g. the name as a separate field in the record) not help
here?  It comes from the HTTP world and is aligned with the existing AltSvc
feature and thus is useful in other ways (such as perhaps solving the DNS
deployabilty issues for encrypted SNI):

https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

- Erik

On Sun, Sep 23, 2018, 10:41 AM Ray Bellis <[email-masked] wrote:

> On 21/09/2018 19:11, JW wrote:
>
> > I also feel from this discussion, we are all roughly on the same page.
> > We want SRV as the long term solution ...
>
> except that we heard at the side meeting in Montreal (albeit from
> browser people rather than content people) that they *don't* want SRV,
> because it has fields that are not compatible with the web security model.
>
> I still want to define a new RR that does have mutually agreed semantics
> that's specifically for use by HTTP(s), but so far no takers.
>
> Ray
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 5 Nov 2018 13:27:14 -0500

On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren <[email-masked]> wrote:

> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make
> it more DNS-aligned (e.g. the name as a separate field in the record) not
> help here?
>

Thanks for mentioning DNS-Alt-Svc, Erik.

Compared to URI or the proposed HTTP record, one thing that's different
about DNS-Alt-Svc is that Alt-Svc is always optional, as currently defined,
and DNS-Alt-Svc inherits those semantics.  That means servers have to be
prepared for some users to ignore the ALTSVC record, so the apex would
still need AAAA records.

Being optional may seem like a deficiency for this application, but I now
think it's actually the best we can do as a first step.  If we start with
an optional record type that offers added value (e.g. performance, privacy,
or security), then both client vendors and server operators have a reason
to invest in deployment.  Once it's widely deployed, then we can imagine
simplified architectures that rely on the new record type, starting with
servers that don't need to support legacy clients.

I think it's reasonable to have a roadmap to a full transformation of the
DNS architecture for HTTP, but every step along the roadmap ought to have
clear net benefit to each participating party.  This seems to require a
design more or less like DNS Alt-Svc, where the additional indirection is
coupled to other improvements for HTTP.

>   It comes from the HTTP world and is aligned with the existing AltSvc

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 09:05:50 +1100

> On 6 Nov 2018, at 5:27 am, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make it more DNS-aligned (e.g. the name as a separate field in the record) not help here?
> 
> Compared to URI or the proposed HTTP record, one thing that's different about DNS-Alt-Svc is that Alt-Svc is always optional, as currently defined, and DNS-Alt-Svc inherits those semantics.  That means servers have to be prepared for some users to ignore the ALTSVC record, so the apex would still need AAAA records.

The publishing or the lookup?

> Being optional may seem like a deficiency for this application, but I now think it's actually the best we can do as a first step.  If we start with an optional record type that offers added value (e.g. performance, privacy, or security), then both client vendors and server operators have a reason to invest in deployment.  Once it's widely deployed, then we can imagine simplified architectures that rely on the new record type, starting with servers that don't need to support legacy clients.
> 
> I think it's reasonable to have a roadmap to a full transformation of the DNS architecture for HTTP, but every step along the roadmap ought to have clear net benefit to each participating party.  This seems to require a design more or less like DNS Alt-Svc, where the additional indirection is coupled to other improvements for HTTP.
>  
>   It comes from the HTTP world and is aligned with the existing AltSvc feature and thus is useful in other ways (such as perhaps solving the DNS deployabilty issues for encrypted SNI):
> 

What are the rules for populating the additional section of a response?

It looks like nameservers will have to split the rdata up on commas the look for protocol-id=value pair at the start of comma separated field.  Then look for the :port and remove it from value.
then look to see if there was a host specified and if so lookup up that name.

Wouldn’t be better to pre-parse the fields in the record?

[<len><id-len><id><host><port>[<name-len><name><value-len><value]*]{1+}

where host is in DNS wire format and . (00) is used for a empty host field in the alt-srv record?

Libraries can reconvert this to textual format if that makes it easier for a browser though
you may as well use it in structured format.

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 6 Nov 2018 17:25:46 -0500

> The publishing or the lookup?

Both.  Most web servers don't make use of Alt-Svc, and browsers are under
no obligation to respect it (and indeed many don't).  It's strictly an
optimization, and everything still has to work correctly without it.

> > I think it's reasonable to have a roadmap to a full transformation of
> the DNS architecture for HTTP, but every step along the roadmap ought to
> have clear net benefit to each participating party.  This seems to require
> a design more or less like DNS Alt-Svc, where the additional indirection is

The DNS Alt-Svc draft currently doesn't cover this, but I would definitely
be interested to hear suggestions.  Since support is optional, the draft
focuses on the RFC 3597 opaque record process, but we can certainly
consider further optimizations that would be possible in ALTSVC-aware DNS
servers.

> It looks like nameservers will have to split the rdata up on commas the
> look for protocol-id=value pair at the start of comma separated field.
> Then look for the :port and remove it from value.

I'm fine with minor alterations to the syntax, but I'm not convinced that
it's important.  Parsing the contents is optional (per RFC 3597), and
writing a parser is trivial (as you've described).  Open-source parsers are
widely available (e.g. from open-source browsers).  To avoid ossification,
we'd need to have confidence that any deviations from the HTTP Alt-Svc
syntax are losslessly interconvertible and future-proof, which is a high
bar.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 09:53:26 +1100

> On 7 Nov 2018, at 9:25 am, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> Both.  Most web servers don't make use of Alt-Svc, and browsers are under no obligation to respect it (and indeed many don't).  It's strictly an optimization, and everything still has to work correctly without it.

HTTP is optional to be published.  For HTTP to a solution to name to server mapping in the DNS it needs to be looked up by clients and ALTSRV would also need to be looked up clients at the time
A and AAAA records are being looked up.  Say it wouldn't is being disingenuous.  Legacy clients wouldn’t look it up.

> The DNS Alt-Svc draft currently doesn't cover this, but I would definitely be interested to hear suggestions.  Since support is optional, the draft focuses on the RFC 3597 opaque record process, but we can certainly consider further optimizations that would be possible in ALTSVC-aware DNS servers.
>  
> I'm fine with minor alterations to the syntax, but I'm not convinced that it's important.  Parsing the contents is optional (per RFC 3597), and writing a parser is trivial (as you've described).

Given lots of browser people complained that SRV would require two round trips to the recursive server not describing how to populate the additional section would seem to be a non-starter.

Having to re-parse the record every time you serve it also seem like a big waste of resources so
no it really isn’t a minor alteration from the DNS side.

> Open-source parsers are widely available (e.g. from open-source browsers).  To avoid ossification, we'd need to have confidence that any deviations from the HTTP Alt-Svc syntax are losslessly interconvertible and future-proof, which is a high bar.

If you extend the syntax such that a parser to the binary format above breaks request a new type
and start using it.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Nov 2018 14:51:15 +0900

I changed Subject.

Let me clarify confusions on SRV and ALTSRV.

On 2018/11/07 7:05, Mark Andrews wrote:

>> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to >> make it more DNS-aligned (e.g. the name as a separate field in the>>  
record) not help here?

I'm afraid you (Erik) are not aware of the most important
changes of ALTSRV from SRV, which is necessary to make SRV
implementable on browsers.

One is that, instead of _<portname>, _<portnumber> is used. OW,
browsers need most recent /etc/services and we are still at
a loss if port numbers do not have IANA assigned names.

Another important change is removal of _<protocol> replaced
by _<scheme>. Browsers know <scheme>, but <protocol> may
be known only by add on modules for <scheme>.

They are good changes.

However,

>> It comes from the HTTP world and is aligned with the
>> existing AltSvc feature

that is a fatal mistake.

It MUST come from WWW, *NOT* HTTP, world.

What is necessary for browsers is translation mechanism of
URLs in general, which is *NOT* HTTP specific.

Thus, proposed features specific to HTTP/HTTPS should be
removed entirely.

> Wouldn’t be better to pre-parse the fields in the record?

Yes, of course.

 From URLs including <hostname>,

    <scheme>://[<userinfor>@]<hostname>[:<port>]<path>[?<query>]

_<port>._<scheme>.<hostname> NEWSRV <newhostname> <newport>

or, if optional <port> is not specified,

_<defaultport>._<scheme>.<hostname> NEWSRV <newhostname> <newport>

should be looked up and the original URLs should be rewritten as:

    <scheme>://[<userinfor>@]<newhostname>:<newport><path>[?<query>]

or, if <newport> is 0,

    <scheme>://[<userinfor>@]<newhostname><path>[?<query>]

That's all necessary.

As multiple (anycast) addresses (<hostname> may have multiple
addresses, which may be anycast ones) take care of load
distribution and fault tolerance, I don't think complications
by priority or weight necessary. As they are not very harmful,
they may be added, if someone insists, but, won't be used.

						Masataka Ohta

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 7 Nov 2018 00:54:00 -0500

On Tue, Nov 6, 2018 at 5:53 PM Mark Andrews <[email-masked]> wrote:

> > > How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to
> make it more DNS-aligned (e.g. the name as a separate field in the record)
> not help here?
> > >
> > > Compared to URI or the proposed HTTP record, one thing that's
> different about DNS-Alt-Svc is that Alt-Svc is always optional, as
> currently defined, and DNS-Alt-Svc inherits those semantics.  That means
> servers have to be prepared for some users to ignore the ALTSVC record, so
> the apex would still need AAAA records.
> >
> > Both.  Most web servers don't make use of Alt-Svc, and browsers are
> under no obligation to respect it (and indeed many don't).  It's strictly
> an optimization, and everything still has to work correctly without it.
>
> HTTP is optional to be published.  For HTTP to a solution to name to
> server mapping in the DNS it needs to be looked up by clients and ALTSRV
> would also need to be looked up clients at the time
> A and AAAA records are being looked up.  Say it wouldn't is being
> disingenuous.  Legacy clients wouldn’t look it up.
>

HTTP as proposed isn't useful to site operators until it's deployed in all
(their relevant) clients.  HTTP as proposed isn't useful to clients until
there are servers that don't work without it.  This is essentially the same
deadlock as with SRV, and IMHO it's the main reason we haven't made any
progress on this topic.

It seems you're proposing that clients should implement this unilaterally
now, with the expectation that servers will eventually start to depend on
it, N years from now when client support is universal.  I think this is
unlikely to happen.  By my estimate, this proposal would ask browser
vendors to waste quadrillions of DNS queries over the next few years,
waiting for a critical mass that may never arrive, in order to achieve a
goal with no apparent benefit to the user.  If Browser A (X% of users)
implements this feature, and Browser B (Y > 5% of users) never implements
it, then most websites can never rely on it, and Browser A incurs an
ongoing cost for no benefit to anyone.

Perhaps all the browser vendors will get on board, but if history is any
guide, most will not, and even one holdout torpedoes the whole project.
(Also, browsers simply _can't_ implement it if they do DNS through POSIX
libc, as many browsers traditionally have done.)

> > > Being optional may seem like a deficiency for this application, but I
> now think it's actually the best we can do as a first step.  If we start
> with an optional record type that offers added value (e.g. performance,
> privacy, or security), then both client vendors and server operators have a
> reason to invest in deployment.  Once it's widely deployed, then we can
> imagine simplified architectures that rely on the new record type, starting
> with servers that don't need to support legacy clients.
> > >
> > The DNS Alt-Svc draft currently doesn't cover this, but I would
> definitely be interested to hear suggestions.  Since support is optional,
> the draft focuses on the RFC 3597 opaque record process, but we can
> certainly consider further optimizations that would be possible in
> ALTSVC-aware DNS servers.
> >
> > I'm fine with minor alterations to the syntax, but I'm not convinced
> that it's important.  Parsing the contents is optional (per RFC 3597), and
> writing a parser is trivial (as you've described).
>
> Given lots of browser people complained that SRV would require two round
> trips to the recursive server not describing how to populate the additional
> section would seem to be a non-starter.
>

DNS Alt-Svc as specified can be done without blocking the page load
critical path, so it doesn't add latency.  However, I agree that we would
want an approved way to populate the Additional section before asking
browsers to block pageload on an ALTSVC query.

> no it really isn’t a minor alteration from the DNS side.

In the architecture you're describing, each ALTSVC record would only need
to be parsed once, when it arrives over the network.  I do not believe that
this kind of parsing represents a significant cost: throughput will be
network-limited before it is limited by this parsing step.

> Open-source parsers are widely available (e.g. from open-source
> browsers).  To avoid ossification, we'd need to have confidence that any
> deviations from the HTTP Alt-Svc syntax are losslessly interconvertible and
> future-proof, which is a high bar.
>

This will not work with DNS Alt-Svc, which is specified as a transparent
pass-through for the HTTP Alt-Svc field value.  Even if we relax that
requirement, adding new RRTYPEs would create increasing overhead and
complexity, requiring clients to issue a query for every revision of the
ALTSVC RRTYPE on every connection initiation.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 7 Nov 2018 17:36:18 +1100

> On 7 Nov 2018, at 4:54 pm, Ben Schwartz <[email-masked]> wrote:
> 
> 
> 
> HTTP as proposed isn't useful to site operators until it's deployed in all (their relevant) clients.  HTTP as proposed isn't useful to clients until there are servers that don't work without it.  This is essentially the same deadlock as with SRV, and IMHO it's the main reason we haven't made any progress on this topic.

Well it worked for SMTP. When MX records were introduced A records were the only thing SMTP
servers understood. It took a while but nobody now worries about publishing a MX record without
a A (or AAAA) records as a backup for legacy clients.  I still remember having to worry about publishing A records for legacy SMTP servers that didn’t understand MX records.

> It seems you're proposing that clients should implement this unilaterally now, with the expectation that servers will eventually start to depend on it, N years from now when client support is universal.  I think this is unlikely to happen.  By my estimate, this proposal would ask browser vendors to waste quadrillions of DNS queries over the next few years, waiting for a critical mass that may never arrive, in order to achieve a goal with no apparent benefit to the user.  If Browser A (X% of users) implements this feature, and Browser B (Y > 5% of users) never implements it, then most websites can never rely on it, and Browser A incurs an ongoing cost for no benefit to anyone.

Enough with this critical mass garbage because that is all that it is.  We could have completed
2 or 3 transitions since SRV was introduced in the DNS.

> Perhaps all the browser vendors will get on board, but if history is any guide, most will not, and even one holdout torpedoes the whole project.  (Also, browsers simply _can't_ implement it if they do DNS through POSIX libc, as many browsers traditionally have done.)

So they can’t link with libresolv which has supported unknown types and classes since it was written back when BSD 4.2 was released back in the 1990s?  

#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>

#define T_HTTP <TBD>
unsigned char buf[65536];

n = res_init();
n = res_query(“example.com”, C_IN, T_HTTP, buf, sizeof(buf));

If you don’t want to block use res_mkquery and handle their own socket IO by looking in _res for the name server addresses.

unsigned char qbuf[512]; 
n = res_init();
n = res_mkquery(QUERY, “example.com”, C_IN, T_HTTP, NULL, 0, NULL, qbuf, sizeof(qbuf));

> DNS Alt-Svc as specified can be done without blocking the page load critical path, so it doesn't add latency.  However, I agree that we would want an approved way to populate the Additional section before asking browsers to block pageload on an ALTSVC query.
>  
> In the architecture you're describing, each ALTSVC record would only need to be parsed once, when it arrives over the network.  I do not believe that this kind of parsing represents a significant cost: throughput will be network-limited before it is limited by this parsing step.
> 
> This will not work with DNS Alt-Svc, which is specified as a transparent pass-through for the HTTP Alt-Svc field value.  Even if we relax that requirement, adding new RRTYPEs would create increasing overhead and complexity, requiring clients to issue a query for every revision of the ALTSVC RRTYPE on every connection initiation.
>  
> 
> > > - Erik
> > > 
> > >      
> > >