[Pdns-users] Fwd: Re: Recursion when Powerdns auth servers is SOA

[Chris Moates]

We have a different use case but similar situation. In our case, we are
(unfortunately) using the same domain both internally and externally. So
some entries only exist internally, some only externally, and some both,
but with different IP's. Here's an example:

web1.domain.com has a 10.x and 208.x address, depending on if you're
outside or inside.
www.domain.com only exists externally
database.domain.com only exists internally

What I'd like to do is have our internal DNS servers try asking the outside
DNS servers when they don't have a record. What we have to do now is copy
the relevant records across and maintain them in two places. Previously, we
had accomplished this with Bind's split views, but that had it's own share
of issues.

I've toyed with implementing a backend that would query the external
server, as it seems my best option. I just haven't gotten to completing it
yet. Sort of a "also ask this DNS server" backend.

Cheers,
Chris

On Tue, Jan 10, 2012 at 6:44 PM, Rory Toma <rory at ooma.com> wrote:

>  I noticed I failed to reply to the list...
>
>
> -------- Original Message --------  Subject: Re: [Pdns-users] Recursion
> when Powerdns auth servers is SOA  Date: Tue, 10 Jan 2012 14:56:13 -0800  From:
> Rory Toma <rory at ooma.com> <rory at ooma.com>  To: bert hubert
> <bert.hubert at netherlabs.nl> <bert.hubert at netherlabs.nl>
>
>
> On 1/10/12 2:48 PM, bert hubert wrote:
>
>
>  On Jan 10, 2012, at 11:37 PM, Rory Toma wrote:
>
>  "To make sure that the local authoritative database overrides recursive
> information, PowerDNS first tries to answer a question from its own
> database. If that succeeds, the answer packet is sent back immediately
> without involving the recursor in any way. This means that for questions
> for which there is no answer, PowerDNS will consult the recursor for an
> recursive query, even if PowerDNS is authoritative for a domain! This will
> only cause problems if you 'fake' domains which don't really exist."
>
> What I want to do is have powerdns consult the recursor even of powerdns
> is authoritative for a domain. This is what I can' seem to get to work.
>
>
>  I think we no longer do this, and that the documentation is in that case
> out of date. It complicated things too badly.
>
>  If you want to override the internet, you may have more success the
> other way around, put a PowerDNS Recursor with specific authoritative data
> as an auth server.
>
>  Bert
>
>
> I'll explain my problem in a little more detail, and then perhaps
> suggestions can flow:
>
> We are using dns as a registration system. Devices contact a server and
> register, a dns record is created. For the sake of this discussion, I'll
> refer to this as old registration system (bind and old registration
> servers) and new registration system (powerdns and new server)
>
> Many "apps" need to look up the information in dns, we have a keepalived
> fault tolerant IP address that points to a name server (currently bind),
> but we'd like to switch this to powerdns. However, we can't just switch all
> the dns records over at once, there has to be a transition period. So, we'd
> like to switch over to powerdns and new registration server. All new
> records will exist in powerdns. Eventually, all the old records will
> migrate as clients re-register.
>
> So, when someone queries the new server, it needs to look up the data
> first in powerdns, and if it isn't there, recurse.
>
> I tried putting the powerdns recursor in front. It did not work for me, as
> each backend server thinks it is authoritative. So if it happens to query
> that one first, it returns NXDOMAIN and never looks at the next one in the
> list.
>
>
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20120110/44802446/attachment-0001.html>