Providing local DNS service behind a cheap router/gateway
Steven Stromer
filter at stevenstromer.com
Wed Jan 2 23:22:56 UTC 2008
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!
> 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