DNS "Fake" Authority for hidden forwarders?

[Leland Vandervort <leland () taranta discpro org>]

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

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