# tinydns so slooooowww [solved]

## tecknojunky

I think there are no worst bad-software than ones with bad documentation, which is exactly what djbdns seem to have (in my humble opinion).  I can't find a clear example how to set a cache dns AND a server DNS on the same box.

I'm trying to set the dns server on 192.168.1.11 to resolv local lan names and public names we own but the servers are behind the NATed router.  

So, on this machine (192.168.1.11), ...

- tinydns is set to listen on 127.0.0.2, and dnscache is chained to query it.  

- dnscache is binded to 127.0.0.1, and configured to respond queries from 127.0.0.1 and 192.168.1.  

- dnscache root servers are 127.0.0.2, two publicly accessible dns from the ISP, and two more for non-ICANN TLDs

- resolv.conf contains 127.0.0.1

On the clients, resolv.conf contains 192.168.1.11.

So, this should work, and it does.  Problem is, the local network addresses served by tibydns are unacceptably slow  *Quote:*   

> # ping fiston
> 
> PING fiston.inet (192.168.1.2) 56(84) bytes of data.
> 
> 64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.326 ms
> ...

 compared to resolving public names *Quote:*   

> # ping www.gentoo.org
> 
> PING www.gentoo.org (66.219.59.46) 56(84) bytes of data.
> 
> 64 bytes from kiwi.gentoo.org (66.219.59.46): icmp_seq=1 ttl=54 time=76.5 ms
> ...

 I'm starting to get the urge to use dnsmasq instead, which is way simpler to use.  But I wish to get ready to serve my own dns when I'll get a fix IP (some day  :Sad:  ).  I doubt dnsmasq is suited for that.

----------

## UberLord

 *tecknojunky wrote:*   

> I'm starting to get the urge to use dnsmasq instead, which is way simpler to use.  But I wish to get ready to serve my own dns when I'll get a fix IP (some day  ).  I doubt dnsmasq is suited for that.

 

What you mean serve your own dns?

dnsmasq is my choice for DNS+DHCP for small LANs

----------

## tecknojunky

 *UberLord wrote:*   

> What you mean serve your own dns?

 I have domain names but I'm using ZoneEdit for them because I only have dynamic IPs for now.  Since with them you are allowed only 5 domains before you have to pay, I'm figuring that maybe I should arrange to have my own fix IPs eventualy, but for that I would need to setup myself to serve them.  I don't think dnsmasq is good for being a public dns server.

----------

## darkphader

 *tecknojunky wrote:*   

> - dnscache root servers are 127.0.0.2, two publicly accessible dns from the ISP, and two more for non-ICANN TLDs

 

This is most likely the problem.

Info: http://www.faqts.com/knowledge_base/view.phtml/aid/12524/fid/699

Chris

----------

## tecknojunky

 *darkphader wrote:*   

> This is most likely the problem.
> 
> Info: http://www.faqts.com/knowledge_base/view.phtml/aid/12524/fid/699

 

I have these files:

```
# ls /var/djbdns/dnscache/192.168.1.11/root/servers/

1.168.192.in-addr.arpa  @  inet
```

Each containing...

```
# cat 1.168.192.in-addr.arpa

127.0.0.1
```

```
# cat @

216.239.64.154

216.239.64.155

199.5.157.128

199.166.31.3
```

```
# cat inet

127.0.0.1
```

Basically, dnscache does query tinydns on 127.0.0.1 and the reply makes it all the way back to the client, but it takes a very long time and I don't know why.

----------

## Spiffster

