Moin! On 2 Jun 2023, at 17:23, Jesus Cea wrote:
> Bind DNS server replies AAAA queries to "oauth-login.cloud.huawei.com" with > SERVFAIL and the logs shows: "Name huawei.com (SOA) not subdomain of zone > cloud.huawei.com". This is not an issue with AAAA, but with any query for a > register not present in the zone. This is not a BIND bug, it is a > misconfiguration in the "cloud.huawai.com" delegation. The delegation is fine: ; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com @nsall.huawei.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23409 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;cloud.huawei.com. IN NS ;; AUTHORITY SECTION: cloud.huawei.com. 600 IN NS ns4.dnsv5.com. cloud.huawei.com. 600 IN NS ns3.dnsv5.com. cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org. What is not fine is what the child zone thinks about itself: ; <<>> DiG 9.18.15 <<>> +nocookie NS cloud.huawei.com @gns1.huaweicloud-dns.org. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21797 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ;; QUESTION SECTION: ;cloud.huawei.com. IN NS ;; AUTHORITY SECTION: huawei.com. 300 IN SOA gns1.huaweicloud-dns.org. hwclouds\.cs.huawei.com. 1 7200 900 1209600 300 My guess is that the reason the resolution is failing is a problem with either qname minimisation or trying to validate zone cuts. If you do regular old style just follow the delegation you get a correct answer (e.g do a dig +trace). I agree that you should complain to Huawei, but the domain is certainly resolvable for most resolvers out there. > Interestingly, 8.8.8.8, 1.1.1.1, 9.9.9.9 and most other open resolvers just > ignore (or not detect) the misconfiguration. Too bad, since then the issue > goes unresolved because "it works for me!". > > This is a common misconfiguration. Would be a public service that common and > popular open DNS resolvers care about it, since a proper SERVFAIL would > prompt a fast and trivial fix in the affected DNS configurations. What would be the incentive for those public resolver or other resolvers to give back SERVFAIL? There users would no longer be able to get to the site and complain. To do something requires a concerted effort of all participants like we did with the DNS Flag days, but IMHO this misconfiguration is less severe than others we had flag days for. So long -Ralf ——- Ralf Weber _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
