problem with bind book example

Kevin Darcy kcd at chrysler.com
Thu Sep 24 14:23:40 UTC 2009


Linda W wrote:
> I was trying to auto load the root hints file on a cron job.
>
> In the bind 4th ed. book, p 157, there's and example to use dig to create a
> a file it calls db.cache
>   

Specifically, the example is

$ dig @a.root-servers.net . ns > db.cache

I wouldn't cron that _as_is_. You should at least put a wrapper script 
around it to ensure that the "dig" actually worked and produced a 
non-zero-length file. Bonus points for keeping several generations of 
the file so that if something goes wrong, you can do forensics on where 
things went awry.
> >From the text I understood it to be a 'roots.hint' file for startup.
> It seems to have the same information but in a different order as the root.hints
> file, but when I try to use it my named won't start.  
>   
The name of the file doesn't matter; there's nothing magical about it. 
We usually call our hints file just "hints". But you could call it "joe" 
if you wanted to, or "throat-warbler-mangrove".
> In the log I have evil messages saying many things are refused:
> 20-Sep-2009 23:37:07.050 xfer-in: error: transfer of 'ARPA/IN' from 198.41.0.4#53
> : failed while receiving responses: REFUSED
> 21-Sep-2009 02:22:08.919 xfer-in: error: transfer of 'in-addr.arpa/IN' from 198.4
> 1.0.4#53: failed while receiving responses: REFUSED
> 21-Sep-2009 11:07:16.575 xfer-in: error: transfer of 'ARPA/IN' from 128.8.10.90#5
> 3: failed while receiving responses: REFUSED
> 21-Sep-2009 11:07:17.096 xfer-in: error: transfer of 'ARPA/IN' from 192.203.230.1
> 0#53: failed while receiving responses: REFUSED
> 21-Sep-2009 14:34:40.774 xfer-in: error: transfer of 'in-addr.arpa/IN' from 198.4
> 1.0.4#53: failed while receiving responses: REFUSED
> 22-Sep-2009 02:34:19.939 xfer-in: error: transfer of 'in-addr.arpa/IN' from 198.4
> 1.0.4#53: failed while receiving responses: REFUSED
> 22-Sep-2009 07:40:59.577 xfer-in: error: transfer of 'ARPA/IN' from 198.41.0.4#53
> : failed while receiving responses: REFUSED
> 22-Sep-2009 11:08:30.583 xfer-in: error: transfer of 'ARPA/IN' from 128.8.10.90#5
> 3: failed while receiving responses: REFUSED
> 22-Sep-2009 11:08:31.077 xfer-in: error: transfer of 'ARPA/IN' from 192.203.230.1
> 0#53: failed while receiving responses: REFUSED
> 22-Sep-2009 14:12:11.720 xfer-in: error: transfer of 'in-addr.arpa/IN' from 128.8
> .10.90#53: failed while receiving responses: REFUSED
> 22-Sep-2009 14:12:12.217 xfer-in: error: transfer of 'in-addr.arpa/IN' from 192.2
> 03.230.10#53: failed while receiving responses: REFUSED
> 23-Sep-2009 14:18:13.797 general: notice: stopping command channel on 127.0.0.1#9
> 53
> 23-Sep-2009 14:18:13.814 general: notice: exiting
>   
Those log messages indicate that you have configured named to slave arpa 
and in-addr.arpa. The servers for those zones don't allow zone 
transfers, so you're getting "REFUSED". Consequently, the zone transfers 
are failing.

I don't think that has anything to do with your hints file.

Also, named exited more than 24 hours after the last REFUSED message. 
How do you interpret this as "named won't start"? It looks like a 
deliberate, orderly shutdown to me, after running more than 24 hours 
without any errors whatsoever.

Maybe you need to tune your logging. It might not be giving you enough 
information to give you a proper picture.

> ----------
>
> The addresses in the two files appear to be the same...so I don't understand 
> why one works and the other does not?
>
> In my main config it's in the section:
> root "." IN {
> 	type hint;
> 	file "root.hint";
> };
> --- I change the file to 'root.db' (also tried a different name, root.cache), 
> and it fails.  The root.db file has in it:
> --------
>
> ; <<>> DiG 9.5.0-P2 <<>> +nocomments +noquestion +norecurse @a.root-servers.net .
>  NS
> ; (1 server found)
> ;; global options:  printcmd
> .                       518400  IN      NS      D.ROOT-SERVERS.NET.
> .                       518400  IN      NS      L.ROOT-SERVERS.NET.
> .                       518400  IN      NS      G.ROOT-SERVERS.NET.
> .                       518400  IN      NS      F.ROOT-SERVERS.NET.
> .                       518400  IN      NS      H.ROOT-SERVERS.NET.
> .                       518400  IN      NS      C.ROOT-SERVERS.NET.
> .                       518400  IN      NS      J.ROOT-SERVERS.NET.
> .                       518400  IN      NS      B.ROOT-SERVERS.NET.
> .                       518400  IN      NS      E.ROOT-SERVERS.NET.
> .                       518400  IN      NS      A.ROOT-SERVERS.NET.
> .                       518400  IN      NS      K.ROOT-SERVERS.NET.
> .                       518400  IN      NS      I.ROOT-SERVERS.NET.
> .                       518400  IN      NS      M.ROOT-SERVERS.NET.
> A.ROOT-SERVERS.NET.     3600000 IN      A       198.41.0.4
> A.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:503:ba3e::2:30
> B.ROOT-SERVERS.NET.     3600000 IN      A       192.228.79.201
> C.ROOT-SERVERS.NET.     3600000 IN      A       192.33.4.12
> D.ROOT-SERVERS.NET.     3600000 IN      A       128.8.10.90
> E.ROOT-SERVERS.NET.     3600000 IN      A       192.203.230.10
> F.ROOT-SERVERS.NET.     3600000 IN      A       192.5.5.241
> F.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:2f::f
> G.ROOT-SERVERS.NET.     3600000 IN      A       192.112.36.4
> H.ROOT-SERVERS.NET.     3600000 IN      A       128.63.2.53
> H.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:500:1::803f:235
> I.ROOT-SERVERS.NET.     3600000 IN      A       192.36.148.17
> J.ROOT-SERVERS.NET.     3600000 IN      A       192.58.128.30
> J.ROOT-SERVERS.NET.     3600000 IN      AAAA    2001:503:c27::2:30
> ;; Query time: 40 msec
> ;; SERVER: 198.41.0.4#53(198.41.0.4)
> ;; WHEN: Sun Sep 20 20:19:46 2009
> ;; MSG SIZE  rcvd: 500
>
>   
Again, the name doesn't matter. All that matters is that you have the 
right contents in the file.
> ---
> So how come such a simple example fails on my system when the standard ftp one works?
>
>
>   
When troubleshooting problems of this type, it's helpful to eliminate 
variables.

Take out those slave-zone definitions for arpa and in-addr.arpa and try 
again.

- Kevin





More information about the bind-users mailing list