Subject: Re: [DNSOP] abandoning ANAME and standardizing CNAME at apex

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 16 Sep 2018 15:26:56 +0530

Hi Petr

Apologies for the delayed reply.

On Tue, Jun 19, 2018 at 03:18:22PM +0200, Petr Špaček wrote:
> Hello dnsop,
> 
> beware, material in this e-mail might cause your head to explode :-)
> 
> This proposal is based on following observations:
> - It seems that DNS protocol police lost battle about CNAME at apex,
>   is is deployed on the Internet.
> - Major DNS resolvers like BIND, Unbound, PowerDNS Recursor, dnsmasq
>   already have code to cope with the "impossible" case of CNAME at the
>   apex and deal with it in ways which do not break stuff on resolver
>   side.
> - Authoritative servers of vendors named above refuse to serve CNAME at
>   apex.
> - There are CDNs etc. which allow users to create CNAME at apex
>   no matter what the standards and "normal" servers say and do.
> (We have found out this because Knot Resolver is missing hacks for CNAME
> at apex and users complain that "it works with every other resolver".)
> 
> 
> Take a deep breath!
> 
> 
> Given that resolver side somehow works already ...
> could we standardize this obvious violation of RFC 1035?
> 
> It is very clear violation of the standard, but almost everyone found
> his way around it using different hacks. These hacks are not going away
> because all the CDNs just don't care about standards so we will have
> to maintain this code no matter what a great solution we will invent for
> future. I.e. adding ANAME will just increase complexity because CNAME at
> apex will be there for a long time (if not forever).
> 
> I personally do not like this but it seems better to think though
> corner cases in code we already have in production (i.e. think through
> current hacks for CNAME at apex) instead of inventing new things like ANAME
> (or whatever else).
> 
> Opinions? Tomatoes? Can it work? If not, why not?

To me it seems it can work, and it sounds like a good idea. To relax DNS
protocol for CNAME to co-exist with other RR types, we'd need resolver
support, authoritive support and a time when it is practially usable.

----

Adding resolver support (to resolvers that don't have it, i.e., vs. RFC
1035) does not appear to break current DNS, i.e., it can be proposed
now.

1. When a resolver looks up a RR type in cache, and finds any positive
type match, it serves it.

2. If it does not find a positive type match, but finds a CNAME, it
looks for a negative cache entry for that RR type.

2.a. If a negative cache entry is found (or if it can synthesize one),
it returns/follows the CNAME chain.

2.b. If no negative cache entry is found (and it cannot synthesize one),
it starts a fetch for that type from upstream.

2.b.i. If the fetch returns a CNAME or NODATA, it means that the type
does not co-exist with CNAME in that node in the auth zone. The resolver
adds a negative cache entry for the type for the TTL of the returned
CNAME (or from SOA fields) to the cache, and returns/follows the CNAME
chain.

2.b.ii. If the fetch returns the type, it means that the type may
co-exist with the CNAME. The resolver adds a positive cache entry for
the type and returns the fetched answer.

2.b.iii. If the fetch returns NXDOMAIN, it overwrites the cache for that
node with a negative cache entry.

----

Adding authoriative support would mean relaxing checks and allowing
CNAME to co-exist with other types except non-apex NS (parent of zone
cut), and perhaps allow CNAME and DNAME to co-exist too.

For operators to be able to use it, they would need resolver support to
be available everywhere. I guess nothing stops a draft requiring
resolvers to implement support for it now.

So +1.

		Mukund

---

From: Paul Vixie <[email-masked]>
Date: Sun, 16 Sep 2018 08:54:27 -0700

this proposal appears to make more sense. if cname cannot be used until 
everybody has upgraded, then some other ?name RR could be used instead, 
on a similar time line, and would have no impact on those who never 
upgraded.

---

From: Dan York <[email-masked]>
Date: Mon, 17 Sep 2018 01:18:24 +0000

Mukund,

Thank you for reviving this conversation. I was just asked last week about the status of this whole debate by someone who was seeking to set up “CNAME at apex”-style records for a variety of domains, all of which would be pointed over to links within various CDNs.

His challenge is that, for a variety of reasons not within his control, his domains are spread across several different CDNs / DNS hosting providers, all of whom do “CNAME at apex” in different ways. (And, if I recall correctly, one provider did NOT support this capability, citing RFC 1035 as their rationale.) The added complexity, and having to be sure he is doing it correctly for each of the different services, is quite frustrating and time consuming.  Meanwhile, he has communications people asking him very strongly for the ability to drop the “www” and just refer to their website addresses as “example.com<http://example.com>/<foo>”.

Hence his question to me about if this was ever going to be “fixed” by the IETF with some kind of standard.

