Subject: Re: [DNSOP] Minimum viable ANAME

From: Olli Vanhoja <[email-masked]>
Date: Tue, 26 Mar 2019 15:35:34 +0100

Did someone say that there will be a side meeting about mvp ANAME
during this week? If so, I couldn't find that from the calendar.

---

From: tjw ietf <[email-masked]>
Date: Tue, 26 Mar 2019 16:17:35 +0100

No

I said I want to reset and work toward an interim. 

From my high tech gadget

> On Mar 26, 2019, at 15:35, Olli Vanhoja <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Dan York <[email-masked]>
Date: Tue, 26 Mar 2019 15:17:54 +0000

On Mar 26, 2019, at 3:35 PM, Olli Vanhoja <[email-masked]<mailto:[email-masked]>> wrote:

I believe it was a comment from someone at the mic that the *authors* were going to have a side meeting to talk about simplifying the draft and providing a new version.

If it is a larger meeting than just the authors, then there are probably a number of us who would be interested.

Dan

--
Dan York
Director of Web Strategy, Internet Society
[email-masked]<mailto:[email-masked]>   +1-603-439-0024
Jabber: [email-masked]<mailto:[email-masked]>  Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Mar 2019 16:28:54 +0100

That was me on the mic.

To clarify:

DNS open source implementers discussed it earlier this week to see if 
there is still appetite for ANAME. The last draft did not see a lot of 
comments. To get things moving again we thought it might be a good idea 
to make a document with reduced scope.

Matthijs

On 3/26/19 4:17 PM, Dan York wrote:
> I believe it was a comment from someone at the mic that the *authors* 
> were going to have a side meeting to talk about simplifying the draft 
> and providing a new version.
> 
> [email-masked] <mailto:[email-masked]>   +1-603-439-0024
> Jabber: york@jabber..isoc.org <mailto:[email-masked]>  
> Skype: danyork http://twitter.com/danyork
>

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 15:32:54 +0000

I'm overloaded at the moment so I wasn't able to rev the draft in time for
IETF 104. I was planning to (basically) re-focus on the meaning of the
bits on the wire, and remove any requirements about how zone contents are
provisioned. Instead there would be a series of examples of existing
ANAME-like systems.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
the widest possible distribution of wealth

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Mar 2019 16:36:46 +0100

Hi Tony,

> provisioned. Instead there would be a series of examples of existing

I think that would be the wrong direction.  I believe there is a need to 
standardize the ANAME resolution process and so my suggestion would be 
to reduce the scope by focusing just on how to do that on the 
provisioning side (and leave secondary servers and resolvers out of 
scope for now).

Matthijs

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 16:10:03 +0000

Matthijs Mekking <[email-masked]> wrote:
> standardize the ANAME resolution process and so my suggestion would be to
> reduce the scope by focusing just on how to do that on the provisioning side
> (and leave secondary servers and resolvers out of scope for now).

>From past discussions, I didn't think there was any way we could get
consensus on the provisioning side.

Dynamic lookups on authoritative servers are out, because it has to be
compatible with traditional secondaries.

Updates on the primary are out, because that doesn't scale to large
numbers of zones.

Sometimes a system might have known fallback addresses, but often it won't
(e.g. whether the DNS setup is or isn't coupled to a web provisioning
system).

But I think it's reasonable to allow whatever provisioning mechanisms
there might be, provided the meaning of answers from auth -> rec have a
consistent meaning that resolvers can use.

It's also really imortant that ANAME can work in multi-provider setups, so
there needs to be something approaching interoperable semantics for
importing a zone file into a provisioning system. (Though I think the
semantics will have to be very loose in this case, to allow for variations
between existing systems.)

I haven't seen any objections to support for ANAME in recursive servers
so I'm surprised you think that is problematic enough to be removed. My
understanding was that recursive support is seen as better than trying to
do all the tricks on authoritative servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
safeguard the balance of nature and the environment

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 16:19:52 +0000

