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

[Mukund Sivaraman <[e-mail]>]

On Wed, Sep 19, 2018 at 09:05:21AM +0200, Petr Špaček wrote:
> On 18/09/2018 22:02, JW wrote:
> > 
> > -------- Original message --------
> > From: Mark Andrews <[e-mail]>
> > 
> >> 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

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