You are wrong if you think the SOA record is only informal. It’s not, see https://www.rfc-editor.org/rfc/rfc2308 for more details.
Then > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address mixes things that **are** important to DNS (caches) and those that **aren’t** important to the DNS. You used that as a strawman argument and that never helps to have a useful discussion. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 7. 7. 2023, at 12:35, Jakob Bohm via bind-users <bind-users@lists.isc.org> > wrote: > > On 2023-07-07 12:17, Emmanuel Fusté wrote: >>> Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit : >>> >>> >>> On 2023-06-02 05:02, Jesus Cea wrote: >>>> On 2/6/23 4:25, Mark Andrews wrote: >>>>> Yep, some people just don’t take care with delegations. Complain to >>>>> Huawei. >>>>> Complain to the other companies you list in your followup email. >>>>> >>>>> All it takes to fix this is to change the name of the zone on the child >>>>> servers >>>>> (ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from >>>>> “huawei.com” >>>>> to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the >>>>> zone >>>>> if they are fully qualified. If there are other delegations from >>>>> huawei.com >>>>> for other sub zones to these servers they will also need to be >>>>> instantiated. >>>>> >>>>> It’s maybe 10 minute work for each subdomain to fix. It just requires >>>>> someone >>>>> to do the work. >>>> >>>> I sympathize. Expertise and caring for the job is something the world is >>>> losing fast and few people care at all. Complaining to business is not >>>> going to work, because this misconfiguration works fine for 99.9% of their >>>> users, clients of more "lax" DNS resolvers. >>>> >>>> What I get from your reply is that BIND is not expected to do anything >>>> about this. It is a bit disappointed but I agree that BIND is doing the >>>> right thing. Too bad big players don't care. But I need to "solve" this, >>>> so dropping BIND (nooo!) or patching software is on my table now. >>>> >>>>> When people come to you and say that it works with Google, et al. point >>>>> them at >>>>> https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error >>>>> and say >>>>> “Here is a DNS configuration testing site and it reports the zone as >>>>> broken, you >>>>> need to take it up with the company." >>>> >>>> "Whatever, Google works and you don't. You sucks!". Few people care about >>>> doing the right thing if crap works for them. If only 8.8.8.8 cared and >>>> gave back SERVFAIL as it should, everybody would fix her configuration >>>> immediately. Postel law [*] was a mistake (be strict when sending and >>>> forgiving when receiving). Nice advice, awful consequences we will pay >>>> forever. >>>> >>>> https://en.wikipedia.org/wiki/Robustness_principle >>>> >>> >>> The robustness principle isn't the problem here. It is more that parts of >>> the >>> bind code isapparently being strict about receiving out-of-range values in >>> an >>> informational part ofDNS responses, then turning a mostly usable reply from >>> remote servers into a SERVFAIL of binds own making, rather than just >>> filtering >>> out that informational part if bind considers it worth checking at all. >>> >> It is at the core of delegation and trust model of DNS, now possibly >> enforced by DNSSEC. Peer centric resolvers are lax on this checking for all >> but the security of their users. >> So in your opinion it is purely useless, and bad data it better than >> nodata/error. >> > I am saying that the SOA copy in the authority section of responses is purely > informational, unlike the data that provides DNSSEC signatures or even the > data that provides IP addresses for servers in responses to MX queries. > > So from that perspective, if bind code checks that this informal copy of an > SOA record is for the wrong zone, it should simply filter out that SOA > record instead of filtering out the entire response to the actual query. > > In the special case of using that SOA copy to get the negative response TTL, > that special use should only check that the SOA copy was provided in the > same DNS response as the negative response to be cached, not the diagnostic > data about the origin server's zone files. > > In a similar way, bind should not object to the SOA mail contect being valid, > as a surprising number of zones actually fail to handle mail to that address > (I personally had to go through hoops with support people when trying to > coordinate a small change with another zone that I no longer had a business > relationship with, so validating this is useful in a compliance checker, but > not > in a caching resolver). > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users
-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
