In message <AC9E4B93-2A89-4D07-851B-1BA2FBA08A0C@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@isc.org