Re: zone reload questions
Hmm! I was just thinking this is a BUG!
I wrote a function in Perl to modify the serial number:
sub increase_serial {
my $bindetc = /usr/local/bind/etc/;
my @zones = get_zones(); # get the zones
for my $zone (@zones) {
for my $isp ('tel','cnc') { # two isp links
my $file = $bindetc . $zone.$isp.db;
my @c;
open HD, $file or die $!;
while(HD) {
s/(\d+)(\s+\; Serial)/($1 + 1) . $2/e; # increase the
serial number by 1
push @c,$_;
}
close HD;
open HDW, , $file or die $!;
print HDW for @c;
close HDW;
}
}
return 1;
}
I do below to execute the reload:
increase_serial();
system(/usr/local/bind/sbin/rndc reload);
OK I run two reload in a second, the serial number was increased
correctly, but bind only reload zones correctly for the first time.
This is the system log:
[the first reload is successful]:
Mar 20 16:08:46 localhost named[25599]: received control channel
command 'reload'
Mar 20 16:08:46 localhost named[25599]: loading configuration from
'/usr/local/bind9.6/etc/named.conf'
Mar 20 16:08:46 localhost named[25599]: using default UDP/IPv4 port
range: [1024, 65535]
Mar 20 16:08:46 localhost named[25599]: using default UDP/IPv6 port
range: [1024, 65535]
Mar 20 16:08:46 localhost named[25599]: reloading configuration succeeded
Mar 20 16:08:46 localhost named[25599]: reloading zones succeeded
Mar 20 16:08:46 localhost named[25599]: zone test.duxieweb.com/IN/cnc:
loaded serial 102502
Mar 20 16:08:46 localhost named[25599]: zone my.test.com/IN/cnc:
loaded serial 101
Mar 20 16:08:46 localhost named[25599]: zone test.duxieweb.com/IN/tel:
loaded serial 102502
Mar 20 16:08:46 localhost named[25599]: zone my.test.com/IN/tel:
loaded serial 101
[the second time bind doesn't reload zones even zones db were changed]:
Mar 20 16:08:46 localhost named[25599]: received control channel
command 'reload'
Mar 20 16:08:46 localhost named[25599]: loading configuration from
'/usr/local/bind9.6/etc/named.conf'
Mar 20 16:08:46 localhost named[25599]: using default UDP/IPv4 port
range: [1024, 65535]
Mar 20 16:08:46 localhost named[25599]: using default UDP/IPv6 port
range: [1024, 65535]
Mar 20 16:08:46 localhost named[25599]: reloading configuration succeeded
Mar 20 16:08:46 localhost named[25599]: reloading zones succeeded
Will bind only reload zone files based on the file's mtime by second?
That's will be a huge problem for some dynamic dns I may think.
Thanks.
Ralf.
2009/3/20 Ralf Peng ralf.p...@gmail.com:
Hello,
I'm using Bind-9.6-P1, and found something strange about zone reloading.
I have two views, for example, one is cnc, another is tel (the default).
The records for cnc and tel are parsed to two different ISP's links.
Sometime our cnc link is disconnected, at this time I copy cnc's zone
db to a backup file, for example:
cp cnc.zone.db cnc.zone.db.bak
and copy tel's zone db to cnc's, for example,
cp tel.zone.db cnc.zone.db
Then I reload bind (sbin/rndc reload), all works fine.
But, the problem is, when cnc link is re-connected, I restore cnc's
zone db to the original one, for example:
mv cnc.zone.db.bak cnc.zone.db
and reload bind.
this time things work not fine.
bind didn't load the correct cnc zone (restored from cnc.zone.db.bak),
it kept the old one which was copied from tel's.
in order to let bind reload correctly, I need to do:
cd /usr/local/bind/etc
touch *
/usr/local/bind/sbin/rndc reload
then bind reloads all zones correctly.
Why this happens? is it problematic for automatic SA job?
btw: my name server is: ns.test.duxieweb.com
Thanks.
Ralf.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: No A Record for NS
On Fri, 20 Mar 2009 15:57:03 +1100 Mark Andrews mark_andr...@isc.org wrote: I'm trying to query for A record, like this : # dig @a.gtld-servers.net ns1.ats-com.com +short 203.130.232.235 # dig @203.130.232.235 ns1.ats-com.com +short (No A Record) What is happen if that NS be used for authoritative some domain(s) ? Things break once the nameserver learn that the authoritative servers for the zone don't have address records. Could you explain the query results, below : (Two Cache DNS, with different results) # dig www.ats-com.com @222.124.204.34 ; DiG 9.4.1-P1 www.ats-com.com @222.124.204.34 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 2091 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.ats-com.com. IN A ;; Query time: 6 msec ;; SERVER: 222.124.204.34#53(222.124.204.34) ;; WHEN: Fri Mar 20 15:14:45 2009 ;; MSG SIZE rcvd: 33 # dig www.ats-com.com @202.134.1.10 ; DiG 9.4.1-P1 www.ats-com.com @202.134.1.10 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45331 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; QUESTION SECTION: ;www.ats-com.com. IN A ;; ANSWER SECTION: www.ats-com.com.3108IN CNAME ats-com.com. ats-com.com.745 IN A 203.130.232.235 ;; AUTHORITY SECTION: ats-com.com.745 IN NS ns2.ats-com.com. ats-com.com.745 IN NS ns1.ats-com.com. ;; ADDITIONAL SECTION: ns2.ats-com.com.2337IN A 203.130.232.235 ;; Query time: 11 msec ;; SERVER: 202.134.1.10#53(202.134.1.10) ;; WHEN: Fri Mar 20 15:22:36 2009 ;; MSG SIZE rcvd: 115 Is it possible if the information for A record (ns1.ats-com.com) get from the NS parent ? Which the problem ? (cache dns or the domain) Thank You. -- Senmi sen...@telkom.net.id ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: No name resolution when slave is down
More data will need to be known. Where is the master and where is the slave, in the same subnet, or elsewhere? Were you previously getting any queries against the master at all, look in your logs? Are you sure your domains NS records even point to the master server? If the master is replying, and you are sure the answer is coming from the master, and not somewhere else, then I would look to make sure the domains are set up correct with the registrar pointing to the correct NS's. On Mar 20, 2009, at 4:51 AM, Dennis J. wrote: Hi, This morning the slave in our nameserver setup went down and surprisingly none of the domains hosted on these system could be resolved anymore even with the master working perfectly fine. When I send queries directly to the master it resolves the domains fine so I'm not sure why a failure of the slave leads to a total failure of the service. Does anyone have an idea what might cause this behavior? -- Scott * If you contact me off list replace talklists@ with scott@ * ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Fwd: No name resolution when slave is down
-- Forwarded message -- From: Chris Dew cms...@googlemail.com Date: 2009/3/20 Subject: Re: No name resolution when slave is down To: Dennis J. denni...@conversis.de Asking the obvious here, but does your domain registrar list both your master and your slave as authoritative nameservers for your domain? Could you provide the domain name in question? Regards, Chris Dew http://www.finalcog.com 2009/3/20 Dennis J. denni...@conversis.de Hi, This morning the slave in our nameserver setup went down and surprisingly none of the domains hosted on these system could be resolved anymore even with the master working perfectly fine. When I send queries directly to the master it resolves the domains fine so I'm not sure why a failure of the slave leads to a total failure of the service. Does anyone have an idea what might cause this behavior? Regards, Dennis ___ 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: No name resolution when slave is down
DHCP options not giving both nameservers? What happens when you manually configure your workstation to only query the master? Quoting Dennis J. denni...@conversis.de: Hi, This morning the slave in our nameserver setup went down and surprisingly none of the domains hosted on these system could be resolved anymore even with the master working perfectly fine. When I send queries directly to the master it resolves the domains fine so I'm not sure why a failure of the slave leads to a total failure of the service. Does anyone have an idea what might cause this behavior? Regards, Dennis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Dwayne Hottinger Network Administrator Harrisonburg City Public Schools Everything should be made as simple as possible, but not simpler. -- Albert Einstein The hottest places in Hell are reserved for those who, in times of moral crisis, preserved their neutrality. -- Dante ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
No name resolution when slave is down
Hi, This morning the slave in our nameserver setup went down and surprisingly none of the domains hosted on these system could be resolved anymore even with the master working perfectly fine. When I send queries directly to the master it resolves the domains fine so I'm not sure why a failure of the slave leads to a total failure of the service. Does anyone have an idea what might cause this behavior? Regards, Dennis ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
zone transfer from slave to master not working
Greetings fellow bind users: We have two name servers: ns1, ns2. We have domain name: let's say abc.com Management decided to have a dns hosting company hosts that domain. LOL. Now they want to move that domain back to the ns1, ns2. ($$) I have changed the dns entries at the registrar to point to ns1, ns2. Now when I tried to do a zone transfer from ns2 to get the record from ns1 it does not work. I think because ns1 is still not yet authoritative for abc.com My questions: 1. If ns1 is not authoritative for abc.com, ns2 cannot do a zone transfer from ns1, correct? please confirm. 2. If yes on number 1, then WHY? Thank you. -John. -- Best Regards, John D. Vo Eagle Teleconferencing Services, Inc. Network-System Administrator j...@eagle.net Office: (212) 200-2000 Ext. 105 Cell: (212) 200-3016 --- ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND 9.6.0-P1
Hi Everyone I have installed BIND 9.6.0-P1 on a Windows Server 2003 x64 system but when I come to start the ISC BIND service I always get a 1067 error which I read somewhere was due to permissions so made sure the user account password etc was correct still didn't fix the issue. Sometimes the exe actually crashes and I get an unknown exception The only way I can get bind to start successfully is with named.exe -f -c c:\bind9\etc\named.conf Could anyone tell me what this could be? It works fine on 32 bit systems but I've had bind running before on x64. Regards Carl ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Root Server Simulation Communication Problem
You have recursion disabled on your abc.com server, and I believe that
is preventing your query from succeeding. My understanding is that the
contents of the root hints file are not stored in the server's cache
(which means, I think, that they are not themselves returned in response
to queries for those records). Since you have recursion disabled on
abc.com, it is never using its root hints to query your root server
(rootns.man) for the NS and A records for the root zone (which sounds
obfuscated, but it is done that way because the root servers themselves
have the most current list of servers for the root zone).
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of T
MANIKANDAN-PKXR74
Sent: Friday, March 20, 2009 8:30 AM
To: bind-users@lists.isc.org
Subject: Root Server Simulation Communication Problem
Hi,
I am trying to set up lab which replicates the root server
also. ( DNS with Root server simulation for Intranet),
Basically I have two servers one abc.com as authoritative server
and the other rootns.man acting as root server. running BIND 9 on both.
I have done the following things in my named.conf file
options {
directory /var/named;
recursion no;
};
zone . {
type hint;
file root;
};
zone abc.com IN {
type master;
file forward;
};
zone 10.168.192.in-addr.arpa IN {
type master;
file reverse;
};
My root File (Points to another DNS acting as Root server let us
call rootns.man)
. 86400 IN NS rootns.man.
rootns.man. 86400 IN A 1.2.3.4
My Forward and reverse file
$TTL 3600
@ IN SOA abc.com. root.abc.com. (
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
abc.com. IN A 192.168.10.12
$TTL 3600
@ IN SOA abc.com. root.abc.com.(
42 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D) ; minimum
IN NS abc.com.
12 IN PTR abc.com.
In the other DNS server rootns.man (acting root server)
zone . IN {
type master;
file forward;
};
Forward file in roons.man server
$TTL86400
@ IN SOA rootns.man root.rootns.man (
42 ; serial
(d. adams)
3H ;
refresh
15M ; retry
1W ; expiry
1D );
minimum
. IN NS rootns.man.
rootns.man. IN A1.2.3.4
Once completing this I have a minor problem that is my abc.com
server is not able to determine the root server (rootns.man) IP address.
attached the DIG output from abc.com server. can any one please help me
in resolving this issue.
Regards
Mani
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: zone transfer from slave to master not working
On 20.03.09 09:56, John D. Vo wrote: We have two name servers: ns1, ns2. We have domain name: let's say abc.com Management decided to have a dns hosting company hosts that domain. LOL. Now they want to move that domain back to the ns1, ns2. ($$) I have changed the dns entries at the registrar to point to ns1, ns2. Now when I tried to do a zone transfer from ns2 to get the record from ns1 it does not work. I think because ns1 is still not yet authoritative for abc.com What do you mean authoritative here? That the zone is not on ns1 yet? (see below) My questions: 1. If ns1 is not authoritative for abc.com, ns2 cannot do a zone transfer from ns1, correct? please confirm. correct. 2. If yes on number 1, then WHY? well, in addition to the requirement that the zone must reside on the server to be able to AXFR from it, the server must also allow transfer from the client you are transferring from. Check allow-transfer directive, globally for the nameserver and locally for the configured zone. I think the default is none (check the docs for sure) -- 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 World. One Web. One Program. - Microsoft promotional advertisement Ein Volk, ein Reich, ein Fuhrer! - Adolf Hitler ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone transfer from slave to master not working
In article gq077q$13q...@sf1.isc.org, John D. Vo j...@eagle.net wrote: 1. If ns1 is not authoritative for abc.com, ns2 cannot do a zone transfer from ns1, correct? please confirm. Correct. 2. If yes on number 1, then WHY? A nameserver declares itself non-authoritative either because it hasn't loaded the zone at all, or because it detected serious errors when loading the zone. In the first case, there's nothing to transfer. In the second case, it would be transferring an erroneous, probably incomplete, zone, and this doesn't seem like a good idea; it's better to have the slaves continue to serve the last known good version of the zone. -- 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
query (cache) 'coriander.plus.com/A/IN' denied
We have a domain which we serve dns for but we don't handle mail for this client. However in the log file I can see all the time that there mail server is trying to run a query on our dns server but is being denied. The log message 20-Mar-2009 16:32:54.984 security: info: client 95.102.17.107#14080: query (cache) 'coriander.plus.com/A/IN' denied And in the clients zone file we have @ IN MX 10 coriander.plus.com. Is this anything to worry about? How can I determine if the client is receiving email - without asking - because these appear in the log all the time. Regards Carl ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query (cache) 'coriander.plus.com/A/IN' denied
In article gq0gtm$1a0...@sf1.isc.org, Carl Fretwell c...@growstudio.co.uk wrote: We have a domain which we serve dns for but we don't handle mail for this c= lient. However in the log file I can see all the time that there mail serve= r is trying to run a query on our dns server but is being denied. The log message 20-Mar-2009 16:32:54.984 security: info: client 95.102.17.107#14080: query = (cache) 'coriander.plus.com/A/IN' denied Is it always the same client IP? That IP is some random DSL user in Slovakia. And in the clients zone file we have @ IN MX 10 coriander.plus.com. Is this anything to worry about? How can I determine if the client is recei= ving email - without asking - because these appear in the log all the time. This suggests one of the following problems: 1. 95.102.17.107 is pointing to your nameserver in its resolver configuration, but your server doesn't allow them to use you as a resolver (the IP isn't in your allow-recursion and allow-query-cache ACL). 2. The plus.com zone is delegated to your server, but you're not properly configured to serve it. It doesn't look like #2. The zone is delegated to ns1.force9.net and ns2.force9.net, and they appear to be responding properly. -- 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
RE: number of zones not matching
I had to do this a couple times lately .. this is the simplest way I've
found. It's not elegant or nifty, but it works.
on the master:
grep zone named.conf | awk '{print $2} | sort master.zones
on the slave:
grep zone named.conf | awk '{print $2} | sort slave.zones
get the files on the same system and diff them.
Are they both running the same version of BIND?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John D. Vo
Sent: Friday, March 20, 2009 3:15 PM
To: bind-users@lists.isc.org
Subject: number of zones not matching
Greetings:
My master name server says it has 102 zones but my slave says it has 98.
Without going through each and compare one with another, is there an
easier way to see what's missing on the slave?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: number of zones not matching
Yes, Todd. 9.2.2.
Todd Snyder wrote:
I had to do this a couple times lately .. this is the simplest way I've
found. It's not elegant or nifty, but it works.
on the master:
grep zone named.conf | awk '{print $2} | sort master.zones
on the slave:
grep zone named.conf | awk '{print $2} | sort slave.zones
get the files on the same system and diff them.
Are they both running the same version of BIND?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John D. Vo
Sent: Friday, March 20, 2009 3:15 PM
To: bind-users@lists.isc.org
Subject: number of zones not matching
Greetings:
My master name server says it has 102 zones but my slave says it has 98.
Without going through each and compare one with another, is there an
easier way to see what's missing on the slave?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: number of zones not matching
I know at some point in the recent past, BIND started loading RFC1918
zones, which can increase the zone count, even though they don't show up
in named.conf. That caused me 5 minutes of wtf before I remembered.
I think it was well after 9.2.2, so I'm guessing you should be safe.
t.
-Original Message-
From: John D. Vo [mailto:j...@eagle.net]
Sent: Friday, March 20, 2009 3:27 PM
To: Todd Snyder
Cc: bind-users@lists.isc.org
Subject: Re: number of zones not matching
Yes, Todd. 9.2.2.
Todd Snyder wrote:
I had to do this a couple times lately .. this is the simplest way
I've found. It's not elegant or nifty, but it works.
on the master:
grep zone named.conf | awk '{print $2} | sort master.zones
on the slave:
grep zone named.conf | awk '{print $2} | sort slave.zones
get the files on the same system and diff them.
Are they both running the same version of BIND?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John D. Vo
Sent: Friday, March 20, 2009 3:15 PM
To: bind-users@lists.isc.org
Subject: number of zones not matching
Greetings:
My master name server says it has 102 zones but my slave says it has
98.
Without going through each and compare one with another, is there an
easier way to see what's missing on the slave?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: number of zones not matching
Hi Todd:
Thank you for those magical commands. Works better than printing them
out and crossing one by one with a pen.
Think the problem was some of the domains I created on master(see my
previous post) did not get transferred to the slave hence the mismatch.
I just reloaded on the master and saw a bunch of stuff going to the
slave so I must be doing something right. The number of zones now
matched.
Thanks,
-John.
Todd Snyder wrote:
I know at some point in the recent past, BIND started loading RFC1918
zones, which can increase the zone count, even though they don't show up
in named.conf. That caused me 5 minutes of wtf before I remembered.
I think it was well after 9.2.2, so I'm guessing you should be safe.
t.
-Original Message-
From: John D. Vo [mailto:j...@eagle.net]
Sent: Friday, March 20, 2009 3:27 PM
To: Todd Snyder
Cc: bind-users@lists.isc.org
Subject: Re: number of zones not matching
Yes, Todd. 9.2.2.
Todd Snyder wrote:
I had to do this a couple times lately .. this is the simplest way
I've found. It's not elegant or nifty, but it works.
on the master:
grep zone named.conf | awk '{print $2} | sort master.zones
on the slave:
grep zone named.conf | awk '{print $2} | sort slave.zones
get the files on the same system and diff them.
Are they both running the same version of BIND?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of John D. Vo
Sent: Friday, March 20, 2009 3:15 PM
To: bind-users@lists.isc.org
Subject: number of zones not matching
Greetings:
My master name server says it has 102 zones but my slave says it has
98.
Without going through each and compare one with another, is there an
easier way to see what's missing on the slave?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
-
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
j...@eagle.net
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: number of zones not matching
In message 49c3f591.1090...@eagle.net, John D. Vo writes:
--===8258205717685425773==
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
!DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
html
head
meta content=text/html;charset=ISO-8859-1 http-equiv=Content-Type
/head
body bgcolor=#ff text=#00
Hi Todd:br
br
Thank you for those magical commands. Works better than printing them
out and crossing one by one with a pen.br
br
Think the problem was some of the domains I creatednbsp; on master(see my
previous post) did not get transferred to the slave hence the mismatch.
I just reloaded on the master and saw a bunch of stuff going to the
slave so I must be doing something right. The number of zones now
matched.br
br
Thanks,br
br
-John.br
br
Todd Snyder wrote:
blockquote
cite=mid:1d8c9a4471119a40bd574f9d8d464ae304bd4...@xch60ykf.rim.net
type=cite
pre wrap=I know at some point in the recent past, BIND started loading
RFC1918
zones, which can increase the zone count, even though they don't show up
in named.conf. That caused me 5 minutes of wtf before I remembered.
BIND does NOT load RFC1918 zones. The Internet-Draft that will
allow that has been stalled for over a year now. Once that draft
clears the working group the #if 0/#endif around the RFC 1918
zones will be removed.
I think it was well after 9.2.2, so I'm guessing you should be safe.
t.
-Original Message-
From: John D. Vo [a class=moz-txt-link-freetext href=mailto:j...@eagle.net
mailto:j...@eagle.net/a]
Sent: Friday, March 20, 2009 3:27 PM
To: Todd Snyder
Cc: a class=moz-txt-link-abbreviated href=mailto:bind-users@lists.isc.org
bind-users@lists.isc.org/a
Subject: Re: number of zones not matching
Yes, Todd. 9.2.2.
Todd Snyder wrote:
/pre
blockquote type=cite
pre wrap=I had to do this a couple times lately .. this is the simple
st way
I've found. It's not elegant or nifty, but it works.
on the master:
grep zone named.conf | awk '{print $2} | sort gt; master.zones
on the slave:
grep zone named.conf | awk '{print $2} | sort gt; slave.zones
get the files on the same system and diff them.
Are they both running the same version of BIND?
-Original Message-
From: a class=moz-txt-link-abbreviated href=mailto:bind-users-boun...@lis
ts.isc.orgbind-users-boun...@lists.isc.org/a
[a class=moz-txt-link-freetext href=mailto:bind-users-boun...@lists.isc.o
rgmailto:bind-users-boun...@lists.isc.org/a] On Behalf Of John D. Vo
Sent: Friday, March 20, 2009 3:15 PM
To: a class=moz-txt-link-abbreviated href=mailto:bind-users@lists.isc.org
bind-users@lists.isc.org/a
Subject: number of zones not matching
Greetings:
My master name server says it has 102 zones but my slave says it has
/pre
/blockquote
pre wrap=!98.
/pre
blockquote type=cite
pre wrap=Without going through each and compare one with another, is
there an
easier way to see what's missing on the slave?
Thanks.
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
a class=moz-txt-link-abbreviated
href=mailto:j...@eagle.net;j...@eagle.net
/a
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
___
bind-users mailing list
a class=moz-txt-link-abbreviated href=mailto:bind-users@lists.isc.org;bi
nd-us...@lists.isc.org/a
a class=moz-txt-link-freetext href=https://lists.isc.org/mailman/listinfo
/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users/a
-
This transmission (including any attachments) may contain confidential
/pre
/blockquote
pre wrap=!information, privileged material (including material pr
otected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
/pre
blockquote type=cite
pre wrap=
/pre
/blockquote
pre wrap=!
--
Best Regards,
John D. Vo
Eagle Teleconferencing Services, Inc.
Network-System Administrator
a class=moz-txt-link-abbreviated
href=mailto:j...@eagle.net;j...@eagle.net
/a
Office: (212) 200-2000 Ext. 105
Cell: (212) 200-3016
---
-
This transmission (including any attachments) may contain confidential informat
ion, privileged material (including material protected by the solicitor-clien
t or other applicable
RE: number of zones not matching
BIND does NOT load RFC1918 zones. The Internet-Draft that will allow that has been stalled for over a year now. Once that draft clears the working group the #if 0/#endif around the RFC 1918 zones will be removed. Perhaps I am confused by terminology. I am referring to this: Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 0.IN-ADDR.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 127.IN-ADDR.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 254.169.IN-ADDR.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 2.0.192.IN-ADDR.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 255.255.255.255.IN-ADDR.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: D.F.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 8.E.F.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: 9.E.F.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: A.E.F.IP6.ARPA Mar 20 21:13:34 jump01 named[25739]: automatic empty zone: B.E.F.IP6.ARPA Those zones add to the count of zones loaded, but will not show up in your named.conf. If people are relying on the number of zones loaded verify that zones are available on the slaves, they need to take the automatic empty zones into consideration if they are using different versions of BIND. Sorry if I caused confusion. Todd. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: query (cache) 'coriander.plus.com/A/IN' denied
Barry Margolin bar...@alum.mit.edu wrote: This suggests one of the following problems: 1. 95.102.17.107 is pointing to your nameserver in its resolver configuration, but your server doesn't allow them to use you as a resolver (the IP isn't in your allow-recursion and allow-query-cache ACL). 2. The plus.com zone is delegated to your server, but you're not properly configured to serve it. 3. Incorrect behaviour by the resolver behind 95.102.17.107. I admin an authoritative nameserver which hosts domains with MX records outside the zones: commercial spam/virus-filtering companies providing the MXs for their mail customers which are our DNS-hosting customers. I regularly see queries for the MX records of the hosted domains being immediately followed by queries for the A records for their out-of-zone MX servers. I infer confusion within the resolvers about which nameservers to query. -- Ronan Flood use...@umbral.org.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND 9.5.1-P2 is now available
BIND 9.5.1-P2 is now available. BIND 9.5.1-P2 is a SECURITY patch for BIND 9.5.1. It addresses a bug in DNSSEC lookaside validation (DLV): unrecognized signature algorithms, which should have been treated as the equivalent of an unsigned zone, were instead treated as a validation failure. Bugs should be reported to bind9-b...@isc.org. BIND 9.5.1-P2 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at http://www.isc.org/ISC/isckey.txt. A binary kit for Windows XP, Windows 2003 and Windows 2008 is at ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.zip ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.debug.zip The PGP signature of the binary kit is at ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.zip.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.5.1-P2/BIND9.5.1-P2.debug.zip.sha512.asc Changes since 9.5.1-P1: --- 9.5.1-P2 released --- 2579. [bug] DNSSEC lookaside validation failed to handle unknown algorithms. [RT #19479] -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC BIND 9.4.3-P2 is now available
BIND 9.4.3-P2 is now available. BIND 9.4.3-P2 is a SECURITY patch for BIND 9.4.3. It addresses a bug in DNSSEC lookaside validation (DLV): unrecognized signature algorithms, which should have been treated as the equivalent of an unsigned zone, were instead treated as a validation failure. Bugs should be reported to bind9-b...@isc.org. BIND 9.4.3-P2 can be downloaded from ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz The PGP signature of the distribution is at ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz.sha512.asc The signature was generated with the ISC public key, which is available at http://www.isc.org/ISC/isckey.txt. A binary kit for Windows XP, Windows 2003 and Windows 2008 is at ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.zip ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.debug.zip The PGP signature of the binary kit is at ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.zip.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.zip.sha512.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.debug.zip.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.debug.zip.sha256.asc ftp://ftp.isc.org/isc/bind9/9.4.3-P2/BIND9.4.3-P2.debug.zip.sha512.asc Changes since 9.4.3-P1: --- 9.4.3-P2 released --- 2579. [bug] DNSSEC lookaside validation failed to handle unknown algorithms. [RT #19479] -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ISC Security patch for BIND users of DLV
Users of BIND version 9.5.x or 9.4.x AND DLV ISC announced a new user interface for DLV - DNSSEC Lookaside Validation on March 11th. We have been running the DLV service in limited production and will shortly be ready to move to full production. On 15th March 09 the US Government .gov TLD was added to DLV. The .gov zone is the first major TLD we know of which has been signed using NSEC3, which uses the NSEC3RSASHA1 DNSKEY signature algorithm. Unfortunately this change highlighted a shortcoming in the handling of DLV lookups for BIND versions 9.3, 9.4 and 9.5, which do not support or recognize the NSEC3RSASHA1 signature algorithm used with NSEC3. DLV processing in these affected versions did not handle unknown signature algorithms correctly. They should have treated data signed with unknown signature algorithms as equivalent to unsigned data, as base DNSSEC does, but instead treated them as a validation failure. This was causing significant operational issues for those DNSSEC early adopters using DLV to validate .gov zones. As a consequence, to avoid service disruption, ISC has temporarily removed the .gov trust anchor from DLV. ISC has generated software patches applicable to BIND versions 9.4.3 and 9.5.1 which correct the resolution behavior. These patches can be downloaded from: ftp://ftp.isc.org/isc/bind9/9.4.3-P2/bind-9.4.3-P2.tar.gz ftp://ftp.isc.org/isc/bind9/9.5.1-P2/bind-9.5.1-P2.tar.gz PGP signatures and Windows binary kits for these patches are in the usual places, see the individual release announcements for details. DLV users running versions of BIND prior to 9.4 are recommended to upgrade, or to contact ISC for assistance. ISC is also conducting beta trials of the latest BIND release, 9.6.1. Note: Although 9.6.0 has the same error handling for unknown algorithms as the prior versions, the problem will not be triggered as native support for NSEC3-signed zones is included. Early adopters wishing to run fully patched BIND 9.6.1 code should run the latest beta release version: ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz In order to give BIND DLV users time to upgrade their resolvers to these fixed versions, ISC is suspending addition of the .gov DNSSEC trust anchor in DLV until 1st May 2009. From that date onwards it is assumed that all DLV users will be running BIND versions amended with the above patch, and that .gov and other zones with all possible signature algorithms will be present in DLV, which will only be supported for resolvers with the correct behavior as per this patch. Note also that this problem only manifests itself for dynamic trust anchor lookups via services such as DLV, and there are no issues for statically configured trust anchors, even with unknown signature algorithms. DNSSEC users who wish to validate .gov and other NSEC3-signed zones prior to 1st May are recommended to statically add these trust anchors to their configuration meantime. Finally, BIND users who do not use DLV, or do not use DNSSEC at all, are not affected by this issue, and may continue to run their existing BIND release without any concerns. DNSSEC, while an essential tool for securing the future of the Internet, is very much in an early adoption phase, and it is to be expected that bootstrap tools such as DLV may encounter some operational glitches as deployment experience is gathered. This is an issue for DLV service users only, and not in any way a shortcoming in the DNSSEC architecture. We would like to thank members of the DNSSEC early adopter community (and in particular Michael Sinatra of UC Berkeley) for bringing this issue to our attention, and commend GSA as operators of the .gov zone, with the assistance of NIST, for aggressively deploying DNSSEC technologies. It is only through such early deployment and co-operation that lessons can be learned for the successful problem-free deployment of DNSSEC in the longer term. Keith Mitchell ISC Director of Engineering ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: zone reload questions
2009/3/21 Mark Andrews mark_andr...@isc.org: Named records modification times of masterfiles and only reloads those that are *newer* than the recorded modification time. Thanks. That help me understand for the case. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
