Providing local DNS service behind a cheap router/gateway

Sun Dec 30 18:22:12 UTC 2007

Thanks Chris. Your replies to this list are always informative and  
thorough. While I have tinkered with this configuration on and off  
for over three years, writing to this list finally inspired me to  
configure an internal DHCP server, and to take this responsibility  
away from the router. The DHCP server is now running on the same host  
as the BIND service. This step helps to remove one more potential  
bottleneck in the networks running under the configuration described  
in this thread, while giving me greater control over DHCP.

To further reduce the risk of any kind of looping, I've returned the  
DNS setting on the WAN side of the router to a more typical  
configuration, listing the service provider's nameservers instead of  
my internal addresses. Since the router isn't handling the DNS  
requests, I figure that these entries will only be used by the router  
itself (say for resolving ntp or mail server addresses for its  
internal logging facility).

Interestingly, though, this step seems to have revealed a new  
problem, and also a new solution. First, the solution...

Your mention that:

> Loading a typical webpage involves several DNS lookups, and if those
> lookups each take a couple of seconds, it can look like there is a
> problem at the HTTP level.

prompted me to look for a caching nameserver on the host. It was not  
installed! This has helped to speed up the name resolution process  
significantly, as you'd expect. Thanks for the words that jogged the  
thought! (I still find that preliminary lookups seem slow, but I'll  
look into that further on my own.)

However, I find I have a new problem. Until these changes, named was  
able to resolve recursively without a hitch. Now:

# dig @192.168.0.38 www.wikipedia.com
; <<>> DiG 9.3.4-P1 <<>> @192.168.0.38 www.wikipedia.com
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

But, if I configure the forwarders option to point to the service  
provider's name servers:

