On Wed, Sep 19, 2018 at 09:48:18AM +0200, Petr Špaček wrote:
>
>
> On 19/09/2018 09:31, Mukund Sivaraman wrote:
> > 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 <[email protected]>
> >>>
> >>>> 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.
>
> 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.
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
