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@ash:/etc/bind# 05-Feb-2025 12:08:46.332 general: warning: checkhints:
unable to find root NS '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' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS
'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' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS
'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' in hints
05-Feb-2025 12:08:46.332 general: warning: checkhints: unable to find root NS
'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' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS
'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' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS
'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' in hints
05-Feb-2025 12:08:46.336 general: warning: checkhints: unable to find root NS
'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 <[email protected]>
Sent: Wednesday, December 18, 2024 5:04 PM
To: Cuttler, Brian R (HEALTH) <[email protected]>
Cc: bind-users <[email protected]>
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)
<[email protected]<mailto:[email protected]>> 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@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@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
<[email protected]<mailto:gregchoules%[email protected]>>
Cc: bind-users <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, December 10, 2024 9:54 AM
To: Cuttler, Brian R (HEALTH)
<[email protected]<mailto:[email protected]>>
Cc: bind-users <[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> 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@cedar:/etc/dns-root$ more db.cache
@ IN A 10.108.43.7
@ IN A 10.108.43.8
@ IN NS @
From: Greg Choules
<[email protected]<mailto:gregchoules%[email protected]>>
Sent: Tuesday, December 10, 2024 9:38 AM
To: Cuttler, Brian R (HEALTH)
<[email protected]<mailto:[email protected]>>
Cc: bind-users <[email protected]<mailto:[email protected]>>
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)
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:gregchoules%[email protected]>>
Sent: Monday, December 9, 2024 6:26 PM
To: Cuttler, Brian R (HEALTH)
<[email protected]<mailto:[email protected]>>
Cc: bind-users <[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
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
[email protected]<mailto:[email protected]>
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
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
