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

[Darren Ankney]

Hi Håvard,

I was curious about the additional section count dig is reporting.  I
had to do a packet capture to prove it to myself, but there is an
additional records section returned in the answer from 183.47.126.169.
It is the edns OPT pseudosection which is also shown in my dig output:

% dig +norecurse @183.47.126.169 oauth-login.cloud.huawei.com. aaaa

; <<>> DiG 9.10.6 <<>> +norecurse @183.47.126.169
oauth-login.cloud.huawei.com. aaaa
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2648
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;oauth-login.cloud.huawei.com. IN AAAA

;; AUTHORITY SECTION:
huawei.com. 180 IN SOA ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com.
1688974445 3600 180 1209600 180

;; Query time: 237 msec
;; SERVER: 183.47.126.169#53(183.47.126.169)
;; WHEN: Mon Jul 10 14:29:01 EDT 2023
;; MSG SIZE  rcvd: 136

On Mon, Jul 10, 2023 at 1:05 PM Havard Eidnes via bind-users
<bind-users at lists.isc.org> wrote:
>
> > You are wrong if you think the SOA record is only informal.
> > It's not, see https://www.rfc-editor.org/rfc/rfc2308 for more
> > details.
>
> Exactly.  The SOA record included in the "Authority section" of an
> NXDOMAIN ("name does not exist") or NODATA ("answer count" = 0,
> i.e. indicating "name exists, but no record of this type exists")
> indicates "under whose authority is this reply given", as indicated by
> the owner name of the SOA record, and the version number of that zone
> (as indicated by the version number in the SOA record).
>
> Also, following up on an earlier part of this thread:
>
> >>> It is at the core of delegation and trust model of DNS, now
> >>> possibly enforced by DNSSEC.
>
> Correct.  It's a matter of how you divide the name space into
> zones, what a minimal zone looks like from an external observer,
> and how delegations work.
>
> A minimal zone will need to contain a SOA record for the zone,
> and the NS RRset for the zone.  When a DNS name server which has
> been delegated authority for a given zone, that name server had
> better serve up the correct(!) SOA record with the correct owner
> name when supplying an NXDOMAIN or a NODATA answer.
>
> $ dig huawei.com. ns
> ...
> ;; ANSWER SECTION:
> huawei.com.             2616    IN      NS      nsall4th.huawei.cn.
> huawei.com.             2616    IN      NS      nsallsec.huawei.com.
> huawei.com.             2616    IN      NS      nsall.huawei.com.
> huawei.com.             2616    IN      NS      nsall3rd.huawei.cn.
> ...
>
> Pick one, query:
>
> $ dig @nsall.huawei.com. cloud.huawei.com. ns
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30727
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 1
> ...
> ;; 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.
> ...
>
> This means:
>
> 1) The zone cloud.huawei.com should exist
> 2) This entire zone is delegated to the named name servers (only
>    authority over the DS record for the zone name remains with the
>    parent NSes, if/when you do DNSSEC).
> 3) NXDOMAIN or NODATA responses from these name servers for names
>    in cloud.huawei.com should include the SOA record for the
>    cloud.huawei.com zone.
> 4) As stated above, both SOA and NS records for this zone should
>    be returned by these name servers (they do not, see below).
>
> Side issue: note that the "additional" count above in the last
> reply is wrong (there is no additional record in the reply).
>
> $ dig @ns4.dnsv5.com. cloud.huawei.com. ns
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15950
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> huawei.com.             180     IN      SOA     ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
> ...
>
> Again, "additional" count is wrong.  The owner name of the SOA
> record is also wrong, since the reply from nsall.huawei.com above
> states that cloud.huawei.com is a delegated zone.  It is
> therefore wrong by this name server to refer back up the zone
> tree to the parent zone's authority for a name which is clearly
> within the delegated zone.
>
> Also, it failed to respond with a copy of the NS RRset for the
> zone; it should have included that set in the answer section when
> asked explicitly about it.
>
> $ dig @ns4.dnsv5.com. yyyy.cloud.huawei.com. a
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37427
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> huawei.com.             180     IN      SOA     ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
> ...
>
> OK, here we get (correctly) a "name does not exist" error, since
> the name truly doesn't exist, but again the owner name for the
> SOA record in the response is wrong, and refers to the parent
> zone, not the zone where the name would exist if it did exist.
> Upwards referral => SERVFAIL.  You get what you deserve for not
> correctly implementing the delegation model and zone delination
> rules.
>
> $ dig @ns3.dnsv5.com. oauth-login.cloud.huawei.com. aaaa
> ...
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22050
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
> ...
> ;; AUTHORITY SECTION:
> huawei.com.             180     IN      SOA     ns3.dnsv5.com. enterprise3dnsadmin.dnspod.com. 1688974445 3600 180 1209600 180
> ...
>
> Again, "Additional" count is wrong, and the SOA owner name is
> wrong -- it should have been cloud.huawei.com, since the copy of
> the NS RRset from the huawei.com zone indicates that
> cloud.huawei.com should be a zone.
>
>
> Best 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users