I do think something needs to be done to standardize CNAME (or something very similar) at the apex. For the person with whom I was speaking, all of this websites are set up using various CDNs. So all he can provide is a DNS address in the CDN’s network.  He has no way to get an A or AAAA address as I understand the ANAME proposal would require.

So this is a lengthy way of saying that I would agree with moving ahead with a proposal to allow CNAME at apex, and to start to get resolvers to implement that.  I realize that updating the whole DNS infrastructure is incredibly challenging (we wrote about this with regard to crypto algorithms at https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs ).  And so this may not be something widely available for some time.  But if we could get it started, it would definitely help the many people out there trying to configure domains to point to CDNs from their apex.

Dan

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

http://www.internetsociety.org/

On Sep 16, 2018, at 5:56 AM, Mukund Sivaraman <[email-masked]<mailto:[email-masked]>> wrote:

Hi Petr

Take a deep breath!

----

----

So +1.

Mukund

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

---

From: Evan Hunt <[email-masked]>
Date: Mon, 17 Sep 2018 03:51:34 +0000

It seems to me problematic to start with the statement that apex CNAME is
"deployed on the internet". Obviously it does occur, but it breaks things
when it does.  Depending on various factors such as the order in which
responses are cached, the breakage is sometimes survivable, but you can't
put a CNAME at a zone apex and expect resolvers to Just Work. Even the
ones that have hacks to work around this problem aren't always successful.

I don't see how we can responsibly declare a new standard which, if
followed, will break every prior implementation. Apex CNAME is the sort
of solution that's clear, simple, and wrong.

We're going to need another type code.

On Mon, Sep 17, 2018 at 01:18:24AM +0000, Dan York wrote:
> Mukund,
> 
> Thank you for reviving this conversation. I was just asked last week
> about the status of this whole debate by someone who was seeking to set
> up “CNAME at apex”-style records for a variety of domains, all of which
> would be pointed over to links within various CDNs.
> 
> His challenge is that, for a variety of reasons not within his control,
> his domains are spread across several different CDNs / DNS hosting
> providers, all of whom do “CNAME at apex” in different ways. (And, if I
> recall correctly, one provider did NOT support this capability, citing
> RFC 1035 as their rationale.) The added complexity, and having to be
> sure he is doing it correctly for each of the different services, is
> quite frustrating and time consuming.  Meanwhile, he has communications
> people asking him very strongly for the ability to drop the “www” and
> just refer to their website addresses as
> “example.com<http://example.com>/<foo>”.
> 
> I do think something needs to be done to standardize CNAME (or something
> very similar) at the apex. For the person with whom I was speaking, all
> of this websites are set up using various CDNs. So all he can provide is
> a DNS address in the CDN’s network.  He has no way to get an A or AAAA
> address as I understand the ANAME proposal would require.
> 
> So this is a lengthy way of saying that I would agree with moving ahead
> with a proposal to allow CNAME at apex, and to start to get resolvers to
> implement that.  I realize that updating the whole DNS infrastructure is
> incredibly challenging (we wrote about this with regard to crypto
> algorithms at
> https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs
> ).  And so this may not be something widely available for some time.
> But if we could get it started, it would definitely help the many people
> out there trying to configure domains to point to CDNs from their apex.
> 
> Dan
>
> --
> Dan York

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 17 Sep 2018 09:11:21 +0200

On Mon, Sep 17, 2018 at 03:51:34AM +0000,
 Evan Hunt <[email-masked]> wrote 
 a message of 124 lines which said:

> followed, will break every prior implementation. Apex CNAME is the
> sort of solution that's clear, simple, and wrong.

+1

> We're going to need another type code.

Since the main use case is "people with a domain name such as
example.com, who wants https://example.com/ to actually work, and who
hosts the stuff at a CDN where the IP address is wildly variable so
they cannot use A or AAAA records", I suggest that this use case is
better solved by using SRV records for HTTP. True, it seems
unrealistic that it will be specified and deployed but it is also the
case for the DNS "CNAME at apex" change.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 17 Sep 2018 09:14:14 +0200

On Sun, Sep 16, 2018 at 03:26:56PM +0530,
 Mukund Sivaraman <[email-masked]> wrote 
 a message of 66 lines which said:

> Adding resolver support (to resolvers that don't have it, i.e.,
> vs. RFC 1035) does not appear to break current DNS, i.e., it can be
> proposed now.

[Algorithm deleted]

The difficult thing is not to specify what the new resolvers will have
to do, but to describe what will happen with the current
resolvers. What will happen when "CNAME at apex" will be deployed,
assuming X % of the resolvers will not be upgraded?

---

From: Ray Bellis <[email-masked]>
Date: Mon, 17 Sep 2018 08:29:54 +0100

> case for the DNS "CNAME at apex" change.

We heard at the side meeting in Montreal that SRV doesn't meet the 
requirements, in part because it has features that are considered 
incompatible with the web origin model (i.e. the port field).

