On 17/09/2018 11:30, Mukund Sivaraman wrote: > Hi Ray > > On Mon, Sep 17, 2018 at 09:47:50AM +0100, Ray Bellis wrote: >> On 17/09/2018 08:43, Mukund Sivaraman wrote: >> >>> 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. >> >> .... >> >>> 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. >> >> 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. > > "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. 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
