Issue: Name huawei.com (SOA) not subdomain of zone cloud.huawei.com -- invalid response

Havard Eidnes he at uninett.no
Tue Jun 6 13:28:44 UTC 2023


> 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


More information about the bind-users mailing list