If you need to use dns-cache to forward requests to other DNS-servers (eg. if you do not have the root-servers in @), you should set the FORWARDONLY option. I have a setup with tinydns running on 127.0.0.1 and dnscache running on 10.0.0.1, with dnscache asking tinydns for the local domain and forwarding all other requests to my ISPs nameserver. (This is on a Debian-box so I'm not sure exactly how to configure it on gentoo).

If you do not set FORWARDONLY, your dnscache will do the recursive resolving, which dosn't make a lot of sense unless you list the root nameservers in @.

----------

## darkphader

Sorry, I misunderstood. Thought you added the local server address to @ (file that holds the root servers).

Do you have the ns records in the tinydns data file? Lines like:

```
.inet:127.0.0.1:a:259200

.1.168.192.in-addr.arpa:127.0.0.1:a:259200
```

And did you execute make after adding them?

Where does 127.0.0.2 come into play?

Have you tried another TLD besides "inet" (such as "home"), just in case there's some reserved name conflict?

----------

## DaveArb

 *darkphader wrote:*   

> Have you tried another TLD besides "inet" (such as "home"), just in case there's some reserved name conflict?

 

Suggest .test, .example, .invalid, or .localhost, these are the official RFC 2606 reserved TLDs.

Dave

----------

## darkphader

 *DaveArb wrote:*   

> Suggest .test, .example, .invalid, or .localhost, these are the official RFC 2606 reserved TLDs.

 

A trick that I use is to create a sub-domain of a domain under my control, and use that for my private networks.

If you have a registered domain name under your control you can do this with impunity. Your DNS proxy will query your private DNS server for all of the sub-domain requests yet properly pass all up-level requests. And since you are only serving a private network there is no need to delegate or make the public DNS servers aware of your private sub-domain. It works exactly the same way as using an invented TLD.

It has some added pluses. You could easily bring it public though exposing the DNS servers and properly delegating without renaming. And for running email services I like the way it seems to simplify many setups.

For example if you own and control mydomain.com and you know there is no publically available sub-domain or host called subdom.mydomain.com, then you can use it, instead of some TLD like "inet" or the others suggested.

I've been doing this for years and it works a treat.

Chris

----------

## darkphader

technojunky -  just noticed this in regards to your first post:

I don't think "ping" tells you much, if anything. about DNS resolution time. Use "dig" and examine "Query time".

EDIT:

You didn't mention it but does your resolv.conf contain "domain inet" as well?

I'm guessing yes, as you were pinging just "fiston" and not "fiston.inet" but it never hurts to ask.

Chris

----------

## darkphader

More thoughts on this.

 *tecknojunky wrote:*   

> 
> 
> So, on this machine (192.168.1.11), ...
> 
> - tinydns is set to listen on 127.0.0.2, and dnscache is chained to query it.  
> ...

 

Since you want other hosts on the network to use your DNS proxy, bind tinydns to 127.0.0.1 and bind dnscache to 192.168.1.11.

I see no reason here to use 127.0.02 at all, unless you want to run a separate DNS proxy just for this host (something to possibly do for a system that's also an outgoing mail server that  might have entirely different cache contents than the rest of the local network - but never necessary).

Also, despite what the documentation says, I suspect that just using a different IP address isn't enough. I also had some problems trying to use 127.0.0.1 and 127.0.0.2 as even though the IP addresses are different the logical interfaces are not. I suspect (but have not yet proven) that the only way  works properly is to alias the interface so that you you have a separate logical interface for the IP address. So you would have a lo and lo:1, just like you might have an eth0 and an eth0:1. But regardless I think the dnscache should be bound to the eth0 address if you want other hosts to use it.

Chris

----------

## tecknojunky

 *Spiffster wrote:*   

> If you need to use dns-cache to forward requests to other DNS-servers (eg. if you do not have the root-servers in @), you should set the FORWARDONLY option. I have a setup with tinydns running on 127.0.0.1 and dnscache running on 10.0.0.1, with dnscache asking tinydns for the local domain and forwarding all other requests to my ISPs nameserver. (This is on a Debian-box so I'm not sure exactly how to configure it on gentoo).
> 
> If you do not set FORWARDONLY, your dnscache will do the recursive resolving, which dosn't make a lot of sense unless you list the root nameservers in @.

 

The ip's in @ are the two DNS server from my ISP, and the other two are for the not-ICANN ones.  In /etc/dnsroots.global, I have:

```
198.41.0.4

192.228.79.201

192.33.4.12

128.8.10.90

192.203.230.10

192.5.5.241

192.112.36.4

128.63.2.53

192.36.148.17

192.58.128.30

193.0.14.129

198.32.64.12

202.12.27.33
```

 *darkphader wrote:*   

> Do you have the ns records in the tinydns data file? Lines like:
> 
> ```
> .inet:127.0.0.1:a:259200
> 
> ...

 /var/djbdns/tinydns/127.0.0.1/root/data contains:

```
# Manitou (192.168.1.11)

=manitou.inet:192.168.1.11

+ns1.inet:192.168.1.11

.inet::ns1.inet

@inet::courriels.inet

+proxy.inet:192.168.1.11

+time.inet:192.168.1.11

+ns1.inet:192.168.1.11

# Baby (192.168.1.4)

=baby.inet:192.168.1.4

+courriels.inet:192.168.1.4

+*.tecknojunky.com:192.168.1.4

.tecknojunky.com::ns1.inet

+*.gironne.com:192.168.1.4

.gironne.com::ns1.inet

+qc.freescosoft.ca:192.168.1.4

.qc.freescosoft.ca::ns1.inet

# Autres stations...

=routeur.inet:192.168.1.1

=fiston.inet:192.168.1.2

=moman.inet:192.168.1.3
```

 *darkphader wrote:*   

> Where does 127.0.0.2 come into play?

  :Shocked:  You tell me.

 *darkphader wrote:*   

> Have you tried another TLD besides "inet" (such as "home"), just in case there's some reserved name conflict?

 I used that at a lot of places, but only with dnsmasq.

 *darkphader wrote:*   

> I don't think "ping" tells you much, if anything. about DNS resolution time. Use "dig" and examine "Query time".

 Well, my boxes who call servies on other boxes would argue differently.  When I try to use the tinydns setup and the caches are flushed, I get timeouts.  

With dig though, the answers comes really fast:

```
# dig baby.inet

; <<>> DiG 9.2.5 <<>> baby.inet

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9876

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:

;baby.inet.                     IN      A

;; ANSWER SECTION:

baby.inet.              14591   IN      A       192.168.1.4

;; Query time: 2 msec

;; SERVER: 192.168.1.11#53(192.168.1.11)

;; WHEN: Thu Aug 25 21:11:01 2005

;; MSG SIZE  rcvd: 43
```

So, maybe I'm chasing the wrong problem?

 *darkphader wrote:*   

> You didn't mention it but does your resolv.conf contain "domain inet" as well?
> 
> I'm guessing yes, as you were pinging just "fiston" and not "fiston.inet" but it never hurts to ask.

 /etc/resolv.conf

```
nameserver 192.168.1.11

domain inet
```

You're right.  I did not feel a thing.  :Wink: 

----------

## tecknojunky

 *darkphader wrote:*   

> More thoughts on this.
> 
>  *tecknojunky wrote:*   
> 
> So, on this machine (192.168.1.11), ...
> ...

 Ahhh!  That's where it came from.  oups!  :Embarassed: 

 *darkphader wrote:*   

> Since you want other hosts on the network to use your DNS proxy, bind tinydns to 127.0.0.1 and bind dnscache to 192.168.1.11.

 It's been like this for a while.  I think I tried the 127.0.0.2 as a last attempt and posted here then with that config setted.  I have reverted back to 127.0.0.1 long enough for me to forget I tried that.

Sorry.

----------

## darkphader

 *tecknojunky wrote:*   

>  *darkphader wrote:*   Do you have the ns records in the tinydns data file? Lines like:
> 
> ```
> .inet:127.0.0.1:a:259200
> 
> ...

 

It should be much simpler, to directly bind your DNS proxy to 192.168.1.11. Suggest you try it. Also there seems to be nothing that makes it authoritative for reverse address lookups (per my second line).

 *tecknojunky wrote:*   

>  *darkphader wrote:*   Where does 127.0.0.2 come into play? You tell me.

 

You posted it. I'm just trying to figure it out. Again, it would simplify and at the very least, help in troubleshooting if you just bound dnscache directly to 192.168.1.11 dropping the ns1.inet stuff.

 *tecknojunky wrote:*   

>  *darkphader wrote:*   I don't think "ping" tells you much, if anything. about DNS resolution time. Use "dig" and examine "Query time". Well, my boxes who call servies on other boxes would argue differently.  When I try to use the tinydns setup and the caches are flushed, I get timeouts.  
> 
> With dig though, the answers comes really fast:
> 
> ```
> ...

 

Maybe. Although it's possible there's some sort of circular reference with the way you have the DNS proxy set up.

----------

## darkphader

 *tecknojunky wrote:*   

>  *darkphader wrote:*   Since you want other hosts on the network to use your DNS proxy, bind tinydns to 127.0.0.1 and bind dnscache to 192.168.1.11. It's been like this for a while.  I think I tried the 127.0.0.2 as a last attempt and posted here then with that config setted.  I have reverted back to 127.0.0.1 long enough for me to forget I tried that.
> 
> Sorry.

 

And did you revert dnscache back to binding to 192.168.1.11?

If so fix the ns info to read:

```
.inet:127.0.0.1:a:259200 

 .1.168.192.in-addr.arpa:127.0.0.1:a:259200
```

 Drop the reference to ns1.

Chris

----------

## tecknojunky

 *darkphader wrote:*   

> It should be much simpler, to directly bind your DNS proxy to 192.168.1.11. Suggest you try it. Also there seems to be nothing that makes it authoritative for reverse address lookups (per my second line).

 But if I am to change the nameserver's ip, I'd have to modify each entries instead of only one.  Granted, I don't have a lot (now), but it seems loggical, and I learned it here

 *darkphader wrote:*   

> ... it's possible there's some sort of circular reference with the way you have the DNS proxy set up.

 I totally agree, but something is odd.  Now fiston's ping to anywhere is "normal", but baby still has problems.  I have tailed tinydns log and perform a ping of fiston from baby.  The odd thing is that the log enters an entry about 1 per second (as a normal ping output would do) but ping only prints 1 in about 5 (or 10.  haven't count).  So there's something really bizarre going on.  I tried clearing baby's dns cache by restarting nscd, but it changed nothing.

Thanks for being so helpful.

----------

## tecknojunky

 *darkphader wrote:*   

> Drop the reference to ns1.

 

Ok, ok.  Not so loud.  I heard you the first time.  I'm just being stuburn.  :Razz: 

Well, it's fast now.   :Sad: 

I shoud listen to people and stop reading praised howtos.

Now, I have to understand this, or else I'll have problems sleeping.  What happened?

----------

## darkphader

 *tecknojunky wrote:*   

> Now, I have to understand this, or else I'll have problems sleeping.  What happened?

 

Simplification<g>.

Looked over your reference, which although a bit convoluted, seems OK; however, it appears your implementation is possibly somewhat suspect.

In reading the reference it becomes clear that the "1.2.3.5" in "+ns1.example.com:1.2.3.5" refers to address that tinydns is listening on. Since, in your case, tinydns is bound to 127.0.0.1, that's the address you need to use (it is the address it listens on), and not 192.168.1.11 (the address that the DNS proxy, dnscache, is bound to). That's why when we simplified to ".inet:127.0.0.1:a:259200" it worked. Not because we dropped the "ns1" reference but because we became authoritative on the address we were actually listening on. IOW, if ".inet:127.0.0.1:a:259200" was replaced with ".inet:195.168.1.11:a:259200" there would still be problems, despite the simplification.

Chris

----------

## tecknojunky

Yes, yes.  I kinda get it now.  I have configure ns1.inet to be at 192.168.1.11 and then use that to specify the nameserver's location (with : :Smile:  but it's dnscache that's bind there, not tinydns that is on 127.0.0.1.  Right?

So, if I understand correctly, if I want to specify my nameserver by name from the intranet, I think I'm screwed with this setup.  I'm immediatly thinking about an alias interface on eth to do wnat I want to do.  You think it might work?

```
eth0 = 192.168.1.11 -> dnscache

eth0.0 = 102.168.1.12 -> tinydns
```

ADDITION:

So, thi is the data file that seems to work for me currently:

```
# Manitou (192.168.1.11)

=manitou.inet:192.168.1.11

.inet::ns1.inet

@inet::courriels.inet

+proxy.inet:192.168.1.11

+time.inet:192.168.1.11

+ns1.inet:127.0.0.1

.1.168.192.in-addr.arpa:127.0.0.1:a:259200

# Baby (192.168.1.4)

=baby.inet:192.168.1.4

+courriels.inet:192.168.1.4

+*.tecknojunky.com:192.168.1.4

+*.gironne.com:192.168.1.4

+qc.freescosoft.ca:192.168.1.4

# Autres stations...

=routeur.inet:192.168.1.1

=fiston.inet:192.168.1.2

=moman.inet:192.168.1.3
```

Now it's late and I'm going to squeeze my pillow, but tomorrow I'll give all my boxes a cold reboot and see if it still works.

If it does, I'll still have to figure how to enable the nameserver be reachable by name, doing the interface alias voodoo magic that I have never done before.

Then, I want to set replication on another box with rsync and ssh.

Yay, a lot of fun for the upcoming days  :Sad: 

----------

## darkphader

 *tecknojunky wrote:*   

> So, if I understand correctly, if I want to specify my nameserver by name from the intranet, I think I'm screwed with this setup.  I'm immediatly thinking about an alias interface on eth to do wnat I want to do.  You think it might work?

 

Realize again that there are two pieces, a DNS server (tinydns) and a DNS proxy (dnscache). The authoritative nameserver for your intranet is on 127.0.0.1, no other host can connect to it and nor do they need to(!) as they will talk to your DNS proxy. Unless you have a need to expose your DNS server to the hosts (you don't - delegation? zone transfer? nah) there is no need to create an alias for it or place it on an exposed interface.

But you may want an alias for your DNS proxy, so just create one. Add back the alias 

```
+ns1.inet:192.168.1.11
```

 but don't point the ns authoritative record to it, as in 

```
.inet::ns1.inet   <-- this is the loser here
```

 since you really need this 

```
.inet:127.0.0.1:a:259200 

.1.168.192.in-addr.arpa:127.0.0.1:a:259200
```

You can do this 

```
.inet::ns1.inet
```

 if and only if, you do this 

```
+ns1.inet:127.0.0.1
```

 but that wont give you alias named "ns1" you can see from the other hosts.

Chris

----------

## darkphader

 *tecknojunky wrote:*   

> So, if I understand correctly, if I want to specify my nameserver by name from the intranet, I think I'm screwed with this setup.  I'm immediatly thinking about an alias interface on eth to do wnat I want to do.  You think it might work?
> 
> ```
> eth0 = 192.168.1.11 -> dnscache
> 
> ...

 

Just to add, if you needed your name server to be available to other systems (seldom the case in a small network) you can bind it to an external address instead of a loopback address. And an IP alias works just fine. I run one system with tinydns on eth0 and dnscache on eth0:1 (and this could be reversed just as easily). Although I will add that is not because I needed tinydns to be available outside the host but because it was my first djbdns install and I was a bit confused, with some docs putting dnscache on lo, other putting tinydns on lo, etc. So to be safe I created a scenario where both could be available outside of the host.

At this time I'm convinced that for most small (I run it like this on a 250 system network with no problems) private internal networks that it is safest to bind tinydns on the lo interface. Safest because it is not exposed to other hosts as only dnscache needs to access it. And by virtue of this setup the need to run walldns is completely obviated.

And now with the new baselayout making it easy to alias lo, I will probably add a second cache for the server alone on lo:1 so that DNS lookups for outgoing mail don't affect the cached results in the cache the clients use.

Chris

----------

## Spiffster

 *darkphader wrote:*   

> And now with the new baselayout making it easy to alias lo, I will probably add a second cache for the server alone on lo:1 so that DNS lookups for outgoing mail don't affect the cached results in the cache the clients use.

 

What do you mean by affect? Isn't the idea of a DNS-cache that you can save some lookups. The only way your local mail-server doing lookups is going to affect anything is that they are already in the cache if a user tries to look up the same name. How is this a problem? Security?

----------

## darkphader

 *Spiffster wrote:*   

> What do you mean by affect? Isn't the idea of a DNS-cache that you can save some lookups. The only way your local mail-server doing lookups is going to affect anything is that they are already in the cache if a user tries to look up the same name. How is this a problem? Security?

 

No, not a security problem. It's just that I'm thinking that contents of the mail-server's cache would, if separated, be entirely different then the contents of the cache created from lookups (mostly for websites) by the network hosts. So by "affect", I mean that all of the cached MX records, which are useless to the internal hosts, and all of the records for web sites will vie for the space in a combined cache. The internal hosts don't need the MX records, and the mail server doesn't need much else. If they have their own caches the hit ratio and performance should improve.

Chris

----------

## tecknojunky

 *darkphader wrote:*   

> Just to add, if you needed your name server to be available to other systems (seldom the case in a small network) you can bind it to an external address instead of a loopback address. And an IP alias works just fine. I run one system with tinydns on eth0 and dnscache on eth0:1 (and this could be reversed just as easily). Although I will add that is not because I needed tinydns to be available outside the host but because it was my first djbdns install and I was a bit confused, with some docs putting dnscache on lo, other putting tinydns on lo, etc. So to be safe I created a scenario where both could be available outside of the host.

 

```
# Manitou (192.168.1.11)

=manitou.inet:192.168.1.11

@inet::courriels.inet

+proxy.inet:192.168.1.11

+time.inet:192.168.1.11

+ns1.inet:127.0.0.1

.inet:127.0.0.1

.1.168.192.in-addr.arpa:127.0.0.1:a:259200

# Baby (192.168.1.4)

=baby.inet:192.168.1.4

+courriels.inet:192.168.1.4

+*.tecknojunky.com:192.168.1.4

+*.gironne.com:192.168.1.4

+qc.freescosoft.ca:192.168.1.4

# Autres stations...

=routeur.inet:192.168.1.1

=fiston.inet:192.168.1.2

=moman.inet:192.168.1.3
```

(for now)  :Wink: 

Well, Chris.  I think you have sorted out my miscon[ figura | cep ]tion pretty well.  I know my stuburness made me a bad pupile, but I think your patience made you a great mentor.

Since a while I have not had much luck in getting answers from more knowlegeable than me from these forums.  For once I have struck gold.  :Very Happy: 

Thanks a bunch.  Chris Rocks! Woot! Woot!  :Cool: 

----------

## tecknojunky

Man, I'm getting weared out by this.  :Sad: 

I created an alias:

```
eth0      Link encap:Ethernet  HWaddr 00:50:BA:64:BB:DF

          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0

          inet6 addr: fe80::250:baff:fe64:bbdf/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:131385 errors:0 dropped:0 overruns:0 frame:0

          TX packets:97659 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:106672252 (101.7 Mb)  TX bytes:29704480 (28.3 Mb)

          Interrupt:11 Base address:0xe000

eth0:1    Link encap:Ethernet  HWaddr 00:50:BA:64:BB:DF

          inet addr:192.168.1.12  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

          Interrupt:11 Base address:0xe000
```

Modified my data file:

```
# Manitou (192.168.1.11)

=manitou.inet:192.168.1.11

=ns1.inet:192.168.1.12

.inet:192.168.1.12

.1.168.192.in-addr.arpa:192.168.1.12:a:259200

@inet::courriels.inet

+proxy.inet:192.168.1.11

+time.inet:192.168.1.11

# Baby (192.168.1.4)

=baby.inet:192.168.1.4

+courriels.inet:192.168.1.4

+*.tecknojunky.com:192.168.1.4

+*.gironne.com:192.168.1.4

+qc.freescosoft.ca:192.168.1.4

# Autres stations...

=routeur.inet:192.168.1.1

=fiston.inet:192.168.1.2

=moman.inet:192.168.1.3
```

Renamed my folder from 127.0.0.1 to 192.168.1.12:

```
manitou root # ls -l /var/djbdns/tinydns/

total 1

drwxr-sr-t  6 root root 7 Aug 27 04:02 192.168.1.12
```

Assigned the new IP to bind to:

```
manitou root # cat /var/djbdns/tinydns/192.168.1.12/env/IP

192.168.1.12
```

Told dnscache about the new IP of the inet nameserver:

```
manitou root # cat /var/djbdns/dnscache/192.168.1.11/root/servers/inet

192.168.1.12

manitou root # cat /var/djbdns/dnscache/192.168.1.11/root/servers/1.168.192.in-addr.arpa

192.168.1.12
```

But now I'm getting this in dnscache log:

```
@4000000043102c2f35fdad9c dnscache: fatal: unable to read servers: access denied

@4000000043102c3036d3a30c dnscache: fatal: unable to read servers: access denied

@4000000043102c313ada4e9c dnscache: fatal: unable to read servers: access denied

@4000000043102c3303128d6c dnscache: fatal: unable to read servers: access denied

@4000000043102c3404bee994 dnscache: fatal: unable to read servers: access denied

@4000000043102c3506b798cc dnscache: fatal: unable to read servers: access denied

@4000000043102c360c1c49d4 dnscache: fatal: unable to read servers: access denied

@4000000043102c3712c0f104 dnscache: fatal: unable to read servers: access denied

@4000000043102c38157f26a4 dnscache: fatal: unable to read servers: access denied

@4000000043102c391ee998dc dnscache: fatal: unable to read servers: access denied
```

Ad Vitam Eternam!

I'm suffling different things, but I think I made a bobo.  :Sad:   I can't pinpoint the error.

ADDITION:

Well, I baffled.  I went to see the code and this message is found only in dnscache.c, which calls roots_init which in turn I'm guessing is trying to read all the files in the server folder.  Failing to that must some right permission problem, right?

```
manitou work # ls /var/djbdns/dnscache/192.168.1.11/root/servers -ld

drwxr-sr-x  2 root root 5 Aug 27 05:51 /var/djbdns/dnscache/192.168.1.11/root/servers
```

See the "s" in the "execute" holder of the "group" perms?  I have no clue how to manipulate that, so I used mc which states it is to "set group ID on execution".  Well, I removed that and dnscache now starts.

What baffles me is that all the other folders are set this way, and I havent done a chmod at all (remember, I said I don't know how to manipulate this).

Can someone theorize on what happened?  I did run by mistake svscan from the shell, which started something, or tried to.  I also think there are a lot of supervise folders where I don't remember seing any before.

I'm clumsy.  :Crying or Very sad: 

----------

