In that case, something's not right. Please send your "named.conf".
Cheers, Greg
On Thu, 6 Feb 2025 at 14:52, Cuttler, Brian R (HEALTH) <
brian.cutt...@health.ny.gov> wrote:
> Greg,
>
>
>
> Yes, I did remove that stanza and restart the daemon, clean shutdown and
> restart, not just a reload.
> Get the messages about the extra NS “.” And unable to find root files,
> restored the stanza, same error.
>
>
>
> Thanks,
>
> Brian
>
>
>
> *From:* Greg Choules <gregchoules+bindus...@googlemail.com>
> *Sent:* Thursday, February 6, 2025 3:18 AM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@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.cutt...@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@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 <gregchoules+bindus...@googlemail.com>
> *Sent:* Wednesday, December 18, 2024 5:04 PM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@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.cutt...@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@intest:/etc/bind# dig @intest ns1.albany.edu
>
> 18-Dec-2024 14:45:04.452 queries: info: client @0x7f10f4447468
> 10.50.156.104#57192 (ns1.albany.edu): query: 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
>
> ; (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. IN A
>
>
>
> ;; AUTHORITY SECTION:
>
> albany.edu. 10234 IN SOA ns1.albany.edu.
> 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
>
> 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
>
> ; (3 servers found)
>
> ;; global options: +cmd
>
> . 492210 IN NS b.root-servers.net.
>
> . 492210 IN NS e.root-servers.net.
>
> . 492210 IN NS g.root-servers.net.
>
> . 492210 IN NS i.root-servers.net.
>
> . 492210 IN NS k.root-servers.net.
>
> . 492210 IN NS d.root-servers.net.
>
> . 492210 IN NS h.root-servers.net.
>
> . 492210 IN NS a.root-servers.net.
>
> . 492210 IN NS f.root-servers.net.
>
> . 492210 IN NS m.root-servers.net.
>
> . 492210 IN NS c.root-servers.net.
>
> . 492210 IN NS j.root-servers.net.
>
> . 492210 IN NS 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.
>
> edu. 172800 IN NS b.edu-servers.net.
>
> edu. 172800 IN NS c.edu-servers.net.
>
> edu. 172800 IN NS d.edu-servers.net.
>
> edu. 172800 IN NS e.edu-servers.net.
>
> edu. 172800 IN NS f.edu-servers.net.
>
> edu. 172800 IN NS g.edu-servers.net.
>
> edu. 172800 IN NS h.edu-servers.net.
>
> edu. 172800 IN NS i.edu-servers.net.
>
> edu. 172800 IN NS j.edu-servers.net.
>
> edu. 172800 IN NS k.edu-servers.net.
>
> edu. 172800 IN NS l.edu-servers.net.
>
> edu. 172800 IN NS 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': failure
>
> couldn't get address for 'b.edu-servers.net': failure
>
> couldn't get address for 'c.edu-servers.net': failure
>
> couldn't get address for 'd.edu-servers.net': failure
>
> couldn't get address for 'e.edu-servers.net': failure
>
> couldn't get address for 'f.edu-servers.net': failure
>
> couldn't get address for 'g.edu-servers.net': failure
>
> ^C^Ccouldn't get address for 'h.edu-servers.net': failure
>
> couldn't get address for 'i.edu-servers.net': failure
>
> couldn't get address for 'j.edu-servers.net': failure
>
> couldn't get address for 'k.edu-servers.net': failure
>
> couldn't get address for 'l.edu-servers.net': failure
>
> couldn't get address for 'm.edu-servers.net': failure
>
> dig: couldn't get address for 'a.edu-servers.net': no more
>
>
>
> *From:* Cuttler, Brian R (HEALTH)
> *Sent:* Tuesday, December 10, 2024 10:25 AM
> *To:* Greg Choules <gregchoules+bindus...@googlemail.com>
> *Cc:* bind-users <bind-users@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+bindus...@googlemail.com>
> *Sent:* Tuesday, December 10, 2024 9:54 AM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@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.cutt...@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@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+bindus...@googlemail.com>
> *Sent:* Tuesday, December 10, 2024 9:38 AM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@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.cutt...@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 and ny.gov and its.ny.gov,
> those will continue to word when I add a forwarders statement for the
> servers that ny.gov servers for all more generic queries.
>
>
>
> Many thanks,
>
> Brian
>
>
>
> *From:* Greg Choules <gregchoules+bindus...@googlemail.com>
> *Sent:* Monday, December 9, 2024 6:26 PM
> *To:* Cuttler, Brian R (HEALTH) <brian.cutt...@health.ny.gov>
> *Cc:* bind-users <bind-users@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@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.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
