[dns-operations] Invalid delegation for "cloud.huawai.com"

[Mark Andrews]

No, it is not delegated properly. There is a referral NS RRset but unless there is a zone configured for that name on the targeted servers the delegation is broken. 

If named accepted the incorrect SOA record in the negative response it could then learn that there is no NS RRset at cloud.Huawei.com and lookups would return NXDOMAIN intermittently.

Broken delegations do no one a favour. Papering over them does not help in the end. This should take about 10 minutes to fix as it just requires using the correct name for the zone on those three servers.  Additionally if DNSSEC is ever turned on for that zone they will need to fix it to get the DNSKEY records published. I presume all vendors reject attempts to load zones with DNSKEY RRsets not at the apex. 

-- 
Mark Andrews

> On 3 Jun 2023, at 02:56, Ralf Weber <dns at fl1ger.de> wrote:
> 
> 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
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations