DNS "Fake" Authority for hidden forwarders?

Wed Dec 15 00:01:52 UTC 2010

In message <AC9E4B93-2A89-4D07-851B-1BA2FBA08A0C at taranta.discpro.org>, Leland Van
dervort writes:
>
> Hi All, 
>
> 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...).

Well set the AA bit.  It's a python script which you can fix with
a text editor.  If it's acting as a authoritative DNS server, even
in part, then it should be doing what a authoritative DNS server
does.

> 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.

So you want the cache to lie about being a cache.

> 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 
>     // 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).  
>
>
> Is there anything out there that can do such authority
> masquerading/proxying?
>
>
> Thanks in advance
>
>
> Leland
>
>
>
>
>
>
>
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org