# dig @192.168.0.38 www.wikipedia.com
; <<>> DiG 9.3.4-P1 <<>> @192.168.0.38 www.wikipedia.com
; (	1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57586
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;www.wikipedia.com.             IN      A

;; ANSWER SECTION:
www.wikipedia.com.      3598    IN      CNAME   rr.wikimedia.org.
rr.wikimedia.org.       422     IN      CNAME   rr.pmtpa.wikimedia.org.
rr.pmtpa.wikimedia.org. 3420    IN      A       66.230.200.100

;; AUTHORITY SECTION:
.                       518099  IN      NS      K.ROOT-SERVERS.NET.
.                       518099  IN      NS      L.ROOT-SERVERS.NET.
.                       518099  IN      NS      M.ROOT-SERVERS.NET.
.                       518099  IN      NS      A.ROOT-SERVERS.NET.
.                       518099  IN      NS      B.ROOT-SERVERS.NET.
.                       518099  IN      NS      C.ROOT-SERVERS.NET.
.                       518099  IN      NS      D.ROOT-SERVERS.NET.
.                       518099  IN      NS      E.ROOT-SERVERS.NET.
.                       518099  IN      NS      F.ROOT-SERVERS.NET.
.                       518099  IN      NS      G.ROOT-SERVERS.NET.
.                       518099  IN      NS      H.ROOT-SERVERS.NET.
.                       518099  IN      NS      I.ROOT-SERVERS.NET.
.                       518099  IN      NS      J.ROOT-SERVERS.NET.

;; Query time: 4048 msec
;; SERVER: 192.168.0.38#53(192.168.0.38)
;; WHEN: Sun Dec 30 12:37:28 2007
;; MSG SIZE  rcvd: 315

Possibly pertinent lines from named.conf:

options {
	query-source address 192.168.0.38 port 53;
	forwarders { 209.116.241.10; 206.205.242.132; };
};

acl "admirallan" {
	192.168.0.0/24;
};

view "inside" {
	# Limit access to internal IP addresses
	match-clients { localnets; localhost; "admirallan"; };	

	# Redundant to above, but added comfort	
	allow-query { localnets; localhost; "admirallan"; };

	# Allow internal clients to request DNS for domains not managed by  
this server
	recursion yes;

	# Redundant to above, but added comfort	
	allow-recursion { localnets; localhost; "admirallan"; };
}

Any ideas on why this is happening? bind version is 9.3.4-P1, running  
on Fedora 6.

Thank you,
Steven Stromer

> First off, what you have now functions. There are just performance
> problems. This could probably be resolved by configuring global
> forwarding in the DNS server pointing to some outside name server that
> has a bigger cache and more available bandwidth. Loading a typical
> webpage involves several DNS lookups, and if those lookups each take a
> couple of seconds, it can look like there is a problem at the HTTP
> level.
>
> If you turned on the DNS proxy service in the router, it would give
> out its own address as a DNS service in DHCP leases. It would then
> forward queries to whatever is configured in it as an "outside" name
> server. This would be the internal DNS server, which would then send
> queries to the outside world (through the router). However, the DNS
> proxy service in the router would probably* not interfere with this -
> there would be no infinite loop.
>
> * Some routers have an actual DNS interceptor (transparent proxy) that
> would cause things to fail. But usually, it's a simple DNS server that
> only receives queries that are addressed to it. This is usually done
> using dnsmasq, which is most likely also the DHCP server - this can
> have some neat capabilities if properly configured. You might want to
> look at a replacement firmware such as Tomato.
> <http://www.polarcloud.com/tomato>
>
> Since you're having performance problems with your BIND name server
> and outside data, it might make sense to switch to something simpler
> like dnsmasq (possibly in your router) that would forward everything
> unknown out to a better-connected resolving name server.
>
> If you decide instead to build your own DHCP server, then for a small
> office, you may still end up wanting to use dnsmasq. If you decide to
> set up ISC's DHCP service instead, you'll have a lot more work to do,
> and for a small network you probably won't see any functional benefit.
> Either way, setting up a separate DHCP service (from the router) means
> disabling the DHCP service in the router itself.
>
> Chris Buxton
> Professional Services
> Men & Mice
> Address: Noatun 17, IS-105, Reykjavik, Iceland
> Phone:   +354 412 1500
> Email:   cbuxton at menandmice.com
> www.menandmice.com
>
> Men & Mice
> We bring control and flexibility to network management
>
> This e-mail and its attachments may contain confidential and
> privileged information only intended for the person or entity to which
> it is addressed. If the reader of this message is not the intended
> recipient, you are hereby notified that any retention, dissemination,
> distribution or copy of this e-mail is strictly prohibited. If you
> have received this e-mail in error, please notify us immediately by
> reply e-mail and immediately delete this message and all its  
> attachment.
>
>
>
> On Dec 23, 2007, at 7:25 PM, Steven Stromer wrote:
>
>> Many of my smaller clients use high-end consumer or low-end
>> professional router/gateways. These router/gateways provide DHCP
>> services for the LAN, and are thus providing LAN hosts with DNS
>> information dynamically. The DNS servers that the LAN hosts are
>> pointed to are BIND servers running on the LAN. In these router/
>> gateways, there is no DHCP specific option for specifying the the IP
>> address to offer for DNS. The only solution is to assign the LAN
>> address of the BIND server in the router's WAN configuration.
>>
>> The result that I believe is achieved is that the router/gateway
>> provides the LAN address of the local BIND host to the local clients
>> (this part I know to be correct). When needing name resolving
>> service, the local clients query the DNS service on the LAN, and the
>> BIND service uses full recursion to query authoritative name servers
>> on the internet, passing these queries, and all replies, through the
>> very router/gateway that provided the DHCP service.
>>
>> This seems to function, but not perfectly; I notice that web pages
>> and similar services that depend on name resolution load more slowly
>> than I'd expect them to, but I'm not sure why. I am not certain
>> whether the router 'appreciates' having to look inward to the LAN for
>> name resolution, or having to pass the DNS responses on to the BIND
>> server on the LAN instead of handling them itself.
>>
>> There exists an option in the router/gateway to toggle on or off
>> 'Provide DNS proxy service', which I have turned off, so that the
>> router/gateway will not try to use its own DNS configuration (which,
>> as described earlier, points to the BIND server on the LAN) to
>> resolve the outgoing queries from the BIND server. This would
>> obviously cause a never-ending loop between the BIND service running
>> on the LAN and the router/gateway itself.
>>
>> I have a feeling that the best solution would be to move the DHCP
>> service to one of the internal linux servers, and to be done with it
>> all, but it doesn't resolve my curiosity regarding this arrangement,
>> nor does it provide me the time to rearrange DHCP service, which is
>> really limited at the moment. Any insight on whether this convoluted
>> configuration could ever work would be really appreciated!
>>
>> Thanks,
>> Steven Stromer
>>
>>
>
>
>