Re: SERVFAIL error during the evening

[Greg Choules via bind-users]

Hi Sami.
If you can, I would set up a new BIND (test) server running the current
code - 9.18.27 - next to your current production system and compare how
they behave: current code uses NS queries for qmin rather than _... A
queries. There may still be failures, but this would allow you to pinpoint
better which domains are the problematic ones.
Packet captures are always good for showing exactly what servers send and
what they get back. There's no hiding in Wireshark!

Cheers, Greg

On Wed, 26 Jun 2024 at 07:45,  wrote:

> Hello
> Thank you for your response. I have configured qname to disabled for now.
> Once the issue is resolved, I will set it to relaxed. I have provided a
> download link for the log files and a dig +trace test for more details on
> this issue, which I do not think is related to BIND or its configuration. I
> suspected that a firewall was blocking the DNS traffic, so I bypassed the
> firewall, but the result is the same. How can we ensure that this is a
> network-level issue?
>
> download link:
>
> https://we.tl/t-M77os84duE
>
> Regards
>
> Sami
>
> -Message d'origine-
> De : bind-users  De la part de
> bind-users-requ...@lists.isc.org
> Envoyé : mardi 25 juin 2024 13:00
> À : bind-users@lists.isc.org
> Objet : bind-users Digest, Vol 4495, Issue 2
>
>
> --
> CAUTION : This email originated outside the company. Do not click on any
> links or open attachments unless you are expecting them from the sender.
>
> ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez
> pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre
> l'expéditeur.
>
> --
>
> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. Re: SERVFAIL error during the evening (Michael Batchelder)
>2. Re: qname minimization: me too :( (Stephane Bortzmeyer)
>3. Re: can I provide invalid HTTPS values for testing?
>   (Stephane Bortzmeyer)
>
>
> --
>
> Message: 1
> Date: Tue, 25 Jun 2024 06:34:42 + (UTC)
> From: Michael Batchelder 
> To: bind-users 
> Cc: sami rahal 
> Subject: Re: SERVFAIL error during the evening
> Message-ID: <646819319.2383375.1719297282567.javamail.zim...@isc.org>
> Content-Type: text/plain; charset=utf-8
>
> >> Hello Michael
> >> Thank you for your response. Here is a pcap file and some logs.
> >
> > Hello Sami,
> >
> > Your pcap shows your resolver making thousands of queries that get no
> > responses (or at least the pcap does not contain them). There's not
> > much I can say, beyond that this does not appear to be a > problem
> > related to BIND.
>
> Sami,
>
> My co-worker helpfully pointed out something I missed when reviewing your
> packet capture. A large number of your resolution failures are because your
> BIND is configured to use QNAME minimization (a.k.a. "qmin") and the
> queries are to zones whose configuration is done incorrectly and breaks
> qmin.
>
> The pcap indicates you have the 'qname-minimization strict' setting in
> your BIND configuration file. See the "qname-minimization" statement in the
> Options section of the BIND ARM (
> https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
> For the general background on qmin, read RFCs 7816 and 9156.
>
> I don't know of a reason why you would experience more qmin failures in
> the evening, other than the requests that fail are only made at that time.
> Regardless, if you want to stop the failures completely, you can change the
> 'qname-minimization strict' setting to 'qname-minimization disabled'. The
> drawback is that your queries will no longer be minimized, so all
> authoritative servers will see the full query name during recursion.
>
> As a compromise between doing nothing and fully disabling qmin, you can
> use the 'qname-minimization relaxed' setting which will try qmin and if
> BIND encounters a zone which breaks qmin, then BIND will switch to not
> doing qmin and do normal recursion (equivalent to 'qname-minimization
> disabled') for that query.
>
> Also, you should upgrade your version of BIND, as we can see that the qmin
> queries are those used in older versions of BIND.
>
> Michael
>
>
> --
>
> Message: 2
> Date: Tue, 25 Jun 2024 10:59:19 +

Re: Question about ISC BIND COPR repositories for 9.16->9.18 ESV transition

[Michał Kępień]

We have just upgraded the "bind-esv" repository from BIND 9.16.50 to
BIND 9.18.27, i.e. the same version as in the "bind" repository.

We will try to keep everyone informed about further major version
upgrades in our package repositories in the coming months.

-- 
Best regards,
Michał Kępień
-- 
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

rolling my own hints file

[Cuttler, Brian R (HEALTH) via bind-users]

Running Bind 9.18.18 on Ubuntu 22.04

We would like to use root servers within our organization rather than the 
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to 
still access the official root servers.

Wondering how I ignore the internal/build-in hints and have my own file.

Wondering if replacing the IP addresses in the db.cache file with a round-robin 
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?

Is there a supported way to do what I want to do - we do not want an forwarding 
only server, we do serve a good number of internal statis and dynamic zones but 
also want to resolve non-domain addresses or addresses we lack forwarder zones 
for from a 'root' source.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   198.41.0.4
b.root-servers.net. 518400  IN  A   170.247.170.2
c.root-servers.net. 518400  IN  A   192.33.4.12

Thanks for your help and suggestions,
Brian


Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov
518 486-1697

-- 
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

Re: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The
contents (I called the file "db.root" but the name is your choice) could be
as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is
the same name and its IP is 127.0.0.3, which happens to be another instance
of BIND I have running. Your file would contain the names and IPs of your
internal roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> 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
>
-- 
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

Re: rolling my own hints file

[David Farje]

Hi Brian R,

I built a lab to investigate DNS cache poisoning with custom root servers,
no DNSSEC.  What you're trying to do is possible in production I'm just not
sure it's recommended.
You will need to update your root.hints (or whatever file name you're using
for the root hint zone) file to point to your custom root server and you
will probably have to restart named daemon.
The root server must serve the root zone authoritatively. You can find an
example root zone in the following link
https://www.internic.net/domain/root.zone.   In my lab I had to edit this
file to use my custom TLD server for the .net domain.

Best Regards,
David Farje
On Wed, Jun 26, 2024 at 10:58 AM Cuttler, Brian R (HEALTH) via bind-users <
bind-users@lists.isc.org> wrote:

> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
> --
> 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
>
-- 
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

RE: rolling my own hints file

[Cuttler, Brian R (HEALTH) via bind-users]

Greg, David,

Thanks, much easier than what I thought it would be.

I have two "root" servers so I went with this format, allowing a round robin 
selection.
Essentially this, sorry trying to be vague on the IPs.

@ 518400   IN A xx.yy.zz..7
@ 518400   IN A xx.yy.zz..8
.   518400IN NS @

Server reloaded fine and I am able to resolve non-domain information.
Is there a flag someplace in dig or nslookup to show what root server I'm 
hitting? I don't see that in any of the named log files, I may need to add an 
ACL to log the traffic in a router to verify.
Then again - my FW is not seeing queries to any of the normal root servers, so 
that is in fact a good sign.

New root servers are managed by my parent organization and my manager asked me 
to send these queries through them. Wouldn't be performing this exercise 
otherwise.

Thank you - I think you've given me exactly what was needed.

Brian

From: Greg Choules 
Sent: Wednesday, June 26, 2024 12:29 PM
To: Cuttler, Brian R (HEALTH) 
Cc: bind-users 
Subject: Re: rolling my own hints file

You don't often get email from 
gregchoules+bindus...@googlemail.com.
 Learn why this is important

ATTENTION: This email came from an external source. Do not open attachments or 
click on links from unknown senders or unexpected emails.

Hi Brian.
Yes, you can define your own hint zone and tell BIND to use it. The contents (I 
called the file "db.root" but the name is your choice) could be as simple as:

@ 300 IN A 127.0.0.3
@ 300 IN NS @

which says for this zone (which will be called ".", coming next) the NS is the 
same name and its IP is 127.0.0.3, which happens to be another instance of BIND 
I have running. Your file would contain the names and IPs of your internal 
roots.

In the config, define the hint zone like this:

zone "." {
type hint;
file "db.root";
};

That should be all you need.
Cheers, Greg

On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users 
mailto:bind-users@lists.isc.org>> wrote:
Running Bind 9.18.18 on Ubuntu 22.04

We would like to use root servers within our organization rather than the 
actual root servers.
I updated the hints file with the names and IPs of our servers, but we seem to 
still access the official root servers.

Wondering how I ignore the internal/build-in hints and have my own file.

Wondering if replacing the IP addresses in the db.cache file with a round-robin 
of my internal IP addresses isn't the answer.
Not elegant but perhaps would work?

Is there a supported way to do what I want to do - we do not want an forwarding 
only server, we do serve a good number of internal statis and dynamic zones but 
also want to resolve non-domain addresses or addresses we lack forwarder zones 
for from a 'root' source.

;; ADDITIONAL SECTION:
a.root-servers.net. 518400  IN  A   
198.41.0.4
b.root-servers.net. 518400  IN  A   
170.247.170.2
c.root-servers.net. 518400  IN  A   
192.33.4.12

Thanks for your help and suggestions,
Brian


Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
brian.cutt...@health.ny.gov
518 486-1697

--
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
-- 
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

Re: rolling my own hints file

[Greg Choules via bind-users]

Hi Brian.
Ni problem. The server may tell the client (dig; please not nslookup)
information about where the answer came from, if 'minimal-responses' is set
to "no". Usually clients don't need to know that, so please take a look at
how m-r works:
https://bind9.readthedocs.io/en/latest/reference.html#namedconf-statement-minimal-responses

Cheers, Greg

On Wed, 26 Jun 2024 at 17:55, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:

>
>
> Greg, David,
>
>
>
> Thanks, much easier than what I thought it would be.
>
> I have two “root” servers so I went with this format, allowing a round
> robin selection.
>
> Essentially this, sorry trying to be vague on the IPs.
>
>
>
> @ 518400   IN A xx.yy.zz..7
>
> @ 518400   IN A xx.yy.zz..8
>
> .   518400IN NS @
>
>
>
> Server reloaded fine and I am able to resolve non-domain information.
> Is there a flag someplace in dig or nslookup to show what root server I’m
> hitting? I don’t see that in any of the named log files, I may need to add
> an ACL to log the traffic in a router to verify.
> Then again – my FW is not seeing queries to any of the normal root
> servers, so that is in fact a good sign.
>
>
>
> New root servers are managed by my parent organization and my manager
> asked me to send these queries through them. Wouldn’t be performing this
> exercise otherwise.
>
>
>
> Thank you – I think you’ve given me exactly what was needed.
>
>
>
> Brian
>
>
>
> *From:* Greg Choules 
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) 
> *Cc:* bind-users 
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com. Learn
> why this is important 
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails.*
>
>
>
> Hi Brian.
>
> Yes, you can define your own hint zone and tell BIND to use it. The
> contents (I called the file "db.root" but the name is your choice) could be
> as simple as:
>
>
>
> @ 300 IN A 127.0.0.3
> @ 300 IN NS @
>
>
>
> which says for this zone (which will be called ".", coming next) the NS is
> the same name and its IP is 127.0.0.3, which happens to be another instance
> of BIND I have running. Your file would contain the names and IPs of your
> internal roots.
>
>
>
> In the config, define the hint zone like this:
>
>
>
> zone "." {
> type hint;
> file "db.root";
> };
>
>
>
> That should be all you need.
>
> Cheers, Greg
>
>
>
> On Wed, 26 Jun 2024 at 15:58, Cuttler, Brian R (HEALTH) via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Running Bind 9.18.18 on Ubuntu 22.04
>
>
>
> We would like to use root servers within our organization rather than the
> actual root servers.
> I updated the hints file with the names and IPs of our servers, but we
> seem to still access the official root servers.
>
> Wondering how I ignore the internal/build-in hints and have my own file.
>
> Wondering if replacing the IP addresses in the db.cache file with a
> round-robin of my internal IP addresses isn’t the answer.
> Not elegant but perhaps would work?
>
> Is there a supported way to do what I want to do – we do not want an
> forwarding only server, we do serve a good number of internal statis and
> dynamic zones but also want to resolve non-domain addresses or addresses we
> lack forwarder zones for from a ‘root’ source.
>
>
>
> ;; ADDITIONAL SECTION:
>
> a.root-servers.net. 518400  IN  A   198.41.0.4
>
> b.root-servers.net. 518400  IN  A   170.247.170.2
>
> c.root-servers.net. 518400  IN  A   192.33.4.12
>
>
>
> Thanks for your help and suggestions,
>
> Brian
>
>
>
>
>
> Brian Cuttler, System and Network Administration
>
> Wadsworth Center, NYS Department of Health
>
> Albany, NY 12201 POB 509
>
> brian.cutt...@health.ny.gov
>
> 518 486-1697
>
>
>
> --
> 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
>
>
-- 
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

Re: SERVFAIL error during the evening

[Michael Batchelder]

> I have configured qname to disabled for now. Once the issue is resolved,
> I will set it to relaxed. I have provided a download link for the log
> files and a dig +trace test for more details on this issue, which I do
> not think is related to BIND or its configuration.

Sami,

Discussions of non-BIND issues are outside the scope of this list. If you 
believe an issue is not related to BIND, you should look for a different forum 
or resource (such as vendor technical support) whose purview is relevant to the 
problem you have.

Regarding your example dig +trace for push-rtmp-l96.douyincdn.com, you stopped 
at the point of tracing that produced this answer:

push-rtmp-l96.douyincdn.com. 600 IN CNAME   
push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com.

You will need to do the next steps of troubleshooting to see how 
push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com is resolved. To do that, 
I recommend using an excellent tool written by Shumon Huque: resolve.py 
(https://github.com/shuque/resolve). In particular, this tool will help you to 
see problems when QNAME minimization breaks due to bad zone configurations. 
Running the tool with the appropriate command-line switches:

resolve.py -mv push-rtmp-l96.douyincdn.com.d.live.cdn.chinamobile.com

will reveal multiple issues. One is:

# QUERY: com.d.live.cdn.chinamobile.com. A IN at zone 
d.live.cdn.chinamobile.com. address 139.159.208.46
#[Got answer in 0.378 s]
ERROR: NXDOMAIN: com.d.live.cdn.chinamobile.com. not found

NXDOMAIN is an incorrect response for this query; the correct response is 
NODATA (i.e. RCODE = 0, ANSWER = 0). So China Mobile's CDN has broken DNS 
configuration and this breaks QNAME minimization. And querying the domain of 
the CNAME you would get if this failure wasn't present 
(cmcczjcdnl.pushcmcc.rtmps.gslb.d.live.cdn.chinamobile.com) also produces an 
NXDOMAIN at gslb.d.live.cdn.chinamobile.com and the nodes below it. So same 
problem.

> I suspected that a firewall was blocking the DNS traffic, so I bypassed
> the firewall, but the result is the same. How can we ensure that this is
> a network-level issue?

I looked at some of your logs. The resolver.log file is mostly errors of the 
form:

resolver: notice: DNS format error from #53 resolving 
ns-open3.qq.com/ for : Name qq.com (SOA) not subdomain of zone 
ns-open3.qq.com -- invalid response

If you look at the corresponding packets in your pcap, the responses are NODATA 
with an SOA record for the qq.com zone indicating the authoritative zone. But 
if you query for the NS records from the authoritative servers, you get a reply 
that indicates the zone ns-open3.qq.com is authoritative for resolving 
ns-open3.qq.com/all QTYPEs:

# dig @59.36.132.142 ns-open3.qq.com ns

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> @59.36.132.142 ns-open3.qq.com 
ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1621
;; flags: qr aa rd ad; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4304
; COOKIE: 4cd34d4c82645709 (echoed)
;; QUESTION SECTION:
;ns-open3.qq.com.   IN  NS

;; ANSWER SECTION:
ns-open3.qq.com.86400   IN  NS  ns-tel1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-cnc1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-os1.qq.com.
ns-open3.qq.com.86400   IN  NS  ns-cmn1.qq.com.

This mismatch between the authoritative zone name in the SOA record (qq.com) 
and what the delegated nameservers claim is the authoritative zone 
(ns-open3.qq.com) causes these messages.

If you use the search for this mailing list at 
https://lists.isc.org/pipermail/bind-users/ or just use any public search 
engine you will see examples of people reporting this issue, and even citing 
this particular domain. This is not a BIND problem, it's a misconfiguration of 
records/zones. You can try contacting the administrator of the zone, 
webmas...@qq.com (per the SOA record).

And before you ask for help from this list for future issues, I strongly 
recommend you run any domain that is failing to resolve through dnsviz.net to 
ensure that you're not asking about another zone misconfiguration, rather than 
an actual BIND problem.

> download link: 
>
> https://we.tl/t-M77os84duE

This link does not appear to be a "public" link. A login appears to be 
required. In the future, please check that you are providing a public link 
(i.e. no login required) by using "private" mode of your chosen browser to see 
if a link can be accessed without prior login.

Beyond that... As I mentioned in my initial email, your version of BIND is old 
and end-of-life. You should upgrade so that any issues can be discussed and 
bugs filed if necessary. Problems found in EOL'd versions are less likely to be 
addressed by listmembers (beyond indicating that you should upgrade)