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. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
