[133615] in North American Network Operators' Group
DNS "Fake" Authority for hidden forwarders?
daemon@ATHENA.MIT.EDU (Leland Vandervort)
Tue Dec 14 14:22:15 2010
From: Leland Vandervort <leland@taranta.discpro.org>
Date: Tue, 14 Dec 2010 20:22:00 +0100
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
Hi All,=20
Apologies if off topic, but hoping that one of you gurus out there might =
have some tips on this.
I have a rather "unusual" application for DNS which I need to figure out =
a way to make it work, but running into authority issues.
Basically, I have a "fake" server running on a private network which can =
respond to PTR and A requests dynamically, with their details extracted =
from a database. In front of that in the public network, I have two =
servers (load-balanced) which can handle the queries from the "world" =
for these zones.
The problem is that the backend "dummy" server doesn't not actually =
generate a zone as such, and does not set the AA bit (it's a python =
script, actually...).
I'm trying find a way for the front-end servers to declare themselves as =
authority for the zones in question, but obtaining the details of the =
records via forwarder to the dummy server behind, then of course caching =
the response for the stated TTL in the response.
I have looked at various configuration options of BIND and nothing =
really works, be it a forward, split-horizion, hidden-master, =
hidden-slave, etc.
Is there another daemon somewhere out there that can do something along =
lines of this pseudo configuration:
zone "1.168.192.in-addr.arpa" {
type master;
// actually a "fake" master to pretend to be the authority
allow-query { any; };
recursion no;
file "/etc/bind/zones/1.168.192.in-addr.fake-master.zone";
// file contains an SOA and NS record of the zone
// pointing to the "public" visible servers (i.e. myself)
// actual records (PTR, A, AAAA, etc.) are dynamically retrieved
// from a "record-forwarder", but works the same way as=20
// a standard forward type zone:
record-forwarders {
10.1.1.2;
};
};
When an external query arrives for the zone, the front-end server =
declares itself to be authoritative for the zone, but obtains the actual =
A/PTR/AAAA record via the back-end forwarder, and stuffs it into the =
response as if it was locally configured. It then keeps it in cache.
For the moment, I have it setup simply as a forwarder, and it does =
indeed respond to queries for the dynamically generated queries, but =
only if queried DIRECTLY (dig -x 1.1.1.1 @frontend-server) , but it =
responds without authority. As such, this configuration cannot be used =
for "live" deployment. (the front-end servers are of course fully =
delegated for the zones in question, so they need to be authoritative). =20=
Is there anything out there that can do such authority =
masquerading/proxying?
Thanks in advance
Leland
