<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">You are wrong if you think the SOA record is only informal. It’s not, see <a href="https://www.rfc-editor.org/rfc/rfc2308">https://www.rfc-editor.org/rfc/rfc2308</a> for more details.<br><br>Then<div><br></div><div>> 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<br><br>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.</div><div><br>Ondřej<br><div dir="ltr"><div>--</div>Ondřej Surý — ISC (He/Him)<div><br></div><div>My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.</div></div><div dir="ltr"><br><blockquote type="cite">On 7. 7. 2023, at 12:35, Jakob Bohm via bind-users <bind-users@lists.isc.org> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>On 2023-07-07 12:17, Emmanuel Fusté wrote:</span><br><blockquote type="cite"><span>Le 07/07/2023 à 11:57, Jakob Bohm via bind-users a écrit :</span><br></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>On 2023-06-02 05:02, Jesus Cea wrote:</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>On 2/6/23 4:25, Mark Andrews wrote:</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Yep, some people just don’t take care with delegations. Complain to Huawei.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>Complain to the other companies you list in your followup email.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>All it takes to fix this is to change the name of the zone on the child servers</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>(ns3.dnsv5.com, gns1.huaweicloud-dns.org and ns4.dnsv5.com) from “huawei.com”</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>to “cloud.huawei.com” and perhaps adjust the NS and SOA records for the zone</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>if they are fully qualified. If there are other delegations from huawei.com</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>for other sub zones to these servers they will also need to be instantiated.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>It’s maybe 10 minute work for each subdomain to fix. It just requires someone</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>to do the work.</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>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.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>When people come to you and say that it works with Google, et al. point them at</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>https://dnsviz.net/d/cloud.huawei.com/dnssec/ which reports this error and say</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>“Here is a DNS configuration testing site and it reports the zone as broken, you</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>need to take it up with the company."</span><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>"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.</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span>https://en.wikipedia.org/wiki/Robustness_principle</span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>The robustness principle isn't the problem here. It is more that parts of the</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>bind code isapparently being strict about receiving out-of-range values in an</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>informational part ofDNS responses, then turning a mostly usable reply from</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>remote servers into a SERVFAIL of binds own making, rather than just filtering</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span>out that informational part if bind considers it worth checking at all.</span><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><span></span><br></blockquote></blockquote><blockquote type="cite"><span>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.</span><br></blockquote><blockquote type="cite"><span>So in your opinion it is purely useless, and bad data it better than nodata/error.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><span>I am saying that the SOA copy in the authority section of responses is purely</span><br><span>informational, unlike the data that provides DNSSEC signatures or even the</span><br><span>data that provides IP addresses for servers in responses to MX queries.</span><br><span></span><br><span>So from that perspective, if bind code checks that this informal copy of an</span><br><span>SOA record is for the wrong zone, it should simply filter out that SOA</span><br><span>record instead of filtering out the entire response to the actual query.</span><br><span></span><br><span>In the special case of using that SOA copy to get the negative response TTL,</span><br><span>that special use should only check that the SOA copy was provided in the</span><br><span>same DNS response as the negative response to be cached, not the diagnostic</span><br><span>data about the origin server's zone files.</span><br><span></span><br><span>In a similar way, bind should not object to the SOA mail contect being valid,</span><br><span>as a surprising number of zones actually fail to handle mail to that address</span><br><span>(I personally had to go through hoops with support people when trying to</span><br><span>coordinate a small change with another zone that I no longer had a business</span><br><span>relationship with, so validating this is useful in a compliance checker, but not</span><br><span>in a caching resolver).</span><br><span></span><br><span>Enjoy</span><br><span></span><br><span>Jakob</span><br><span>-- </span><br><span>Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com</span><br><span>Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10</span><br><span>This public discussion message is non-binding and may contain errors.</span><br><span>WiseMo - Remote Service Management for PCs, Phones and Embedded</span><br><span></span><br><span>-- </span><br><span>Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list</span><br><span></span><br><span>ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.</span><br><span></span><br><span></span><br><span>bind-users mailing list</span><br><span>bind-users@lists.isc.org</span><br><span>https://lists.isc.org/mailman/listinfo/bind-users</span><br></div></blockquote></div></body></html>