Matthijs Mekking <[email-masked]> wrote:
>
> The last draft did not see a lot of comments.

I thought there was quite a lot of very informative and robust discussion
in November.

https://mailarchive.ietf.org/arch/msg/dnsop/fmMGXQA0ryaJdtjSCVEsQ9ZiF2M
https://mailarchive.ietf.org/arch/msg/dnsop/lC2ZW0lwME-RrvkpntRpJzWrLuc
https://mailarchive.ietf.org/arch/msg/dnsop/HGld_NMA0kKzcX3r8sNZiayVJRY

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: Variable,
mainly west or northwest, 3 or 4. Smooth or slight. Fair. Good.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 17:22:25 +0100

I think the one proposal was very client-specific, which kind of ruled it
out for a generic "aname" type.
That was Ray's "HTTP" RRtype, that I did a deep dive on.

Basically, you are correct; the easiest path forward would be for client
software upgrades to get actual DNS records (rather than rely on
getaddrinfo), and do the indirection following (similar to and inclusive of
CNAME and DNAME, in addition to the new "HTTP" type.)

It avoids requiring recursives do the extra handling (analogous to CNAME
chaining and ultimately returning A/AAAA, based on the original QTYPE)
It definitely is the case that there is anti-consensus on the original
ANAME spec which requires sibling records provisioned/populated/maintained
by authority servers -- which is basically fatal to the original ANAME
draft.

I would definitely be willing to work on a true reset of ANAME that goes in
the other direction. I suspect that's what Ray's reset will involve, and I
believe that any effort on the current ANAME before the reset, would likely
be wasted effort. I really want to avoid the issue where those who have, in
good faith, contributed significant effort, want to hold onto that work,
even if that work is ultimately counter-productive.

Please see the discussion on the list from November 2018 timeframe, on the
major issues....

Thanks,
Brian

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Mar 2019 17:23:17 +0100

I stand corrected indeed, I just went to the mailing list to find the 
latest version of the draft and noticed there were many fundamental 
arguments.

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 26 Mar 2019 17:27:04 +0100

