Providing local DNS service behind a cheap router/gateway
Steven Stromer
filter at stevenstromer.com
Thu Jan 3 02:16:25 UTC 2008
On Jan 2, 2008, at 6:22 PM, Steven Stromer wrote:
> I appreciate your warnings regarding use of a query-source statement
> and of specifying port 53, but this is not really the problem that
> I'm trying to seek assistance for. Again, the recent changes I have
> described in this thread have left me with a nameserver that can do
> nothing but forward queries. Though I could be wrong, I don't think
> that this has anything to do with my router or firewalling; this
> router has permitted such queries to pass through for years without a
> problem. I remain lost to the reasons for the real problem I am
> experiencing, despite experimentation and many fruitless hours of
> work.
>
> I am starting to question whether my newfound problem might have
> something to do with having installed the caching-nameserver package.
> I don't fully understand what this package does, especially when I've
> read all over the web that "an authoritative nameserver also caches
> by default". I have a feeling that it doesn't belong anywhere near a
> nameserver that is authoritative for a domain. (Again, the server in
> question provides recursive services for local users, and is
> authoritative for a domain publicly.) I see that the caching-
> nameserver package adds a file, 'named.caching-nameserver.conf'. I
> can't seem to find documentation that clearly explains what this
> package contains, what changes its installation makes to the
> installed bind service, or how named.caching-nameserver.conf
> interacts with the standard named.conf. If I wanted to uninstall the
> caching-nameserver package, would this be possible? What would have
> to be done beside 'yum remove caching-nameserver'?
>
> Is it possible that it was the installation of the caching-nameserver
> package that has created my newfound problems? Again, any help
> regarding this problem would be VERY, VERY much appreciated!
Trying to be self sufficient, I tried the following:
1. Listed the files in the caching-nameserver package:
# rpm -q -p http://download.fedora.redhat.com/pub/fedora/linux/core/
updates/6/i386/caching-nameserver-9.3.4-8.P1.fc6.i386.rpm -l
2. Compared each of the files contained in the caching-nameserver
package (all of which are listed below) with an archive of the files
from my bind server, line by line. In parens below, I first list
whether the install of the caching-nameserver package altered the
original named file, and then, how I handled the change to get back
to my previously working configuration.)
/etc/named.caching-nameserver.conf (NEVER EXISTED, AND WAS NOT CREATED)
/etc/named.conf (UNCHANGED)
/etc/named.rfc1912.zones (NEVER EXISTED, AND WAS NOT CREATED)
/usr/share/doc/caching-nameserver-9.3.4 (WAS REMOVED WITH 'yum remove
caching-nameserver')
/usr/share/doc/caching-nameserver-9.3.4/Copyright (WAS REMOVED WITH
'yum remove caching-nameserver')
/usr/share/doc/caching-nameserver-9.3.4/rfc1912.txt (WAS REMOVED WITH
'yum remove caching-nameserver')
/var/named/chroot/etc/named.caching-nameserver.conf (DID NOT
PREVIOUSLY EXIST - RENAMED EXTENSION - SHOULD BE DELETED...)
/var/named/chroot/etc/named.conf (UNCHANGED)
/var/named/chroot/etc/named.rfc1912.zones (DID NOT PREVIOUSLY EXIST -
RENAMED EXTENSION - SHOULD BE DELETED...)
/var/named/chroot/var/named/localdomain.zone (CHANGED - RENAMED AND
RECOVERED ORIGINAL FROM BACKUP)
/var/named/chroot/var/named/localhost.zone (UNCHANGED)
/var/named/chroot/var/named/named.broadcast (UNCHANGED)
/var/named/chroot/var/named/named.ca(DID NOT PREVIOUSLY EXIST -
RENAMED EXTENSION - SHOULD BE DELETED...)
/var/named/chroot/var/named/named.ip6.local (CHANGED - RENAMED AND
RECOVERED ORIGINAL FROM BACKUP)
/var/named/chroot/var/named/named.local (CHANGED - RENAMED AND
RECOVERED ORIGINAL FROM BACKUP)
/var/named/chroot/var/named/named.zero (UNCHANGED)
/var/named/localdomain.zone (RENAMED localdomain.zone.rpmorig -
RENAMED BACK TO ORIGINAL FILENAME)
/var/named/localhost.zone (RENAMED localhost.zone.rpmorig - RENAMED
BACK TO ORIGINAL FILENAME)
/var/named/named.broadcast (RENAMED named.broadcast.rpmorig - RENAMED
BACK TO ORIGINAL FILENAME)
/var/named/named.ca (NEVER EXISTED, AND WAS NOT CREATED)(I thought
this had been replaced by named.root a long time ago.)
/var/named/named.ip6.local (RENAMED named.ip6.local.rpmorig - RENAMED
BACK TO ORIGINAL FILENAME)
/var/named/named.local (RENAMED named.local.rpmorig - RENAMED BACK TO
ORIGINAL FILENAME)
/var/named/named.zero (RENAMED named.zero.rpmorig - RENAMED BACK TO
ORIGINAL FILENAME)
Further, according to RedHat, 'If you have installed the caching-
nameserver package, the default configuration file is /etc/
named.caching-nameserver.conf. To override this default
configuration, you can create your own custom configuration file in /
etc/named.conf. BIND will use the /etc/named.conf custom file instead
of the default configuration file after you restart.' I'm assuming
that they mean, 'restart the named service', and not the actual
hardware...
How can I tell what else the installation of the caching-nameserver
package affected? I have never created my own rpm packages, and don't
know how to access the installer script within the package.
Thanks again,
Steven Stromer
>
>
>> You don't need the "port *". Just use:
>>
>> query-source 192.168.0.38;
>>
>> Or remove the "query-source" statement altogether. You probably
>> shouldn't need it, except as described below.
>>
>> It sounds like your router is, for whatever reason, forbidding
>> outbound DNS queries with a source port other than 53. If this is
>> the case, this is really bad. Your only solution is to forward
>> queries and use the query-source statement with port 53, as you are
>> doing now, until you can replace or fix your broken router.
>>
>> 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 Jan 2, 2008, at 11:46 AM, Steven Stromer wrote:
>>
>>>> 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