> 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 <IP address>#53 resolving ns-open3.qq.com/AAAA for <unknown>: 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). > How can we ensure that this is a network-level issue? Through standard network troubleshooting techniques, such as packet captures and firewall log inspection. Beyond that, you'll need to inquire elsewhere, as I indicated at the top of this message, as this is a list about BIND-related issues. Michael -- 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
