> On 02/06/2023 13:59, Jesus Cea wrote: >> On 2/6/23 10:38, Cathy Almond wrote: >>> Has this just started - as in, it worked before ... when? >> >> No idea. We have been biten by this because a new client. The issue >> could be for ages, no idea.> That may be so. For the client, they're >> getting a SERVFAIL from your resolver instead of 'there is no AAAA RR >> for oauth-login.cloud.huawei.com'. > > But they should be getting a query response for the A record for the > same name, and then using that - assuming that they do actually query > for the A record too? > > Is the client actually broken because of the broken provisioning of > the servers for cloud.huawei.com, or is the issue just the plague of > log messages you're seeing? > > (Aside: it is nevertheless a pity Huawei can't set up this delegation > properly - it might just be an incompletely/improperly configured > (maybe proxying?) set of load-balancers or something of that ilk).
It definately looks like a load-balancer of some sort which doesn't sufficiently implement the DNS standards, and probably has no concept of "zone", or even knows anything about other RR types than "A". Ref. the answers you get to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. a (gives two IPv4 addresses) compared to dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. aaaa dig @ns3.dnsv5.com. cloud.huawei.com. ns Both of the two latter say "NOERROR", "answer-count=0" and refers in the authority section to ;; AUTHORITY SECTION: huawei.com. 180 IN SOA ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1686041357 3600 180 1209600 180 However, asking one of the huawei.com name servers for the name servers for cloud.huawei.com as e.g. dig @nsall.huawei.com. cloud.huawei.com. ns gives this result: ;; AUTHORITY SECTION: cloud.huawei.com. 600 IN NS gns1.huaweicloud-dns.org. cloud.huawei.com. 600 IN NS ns3.dnsv5.com. cloud.huawei.com. 600 IN NS ns4.dnsv5.com. So... Neither of those three appear to even implement the concept of "zone", and the observed behaviour ensues, as the SOA when asked for AAAA or NS records for that name results in an upwards referral, and that now triggers a SERVFAIL, as that doesn't progress the resolution of the name. Regards, - Håvard -- 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
