Re: root hints
On 02/05/2018 23:39, Rick Dicaire wrote: > Thanks for the responses folks...so if I don't need to manage root.hints, > can I remove the line: > > zone "." IN {type hint;file "root.cache";}; > > from named.conf? Yes, you can remove it. Regards, Anand ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
Thanks for the responses folks...so if I don't need to manage root.hints, can I remove the line: zone "." IN {type hint;file "root.cache";}; from named.conf? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Wed, May 2, 2018 at 5:02 PM Greg Rivers wrote: > On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote: > > ... what is the official/best practise/recommended way to update > root.hints? > > > https://www.iana.org/domains/root/files > > But you don't really need it unless you're running an internal root; as > stated at that link, "For many pieces of software, this list comes built > into the software.". As I recall, this is true for BIND. Yup, this is built into BIND and automagically managed. Unless you have a *really* good reason to monkey with it, ‘tis best left alone these days... W > > -- > Greg Rivers > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Wednesday, May 02, 2018 16:48:00 Rick Dicaire wrote: > ... what is the official/best practise/recommended way to update root.hints? > https://www.iana.org/domains/root/files But you don't really need it unless you're running an internal root; as stated at that link, "For many pieces of software, this list comes built into the software.". As I recall, this is true for BIND. -- Greg Rivers ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
root hints
Hi, used to be you could dig > root.hints and use this file in named.conf for root.hints configuration. Some time around 9.11? the output of dig with no arguments stopped reporting the ADDITIONAL section that shows the IPs of the root servers. I've moved on to 9.12 and the dig behaviour is same as above, so for the time being I'm using: dig @a.root-servers.net. to get an output usable for root.hints. While the above works, what is the official/best practise/recommended way to update root.hints? Thanks ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
Grant Taylor wrote: > > This quite from Twitter seems appropriate: DNSSEC only protects you from > getting bad answers. If someone wants you to get no answers at all then > DNSSEC cannot help. That wasn't from Twitter, that was from me on NANOG. http://mailman.nanog.org/pipermail/nanog/2015-November/082413.html Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber, Thames, Dover: West or northwest, backing southwest for a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later in German Bight and Humber. Rough or very rough, occasionally high later in German Bight and Humber. Rain at times. Good, occasionally poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
In message <564be747.40...@tnetconsulting.net>, Grant Taylor writes: > On 11/17/2015 03:22 PM, Mark Andrews wrote: > > Given the root zone is signed and most of the TLD's are also signed > > there is little a rogue operator can do besides causing a DoS if > > you validate the returned answers. > > This quite from Twitter seems appropriate: DNSSEC only protects you > from getting bad answers. If someone wants you to get no answers at all > then DNSSEC cannot help. As I said. It doesn't protect you from a Denial of Service. > I think it would be possible for a rogue operator to completely hide > DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS. Thus it > would then be possible to do some nefarious things. > > I think the only thing that would help thwart this type of behavior is > for clients to do DNSSEC validation themselves. (It's my understanding > that most do not.) If your recursive server is validating then you are protected from a rogue root server. If your application is validating then you are protected from a rogue root server and a rogue recursive server. Mark > -- > Grant. . . . > unix || die > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/17/2015 03:22 PM, Mark Andrews wrote: Given the root zone is signed and most of the TLD's are also signed there is little a rogue operator can do besides causing a DoS if you validate the returned answers. This quite from Twitter seems appropriate: DNSSEC only protects you from getting bad answers. If someone wants you to get no answers at all then DNSSEC cannot help. I think it would be possible for a rogue operator to completely hide DNSSEC related records (NODATA) and revert to pre-DNSSEC DNS. Thus it would then be possible to do some nefarious things. I think the only thing that would help thwart this type of behavior is for clients to do DNSSEC validation themselves. (It's my understanding that most do not.) -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/17/2015 03:02 PM, Dave Warren wrote: Or, the IP formerly used as a root server could turn malicious and start offering an alternate response. This would only impact resolvers that had outdated root hints, and also happened to try that particular IP first, but it's at least a theoretical risk. I read that the old IP that H-root is currently using will stay under the Army's control and will never be used for a DNS server again. Does anyone know if any of the other root servers that have changed their address have similarly quarantined the old IPs? -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/17/2015 04:10 PM, Darcy Kevin (FCA) wrote: No default route to Internet, internal-root architecture; when you think this through, it's pretty obvious that the ability to explicitly specify "hints" is a mandatory feature of any enterprise-strength DNS product. There is noting that prevents me from applying AS112 methodologies to the root DNS servers. (Network black magic.) -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/17/2015 02:21 AM, Ray Bellis wrote: It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. Valid point. Thanks Ray. Otherwise, I might be tempted to leverage some network black magic. -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/17/2015 02:15 AM, Cathy Almond wrote: If someone *could* maliciously replace a file on your DNS server with a blank one, you have more problems than just a blank root hints file don't you? Very likely. But not guaranteed. }:-> -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: root hints operation
No default route to Internet, internal-root architecture; when you think this through, it's pretty obvious that the ability to explicitly specify "hints" is a mandatory feature of any enterprise-strength DNS product. - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Joseph S D Yao Sent: Tuesday, November 17, 2015 10:25 AM To: Ray Bellis Cc: bind-users@lists.isc.org Subject: Re: root hints operation On 2015-11-17 04:21, Ray Bellis wrote: > On 17/11/2015 02:09, Grant Taylor wrote: >> On 11/16/2015 06:56 PM, /dev/rob0 wrote: >>> You either specify a hints file to use, or use the compiled-in root >>> hints. >> >> Interesting. I was not aware that it was an exclusive or type >> situation. > > It's important that they're exclusive - it would be very much harder > to build an isolated test bed (with "fake" root hints) if BIND > insisted on always trying to reach all of the compiled-in root hints. ... Or a real root hints file that differed from the compiled-in version, either in the current case (where there is a lot of overlap so it actually wouldn't matter that much) or for a private internet (lower-case 'i') with no overlap. Joe Yao ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
In message <564ba6e9.2050...@hireahit.com>, Dave Warren writes: > On 2015-11-17 14:13, Mark Andrews wrote: > > In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: > >> On 2015-11-16 18:09, Grant Taylor wrote: > >>> It's my understanding that ALL of the root servers would have to > >>> change all of their addresses at the same time for DNS to be impacted. > >> Or, the IP formerly used as a root server could turn malicious and start > >> offering an alternate response. This would only impact resolvers that > >> had outdated root hints, and also happened to try that particular IP > >> first, but it's at least a theoretical risk. > > Which is why those addresses get held back from reassignment. It is a > > known risk that is mitigated. > > Understood and agreed, there's little real-world risk, but it's > important to understand that this risk is mitigated by policy, not by > technology. Given the root zone is signed and most of the TLD's are also signed there is little a rogue operator can do besides causing a DoS if you validate the returned answers. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 2015-11-17 14:13, Mark Andrews wrote: In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: On 2015-11-16 18:09, Grant Taylor wrote: It's my understanding that ALL of the root servers would have to change all of their addresses at the same time for DNS to be impacted. Or, the IP formerly used as a root server could turn malicious and start offering an alternate response. This would only impact resolvers that had outdated root hints, and also happened to try that particular IP first, but it's at least a theoretical risk. Which is why those addresses get held back from reassignment. It is a known risk that is mitigated. Understood and agreed, there's little real-world risk, but it's important to understand that this risk is mitigated by policy, not by technology. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
In message <564ba3e3.9060...@hireahit.com>, Dave Warren writes: > On 2015-11-16 18:09, Grant Taylor wrote: > > It's my understanding that ALL of the root servers would have to > > change all of their addresses at the same time for DNS to be impacted. > > Or, the IP formerly used as a root server could turn malicious and start > offering an alternate response. This would only impact resolvers that > had outdated root hints, and also happened to try that particular IP > first, but it's at least a theoretical risk. Which is why those addresses get held back from reassignment. It is a known risk that is mitigated. > -- > Dave Warren > http://www.hireahit.com/ > http://ca.linkedin.com/in/davejwarren > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 2015-11-16 18:09, Grant Taylor wrote: It's my understanding that ALL of the root servers would have to change all of their addresses at the same time for DNS to be impacted. Or, the IP formerly used as a root server could turn malicious and start offering an alternate response. This would only impact resolvers that had outdated root hints, and also happened to try that particular IP first, but it's at least a theoretical risk. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 2015-11-17 04:21, Ray Bellis wrote: On 17/11/2015 02:09, Grant Taylor wrote: On 11/16/2015 06:56 PM, /dev/rob0 wrote: You either specify a hints file to use, or use the compiled-in root hints. Interesting. I was not aware that it was an exclusive or type situation. It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. ... Or a real root hints file that differed from the compiled-in version, either in the current case (where there is a lot of overlap so it actually wouldn't matter that much) or for a private internet (lower-case 'i') with no overlap. Joe Yao ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 17/11/2015 02:09, Grant Taylor wrote: > On 11/16/2015 06:56 PM, /dev/rob0 wrote: >> You either specify a hints file to use, or use the compiled-in root >> hints. > > Interesting. I was not aware that it was an exclusive or type situation. It's important that they're exclusive - it would be very much harder to build an isolated test bed (with "fake" root hints) if BIND insisted on always trying to reach all of the compiled-in root hints. Ray ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 17/11/2015 02:31, Grant Taylor wrote: ... > The idea that a (maliciously) blank root.hints file would prevent BIND > from using the compiled in version is new to me. If someone *could* maliciously replace a file on your DNS server with a blank one, you have more problems than just a blank root hints file don't you? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/16/2015 07:20 PM, Barry Margolin wrote: Did you think it combined the file with the built-in list? I hadn't given much thought to how the built in would or would not be combined with the contents of the root.hints file. I always took it that BIND would fall back to the compiled in version if nothing else succeeded. It is. I'm not even sure you misunderstood the XOR, since you wrote that it tries each server in the root hints file until it gets a successful response. That suggests that you understood that the built-in list is used in place of the file if no file is provided. The idea that a (maliciously) blank root.hints file would prevent BIND from using the compiled in version is new to me. -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
In article , Grant Taylor wrote: > On 11/16/2015 06:56 PM, /dev/rob0 wrote: > > You either specify a hints file to use, or use the compiled-in root > > hints. > > Interesting. I was not aware that it was an exclusive or type situation. Did you think it combined the file with the built-in list? > Based on the way I read the link, I still believe my original post is > accurate. (Save for the XOR.) It is. I'm not even sure you misunderstood the XOR, since you wrote that it tries each server in the root hints file until it gets a successful response. That suggests that you understood that the built-in list is used in place of the file if no file is provided. -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On 11/16/2015 06:56 PM, /dev/rob0 wrote: You either specify a hints file to use, or use the compiled-in root hints. Interesting. I was not aware that it was an exclusive or type situation. Since the beginning of DNS, there has not been enough change to root hints so as to cause operational problems. Agreed. It's my understanding that ALL of the root servers would have to change all of their addresses at the same time for DNS to be impacted. I think this should answer your questions: I was hoping for a thumbs up or thumbs down, not to be pointed at another document. Based on the way I read the link, I still believe my original post is accurate. (Save for the XOR.) -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints operation
On Mon, Nov 16, 2015 at 06:37:36PM -0700, Grant Taylor wrote: > In light of the upcoming H-root server changing addresses I wanted > to confirm how BIND uses root hints. > > It's my understanding that BIND has a compiled in version of the > root hints -and- a root hints file that can easily be updated. You either specify a hints file to use, or use the compiled-in root hints. > This information is used to prime named as it starts up in such as > it takes an IP for one of the root servers and attempts a to query > to update the root hint server name to IP mappings. I believe that > named will cycle through all of the IPs in the root hints file > until it finds a server that it can query and update all of the > root server names / IPs in memory. From and then continues running > with that updated information. > > As such, I think BIND will continue operating with little, if any, > ill effect if people don't update their root hints file > immediately. (Though ideally people should update.) Since the beginning of DNS, there has not been enough change to root hints so as to cause operational problems. > Will someone take a moment and confirm, or correct, my > understanding of how root hints work in BIND? I think this should answer your questions: https://www.isc.org/blogs/h-root-will-change-its-addresses-on-1-december-2015-what-does-this-mean-for-you/ -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
root hints operation
In light of the upcoming H-root server changing addresses I wanted to confirm how BIND uses root hints. It's my understanding that BIND has a compiled in version of the root hints -and- a root hints file that can easily be updated. This information is used to prime named as it starts up in such as it takes an IP for one of the root servers and attempts a to query to update the root hint server name to IP mappings. I believe that named will cycle through all of the IPs in the root hints file until it finds a server that it can query and update all of the root server names / IPs in memory. From and then continues running with that updated information. As such, I think BIND will continue operating with little, if any, ill effect if people don't update their root hints file immediately. (Though ideally people should update.) Will someone take a moment and confirm, or correct, my understanding of how root hints work in BIND? -- Grant. . . . unix || die ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root hints
Am 06.10.2015 um 19:42 schrieb Jack Tavares: Since the H root server IP address will be changing I have a question: http://h.root-servers.org/renumber.html how does bind get the root servers these days? I think the code includes a set. yes, a hardcoded fallback Is there a provision to query a known address to get an update? AFAIK no (I also know that I can define a hints file locally) i am using a script like below to deploy the hint-files well, not terrible happy about non-TLS at the moment [root@buildserver:~]$ cat /buildserver/distribute-dns-root-zones.sh #!/usr/bin/bash if wget --quiet ftp://ftp.internic.net/domain/named.cache --output-document=/var/named/chroot/var/named/named.ca; then cat /var/named/chroot/var/named/named.ca | grep "last update" chmod 0644 /var/named/chroot/var/named/named.ca ** rsync to nameservers ** fi signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root hints
On Tue, Oct 06, 2015 at 05:42:52PM +, Jack Tavares wrote: > Since the H root server IP address will be changing I have a question: > http://h.root-servers.org/renumber.html > > how does bind get the root servers these days? > I think the code includes a set. There's a copy of the hints built in to named (it's in lib/dns/rootns.c). We update it periodically (most recently to add an for D root a few years ago), and will do so again when the H address changes. IIRC that change is planned for the end of this year, so the change will be included in BIND 9.9.9, 9.10.4, and 9.11.0. > Is there a provision to query a known address to get an update? When named starts up, if it's running as an iterative resolver (as opposed to a forwarder), the first thing it does is send a "priming" query to the hint servers looking for a new up-to-date NS RRset. In servers that still have the old hints, H wouldn't respond to the priming query, but all the other root servers would, and named would learn the new address for H from one of them, so H will work fine thereafter. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Root hints
Since the H root server IP address will be changing I have a question: http://h.root-servers.org/renumber.html how does bind get the root servers these days? I think the code includes a set. Is there a provision to query a known address to get an update? (I also know that I can define a hints file locally) Thank you -- Jack Tavares ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
On 8/28/2013 5:25 AM, Cathy Almond wrote: On 27/08/13 21:28, Kevin Darcy wrote: On 8/27/2013 1:07 PM, Colin Harvey wrote: My environment is firewalled from the real world. For queries on zones to which I'm not master, I want to recurse to a corporate server. nslookup some.internal.hostname.com internal.corporate.server works fine. nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic how your nameserver would talk to the other nameserver, use the options +norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size from the default, in which case, plug in that value instead). Setting "." to use this internal server in the root.hints file does not. In fact I do not even see my system trying to recurse. (I'm looking at network traffic with a sniffer.) My root.hints: .600INNSinternal.corporate.server. internal.corporate.server.600INA192.168.1.1 Do you have recursion enabled? Alternatively I've setup a forwarding zone in named.conf to query 192.168.1.1 for 'internal.hostname.com'. Ugh, don't do that. Forwarding is for getting around network restrictions or limitations, and you haven't (so far) indicated that you have any of those to deal with. If you're really playing in an internal-only name space with no queries ever going out to the Internet name space, then in order to do recursion properly in that environment, you should really have access to a nameserver that is essentially taking the role of of the root nameservers - an 'internal root'. It should be authoritative for "." and then in its root zone, have delegations to your internal namespace nameservers for the internal top level zones. It might also be authoritative for some of those internal zones itself too. On your recursive server, you configure the internal root nameserver in your hints zone, and then when you first need to recurse, it will 'prime' the roots by querying that server for the NS records for '.'. If that server (or those servers) doesn't (don't) respond authoritatively with the necessary information, then your server isn't going to be able to do recursion very successfully. :-( If you don't have internal roots, then you don't really have any option except to use forwarding to direct queries to another nameserver to deal with where you don't have something else in place to resolve queries for that specific zone. Bear in mind that you (usually!) can't control what names your clients will query you for if you're 'their' recursive server, so you need some way to handle they throw at you. That's a risky choice, since when you forward to another server by default, you trust it with your name resolution. As we know, trust isn't always transitive. If they forward, and they forward, and so on, eventually you may find that your resolution is going out to the Internet, your users are forming VPN tunnels over DNS, and bypassing all of your security controls. So, my preference in this situation would be to define a root zone locally. - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
On 27/08/13 21:28, Kevin Darcy wrote: > On 8/27/2013 1:07 PM, Colin Harvey wrote: >> My environment is firewalled from the real world. For queries on >> zones to which I'm not master, I want to recurse to a corporate >> server. nslookup some.internal.hostname.com internal.corporate.server >> works fine. > nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic > how your nameserver would talk to the other nameserver, use the options > +norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size > from the default, in which case, plug in that value instead). > >> Setting "." to use this internal server in the root.hints file does >> not. In fact I do not even see my system trying to recurse. (I'm >> looking at network traffic with a sniffer.) >> My root.hints: >> .600INNSinternal.corporate.server. >> internal.corporate.server.600INA192.168.1.1 > Do you have recursion enabled? >> Alternatively I've setup a forwarding zone in named.conf to query >> 192.168.1.1 for 'internal.hostname.com'. > Ugh, don't do that. Forwarding is for getting around network > restrictions or limitations, and you haven't (so far) indicated that you > have any of those to deal with. If you're really playing in an internal-only name space with no queries ever going out to the Internet name space, then in order to do recursion properly in that environment, you should really have access to a nameserver that is essentially taking the role of of the root nameservers - an 'internal root'. It should be authoritative for "." and then in its root zone, have delegations to your internal namespace nameservers for the internal top level zones. It might also be authoritative for some of those internal zones itself too. On your recursive server, you configure the internal root nameserver in your hints zone, and then when you first need to recurse, it will 'prime' the roots by querying that server for the NS records for '.'. If that server (or those servers) doesn't (don't) respond authoritatively with the necessary information, then your server isn't going to be able to do recursion very successfully. :-( If you don't have internal roots, then you don't really have any option except to use forwarding to direct queries to another nameserver to deal with where you don't have something else in place to resolve queries for that specific zone. Bear in mind that you (usually!) can't control what names your clients will query you for if you're 'their' recursive server, so you need some way to handle they throw at you. For the 'known' other internal zones, you can use zone type static-stub to 'tell' your recursive server who the authoritative servers are - and you should just need to configure the top level(s) - everything else below those should then be resolved recursively, starting with those static-stub servers as the 'nearest' authoritative servers if there are none nearer already in cache. And finally, although this probably isn't the cause of your problems, you're using an RFC1918 network, so depending on what else you have configured, you might be tripping over the automatic empty zones that named loads. There's also a bug (to be fixed in upcoming releases) where adding a manually configured zone of type forward as opposed to any other type isn't disabling the creation of the automatic zone. Take a look at "disable-empty-zone" in the ARM, and also https://kb.isc.org/article/AA-00800 (you'll need to register to view it, but registration is open to all). There's also https://kb.isc.org/article/AA-00803 that includes a feedback comment about the bug that was recently uncovered. And yes - do use dig (from your recursive server) rather than nslookup for testing - with options that you've previously had recommended to you. Cathy ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
On 8/27/2013 1:07 PM, Colin Harvey wrote: My environment is firewalled from the real world. For queries on zones to which I'm not master, I want to recurse to a corporate server. nslookup some.internal.hostname.com internal.corporate.server works fine. nslookup is a terrible DNS troubleshooting tool. Try dig. And to mimic how your nameserver would talk to the other nameserver, use the options +norec and +bufsiz=4096 (unless you've changed your EDNS0 buffer size from the default, in which case, plug in that value instead). Setting "." to use this internal server in the root.hints file does not. In fact I do not even see my system trying to recurse. (I'm looking at network traffic with a sniffer.) My root.hints: .600INNSinternal.corporate.server. internal.corporate.server.600INA192.168.1.1 Do you have recursion enabled? Alternatively I've setup a forwarding zone in named.conf to query 192.168.1.1 for 'internal.hostname.com'. Ugh, don't do that. Forwarding is for getting around network restrictions or limitations, and you haven't (so far) indicated that you have any of those to deal with. - Kevin ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
dig +trace host.internal.hostname.com responds with a list of authoritative nameservers for the zone and the error "dig: couldn't get address for ns1.corporate.hostname.com" where the error cycles through all four of the authoritative nameservers. Also ns1.corporate.hostname.com is not 192.168.1.1. Colin From: Colin Harvey To: "wbr...@e1b.org" Cc: "bind-users-bounces+wbrown=e1b@lists.isc.org" ; bind users Sent: Tuesday, August 27, 2013 2:13 PM Subject: Re: redirecting root hints to fake internal root server Thanks. But I already have that option for the internal.hostname.com zone. Still not seeing traffic going to 192.168.1.1. Colin From: "wbr...@e1b.org" To: Colin Harvey Cc: bind users ; bind-users-bounces+wbrown=e1b@lists.isc.org Sent: Tuesday, August 27, 2013 1:20 PM Subject: Re: redirecting root hints to fake internal root server From: Colin Harvey > My environment is firewalled from the real world. For queries on > zones to which I'm not master, I want to recurse to a corporate > server. nslookup some.internal.hostname.com > internal.corporate.server works fine. Setting "." to use this > internal server in the root.hints file does not. In fact I do not > even see my system trying to recurse. (I'm looking at network > traffic with a sniffer.) > > My root.hints: > > . 600 IN NS internal.corporate.server. > internal.corporate.server. 600 IN A 192.168.1.1 > > > Alternatively I've setup a forwarding zone in named.conf to query > 192.168.1.1 for 'internal.hostname.com'. When monitoring the > network for udp data over port 53, I'm not even seeing the query > being forwarded. Why? Add these lines to your options section: forward only; forwarders {192.168.1.1;}; see ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567 Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
Thanks. But I already have that option for the internal.hostname.com zone. Still not seeing traffic going to 192.168.1.1. Colin From: "wbr...@e1b.org" To: Colin Harvey Cc: bind users ; bind-users-bounces+wbrown=e1b@lists.isc.org Sent: Tuesday, August 27, 2013 1:20 PM Subject: Re: redirecting root hints to fake internal root server From: Colin Harvey > My environment is firewalled from the real world. For queries on > zones to which I'm not master, I want to recurse to a corporate > server. nslookup some.internal.hostname.com > internal.corporate.server works fine. Setting "." to use this > internal server in the root.hints file does not. In fact I do not > even see my system trying to recurse. (I'm looking at network > traffic with a sniffer.) > > My root.hints: > > . 600 IN NS internal.corporate.server. > internal.corporate.server. 600 IN A 192.168.1.1 > > > Alternatively I've setup a forwarding zone in named.conf to query > 192.168.1.1 for 'internal.hostname.com'. When monitoring the > network for udp data over port 53, I'm not even seeing the query > being forwarded. Why? Add these lines to your options section: forward only; forwarders {192.168.1.1;}; see ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567 Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system.___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: redirecting root hints to fake internal root server
From: Colin Harvey > My environment is firewalled from the real world. For queries on > zones to which I'm not master, I want to recurse to a corporate > server. nslookup some.internal.hostname.com > internal.corporate.server works fine. Setting "." to use this > internal server in the root.hints file does not. In fact I do not > even see my system trying to recurse. (I'm looking at network > traffic with a sniffer.) > > My root.hints: > > .600INNSinternal.corporate.server. > internal.corporate.server.600INA192.168.1.1 > > > Alternatively I've setup a forwarding zone in named.conf to query > 192.168.1.1 for 'internal.hostname.com'. When monitoring the > network for udp data over port 53, I'm not even seeing the query > being forwarded. Why? Add these lines to your options section: forward only; forwarders {192.168.1.1;}; see ftp://ftp.isc.org/isc/bind9/9.9.3-P2/doc/arm/Bv9ARM.ch06.html#id2578567 Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
redirecting root hints to fake internal root server
My environment is firewalled from the real world. For queries on zones to which I'm not master, I want to recurse to a corporate server. nslookup some.internal.hostname.com internal.corporate.server works fine. Setting "." to use this internal server in the root.hints file does not. In fact I do not even see my system trying to recurse. (I'm looking at network traffic with a sniffer.) My root.hints: .600INNSinternal.corporate.server. internal.corporate.server.600INA192.168.1.1 Alternatively I've setup a forwarding zone in named.conf to query 192.168.1.1 for 'internal.hostname.com'. When monitoring the network for udp data over port 53, I'm not even seeing the query being forwarded. Why? Thanks___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Noisy messages from BIND about root hints change
On 07/01/13 17:14, Chris Thompson wrote: > One (but only one) of our recursive nameservers, running BIND 9.8.3-P4 > we got a whole lot of messages in the log as a result of last week's change > of address for d.root-servers.net: > > Jan 4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (128.8.10.90) missing from hints > Jan 4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints > Jan 4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (128.8.10.90) missing from hints > Jan 4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints > > [... 1972 pairs of messages omitted ...] > > Jan 4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (128.8.10.90) missing from hints > Jan 4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints > Jan 4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (128.8.10.90) missing from hints > Jan 4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: > checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints > > And then they stopped. > > Now I can more or less work out what provoked the first message. We had > already changed our root hints file the previous day (and done an rndc > reconfig) but the old A record for d.root-servers.net was still in the > cache (and was still there much later on 4 January as I explicitly did > an rndc flushname on it for other reasons). One of our regular checking > jobs at 06:24 will have used this recursive nameserver to look up the > NS records for "." and the address records for the *.root-servers.net > names so referenced. > > But why did it keep going on and on about it? And what made it stop? > Has anyone else seen anything similar? I've seen one other report of repeating messages from checkhints - but they also 'went away' (temporarily seen due to the transition of addresses, and fixed by fixing the hints file to have D-root's new IPv4 address). Differences between what's in the hints file and what's returned when querying the root nameservers should only be 'spotted' by checkhints when the cache is re-primed with the list of root nameservers - and that should only happen when the roots have all expired from the cache. What happens then is that the next time that a root nameserver needs to be sent a query, named goes back to the hints and uses those to query for an up-to-date list of root nameservers and their addresses - and it's then that it will warn on any differences. Now - on a busy cache, it would not be that unusual not to send queries to root nameservers very often once you've been up and running for awhile and have handled queries for all of the main TLDs. So the theory I have for this is that the caches reporting a spate of repeated warnings are ones in which there is a fairly conservative max-cache-size set and then sufficient cache 'thrash' that the root RRset is getting expired out of cache on the basis of 'least recently used' (LRU cache management) to make space for other new entries. Might that ring true in your case? (Although - by 4th January - the new address should have been being served by all the official root nameservers. So it's still a bit odd why you saw this at all, and moreover that you didn't see it before the switch - so I'm not entirely convinced by the theory I'm putting forward to you, and wonder if there was some other factor in play too). Cathy ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Noisy messages from BIND about root hints change
One (but only one) of our recursive nameservers, running BIND 9.8.3-P4 we got a whole lot of messages in the log as a result of last week's change of address for d.root-servers.net: Jan 4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (128.8.10.90) missing from hints Jan 4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints Jan 4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (128.8.10.90) missing from hints Jan 4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints [... 1972 pairs of messages omitted ...] Jan 4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (128.8.10.90) missing from hints Jan 4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints Jan 4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (128.8.10.90) missing from hints Jan 4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning: checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints And then they stopped. Now I can more or less work out what provoked the first message. We had already changed our root hints file the previous day (and done an rndc reconfig) but the old A record for d.root-servers.net was still in the cache (and was still there much later on 4 January as I explicitly did an rndc flushname on it for other reasons). One of our regular checking jobs at 06:24 will have used this recursive nameserver to look up the NS records for "." and the address records for the *.root-servers.net names so referenced. But why did it keep going on and on about it? And what made it stop? Has anyone else seen anything similar? -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root hints updates
On 09/06/12 07:06, Timothe Litt wrote: In doing some system administration, I realized that I have a tool that might be generally useful - ISC is welcome to add it to contribs. Hopefully the attachment will make it through the mailing list server. This is a script to automagically update the root hints file. There are a bunch of these floating around the internet; most don't work; those that do don't work well. I wrote this several years ago; it's worked for me. It will FTP the new file - or, if you value speed over comments, will fabricate a copy from the existing root servers - yes, it will deal with the case that a root server is renumbered or returns partial data. It acts as a SYS V init script so that it runs on every boot; It's smart enough to requeue itself hourly if it fails to get data. It verifies FTP transfers. It also runs as a cron job monthly to catch any updates. It will log actions to syslog; will also send mail if you like. It preserves file ownership and the timestamp of last download. It knows to run rndc reconfig when it gets a new file. (And not when nothing has changed.) I did some cleanup for this release, but the core logic has run for several years on Fedora and random embedded Linuxes. For me, it's install & forget. README: Install it (or create a link to it) in /etc/init.d/ as update_root. E.g. if it's in /usr/local/sbin, then ln -sf ../../../usr/local/sbin/update_root /etc/init.d/ Then execute /etc/init.d/update_root setup and /etc/init.d/update_root Create a /etc/sysconfig/update_root file if you want a non-default configuration. The most useful configuration variables are: # Undefined uses FTP (default) #USEDNS=yes # Root file name HINT=ROOT.HINT # named control address (undef for none) NAMEDRNDC="127.0.0.1" # Root file owner DEFAULTOWNER="named:named" (When there's no file; normally copies from old) # Define for e-mail recipient (default is undef => none) #TO=hostmas...@example.com # Cron directories CRONMONTHLY="/etc/cron.monthly" CRONHOURLY="/etc/cron.hourly" # No IPV6? This may speed FTP connections. WGET="$WGET -4" Other parameters are in the first ~80 lines of the script. The script commands are: start - check for update (default if no command) setup - run chkconfig and link to monthly queue (don't if you use crontab) status - list current file One caution: Do not copy the script using copy & paste; there are places where literal tabs and spaces are important. [Some environments have very limited regexps.] It's freely redistributable, with the usual caveat that there is no warranty or promise of support & that you use it at your own risk. Enjoy. Timothe Litt ACM Distinguished Engineer - This communication may not represent the ACM or my employer's views, if any, on the matters discussed. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Nice script. Now my pet peeve time. This file: http://www.internic.net/domain/named.root indicates the named.root file should be available at ftp.internic.net or rs.internic.net. It's only at ftp.internic.net. This page has a pointer to root hints file(via FTP) that does not work either. The http version shows the above mistake. It's not available at rs.internic.net. http://www.iana.org/domains/root/files Lyle Giese LCR Computer Services, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Root hints updates
Timothe Litt wrote: > > Until someone authoritative tells me that BIND manages the hints file on its > own, I'm taking the conservative route and letting my tool run > BTW, I do have systems that come on-line every 5 years or so. Automation is > good :-) Well, I'm not authoritative, but I don't have a root hints file on my systems. Instead I rely on the hints built in to named, which get updated when I update BIND. Also it doesn't matter if the hints are out of date since the root name server list changes very infrequently and you only need one of them to work for named to start OK. Tony. -- f.anthony.n.finchhttp://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Root hints updates
>> Since the first thing BIND does at startup is to check the root NS set, and since DNSSEC guarantees that it is genuine, is there still an use for this tool? Unless bind updates the hint file as a result of these checks, yes. It's not a question of authenticity; named has to start somewhere to find the root NS; this is the bootstrap cache. It wouldn't be a bad thing if bind did the update itself (sort of like DNSSECS's 5011 for keys). But so far as I know, it doesn't. Since I run the tool, I can't say that I've ever seen a message from BIND complaining about the root hints being out of date. I know there was a root hints update last June... Does it sync to what it finds, or just complain? Until someone authoritative tells me that BIND manages the hints file on its own, I'm taking the conservative route and letting my tool run BTW, I do have systems that come on-line every 5 years or so. Automation is good :-) - This communication may not represent my employer's views, if any, on the matters discussed. -Original Message- From: Stephane Bortzmeyer [mailto:bortzme...@nic.fr] Sent: Thursday, September 06, 2012 09:08 To: Timothe Litt Cc: bind-users@lists.isc.org Subject: Re: Root hints updates On Thu, Sep 06, 2012 at 08:06:45AM -0400, Timothe Litt wrote a message of 466 lines which said: > This is a script to automagically update the root hints file. Since the first thing BIND does at startup is to check the root NS set, and since DNSSEC guarantees that it is genuine, is there still an use for this tool? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root hints updates
On Thu, Sep 06, 2012 at 08:06:45AM -0400, Timothe Litt wrote a message of 466 lines which said: > This is a script to automagically update the root hints file. Since the first thing BIND does at startup is to check the root NS set, and since DNSSEC guarantees that it is genuine, is there still an use for this tool? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Root hints updates
In doing some system administration, I realized that I have a tool that might be generally useful - ISC is welcome to add it to contribs. Hopefully the attachment will make it through the mailing list server. This is a script to automagically update the root hints file. There are a bunch of these floating around the internet; most don't work; those that do don't work well. I wrote this several years ago; it's worked for me. It will FTP the new file - or, if you value speed over comments, will fabricate a copy from the existing root servers - yes, it will deal with the case that a root server is renumbered or returns partial data. It acts as a SYS V init script so that it runs on every boot; It's smart enough to requeue itself hourly if it fails to get data. It verifies FTP transfers. It also runs as a cron job monthly to catch any updates. It will log actions to syslog; will also send mail if you like. It preserves file ownership and the timestamp of last download. It knows to run rndc reconfig when it gets a new file. (And not when nothing has changed.) I did some cleanup for this release, but the core logic has run for several years on Fedora and random embedded Linuxes. For me, it's install & forget. README: Install it (or create a link to it) in /etc/init.d/ as update_root. E.g. if it's in /usr/local/sbin, then ln -sf ../../../usr/local/sbin/update_root /etc/init.d/ Then execute /etc/init.d/update_root setup and /etc/init.d/update_root Create a /etc/sysconfig/update_root file if you want a non-default configuration. The most useful configuration variables are: # Undefined uses FTP (default) #USEDNS=yes # Root file name HINT=ROOT.HINT # named control address (undef for none) NAMEDRNDC="127.0.0.1" # Root file owner DEFAULTOWNER="named:named" (When there's no file; normally copies from old) # Define for e-mail recipient (default is undef => none) #TO=hostmas...@example.com # Cron directories CRONMONTHLY="/etc/cron.monthly" CRONHOURLY="/etc/cron.hourly" # No IPV6? This may speed FTP connections. WGET="$WGET -4" Other parameters are in the first ~80 lines of the script. The script commands are: start - check for update (default if no command) setup - run chkconfig and link to monthly queue (don't if you use crontab) status - list current file One caution: Do not copy the script using copy & paste; there are places where literal tabs and spaces are important. [Some environments have very limited regexps.] It's freely redistributable, with the usual caveat that there is no warranty or promise of support & that you use it at your own risk. Enjoy. Timothe Litt ACM Distinguished Engineer - This communication may not represent the ACM or my employer's views, if any, on the matters discussed. update_root Description: Binary data ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root Hints Data File for a .local Domain
On 3/9/2011 8:32 AM, Tony MacDoodle wrote: Hello, I am currently running BIND 9.6.1-P3 and it works fine. My question is regarding the db.cache file. I am only running a local domain (apps.local) that does not access the internet for resolution. My current root hints file is from Internic. 1) Can I use a stripped version of the named.root file 2) Do I need it at all for a local domain If you're on a completely isolated network, with a DNS-consumer population of any significant size, you should set up your own root zone, along with defining slaves, setting up master/slave replication, and publishing all available nameservers in the NS records of the root zone. If, after you've built up that core authoritative infrastructure, you want any of your "edge" resolvers to be "caching-only", i.e. with a minimal config, then you'd configure them with a root "hints" file, but it wouldn't contain the same contents as the one from Internic -- it would contain references to your own internal root nameservers, along with their internal addresses. Someone suggested that ".local" might be problematic, but we've been using various ".local" domains in our internal DNS for years -- not my choice, this is from the Active Directory team of one of our business partners -- and not run into any problems so far. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root Hints Data File for a .local Domain
* Tony MacDoodle: > So in the named.conf file I can get rid of the following: > > zone "." { type hint; file "db.cache"; }; Yes, I think 9.6 has built-in root hints. The zone contents is ignored, except for the NS records and the associated addresses (because of "type hint" instead of "type master"). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root Hints Data File for a .local Domain
So in the named.conf file I can get rid of the following: zone "." { type hint; file "db.cache"; }; Thanks On Wed, Mar 9, 2011 at 9:19 AM, Florian Weimer wrote: > * Tony MacDoodle: > > > 2) Do I need it at all for a local domain > > No, configuring a zone using the "zone" statement on all resolvers is > sufficient. If the resolver knows about authoritative data, it will > not try to fetch it from the Internet. > > You should reconsider using "local", though. Some clients treat it as > a special string. Use a real domain name, or something under "loc" or > "corp". > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstraße 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Root Hints Data File for a .local Domain
* Tony MacDoodle: > 2) Do I need it at all for a local domain No, configuring a zone using the "zone" statement on all resolvers is sufficient. If the resolver knows about authoritative data, it will not try to fetch it from the Internet. You should reconsider using "local", though. Some clients treat it as a special string. Use a real domain name, or something under "loc" or "corp". -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Root Hints Data File for a .local Domain
Hello, I am currently running BIND 9.6.1-P3 and it works fine. My question is regarding the db.cache file. I am only running a local domain (apps.local) that does not access the internet for resolution. My current root hints file is from Internic. 1) Can I use a stripped version of the named.root file 2) Do I need it at all for a local domain Thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 11:12:29PM -0500, Barry Margolin wrote: ... > I'm sure the folks who run these networks are quite aware of this > danger. If a root server changes, I'll bet it will be several years > before the old address goes to some other organization. ... Yah, I know. May not be true on some private internets, tho. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
In message , Barry Mar golin writes: > In article , > Joseph S D Yao wrote: > > > [This does leave a security hole - if a root name server's IP changes, > > and a Bad Guy gets the old one; or on another internet, if the Bad Guy > > gets all the IP addresses in the default file. It's not just lust for > > control that has me using a visible root hints file.] > > I'm sure the folks who run these networks are quite aware of this > danger. If a root server changes, I'll bet it will be several years > before the old address goes to some other organization. > > How would a Bad Guy get these blocks, anyway? Since when do > organizations return IP blocks. > > And if you check the registrations, several of them are assigned > specifically to reserve the blocks for root servers. Presumably the > intent is that even if the organizations operating them change, the IPs > shouldn't -- they simply route the IPs to someone else. > > inetnum:202.12.27.0 - 202.12.27.255 > netname:NSPIXP-2 > descr: root DNS server > > NetRange: 199.7.83.0 - 199.7.83.255 > CIDR: 199.7.83.0/24 > OriginAS: AS20144 > NetName:L-ROOT > > -- > Barry Margolin, bar...@alum.mit.edu > Arlington, MA > *** PLEASE don't copy me on replies, I'll read them in the group *** > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users And one can always turn on DNSSEC and then it doesn't matter which server gives you the information. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
In article , Joseph S D Yao wrote: > [This does leave a security hole - if a root name server's IP changes, > and a Bad Guy gets the old one; or on another internet, if the Bad Guy > gets all the IP addresses in the default file. It's not just lust for > control that has me using a visible root hints file.] I'm sure the folks who run these networks are quite aware of this danger. If a root server changes, I'll bet it will be several years before the old address goes to some other organization. How would a Bad Guy get these blocks, anyway? Since when do organizations return IP blocks. And if you check the registrations, several of them are assigned specifically to reserve the blocks for root servers. Presumably the intent is that even if the organizations operating them change, the IPs shouldn't -- they simply route the IPs to someone else. inetnum:202.12.27.0 - 202.12.27.255 netname:NSPIXP-2 descr: root DNS server NetRange: 199.7.83.0 - 199.7.83.255 CIDR: 199.7.83.0/24 OriginAS: AS20144 NetName:L-ROOT -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 09:51:13PM -0500, Joseph S D Yao wrote: > On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote: > > I have a question about the hints file. > > > > It is "built in" to BIND. > > > > Does bind check for updates to this periodically? ... > To the best of my knowledge, NO. To clarify: The distinguished gentleman from RIPE is also correct. Once BIND starts, IF any of the built-in root name servers is correct [very likely on the public Internet, unlikely on any other internet], it will get the complete current list, as this should be identical on all root name servers. But the answer to your original question remains, "no" - it does not do a file transfer to download any file to keep its boot-time root hints list persistently "current". [This does leave a security hole - if a root name server's IP changes, and a Bad Guy gets the old one; or on another internet, if the Bad Guy gets all the IP addresses in the default file. It's not just lust for control that has me using a visible root hints file.] -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 08:10:10PM +, Jack Tavares wrote: > I have a question about the hints file. > > It is "built in" to BIND. > > Does bind check for updates to this periodically? > If so, where does it get it from ? > I assume it gets it from ftp.isc.org. > Does bind contain a hardcode for that IP address? > or does it use the existing hints to find the address > of "ftp.isc.org" and then download a new ftp.isc.org? To the best of my knowledge, NO. [If you recognized the BigIP in my last posting, you were right!] -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Fri, Jan 28, 2011 at 04:40:50PM +0800, p...@mail.nsbeta.info wrote: > Joseph S D Yao writes: > > Just because we don't need to, doesn't mean that it's a good practtice > > not to. And it's so easy to create one on a system where DNS is already > > set up. > > > > dig ns . > root.hints > > I disagree with this. > Few files mean few risk for admin. > How about the case when someone did "echo > root.hints" by mistake? > > Regards. Pyh, We can agree to disagree. I admit I prefer to have more control over the configuration, and am uncomfortable with "invisible" parts of the configuration. I like those appliances best where I can log in the maintenance port and see the whole configuration laid out before me. It helps with debugging, too. As for "echo > root.hints", who leaves their configuration files writable, or does it as the super-user? That's bound to get you in trouble. Use configuration management software that leaves you with a read-only file! -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On 28/01/2011 21:10, Jack Tavares wrote: > I have a question about the hints file. > > It is "built in" to BIND. > > Does bind check for updates to this periodically? > If so, where does it get it from ? > I assume it gets it from ftp.isc.org. > Does bind contain a hardcode for that IP address? > or does it use the existing hints to find the address > of "ftp.isc.org" and then download a new ftp.isc.org? Hi Jack, BIND has a built-in copy of the root server hints file. However, each time it starts up, it sends a query to the root servers to get an up to date copy of the root servers and their addresses. This is called a "priming query". The priming query is repeated periodically to ensure that BIND has a fresh copy. Regards, Anand Buddhdev RIPE NCC ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: root hints
> On 28/01/2011 21:10, Jack Tavares wrote: > > > I have a question about the hints file. > > > > It is "built in" to BIND. > > > > Does bind check for updates to this periodically? > > If so, where does it get it from ? > > I assume it gets it from ftp.isc.org. > > Does bind contain a hardcode for that IP address? > > or does it use the existing hints to find the address > > of "ftp.isc.org" and then download a new ftp.isc.org? > > Hi Jack, > > BIND has a built-in copy of the root server hints file. However, each > time it starts up, it sends a query to the root servers to get an up to > date copy of the root servers and their addresses. This is called a > "priming query". The priming query is repeated periodically to ensure > that BIND has a fresh copy. > > Regards, > > Anand Buddhdev > RIPE NCC That is what I thought happened, but I was told otherwise, so I wanted to verify. Thank you. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: root hints
I have a question about the hints file. It is "built in" to BIND. Does bind check for updates to this periodically? If so, where does it get it from ? I assume it gets it from ftp.isc.org. Does bind contain a hardcode for that IP address? or does it use the existing hints to find the address of "ftp.isc.org" and then download a new ftp.isc.org? Thanks -- jack ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
Joseph S D Yao writes: Just because we don't need to, doesn't mean that it's a good practtice not to. And it's so easy to create one on a system where DNS is already set up. dig ns . > root.hints I disagree with this. Few files mean few risk for admin. How about the case when someone did "echo > root.hints" by mistake? Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Thu, Jan 27, 2011 at 09:59:58AM +0800, p...@mail.nsbeta.info wrote: ... > That means since BIND 9.2 we don't have the need to make a hints file for > named. Yep in current days who are running the named version below 9.2? ... Surprisingly more people than you would imagine. Is Bill M still doing his periodic surveys? Just because we don't need to, doesn't mean that it's a good practtice not to. And it's so easy to create one on a system where DNS is already set up. dig ns . > root.hints -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Wed, Jan 26, 2011 at 04:16:47PM +, Chris Thompson wrote: ... > which puts it in BIND 9.2 but not in 9.1. I can't find any indication > in the CHANGES files or in my memory that BIND 8 ever had compiled-in > hints. ... Which just shows that my memory going back to BIND 8 has deteriorated. I apologize for throwing that in - I know I have no sense of time, and I should have looked it up if I was going to answer it at all. But I still think it better to have an explicit "root.hints" file than to trust in the invisible file compiled in. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
Chris Thompson writes: The relevant CHANGES file entry for BIND 9 would seem to be 701. [func] Root hints are now fully optional. Class IN views use compiled-in hints by default, as before. Non-IN views with no root hints now provide authoritative service but not recursion. A warning is logged if a view has neither root hints nor authoritative data for the root. [RT #696] which puts it in BIND 9.2 but not in 9.1. I can't find any indication in the CHANGES files or in my memory that BIND 8 ever had compiled-in hints. Thanks Chris. That means since BIND 9.2 we don't have the need to make a hints file for named. Yep in current days who are running the named version below 9.2? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Jan 26 2011, Joseph S D Yao wrote: On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: Hello, From what version of bind we won't include the root hints file in named.conf? Since the bind server has been including it inherently. I could be wrong, but I think that all V9 and even all V8 had this "feature". The relevant CHANGES file entry for BIND 9 would seem to be 701. [func] Root hints are now fully optional. Class IN views use compiled-in hints by default, as before. Non-IN views with no root hints now provide authoritative service but not recursion. A warning is logged if a view has neither root hints nor authoritative data for the root. [RT #696] which puts it in BIND 9.2 but not in 9.1. I can't find any indication in the CHANGES files or in my memory that BIND 8 ever had compiled-in hints. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
Tried both numbers. I'm available 602-418-6471. On Jan 26, 2011, at 6:49 AM, Mark Andrews wrote: > > In message <20110126003702.c16...@gwyn.tux.org>, Joseph S D Yao writes: >> On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: >>> >>> Hello, >>> >>> From what version of bind we won't include the root hints file in >>> named.conf? Since the bind server has been including it inherently. >> >> >> I could be wrong, but I think that all V9 and even all V8 had this >> "feature". I include them anyway - because sometimes I need to change >> what's hidden in the program. >> >> With current V9 you can 'cp /dev/null $directory/named.conf' and have >> 'named' work fine. But I have only done this once, just for the >> experience. > > You don't even need the copy. "named -c /dev/null" will do the job > if you just want a recursive server for the local network. > >> -- >> /*\ >> ** >> ** Joe Yaoj...@tux.org - Joseph S. D. Yao >> ** >> \*/ >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
Please excuse my prior noise. Fat finger and head replied to wrong email. But feel free to call if you feel the need ;-) On Jan 26, 2011, at 6:49 AM, Mark Andrews wrote: > > In message <20110126003702.c16...@gwyn.tux.org>, Joseph S D Yao writes: >> On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: >>> >>> Hello, >>> >>> From what version of bind we won't include the root hints file in >>> named.conf? Since the bind server has been including it inherently. >> >> >> I could be wrong, but I think that all V9 and even all V8 had this >> "feature". I include them anyway - because sometimes I need to change >> what's hidden in the program. >> >> With current V9 you can 'cp /dev/null $directory/named.conf' and have >> 'named' work fine. But I have only done this once, just for the >> experience. > > You don't even need the copy. "named -c /dev/null" will do the job > if you just want a recursive server for the local network. > >> -- >> /*\ >> ** >> ** Joe Yaoj...@tux.org - Joseph S. D. Yao >> ** >> \*/ >> ___ >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
In message <20110126003702.c16...@gwyn.tux.org>, Joseph S D Yao writes: > On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: > > > > Hello, > > > > From what version of bind we won't include the root hints file in > > named.conf? Since the bind server has been including it inherently. > > > I could be wrong, but I think that all V9 and even all V8 had this > "feature". I include them anyway - because sometimes I need to change > what's hidden in the program. > > With current V9 you can 'cp /dev/null $directory/named.conf' and have > 'named' work fine. But I have only done this once, just for the > experience. You don't even need the copy. "named -c /dev/null" will do the job if you just want a recursive server for the local network. > -- > /*\ > ** > ** Joe Yaoj...@tux.org - Joseph S. D. Yao > ** > \*/ > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On 26.01.11 11:20, p...@mail.nsbeta.info wrote: > From what version of bind we won't include the root hints file in > named.conf? Since the bind server has been including it inherently. Why won't you include root hints file in named.conf? While named has builtin default, you can always includeprovide newerthan default. If it exists, named will use that one. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Boost your system's speed by 500% - DEL C:\WINDOWS\*.* ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: root hints
On Wed, Jan 26, 2011 at 11:20:18AM +0800, p...@mail.nsbeta.info wrote: > > Hello, > > From what version of bind we won't include the root hints file in > named.conf? Since the bind server has been including it inherently. I could be wrong, but I think that all V9 and even all V8 had this "feature". I include them anyway - because sometimes I need to change what's hidden in the program. With current V9 you can 'cp /dev/null $directory/named.conf' and have 'named' work fine. But I have only done this once, just for the experience. -- /*\ ** ** Joe Yao j...@tux.org - Joseph S. D. Yao ** \*/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
root hints
Hello, From what version of bind we won't include the root hints file in named.conf? Since the bind server has been including it inherently. Thanks in advance. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-validation and root hints. why need to validate entries in root hints?
Hi! I have a DNSSEC isolated testlab and we simulated signining of a ccTLD. I and my friends already finished setting up the following: 1. client (resolvers) 2. DNS cache server (having a customized ROOT HINTS) 3. ROOT server (without root hints and with "." zone) 4. primary DNS server for "tld", "net.tld" and "testbed.net.tld" zones 5. secondary DNS server for "tld", "net.tld" and "testbed.net.tld" zones 6. primary Dns server for "domain.tld" 7. secondary Dns server for "domain.tld" To make this posting short, I'll not narrate everything but rather inform you that everything was set-up correctly and that client can query the RRs of domain.tld perfectly. However, when we signed the "tld" zone and provided the trusted-key of "tld" for DNS cache server and activated dnssec-enable yes; (which in turn enabled dnssec-validation), The DNS cache server resulted to not being able to find the hostname of "ns1test.testbed.net.tld" Here's the root hints: . 360 NS ns1test.testbed.net.tld. ns1test.testbed.net.tld. 360 A 192.168.1.212 Tacking the problem down, I have the "tld" zone signed, "net.tld" signed and DS RR correctly defined in "tld", but the "testbed.net.tld" is NOT signed... so we signed it and added the DS in 'net.tld'... and it worked! (In theory I can also have the root hints to have a different FQDN and it would still work) Note: the root zone "." is not signed. Direct to the question: Q: I understand that BIND needs to validate *everything* once dnssec-validation is turned ON and when a trusted-key is set-up. But why does it need to validate the entries of its own ROOT HINTS? Is'nt it trust-worthy enough since the mapping is already on the file? should'nt be an exemption is good in this caes? also, the zone to be queried is the "." (root zone) so why need to validate the "tld"? I also have a production DNS cache server that have trusted-keys for "se", "gov", "dlv.isc.org", etc... and dnssec-validation enabled, (I have'nt tried this yet) but in theory if will add a (fictitious) trusted-key for "net", will it totally break my DNS cache? A.ROOT-SERVERS.NET. Thanks! ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users