Re: big improvement in BIND9 auth-server startup time
Evan Hunt wrote last July 13: -- People who operate big authoritative name servers (particularly with large numbers of small zones, e.g., for domain hosting and parking), and have had trouble with slow startup, may find this information useful: http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance I ran some tests yesterday on an Ubuntu Hardy virtual machine. I was using 9.7.3-P3 and 9.7.4. There is nothing running on the box except BIND and the Hardy operating system. The DNS configuration file has a handful of test zones. It also has our list of 202,818 spyware/malware zones, each using the same zone file, which has one NS record and @ IN A a.b.c.d * IN A a.b.c.d The shutdown time for 9.7.3-P3 was 1:27:11 (1.5 hours). The timing was from the ./rndc stop until the exiting message. I did three shutdowns of 9.7.4 with the default BIND9_ZONE_TASKS_HINT=8 value. The shutdown times were 7:17, 7:07, and 7:35. The shutdown time improved DRAMATICALLY. I did three start-ups of 9.7.4: BZTH Time --- default 4:57 default 5:04 1020 5:19 I did not see any improvement in start-up time. The last start-up did produce the message Using 1020 tasks for zone loading The first two start-ups produced the message Using 101 tasks for zone loading The CHANGES file says that the default is 8. I need to run some more tests. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ 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: How to Setup a Name Servers visible on Internet?
Metropolitan College Eric Kom eric...@metropolitanstaff.co.za wrote, in part: An embedded and charset-unspecified text was scrubbed... Name: 194.134.41.in-addr.arpa URL: https://lists.isc.org/pipermail/bind-users/attachments/20110620/99499308/attachment-0001.ksh The attachment: $TTL 3H 194.134.41.in-addr.arpa.IN SOA ns1.metropolitanbuntu.co.za. postmaster.metropolitanbuntu.co.za. ( 8 ; serial 3600; refresh 900 ; retry 1209600 ; expire 43200) ; default_TTL ; 90.194.134.41.in-addr.arpa. IN NS ns1.metropolitanbuntu.co.za. 91.194.134.41.in-addr.arpa. IN NS ns2.metropolitanbuntu.co.za. ; 194.134.41.in-addr.arpa.IN NS ns1.mweb.co.za. 194.134.41.in-addr.arpa.IN NS ns2.mweb.co.za. ; 90 IN PTR ns1.metropolitanbuntu.co.za. 91 IN PTR ns2.metropolitanbuntu.co.za. The NS records are incorrect. The left-hand side on the ns1.metropolitanbuntu ns2.metropolitanbuntu lines should either be 194.134.41.in-addr.arpa. or @ The @ signifies the current origin. You have the NS records with a prefix of the last octet of the IP address. The NS records for ns[12].mweb are correct, I believe. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ 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: BIND 9.7 Serial Number Decrease Problem
On 07/06/11 13:51, I wrote: I now have this situation on one Solaris 10 slave; the problem probably also exists on the other Sol 10 slave and the two Ubuntu hardy slaves: The _tcp zone on the master MS DNS Server: 1238 600 86400 3600 The _tcp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 1239 ; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) The _udp zone on the master MS DNS Server: 842 900 600 86400 3600 The _udp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 843; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) Note that the zone serial number for both zones on the master is one LESS than the serial number on the slave. The last messages in /var/adm/messages are _tcp: Jun 4 07:46:57 serial number (1238) received from master ... ours (1239) Jun 4 07:47:35 zone ... expired Jun 4 07:47:35 zone ... transfer started Jun 4 07:47:35 zone ... transferred serial 1238 Jun 4 07:47:35 zone ... Transfer completed: ... _udp: Jun 4 07:39:22 serial number (842) received from master ... ours (843) Jun 4 07:42:22 zone ... expired Jun 4 07:42:22 zone ... transfer started Jun 4 07:42:22 zone ... transferred serial 842 Jun 4 07:42:22 zone ... Transfer completed There was a zone serial number mismatch, each zone expired three days ago, and new zones were transferred from the master. But the zone files on disk still have the higher serial numbers. There are no .jnl files on the disk. A dig on the server for the zone serial numbers shows the lower numbers, so BIND has those correct serial numbers. I assume that if I stopped BIND (rndc stop) and restarted it, then I would again see the serial number mismatches. I can try this during the day, as this server is not heavily used. Is there any debugging I need to run? Thanks. I ran a test this morning on one of the Solaris 10 slave servers. A query to the server showed serial numbers: _tcp 1238 _udp842 Both of these match the zone on the MS Windows DNS Server. I checked the zone files on the slave server: _tcp 1239 _udp843 Both of these are increased by one from what BIND returns in response to a query. The two zones have NO .jnl files. I did ./rndc stop Wait for the exiting message. /etc/init.d/named.anl start;tail -f /var/adm/messages Once BIND started, the serial numbers were INCREASED, as I expected they would be, given the lack of .jnl files. And a few minutes later BIND complained about the serial number on the master being less than that on the slave for both zones. I consider this a bug in BIND 9. What further diagnostics do I need to get? I have another Solaris 10 slave on which, I assume, I can duplicate this. And from past experience, in one day, after the zone has expired and been refreshed, I will be in the same state on this slave. - -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
In my last posting I was confused as to the .jnl file. I have about 44 AD slave files on my BIND servers, and 40 .jnl files. The two zones in question do not have .jnl files. As I do not look at .jnl files much, I had forgotten about the tool to list them. I now have this situation on one Solaris 10 slave; the problem probably also exists on the other Sol 10 slave and the two Ubuntu hardy slaves: The _tcp zone on the master MS DNS Server: 1238 600 86400 3600 The _tcp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 1239 ; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) The _udp zone on the master MS DNS Server: 842 900 600 86400 3600 The _udp zone on the BIND 9.7.3-P1 Solaris 10 server disk: 843; serial 900; refresh (15 minutes) 600; retry (10 minutes) 86400 ; expire (1 day) 3600 ; minimum (1 hour) Note that the zone serial number for both zones on the master is one LESS than the serial number on the slave. The last messages in /var/adm/messages are _tcp: Jun 4 07:46:57 serial number (1238) received from master ... ours (1239) Jun 4 07:47:35 zone ... expired Jun 4 07:47:35 zone ... transfer started Jun 4 07:47:35 zone ... transferred serial 1238 Jun 4 07:47:35 zone ... Transfer completed: ... _udp: Jun 4 07:39:22 serial number (842) received from master ... ours (843) Jun 4 07:42:22 zone ... expired Jun 4 07:42:22 zone ... transfer started Jun 4 07:42:22 zone ... transferred serial 842 Jun 4 07:42:22 zone ... Transfer completed There was a zone serial number mismatch, each zone expired three days ago, and new zones were transferred from the master. But the zone files on disk still have the higher serial numbers. There are no .jnl files on the disk. A dig on the server for the zone serial numbers shows the lower numbers, so BIND has those correct serial numbers. I assume that if I stopped BIND (rndc stop) and restarted it, then I would again see the serial number mismatches. I can try this during the day, as this server is not heavily used. Is there any debugging I need to run? Thanks. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.7 Serial Number Decrease Problem
McDonald, Dan dan.mcdon...@austinenergy.com replied to my posting: I think your root problem is trying to deal with active directory integrated zones. We stopped using them entirely when we found that each domain controller maintains an individual SOA record with its own serial number. The serial numbers rapidly (and purposely) fall out of sync, but active directory doesn't care as they use a different replication method. The only way that we could successfully interact from bind was to set up a forward-only zone and try to cache the results. When we found that Active directory under windows 2000 was unable to maintain proper synchronization, we switched to bind for all zones and haven't looked back. If you check the list archives (back to the days when there was bind-users and bind9-users), you will find my postings dealing with MS article 282826. MS details the problem with zone serial numbers, and that is why we run the DNS Server on only ONE Domain Controller (and have since the beginning of AD in Windows 2000). When we run the DNS Server on a second DC (because the Windows admins want to), I tell BIND that there is ONE master server. I do not care what the zone serial number is on the other DC DNS Server, unless we have to switch masters. The only times I have switched is when the master DC is being upgraded, and I switch to another DC as the master. We have NO machines cofigured (as far as I know) to use the DNS Servers on the DC as primary DNS servers; all machines are configured to use the BIND slaves. In the early days of AD, there were serial number decreases in the MS code. I had an open trouble ticket for a long time before the MS DNS development team found the problem. I have not had a serial number decrease on the MS side for a long time except, occasionally, when patches are being applied to the DC, the serial number on one or more zones will decrease during the patch run, but after the DC is rebooted, the serial number goes back to a non-decrease normal. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.7 Serial Number Decrease Problem
In message4de9045c.2050...@anl.gov, Barry Finkel writes: I have a problem with BIND 9.7.x on Ubuntu. I have two servers that are running 9.7.3. They slave 332 zones, and they also master 213,750 malware/spyware zones that we have defined to reroute these domains to a local machine. When I was upgrading the BIND to 9.7.3-P1 yesterday, an ./rndc stop command ran over 8 minutes, and named did not stop. A kill command did not work; I had to revert to a kill -9 command. What was BIND doing? Gracefully closing all of the zones? Most probably. rndc stop ensures that masterfiles are up-to-date before exiting. rndc halt does not try to flush master files before exiting. There could also have been a reference leak causing named to not stop. BIND 9.7.3-P1 came up fine, but there are two things that concern me: 1) After BIND began responding to queries, it was using 100% of the CPU for about three minutes. I am not sure what BIND was doing. This is not major because BIND was handling customer queries, and after the three minutes the CPU usage dropped to a normal 1%. 2) Two zones reported serial number decreases. This is bad. I did some research on the two zones - both Microsoft Active Directory zones (one _tcp and one _udp) that are mastered on a Windows Domain Controller and slaved on my BIND boxes. I have around 44 AD zones I slave, and only these two reported problems - on my two internal Ubuntu slaves and my two Solaris 10 slaves. The two Solaris 10 slaves do not run the spyware zones, so I had no problem with ./rndc stop. I therefore am not sure that the serial number problems are due to the kill -9. They shouldn't be. The handling of master files and journals is designed to have the power be pull at anytime provided the filesystem supports atomic replacement of files. I looked at the serial number issue on these two zones in detail; I capture the serial numbers on all the AD zones each morning at 6:10. Here is information for the _tcp zone: DateZone Mast Slav Slav 20 Oct 2010 _tcp. 1233 1233 1233 21 Oct 2010 _tcp. 1239 1239 1239 The master incremented the serial. ... 09 Nov 2010 _tcp. 1239 1239 1239 10 Nov 2010 _tcp. 1238 1239 1239 Master decreased due to MS patch 11 Nov 2010 _tcp. 1238 1238 1238 ... 03 Dec 2010 _tcp. 1238 1238 1238 04 Dec 2010 _tcp. 1238 1238 1239 ?? 05 Dec 2010 _tcp. 1238 1239 1238 ?? 06 Dec 2010 _tcp. 1238 1238 1238 ... 09 Dec 2010 _tcp. 1238 1238 1238 10 Dec 2010 _tcp. 1238 1238 1239 ?? 11 Dec 2010 _tcp. 1238 1239 1238 ?? 12 Dec 2010 _tcp. 1238 1238 1238 ... 05 Jan 2011 _tcp. 1238 1238 1238 06 Jan 2011 _tcp. 1238 1239 1239 ?? 07 Jan 2011 _tcp. 1238 1238 1238 ... 02 Mar 2011 _tcp. 1238 1238 1238 Upgrade 9.7.2-P3 to 9.7.3 03 Mar 2011 _tcp. 1238 1239 1239 04 Mar 2011 _tcp. 1238 1238 1238 ... 16 Apr 2011 _tcp. 1238 1238 1238 17 Apr 2011 _tcp. 1238 1238 1238 1238 1238 Two Sol10 slaves added. ... 02 Jun 2011 _tcp. 1238 1238 1238 1238 1238 Upgrade 9.7.3 to 9.7.3-P1 03 Jun 2011 _tcp. 1238 1239 1239 1239 1239 Both Ubuntu slaves have been up for 149 days (reboot around Jan 15). The zone serial was 1239 until a MS patch run on the Domain Controller decreased the serial by one on the evening of Nov 9. I did nothing to correct the problem; I waited for the two zones to expire, and then new zones were transferred from the Windows master server. The serial number was 1238 on the master and slaves. On a few days, the serial on the slaves increased by one, and I am not sure what happened on those days. On Mar 02 I upgraded BIND from 9.7.2-P3 to 9.7.3, and the serial numbers on the two upgraded BIND slaves reverted to the higher 1239 serial. Again, I did no fixup, and on Mar 04 the serials were the same at the lower value. I think that the serial number decrease was temporary during the patch run. On Apr 17 I added the two Solaris 10 slaves to my morning report, and all five serials were contant at 1238 until I upgraded BIND Tuesday (on the Solaris 10 boxes) and yesterday (on the Ubuntu boxes). Immediately after the upgrade BIND reported the serial number problem on these two zones. The other AD zones have had no serial number problems. I have no idea why BIND would remember the increased 1239 serial number, when the serial number for the zone has been constant at 1238 since Mar 04. I have to assume that between Mar 04 and Jun 03 BIND would have written the zone to disk, either in the base zone file or a .jnl file. -- -- Barry S. Finkel Phil Mayers suggested a corrupt .jnl file; I am not sure. How do I debug this? I have the following situation now: 1) The master (on an MS DNS Server) has serial 1238. 2) The zone file on a Solaris 10
BIND 9.7 Serial Number Decrease Problem
I have a problem with BIND 9.7.x on Ubuntu. I have two servers that are running 9.7.3. They slave 332 zones, and they also master 213,750 malware/spyware zones that we have defined to reroute these domains to a local machine. When I was upgrading the BIND to 9.7.3-P1 yesterday, an ./rndc stop command ran over 8 minutes, and named did not stop. A kill command did not work; I had to revert to a kill -9 command. What was BIND doing? Gracefully closing all of the zones? BIND 9.7.3-P1 came up fine, but there are two things that concern me: 1) After BIND began responding to queries, it was using 100% of the CPU for about three minutes. I am not sure what BIND was doing. This is not major because BIND was handling customer queries, and after the three minutes the CPU usage dropped to a normal 1%. 2) Two zones reported serial number decreases. This is bad. I did some research on the two zones - both Microsoft Active Directory zones (one _tcp and one _udp) that are mastered on a Windows Domain Controller and slaved on my BIND boxes. I have around 44 AD zones I slave, and only these two reported problems - on my two internal Ubuntu slaves and my two Solaris 10 slaves. The two Solaris 10 slaves do not run the spyware zones, so I had no problem with ./rndc stop. I therefore am not sure that the serial number problems are due to the kill -9. I looked at the serial number issue on these two zones in detail; I capture the serial numbers on all the AD zones each morning at 6:10. Here is information for the _tcp zone: DateZone Mast Slav Slav 20 Oct 2010 _tcp. 1233 1233 1233 21 Oct 2010 _tcp. 1239 1239 1239 The master incremented the serial. ... 09 Nov 2010 _tcp. 1239 1239 1239 10 Nov 2010 _tcp. 1238 1239 1239 Master decreased due to MS patch 11 Nov 2010 _tcp. 1238 1238 1238 ... 03 Dec 2010 _tcp. 1238 1238 1238 04 Dec 2010 _tcp. 1238 1238 1239 ?? 05 Dec 2010 _tcp. 1238 1239 1238 ?? 06 Dec 2010 _tcp. 1238 1238 1238 ... 09 Dec 2010 _tcp. 1238 1238 1238 10 Dec 2010 _tcp. 1238 1238 1239 ?? 11 Dec 2010 _tcp. 1238 1239 1238 ?? 12 Dec 2010 _tcp. 1238 1238 1238 ... 05 Jan 2011 _tcp. 1238 1238 1238 06 Jan 2011 _tcp. 1238 1239 1239 ?? 07 Jan 2011 _tcp. 1238 1238 1238 ... 02 Mar 2011 _tcp. 1238 1238 1238 Upgrade 9.7.2-P3 to 9.7.3 03 Mar 2011 _tcp. 1238 1239 1239 04 Mar 2011 _tcp. 1238 1238 1238 ... 16 Apr 2011 _tcp. 1238 1238 1238 17 Apr 2011 _tcp. 1238 1238 1238 1238 1238 Two Sol10 slaves added. ... 02 Jun 2011 _tcp. 1238 1238 1238 1238 1238 Upgrade 9.7.3 to 9.7.3-P1 03 Jun 2011 _tcp. 1238 1239 1239 1239 1239 Both Ubuntu slaves have been up for 149 days (reboot around Jan 15). The zone serial was 1239 until a MS patch run on the Domain Controller decreased the serial by one on the evening of Nov 9. I did nothing to correct the problem; I waited for the two zones to expire, and then new zones were transferred from the Windows master server. The serial number was 1238 on the master and slaves. On a few days, the serial on the slaves increased by one, and I am not sure what happened on those days. On Mar 02 I upgraded BIND from 9.7.2-P3 to 9.7.3, and the serial numbers on the two upgraded BIND slaves reverted to the higher 1239 serial. Again, I did no fixup, and on Mar 04 the serials were the same at the lower value. I think that the serial number decrease was temporary during the patch run. On Apr 17 I added the two Solaris 10 slaves to my morning report, and all five serials were contant at 1238 until I upgraded BIND Tuesday (on the Solaris 10 boxes) and yesterday (on the Ubuntu boxes). Immediately after the upgrade BIND reported the serial number problem on these two zones. The other AD zones have had no serial number problems. I have no idea why BIND would remember the increased 1239 serial number, when the serial number for the zone has been constant at 1238 since Mar 04. I have to assume that between Mar 04 and Jun 03 BIND would have written the zone to disk, either in the base zone file or a .jnl file. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to check if a slave zone is expired
I review the BIND syslogs on my servers daily. The syslog will tell me if any slave is having problems loading a zone. I expect that the hostmasters at my off-site slaves do the same. If I slave a zone for someone else, and I see problems, I contact the owner of that zone. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9 And Short Name resolution Problem
On 03/31/11 13:17, bind-users-requ...@lists.isc.org wrote:
Hello,
I get the following messages on the BIND server when I do a short name
nslookup from a client:
Mar 31 14:08:04 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'C.ROOT-SERVERS.NET//IN': 2001:500:1::803f:235#53
Mar 31 14:08:05 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'I.ROOT-SERVERS.NET//IN': 2001:500:1::803f:235#53
Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'B.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
Mar 31 14:08:07 jedi named[1299]: [ID 873579 daemon.info] network
unreachable resolving 'L.ROOT-SERVERS.NET//IN': 2001:500:2f::f#53
The config files are below, we are running BIND 9 on Solaris 10. We
currently have 2 domain names configured and on IP address on the BIND
server itself. Any ideas from the gurus??
Thanks
You do not have IPv6 connectivity from the DNS server to
{C,I,B,L}.root-servers.net.
--
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Typo in 9.7.3 Announcement
In the posting and on the ISC release notes page on the web, under Feature Changes - the first heading 9.7.2 should read 9.7.3. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Telling rndc Which IP Address to Use
On 01/19/11 15:21, Jay Ford wrote:
On Wed, 19 Jan 2011, Barry Finkel wrote:
I have a master DNS server that has two IP addresses - one used for
DNS and one used for non-DNS. On that master I run rndc to load
zones on slave servers. On the slave servers I have
controls{
inet a.b.c.d port 953
allow {127.0.0.1; e.f.g.h; } keys { rndc-key';};
}
Where e.f.g.h is the DNS address for the master server. Is there a
way on the master to run rndc and tell rndc which IP address to use?
Or do I have to put the non-DNS address of the master in the controls
directive on the slaves. I am running 9.7.2-P3. Thanks.
Does the -b option not suffice?
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
I forgot about the -b option.
--
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Telling rndc Which IP Address to Use
I have a master DNS server that has two IP addresses - one used for
DNS and one used for non-DNS. On that master I run rndc to load
zones on slave servers. On the slave servers I have
controls{
inet a.b.c.d port 953
allow {127.0.0.1; e.f.g.h; } keys { rndc-key';};
}
Where e.f.g.h is the DNS address for the master server. Is there a
way on the master to run rndc and tell rndc which IP address to use?
Or do I have to put the non-DNS address of the master in the controls
directive on the slaves. I am running 9.7.2-P3. Thanks.
--
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Tracing Response Packets at the Querying Server
I am running bind-9.7.2-P3, and I am having a problem with BIND or the network or the Ubuntu operating system. I send a DNS query from one of my DNS servers to another of my DNS servers. I see in a tshark trace that the reply packet is received back at the querying server, but dig produces a timeout message. Can I set some trace level to see if the reply packet is being seen by BIND? And I am not sure into which logging category the trace records would be written. Thanks. -- -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND View Option
From: St?phanas Schaden stephan...@ctbc.com.br wrote:
Is there a way or option to configure bind to do the following logic:
If the bind didn't find a entry in a view 1 (internal view) it will
search this entry on the view 2 (external view) ?
Place the common piece in a separate include file:
view view1 {
...
include named.conf.non-views;
...
}
view view2 {
...
include named.conf.non-views;
...
}
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Logging SERVFAIL Errors
On BIND 9.7.1-P2 I have in named.conf:
channel query-errors-log {
file /var/log/named.query-errors.log versions 3 size 200k;
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category query-errors { query-errors-log; }; // no default_syslog
Is this correct for logging queries that produce SERVFAIL?
I ran this query on the DNS server:
dns# dig klyuniv.ernet.in @t1dns2.anl.gov
; DiG 9.7.1-P2 klyuniv.ernet.in @t1dns2.anl.gov
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 7278
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;klyuniv.ernet.in. IN A
;; Query time: 1860 msec
;; SERVER: 130.202.101.37#53(130.202.101.37)
;; WHEN: Fri Oct 8 09:06:04 2010
;; MSG SIZE rcvd: 34
dns#
and there is nothing logged in
/var/log/named.query-errors.log
Am I doing something wrong? Thanks.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Logging SERVFAIL Errors
Am Fri, 8 Oct 2010 09:09:16 -0500 (CDT)
schrieb b19...@anl.gov (Barry Finkel):
On BIND 9.7.1-P2 I have in named.conf:
channel query-errors-log {
file /var/log/named.query-errors.log versions 3 size
200k; print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category query-errors { query-errors-log; }; // no
default_syslog
Is this correct for logging queries that produce SERVFAIL?
I ran this query on the DNS server:
dns# dig klyuniv.ernet.in @t1dns2.anl.gov
; DiG 9.7.1-P2 klyuniv.ernet.in @t1dns2.anl.gov
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 7278
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;klyuniv.ernet.in. IN A
;; Query time: 1860 msec
;; SERVER: 130.202.101.37#53(130.202.101.37)
;; WHEN: Fri Oct 8 09:06:04 2010
;; MSG SIZE rcvd: 34
dns#
and there is nothing logged in
/var/log/named.query-errors.log
Am I doing something wrong? Thanks.
and Torsten t...@the-damian.de replied:
You have to set a debug level of at least 1 to capture SERVFAIL errors
in your logfile.
I did
./rndc trace
and re-issued my query. There was nothing in the
/var/log/named.query-errors.log
log. I then did another trace command to increase the debug level to
2, and a subsequent query command put nothing in the log.
--
Barry S. Finkel
Computing and Information Systems Division
Argonne National Laboratory Phone:+1 (630) 252-7277
9700 South Cass Avenue Facsimile:+1 (630) 252-4601
Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
Argonne, IL 60439-4828 IBMMAIL: I1004994
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: non-24 bit subnets
You can have a different TTL for each and every record, if you like, in the same zone file with no includes (the $TTL directive can appear multiple times). e.g. : $TTL 300; 5 mins *PTRhost-no-spec.example.com. $TTL 3600; 1 hour 17 PTR mail.example.com. $TTL 1800; 30 mins 18 PTR mail2.example.com. $TTL 86400; 1 day 19PTRwhatever.example.com 20PTRwhatever2.example.com 22PTRwhatever2.example.com Or you can put a TTL on an individual line: $TTL 300; 5 mins *PTRhost-no-spec.example.com. 17 3600 PTR mail.example.com. 18 1800 PTR mail2.example.com. 19PTRwhatever.example.com 20PTRwhatever2.example.com 22PTRwhatever2.example.com Those lines without a TTL get the first $TTL in the zone. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
A Further Question about query-source
I have DNS severs with multiple addresses. They are running 9.7.1-P2. On the servers I have query-source 1.2.3.4; to tell BIND to use one of the DNS addresses for its queries. Yesterday on the box I issued dig example.com @someserver.example.com and the query was sent using the non-DNS address. I expected the query-source directive to send the query over the 1.2.3.4 IP address and not one of the other three addresses on the box. Is query-source not honored because I specified the DNS server I wanted to query? Thanks. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Question on query-source, transfer-source, notify-source
On 7/28/10, I wrote: I have a BIND config question. First some history. My initial two DNS servers (A and B) had three NICs and three IP addresses. Then I installed two additional servers (C and D), each with one NIC; each server has one base address and one DNS address. All four servers run Solaris. When I installed C and D, I placed in the config file query-source address dns-address; transfer-source dns-address; notify-source dns-address; Then we changed servers A and B to new hardware, and we have in addition to the three NICs each, a base, non-DNS address for each. We made no config file changes, and no users have reported problems. These new servers A and B have been running for a few years. Now, I am converting all four servers to an Ubuntu platform, and I am revisiting the config file. In looking through various firewall and DNS query logs, I see that machines A and B are using the non-DNS and queries to the hidden BIND master via the non-DNS addresses. The Internet queries are being blocked at the firewall because we do not allow non-registered DNS addresses to send DNS queries to the Internet, and the non-DNS addresses have no firewall conduits. I can add three options directives above, as I have done on servers C and D, but the ARM seems to imply that I can list only one address in each directive, and I have three DNS addresses for each server. The BIND is 9.7.x on all machines. Does anyone have suggestions? Thanks. and Chris Buxton chris.p.bux...@gmail.com replied: Why do you need 3 DNS interfaces on one box? Why do you need the extra interface? Perhaps you could simplify, or split the three addresses across multiple hosts, or even run multiple instances of named on each box. Historical. The DNS servers serve three Class-B subnets, and it was decided when the servers were placed in production many years ago that they should have an address on each of the Class-B subnets. One of the subnets had a /22 that was used for buildings on campus that did not have IP connectivity; they got their IP via the phone system copper and a device plugged in to the phone jack. We had to have a DNS server on that /22. We have decided that since we can only place one address in the query-source address dns-address; transfer-source dns-address; notify-source dns-address; statements, we will choose one of the three addresses on each server and use it. I believe that it makes no difference if we use the same address in each of the three statements, or if we use a different address in each. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Question on query-source, transfer-source, notify-source
I have a BIND config question. First some history. My initial two DNS servers (A and B) had three NICs and three IP addresses. Then I installed two additional servers (C and D), each with one NIC; each server has one base address and one DNS address. All four servers run Solaris. When I installed C and D, I placed in the config file query-source address dns-address; transfer-source dns-address; notify-source dns-address; Then we changed servers A and B to new hardware, and we have in addition to the three NICs each, a base, non-DNS address for each. We made no config file changes, and no users have reported problems. These new servers A and B have been running for a few years. Now, I am converting all four servers to an Ubuntu platform, and I am revisiting the config file. In looking through various firewall and DNS query logs, I see that machines A and B are using the non-DNS address for DNS activity. A and B are sending queries to the Internet and queries to the hidden BIND master via the non-DNS addresses. The Internet queries are being blocked at the firewall because we do not allow non-registered DNS addresses to send DNS queries to the Internet, and the non-DNS addresses have no firewall conduits. I can add three options directives above, as I have done on servers C and D, but the ARM seems to imply that I can list only one address in each directive, and I have three DNS addresses for each server. The BIND is 9.7.x on all machines. Does anyone have suggestions? Thanks. -- Barry S. Finkel Computing and Information Systems Division Argonne National Laboratory Phone:+1 (630) 252-7277 9700 South Cass Avenue Facsimile:+1 (630) 252-4601 Building 240, Room 5.B.8 Internet: bsfin...@anl.gov Argonne, IL 60439-4828 IBMMAIL: I1004994 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
