[Pdns-users] Managing pdns-recursors forward.zones file

[Marc Haber]

On Mon, Jan 07, 2013 at 10:02:33AM +0100, Thomas Mieslinger wrote:
> On 04.01.13 09:06, Peter van Dijk wrote:
> >Hello Thomas,
> >
> >On Jan 3, 2013, at 20:21 , Thomas Mieslinger wrote:
> >
> >>currently my team mates and I use a script to build a (currently) 423 lines long forward.zones file.
> >>Every time we need to touch it we have fear to break things really fast.
> >
> >Why?
> 
> We have 12 recursor (this year growing to 20) boxes each with four
> instances with different configuration. When we need to change
> something in the forward.zones file, then we edit files in puppet,
> have to log into every machine to do the puppet run by hand and
> watch it doing things.
> Maybe this is home made problem and we should use puppet differently
> so that we regain trust in it but after all this is a philosophical
> question.

IMO your analysis is correct. This suspiciously looks like a home made
problem and you're using puppet wrong ;-)

Usually, a staging setup is used to test changes first on a smaller
number of (probably not productively used) machines before taking the
configuration verbatim to production. This would need, however, some
effort to keep staging and production sufficiently simliar so that a
change can _really_ be taken verbatim. The moment you need changes to
a tested change, it becomes an untested change and you have gained
nothing.

> Where do we manage dns data? In Puppet or somewhere else? For our
> 4000 Zones we've decided "some where else". So I'd like to be able
> to manage the forward.zones "just like" dns data...

DNS data is, however, managed in the authoritative server, and not in
the recursor. I guess that you use some kind of database setup for the
authoritative servers, so you are probably asking for a forward.zones
database setup, but that will probably be hard to do since the
recursor does not have a database interface yet and is not as modular
as the authoritative server is written.

Using a forward.zones.d directory is what immediately came to my mind,
but on a second thought you are only duplicating the effort there,
since you already have puppet.

Are you using puppet-concat to build the forward.zones file, or do you
have the big forward.zones file verbatim in your puppet?

> >>So I'm thinking about two solutions:
> >>- I could add functionality to my employers new ip address and dns management tool to manage forward.zone files.
> >>- I could regular download the root-zone file, strip dnssec from it, append information for the 423 forward.zones and load it into our pdns-authoritative servers and shorten the forward.zones to
> >>".=<pdns-authoritative-IPs>"
> >>
> >>Has anyone already tried the second method? Do you think that could work?
> >
> >A simplified version of that file might look like this (I presume, please correct me if I'm wrong!)
> >. SOA ....
> >com. IN NS a.gtld-servers.net.
> >hotmail.com. IN NS ns.pc-h.de.
> >
> >If the recursor asks for www.google.com, it will get the com referral, and cache that. If it *then* needs www.hotmail.com, it will presumably use that cached com referral. I have not tried this but I have the feeling this is where it would go wrong.
> 
> Thanks for the hint with the simplified root zone.

I don't see how this would ease your pain though. It would only make
your forward.zones file _more_ complex and the recursor will fall back
to the root servers anyway when a zone is not found in forward.zones

But maybe, I am missing something and I don't know your setup.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062