Hi Brian. You need the NS record(s) in hints because this is what a resolver wants first; the name(s) of the NS for a given zone. Regarding "@" or ".", they amount to the same thing in my example, though perhaps I was being a bit lazy and minimal.
@ represents the name of the zone (or the most recent $ORIGIN declaration), so in this case "", or the root zone. The names of the NS are specified with this, so they have no explicit names and that's what the A records are tied to. For the NS record it says that it belongs to the zone with name "@", or root (the "owner" field, on the left hand side), and the name of the NS for that zone is also @, which from above is what owns the A records. It might be easier to understand if you give the NS a name, such as: myroots.mydomain. <TTL_optional> A X.Y.Z.7 myroots.mydomain. <TTL_optional> A X.Y.Z.8 NOTE: The dot after "...mydomain" terminates the name (like "." in a sentence) and prevents it from inheriting the name of the zone. In this zone it doesn't matter because the zone is "", so there is nothing to inherit. In any other zone, it matters. Then the NS record would become either: . <TTL_optional> IN NS myroots.mydomain. or @ <TTL_optional> IN NS myroots.mydomain. "." is more conventional and is an absolute representation of the root. "@" works too, but is a relative reference to 'this zone we are in', which just happens to be the root zone. Compare this with how it's done in the Internet hints file: . 3600000 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 A.ROOT-SERVERS.NET. 3600000 AAAA 2001:503:BA3E::2:30 Hope that helps. Greg On Mon, 1 Jul 2024 at 16:05, Cuttler, Brian R (HEALTH) < brian.cutt...@health.ny.gov> wrote: > Greg, David, > > > > Another questions or two before I commit the changes to my hints file. > > > I have only the two servers, this last line isn’t necessary? Or for that > matter, possibly detrimental? > If it is, its “dot” rather than “at”? > > @ 518400 IN A xx.yy.zz..7 > > @ 518400 IN A xx.yy.zz..8 > > . 518400 IN NS @ > > > > Thank you. > > Brian > > > > *From:* bind-users <bind-users-boun...@lists.isc.org> * On Behalf Of *Cuttler, > Brian R (HEALTH) via bind-users > *Sent:* Wednesday, June 26, 2024 12:56 PM > *To:* Greg Choules <gregchoules+bindus...@googlemail.com>; David Farje < > davidabelfa...@gmail.com> > *Cc:* bind-users <bind-users@lists.isc.org>; Hefner, Joseph (HEALTH) < > joseph.hef...@health.ny.gov> > *Subject:* RE: rolling my own hints file > > > > *ATTENTION: This email came from an external source. Do not open > attachments or click on links from unknown senders or unexpected emails.* > > > > > > 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 > >
-- 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
