Access problem - dnscache as external forwarder

I'm running dnscache (djbdns) on a FreeBSD box, as an external forwarder.

In root/servers, I have "@" being my ISP's nameservers:
64.x.0.x
64.x.1.x

In root/ip, I have "127.0.0.1" and "192.168.1".

When I run

env DNSCACHEIP=127.0.0.1 dnsqr a www.aol.com

it works fine, but if I run

env DNSCACHEIP=192.168.1.31 dnsqr a www.aol.com

it hangs. Same if I try it from a different box, or try to ping www.aol.com with only 192.168.1.31 in resolv.conf.

is that the wrong thing for root/ip? should it be working??? any ideas?

-Kevan

That sounds right - what does the log:

log/main/current

say?

It looks like it is catching the "local" request but not the "external ip" requests:

I get this:



which I think is the local request (env DNSCACHEIP=127.0.0.1 dnsqr a www.aol.com) being answered, but neither the external (env DNSCACHEIP=192.168.1.31 dnsqr a www.aol.com) or a ping from another host pointing at this server shows any entry in the log.

Am I outright restricting access to the port or something?

netstat -na gives me (pertinent lines only shown...)



I notice there's no tcp on the 192.168.1.31/port 53...

I don't know jesus from satan in djbdns as I've never used it, but one thing I can say. If you're not listening on TCP, but you are on UDP, for all intents and purposes your server is on the air. lots of people block TCP connections to their dns servers. TCP is only required when:

1) a response to a query exceeds 512 bytes in which case a UDP datagram is not capable of transmitting the entire response. The client is then bound to try to connect to you via TCP to reissue the query.

2) a IXFR (Incremental Transfer) or AXFR (Full Zone Transfer) is asked of your servers. Those responses are so potentially huge that TCP is required for this kind of transaction. Normally, only slave servers will be making these kind of requests to your server to update their records.

ok, so my machine thinks it's listening correctly. then why no response to dnsqr/ping...

Perhaps your router or firewall configuration is not allowing UDP requests to reach your server.

I can give you more detailed information on the status of your server if you give me its IP address, and the name of one of the zone's you are hosting.

it's literaly an internal server behind NAT, so, no, I can't really do that.

Basic setup:

ISP---DSL Modem---Router--- Internal Net

on the internal net I have dnscache running on a machine at 192.168.1.31. I have the resolv.conf of that machine pointed only at 127.0.0.1. If, from that machine, I ping an address on the internet, or use dnsqr with the ENV var set to 127.0.0.1, it works fine.

If I use dnsqr with the ENV var set to the network IP (192.168.1.31), or, from another machine on my internal network (that has only 192.168.1.31 in resolv.conf), try to ping externally, it does not work, nor is anything logged. It shouldn't be going through the router to try and hit the machine - it's possible that some firewall settings might be set on the dns forwarder - in this regard (on FreeBSD at least) I know pretty little - though I'd be willing to show any config files I might have if you point me in the right direction.

Possible monkey-wrench in the works: I'm also trying to use tinydns on the same machine to answer requests for an internal domain. It literaly (not straying far from the djbdns docs) is .internal.

So, the 192.168.1.31 machine (the dns) is named "cardhu.internal". My other machines in the internal net all have similar (single malt scotch inspired) A records. This seems to be working fine, though granted I have issues with nslookup (versus dnsqr/dig/etc) and Windows boxes that I was going to bring up once I got the forwarder issue resolved.

To recap:

/etc/dnscache/root/ip:
127.0.0.1
192.168.1

/etc/dnscache/root/servers:
@, contains:
64.x.0.10
64.x.1.10

internal, contains:
192.168.1.31

/etc/dnscache/env:
FOWARDONLY:1
IP:127.0.0.1
IPSEND:0.0.0.0

any of these off? otherwise, any ideas about firewall configs?

Thanks

You need to get alexgreg involved in this topic. He's the djbdns user and can tell you where the config has gone wrong.

