Hello
Thank you for these suggestions and advice. I will start by updating BIND to
version 9.18, then monitor the situation and provide feedback
Regards
-----Message d'origine-----
De : bind-users <bind-users-boun...@lists.isc.org> De la part de
bind-users-requ...@lists.isc.org
Envoyé : jeudi 27 juin 2024 02:04
À : bind-users@lists.isc.org
Objet : bind-users Digest, Vol 4497, Issue 1
--------------------------------------------------------------------------------------------------------------
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: rolling my own hints file (Greg Choules)
2. Re: SERVFAIL error during the evening (Michael Batchelder)
----------------------------------------------------------------------
Message: 1
Date: Wed, 26 Jun 2024 20:46:46 +0100
From: Greg Choules <gregchoules+bindus...@googlemail.com>
To: "Cuttler, Brian R (HEALTH)" <brian.cutt...@health.ny.gov>
Cc: David Farje <davidabelfa...@gmail.com>, bind-users
<bind-users@lists.isc.org>, "Hefner, Joseph (HEALTH)"
<joseph.hef...@health.ny.gov>
Subject: Re: rolling my own hints file
Message-ID:
<canseuy20ycqoyuhoc6pn-tvw+1fm+aknrxsx6qnzv0uvci9...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
> . 518400 IN 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 <gregchoules+bindus...@googlemail.com>
> *Sent:* Wednesday, June 26, 2024 12:29 PM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@lists.isc.org>
> *Subject:* Re: rolling my own hints file
>
>
>
> You don't often get email from gregchoules+bindus...@googlemail.com.
> Learn why this is important
> <https://aka.ms/LearnAboutSenderIdentification>
>
> *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/bind-users/attachments/20240626/c7433b9c/attachment-0001.htm>
------------------------------
Message: 2
Date: Thu, 27 Jun 2024 01:03:38 +0000 (UTC)
From: Michael Batchelder <mich...@isc.org>
To: bind-users <bind-users@lists.isc.org>
Subject: Re: SERVFAIL error during the evening
Message-ID: <1282367930.2472143.1719450218727.javamail.zim...@isc.org>
Content-Type: text/plain; charset=utf-8
> 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
------------------------------
Subject: Digest Footer
_______________________________________________
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
------------------------------
End of bind-users Digest, Vol 4497, Issue 1
*******************************************
--
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
