From: <da...@so...> - 2007-04-27 19:05:29
|
Howdy all, After all my efforts this week I see I still have the same problem with empty slave records. I'd thought it might be a conflict between Slackware and CentOS but I guess not. I wish I could say it's consistent across the board, but that would be too easy. The name gets entered into named.conf but the record doesn't get transferred. I have BIND CHROOTED (but it's the same either way). When I check on the slave bob.com I get: View Records File /var/named/slaves/bob.com.hosts This page shows the DNS records file /var/named/slaves/bob.com.hosts, created by BIND when the zone was transferred from the master server. However the file is currently empty, probably because the zone has not yet been transferred from the master server. ************************************************* The problem is that bob.com.hosts doesn't exit. THere are a number of empty temp files in the /slaves dir . This is the log for bob.com ns2 named[2756]: received notify for zone 'bob.com': not authoritative Apr 27 13:21:16 ns2 named[2756]: loading configuration from '/etc/named.conf' Apr 27 13:21:16 ns2 named[2756]: zone bob.com/IN: has 0 SOA records Apr 27 13:21:16 ns2 named[2756]: zone bob.com/IN: has no NS records Apr 27 13:21:16 ns2 named[2756]: zone bob.com/IN: saved '/var/named/slaves/bob.com.hosts' as '/var/named/slaves/db-XXZkfXRC' Apr 27 13:21:16 ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 Apr 27 13:21:16 ns2 named[2756]: zone solvnet.net/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 Apr 27 13:22:03 ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 Apr 27 13:23:43 ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 I'm at a loss, I used to cover my tracks taking the tempfile and renaming it but this should be straight forward with identical boxes and OS. any thoughts, thanks, Dan |
From: Kris D. <kd...@vi...> - 2007-04-27 19:28:54
|
da...@so... wrote: > This is the log for bob.com (looks like it got a bit mangled in transit; cleaning it up a little and stripping dates to reduce linewrap) > ns2 named[2756]: received notify for zone 'bob.com': not authoritative > ns2 named[2756]: loading configuration from '/etc/named.conf' > ns2 named[2756]: zone bob.com/IN: has 0 SOA records > ns2 named[2756]: zone bob.com/IN: has no NS records > ns2 named[2756]: zone bob.com/IN: saved '/var/named/slaves/bob.com.hosts' as '/var/named/slaves/db-XXZkfXRC' > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone solvnet.net/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 Okay, this adds some more questions: Is this from the master's log, or the slave? Why is it referencing "master 127.0.0.1#53"? Do you have 127.0.0.1 as an NS in the zone file? What's in the named.conf on the master, and on the slave? What are the NS records in the zone file on the master? After a bit of thought, this *looks* like you've told the slave to talk to itself to get the zone data. -kgd |
From: <da...@so...> - 2007-04-27 21:14:03
|
Hi, THis is on VMPro. In essence NS! and NS@ have each other as cluster slave servers. So bob.com was created on NS1 with complete records and NS2 (slave) added the zone but didn't transact the records for the zone. I thought putting the zone in the slave cluster took care of that?? Date sent: Fri, 27 Apr 2007 15:28:50 -0400 From: Kris Deugau <kd...@vi...> Organization: ViaNet Internet Solutions To: Webmin users list <web...@li...> Subject: Re: [webmin-l] BIND slave issue Send reply to: Webmin users list <web...@li...> <mailto:web...@li...?subject=unsubscribe> <mailto:web...@li...?subject=subscribe> [ Double-click this line for list subscription options ] da...@so... wrote: > This is the log for bob.com (looks like it got a bit mangled in transit; cleaning it up a little and stripping dates to reduce linewrap) > ns2 named[2756]: received notify for zone 'bob.com': not authoritative > ns2 named[2756]: loading configuration from '/etc/named.conf' > ns2 named[2756]: zone bob.com/IN: has 0 SOA records > ns2 named[2756]: zone bob.com/IN: has no NS records > ns2 named[2756]: zone bob.com/IN: saved '/var/named/slaves/bob.com.hosts' as '/var/named/slaves/db- XXZkfXRC' > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone solvnet.net/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 > ns2 named[2756]: zone bob.com/IN: refresh: unexpected rcode (SERVFAIL) from master 127.0.0.1#53 Okay, this adds some more questions: Is this from the master's log, or the slave? Why is it referencing "master 127.0.0.1#53"? Do you have 127.0.0.1 as an NS in the zone file? What's in the named.conf on the master, and on the slave? What are the NS records in the zone file on the master? After a bit of thought, this *looks* like you've told the slave to talk to itself to get the zone data. -kgd ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - Forwarded by the Webmin mailing list at webadmin- li...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list ****************************************************************************** *** Domains by SolvNet http://solvnetdomains.com Be a domain reseller and make cash http://domainmiddleman.com Domain name registration and hosting solutions. http://solvnethosting.com |
From: Kris D. <kd...@vi...> - 2007-04-27 21:50:08
|
(Please keep replies on-list; no need to CC me.) da...@so... wrote: > THis is on VMPro. In essence NS! and NS@ have each other as > cluster slave servers. So bob.com was created on NS1 with > complete records and NS2 (slave) added the zone but didn't > transact the records for the zone. I thought putting the zone in the > slave cluster took care of that?? I'm not sure what you mean by "cluster slave servers"; with BIND, a machine is either a (usually THE) master, or a slave for any given zone. If a server is set as a slave, and the master allows zone transfers to that slave, it works fine IME - that's why I asked about what's in your named.conf on the master and slave machines, and what the NS records are in the master zone file. The log messages you reported indicate that something isn't set up correctly for the slave to be able to transfer the zone. There are extra directives you can use in the master and slave servers' named.conf to allow servers outside those listed as authoritative NS machines to do zone transfers, but I can't really think of many cases where that would be useful for Internet-facing zones. To rephrase what I was trying to point out with my previous message, your slave server appears to be confused about where to find the master zone, and the master may or may not even be configured correctly to allow slaves to request a zone transfer. Without looking at the named.conf files and the master zone's NS records, I can't say for certain what's wrong. -kgd |
From: <da...@so...> - 2007-04-28 15:27:18
|
Hi Kris, You're right. The primary and secondary namservers are accepting the slave zones but addressing them as local in named.conf. I don't understand why as I have bind set up with default settings on all the boxes, specifically, "Default master server IP for remote slave zones " is set to "ip address of hostname". Maybe Jamie has an idea. Dan From: da...@so... To: Kris Deugau <kd...@vi...>, Webmin users list <web...@li...> Date sent: Fri, 27 Apr 2007 17:51:47 -0500 Priority: normal Subject: Re: [webmin-l] BIND slave issue Send reply to: Webmin users list <web...@li...> <mailto:web...@li...?subject=unsubscribe> <mailto:web...@li...?subject=subscribe> [ Double-click this line for list subscription options ] Sorry Kris, I'm just using the out of box BIND module in a VirtualminPro setup. In Webmin you can register other servers as webmin servers and then assign them as "cluster slave servers" in the BIND module. Essentially, I'm trying to see if there's a bug or I what I need to adjust to fix these RPC errors that I've been getting. So NS1 and NS2 have each other then as slave servers. For some reason NS2 will receive the new domain during account creation but then gets an RPC invalid login error during the second access to NS2. Date sent: Fri, 27 Apr 2007 17:50:01 -0400 From: Kris Deugau <kd...@vi...> Organization: ViaNet Internet Solutions To: Webmin users list <web...@li...> Subject: Re: [webmin-l] BIND slave issue Send reply to: Webmin users list <web...@li...> <mailto:web...@li...?subject=unsubscribe> <mailto:web...@li...?subject=subscribe> [ Double-click this line for list subscription options ] (Please keep replies on-list; no need to CC me.) da...@so... wrote: > THis is on VMPro. In essence NS! and NS@ have each other as > cluster slave servers. So bob.com was created on NS1 with > complete records and NS2 (slave) added the zone but didn't > transact the records for the zone. I thought putting the zone in the > slave cluster took care of that?? I'm not sure what you mean by "cluster slave servers"; with BIND, a machine is either a (usually THE) master, or a slave for any given zone. If a server is set as a slave, and the master allows zone transfers to that slave, it works fine IME - that's why I asked about what's in your named.conf on the master and slave machines, and what the NS records are in the master zone file. The log messages you reported indicate that something isn't set up correctly for the slave to be able to transfer the zone. There are extra directives you can use in the master and slave servers' named.conf to allow servers outside those listed as authoritative NS machines to do zone transfers, but I can't really think of many cases where that would be useful for Internet-facing zones. To rephrase what I was trying to point out with my previous message, your slave server appears to be confused about where to find the master zone, and the master may or may not even be configured correctly to allow slaves to request a zone transfer. Without looking at the named.conf files and the master zone's NS records, I can't say for certain what's wrong. -kgd ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - Forwarded by the Webmin mailing list at webadmin- li...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list ****************************************************************************** *** Domains by SolvNet http://solvnetdomains.com Be a domain reseller and make cash http://domainmiddleman.com Domain name registration and hosting solutions. http://solvnethosting.com ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - Forwarded by the Webmin mailing list at web...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list ********************************************************************************* Domains by SolvNet http://solvnetdomains.com Be a domain reseller and make cash http://domainmiddleman.com Domain name registration and hosting solutions. http://solvnethosting.com |
From: Kris D. <kd...@vi...> - 2007-04-30 14:53:02
|
da...@so... wrote: > You're right. The primary and secondary namservers are accepting the > slave zones but addressing them as local in named.conf. I don't > understand why as I have bind set up with default settings on all the > boxes, specifically, "Default master server IP for remote slave zones " > is set to "ip address of hostname". I can't quite put my finger on it, but that just sounds wrong, and may be why you're having trouble. Any reason you didn't just enter the IP? > Maybe Jamie has an idea. If it's just something odd in the way Webmin is setting up zones on the master and slave servers, hopefully. <g> I'm just trying to set up a test to see if I can reproduce the problem once I've wrestled one of my Debian test boxes into installing BIND. -kgd |
From: Kris D. <kd...@vi...> - 2007-04-30 16:36:06
|
Kris Deugau wrote: > I'm just trying to set up a test to see if I can reproduce the problem > once I've wrestled one of my Debian test boxes into installing BIND. Aside from the minor headaches I always seem to have with Debian, this worked fine - master on CentOS4, one slave on Debian 4.0 (etch), another on Debian 3.1 (sarge). I created a test zone and it transferred correctly. I'm not sure where else to try to get you to look - your BIND install *is* misconfigured somewhere, but if you haven't made manual changes outside of Webmin it's hard to say what might be wrong. -kgd |
From: <da...@so...> - 2007-04-27 22:51:00
|
Sorry Kris, I'm just using the out of box BIND module in a VirtualminPro setup. In Webmin you can register other servers as webmin servers and then assign them as "cluster slave servers" in the BIND module. Essentially, I'm trying to see if there's a bug or I what I need to adjust to fix these RPC errors that I've been getting. So NS1 and NS2 have each other then as slave servers. For some reason NS2 will receive the new domain during account creation but then gets an RPC invalid login error during the second access to NS2. Date sent: Fri, 27 Apr 2007 17:50:01 -0400 From: Kris Deugau <kd...@vi...> Organization: ViaNet Internet Solutions To: Webmin users list <web...@li...> Subject: Re: [webmin-l] BIND slave issue Send reply to: Webmin users list <web...@li...> <mailto:web...@li...?subject=unsubscribe> <mailto:web...@li...?subject=subscribe> [ Double-click this line for list subscription options ] (Please keep replies on-list; no need to CC me.) da...@so... wrote: > THis is on VMPro. In essence NS! and NS@ have each other as > cluster slave servers. So bob.com was created on NS1 with > complete records and NS2 (slave) added the zone but didn't > transact the records for the zone. I thought putting the zone in the > slave cluster took care of that?? I'm not sure what you mean by "cluster slave servers"; with BIND, a machine is either a (usually THE) master, or a slave for any given zone. If a server is set as a slave, and the master allows zone transfers to that slave, it works fine IME - that's why I asked about what's in your named.conf on the master and slave machines, and what the NS records are in the master zone file. The log messages you reported indicate that something isn't set up correctly for the slave to be able to transfer the zone. There are extra directives you can use in the master and slave servers' named.conf to allow servers outside those listed as authoritative NS machines to do zone transfers, but I can't really think of many cases where that would be useful for Internet-facing zones. To rephrase what I was trying to point out with my previous message, your slave server appears to be confused about where to find the master zone, and the master may or may not even be configured correctly to allow slaves to request a zone transfer. Without looking at the named.conf files and the master zone's NS records, I can't say for certain what's wrong. -kgd ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - Forwarded by the Webmin mailing list at webadmin- li...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list ****************************************************************************** *** Domains by SolvNet http://solvnetdomains.com Be a domain reseller and make cash http://domainmiddleman.com Domain name registration and hosting solutions. http://solvnethosting.com |
From: Kris D. <kd...@vi...> - 2007-04-30 14:53:04
|
da...@so... wrote: > Sorry Kris, > I'm just using the out of box BIND module in a VirtualminPro setup. > In Webmin you can register other servers as webmin servers and > then assign them as "cluster slave servers" in the BIND module. > > Essentially, I'm trying to see if there's a bug or I what I need to > adjust to fix these RPC errors that I've been getting. So NS1 and > NS2 have each other then as slave servers. For some reason NS2 > will receive the new domain during account creation but then gets > an RPC invalid login error during the second access to NS2. Hmm. This sounds like a Webmin RPC error rather than a BIND AXFR-related error; as I noted before, a BIND server is either a master or a slave for any given zone - it can't be both, and the errors you showed from BIND indicate to me that one machine *is* trying to be both master and slave for a zone. Without seeing the named.conf and zone files, I can't tell you anything more useful about what BIND is doing. You *can* have a pair of servers with one machine acting as master for some zones, and the other acting as master for the rest, but that's not very common and you need a tool like Webmin to keep track of what's where. <g> -kgd |
From: <da...@so...> - 2007-04-30 16:17:00
|
Hi Kris, Actually I fixed the RPC errors after reading Jamie's RPC tutorial and gave firewall access to the range of base port plus 100. THe BIND mod is supposed to glean the master address from the master server hostname within the BIND mod. But, I even tried hand entering the address (both physical and hostname) into each server to no avail.. I still get the following: zone "dan.net" { type slave; masters { 127.0.0.1; }; file "/var/named/slaves/dan.net.hosts"; }; zone "dan.com" { type slave; masters { 127.0.0.1; }; file "/var/named/slaves/dan.com.hosts"; }; zone "dan.info" { type slave; masters { 127.0.0.1; }; file "/var/named/slaves/dan.info.hosts"; }; So yes, it is calling the master local. named.conf also has this: // // a caching only nameserver config // controls { inet 127.0.0.1 allow { localhost; } keys { rndckey; rndc-key; }; }; The only place to mess with that is in the control interface options module. I tried adding allowed IP addresses there, to no avail. I would have assumed assigning a cluster slave server would have modified that line in named.conf. if needed. I can hand enter the slave master address but that defeats the purpose of having the BIND mods linked. I have to fix this by hand to get current clients back up but I need it fixed before I can put the billing client back online with account creation. Date sent: Mon, 30 Apr 2007 10:53:02 -0400 From: Kris Deugau <kd...@vi...> Organization: ViaNet Internet Solutions To: Webmin users list <web...@li...> Subject: Re: [webmin-l] BIND slave issue Send reply to: Webmin users list <web...@li...> <mailto:web...@li...?subject=unsubscribe> <mailto:web...@li...?subject=subscribe> [ Double-click this line for list subscription options ] da...@so... wrote: > Sorry Kris, > I'm just using the out of box BIND module in a VirtualminPro setup. > In Webmin you can register other servers as webmin servers and > then assign them as "cluster slave servers" in the BIND module. > > Essentially, I'm trying to see if there's a bug or I what I need to > adjust to fix these RPC errors that I've been getting. So NS1 and > NS2 have each other then as slave servers. For some reason NS2 > will receive the new domain during account creation but then gets > an RPC invalid login error during the second access to NS2. Hmm. This sounds like a Webmin RPC error rather than a BIND AXFR-related error; as I noted before, a BIND server is either a master or a slave for any given zone - it can't be both, and the errors you showed from BIND indicate to me that one machine *is* trying to be both master and slave for a zone. Without seeing the named.conf and zone files, I can't tell you anything more useful about what BIND is doing. You *can* have a pair of servers with one machine acting as master for some zones, and the other acting as master for the rest, but that's not very common and you need a tool like Webmin to keep track of what's where. <g> -kgd ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ - Forwarded by the Webmin mailing list at webadmin- li...@li... To remove yourself from this list, go to http://lists.sourceforge.net/lists/listinfo/webadmin-list ****************************************************************************** *** Domains by SolvNet http://solvnetdomains.com Be a domain reseller and make cash http://domainmiddleman.com Domain name registration and hosting solutions. http://solvnethosting.com |
From: Kris D. <kd...@vi...> - 2007-04-30 16:41:27
|
da...@so... wrote: > THe BIND mod is supposed to glean the master address from the master > server hostname within the BIND mod. But, I even tried hand entering the > address (both physical and hostname) into each server to no avail.. I > still get the following: > > zone "dan.net" { > type slave; > masters { > 127.0.0.1; > }; > file "/var/named/slaves/dan.net.hosts"; > }; [snip] Final Wild-Assed Guess: Set the master's IP explicitly in the master's BIND module config by going into the Zone Defaults section, and switching it from "System hostname (host.domain)" to an explicit IP or name. Even accessing via localhost, my test setup set this "correctly" to the master's FQDN. -kgd |