Re: [DNSOP] Use of CNAMEs for NS Records
Heho, > Isn't the latter selection more constrained than the former, that is, > shouldn't an "All NS fulfill X" criterion lead to lower numbers than "at > least one NS fulfills X"? I made the categories exclusive; Sorry if this was not clear. So: > > At least one NS is a CNAME and zone has more than one NS: What is missing in the description is "and not all NS are CNAMEs"; Sorry for that. I did that to separate "CNAME NS may break zone" from "there potentially is still a correctly configured NS"; Furthermore I split "All NS are CNAME" from "Only one NS and that is a CNAME" to separate out 'noise/small' zones with only one NS. The top one [At least one NS is a CNAME (Aggregate of the three distinct categories below)] is then the aggregate of the three distinct classes. With best regards, Tobias ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Use of CNAMEs for NS Records
Hi Tobias, On 8/26/22 07:31, Tobias Fiebig wrote: At least one NS is a CNAME and zone has more than one NS: Months: 83 avg: 0.0713% min: 0.0165% max: 0.8398% median: 0.0387% All NS are CNAME and zone has more than one NS: Months: 83 avg: 0.6690% min: 0.0123% max: 1.7653% median: 0.3242% Isn't the latter selection more constrained than the former, that is, shouldn't an "All NS fulfill X" criterion lead to lower numbers than "at least one NS fulfills X"? Thanks, Peter -- https://desec.io/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Use of CNAMEs for NS Records
Heho, As a follow up; Out of curiosity, me and my colleagues took a look at our passive dataset counting domains that have various forms of CNAME in NS between Jan 2015 and Dec 2021. Figured it might be interesting for some to take a look at the data; Results below. Note that over the last months of 2021 the number of affected zones went back down from the high avg/max to a (more) reasonable ~0.1% of all zones; The peaks we saw in the months/years before then were some random domain parking company holding DNS wrong and a very large DNS/Domain company holding DNS very wrong (most likely a misconfiguration including an *. IN CNAME). With best regards, Tobias Number of unique zones per month: Months: 83 avg: 294M At least one NS is a CNAME (Aggregate of the three distinct categories below): Months: 83 avg: 0.7464% min: 0.0302% max: 1.7987% median: 0.7767% At least one NS is a CNAME and zone has more than one NS: Months: 83 avg: 0.0713% min: 0.0165% max: 0.8398% median: 0.0387% All NS are CNAME and zone has more than one NS: Months: 83 avg: 0.6690% min: 0.0123% max: 1.7653% median: 0.3242% Zone has only one NS and it is a CNAME: Months: 83 avg: 0.0061% min: 0.0014% max: 0.0701% median: 0.0046% ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Use of CNAMEs for NS Records
On 8/23/22 7:00 AM, Tobias Fiebig wrote: 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. Obeying the speed limit is "[...] by the spec, [...] true, [but] also commonly ignored in practice" doesn't mean that speeding is legal. It /MAY/ be an indication that the law / speed limit or RFC / CNAME spec needs to be changed. However there is a process to go about doing both of those things. In the mean time, don't speed. Or at least don't be upset when you get stopped or your CNAME NS records fail to operate as desired. 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. I want to say "be liberal in what you accept and conservative in what you send" but "brown M". I do encourage you to stand your ground and not support CNAMEs for NS records. Or at most call it out as an "undefined behavior" that you will not expend effort to make work. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Use of CNAMEs for NS Records
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 > 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/ 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
Re: [DNSOP] Use of CNAMEs for NS Records
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/ 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
Re: [DNSOP] Use of CNAMEs for NS Records
On 23/08/2022 14.15, Tobias Fiebig wrote: Is there something I missed/should CNAME in NS be considered valid now? [...] However, it seems odd that RFC2181 and operational practice seem to diverge here. This sounds like running a few tests in the wild might imply that such setup is OK. (compliant/valid/reliable) I believe that's a wrong approach in principle and risky in practice. DNS servers are not even *obliged* to fail on non-compliant input, except for explicit requirements like in DNSSEC validation. They're *allowed* to fail, which is a thing depending on particular implementation and can change over time. --Vladimir | knot-resolver.cz ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Use of CNAMEs for NS Records
Heho, I am currently doing some measurement work related to DNS delegation. In this work, we initially decided to exclude names listed in NS that only contain a CNAME, following RFC2181 Sec. 10.3., which--as far as I can see--has not been updated, stating: 10.3. MX and NS records The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR. The reviewers now claimed that this is, indeed, no longer true, which made me setup a test-case; Indeed, I find that even though a default unbound 1.15.0 does _not_ resolve a CNAME based delegation, major other operators (q1/q8, my local ISP) indeed _do_ resolve these names. (Testcase below.) I also ran some quick atlas measurements, using probe resolvers, once with resolve-on-probe and once with defaults: Resolve on probe: https://atlas.ripe.net/frames/measurements/44061850/ data/RIPE-Atlas-measurement-44061850.json resolving: 263 not resolving: 180 Default: https://atlas.ripe.net/frames/measurements/44061849/ data/RIPE-Atlas-measurement-44061849.json resolving: 264 not resolving: 179 In both cases only counting unique configured resolvers, i.e., +- some noise for 1918/::1 et al. Is there something I missed/should CNAME in NS be considered valid now? I will take a look at the prevalence of CNAME in NS (but crunching the data takes some more time). However, it seems odd that RFC2181 and operational practice seem to diverge here. With best regards, Tobias --- Test case: RR to resolve (A/): www.dns-test-cname.wybt.net, which is: www.dns-test-cname.wybt.net. IN A 195.191.197.4 www.dns-test-cname.wybt.net. IN 2a06:d1c0:dead:1::4 dns-test-cname.wybt.net. IN NS authns.dns-test.wybt.net. dns-test-cname.wybt.net. IN CNAME authns.dns-test2.wybt.net. authns.dns-test2.wybt.net. IN A 195.191.197.27 authns.dns-test2.wybt.net. IN 2a06:d1c0:dead:1::27 With: dns-auth-test.wybt.net. IN A 195.191.197.25 dns-auth-test.wybt.net. IN 2a06:d1c0:dead:1::25 dns-auth-test2.wybt.net. IN A 195.191.197.25 dns-auth-test2.wybt.net. IN 2a06:d1c0:dead:1::25 dns-auth-test3.wybt.net. IN A 195.191.197.25 dns-auth-test3.wybt.net. IN 2a06:d1c0:dead:1::25 wybt.net, dns-test.wybt.net and dns-test2.wybt.net, dns-test-cname.wybt.net are all on different machines: wybt.net. IN NS robotns2.second-ns.de. wybt.net. IN NS robotns3.second-ns.com. wybt.net. IN NS dns.aperture-labs.org. wybt.net. IN NS dns2.aperture-labs.org. wybt.net. IN NS ns1.first-ns.de. dns-test.wybt.net. IN NS dns-auth-test.wybt.net. dns-test2.wybt.net. IN NS dns-auth-test2.wybt.net. dns-test-cname.wybt.net. IN NS authns.dns-test.wybt.net. dns-test-cname.wybt.net. IN NS authns.dns-test.wybt.net. dns-test-cname.wybt.net. IN CNAME authns.dns-test2.wybt.net. authns.dns-test2.wybt.net. IN A 195.191.197.27 authns.dns-test2.wybt.net. IN 2a06:d1c0:dead:1::27 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