> (e.g. whether the DNS setup is or isn't coupled to a web provisioning

All these things are contentious which is the reason why removing it 
from the scope will hopefully aid progress.  These can be resolved in a 
follow up document.

> consistent meaning that resolvers can use. >

Except for the slow deployment issue.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Mar 2019 17:35:19 +0100

On 3/26/19 5:10 PM, Tony Finch wrote:
> so I'm surprised you think that is problematic enough to be removed.

I'm not convinced that the resolver parts will be important, regardless 
of what exact mechanism will be chosen.  My reasoning is that you can't 
rely on any changes there being widely deployed soon, and there might 
not be enough incentive to implement and deploy.  On the authoritative 
side, on the other hand, it's enough to just get support on all servers 
*you* use, and the incentives seem much stronger, too.

--Vladimir

---

From: Olli Vanhoja <[email-masked]>
Date: Tue, 26 Mar 2019 18:01:30 +0100

On Tue, Mar 26, 2019 at 5:36 PM Vladimír Čunát <[email-masked]> wrote:
>
> I'm not convinced that the resolver parts will be important, regardless of what exact mechanism will be chosen.  My reasoning is that you can't rely on any changes there being widely deployed soon, and there might not be enough incentive to implement and deploy.  On the authoritative side, on the other hand, it's enough to just get support on all servers *you* use, and the incentives seem much stronger, too.
>
> --Vladimir

I think it's totally wrong to *choose* here what we think is the best
method to solve the issue. Note that ANAME/ALIAS/whatever is already
widely deployed on the authoritative side i.e. DNS providers like AWS,
PointDNS, DNSMadeEasy, Constellix, Cloudflare (on enterprise plans),
and probably many others. Surely their implementations differ from
each other and what is exactly supported varies a lot, but regardless
of that these providers and their customers are already in consensus
about the key details. Me and many others will be using those
providers no matter whether there will be an RFC or not. Zone
transfers will be hard and feature parity will be lacking but at least
it somewhat works while we keep designing the perfecting Internet that
nobody else has time to wait for.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 26 Mar 2019 18:17:43 +0100

On 3/26/19 6:01 PM, Olli Vanhoja wrote:
> I think it's totally wrong to*choose*  here what we think is the best
> method to solve the issue.

I think it goes the direction you'll like.  My understanding of the 
current plan (of open-source implementors) is to have an RFC specifying 
*as little* as possible, so that it can go through more easily while 
improving interoperability of different (authoritative-only) 
implementations.  In the first RFC at least. After we (dnsop) see 
experience from that, it may be clearer where to go next, if anywhere at 
all.

Please correct me if I'm wrong; I know there are people who know "the 
plan" in more detail.

--Vladimir

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 19:23:06 +0100

On Tue, Mar 26, 2019 at 6:02 PM Olli Vanhoja <[email-masked]> wrote:

> rely on any changes there being widely deployed soon, and there might not
> be enough incentive to implement and deploy.  On the authoritative side, on
> the other hand, it's enough to just get support on all servers *you* use,
> and the incentives seem much stronger, too.
> >
> > --Vladimir
>
> and probably many others.
>

The problem with this assessment, is that those providers are *not* DNS
providers.
They are providers of incompatible, vertically integrated walled gardens.

As far as I understand it, even most of those providers would prefer a
standardized solution.

There are a number of problems around the current solutions, including
lock-in, inability to go multi-provider (on DNS), scalability, and a bunch
of other things.

Doing anything that looks and feels like taking any/all of their solutions,
putting them in an opaque box, wrapping it up, and putting a bow on it,
does nothing to address those issues.
That activity may be many things, but it is not the design of standards, it
is not interoperability, and it most certainly is not "DNS operations".

So, I have to say specifically, "I beg to differ."

We need to start with the base requirements, which is, "I want an apex RR
that allows HTTP browser indirection just as if there was a CNAME there".
Sibling records do not behave like CNAMEs, no matter what extra hacks get
applied; CNAME processing is done by the resolver.
The options are, new RRtypes that require resolver upgrades, or RRtypes
that are handled by the client application (browser), which benefit from
(but do not require) resolver upgrades.

(The above is the "Cliff Notes" version. If you want the long version, go
back in your email or on the WG mailing list archives, and look at the
thread from November of last year.)

BTW, I am happy to actually work on future drafts on this stuff, and even
to contribute code for PoC work. My coding is probably not quite up to
snuff for full implementation, but PoC, sure.

Brian

---

From: Olli Vanhoja <[email-masked]>
Date: Tue, 26 Mar 2019 20:31:33 +0100

On Tue, Mar 26, 2019 at 7:23 PM Brian Dickson
> We need to start with the base requirements, which is, "I want an apex RR that allows HTTP browser indirection just as if there was a CNAME there".
> Sibling records do not behave like CNAMEs, no matter what extra hacks get applied; CNAME processing is done by the resolver.
> The options are, new RRtypes that require resolver upgrades, or RRtypes that are handled by the client application (browser), which benefit from (but do not require) resolver upgrades.
>

I see a huge problem there, let's call it IPv6 problem. During the
transition phase to this new RR we need to have a fallback, right? How
long do we need to have that fallback for old resolvers and browsers?
I'd say approximately until DNS has been replaced by some other tech.
If we are lucky DoH would solve it by doing what those previously
mentioned companies are doing now on their servers, but then we would
cry again that it's the wrong solution.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Mar 2019 21:20:10 +0100

On Tue, Mar 26, 2019 at 8:31 PM Olli Vanhoja <[email-masked]> wrote:

> > We need to start with the base requirements, which is, "I want an apex
> RR that allows HTTP browser indirection just as if there was a CNAME there".
> > Sibling records do not behave like CNAMEs, no matter what extra hacks
> get applied; CNAME processing is done by the resolver.

I don't follow you.

I'm advocating the latter of the two options, because it does not require
resolver upgrades.
Thus, the "old resolvers" is a moot issue, as they would continue to be
compatible with the new types.
The only expectation is that new resolvers would be more efficient, thus
the incentive (not requirement) is for the resolver operators. Or not, if
they don't particularly care.

I also don't follow the "transition phase" logic, either.

Clearly, there would not be compatibility between old browsers and new
RRtypes, since the support for the new types would be in the new browsers
exclusively.

The use of the new types would be controlled by the apex owners of each
individual domain.
Each domain would be free to switch to the new type whenever they wished; I
would expect it to follow the traditional curve of early adopters through
laggards...

This would be a case where there would be a need for deployment of new
browsers first, in order to enable the new record type.
Once there was a critical mass of deployed browsers, I'd expect uptake on
zone owners to follow, eventually creating pressure on laggards to upgrade
their browsers.

Non-upgraded browsers would lose access to names at zone apexes which use
the new type(s).

> cry again that it's the wrong solution.

I'm not sure how you see this involving DoH; it is an issue orthogonal to
the transport or the choice of recursive.

An upgraded browser (which understands the new RRtype) would be able to
resolve the new type using an old resolver.
Resolvers do not require upgrades to serve new types, as long as the new
types don't require special handling.
These new types would not require special handling by the resolver, but
rather would have the special handling done by the browser.
(That's kind of the whole point - eliminate the need for resolver upgrades.)

In this context, "DoH would solve it" is both ambiguous, and largely
redundant, or erroneous.

If by DoH, you mean upgraded resolvers, then upgraded resolvers would be
doing "it"; DoH doesn't enter the picture at all, except as an optional
transport path. Except that without upgrading the browsers, the new RRtypes
would not be requested, and "it" would not work at all. With upgraded
resolvers and browsers both, the new RRtypes would work and have better
performance, but again, the DoH piece is unrelated and not required.

If by DoH, you mean upgraded browsers, then upgraded browsers would be
doing "it"; again, DoH doesn't enter the picture. At best, DoH would be
orthogonal to the new RRtype usage. It would be the support for the RRtype,
not the support for DoH, that would enable the new apex dns record type for
HTTP-specific aliasing.

Brian

---

From: Olli Vanhoja <[email-masked]>
Date: Tue, 26 Mar 2019 21:46:40 +0100

On Tue, Mar 26, 2019 at 9:20 PM Brian Dickson
<[email-masked]> wrote:
> I'm advocating the latter of the two options, because it does not require resolver upgrades.
> Thus, the "old resolvers" is a moot issue, as they would continue to be compatible with the new types.
> The only expectation is that new resolvers would be more efficient, thus the incentive (not requirement) is for the resolver operators. Or not, if they don't particularly care.
>

Perhaps I misunderstood you. That's exactly what I'm hoping for,
compatibility with the old resolvers.

> I'm not sure how you see this involving DoH; it is an issue orthogonal to the transport or the choice of recursive.

I mean, if there is something new that the client side needs to do to
get an IP address for a domain, then it could be implemented on a DoH
server. Though maybe in that case the client is updated already. Maybe
it would happen at an ISP instead over traditional DNS.

> An upgraded browser (which understands the new RRtype) would be able to resolve the new type using an old resolver.
> Resolvers do not require upgrades to serve new types, as long as the new types don't require special handling.
> These new types would not require special handling by the resolver, but rather would have the special handling done by the browser.

Well that's my point, if you need to do something new on the client
side, is it a resolver change or a browser change, it will make it
much slower transition. Would a big multinational company change to
this new way of resolving an IP address (and stop serving A records on
selected names) any time soon and risking losing possible customers?
The fallback here would be to just somehow serve a normal A record
that a client already understands.

---

From: Tony Finch <[email-masked]>
Date: Tue, 26 Mar 2019 20:54:04 +0000

> On 26 Mar 2019, at 18:23, Brian Dickson <[email-masked]> wrote:
> 

The current draft is neither of those (and I think maybe you excluded it from your list because you don’t consider it viable, for good reasons, but...)

Whatever new thing we come up with, my view is that it will need sibling address records for backwards compatibility, otherwise no-one can deploy it. (Or at least, that new thing won’t make my job easier any time soon.) So there has to be some kind of provisioning or authoritative hack to make it easy to automatically add address records that have the same effect as the ANAME or HTTP record that they are supporting. (Remember, the existing non-standard alias stuff exists because it is easier than standard DNS.)

Ray Bellis thinks (quite reasonably) that there is a good chance that an HTTP specific record can be deployed fairly quickly, because browser upgrades are impressively fast these days. I’m less enthusiastic about telling DNS admins to look at caniuse.com before they decide whether to put in an HTTP record.

(On the gripping hand, based on the support queries I have answered, an HTTP302 record [an http redirect in the dns] would be a lot closer to what many webmasters expect!)

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

---

From: Dan York <[email-masked]>
Date: Tue, 26 Mar 2019 22:49:17 +0000

> On Mar 26, 2019, at 7:23 PM, Brian Dickson <[email-masked]> wrote:
> 
> We need to start with the base requirements, which is, "I want an apex RR that allows HTTP browser indirection just as if there was a CNAME there”.

Yes, THIS. 

In response to the discussion last November, I put together this draft outlining the views of one publisher of a set of websites (me):

https://tools.ietf.org/html/draft-york-dnsop-cname-at-apex-publisher-view-01

For reasons outlined in that draft, I want to use a CDN in front of my sites, but I also want to retain control of operating my own DNS. (I.e. I don’t want to have the CDN also do the DNS hosting for me, too.).

To use a CDN while retaining DNS control, most CDNs require you to set up a CNAME pointing to some URL they give you.  When a person then visits that URL, the CDN does its own magic inside its own DNS services to provide the visitor with the A or AAAA record of the edge server closest to the visitor.

This all works perfectly fine if you use a subdomain such as “www.”. You just use a CNAME record and all is fine.

But if you want to drop the “www.” and just use the domain name (example.com), then we don’t have any standardized way to do a CNAME-like function at the apex of the zone. 

Because this is a common business requirement, most DNS hosting providers / operators provide some proprietary method of doing this kind of redirection. Either that or a company has to create their own redirection server (something we did). Either way, you are locked into a proprietary system with issues I outlined in that draft.

As Tim Wicinski mentioned in his review of documents today in DNSOP, this is not a simple problem to solve and there are some fundamental (and passionate) disagreements about the way forward. 

Tim’s suggestion of an interim (presumably virtual?) to focus specifically on this issue seems to make sense to me.

As I stated in the draft, I don’t personally have an opinion (yet, anyway) about solutions. I just want something that works and can be rapidly deployed and used…. so that I can be using a standard RR type instead of proprietary solutions.

That’s it,
Dan  (who just last month deployed a new website and immediately had people asking him when it would work without the “www.” in front of it… so we had to rapidly go and get that set up)

---

From: Benno Overeinder <[email-masked]>
Date: Fri, 29 Mar 2019 00:14:04 +0100

> Tim’s suggestion of an interim (presumably virtual?) to focus specifically on this issue seems to make sense to me.

Given the discussion on the list, the chairs have decided to schedule a
10-15 minute slot at the end of the Friday DNSOP session.

After an overview of the context, Matthijs Mekking will present the
current status of the ANAME draft -02 and (alternative) paths to make
progress at the WG.

See updated agenda on
https://datatracker.ietf.org/meeting/104/materials/agenda-104-dnsop-06

Cheers,

-- Benno