date:20090320

Re: zone reload questions

2009-03-20 Thread Ralf Peng

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() {
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 :
> 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

2009-03-20 Thread Bind DNS

On Fri, 20 Mar 2009 15:57:03 +1100
Mark Andrews  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 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: GeoIP like RBLDNS

2009-03-20 Thread Michelle Konzack

Am 2009-03-17 18:05:31, schrieb David Sparks:
> Did you look at this:
> 
> "countries.nerd.dk is NOT a list of spammers, it is an IP-to-country DNS
> mapping service."
> 
> http://countries.nerd.dk/

Yes, I have gotten the tip from the  list and it  is
exactly what I was searching for.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
 Michelle Konzack
   Apt. 917
   50, rue de Soultz
Jabber linux4miche...@jabber.ccc.de   67100 Strasbourg/France
IRC #Debian (irc.icq.com) Tel. DE: +49 177 9351947
ICQ #328449886Tel. FR: +33  6  61925193


signature.pgp
Description: Digital signature
___
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

2009-03-20 Thread Scott Haneda

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

2009-03-20 Thread Chris Dew

-- Forwarded message --
From: Chris Dew 
Date: 2009/3/20
Subject: Re: No name resolution when slave is down
To: "Dennis J." 


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. 

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

2009-03-20 Thread dhottinger

DHCP options not giving both nameservers?  What happens when you  
manually configure your workstation to only query the master?


Quoting "Dennis J." :


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

2009-03-20 Thread Dennis J.


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

Root Server Simulation Communication Problem

2009-03-20 Thread T MANIKANDAN-PKXR74

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

[r...@abc named]# dig 

; <<>> DiG 9.3.4 <<>>
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48035
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;.  IN  NS

;; AUTHORITY SECTION:
.   86400   IN  NS  rootns.man.

;; Query time: 0 msec
;; SERVER: 192.168.10.12#53(192.168.10.12)
;; WHEN: Fri Mar 20 02:16:09 2009
;; MSG SIZE  rcvd: 40

[r...@abc named]# dig abc.com

; <<>> DiG 9.3.4 <<>> abc.com
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65138
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;abc.com.   IN  A

;; ANSWER SECTION:
abc.com.3600IN  A   192.168.10.12

;; AUTHORITY SECTION:
abc.com.3600IN  NS  abc.com.

;; Query time: 0 msec
;; SERVER: 192.168.10.12#53(192.168.10.12)
;; WHEN: Fri Mar 20 02:16:16 2009
;; MSG SIZE  rcvd: 55

[r...@abc named]# 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zone reload questions

2009-03-20 Thread Matus UHLAR - fantomas

On 20.03.09 16:23, Ralf Peng wrote:
> Hmm! I was just thinking this is a BUG!
> 
> I wrote a function in Perl to modify the serial number:
> 
> sub increase_serial {
[...]
> }
> 
> 
> I do below to execute the reload:
> 
> increase_serial();
> system("/usr/local/bind/sbin/rndc reload");

why not "...rndc reload $zone" ?

> OK I run two reload in a second, the serial number was increased
> correctly, but bind only reload zones correctly for the first time.

It mat need some time to reload _all_ zones. 

> This is the system log:
> 
> [the first reload is successful]:
[...]
> 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.

seems so. If you need to do that faster, you should try update or
different mechanism
-- 
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.
Christian Science Programming: "Let God Debug It!".
___
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

2009-03-20 Thread John D. Vo


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

2009-03-20 Thread Carl Fretwell

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

2009-03-20 Thread Ben Bridges

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

2009-03-20 Thread Matus UHLAR - fantomas

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

2009-03-20 Thread Barry Margolin

In article , "John D. Vo"  
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

2009-03-20 Thread Carl Fretwell

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

2009-03-20 Thread Barry Margolin

In article ,
 Carl Fretwell  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: query (cache) 'coriander.plus.com/A/IN' denied

2009-03-20 Thread Jeff Lightner

We had need to continue to have the MX record a domain we acquired point
to an external location.   The MX record was modified and the email
continued to work.  I did see odd lookups in the logs but disregarded
them as they were failures - it looked like the target mail server was
the one trying to query us though I could see no reason for it.  As it
didn't impeded mail flow to/from that target mail server I ignored the
messages.

Earlier this week we changed the MX record back to our mail server but
that was only because we no longer needed to allow access to the
original rather than due to any problem.

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Barry Margolin
Sent: Friday, March 20, 2009 1:07 PM
To: comp-protocols-dns-b...@isc.org
Subject: Re: query (cache) 'coriander.plus.com/A/IN' denied

In article ,
 Carl Fretwell  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

Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential 
information and is for the sole use of the intended recipient(s). If you are 
not the intended recipient, any disclosure, copying, distribution, or use of 
the contents of this information is prohibited and may be unlawful. If you have 
received this electronic transmission in error, please reply immediately to the 
sender that you have received the message in error, and delete it. Thank you.
--
___
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

2009-03-20 Thread John Wobus

Actually, master and slave has little (read "nothing") to do with 
whether the domain resolves.
What's relevant are the delegation records pointing to your domain and 
the authoritative
records for the two servers.  In a normal, straight-forward setup for 
one master and
one slave, both servers would be listed in the authoritative data as 
well as the delegation records
within the delegating zone, and if one server were down, the other 
server could be found

and queried.

John

On Mar 20, 2009, at 7: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?

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

number of zones not matching

2009-03-20 Thread John D. Vo


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

RE: number of zones not matching

2009-03-20 Thread Todd Snyder

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

2009-03-20 Thread John D. Vo


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

2009-03-20 Thread Todd Snyder

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

2009-03-20 Thread John D. Vo





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: zone reload questions

2009-03-20 Thread Mark Andrews


Named records modification times of masterfiles and only
reloads those that are *newer* than the recorded modification
time.  

Changing the zone content without updating the serial will
also cause problems for slaves.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: number of zones not matching

2009-03-20 Thread Mark Andrews


In message <49c3f591.1090...@eagle.net>, "John D. Vo" writes:
> --===8258205717685425773==
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> 
> 
> 
>   
> 
> 
> 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:
>   cite="mid:1d8c9a4471119a40bd574f9d8d464ae304bd4...@xch60ykf.rim.net"
>  type="cite">
>   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 [mailto:j...@eagle.net
> ">mailto:j...@eagle.net] 
> Sent: Friday, March 20, 2009 3:27 PM
> To: Todd Snyder
> Cc: mailto:bind-users@lists.isc.org
> ">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 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 > 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: mailto:bind-users-boun...@lis
> ts.isc.org">bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.o
> rg">mailto:bind-users-boun...@lists.isc.org] On Behalf Of John D. Vo
> Sent: Friday, March 20, 2009 3:15 PM
> To: mailto:bind-users@lists.isc.org
> ">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
>  href="mailto:j...@eagle.net";>j...@eagle.net
> 
> Office: (212) 200-2000 Ext. 105
> Cell: (212) 200-3016
> 
> ---
> 
> 
> ___
> bind-users mailing list
> mailto:bind-users@lists.isc.org";>bi
> nd-us...@lists.isc.org
> https://lists.isc.org/mailman/listinfo
> /bind-users">https://lists.isc.org/mailman/listinfo/bind-users
> 
> -
> This transmission (including any attachments) may contain confidential
> 
>   
>   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.
>   
>   
>   
> 
>   
>   
> 
> --
> 
> 
> Best Regards,
> 
> John D. Vo
> Eagle Teleconferencing Services, Inc.
> Network-System Administrator
>  href="mailto:j...@eagle.net";>j...@eagle.net
> 
> 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 privileges), or constitute non-public information. Any 
> use of this information by anyone other than the intended recipient is prohib
> ited. If you have received this transmission in error, please immediately rep
> ly to the sender and delete this information from your system. Use, dissemina
> tion, distribution, or reproduction of this transmission by unintended recipi
> ents is not authorized and may be unlawful.
>   
> 
> 
> 
> -- 
> 
> 
> Best Regards,
> 
> John D. Vo
> Eagle Teleconferencing Services, Inc.
> Network-System Administrator
>  href

RE: number of zones not matching

2009-03-20 Thread Todd Snyder

>   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

ISC BIND 9.6.1b1 is now available

2009-03-20 Thread Evan Hunt


BIND 9.6.1 Beta 1 is now available.

BIND 9.6.1b1 is a beta maintenance release for BIND 9.6.

BIND 9.6.1b1 can be downloaded from

ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz

The PGP signature of the distribution is at

ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/bind-9.6.1b1.tar.gz.sha512.asc

The signature was generated with the ISC public key, which is
available at .

A binary kit for Windows XP, Windows 2003 and Windows 2008 is at

ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.zip
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.debug.zip

The PGP signature of the binary kit is at

ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.zip.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.zip.sha512.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.debug.zip.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.debug.zip.sha256.asc
ftp://ftp.isc.org/isc/bind9/9.6.1b1/BIND9.6.1b1.debug.zip.sha512.asc

Changes since 9.6.0:

--- 9.6.1b1 released ---

2577.   [doc]   Clarified some statistics counters. [RT #19454]

2576.   [bug]   NSEC record were not being correctly signed when
a zone transitions from insecure to secure.
Handle such incorrectly signed zones. [RT #19114]

2574.   [doc]   Document nsupdate -g and -o. [RT #19351]

2573.   [bug]   Replacing a non-CNAME record with a CNAME record in a
single transaction in a signed zone failed. [RT #19397]

2568.   [bug]   Report when the write to indicate a otherwise
successful start fails. [RT #19360]

2567.   [bug]   dst__privstruct_writefile() could miss write errors.
write_public_key() could miss write errors.
dnssec-dsfromkey could miss write errors.
[RT #19360]

2564.   [bug]   Only take EDNS fallback steps when processing timeouts.
[RT #19405]

2563.   [bug]   Dig could leak a socket causing it to wait forever
to exit. [RT #19359]

2561.   [doc]   Add isc-config.sh(1) man page. [RT #16378]

2560.   [bug]   Add #include  to iptable.c. [RT #18258]

2559.   [bug]   dnssec-dsfromkey could compute bad DS records when
reading from a K* files.  [RT #19357]

2557.   [cleanup]   PCI compliance:
* new libisc log module file
* isc_dir_chroot() now also changes the working
  directory to "/".
* additional INSISTs
* additional logging when files can't be removed.

2556.   [port]  Solaris: mkdir(2) on tmpfs filesystems does not do the
error checks in the correct order resulting in the
wrong error code sometimes being returned. [RT #19249]

2554.   [bug]   Validation of uppercase queries from NSEC3 zones could
fail. [RT #19297]

2553.   [bug]   Reference leak on DNSSEC validation errors. [RT #19291]

2552.   [bug]   zero-no-soa-ttl-cache was not being honoured.
[RT #19340]

2551.   [bug]   Potential Reference leak on return. [RT #19341]

2550.   [bug]   Check --with-openssl= finds .
[RT #19343]

2549.   [port]  linux: define NR_OPEN if not currently defined.
[RT #19344]

2548.   [bug]   Install iterated_hash.h. [RT #19335]

2547.   [bug]   openssl_link.c:mem_realloc() could reference an
out-of-range area of the source buffer.  New public
function isc_mem_reallocate() was introduced to address
this bug. [RT #19313]

2545.   [doc]   ARM: Legal hostname checking (check-names) is
for SRV RDATA too. [RT #19304]

2544.   [cleanup]   Removed unused structure members in adb.c. [RT #19225]

2543.   [contrib]   Update contrib/zkt to version 0.98. [RT #19113]

2542.   [doc]   Update the description of dig +adflag. [RT #19290]

2541.   [bug]   Conditionally update dispatch manager statistics.
[RT #19247]

2539.   [security]  Update the interaction between recursion, allow-query,
allow-query-cache and allow-recursion.  [RT #19198]

2538.   [bug]   cache/ADB memory could grow over max-cache-size,
especially with threads and

Re: query (cache) 'coriander.plus.com/A/IN' denied

2009-03-20 Thread Ronan Flood

Barry Margolin  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 
___
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

2009-03-20 Thread Evan Hunt


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 .

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

2009-03-20 Thread Evan Hunt


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 .

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

2009-03-20 Thread Sue Graves

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-03-20 Thread Ralf Peng

2009/3/21 Mark Andrews :
>
>        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

Re: zone reload questions

Re: No A Record for NS

Re: GeoIP like RBLDNS

Re: No name resolution when slave is down

Fwd: No name resolution when slave is down

Re: No name resolution when slave is down

No name resolution when slave is down

Root Server Simulation Communication Problem

Re: zone reload questions

zone transfer from slave to master not working

BIND 9.6.0-P1

RE: Root Server Simulation Communication Problem

Re: zone transfer from slave to master not working

Re: zone transfer from slave to master not working

query (cache) 'coriander.plus.com/A/IN' denied

Re: query (cache) 'coriander.plus.com/A/IN' denied

RE: query (cache) 'coriander.plus.com/A/IN' denied

Re: No name resolution when slave is down

number of zones not matching

RE: number of zones not matching

Re: number of zones not matching

RE: number of zones not matching

Re: number of zones not matching

Re: zone reload questions

Re: number of zones not matching

RE: number of zones not matching

ISC BIND 9.6.1b1 is now available

Re: query (cache) 'coriander.plus.com/A/IN' denied

ISC BIND 9.5.1-P2 is now available

ISC BIND 9.4.3-P2 is now available

ISC Security patch for BIND users of DLV

Re: zone reload questions

32 matches

Site Navigation

Mail list logo

Footer information