Re: Metazones or Something Else?
Il 04/ago/2014 18:33 "John Anderson" ha scritto: > > Greetings Bind-Users List, > > I've recently inherited a project that is going to require some method of automatically disseminating zone information to slave DNS servers running BIND. While searching for an industry standard method of accomplishing this task, I came across this rather dated document that Paul Vixie wrote on accomplishing exactly this task. [ http://dotat.at/tmp/metazones.pdf ] Since reading that document, I have been unsuccessful in locating any documentation of this feature on ISC's website. > > Has this metazone idea gained any traction? Is there a distributable implementation? If not, has another technology emerged which essentially injects restart-persistent zone SOA record information into BIND so that it may then receive AXFR/IXFR for the zone from the master? I don't know metazone, but webmin permits to deploy automatically new zone to a predefined dns slaves "cluster". Work perfectly, very simple to use. Best regards > > Any nudge in the right direction would be appreciated. > > John A. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Metazones or Something Else?
>
> Personally I'd like to extend UPDATE
>
> allow-addzone { acl; };
> allow-delzone { acl; };
> e.g.
> nsupdate
> new zone
> server addresss [port]
> key name:secret
> [masters ]
> [allow-query ]
> [allow-transfer ]
> [allow-update ]
> [conf text]
> [conf text]
> [conf text]
> [zone data for master]
> send
>
> nsupdate
> del zone
> key name:secret
> send
>
> Where "new" is a EDNS options which optionally has master addresses /
> names allow-query is a EDNS acl option of subtype query [default any;
> if missing] allow-transfer is a EDNS acl option of subtype transfer
> [default any; if missing] allow-update is a EDNS acl option of subtype
> update [default none; if missing] conf is a EDNS which contains other
> configuration data for a zone
>
> Mark
>
> In message <20140805164053.ga11...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > On 05.08.14 11:43, Brian Cuttler wrote:
> > >The slave trusts the master, for zone files, but creating a new
> > >zone?
> >
> > hmmm, when a meta-zone is signed by trusted key, why not? :-) using
> > notifies and IXFR would be even more great...
This looks very interesting, and would likely do the trick. While waiting to
see what is incorporated into named, I'm going to attempt to implement metazone
as originally describe by P. Vixie. We are using NicTool's API to translate
SOAP requests into persistent SQL, and then NicTool's scripts will convert the
information in the SQL database into named compatible zone files.
I'm going to attach some triggers at the SQL level, so when the API creates a
new "zone" entry in the SQL table, that zone entry will get inserted as a
record in the "metazone" entry in the SQL tables.So when the scripts
compile the SQL into zone files, a metazone file will be created as Vixie's
white-paper describes. Then I'll likely use a python or perl to convert the
information in the metazone to named.conf fragments and HUP named. The
conversion will take place based on inotify events. So in short, NicTool
will convert SQL to named.conf master and zone files. One of those zone files
will be in the metazone format. NicTool will export these files to the
stealth master DNS servers. Each slave will be manually configured to
sync/allow-update of the metazone. So the metazone information will be
transmitted to each slave via DNS IXFR, in-band. Once the metazone is XFR'd to
each slave, and written to disk, an inotify event will trigger a script which
will re
ad in the metazone file, and generate stub configuration in something like
/etc/named.conf.d/*.conf files, and it will finish by sending a HUP to named.
After reloading, named on the slaves will have knowledge of the new zones
created on the masters, and will initiate an AXFR of those zones.
I'll be more than happy to share my work and architecture when I'm done.
John A.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
Mark,
That looks like a nice format for it.
I'd still like to see named.conf mark some zones as
uneditable via rdnc, just in case I want to allow a
peer institution to add/remove zone where I'm the
secondary, I want some mechanism to prevent them from
accidently deleting zones I'm actually the master of.
Perhaps as 'simple' as having different zones fall under
different management keys? Is that possible? My zones
protected by a differnt management key then the zones that
my colleges use?
Albany.edu may provide DNS secondary for RPI.edu, but they
certainly don't want RPI to edit the wrong zones file.
On Wed, Aug 06, 2014 at 09:35:00AM +1000, Mark Andrews wrote:
>
> Personally I'd like to extend UPDATE
>
> allow-addzone { acl; };
> allow-delzone { acl; };
> e.g.
> nsupdate
> new zone
> server addresss [port]
> key name:secret
> [masters ]
> [allow-query ]
> [allow-transfer ]
> [allow-update ]
> [conf text]
> [conf text]
> [conf text]
> [zone data for master]
> send
>
> nsupdate
> del zone
> key name:secret
> send
>
> Where "new" is a EDNS options which optionally has master addresses / names
> allow-query is a EDNS acl option of subtype query [default any; if missing]
> allow-transfer is a EDNS acl option of subtype transfer [default any; if
> missing]
> allow-update is a EDNS acl option of subtype update [default none; if missing]
> conf is a EDNS which contains other configuration data for a zone
>
> Mark
>
> In message <20140805164053.ga11...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > On 05.08.14 11:43, Brian Cuttler wrote:
> > >The slave trusts the master, for zone files, but creating
> > >a new zone?
> >
> > hmmm, when a meta-zone is signed by trusted key, why not? :-)
> > using notifies and IXFR would be even more great...
> >
> > --
> > Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> > Warning: I wish NOT to receive e-mail advertising to this address.
> > Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> > You have the right to remain silent. Anything you say will be misquoted,
> > then used against you.
> > ___
> > Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> > unsubscribe from this list
> >
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
---
Brian R Cuttler brian.cutt...@wadsworth.org
Computer Systems Support(v) 518 486-1697
Wadsworth Center(f) 518 473-6384
NYS Department of HealthHelp Desk 518 473-0773
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
Personally I'd like to extend UPDATE
allow-addzone { acl; };
allow-delzone { acl; };
e.g.
nsupdate
new zone
server addresss [port]
key name:secret
[masters ]
[allow-query ]
[allow-transfer ]
[allow-update ]
[conf text]
[conf text]
[conf text]
[zone data for master]
send
nsupdate
del zone
key name:secret
send
Where "new" is a EDNS options which optionally has master addresses / names
allow-query is a EDNS acl option of subtype query [default any; if missing]
allow-transfer is a EDNS acl option of subtype transfer [default any; if
missing]
allow-update is a EDNS acl option of subtype update [default none; if missing]
conf is a EDNS which contains other configuration data for a zone
Mark
In message <20140805164053.ga11...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 05.08.14 11:43, Brian Cuttler wrote:
> >The slave trusts the master, for zone files, but creating
> >a new zone?
>
> hmmm, when a meta-zone is signed by trusted key, why not? :-)
> using notifies and IXFR would be even more great...
>
> --
> Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> You have the right to remain silent. Anything you say will be misquoted,
> then used against you.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On 05.08.14 11:43, Brian Cuttler wrote: The slave trusts the master, for zone files, but creating a new zone? hmmm, when a meta-zone is signed by trusted key, why not? :-) using notifies and IXFR would be even more great... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. You have the right to remain silent. Anything you say will be misquoted, then used against you. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On Tue, Aug 05, 2014 at 09:41:14AM -0500, /dev/rob0 wrote: > On Tue, Aug 05, 2014 at 09:31:31AM -0400, Brian Cuttler wrote: > > On Tue, Aug 05, 2014 at 09:21:07AM -0400, Brian Cuttler wrote: > > > rndc addzone sounds like a very interesting tool, but > > > if you want an automated sync, will require something to > > > read the source config of the master and then write the > > > requisit slave zone information for the dns slave server(s). > > > > > > Offsite slave servers will require a lot of trust. > > > > - I guess not just trust, but some form of ACL so that remote > >managers can add/remove/edit only certain zones. This may be > >even a larger security issue than a technical issue. > > The slave trusts the master. The master would have to control the > access permissions. Dual-level access control would be hard to > implement, and not make much sense. The slave trusts the master, for zone files, but creating a new zone? What I was thinking of is not so much the on-site master/slave pair, I was wondering, and will allow that this may very well be well outside of the problem scope we are talking about, but what do you do with a remote secondary DNS that is being run on your behalf by another institution? That question being asked, I will also ask that we table it as the trust complexity is much much larger and likely not was what asked in the first place. I took the question out of the park, I will agree with you that for a master/slave pair belonging to a single management entity that trust and creation of zones need not be overly complex. > rndc.conf(5) does not provide flexibility in controlling access to > specific subcommands. (Evan, is that a feature you have thought > about?) So you'd probably have to use something like a web form, > authenticating users and keeping track of which user controls which > zones. > > > > Rsync solution for onsite servers will result in duplicate > > > copies of the master or the slave, unless you automate a > > > wrapper for that too (and I'm inclined to think in terms of > > > # sed, which I use in a surprising number of my scripts). > > named-checkconf -p", piped through sed, can easily convert master > zones to slaves. But "rndc addzone" can be automated. Have the web > form ssh to the slave[s] with the name of the new zone, there run a > script to add the zone. > > As an alternative, you could have the controls channel accessible to > the master over the network (perhaps a VPN for added security), and > simply have the web form do the "rndc addzone" remotely. > > Lots of choices, not easy to say what's best. Except that addzone > (and delzone also) works at runtime, not requiring a separate "rndc > reconfig" to load (or remove) zones. > -- > http://rob0.nodns4.us/ > Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users --- Brian R Cuttler brian.cutt...@wadsworth.org Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On Tue, Aug 05, 2014 at 09:31:31AM -0400, Brian Cuttler wrote: > On Tue, Aug 05, 2014 at 09:21:07AM -0400, Brian Cuttler wrote: > > rndc addzone sounds like a very interesting tool, but > > if you want an automated sync, will require something to > > read the source config of the master and then write the > > requisit slave zone information for the dns slave server(s). > > > > Offsite slave servers will require a lot of trust. > > - I guess not just trust, but some form of ACL so that remote >managers can add/remove/edit only certain zones. This may be >even a larger security issue than a technical issue. The slave trusts the master. The master would have to control the access permissions. Dual-level access control would be hard to implement, and not make much sense. rndc.conf(5) does not provide flexibility in controlling access to specific subcommands. (Evan, is that a feature you have thought about?) So you'd probably have to use something like a web form, authenticating users and keeping track of which user controls which zones. > > Rsync solution for onsite servers will result in duplicate > > copies of the master or the slave, unless you automate a > > wrapper for that too (and I'm inclined to think in terms of > > # sed, which I use in a surprising number of my scripts). named-checkconf -p", piped through sed, can easily convert master zones to slaves. But "rndc addzone" can be automated. Have the web form ssh to the slave[s] with the name of the new zone, there run a script to add the zone. As an alternative, you could have the controls channel accessible to the master over the network (perhaps a VPN for added security), and simply have the web form do the "rndc addzone" remotely. Lots of choices, not easy to say what's best. Except that addzone (and delzone also) works at runtime, not requiring a separate "rndc reconfig" to load (or remove) zones. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On Tue, Aug 05, 2014 at 09:21:07AM -0400, Brian Cuttler wrote: > > rndc addzone sounds like a very interesting tool, but > if you want an automated sync, will require something to > read the source config of the master and then write the > requisit slave zone information for the dns slave server(s). > > Offsite slave servers will require a lot of trust. - I guess not just trust, but some form of ACL so that remote managers can add/remove/edit only certain zones. This may be even a larger security issue than a technical issue. > Rsync solution for onsite servers will result in duplicate > copies of the master or the slave, unless you automate a > wrapper for that too (and I'm inclined to think in terms of > # sed, which I use in a surprising number of my scripts). > > On Mon, Aug 04, 2014 at 05:26:38PM +, Evan Hunt wrote: > > > So to the best of your knowledge this functionality is still on drawing > > > board, unless implemented out-of-band? (i.e. a perl script to parse > > > metazone.zone, and create /etc/named.d/*.conf files) > > > > Or run "rndc addzone". > > > > There's currently no supported way to perform in-band zone provisioning > > via the DNS itself. I do have access to the metazone implementation that > > Vixie wrote his paper about, and I can send it to you if you like, but I'm > > not sure how useful you'll find it. There might also be some interesting > > tricks possible with DLZ or with redhat's "dynDB" LDAP extension (which we > > plan to include in BIND 9.11 but is currently only available as a set of > > patches). > > > > Improving DNS provisioning is a hot topic for future development, but > > we're still just in the requirements-gathering phase. Would you like to > > share what it is you hope to do in more detail? > > > > -- > > Evan Hunt -- e...@isc.org > > Internet Systems Consortium, Inc. > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > --- >Brian R Cuttler brian.cutt...@wadsworth.org >Computer Systems Support(v) 518 486-1697 >Wadsworth Center(f) 518 473-6384 >NYS Department of HealthHelp Desk 518 473-0773 > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users --- Brian R Cuttler brian.cutt...@wadsworth.org Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
rndc addzone sounds like a very interesting tool, but if you want an automated sync, will require something to read the source config of the master and then write the requisit slave zone information for the dns slave server(s). Offsite slave servers will require a lot of trust. Rsync solution for onsite servers will result in duplicate copies of the master or the slave, unless you automate a wrapper for that too (and I'm inclined to think in terms of # sed, which I use in a surprising number of my scripts). On Mon, Aug 04, 2014 at 05:26:38PM +, Evan Hunt wrote: > > So to the best of your knowledge this functionality is still on drawing > > board, unless implemented out-of-band? (i.e. a perl script to parse > > metazone.zone, and create /etc/named.d/*.conf files) > > Or run "rndc addzone". > > There's currently no supported way to perform in-band zone provisioning > via the DNS itself. I do have access to the metazone implementation that > Vixie wrote his paper about, and I can send it to you if you like, but I'm > not sure how useful you'll find it. There might also be some interesting > tricks possible with DLZ or with redhat's "dynDB" LDAP extension (which we > plan to include in BIND 9.11 but is currently only available as a set of > patches). > > Improving DNS provisioning is a hot topic for future development, but > we're still just in the requirements-gathering phase. Would you like to > share what it is you hope to do in more detail? > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users --- Brian R Cuttler brian.cutt...@wadsworth.org Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Metazones or Something Else?
>There's currently no supported way to perform in-band zone provisioning >via the DNS itself. I do have access to the metazone implementation >that Vixie wrote his paper about, and I can send it to you if you like, >but I'm not sure how useful you'll find it. There might also be some >interesting tricks possible with DLZ or with redhat's "dynDB" LDAP >extension (which we plan to include in BIND 9.11 but is currently only >available as a set of patches). > >Improving DNS provisioning is a hot topic for future development, but >we're still just in the requirements-gathering phase. Would you like >to share what it is you hope to do in more detail? >Just as a data point, if you're looking for references -- I'd like to >be able to do "Amazon Route 53" type things (add/edit zones, not just >RRs) via some sort of API. Of course I want to be able to do this >myself, built on a standard platform (vs implementing the API layer as >a one-off) and not relying >on external parties. I suspect I'm not >alone in an increasing world of cloud operators. :-) Pretty much right on the nose for my use case as well. We are creating a new control panel for our hosting environment, which will be a front end for all our clients. We'll be providing public cloud, private cloud, private virtual data centers, as well as physical shared and dedicated hosting. My initial goal is to automate the insertion of reverse DNS for our clients when they "self provision" their own virtual, or physical machines. This may grow to be some sort of route 53 type offering for hosting our customer's forward DNS needs as well. We'll have authorative DNS servers scattered across the globe in our datacenters, and have tentative plans for setting up AnyCast for access. We'd like a user's actions in a central control panel during provisioning and deprovisioning to automatically handle as much of the workload as possible. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On 08/04/2014 09:33 AM, John Anderson wrote: I've recently inherited a project that is going to require some method of automatically disseminating zone information to slave DNS servers running BIND. The traditional solution to this problem is rsync, although I realize that's not very sexy. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
-Original Message- From: Evan Hunt Date: Monday, August 4, 2014 at 1:26 PM To: John Anderson Cc: "bind-users@lists.isc.org" Subject: Re: Metazones or Something Else? >> So to the best of your knowledge this functionality is still on drawing >> board, unless implemented out-of-band? (i.e. a perl script to parse >> metazone.zone, and create /etc/named.d/*.conf files) > >Or run "rndc addzone". > >There's currently no supported way to perform in-band zone provisioning >via the DNS itself. I do have access to the metazone implementation that >Vixie wrote his paper about, and I can send it to you if you like, but I'm >not sure how useful you'll find it. There might also be some interesting >tricks possible with DLZ or with redhat's "dynDB" LDAP extension (which we >plan to include in BIND 9.11 but is currently only available as a set of >patches). > >Improving DNS provisioning is a hot topic for future development, but >we're still just in the requirements-gathering phase. Would you like to >share what it is you hope to do in more detail? Just as a data point, if you're looking for references -- I'd like to be able to do "Amazon Route 53" type things (add/edit zones, not just RRs) via some sort of API. Of course I want to be able to do this myself, built on a standard platform (vs implementing the API layer as a one-off), and not relying on external parties. I suspect I'm not alone in an increasing world of cloud operators. :-) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
> So to the best of your knowledge this functionality is still on drawing > board, unless implemented out-of-band? (i.e. a perl script to parse > metazone.zone, and create /etc/named.d/*.conf files) Or run "rndc addzone". There's currently no supported way to perform in-band zone provisioning via the DNS itself. I do have access to the metazone implementation that Vixie wrote his paper about, and I can send it to you if you like, but I'm not sure how useful you'll find it. There might also be some interesting tricks possible with DLZ or with redhat's "dynDB" LDAP extension (which we plan to include in BIND 9.11 but is currently only available as a set of patches). Improving DNS provisioning is a hot topic for future development, but we're still just in the requirements-gathering phase. Would you like to share what it is you hope to do in more detail? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Metazones or Something Else?
> Some such ideas have been discussed on various lists. See this thread for > example: > >http://www.ietf.org/mail-archive/web/dnsext/current/msg13475.html > > Mukund Mukund, So to the best of your knowledge this functionality is still on drawing board, unless implemented out-of-band? (i.e. a perl script to parse metazone.zone, and create /etc/named.d/*.conf files) John A. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Metazones or Something Else?
Yes, the actual zone information, that would appear in named.conf something
similar to:
zone "name" in {
optionA;
optionB;
optionN;
};
-Original Message-
From: Brian Cuttler [mailto:br...@wadsworth.org]
Sent: Monday, August 04, 2014 9:49 AM
To: John Anderson
Subject: Re: Metazones or Something Else?
John,
Zone information? As in the named.conf file and not the zone files?
Brian
On Mon, Aug 04, 2014 at 04:33:24PM +, John Anderson wrote:
> Greetings Bind-Users List,
>
> I've recently inherited a project that is going to require some method of
> automatically disseminating zone information to slave DNS servers running
> BIND. While searching for an industry standard method of accomplishing this
> task, I came across this rather dated document that Paul Vixie wrote on
> accomplishing exactly this task. [ http://dotat.at/tmp/metazones.pdf ] Since
> reading that document, I have been unsuccessful in locating any documentation
> of this feature on ISC's website.
>
> Has this metazone idea gained any traction? Is there a distributable
> implementation? If not, has another technology emerged which essentially
> injects restart-persistent zone SOA record information into BIND so that it
> may then receive AXFR/IXFR for the zone from the master?
>
> Any nudge in the right direction would be appreciated.
>
> John A.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
---
Brian R Cuttler brian.cutt...@wadsworth.org
Computer Systems Support(v) 518 486-1697
Wadsworth Center(f) 518 473-6384
NYS Department of HealthHelp Desk 518 473-0773
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
Hi John On Mon, Aug 04, 2014 at 04:33:24PM +, John Anderson wrote: > Has this metazone idea gained any traction? Is there a distributable > implementation? If not, has another technology emerged which > essentially injects restart-persistent zone SOA record information > into BIND so that it may then receive AXFR/IXFR for the zone from the > master? Some such ideas have been discussed on various lists. See this thread for example: http://www.ietf.org/mail-archive/web/dnsext/current/msg13475.html Mukund pgpNorflNN_Tt.pgp Description: PGP signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Metazones or Something Else?
Greetings Bind-Users List, I've recently inherited a project that is going to require some method of automatically disseminating zone information to slave DNS servers running BIND. While searching for an industry standard method of accomplishing this task, I came across this rather dated document that Paul Vixie wrote on accomplishing exactly this task. [ http://dotat.at/tmp/metazones.pdf ] Since reading that document, I have been unsuccessful in locating any documentation of this feature on ISC's website. Has this metazone idea gained any traction? Is there a distributable implementation? If not, has another technology emerged which essentially injects restart-persistent zone SOA record information into BIND so that it may then receive AXFR/IXFR for the zone from the master? Any nudge in the right direction would be appreciated. John A. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
