Providing local DNS service behind a cheap router/gateway
Steven Stromer
filter at stevenstromer.com
Wed Jan 2 19:46:30 UTC 2008
> Why is your query source port set to 53? As discussed recently on
> this list, using that setting, while perfectly valid, causes
> problems with broken installations elsewhere on the net, causing
> your server to be unable to query certain other name servers.
>
> Does the problem go away if you remove the port from the query-
> source statement?
Unfortunately, changing 'query-source address 192.168.0.38 port 53;'
to 'query-source address 192.168.0.38 port *;' results in all name
resolution failing (and also seems to cause our router to generate
error logs like 'router1 DBG0071AD ICMP Packet from 192.168.7.2 to
0.0.82.59 dropped, Cause: Illegal IP !').
Further, an exhaustive search through bind-user messages failed to
return the discussion thread that you alluded to. I'm sure I missed
it; maybe you have a thread title, or a direct link?
Finally, the original problem continues: removing the forwarders
option causes all name resolution to fail, as described earlier.
Beside my earlier description of changes, the only other recent
change was to update the firmware on our router. This required re-
entering forwarding rules. Outbound activity is entirely open, and
port 53 is open for both TCP and UDP traffic inbound.
No logs are generated during failed lookup attempts, as far as I can
tell, so I'm having a hard time even finding a starting point to
debug from. This nameserver is also under heavy use, so experimenting
with it is a bit challenging.
If I can provide any better documentation, please tell me what you
need. Any ideas would be MUCH appreciated!
Steven Stromer
>
> On Dec 30, 2007, at 10:22 AM, Steven Stromer wrote:
>
>> 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
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
More information about the bind-users
mailing list