CNAMEs cannot be installed as glue which makes @ SOA . . 0 0 0 0 0 @ NS ns1 ns1 CNAME host host A 1.2.3.4
problematic. Also named refuses to follow NS records that refer to CNAMEs as they can’t be used reliably and no we are not going to try and make them work in the cases where they could potentially. Manage your delegations correctly. Named will also refuse to load a zone if it detected NS referring to a CNAME. I just wish other vendors would do the same thing. Similarly stop loading zones with CNAME at the apex, or CNAME and other data generally. Resolvers shouldn’t have to put up with that sort of garbage. Nor should resolver developers have to deal with bug reports caused by different responses depending upon cached content. STD 13 said not to allow CNAME and other data. > On 23 Aug 2022, at 23:00, Tobias Fiebig <tob...@reads-this-mailinglist.com> > wrote: > > Heho, >> Vladimír Čunát wrote: >> I believe that's a wrong approach in principle and risky in practice. > > Oh, i am fully with you on this one; I just try to make sure I did not miss a > development that outdated RFC2181. > > Context: I am currently dealing with academic reviewers claiming that not > using CNAMEs for NS is, quote, "[...] by the spec, [..] true, [but] also > commonly ignored in practice. This is trivial to demonstrate with a test > domain and queries against major public DNS resolvers." This statement refers > to me/'us' excluding all NS records that are CNAME instead of A/AAAA in a > work looking at delegation issues (which is not broken delegation in > general), while citing RFC2181 Sec 10.3 as the reason for doing so. This is > what prompted me to dig into it in the first place as I will have to make an > argument why we are not considering CNAME NS as a source for potentially > successful resolution in the future. > > I would personally argue "RFC says no" still holds, and I think you already > gave me another good argument to make why exclusion of CNAME NS is valid in > our case. > > With best regards, > Tobias > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
