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
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
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
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
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
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