I've also seen a bunch of posts by "freebsd" about djb's programs (maybe more with qmail?)

Either of you aware of whatever the heck I'm doing wrong here?

Some more detail:
Say I'm on a Windows box internally (for the sake of accuracy, 192.168.1.20). I type nslookup, it fails to connect to my internal box (192.168.1.31), so it rolls over to the backup ISP nameservers. I tell it "server 192.168.1.31", force it to ask my local freebsd box. I then ask it a LOCAL dns query (ie, lagavulin.internal), it responds right away, CORRECTLY (lagavulin is 192.168.1.2, and also one of the nicest malts from the isle of Islay, in case nybody cares about my naming schema). Note - this does not create an entry in the dnscache log either...

Aha! But now I ask it for an external name: www.perl.com. This causes it to time out, just like it has been doing. And of course, no entry in the dnscache log...

And of course, I just looked, and the tinydns log DID pick up the call for the ".internal" request...

I think I'm bringing myself quickly to the conclusion that tinydns is obviously listening and intercepting the same requests - but what I now am confused about is how to make this machine both serve the internal domain and forward the external requests, with these two programs (tinydns and dnscache)...

How would this be done under BIND, for that matter (not that I want to run named again...)?

and of course, searching around more on http://cr.yp.to finds this:

The importance of separating DNS caches from DNS servers

which of course says you need to have mutiple IP addresses and have the two programs listen for caching on one IP and be authoritative on another IP - and then tell the cache that the second IP is the authority...

Well, I'll give all that a shot tonight and let you know.

The fact you have only tcp port 53 open on all interfaces is indicative that you have axfrdns running - as you no doubt know dnscache handles recursive lookups (listening for UDP only) whereas axfrdns handles TCP queries for the case a zone transfer needs to be performed (see silentrage's post above).

So in essence the netstat output looks right.

How about doing:

sockstat -4 | grep :53

just to verify what daemons are listening on port 53?

Also how did you set up dnscache - did you use the dnscache-conf tool?

Personally I only have dnscache listening on my loopback interface since I run tinydns and axfrdns on the external interface for external (non-recursive) queries. As such I can only go by what the manual says about configuring dnscache to listen on more than one interface:


Which is what you've done from reading your first post right?

One thing though - have you tried leaving the @ file alone totally? From the manual it sounds as though there should only be root servers in that file:

Well, that did it. All good now, here's the end setup:

The point is, tinydns and dnscache are meant/need to run on different servers (or at least IPs). The rationale is that dnscache serves as your cache, and provides lookup service to your local machines, where as tinydns is your SOA, your authority for whatever domain you are serving (even in my minor case of running xxx.internal), and thus has a completely different role.

So I set up IP aliasing to have my NIC answer two IPs (.31 and .41 in my case). I then set up dnscache on .31, and tinydns on .41.

netstat now looks like this:


Note I still have the tcp listener for the reasons you guys mentioned. I point resolv.conf on all machines to 192.168.1.31, and in dnscache/root/servers I have:

"@", with my ISP nameservers, and
"internal", with 192.168.1.41

Thus, dnscache calls tinydns as the authority when it gets an "internal" request.

I will say, even though djbdns is not necessarily the "standard" and takes a different paradigm when dealing with it, it has been very easy to change and test configurations - and now that it is set up, quite easy to administer.

Yes I really like djbdns - it's just unfortunate that to run an authoratative server and a recursive server on the same machine you need to have two ip addresses. Then again though if you're undertaking the administration of DNS and you want security that's a small price to pay.

not to dis on djbdns, but that is a bad limitation if that is indeed the case. I have both an authoritative and caching server wound up in a single server using BIND. It makes perfect sense that all queries it is not authoritative for can be cached, and that all recursive requests can be handled. There is no technical reason for there to be a conflict.

There's some info on why you shouldn't run an auth and recursive nameserver on the same IP here:

http://cr.yp.to/djbdns/separation.html

I think one of the main reasons for separation