Re: multi-master with mysql backend
On 2/14/11 4:11 AM, Fajar A. Nugraha wrote: On Mon, Feb 14, 2011 at 6:24 AM, Doug Bartondo...@dougbarton.us wrote: On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. All things considered, it might be the best tool for that specific need is not bind at all, but something like mydns. Yes maybe I should look also for a mydns solution. thanks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Mon, Feb 14, 2011 at 01:50:49PM +1100, Mark Andrews ma...@isc.org wrote a message of 40 lines which said: I could reproduce it in 9.7.1-P1 by just adding a DNSKEY record at the apex I cannot reproduce it. Any more detailed instructions? It will be more difficult to convince the people in charge of the operations to upgrade if I cannot exhibit a test case... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
I will consider very much your hints. Thank you for your point of view and I would like to try What you suggested. Riccardo On 14/feb/2011, at 00:24, Doug Barton do...@dougbarton.us wrote: On 2/13/2011 8:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. It isn't a matter of not liking it. Given that you have steadfastly refused to answer any of the questions from people who are trying to help you, my feeling is that you have decided that you want to use mysql no matter what, and you're not really interested in discussing A) What you're actually trying to accomplish, and B) What might be the best tool for doing that job. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. I'm very familiar with providing mission critical DNS. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers If you nsupdate both servers at the same time, you won't. and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. You're talking about rsync as if it's a huge problem, so my guess is that you're familiar with mysql, but not familiar with rsync. This reinforces my belief that you've settled on mysql as the solution no matter what. But let's take an actual look at your scenario for a second. Which do you _think_ would be faster, rsyncing your data (very little of which is likely to have changed during the outage) or the db synchronizing, which requires it to connect to the other master, play all the transaction logs that it missed, and verify that it's once again in a consistent state? Having thought about it, what results do you get after you actually test it? Good luck, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.6.3 crashing on Freebsd 7.3
On 02/11/2011 21:21, Terry. wrote: 2011/2/11 Joshua Frugéjfru...@lsu.edu: running bind 9.6.3 installed from ports on Freebsd 7.3 (amd64) Getting this error in my local log 10-Feb-2011 21:12:13.711 general: rbtdb.c:1506: INSIST(((unsigned int)(((node)-references)-refs)) == 0 node-data == ((void *)0)) failed could you try to compile BIND from the source rather than the ports installation? Regards. I had to revert back to 9.6.2. Going to try to replicate the issue on a test server and get more info. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Spurious TYPE65534 at the end of a NSEC3, why?
On Mon, Feb 14, 2011 at 10:37:57AM +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote a message of 10 lines which said: I cannot reproduce it. Now, it works. Bug report sent to ISC [ISC-Bugs #23232] No, it is not fixed in recent BINDs. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Strange error from nsupdate
We are running BIND 9.7.2-P3, and update our zones with nsupdate calls that look like this: nsupdate -v -k keys/update-key [input] /dev/null 2[errors] This is run from a Solaris 10_x86 non-global zone (container). On a couple of occasions it has generated the error dns_dispatch_getudp (v4): permission denied This seems to strike at random, and goes away on retrying the same nsupdate call. What's really strange here is that nsupdate is being told to use TCP (the -v option), so why is it messing around with UDP? Has anyone else seen this? -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: additional empty zones
On 13.02.11 09:25, Mark Andrews wrote:
zone xxx {
type master;
database _builtin empty nameserver contact;
};
In message 20110213155712.ga1...@fantomas.sk, Matus UHLAR - fantomas writes:
Nice, but is that documented enough so the behaviour won't change or get
removed in later releases?
It's unlikely to change.
let's hope, keeping it with comment undocumented BIND feature into bind
config is nice but shouldn't cause troubles.
... and it would be nice without the nameserver and contact parts, since
they are usually defined by empty-server and empty-contact options
On 14.02.11 09:30, Mark Andrews wrote:
For the zones named creates. Named isn't creating these zones. You are.
I'm asking the named to create them ;-)
--
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.
One OS to rule them all, One OS to find them,
One OS to bring them all and into darkness bind them
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html , which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server makes for a less reliable system than one just using BIND. The performance of a MySQL based BIND server is much less than a standard BIND server. Managing DNS information using dynamic DNS provides a simple solution to updating the zone information. So, what is the actual advantage of using a MySQL backend to BIND? I'm not convinced that there is any advantage and I am sure that there are many downsides to using this. Using MySQL for a backend to BIND is a fairly commonly proposed solution but it's actual implementation is not followed up on. I looked at using MySQL, but the performance limitations were an absolute deal killer. I set up a simple BIND/MySQL system and benchmarked it and duplicated the performance trends from the BIND-DLZ developers. Maybe this has been improved, but these results have not be published so we don't know about it. If you do implement your MySQL solution, please, please, please, keep us informed about how it works for you. We would like to know more and are always willing to look at new technologies but aren't too accepting of hand waving. Bill Larson Riccardo On 2/12/11 11:33 PM, Doug Barton wrote: On 02/11/2011 01:51 PM, fddi wrote: I understand you, but the advantage of having mysql backend is that if one of the two servers dies, the other keeps running with up to date informations, and can also be updated wit new informations. When the other server comes up again it will automatically sync itself using mysql replica mechanism. if I use file
RE: multi-master with mysql backend
I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server makes for a less reliable system than one just using BIND. The performance of a MySQL based BIND server is much less than a standard BIND server. Managing DNS information using dynamic DNS provides a simple solution to updating the zone information. So, what is the actual advantage of using a MySQL backend to BIND? I'm not convinced that there is any advantage and I am sure that there are many downsides to using this. Using MySQL for a backend to BIND is a fairly commonly proposed solution but it's actual implementation is not followed up on. I looked at using MySQL, but the performance limitations were an absolute deal killer. I
IXFR size limit?
Is there, by any chance, a maximum size to the IXFRs BIND will send? I've noticed an upstream server I slave from is being suspiciously consistent in the number of records it sends per IXFR (86,450 plus or minus ~10 records). The upstream server is part of an appliance, but fingerprints as BIND 9.2.3rc1 -- 9.4.0a0. I don't see anything in the ARM for configuring a limit on the number of records per zone transfer, but I'm curious if there's something hard-coded somewhere... ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IXFR size limit?
On 2011/02/14, at 10:47, Matthew Pounsett wrote: Is there, by any chance, a maximum size to the IXFRs BIND will send? I've noticed an upstream server I slave from is being suspiciously consistent in the number of records it sends per IXFR (86,450 plus or minus ~10 records). The upstream server is part of an appliance, but fingerprints as BIND 9.2.3rc1 -- 9.4.0a0. Nevermind.. I spoke too soon. It turns out the appliance in question is not actually doing IXFRs. I should have checked out the zone size in the first place. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is precisely how I'd do it but actually haven't bothered to do the work of setting up config files in advance. I should, because while it is an easy task, if I need to do it, I'm probably not in the mood to figure it out. Having multiple masters sounds interesting, but considering how close the slave configuration is to a master configuration (when you take into account the zone data which is really the important part), it just doesn't seem necessary. On 02/14/2011 10:52 AM, Mike Mitchell wrote: I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell *From:* bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] *Sent:* Monday, February 14, 2011 10:39 AM *To:* fddi *Cc:* bind-users@lists.isc.org *Subject:* Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is something that all DNS server do provide, so your real requirement must be something else, such as being able to update multiple servers at the same time. But Doug Barton has identified that using nsupdate to update both (all) servers also provides a solution to meet this requirement. So, your the mysql solution looks safer to me, may be your viewpoint which is not universally agreed upon. You also have stated just have mysql properly configured. This statement is not unique to MySQL but to BIND also. BIND also needs to be properly configured, no different than with MySQL - nothing unique here. Now, my single belief for any DNS operation is to follow the KISS principle, keep it simple, stupid. A less complex system will be more reliable than a more complex system, because of having less potential points of failure. This reliability is the single most important requirement for a DNS operation. A DNS operation that requires running both BIND and MySQL will be inherently less reliable than one running just BIND. The complexity of a MySQL BIND server
Re: multi-master with mysql backend
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a): I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Nice idea. I'd go even further - why keep two configs? Have a file with your list of zones, and two scripts that generate either master or slave config. Now you are keeping one common config on both severs, which changes only when you add/remove a zone, and two scripts which are almost identical, except for one line (master address). This should be easier to maintain. Now, just in case, you could put on startup scripts the one that generates slave config, so if it reboots you don't have two master servers. And you could cook up a more complicated script, that tries to ping the other server and runs master config generation, freeze, soa change, thaw, reload and send you an email - and you have fully automated HA. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
FWIW, I feel compelled to chime in -- for those who haven't already begun to filter out this thread. We have many thousands of records (internally) in hundreds of zones, mostly dynamic. We have 8 DNS servers providing authoritative and recursive service to thousands of internal clients. All DNS servers are slaves to a single, semi-hidden master. The master's service addresses is statically host routed to the servers currently providing the master DNS service, with the service addresses being assigned to loopback interface on the server. If the active master dies, then I run a simple script on another working DNS server to promote it to master, and I change a static host route in the layer-3 switches to direct zone transfer and DDNS traffic to the new server. I can restore the master DNS functionality on any other DNS server within seconds. The weakness of this system is that I don't trust an automatic failover, so zone transfers and new DDNS requests have to wait until someone on my team is notified of the problem, and they log in, and implement the flip. We do have a mysql-based management system, but only for the non-dynamic zones, and the zone files are pushed out to the active master using scp and rndc. I would never install the database on an actual DNS server -- for many, many reasons. Sorry if I come across as harsh, but the thought of installing a database system on every DNS server that might need to become master seems extremely insane. Ah. There, I feel much better now having said that. -- Gordon A. Lang / 313-819-7978 - Original Message - From: Mike Mitchell To: fddi Cc: bind-users@lists.isc.org Sent: Monday, February 14, 2011 10:52 AM Subject: RE: multi-master with mysql backend I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I would also suggest that a MySQL DNS server may not be the best solution for a critical DNS operation. Please take a look at the benchmark work done comparing BIND using various backend systems, including MySQL. This can be found at http://bind-dlz.sourceforge.net/perf_tests.html, which is part of the work that the people that developed DLZ for BIND. The standard BIND server could provide 16,000 queries per second. The same BIND server using a MySQL backend could handle less than 700 qps. BIND DLZ using MySQL is NOT what I would consider to be a high performance solution for a DNS operation. Now, granted, these results were not using a current version of BIND, nor was this being run on any high power hardware. Performance of BIND DLZ using a MySQL backend may have easily been improved, but so has the performance of the base system too. A 20 to 1 performance advantage for a straight BIND solution will be hard to overcome. So, performance isn't something that a MySQL backend provides to a DNS operation and high availability is
Re: multi-master with mysql backend
In case anyone is actually paying attention, I just re-read my own post, and I'd like to clarify my plural reference to the service addresses... I have one service address for DDNS and separate service address for zone transfers. So, technically we have to change two static host-routes, not just one. But the simplicity is still intact. And also, I'd like to point out that my simple promote script has a sister script called demote, and these scripts bring up or bring down the service addresses on loopbacks as well as restart the named process. And, by the way, we have NEVER needed to change masters since mid-2005 when it was first deployed. I am anxiously waiting for an actual failure to justify all my work.!!! -- Gordon A. Lang - Original Message - From: Gordon A. Lang gl...@goalex.com To: bind-users@lists.isc.org Cc: Mike Mitchell mike.mitch...@sas.com Sent: Monday, February 14, 2011 1:18 PM Subject: Re: multi-master with mysql backend FWIW, I feel compelled to chime in -- for those who haven't already begun to filter out this thread. We have many thousands of records (internally) in hundreds of zones, mostly dynamic. We have 8 DNS servers providing authoritative and recursive service to thousands of internal clients. All DNS servers are slaves to a single, semi-hidden master. The master's service addresses is statically host routed to the servers currently providing the master DNS service, with the service addresses being assigned to loopback interface on the server. If the active master dies, then I run a simple script on another working DNS server to promote it to master, and I change a static host route in the layer-3 switches to direct zone transfer and DDNS traffic to the new server. I can restore the master DNS functionality on any other DNS server within seconds. The weakness of this system is that I don't trust an automatic failover, so zone transfers and new DDNS requests have to wait until someone on my team is notified of the problem, and they log in, and implement the flip. We do have a mysql-based management system, but only for the non-dynamic zones, and the zone files are pushed out to the active master using scp and rndc. I would never install the database on an actual DNS server -- for many, many reasons. Sorry if I come across as harsh, but the thought of installing a database system on every DNS server that might need to become master seems extremely insane. Ah. There, I feel much better now having said that. -- Gordon A. Lang / 313-819-7978 - Original Message - From: Mike Mitchell To: fddi Cc: bind-users@lists.isc.org Sent: Monday, February 14, 2011 10:52 AM Subject: RE: multi-master with mysql backend I'd keep two copies of the BIND config, one that has all the zones as master, and one that has all the zones as slave. When the master dies, run a little script on a slave that freezes the zones, edits the SOA to make that server the MNAME and increment the serial, then thaws the zone. Swap out the config with the master config, and now you have a new master. Before the broken master comes back online, swap out its config with the slave config. No need for rsync or mysql, BIND replication does all the work for you. Just be sure the updates go to the server listed in the MNAME field of the SOA. Mike Mitchell From: bind-users-bounces+mike.mitchell=sas@lists.isc.org [bind-users-bounces+mike.mitchell=sas@lists.isc.org] on behalf of Bill Larson [wllarso@gmail.com] Sent: Monday, February 14, 2011 10:39 AM To: fddi Cc: bind-users@lists.isc.org Subject: Re: multi-master with mysql backend On Feb 13, 2011, at 9:06 AM, fddi wrote: I do not know why you really don't liket this mysql solution. OK I am talking of a DNS for HA purposes for grid computing services for exampe, so DNS resolution must be always working at any cost. The David solution can be OK, but I want to be sure not to have issues with serial numbers on the two servers and the mysql solution looks safer to me. You do not have to rsync anything, just have mysql properly configured. This list is read by many people with extreme experience with DNS and DNS operations. Using the information that you have provided, many solutions have been provided to meet the requirements that you have stated. I would suggest that you at least consider this other solutions and not be as adamant about using your proposed MySQL solution. You state that you have a HA requirement. Please understand that this is not an uncommon requirement for a DNS operation. In fact, almost all DNS operations have this same requirement. Just imagine if the root servers did not have a require for high availability. The same goes for the com, net, org servers (it also). This is not an unusual requirement and a standard BIND DNS server provides this very well. Now, I
Re: help with views design
Rather than dropping all records in the copied zone, just compute a difference
and apply it to both views.
Or perhaps you should examine why you are using views in the first place and
decide if there is a better way to achieve this.
Regards,
Chris Buxton
BlueCat Networks
On Feb 13, 2011, at 7:12 PM, Terry. wrote:
Hello gurus,
Thanks firstly since I have got many helps from the list before.
Now I'm designing a open DNS service, say I have three views as below:
view uni {
match-clients {
key unikey;
UNI;
};
allow-update {key unikey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.uni.db;
};
};
view edu {
match-clients {
key edukey;
EDU;
};
allow-update {key edukey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.edu.db;
};
};
view any {
match-clients {
key defaultkey;
any;
};
allow-update {key defaultkey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.any.db;
};
};
Some customer's domain names have all three views, so I define the
zones in each view, they work fine.
But some customers have only two views, say it's view uni and view any.
Thus I setup zones in view uni and view any, but view edu will be lost.
If the clients from edu network query for the zones, they will get
NXDOMAIN result.
For my DNS service, the customers submit their records from web
interface, the records are inserted into database.
Then a daemon will load the new updated records from database and call
nsupdate to update them to BIND.
I know I can use complicated SQL to resolve it, for example, if the
customer doesn't have edu view, I could copy all the records from any
view to edu view in database with SQL statement. If the customer later
add a record to edu view, before insert it to database, I have to drop
all the before records copied from any view, etc.
But rather than using SQL doing it, is there a good BIND way handling this
case?
Thanks in advance.
Regards.
--
Free SmartDNS Hosting:
http://DNSbed.com/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange error from nsupdate
On Feb 14, 2011, at 6:31 AM, Chris Thompson wrote: We are running BIND 9.7.2-P3, and update our zones with nsupdate calls that look like this: nsupdate -v -k keys/update-key [input] /dev/null 2[errors] This is run from a Solaris 10_x86 non-global zone (container). On a couple of occasions it has generated the error dns_dispatch_getudp (v4): permission denied This seems to strike at random, and goes away on retrying the same nsupdate call. What's really strange here is that nsupdate is being told to use TCP (the -v option), so why is it messing around with UDP? Has anyone else seen this? I haven't seen it specifically, but: - nsupdate might be sending a query (over UDP) to fill in missing info, such as the zone or server to update. - Your Solaris container might be the problem. I've heard of problems running named in a container, typically performance problems but this type of behavior might explain a performance issue. Regards, Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: multi-master with mysql backend
On Feb 14, 2011, at 12:54 PM, Torinthiel wrote:
Dnia 2011-02-14 15:52 Mike Mitchell napisał(a):
I'd keep two copies of the BIND config, one that has all the zones as
master, and one that has all the zones as slave. When the
master dies,
run a little script on a slave that freezes the zones, edits the SOA
to make
that server the MNAME and increment the serial, then thaws the zone.
Swap
out the config with the master config, and now you have a new
master.
Before the broken master comes back online, swap out its config
with the
slave config.
No need for rsync or mysql, BIND replication does all the work for
you.
Just be sure the updates go to the server listed in the MNAME field
of the
SOA.
Nice idea. I'd go even further - why keep two configs? Have a file
with your
list of zones, and two scripts that generate either master or slave
config.
I'm probably going to regret this, but I'm basically doing what you
suggest for some (~15-20) personal domains. Every now and then someone
asks me to run a mailing list for them, please just host a website,
etc. I got tired of updating named.conf on a bunch of servers, cp ~/
configs/base_bind.db /etc/namedb/example.com, add stuff to apache, go
poke postfix on N mailhosts, kick mailman, etc so I finally invested
the time and effort into setting up puppet -- it was *well* worth it...
Now I have a Python dictionary that looks like:
{
ac4wk.com:{bind: local, postfix_virtual: True,
base_web: True, redirect: False },
af7.org: {bind: local, postfix_virtual: True,
base_web: True, redirect: False },
.
}
and a little script that creates a set of Puppet arrays. Puppet then
reads these and does magic.
bind:local specifies to use a template that lists my machines as
MX and www and similar
postfix_virtual add the domain to the virtual lines in postfix to the
mailservers know to accept mail for it
base_web creates directories, add the site to the apache config and
copies some base html files.
redirect: Can be set to a different domains and will then setup a
domain to serve a 302 redirect to some other domain..
My master has
# And setup bind.
$bind_type = master
include bind
and slaves have:
# And setup bind.
$bind_type = slave
$bindmaster = 198.186.192.250
include bind
bind::db_files {[22.194.204.in-addr.arpa, 58.177.216.in-
addr.arpa]:}
in the node manifest.
named.conf is automatically generated from a template, containing some
base config and:
// Section managed by Puppet.
% if bind_type == master then %
% zones.each do |zone| -%
// %= zone % -- Zone stanza generated by puppet.
zone %= zone % {
type master;
file /etc/namedb/%= zone %;
auto-dnssec maintain;
update-policy {
grant local-ddns subdomain * ANY;
grant tsig_1.kumari.net. zonesub ANY;
};
allow-transfer { xfer; };
};
% end -%
% else %
% zones.each do |zone| -%
// %= zone % -- Zone stanza generated by puppet.
zone %= zone % {
type slave;
file /etc/namedb/slave/%= zone %;
allow-transfer { xfer; };
masters { %= bindmaster %; };
};
% end -%
% end %
This means that adding a new domain now just involves adding a line to
the python dictionary and running a script to convert the python to
the puppet arrays -- takes all of 20 seconds.
Making a slave become a master (which I've done a few times as a test)
involves simply changing the line in the manifest.
I realize that this is getting off topic, but puppet has made my life
way easier (this part was a insignificant part of it) and I wanted to
share :-P
W
Now you are keeping one common config on both severs, which changes
only
when you add/remove a zone, and two scripts which are almost
identical,
except for one line (master address). This should be easier to
maintain.
Now, just in case, you could put on startup scripts the one that
generates
slave config, so if it reboots you don't have two master servers.
And you could cook up a more complicated script, that tries to ping
the
other server and runs master config generation, freeze, soa change,
thaw,
reload and send you an email - and you have fully automated HA.
Torinthiel
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Some people are like Slinkies..Not really good for anything but
they still bring a smile to your face when you push them down the
stairs.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Strange error from nsupdate
On Feb 14 2011, Chris Buxton wrote: On Feb 14, 2011, at 6:31 AM, Chris Thompson wrote: We are running BIND 9.7.2-P3, and update our zones with nsupdate calls that look like this: nsupdate -v -k keys/update-key [input] /dev/null 2[errors] This is run from a Solaris 10_x86 non-global zone (container). On a couple of occasions it has generated the error dns_dispatch_getudp (v4): permission denied This seems to strike at random, and goes away on retrying the same nsupdate call. What's really strange here is that nsupdate is being told to use TCP (the -v option), so why is it messing around with UDP? Has anyone else seen this? I haven't seen it specifically, but: - nsupdate might be sending a query (over UDP) to fill in missing info, such as the zone or server to update. The zone is given explicitly, the server by absolute name. It might be looking up the IP address of the server, I suppose. - Your Solaris container might be the problem. I've heard of problems running named in a container, typically performance problems but this type of behavior might explain a performance issue. The container doing the nsupdate isn't actually the one running the nameserver, although that is in fact also also in a container. We haven't had performance problems with the nameservers doing this (although they are not very heavily loaded). I should emphasize that this is a low-frequency effect - I estimate something like 0.2%. It would be easier to track down if it were more frequent! -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
process of updating slave servers
Greetings I have a new slave server. I edited my master, incremented the serial number and reloaded named. The master is fine, and contains the new entry but the slaves are still running the previous entries. what is the basic operation of updating a slave ? I reloaded the zone with rndc and the slave pulled the zone. The serial number was incremented on the slave, but the old entry's were still there. I checked the forward and reverse records, and nothing had changed except the serial number. So I deleted the slave files, and pulled the zone again, and kick started named, everything works fine. I highly doubt my procedure was the correct way to do it. can someone explain to me the proper work flow for updating records on slaves ? TIA -j ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.7.3 is now available.
Introduction
BIND 9.7.3 is the current release of BIND 9.7.
This document summarizes changes from BIND 9.7.1 to BIND 9.7.3. Please
see the CHANGES file in the source code release for a complete list of
all changes.
Download
The latest development version of BIND 9 software can always be found
on our web site at http://www.isc.org/downloads/development. There you
will find additional information about each release, source code, and
some pre-compiled versions for certain operating systems.
Support
Product support information is available on
http://www.isc.org/services/support for paid support options. Free
support is provided by our user community via a mailing list.
Information on all public email lists is available at
https://lists.isc.org/mailman/listinfo.
New Features
9.7.2
* Zones may be dynamically added and removed with the rndc addzone
and rndc delzone commands. These dynamically added zones are
written to a per-view configuration file. Do not rely on the
configuration file name nor contents as this will change in a
future release. This is an experimental feature at this time.
* Added new filter--on-v4 access control list to select which
IPv4 clients have record filtering applied.
* A new command rndc secroots was added to dump a combined summary
of the currently managed keys combined with statically configured
trust anchors.
* Added support to load new keys into managed zones without signing
immediately with rndc loadkeys. Added support to link keys with
dnssec-keygen -S and dnssec-settime -S.
Feature Changes
9.7.2
* Documentation improvements
* ORCHID prefixes were removed from the automatic empty zone list.
* Improved handling of GSSAPI security contexts. Specifically, better
memory management of cached contexts, limited lifetime of a context
to 1 hour, and added a realm command to nsupdate to allow
selection of a non-default realm name.
* The contributed tool zkt was updated to version 1.0.
Security Fixes
9.7.2-P3
* Adding a NO DATA signed negative response to cache failed to clear
any matching RRSIG records already in cache. A subsequent lookup of
the cached NO DATA entry could crash named (INSIST) when the
unexpected RRSIG was also returned with the NO DATA cache entry.
[RT #22288] [CVE-2010-3613] [VU#706148]
* BIND, acting as a DNSSEC validator, was determining if the NS RRset
is insecure based on a value that could mean either that the RRset
is actually insecure or that there wasn't a matching key for the
RRSIG in the DNSKEY RRset when resuming from validating the DNSKEY
RRset. This can happen when in the middle of a DNSKEY algorithm
rollover, when two different algorithms were used to sign a zone
but only the new set of keys are in the zone DNSKEY RRset. [RT
#22309] [CVE-2010-3614] [VU#837744]
* When BIND is running as an authoritative server for a zone and
receives a query for that zone data, it first checks for
allow-query acls in the zone statement, then in that view, then in
global options. If none of these exist, it defaults to allowing any
query (allow-query {any};).
With this bug, if the allow-query is not set in the zone statement,
it failed to check in view or global options and fell back to the
default of allowing any query. This means that queries that the
zone owner did not wish to allow were incorrectly allowed. [RT
#22418] [CVE-2010-3615] [VU#510208]
9.7.2-P2
* A flaw where the wrong ACL was applied was fixed. This flaw allowed
access to a cache via recursion even though the ACL disallowed it.
9.7.2-P1
* If BIND, acting as a DNSSEC validating server, has two or more
trust anchors configured in named.conf for the same zone (such as
example.com) and the response for a record in that zone from the
authoritative server includes a bad signature, the validating
server will crash while trying to validate that query.
Bug Fixes
9.7.3
* BIND now builds with threads disabled in versions of NetBSD earlier
than 5.0 and with pthreads enabled by default in NetBSD versions
5.0 and higher. Also removes support for unproven-pthreads,
mit-pthreads and ptl2. [RT #19203]
* Added a regression test for fix 2896/RT #21045 (rndc sign failed
to properly update the zone when adding a DNSKEY for publication
only). [RT #21324]
* nsupdate -l now gives error message if session.key file is not
found. [RT #21670]
* HPUX now correctly defaults to using /dev/poll, which should
increase performance. [RT #21919]
* If named is running as a threaded application, after an rndc stop
command has been issued, other inbound TCP requests can cause named
Re: process of updating slave servers
check your configure especially for: * notify/ also-notify/ allow-notify * allow-transfer * does slave named have the permittion to write to data dir? Regards. 2011/2/15 donovan jeffrey j dono...@beth.k12.pa.us: Greetings I have a new slave server. I edited my master, incremented the serial number and reloaded named. The master is fine, and contains the new entry but the slaves are still running the previous entries. what is the basic operation of updating a slave ? I reloaded the zone with rndc and the slave pulled the zone. The serial number was incremented on the slave, but the old entry's were still there. I checked the forward and reverse records, and nothing had changed except the serial number. So I deleted the slave files, and pulled the zone again, and kick started named, everything works fine. I highly doubt my procedure was the correct way to do it. can someone explain to me the proper work flow for updating records on slaves ? TIA -j ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Free SmartDNS Hosting: http://DNSbed.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.8.0rc1 is now available.
Introduction BIND 9.8.0rc1 is the first release candidate of BIND 9.8. This document summarizes changes from BIND 9.7 to BIND 9.8. Please see the CHANGES file in the source code release for a complete list of all changes. Download The latest development versions of BIND 9 software can always be found on our web site at http://www.isc.org/downloads/development. There you will find additional information about each release, source code, and some pre-compiled versions for certain operating systems. Support Product support information is available on http://www.isc.org/services/support for paid support options. Free support is provided by our user community via a mailing list. Information on all public email lists is available at https://lists.isc.org/mailman/listinfo. New Features 9.8.0 * The ADB hash table stores informations about which authoritative servers to query about particular domains. Previous versions of BIND had the hash table size as a fixed value. On a busy recursive server, this could lead to hash table collisions in the ADB cache, resulting in degraded response time to queries. Bind 9.8 now has a dynamically scalable ADB hash table, which helps a busy server to avoid hash table collisions and maintain a consistent query response time. [RT #21186] * BIND now supports a new zone type, static-stub. This allows the administrator of a recursive nameserver to force queries for a particular zone to go to IP addresses of the administrator's choosing, on a per zone basis, both globally or per view. I.e. if the administrator wishes to have their recursive server query 192.0.2.1 and 192.0.2.2 for zone example.com rather than the servers listed by the .com gTLDs, they would configure example.com as a static-stub zone in their recursive server. [RT #21474] * BIND now supports Response Policy Zones, a way of expressing reputation in real time via specially constructed DNS zones. See the draft specification here: http://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt [RT #21726] * BIND 9.8.0 now has DNS64 support. named synthesizes records from specified A records if no record exists. IP6.ARPA CNAME records will be synthesized from corresponding IN-ADDR.ARPA. [RT #21991/22769] * Dynamically Loadable Zones (DLZ) now support dynamic updates. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] * Added a dlopen DLZ driver, allowing the creation of external DLZ drivers that can be loaded as shared objects at runtime rather than having to be linked with named at compile time. Currently this is switched on via a compile-time option, configure --with-dlz-dlopen. Note: the syntax for configuring DLZ zones is likely to be refined in future releases. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] * named now retains GSS-TSIG keys across restarts. This is for compatibility with Microsoft DHCP servers doing dynamic DNS updates for clients, which don't know to renegotiate the GSS-TSIG session key when named restarts. [RT #22639] * There is a new update-policy match type external. This allows named to decide whether to allow a dynamic update by checking with an external daemon. Contributed by Andrew Tridgell of the Samba Project. [RT #22758] * There have been a number of bug fixes and ease of use enhancements for configuring BIND to support GSS-TSIG [RT #22629/22795]. These include: + Added a tkey-gssapi-keytab option. If set, dynamic updates will be allowed for any key matching a Kerberos principal in the specified keytab file. tkey-gssapi-credential is no longer required and is expected to be deprecated. Contributed by Andrew Tridgell of the Samba Project. [RT #22629] + It is no longer necessary to have a valid /etc/krb5.conf file. Using the syntax DNS/hostname@REALM in nsupdate is sufficient for to correctly set the default realm. [RT #22795] + Documentation updated new gssapi configuration options (new option tkey-gssapi-keytab and changes in tkey-gssapi-credential and tkey-domain behavior). [RT 22795] + DLZ correctly deals with NULL zone in a query. [RT 22795] + TSIG correctly deals with a NULL tkey-creator. [RT 22795] Feature Changes 9.8.0 * There is a new option in dig, +onesoa, that allows the final SOA record in an AXFR response to be suppressed. [RT #20929 * There is additional information displayed in the recursing log (qtype, qclass, qid and whether we are following the original name). [RT #22043] * Added option 'resolver-query-timeout' in named.conf (max query
Re: BIND 9.7.3 is now available.
2011/2/15 Mark Andrews ma...@isc.org: 9.7.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] Looks a great release. BTW, does bind-9.7's threads work well on Linux X86 platform? Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: help with views design
Remember that each view is a separate server, that has a limited access
(by the match-clients statement), these clients will see this server and
NOT the other two servers. Likewise a client in the edu view match list
will not see any of the other views (servers).
This is not one server, where the clients go through the views one at a
time. ANY client has access to ONE server(view) and only one, the others
do not exist for them to see.
There can be some recursion reaching the other servers in some cases -
for understanding this setup, consider them totally separate.
On 14/02/11 20:11, Chris Buxton wrote:
Rather than dropping all records in the copied zone, just compute a
difference and apply it to both views.
Or perhaps you should examine why you are using views in the first place and
decide if there is a better way to achieve this.
Regards,
Chris Buxton
BlueCat Networks
On Feb 13, 2011, at 7:12 PM, Terry. wrote:
Hello gurus,
Thanks firstly since I have got many helps from the list before.
Now I'm designing a open DNS service, say I have three views as below:
view uni {
match-clients {
key unikey;
UNI;
};
allow-update {key unikey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.uni.db;
};
};
view edu {
match-clients {
key edukey;
EDU;
};
allow-update {key edukey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.edu.db;
};
};
view any {
match-clients {
key defaultkey;
any;
};
allow-update {key defaultkey;};
zone test.nsbeta.info {
type master;
file test.nsbeta.info.any.db;
};
};
Some customer's domain names have all three views, so I define the
zones in each view, they work fine.
But some customers have only two views, say it's view uni and view any.
Thus I setup zones in view uni and view any, but view edu will be lost.
If the clients from edu network query for the zones, they will get
NXDOMAIN result.
For my DNS service, the customers submit their records from web
interface, the records are inserted into database.
Then a daemon will load the new updated records from database and call
nsupdate to update them to BIND.
I know I can use complicated SQL to resolve it, for example, if the
customer doesn't have edu view, I could copy all the records from any
view to edu view in database with SQL statement. If the customer later
add a record to edu view, before insert it to database, I have to drop
all the before records copied from any view, etc.
But rather than using SQL doing it, is there a good BIND way handling this
case?
Thanks in advance.
Regards.
--
Free SmartDNS Hosting:
http://DNSbed.com/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Best regards
Sten Carlsen
No improvements come from shouting:
MALE BOVINE MANURE!!!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: process of updating slave servers
On Feb 14, 2011, at 8:31 PM, Terry. wrote:
check your configure especially for:
* notify/ also-notify/ allow-notify
* allow-transfer
* does slave named have the permittion to write to data dir?
yes , salve can write.
slave options;
allow-transfer { 10.1.1.2; };
allow-notify {10.1.1.2};
transfer-format many-answers;
master options;
allow-transfer { 10.135.1.3; };
is that correct ?
-j
Regards.
2011/2/15 donovan jeffrey j dono...@beth.k12.pa.us:
Greetings
I have a new slave server. I edited my master, incremented the serial number
and reloaded named. The master is fine, and contains the new entry but the
slaves are still running the previous entries.
what is the basic operation of updating a slave ?
I reloaded the zone with rndc and the slave pulled the zone. The serial
number was incremented on the slave, but the old entry's were still there.
I checked the forward and reverse records, and nothing had changed except
the serial number. So I deleted the slave files, and pulled the zone again,
and kick started named, everything works fine.
I highly doubt my procedure was the correct way to do it.
can someone explain to me the proper work flow for updating records on
slaves ?
TIA
-j
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Free SmartDNS Hosting:
http://DNSbed.com/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: process of updating slave servers
2011/2/15 donovan jeffrey j dono...@beth.k12.pa.us:
On Feb 14, 2011, at 8:31 PM, Terry. wrote:
check your configure especially for:
* notify/ also-notify/ allow-notify
* allow-transfer
* does slave named have the permittion to write to data dir?
yes , salve can write.
slave options;
allow-transfer { 10.1.1.2; };
In practical the slave doesn't have the allow-transfer option.
allow-notify {10.1.1.2};
If the slave is listed in the NS records of the zone distinctly (ie,
it's not a hidden slave) then this allow-notify is also not needed.
transfer-format many-answers;
master options;
allow-transfer { 10.135.1.3; };
If the slave is a hidden name server, then in master both
allow-transfer and also-notify are needed, otherwise neither of them
is needed.
Regards.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7.3 is now available.
2011/2/15 Mark Andrews ma...@isc.org: 9.7.3 * BIND now builds with threads disabled in versions of NetBSD earlier than 5.0 and with pthreads enabled by default in NetBSD versions 5.0 and higher. Also removes support for unproven-pthreads, mit-pthreads and ptl2. [RT #19203] Looks a great release. BTW, does bind-9.7's threads work well on Linux X86 platform? I would think a posix speec compliant implementation would work anywhere. However, who knows, I'll give a quick build on Debian squeeze and see what happens. Personally I'm not sure if there is a comprehensive test suite in the iscbind packages. Is there ? How would one verify the functionality of the new security features? -- Dennis Clarke dcla...@opensolaris.ca - Email related to the open source Solaris dcla...@blastwave.org - Email related to open source for Solaris ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: process of updating slave servers
In article mailman.123.1297730089.10842.bind-us...@lists.isc.org, donovan jeffrey j dono...@beth.k12.pa.us wrote: Greetings I have a new slave server. I edited my master, incremented the serial number and reloaded named. The master is fine, and contains the new entry but the slaves are still running the previous entries. what is the basic operation of updating a slave ? I reloaded the zone with rndc and the slave pulled the zone. The serial number was incremented on the slave, but the old entry's were still there. I checked the forward and reverse records, and nothing had changed except the serial number. So I deleted the slave files, and pulled the zone again, and kick started named, everything works fine. I highly doubt my procedure was the correct way to do it. can someone explain to me the proper work flow for updating records on slaves ? Upon receipt of a NOTIFY message from the master, or when the Refresh period specified in the SOA record expires, the slave queries the SOA record from the master. If the master's serial number is higher than the one the slave already has, it performs a zone transfer. Once the zone transfer completes, it loads the new version of the zone. I can't think of any way that it could be getting just the incremented serial number, but not the rest of the changes to the zone. I think all the other respondents missed this detail from your post. Are there any errors in the slave's log when this happens? -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