I do believe we need a new DNS type code that is designed in cooperation 
with the HTTP community and I've suggested as such on the http-srv 
mailing list, but so far there's little engagement.

There was a suggestion that the proposed ALT-SVC RR could be used, but 
IMHO it has significant issues that would need to be resolved first.

Ray

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 17 Sep 2018 13:13:27 +0530

Hi Stephane

> assuming X % of the resolvers will not be upgraded?

I fully realise what you're saying.

The suggestion is only to require support in resolvers going forward for
CNAME co-existing with other types for now. That should not break any
detail of how DNS is used today.

Whether CNAME + other types at apex can be used in the future would be
an operational decision for that time of the world.

Similar things can be said of other proposals.

* If SRV for HTTP is brought into use, what about X% of user agents that
  don't have support for it?

* If a new RR type is introduced, what about X% of resolvers that do not
  support it?

Although it changes current DNS protocol, AFAICT there does not seem to
be anything badly wrong with allowing CNAME + other types at a node,
where the CNAME is considered a fallback when the required type doesn't
exist.

Repeating what the original post's author Petr said, this seems to be a
simpler change than adding other types for similar benefit, esp. when
hacks are already necessary to workaround the case of CNAME and other
types co-existing that are seen in the DNS.

		Mukund

---

From: Ray Bellis <[email-masked]>
Date: Mon, 17 Sep 2018 09:47:50 +0100

> detail of how DNS is used today.

...

> where the CNAME is considered a fallback when the required type doesn't

This is not true.

Ondrej demonstrated at the last hackathon that permitting a CNAME
alongside the apex can cause MX-related failures in resolvers that are
not upgraded.

There are going to be presentations on this topic at the forthcoming
DNS-OARC meeting in Amsterdam.

Ray

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 17 Sep 2018 15:00:28 +0530

Hi Ray

On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote:
> ....

"The suggestion is only to require support in resolvers going forward
for CNAME co-existing with other types for now."

It is obvious if authoritatives did that today and a RFC 1035 resolver
cached a CNAME, it would match the cached CNAME when doing a type lookup
in cache.

		Mukund

---

From: Petr Špaček <[email-masked]>
Date: Mon, 17 Sep 2018 12:29:13 +0200

> cached a CNAME, it would match the cached CNAME when doing a type lookup
Originally I thought that current workarounds for CNAME at apex (which
are almost everywhere) deal with it in a more deterministic way.
Unfortunatelly it is not the case so I think this is a dead end.

Petr Špacek  @  CZ.NIC

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 17 Sep 2018 17:25:50 +0530

Hi Petr

> are almost everywhere) deal with it in a more deterministic way.

Do you mean the current workarounds in resolver implementations?  These
can be brought into line going forward if there's a draft of expected
behavior.

I was sold when Evan presented the (basic) ANAME idea at a team meeting
at ISC and thought it was a fine idea. Now it seems that relaxing CNAME
to be a fallback would be the most painless and simple path. I
remembered reading something on dnsop@ and got to this thread. Other
ideas would create yet another chapter in the DNS book to implement
which seems excessive for little added benefit.

		Mukund

---

From: Evan Hunt <[email-masked]>
Date: Mon, 17 Sep 2018 16:11:24 +0000

> * If a new RR type is introduced, what about X% of resolvers that do not

They're no worse off than they already were. The old methods would still
work just as well or badly as they do today.

If apex CNAME were declared legitimate, then people using legacy resolvers
*would* be worse off than they are now.

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 17 Sep 2018 22:22:15 +0530

Hi Evan

> *would* be worse off than they are now.

This would not be a decision for people using legacy resolvers to make -
it would be for the zone administrator to decide whether to co-exist
CNAME with other types depending on market share of resolver support.
Then, it wouldn't mean resolvers would break for all other zones - they
could break for this particular zone.

We see this happening in other technologies where new things are
introduced. E.g., many popular websites use SVG, canvas, HTML5 elements,
etc. with no fallback for old browsers which still exist.

(a) Initially, very few web browser instances supported the new
features.

(b) At some point, a majority of web browser instances supported it.

(c) At some point, the *web developer* (not the browser user) decides
that they will now use the new feature in their website, even though it
would not work on a percentage of web browser instances in the wild. It
is a calculated decision for that individual website's case (in the DNS
world, it is for that particular zone and the zone administrator's
choice depending on the risk).

No old behavior is removed as long as zone admins stick to the current
way. Current zones will work as before. And it is a resolver-specific
requirement to support CNAMES with other types for now - it doesn't
require authoritative use, without checking if the new feature is
supported in the market.

The example about SRV has just as much risk. What about browsers that
don't support it? Whether to co-exist CNAME with MX has similar risk as
whether to depend on a new SRV's support in web browsers.

