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 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
