forwarding non-domain queries
Cuttler, Brian R (HEALTH)
brian.cuttler at health.ny.gov
Thu Feb 6 19:57:52 UTC 2025
Greg,
I must have been confused. Checked my work and can't reproduce the problem.
I may have been running a tail on my named logs in the background on the primary and made the change after ssh'ing into the secondary or visa versa.
Whatever dumb thing I did, I've removed the stanza from both servers, restarted both primary and secondary and since I made those changes almost 6 hours ago have not observed those messages.
Sorry, my bad.
Thank you for your continued support,
Brian
From: Greg Choules <gregchoules+bindusers at googlemail.com>
Sent: Thursday, February 6, 2025 3:18 AM
To: Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov>
Cc: bind-users <bind-users at lists.isc.org>
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Hi Brian.
I'm confused. In previous mails you confirmed that you had removed the hint zone completely. To be absolutely clear what I meant before, it would look something like this in named.conf:
...
options {
...
};
...
# zone "." {
# type hint;
# file "db.hint";
# };
I have shown that the config for the zone dot is commented out because if it were removed completely there would be nothing for me to show you. But comment/delete amounts to the same thing: named would not process it because it doesn't need it.
Please can you send the following:
- "named.conf" in full
- The output from the command "named -V"
Cheers, Greg
On Wed, 5 Feb 2025 at 17:13, Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>> wrote:
Greg,
I did a spectacular sloppy job with the hints file.
Just realized that whether or not I have the cache file loading I'm seeing these messages at server restart.
zone ".: {
type hint;
file <whatever>;
};
root at ash:/etc/bind# 05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'a.root-servers.net<http://a.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'b.root-servers.net<http://b.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'c.root-servers.net<http://c.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'd.root-servers.net<http://d.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'e.root-servers.net<http://e.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'f.root-servers.net<http://f.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'g.root-servers.net<http://g.root-servers.net/>' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS 'h.root-servers.net<http://h.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS 'i.root-servers.net<http://i.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS 'j.root-servers.net<http://j.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS 'k.root-servers.net<http://k.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS 'l.root-servers.net<http://l.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS 'm.root-servers.net<http://m.root-servers.net/>' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: extra NS '.' in hints
I did put in place the forward records, pointing to the two primary NYS internal servers so we should be using that rather than the root servers or the domain servers.
I do still have in place some more specific forwarding files for some NYS specific zones.
I have yet to tackle my lame delegation issues, a matter of removing obsolete references to another site.
That is a completely separate matter though, as the hints issues are on my internal servers and my delegation is for my external/public server.
Thank you for your continue help,
Brian
From: Greg Choules <gregchoules+bindusers at googlemail.com<mailto:gregchoules%2Bbindusers at googlemail.com>>
Sent: Wednesday, December 18, 2024 5:04 PM
To: Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>>
Cc: bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Hi Brian.
Just checking; you removed or commented this config?
zone ".: {
type hint;
file <whatever>;
};
A couple of points about dig:
1) The syntax dig <domain> (with no @<something>) will send a query to the address(es) defined as your system DNS. On a *x system this is defined in /etc/resolv.conf with the "nameserver" command.
2) dig @<name> <domain> will cause dig to send a query for <name> to your system-defined DNS (see point 1) firstly to try and resolve <name> and get its address. If that works, then it will send a query for <domain> to that address. If the query for <name> doesn't work then the query for <address can't happen. Can you paste your complete resolv.conf file here?
3) dig @<address> <domain> (v4 or v6, if your network allows it) will send a query for <domain> to that address. I would always recommend using this form, to be certain where your queries are going.
4) dig +trace will cause dig itself to follow addresses it gets back. So whilst the first query may go to your local BIND (depending on 1, 2 or 3) subsequent queries will go to your system DNS.
May I ask why you want to use +trace at all?
Try using Wireshark to see what's actually going on.
Hope that helps.
Greg
On Wed, 18 Dec 2024 at 19:47, Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>> wrote:
Greg,
Modified by test-dns server. Removed the db.cache file and added the two forwarder IP addresses and set 'forward only".
Testing with Dig I get replies just fine.
When I run dig +trace I see failures attending to access the root servers and the tld servers for the domain, in this case I queried a .edu address.
Is there a way to prevent these errors, or was my query ill thought out or have I simply misconfigured my server?
thanks,
Brian
Dig without trace
root at intest:/etc/bind# dig @intest ns1.albany.edu<http://ns1.albany.edu/>
18-Dec-2024 14:45:04.452 queries: info: client @0x7f10f4447468 10.50.156.104#57192 (ns1.albany.edu<http://ns1.albany.edu/>): query: ns1.albany.edu<http://ns1.albany.edu/> IN A +E(0)K (10.50.156.104)
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> @intest ns1.albany.edu<http://ns1.albany.edu/>
; (3 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7225
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: b363a3c730e019cd01000000676326403a59b45d7f84c7d4 (good)
;; QUESTION SECTION:
;ns1.albany.edu<http://ns1.albany.edu/>. IN A
;; AUTHORITY SECTION:
albany.edu<http://albany.edu/>. 10234 IN SOA ns1.albany.edu<http://ns1.albany.edu/>. hostmaster.albany.edu<http://hostmaster.albany.edu/>. 3005050 3600 3600 3600000 28800
;; Query time: 0 msec
;; SERVER: 10.50.156.104#53(intest) (UDP)
;; WHEN: Wed Dec 18 14:45:04 EST 2024
;; MSG SIZE rcvd: 118
With trace
root at intest:/etc/bind# dig +trace @intest ns1.albany.edu<http://ns1.albany.edu/>
18-Dec-2024 14:40:52.623 queries: info: client @0x7f10fc0c4978 10.50.156.104#50839 (.): query: . IN NS +E(0)DK (10.50.156.104)
; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> +trace @intest ns1.albany.edu<http://ns1.albany.edu/>
; (3 servers found)
;; global options: +cmd
. 492210 IN NS b.root-servers.net<http://b.root-servers.net/>.
. 492210 IN NS e.root-servers.net<http://e.root-servers.net/>.
. 492210 IN NS g.root-servers.net<http://g.root-servers.net/>.
. 492210 IN NS i.root-servers.net<http://i.root-servers.net/>.
. 492210 IN NS k.root-servers.net<http://k.root-servers.net/>.
. 492210 IN NS d.root-servers.net<http://d.root-servers.net/>.
. 492210 IN NS h.root-servers.net<http://h.root-servers.net/>.
. 492210 IN NS a.root-servers.net<http://a.root-servers.net/>.
. 492210 IN NS f.root-servers.net<http://f.root-servers.net/>.
. 492210 IN NS m.root-servers.net<http://m.root-servers.net/>.
. 492210 IN NS c.root-servers.net<http://c.root-servers.net/>.
. 492210 IN NS j.root-servers.net<http://j.root-servers.net/>.
. 492210 IN NS l.root-servers.net<http://l.root-servers.net/>.
. 492210 IN RRSIG NS 8 0 518400 20241231050000 20241218040000 61050 . gmkXjFBTwdt2gE7B6UNsaRHVF15aVtk0+WiV4a1Wy+5E5E9SrlFxcRcL jYGAIIYQllvcyLog7VED454djTSJv58z/DawPUczxwwWEtJzb2dnFOTN HyrGSPgLbF5QcZw4mqKHzHkYaq+kAfq7IUU99wzYdHmLjRbwGuZQ40g5 B7X/hqEGZS7VDHf1ISdR0OZnymx9UX5dHS/6b+GdPCXJBO8CzyhzJwPZ S/L30j8MzmyCB9iZRvTIK5RQcYU4F+EwoGwFUM/7o0U0j5K9Gz0AKZhh 87d9+CUsdNRBHTwbuemPYcBdumTheKsvF+gzhVpM7IpLZ5mFl5xBrcUz Ce0sVg==
;; Received 1137 bytes from 10.50.156.104#53(intest) in 0 ms
edu. 172800 IN NS a.edu-servers.net<http://a.edu-servers.net/>.
edu. 172800 IN NS b.edu-servers.net<http://b.edu-servers.net/>.
edu. 172800 IN NS c.edu-servers.net<http://c.edu-servers.net/>.
edu. 172800 IN NS d.edu-servers.net<http://d.edu-servers.net/>.
edu. 172800 IN NS e.edu-servers.net<http://e.edu-servers.net/>.
edu. 172800 IN NS f.edu-servers.net<http://f.edu-servers.net/>.
edu. 172800 IN NS g.edu-servers.net<http://g.edu-servers.net/>.
edu. 172800 IN NS h.edu-servers.net<http://h.edu-servers.net/>.
edu. 172800 IN NS i.edu-servers.net<http://i.edu-servers.net/>.
edu. 172800 IN NS j.edu-servers.net<http://j.edu-servers.net/>.
edu. 172800 IN NS k.edu-servers.net<http://k.edu-servers.net/>.
edu. 172800 IN NS l.edu-servers.net<http://l.edu-servers.net/>.
edu. 172800 IN NS m.edu-servers.net<http://m.edu-servers.net/>.
edu. 86400 IN DS 35663 13 2 A2E1614291831A4746B5AC52B4B345357687271E85353082741F1CF3 D06A4C1D
edu. 86400 IN RRSIG DS 8 1 86400 20241231170000 20241218160000 61050 . hqpVkaatHhZAsmVPL9S4Cv7Ln2aGc3jnSecW9N56N5rEloBIydTeGmGV sGnISjn3BOUW+TmIULKyOS2/voPMyIVBNmkwMuWR1INtPyDDnO30M8ew 3dGkKzQLFecwV60tetwyQGsaOBT1O/O9VTeyyif27M9hYTSpZ6vd7Opp 7+9GypXEoPtcBkrBPmEtnv4naltqV9wXYsepIr/EfFMRcRjhbJ7lCnQm 41TCTb0bZh7YvyvMwsTIgT2dGTHD/C6anjWD/PZ51KL5ltMcvlZ36s9M sNWdMa5w+zksyDoXaq2y6vX++68Mt/CVXVTarwHv/Hk4rZYrN6xWhByV DJejJw==
couldn't get address for 'a.edu-servers.net<http://a.edu-servers.net/>': failure
couldn't get address for 'b.edu-servers.net<http://b.edu-servers.net/>': failure
couldn't get address for 'c.edu-servers.net<http://c.edu-servers.net/>': failure
couldn't get address for 'd.edu-servers.net<http://d.edu-servers.net/>': failure
couldn't get address for 'e.edu-servers.net<http://e.edu-servers.net/>': failure
couldn't get address for 'f.edu-servers.net<http://f.edu-servers.net/>': failure
couldn't get address for 'g.edu-servers.net<http://g.edu-servers.net/>': failure
^C^Ccouldn't get address for 'h.edu-servers.net<http://h.edu-servers.net/>': failure
couldn't get address for 'i.edu-servers.net<http://i.edu-servers.net/>': failure
couldn't get address for 'j.edu-servers.net<http://j.edu-servers.net/>': failure
couldn't get address for 'k.edu-servers.net<http://k.edu-servers.net/>': failure
couldn't get address for 'l.edu-servers.net<http://l.edu-servers.net/>': failure
couldn't get address for 'm.edu-servers.net<http://m.edu-servers.net/>': failure
dig: couldn't get address for 'a.edu-servers.net<http://a.edu-servers.net/>': no more
From: Cuttler, Brian R (HEALTH)
Sent: Tuesday, December 10, 2024 10:25 AM
To: Greg Choules <gregchoules+bindusers at googlemail.com<mailto:gregchoules%2Bbindusers at googlemail.com>>
Cc: bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Subject: RE: forwarding non-domain queries
Greg,
I have a test server I will enable the changes on before I roll them out to my primary and secondary servers.
The test server is where we make all tests and updates to zone files.
As I configure the forwarders stanza, I will remove the zone for db.cache and test it out.
Thanks,
Brian
From: Greg Choules <gregchoules+bindusers at googlemail.com<mailto:gregchoules+bindusers at googlemail.com>>
Sent: Tuesday, December 10, 2024 9:54 AM
To: Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>>
Cc: bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
And my point is that you just don't need that hint zone definition at all, especially using custom NS in an environment such as this. Maybe try commenting it out and see if it makes any difference.
Greg
On Tue, 10 Dec 2024 at 14:48, Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>> wrote:
Greg,
Yes, I do have that but it looks like this
(/etc/dns-root is a link to /etc/bind/zones carry over from an older platform)
These are the servers I want to use as the forwards for all queries that aren't either local zones or more specific zones in the internal corp network.
brian at cedar:/etc/dns-root$ more db.cache
@ IN A 10.108.43.7
@ IN A 10.108.43.8
@ IN NS @
From: Greg Choules <gregchoules+bindusers at googlemail.com<mailto:gregchoules%2Bbindusers at googlemail.com>>
Sent: Tuesday, December 10, 2024 9:38 AM
To: Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>>
Cc: bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Hi Brian.
So in your config you still have a section like this?
zone ".: {
type hint;
file <whatever>;
};
You don't need it a) at all anyway, for the reason I gave and b) because you are forwarding everything non-local and if you specify "forward only;" for both global forwarding (last resort, similar to default route) *and* all your forward zones - which I recommend you do - then the box will never recurse, so hints become moot.
I don't know anything about your network topology, addressing or routeing, so I can't guess why traffic (outbound queries from this server?) might be going to either a local router or a firewall.
As an aside, I would try to keep the forwarding to a minimum; if several things forward to the same place(s), try to aggregate them. Also, if the servers you are forwarding to are authoritative, I would use one of stub/static-stub/secondary zones instead.
Cheers, Greg
On Tue, 10 Dec 2024 at 14:22, Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>> wrote:
Greg,
Thank you.
Replacing the db.cache file seems to work for replacing the root servers, I saw traffic shift to an internal router were I had expected/previously seen traffic through the FW.
Manager noticed that secondary queries to domain servers were still going through the FW.
The forwarder zones I have in place now will continue to function since they are more specific than the new fowarders setting, that serves as a forwarder of last resort (for lack of a better term and borrowing from words I use for network routing).
Example.
Let say I have forwarder zones for health.ny.gov<http://health.ny.gov/> and ny.gov<http://ny.gov/> and its.ny.gov<http://its.ny.gov/>, those will continue to word when I add a forwarders statement for the servers that ny.gov<http://ny.gov/> servers for all more generic queries.
Many thanks,
Brian
From: Greg Choules <gregchoules+bindusers at googlemail.com<mailto:gregchoules%2Bbindusers at googlemail.com>>
Sent: Monday, December 9, 2024 6:26 PM
To: Cuttler, Brian R (HEALTH) <brian.cuttler at health.ny.gov<mailto:brian.cuttler at health.ny.gov>>
Cc: bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>>
Subject: Re: forwarding non-domain queries
ATTENTION: This email came from an external source. Do not open attachments or click on links from unknown senders or unexpected emails.
Hi Brian.
If that's what you want to do; answer authoritatively from local zones you own and forward everything else to Corporate, then you have it correct. "forwarders {...etc" and "forward only;" go in the "options" block.
Since you are forwarding everything that's not local *and* disabling recursion if forwarding fails, you don't need the hint zone at all; please delete it.
Actually you don't need it anyway, even if you are doing recursion, as Internet root hints have been built into BIND for many years. The only reason you would need a hint zone is to define custom roots for a private network that is *completely* isolated from the Internet. Your corporate network does not meet that criterion because your corporate DNS servers will be answering names from the Internet. Therefore, lose the hint zone.
I hope that helps.
Greg
On Mon, 9 Dec 2024 at 21:34, Cuttler, Brian R (HEALTH) via bind-users <bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>> wrote:
Hello, looking for a sanity check.
Inside our network we are running BIND 9.18.28-0ubuntu0.22.04.1-Ubuntu on Ubuntu 22.04.5 LTS
Currently our server serves our own zones files - A/CNAME/PTR/TXT/etc records for our domain.
We have already modified the db.cache file to reference two servers provided by our corporate IT rather than using the internet root servers.
We have numerous forwarder zones for corporate zones, both forward and reverse zones.
We are looking to no longer use recursion but rely entirely on the corporate servers for anything we would normally resolve from external servers.
I think all we need to do is create a forwarders stanza set "forwarder only" , similar to(but with the correct IPS)
forwarders {
1.2.3.4; # External DNS
1.2.3.5; # External DNS
};
forward only;
The desire is to continue to use our own zone files, and to continue to use the already established fowarder zones, but to replace recursion managed by our own internal servers with queries to ONLY the 2 servers we are already using as replacement root servers.
Seems so simple that I have to believe I've missed something.
Thanks in advance,
Brian
Brian Cuttler, System and Network Administration
Wadsworth Center, NYS Department of Health
Albany, NY 12201 POB 509
Brian.Cuttler at Health.NY.gov<mailto:Brian.Cuttler at 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 at lists.isc.org<mailto:bind-users at 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/20250206/19f56490/attachment-0001.htm>
More information about the bind-users
mailing list