Tag: djbdns

Preface:

I remember long time ago when i had to mess around with BIND, the old, venerable, security flaws rich history, and of course the not for humans configuration file, name server. I’m so happy that i switched to djbdns and of course the very practical vegadns GUI.

End of preface.

So, in a a scenario where you have a network with private address(es), yes it can be in the same physical machine (like a private IP jail….) you can use tinydns to publish a PTR record for that IP(s) and force dnscache to use your own published PTR record to resolve the private IP to the configured domain/hostname.

First configure tinydns, you can use vegadns as usual, set a new in-addr.arpa domain according to the pretended IP(s) reverse. Ex:

For several 10.1.1.x addresses, configure a 1.1.10.in-addr.arpa domain, if you just want to configure a reverse record for 10.1.1.2 it’s enough to configure a 2.1.1.10.in-addr.arpa (note in both situations the inverted IP). Don’t forget to set the NS records to your own tinydns instance. Then it’s just a matter of configuring the IP PTR record. Let’s say 10.1.1.1 PTR my.domain.com, in vegadns you insert the IP in the hostname and my.domain.com in the address field (it’s a reverse) and choose PTR from the type select.

Now, for the dnscache resolver use this information, and query directly your server bypassing the normal reverse resolve process. Actually is a very simple, just create a file in /etc/dnscache/root/servers/ with the same tinydns logic. Ex: to bypass only for IP 10.1.1.2 create a 2.1.1.10.in-addr.arpa file, for all 10.1.1.x addresses a 1.1.10.in-addr.arpa file and so on. In the newly created file you just have to put the tinydns IP that dnscache will use to do the resolve queries.

You can easily test if everything is ok, with the good old reliable dig command:
dig +noall +answer -x 10.1.1.1