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 <ma...@isc.org>
> >
> >> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