The ANAME draft seemed to beat this, but it got quite complicated.

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Tue, 18 Sep 2018 10:00:15 +1000

> On 17 Sep 2018, at 5:43 pm, Mukund Sivaraman <[email-masked]> wrote:
> 
> Hi Stephane
> 

Initially none.  That however doesn’t stop a site publishing SRV records for
itself.  They do no harm being published.  As browsers and other clients deploy
add SRV support they will use them.  If you have the SRV records point to
secondary addresses you can actually track the deployment of SRV in your
client population.

e.g.

example.com AAAA 2001:0DB8::1
_http._tcp.example.com SRV 0 0 80 server.example.net
server.example.net AAAA 2001:0DB8::2

I would also expect a relatively large client population using SRV records given
the rate Firefox and Chrome browsers are upgraded.  SRV lookups work for lots of
other protocols.  SRV records also make it through firewalls and IDS today.

Sites can look at the clients that are still using legacy A/AAAA records as well
as the user agent so they know who and what to target to get SRV support added.

There is no simple / reliable way to measure the client population support for
accepting CNAME co-existance.

> where the CNAME is considered a fallback when the required type doesn't

Which is a matter of opinion.  Even if support was started today it would be
a decade at least, maybe two, before you could use MX + CNAME instead of
MX + A/AAAA synthesis.  DNS servers are just not upgraded that fast.

> [email-masked]

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

---

From: JW <[email-masked]>
Date: Tue, 18 Sep 2018 16:02:38 -0400

-------- Original message --------From: Mark Andrews <[email-masked]>
> I would also expect a relatively large client population using SRV records> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups> work for lots ofother protocols.  SRV records also make it through> firewalls and IDS today.
>

Hi Mark,
I agree SRV is the obvious choice for a greenfield protocol but there is HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten scripts, lonely IOT devices, and troubleshooting guides are going to be as easy to solve as updating chrome and firefox.
Whatever the solution, I feel it should be as transparent to the client as possible.  CNAME would fit this bill but the negative impact is largely unknown.
Perhaps defining a set of default protocols for SRV where it could simulate a CNAME-like response if https/http SRV records are found?
/John
>
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, > NSW 2117, Australia
> PHONE: +61 2 9871 4742              > INTERNET: [email-masked]

---

From: Petr Špaček <[email-masked]>
Date: Wed, 19 Sep 2018 09:05:21 +0200

On 18/09/2018 22:02, JW wrote:
>> I would also expect a relatively large client population using SRV records
>> given the rate Firefox and Chrome browsers are upgraded.  SRV lookups
>> work for lots ofother protocols.  SRV records also make it through
>> firewalls and IDS today.
>>
> 
> Hi Mark,
> 
> I agree SRV is the obvious choice for a greenfield protocol but there is
> HTTP code sprinkled /everywhere/.  I can't imagine all those forgotten
> scripts, lonely IOT devices, and troubleshooting guides are going to be
> as easy to solve as updating chrome and firefox.
> 
> Whatever the solution, I feel it should be as transparent to the client
> as possible.  CNAME would fit this bill but the negative impact is
> largely unknown.

TL;DR: Experiments with CNAME @ apex showed that it is not going to work
if the domain has e.g. MX records for e-mail.

Ondrej Sury describes his experimental results in presentation here:
https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf

Petr Špaček  @  CZ.NIC

> Perhaps defining a set of default protocols for SRV where it could
> simulate a CNAME-like response if https/http SRV records are found?
> 
> /John

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 19 Sep 2018 13:01:47 +0530

> https://github.com/IETF-Hackathon/ietf102-project-presentations/blob/master/dns_hackathon-presentation.pdf

Aren't these results with current state of implementations? A cached
CNAME is expected to be matched against future type queries when
following RFC 1034/1035 behavior.

A change in behavior where resolvers expect that CNAME (as a fallback
type) will co-exist with other types will work properly.

		Mukund

---

From: Petr Špaček <[email-masked]>
Date: Wed, 19 Sep 2018 09:48:18 +0200

> type) will co-exist with other types will work properly.

Well, I started this thread because I naively thought that we can get
away with *current* behavior which kind of works because of various
non-standard workarounds. Experiment above proved me wrong so this seems
like dead-end to me - it will have similar upgrade problem as any other
new mechanism.

-- 
Petr Špaček  @  CZ.NIC

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 19 Sep 2018 13:49:54 +0530

> like dead-end to me - it will have similar upgrade problem as any other

That's fair, but it would have lower implementation complexity which is
my concern. I much prefer SRV (that Mark's been pushing for several
years now) that is simpler and elegant.

A relaxed fallback-CNAME resolver implementation would not break the
DNS, so IMO that proposal should still be carried through so some X
years later most deployed resolvers will be capable of handling it.

		Mukund