> 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@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
