Re: Building a fresh named.root
On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grep A.ROOT-SERVERS.NET returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. Chris Buxton BlueCat Networks___ 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: Building a fresh named.root
On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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
builtin hints working - Re: Building a fresh named.root
I commented out include for the root.hints and things are working still so obviously it is built in even though the string search is not working on my binary. On 02/15/2013 12:57 PM, Robert Moskowitz wrote: On 02/15/2013 12:37 PM, Chris Buxton wrote: On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote: Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grepA.ROOT-SERVERS.NET http://A.ROOT-SERVERS.NET/ returns nothing. Yes they are. All versions of BIND since 9.3 or so have had the root hints built in. Even Red Hat's version. Unfortunately, Warren missed a trick of some sort -- I suspect that if you strip the binary, the 'strings' command won't find the values. But they're still there. Adam Tkac would not remove this from the Red Hat SRPM. I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. Root hints, as somebody pointed out, are just hints. There is no reason to focus on making sure they're 100% accurate. There's also no point in stripping the IPv6 addresses out of the root hints zone if you don't have IPv6 -- the real list will be fetched (by DNS query) from the servers in the hints file, including all of their IPv6 addresses. If your DNS server doesn't have IPv6 connectivity, I have two comments for you: - Why not? It's easy to get a tunnel, if nothing else is available. I have a /48 allocated to my home lab :) (I also have a /26 IPv4 allocation here) - Start named with the -4 argument to prevent it from trying to contact IPv6 addresses. ___ 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. Appearently so. Very interesting. using my IP address and I got a nice return back of the root servers. Just like I get from the 'real ones'. And I have commented out the hint stub, so I am good on this matter. One more item checked off. 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: Building a fresh named.root
On Feb 15, 2013, at 3:56 PM, Robert Moskowitz r...@htt-consult.com wrote: The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. Appearently so. Very interesting. using my IP address and I got a nice return back of the root servers. Just like I get from the 'real ones'. And I have commented out the hint stub, so I am good on this matter. One more item checked off. If recursion is allowed on 127.0.0.1 (and your non-loopback IPv4 addresses), you may want to permit it over IPv6 as well. Might save some debugging time when you enable externally visible IPv6. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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: Building a fresh named.root
On 02/15/2013 03:40 PM, Chris Buxton wrote: On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote: I will do some more testing with this to see if I can indeed remove the root.hint includes. But I have a question. I have tried to dig in my server for the root info like you can a root server, but obviously this is not the way to do it, as I get an empty list eventhough I know I can resolve names that I am not authoritative for. I tried dig +bufsize=4096 . ns @localhost (and without the bufsize) and it comes back with a warning that recursion requested but not available and an empty list. More interestingly is that in /var/log/messages it shows: named[2872]: client ::1#57049: view external: query (cache) './NS/IN' denied I would think this should go to my internal view? I even put 127.0.0.1 into my match-clients/destinations network list and it is still using the external view. The hostname 'localhost' can mean different things to different computers. It probably means ::1 (IPv6 localhost) in this case. Try explicitly specifying the IP address rather than using the hostname. I just looked at the dig results using localhost again, and there it was, ::1! I also realize that I have to add my IPv6 prefix to my allowed internal addresses, along with ::1 ___ 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: Building a fresh named.root
On 14 February 2013 13:35, Robert Moskowitz r...@htt-consult.com wrote: What went wrong here? Which do I use? Not sure what is up with your dig response (can you post the contents) but it works for me and if your dig still isn't working use the one from FTP. sjcarr@elmo:~ $ dig . ns @198.41.0.4 ; DiG 9.8.3-P1 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6958 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS j.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS f.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. ;; ADDITIONAL SECTION: j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 e.root-servers.net. 360 IN A 192.203.230.10 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 g.root-servers.net. 360 IN A 192.112.36.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 l.root-servers.net. 360 IN 2001:500:3::42 ;; Query time: 44 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 13:40:13 2013 ;; MSG SIZE rcvd: 508 ___ 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: Building a fresh named.root
BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) There is no need for a named.root file, and is just another thing to go wrong… W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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 -- Does Emacs have the Buddha nature? Why not? It has bloody well everything else... ___ 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: Building a fresh named.root
On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
On Feb 14, 2013, at 9:28 AM, Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. Nope -- it is in lib/dns/rootns.c in the source code tree…. When BIND is compiled into a binary this gets baked in…. You can verify this by running strings on the binary. E.g: wkumari$:~$ strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 360 IN 2001:503:BA3E::2:30 W There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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 think it would be a good idea. - Mahatma Ghandi, when asked what he thought of Western civilization ___ 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: Building a fresh named.root
Oops ignore that earlier send. Hit wrong button... On 02/14/2013 08:42 AM, Steven Carr wrote: On 14 February 2013 13:35, Robert Moskowitz r...@htt-consult.com wrote: What went wrong here? Which do I use? Not sure what is up with your dig response (can you post the contents) but it works for me and if your dig still isn't working use the one from FTP. sjcarr@elmo:~ $ dig . ns @198.41.0.4 ; DiG 9.8.3-P1 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6958 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS Stuff deleted. ;; ADDITIONAL SECTION: j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 e.root-servers.net. 360 IN A 192.203.230.10 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 g.root-servers.net. 360 IN A 192.112.36.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 l.root-servers.net. 360 IN 2001:500:3::42 ;; Query time: 44 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 13:40:13 2013 ;; MSG SIZE rcvd: 508 You too are missing some A and records! Here is mine: ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 57006 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 13 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS f.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS l.root-servers.net. ;; ADDITIONAL SECTION: f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 c.root-servers.net. 360 IN A 192.33.4.12 m.root-servers.net. 360 IN 2001:dc3::35 ;; Query time: 221 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 08:08:32 2013 ;; MSG SIZE rcvd: 508 ___ 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: Building a fresh named.root
Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. Tony. -- f.anthony.n.finch d...@dotat.at http://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: Building a fresh named.root
On 02/14/2013 09:19 AM, Christian Tardif wrote: You're right. CentOS 6.3 does not have named.root. They just call it named.ca. That's actually the same file thing. You just need to refer to the right file name for hints. Note below that I did see the named.ca which is from their namecaching setup. And this stub does not have as many records as the one I ftped, so it is already dated. Which begs the next question I was going to ask. How often should I download a fresh named.zone? Do I set up a monthly cron job? It is clear that there is movement on populating it with records. Christian... On 02/14/2013 08:35 AM, Robert Moskowitz wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
Robert Moskowitz r...@htt-consult.com wrote: Which begs the next question I was going to ask. How often should I download a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. Tony. -- f.anthony.n.finch d...@dotat.at http://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: Building a fresh named.root
On 02/14/2013 09:34 AM, Warren Kumari wrote: On Feb 14, 2013, at 9:28 AM, Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. Nope -- it is in lib/dns/rootns.c in the source code tree…. Oh, of course... When BIND is compiled into a binary this gets baked in…. You can verify this by running strings on the binary. E.g: wkumari$:~$ strings /usr/local/sbin/named | grep A.ROOT-SERVERS.NET . 518400 IN NS A.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 IN A 198.41.0.4 A.ROOT-SERVERS.NET. 360 IN 2001:503:BA3E::2:30 Mine is located in /usr/sbin/ and no such string. In fact the only occurance of ROOT is a comment on the location of the ROOT KEY. And anyway, baking it in is a problem as we continue to have an availablity of for the roots. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? W On Feb 14, 2013, at 8:35 AM, Robert Moskowitz r...@htt-consult.com wrote: The Centos 6.3 bind and bind-chroot do not seem to come with a named.root. Does have a named.ca, though. So from my old named.root.hints include (also not provided; where did I get this?) I tried: wget ftp://ftp.rs.internic.net/domain/named.root And got a nice looking named.root last updated 1/3/2013, with nice comments on who use to run the various root servers. Then I tried: dig . ns @198.41.0.4 named.root I see where this addr is the A root server, anyway, the response did not have A records for B, E, I, J, or L !!! And of course no records for I, J, or L. It has NS records for A thru M. What went wrong here? Which do I use? ___ 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: Building a fresh named.root
On 02/14/2013 09:38 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: On 02/14/2013 09:05 AM, Warren Kumari wrote: BIND now comes with a baked in roots file (in the imaginatively named lib/dns/rootns.c ) Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2. That is a source file name which is compiled into the binary. You don't need any extra files in the installation. There is no need for a named.root file, and is just another thing to go wrong… Is there anything needed in the named.conf to actuate this if you do have it? The default is to use the built-in hints. That makes sense. Smart people that put this together ;) Given the expansion of records, I think I am going to stay with an explicit root file this time around. ___ 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: Building a fresh named.root
On 02/14/2013 09:47 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: Which begs the next question I was going to ask. How often should I download a fresh named.zone? Never. If you keep BIND reasonably up-to-date its built-in hints will work fine. More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). Is there a way I can DIG my server for what it thinks . is? Like using that same DIG command? I am still checking out my files and have not started bind, but I should be ready shortly... ___ 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: Building a fresh named.root
Robert Moskowitz r...@htt-consult.com wrote: More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. Tony. -- f.anthony.n.finch d...@dotat.at http://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: Building a fresh named.root
You too are missing some A and records! Here is mine: Use bufsize=4096 or at least something around 700, else the answer doesn't fitand is truncated. jaap dig +bufsize=4096 . ns @198.41.0.4 ; DiG 9.8.4-P1 +bufsize=4096 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33099 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 23 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 i.root-servers.net. 360 IN 2001:7fe::53 i.root-servers.net. 360 IN A 192.36.148.17 m.root-servers.net. 360 IN 2001:dc3::35 m.root-servers.net. 360 IN A 202.12.27.33 e.root-servers.net. 360 IN A 192.203.230.10 l.root-servers.net. 360 IN 2001:500:3::42 l.root-servers.net. 360 IN A 199.7.83.42 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 ;; Query time: 19 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 16:24:06 2013 ;; MSG SIZE rcvd: 699 ___ 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: Building a fresh named.root
On 02/14/2013 10:18 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Thanks. Now I just have to find out from the Centos list if my version has them built in. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. And with anycast they will probably not change until IPv9... Check out RFC 1606. ___ 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: Building a fresh named.root
On 02/14/2013 10:26 AM, Jaap Akkerhuis wrote: You too are missing some A and records! Here is mine: Use bufsize=4096 or at least something around 700, else the answer doesn't fitand is truncated. I was thinking it was something like that. Thanks. jaap dig +bufsize=4096 . ns @198.41.0.4 ; DiG 9.8.4-P1 +bufsize=4096 . ns @198.41.0.4 ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33099 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 23 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS a.root-servers.net. . 518400 IN NS f.root-servers.net. ;; ADDITIONAL SECTION: d.root-servers.net. 360 IN 2001:500:2d::d d.root-servers.net. 360 IN A 199.7.91.13 j.root-servers.net. 360 IN 2001:503:c27::2:30 j.root-servers.net. 360 IN A 192.58.128.30 h.root-servers.net. 360 IN 2001:500:1::803f:235 h.root-servers.net. 360 IN A 128.63.2.53 g.root-servers.net. 360 IN A 192.112.36.4 k.root-servers.net. 360 IN 2001:7fd::1 k.root-servers.net. 360 IN A 193.0.14.129 b.root-servers.net. 360 IN A 192.228.79.201 c.root-servers.net. 360 IN A 192.33.4.12 i.root-servers.net. 360 IN 2001:7fe::53 i.root-servers.net. 360 IN A 192.36.148.17 m.root-servers.net. 360 IN 2001:dc3::35 m.root-servers.net. 360 IN A 202.12.27.33 e.root-servers.net. 360 IN A 192.203.230.10 l.root-servers.net. 360 IN 2001:500:3::42 l.root-servers.net. 360 IN A 199.7.83.42 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 a.root-servers.net. 360 IN A 198.41.0.4 f.root-servers.net. 360 IN 2001:500:2f::f f.root-servers.net. 360 IN A 192.5.5.241 ;; Query time: 19 msec ;; SERVER: 198.41.0.4#53(198.41.0.4) ;; WHEN: Thu Feb 14 16:24:06 2013 ;; MSG SIZE rcvd: 699 ___ 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: Building a fresh named.root
Running bind rooted on FC 16 using the standard package. The ca file is located in /var/named/chroot/var/named/named.ca The hints are not built in. [shawn@www ~]$ strings /usr/sbin/named | grep A.ROOT-SERVERS.NET returns nothing. Centos is RedHat EL (free version) which is a stable version of fedora Core + proprietary extras ?? They may have re-imped bind differently but I doubt it. If you build it from source, over a set of installed packages, you may have residual files that came with the packages, but are not relevant to you rebuild. Bind is: Date: Thu, 14 Feb 2013 10:44:02 -0500 From: r...@htt-consult.com To: d...@dotat.at Subject: Re: Building a fresh named.root CC: bind-users@lists.isc.org On 02/14/2013 10:18 AM, Tony Finch wrote: Robert Moskowitz r...@htt-consult.com wrote: More records 1/3/2013 than in the named.ca stub which IF my version has it builtin raises the question about keeping current at this time in the Internet (and trusting Redhat to roll in new builtin hints as they go). No need to worry. They are only hints, and named uses them to get the current list of root name servers at startup. Thanks. Now I just have to find out from the Centos list if my version has them built in. Even if they are 15 years out of date it will still work, because the root name servers do not change very often. And with anycast they will probably not change until IPv9... Check out RFC 1606. ___ 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
