[Pdns-users] allow-recursion-override for 'fake' domain causes problem delegating fake subdomain

[Brendan Oakley]

Hi John,

On 10/9/08, John Morris wrote:
>
>  So, the internal pdns has the NS and glue records for the
> test.somedomain.com network, and lookups behave as follows.
>
>  Without allow-recursion-override, queries resolve as follows on the
> internal ns:
>
>  Recursive queries for foo.test.somedomain.com aren't found, and so are
> forwarded to pdns-recursor, which knows
> "forward-zones=test.somedomain.com=192.168.200.3".  That ns
> serves the test.somedomain.com + reverse zones.  With
> allow-recursion-override, the needed answer is produced, but causes the
> above-stated problem (non-existant foo.somedomain.com is recursed to the
> Internet authoritative servers, causing timeouts and waits when WAN link is
> disconnected).  FYI, non-recursive queries for foo.test.somedomain.com
> return NS + glue records for the test.somedomain.com subdomain.
>
>  With allow-recursion-override, queries resolve as follows:
>
>  Recursive queries for foo.test.somedomain.com aren't found in the internal
> nameserver, and fail.  (Non-recursive queries produce the same behavior as
> without allow-recursion-override.)

Yeah, sorry, for some reason I was working on the assumption there was
a recursor in front of the domain server that could make use of the
glue records, but that's clearly not the case.

>  What is the recommended setup in this case?  An alternate configuration
> would be to put the recursor in front of the pdns (and turn off recursion in
> pdns), and indeed we used to do this, but our rapidly changing network
> causes inconvenience when the recursor caches old information about the
> local zones, even when TTLs are as short as 5 minutes.  A third possibility
> would be to put the test.somedomain.com zones in the internal network's pdns
> (and turn off forward-zones in the recursor), which would require additional
> configuration to replicate the LDAP backend from the test network (which is
> treated as a DMZ).

The LDAP backend should do AXFR transfers, if you just set up the
subdomain on your local DNS as a slave. Is there any reason not to do
that?

Putting the recursor in front would have been my next suggestion if
the slave option won't work. I sympathize with your not wanting to
cache local data in the recursor. I tried to solve a similar problem
by using the PipeBackend as a forwarder for domains we don't want to
cache, but the performance hit was too great. If your load volume is
low enough that performance isn't an issue, I could send you my
backend script so you can adapt it. But I would consider the slave
zones to be a much more elegant solution.

Brendan