Re: Notify message from slaves

[Matus UHLAR - fantomas]

On 03.03.10 09:41, Fuat Demir (Garanti Teknoloji) wrote:
> I checked notify messages but in also-notify setting for a specific zone
> does not have any public IP address like 1.1.1.1 or 1.1.1.2...

did you check whole file, includes, etc?

-- 
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.
Linux - It's now safe to turn on your computer.
Linux - Teraz mozete pocitac bez obav zapnut.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notify message from slaves

[Matus UHLAR - fantomas]

Hello,

please configure your mailer to wrap lines below 80 characters per line.
72 to 75 is usually OK.

Thank you.

On 03.03.10 09:27, Fuat Demir (Garanti Teknoloji) wrote:
> "Notify no"  statement is in my global conigurations in named.conf under
> options tab.

did you:

> check all notify settings in config file. Maybe the one you see is not the
> one that applies.

as I advised you before?


-- 
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.
- Holmes, what kind of school did you study to be a detective?
- Elementary, Watson.  -- Daffy Duck & Porky Pig
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Notify message from slaves

[Fuat Demir (Garanti Teknoloji)]

Hello 

It is like below, 


options {
Bla
Bla
Bla
notify no;
Bla
Bla
bla
}; 


I checked notify messages but in also-notify setting for a specific zone does 
not have any public IP address like 1.1.1.1 or 1.1.1.2...


-Original Message-
From: Fuat Demir (Garanti Teknoloji) 
Sent: Wednesday, March 03, 2010 9:28 AM
To: 'Matus UHLAR - fantomas'; bind-users@lists.isc.org
Subject: RE: Notify message from slaves


Hello, 

"Notify no"  statement is in my global conigurations in named.conf under 
options tab. 


-Original Message-
From: bind-users-bounces+fuatd=garanti.com...@lists.isc.org 
[mailto:bind-users-bounces+fuatd=garanti.com...@lists.isc.org] On Behalf Of 
Matus UHLAR - fantomas
Sent: Tuesday, March 02, 2010 4:00 PM
To: bind-users@lists.isc.org
Subject: Re: Notify message from slaves

Hello,

please configure your mailer to wrap lines below 80 characters per line.
72 to 75 is usually OK.

Thank you.

On 02.03.10 14:02, Fuat Demir (Garanti Teknoloji) wrote:
> I have 2 slave 1 master server.
> master is located in different subnet from the slaves.
> Lets say, 10.1.1.1 (ns1) and 10.1.1.2 (ns2) are the real ip addresses of the 
> slaves which have public NAT address for allowing queries from internet for 
> authoritive zones. These public address lets say 1.1.1.1 (ns1) and 1.1.1.2 
> (ns2).
> In conf file of slaves i have a statement that "notify no".

where? in the options {} statement? in the view {} statements? Or in the zone 
{} statement for xxx.com?

> When i configured conf file and reconfigure in slaves, i see transfer 
> logs like this,
> 
> in the xfer log of ns1, it says "notify: info: client 1.1.1.2#25998: received 
> notify for zone 'xxx.com'
> 
> in the xfer log of ns2, it says "notify: info: client 1.1.1.1#25998: received 
> notify for zone 'xxx.com'
> 
> Please note that, ns1 recieves notify form the public address of ns2 and ns2 
> recieves notify from the public address of ns1.
> In both slave server, domain names for ns1 and ns2 are the public addresses 
> of itselves.

check all notify settings in config file. Maybe the one you see is not the one 
that applies.
--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the message confidential. 
The sender has no responsibility for the accuracy or correctness of the 
information in the message and its attachments. Our company shall have no 
liability for any changes or late receiving, loss of integrity and 
confidentiality, viruses and any damages caused in anyway to your computer 
system.  

Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve 
gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi 
halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi 
zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan 
bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin 
herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin 
size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin 
korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi 
herhangi bir zarardan sorumlu tutulamaz.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Notify message from slaves

[Fuat Demir (Garanti Teknoloji)]

Hello, 

"Notify no"  statement is in my global conigurations in named.conf under 
options tab. 




-Original Message-
From: bind-users-bounces+fuatd=garanti.com...@lists.isc.org 
[mailto:bind-users-bounces+fuatd=garanti.com...@lists.isc.org] On Behalf Of 
Matus UHLAR - fantomas
Sent: Tuesday, March 02, 2010 4:00 PM
To: bind-users@lists.isc.org
Subject: Re: Notify message from slaves

Hello,

please configure your mailer to wrap lines below 80 characters per line.
72 to 75 is usually OK.

Thank you.

On 02.03.10 14:02, Fuat Demir (Garanti Teknoloji) wrote:
> I have 2 slave 1 master server.
> master is located in different subnet from the slaves.
> Lets say, 10.1.1.1 (ns1) and 10.1.1.2 (ns2) are the real ip addresses of the 
> slaves which have public NAT address for allowing queries from internet for 
> authoritive zones. These public address lets say 1.1.1.1 (ns1) and 1.1.1.2 
> (ns2).
> In conf file of slaves i have a statement that "notify no".

where? in the options {} statement? in the view {} statements? Or in the zone 
{} statement for xxx.com?

> When i configured conf file and reconfigure in slaves, i see transfer 
> logs like this,
> 
> in the xfer log of ns1, it says "notify: info: client 1.1.1.2#25998: received 
> notify for zone 'xxx.com'
> 
> in the xfer log of ns2, it says "notify: info: client 1.1.1.1#25998: received 
> notify for zone 'xxx.com'
> 
> Please note that, ns1 recieves notify form the public address of ns2 and ns2 
> recieves notify from the public address of ns1.
> In both slave server, domain names for ns1 and ns2 are the public addresses 
> of itselves.

check all notify settings in config file. Maybe the one you see is not the one 
that applies.
--
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the message confidential. 
The sender has no responsibility for the accuracy or correctness of the 
information in the message and its attachments. Our company shall have no 
liability for any changes or late receiving, loss of integrity and 
confidentiality, viruses and any damages caused in anyway to your computer 
system.  

Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve 
gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi 
halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi 
zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan 
bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin 
herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin 
size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin 
korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi 
herhangi bir zarardan sorumlu tutulamaz.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

PKCS#11 engine implementation

[Nikolay Elenkov]

Hi,

I've a few question about the PKCS#11 support in BIND 9.7, specifically the
OpenSSL engine implementation. Is this the right place to ask? There appears to
be no bind-dev mailing list.

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: socket.c:4524: unexpected error in BIND 9.4.3 P3

[Mark Andrews]

In message <1d8c9a4471119a40bd574f9d8d464ae30ea85...@xch60ykf.rim.net>, "Todd S
nyder" writes:
> Good day,
> 
> We've started seeing this bug on a couple servers, but I see no mention
> of it being fixed, so I don't know what version I should upgrade to.
> Nor can I find anything that lays out the impact/risk of this.
> 
> Does anyone know the status of this bug?
> 
> Thanks!

It will most probably be someone publishing a link local IPv6 address
in the DNS for a nameserver.  connect() fails as it is missing
scoping information.

Mark

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

Re: The thread is dead?

[Doug Barton]

On 3/2/2010 8:38 AM, donovan jeffrey j wrote:
> 
> On Jan 14, 2010, at 8:43 AM, pollex wrote:
> 
>> I do not see any activity in the thread... is everyone on holidays?
>>
>> Regards
> 
> nope not dead just sleeping :)


... pining for the fjords.


-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SERVFAIL for some domains on some servers

[Mark Andrews]

In message <4b8ce12b.4010...@imag.fr>, Oliver Henriot writes:
> but nothing shows up when carrying out the failed request. I even tried=20
> debug level and it gave nothing when I did :
> 
> dig www.labanquepostale.fr @129.88.30.10
> 
> ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>>=20
> www.labanquepostale.fr @129.88.30.10
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35429
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;www.labanquepostale.fr.IN  A
> 
> ;; Query time: 1513 msec
> ;; SERVER: 129.88.30.10#53(129.88.30.10)
> ;; WHEN: Tue Mar  2 10:51:46 2010
> ;; MSG SIZE  rcvd: 40
> 
> 
> Thanks for your help (et pour votre travail sur le DNS en g=E9n=E9ral).
> 
> Best regards,
> 
> Oliver

Having the actual domain that is failing is a great help in isolating
the problem.

My bet is that you have the query source port fixed to 53 in your
nameserver (which is a bad idea for a number of reasons) and the
administrators of www.labanquepostale.fr have stupid firewall
settings which blocks packets *from* port 53.  Both ends are
misconfigured.

[postmas...@labanquepostale.fr]
When you are running a service you shouldn't care what port the request
comes from.  For DNS in particular there are still lots of nameservers
configured to send traffic from port 53 as it only required 1 entry
in stateless firewall configuration.

A tcpdump with the source port forced to 53.  Note there is no reply traffic.

08:54:18.517985 211.30.172.21.53 > 83.206.67.133.53:  40497 [1au] A? 
www.labanquepostale.fr. ar: OPT UDPsize=2048,DO=1 (51)
08:54:23.531571 211.30.172.21.53 > 83.206.67.133.53:  40497 [1au] A? 
www.labanquepostale.fr. ar: OPT UDPsize=2048,DO=1 (51)
08:54:28.556952 211.30.172.21.53 > 83.206.67.133.53:  40497 [1au] A? 
www.labanquepostale.fr. ar: OPT UDPsize=2048,DO=1 (51)

A tcpdump with letting the OS choose the source port (60883).  Note there
is reply traffic.

08:57:00.931448 211.30.172.21.60883 > 83.206.67.133.53:  36854 [1au] A? 
www.labanquepostale.fr. ar: OPT UDPsize=2048,DO=1 (51)
08:57:01.261648 83.206.67.133.53 > 211.30.172.21.60883:  36854*- 1/2/3 
A[|domain]

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

Re: socket.c:4524: unexpected error in BIND 9.4.3 P3

[Todd Snyder]

Good day,

We've started seeing this bug on a couple servers, but I see no mention
of it being fixed, so I don't know what version I should upgrade to.
Nor can I find anything that lays out the impact/risk of this.

Does anyone know the status of this bug?

Thanks!



From: bind-users-boun...@lists.isc.org

To: 
Date: Jul 31 2009 - 7:49pm

I have just reported this bug. Ticket number is [ISC-Bugs #20030].

Regards,

Vu

On Sat, Aug 1, 2009 at 4:06 AM, Paul E
wrote:
>
> Le Vu,
>
> lev> BTW, what can I do to help debugging this problem? If it doesn't
> lev> involve with programming I will try.
>
> Submit this to ISC by emailing bind9-b...@isc.org.
>
> Thanks!
> ___
> 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: SERVFAIL for some domains on some servers

[Oliver Henriot]

Dear Kevin,

Dans sa grande sagesse, Kevin Darcy a écrit, le 02/03/2010 20:08 :

1. DNS uses UDP primarily.


My mistake, telnet is not sufficient as a test.

2. The nameservers for labanquepostale.fr appear to be on the same 
subnet. If true, then there are likely to be one or more points of 
failure (e.g. switch, router, WAN link) for the whole zone. What you 
might be seeing are relatively-normal short, temporary outages, which 
become fatal because of poor planning/design. Diversity is good.


Yeah, but that's odd nonetheless as some of my servers always fail (and 
have been doing so for weeks now... oops) whereas others never fail. If 
it were a short temporary outage on their side I'd be getting 
simultaneous failures on all of my servers. The observed failures seem 
more likely to indicate a problem on my network.


Best regards,

Oliver





- Kevin


On 3/2/2010 4:57 AM, Oliver Henriot wrote:

Dear Sten,

I didn't give the domain I'm encountering problems with because it 
seemed irrelevant to me.


As Stéphane Bortzmeyer says in his message of 01/03/10 11:44, it's 
best to give names, so here goes :

x.fr is labanquepostale.fr
"1" is imag.imag.fr
"2" is brahma.imag.fr
"3" is isis.imag.fr
"4" is cosmos.imag.fr

As to a possible firewall problem, how could this be if the servers 
encountering problems don't have any access problems on TCP port 53?


Thanks.

Oliver

Dans sa grande sagesse, Sten Carlsen a écrit, le 27/02/10 19:06 :

Since you don't tell which domain is the problem and at least I get
perfect answers for imag.fr (my only possible guess) from all listed
servers, I can have no clue.

Best guess is still some firewall doing something stupid.


Oliver Henriot wrote:

Dear list users,

Maybe you can help me out here. Please bear with me if I'm stating the
obvious, but my computing skills are scarce and I still have a lot to
learn.

I have a series of name servers, some of which fail to resolve hosts
in other domains whereas others don't have any problem.

My setup is as follows :
- server "1" : master for my domain, recursion disabled for all except
localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
- servers "2", "3" and "4" : slaves for my domain, recusrion allowed
for all, official resolvers for my clients, same configuration on all
3. Setup is DiG 9.3.6-P1 on CentOS 5.4.

Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3"
have no problem (if interrogated locally for "1" of course). The error
I get is :


dig -t A @"2" www.x.fr

;<<>>  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>  -t A @"2" www.x.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.x.fr.IN  A

;; Query time: 4622 msec
;; SERVER: "2"#53("2")
;; WHEN: Sat Feb 27 18:20:07 2010
;; MSG SIZE  rcvd: 40


The behavior is the same for "4" and for any host in domain x.fr (and
the domain itself).

It's not a network problem, I can telnet on port 53 of the name
servers for domain x.fr from "2" (obviously using the ip address as
the name can't be resolved by the server).

Also, reverse queries for hosts in domain x.fr from "2" do not fail.

Finally, even more strange, if I use dig's +trace option servers "2"
and "4" do not fail any more and can resolve www.x.fr (although the
query lags quite a bit when doing the last bit of resolving, from x.fr
to www.x.fr).

Here's the output :

dig www.x.fr @"2" +trace

;<<>>  DiG 9.5.1-P3<<>> www.x.fr @"2" +trace
;; global options:  printcmd
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
;; Received 500 bytes from "2"#53("2") in 2 ms

fr. 172800  IN  NS  E.EXT.NIC.fr.
fr. 172800  IN  NS  B.EXT.NIC.fr.
fr. 172800  IN  NS  F.EXT.NIC.fr.
fr. 172800  IN  NS  A.NIC.fr.
fr. 172800  IN  NS  C.NIC.fr.
fr.

Re: SERVFAIL for some domains on some servers

[Oliver Henriot]

Dear Stan,

Dans sa grande sagesse, Sten Carlsen a écrit, le 02/03/2010 18:43 :

Hi

Seen from here, I get a fast response to dig "labanquepostale.fr".
   

When you query your own servers?
I get a fast response from isis.imag.fr and imag.imag.fr; it's only 
brahma.imag.fr and cosmos.imag.fr who time out.



Using your servers 1 - 4 shows only that they do not answer recursive
queries, that is diferent from my first try but a good change.
   


They only allow recursive queries for clients on our networks. We don't 
have open recursive servers so that's normal.



To have good resolution a nameserver must have access via:
UDP from any local port to remote port 53, it must have the possibility
to use EDNS0 ->  packet size over 512bytes
TCP from any local port to remote port 53.
   


OK, thank you for those important technical precisions. It might indeed 
be a network problem on our side.



Being able to telnet only shows TCP connectivity and only from the port
actually used when trying. UDP is the normal mode of communication.
   


True, telnet to port 53 is a necessary but not a sufficient condition to 
guarantee there is no network problem involved.



A firewall could block any of the above access routes ->  if TCP is open,
you can telnet but it might still block UDP.

Then examples of bad firewall designs have been seen that would modify
packets during transit or truncate them. So there are lots of
possibilities that a firewall can still interfere.

   


OK, thank you for all these indications. I'll investigate our network 
setup in order to ensure that's all OK.


Best regards,

Oliver



Oliver Henriot wrote:
   

Dear Sten,

I didn't give the domain I'm encountering problems with because it
seemed irrelevant to me.

As Stéphane Bortzmeyer says in his message of 01/03/10 11:44, it's
best to give names, so here goes :
x.fr is labanquepostale.fr
"1" is imag.imag.fr
"2" is brahma.imag.fr
"3" is isis.imag.fr
"4" is cosmos.imag.fr

As to a possible firewall problem, how could this be if the servers
encountering problems don't have any access problems on TCP port 53?

Thanks.

Oliver

Dans sa grande sagesse, Sten Carlsen a écrit, le 27/02/10 19:06 :
 

Since you don't tell which domain is the problem and at least I get
perfect answers for imag.fr (my only possible guess) from all listed
servers, I can have no clue.

Best guess is still some firewall doing something stupid.


Oliver Henriot wrote:
   

Dear list users,

Maybe you can help me out here. Please bear with me if I'm stating the
obvious, but my computing skills are scarce and I still have a lot to
learn.

I have a series of name servers, some of which fail to resolve hosts
in other domains whereas others don't have any problem.

My setup is as follows :
- server "1" : master for my domain, recursion disabled for all except
localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
- servers "2", "3" and "4" : slaves for my domain, recusrion allowed
for all, official resolvers for my clients, same configuration on all
3. Setup is DiG 9.3.6-P1 on CentOS 5.4.

Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3"
have no problem (if interrogated locally for "1" of course). The error
I get is :


dig -t A @"2" www.x.fr

;<<>>   DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>   -t A @"2" www.x.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.x.fr.IN  A

;; Query time: 4622 msec
;; SERVER: "2"#53("2")
;; WHEN: Sat Feb 27 18:20:07 2010
;; MSG SIZE  rcvd: 40


The behavior is the same for "4" and for any host in domain x.fr (and
the domain itself).

It's not a network problem, I can telnet on port 53 of the name
servers for domain x.fr from "2" (obviously using the ip address as
the name can't be resolved by the server).

Also, reverse queries for hosts in domain x.fr from "2" do not fail.

Finally, even more strange, if I use dig's +trace option servers "2"
and "4" do not fail any more and can resolve www.x.fr (although the
query lags quite a bit when doing the last bit of resolving, from x.fr
to www.x.fr).

Here's the output :

dig www.x.fr @"2" +trace

;<<>>   DiG 9.5.1-P3<<>>   www.x.fr @"2" +trace
;; global options:  printcmd
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   5

Re: SERVFAIL for some domains on some servers

[Kevin Darcy]

1. DNS uses UDP primarily.
2. The nameservers for labanquepostale.fr appear to be on the same 
subnet. If true, then there are likely to be one or more points of 
failure (e.g. switch, router, WAN link) for the whole zone. What you 
might be seeing are relatively-normal short, temporary outages, which 
become fatal because of poor planning/design. Diversity is good.



- Kevin


On 3/2/2010 4:57 AM, Oliver Henriot wrote:

Dear Sten,

I didn't give the domain I'm encountering problems with because it 
seemed irrelevant to me.


As Stéphane Bortzmeyer says in his message of 01/03/10 11:44, it's 
best to give names, so here goes :

x.fr is labanquepostale.fr
"1" is imag.imag.fr
"2" is brahma.imag.fr
"3" is isis.imag.fr
"4" is cosmos.imag.fr

As to a possible firewall problem, how could this be if the servers 
encountering problems don't have any access problems on TCP port 53?


Thanks.

Oliver

Dans sa grande sagesse, Sten Carlsen a écrit, le 27/02/10 19:06 :

Since you don't tell which domain is the problem and at least I get
perfect answers for imag.fr (my only possible guess) from all listed
servers, I can have no clue.

Best guess is still some firewall doing something stupid.


Oliver Henriot wrote:

Dear list users,

Maybe you can help me out here. Please bear with me if I'm stating the
obvious, but my computing skills are scarce and I still have a lot to
learn.

I have a series of name servers, some of which fail to resolve hosts
in other domains whereas others don't have any problem.

My setup is as follows :
- server "1" : master for my domain, recursion disabled for all except
localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
- servers "2", "3" and "4" : slaves for my domain, recusrion allowed
for all, official resolvers for my clients, same configuration on all
3. Setup is DiG 9.3.6-P1 on CentOS 5.4.

Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3"
have no problem (if interrogated locally for "1" of course). The error
I get is :


dig -t A @"2" www.x.fr

;<<>>  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>  -t A @"2" www.x.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.x.fr.IN  A

;; Query time: 4622 msec
;; SERVER: "2"#53("2")
;; WHEN: Sat Feb 27 18:20:07 2010
;; MSG SIZE  rcvd: 40


The behavior is the same for "4" and for any host in domain x.fr (and
the domain itself).

It's not a network problem, I can telnet on port 53 of the name
servers for domain x.fr from "2" (obviously using the ip address as
the name can't be resolved by the server).

Also, reverse queries for hosts in domain x.fr from "2" do not fail.

Finally, even more strange, if I use dig's +trace option servers "2"
and "4" do not fail any more and can resolve www.x.fr (although the
query lags quite a bit when doing the last bit of resolving, from x.fr
to www.x.fr).

Here's the output :

dig www.x.fr @"2" +trace

;<<>>  DiG 9.5.1-P3<<>>  www.x.fr @"2" +trace
;; global options:  printcmd
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
;; Received 500 bytes from "2"#53("2") in 2 ms

fr. 172800  IN  NS  E.EXT.NIC.fr.
fr. 172800  IN  NS  B.EXT.NIC.fr.
fr. 172800  IN  NS  F.EXT.NIC.fr.
fr. 172800  IN  NS  A.NIC.fr.
fr. 172800  IN  NS  C.NIC.fr.
fr. 172800  IN  NS  G.EXT.NIC.fr.
fr. 172800  IN  NS  D.NIC.fr.
fr. 172800  IN  NS  D.EXT.NIC.fr.
;; Received 444 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 
44 ms


x.fr. 172800  IN  NS  ns1.x.fr.
x.fr. 172800  IN  NS  ns2.x.fr.
;; Received 108 bytes from 193.176.144.6#53(E.EXT.NIC.fr) in 33 ms

www.x.fr. 300 IN  A   xxx.xxx.xxx.xxx
x.fr. 300 IN  NS  ns

Re: SERVFAIL for some domains on some servers

[Sten Carlsen]

Hi

Seen from here, I get a fast response to dig "labanquepostale.fr".

Using your servers 1 - 4 shows only that they do not answer recursive
queries, that is diferent from my first try but a good change.

To have good resolution a nameserver must have access via:
UDP from any local port to remote port 53, it must have the possibility
to use EDNS0 -> packet size over 512bytes
TCP from any local port to remote port 53.

Being able to telnet only shows TCP connectivity and only from the port
actually used when trying. UDP is the normal mode of communication.

A firewall could block any of the above access routes -> if TCP is open,
you can telnet but it might still block UDP.

Then examples of bad firewall designs have been seen that would modify
packets during transit or truncate them. So there are lots of
possibilities that a firewall can still interfere.



Oliver Henriot wrote:
> Dear Sten,
>
> I didn't give the domain I'm encountering problems with because it
> seemed irrelevant to me.
>
> As Stéphane Bortzmeyer says in his message of 01/03/10 11:44, it's
> best to give names, so here goes :
> x.fr is labanquepostale.fr
> "1" is imag.imag.fr
> "2" is brahma.imag.fr
> "3" is isis.imag.fr
> "4" is cosmos.imag.fr
>
> As to a possible firewall problem, how could this be if the servers
> encountering problems don't have any access problems on TCP port 53?
>
> Thanks.
>
> Oliver
>
> Dans sa grande sagesse, Sten Carlsen a écrit, le 27/02/10 19:06 :
>> Since you don't tell which domain is the problem and at least I get
>> perfect answers for imag.fr (my only possible guess) from all listed
>> servers, I can have no clue.
>>
>> Best guess is still some firewall doing something stupid.
>>
>>
>> Oliver Henriot wrote:
>>> Dear list users,
>>>
>>> Maybe you can help me out here. Please bear with me if I'm stating the
>>> obvious, but my computing skills are scarce and I still have a lot to
>>> learn.
>>>
>>> I have a series of name servers, some of which fail to resolve hosts
>>> in other domains whereas others don't have any problem.
>>>
>>> My setup is as follows :
>>> - server "1" : master for my domain, recursion disabled for all except
>>> localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
>>> - servers "2", "3" and "4" : slaves for my domain, recusrion allowed
>>> for all, official resolvers for my clients, same configuration on all
>>> 3. Setup is DiG 9.3.6-P1 on CentOS 5.4.
>>>
>>> Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3"
>>> have no problem (if interrogated locally for "1" of course). The error
>>> I get is :
>>>
>>>
>>> dig -t A @"2" www.x.fr
>>>
>>> ;<<>>  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>  -t A @"2" www.x.fr
>>> ; (1 server found)
>>> ;; global options:  printcmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;www.x.fr.IN  A
>>>
>>> ;; Query time: 4622 msec
>>> ;; SERVER: "2"#53("2")
>>> ;; WHEN: Sat Feb 27 18:20:07 2010
>>> ;; MSG SIZE  rcvd: 40
>>>
>>>
>>> The behavior is the same for "4" and for any host in domain x.fr (and
>>> the domain itself).
>>>
>>> It's not a network problem, I can telnet on port 53 of the name
>>> servers for domain x.fr from "2" (obviously using the ip address as
>>> the name can't be resolved by the server).
>>>
>>> Also, reverse queries for hosts in domain x.fr from "2" do not fail.
>>>
>>> Finally, even more strange, if I use dig's +trace option servers "2"
>>> and "4" do not fail any more and can resolve www.x.fr (although the
>>> query lags quite a bit when doing the last bit of resolving, from x.fr
>>> to www.x.fr).
>>>
>>> Here's the output :
>>>
>>> dig www.x.fr @"2" +trace
>>>
>>> ;<<>>  DiG 9.5.1-P3<<>>  www.x.fr @"2" +trace
>>> ;; global options:  printcmd
>>> .   518400  IN  NS  F.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  G.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  H.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  I.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  J.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  K.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  L.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  M.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  A.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  B.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  C.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  D.ROOT-SERVERS.NET.
>>> .   518400  IN  NS  E.ROOT-SERVERS.NET.
>>> ;; Received 500 bytes from "2"#53("2") in 2 ms
>>>
>>> fr. 172800  IN  NS  E.EXT.NIC.fr.
>>> fr. 172800  IN  NS  B.EXT.NIC.fr.
>>> fr.   

Re: The thread is dead?

[donovan jeffrey j]

On Jan 14, 2010, at 8:43 AM, pollex wrote:


I do not see any activity in the thread... is everyone on holidays?

Regards


nope not dead just sleeping :)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple options{} statements in bind config

[Matus UHLAR - fantomas]

> Matus UHLAR - fantomas wrote:
> > I would now like to have one main config that would include small files
> > containing those statements.
> > 
> > Since listen-on and notify are in options statement; while
> > statistics-channel is a statement of its own, I would like to know, if
> > it's possible to define multiple options {} statements or do I have to
> > include two files.

On 01.03.10 15:25, Cathy Almond wrote:
> No - you can only have one options {}; statement

> > Another question is, can I use master {} as ACL or do I have to define
> > the same IP sets in masters {} and acl {}. Can they at least have the same
> > names?
> 
> I can see what you're thinking if you have only a straightforward list
> of IP addresses in your ACL, but no, this won't work because
> fundamentally the usage/syntax is not the same for both.  A masters list
> is a list of hosts (by IP address) that a slave server might contact to
> refresh a zone whereas an ACL is used for matching purposes (with a
> whole bunch of special syntax options).

I know this difference, I was thinking that masters{} contains ips-only
which, in theory, could be used in ACL (while acl can contain IP range,
which is apparently not imaginable in masters {} statement).

I understand this as the internal structures being so different that using
masters {} in acl {} can't work.

> I believe that you would be able to use the same name twice - once as an
> ACL and once as a masters_list, but it has the potential to cause
> confusion to anyone else reading or updating the configuration.  But you
> should do what's best for your implementation.

That's what I am asking. each of my servers has a few peers I want to
configure them in masters {} and acl {} both. I found defining
peers_acl and peers_masters as a bit redundant while doing a small mistake
in either of them could result to unexpected behaviour (while doing the same
in both would apparently highlight the error).

We've been solving the same problem with other software by defining IPs of
internal/external interfaces and peers as peer1..peerN in /etc/hosts and
configuring hostnames instead of IPs there. BIND doesn't use hosts so I
would invite some kind of #define's (or, using /etc/hosts etc).

-- 
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.
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Shortcut the lookup algorithm *other* than via 'forward' ?

[L. Gabriel Somlo]

Mark,

Thanks much for clearing this up ! I get it now -- the lookup
algorighm is opportunistic, and starts below the root if the right NS
records are already in cache. Having stub zones insures that is always
the case -- very cool !

Also thanks to everyone else who responded !
--Gabriel

On Tue, Mar 02, 2010 at 12:36:49PM +1100, Mark Andrews wrote:
> 
> In message <20100302003617.ga27...@foober.net.cmu.edu>, "L. Gabriel Somlo" 
> writ
> es:
> > Kevin,
> > 
> > > For redundancy, you might want to consider slaving ".local" and 
> > > "example.com" on the remote servers. Note that you don't need to 
> > 
> > Thanks for the reply ! I am slaving and/or stubbing some of our zones
> > in some instances, and redundancy is not what I was concerned about.
> > 
> > I am simply looking for a way to avoid repeating what is already
> > expressed in the data. E.g. primary-auth-server.example.com is master
> > for the zone 'example.local', but not for 'marketing.example.local'.
> > In the master zone file for 'example.local', I have
> > 
> > marketing.example.local NS marketing-auth-svr.example.com
> > 
> > I'd rather not *also* have to maintain a 'marketing.example.local'
> > zone in primary-auth-server's named.conf, be that of type forward,
> > slave, or stub.
> 
> You don't have to.  You just have a stub zone for each internal namespace.
>  
> > When the cache asks primary-auth-server about
> > 'www.marketing.example.local', I want to be able to return the
> > marketing.example.local NS record and let the cache do its thing.
> > 
> > As it is now, the cache either starts at the root (and fails, since
> > it's looking for something.local), or forwards to primary-auth-server
> > (which then must be able to answer the full query, regardless of
> > mechanism -- another forward, slave, or stub), or I have to configure
> > the cache with specific forwards for each subdomain of example.local
> > that is delegated from primary-auth-server, etc.
> 
> Please go re-read what was said in the previous email.  Stub zones do
> what you want if you set them up correctly.
> 
>   zone "local" {
>   type stub;
>   masters {  };
>   forwarders { /* empty */ };
>   file "local.stub";
>   };
> 
> This is be in all the servers that need to see the "local" namespace and
> are not masters or slaves for "local".
> 
> The master of local should be configured to turn off forwarding for the 
> "local"
> namespace if you are using global forwarders.
> 
>   zone "local" {
>   type master;
>   file "local.db";
>   forwarders { /* empty */ };
>   
>   };
> 
> The slaves of local should be configured to turn off forwarding for the 
> "local"
> namespace if you are using global forwarders.
> 
>   zone "local" {
>   type slave;
>   masters {  };
>   file "local.db";
>   forwarders { /* empty */ };
>   
>   };
> 
> > Each scenario requires putting in the same information multiple times:
> > once as delegation NS records, and then again as explicit
> > slave/stub/forward zones in the config file. It is this latter round of
> > duplicated information that I'm trying to avoid having to deal with.
> > 
> > > The "hints" file is a non-starter -- for years now it's been limited to 
> > > only containing root-zone-related information.
> > 
> > Allright, but that was my second question :)
> > 
> > > > Alternatively, I'd also appreciate any insights into why what I'm
> > > > asking for might be a very bad idea and shouldn't be done (or even
> > > > supported at all in BIND) ! :)
> > 
> > And the mechanism itself is of no importance here. I tried adding data
> > to the root hints file (which did not work). I also tried a separate
> > 'type hint' zone only for 'example.local', which bind told me
> > explicitly it's ignoring since it's not '.' :)
> > 
> > For all I care, it could be a variation of the 'type forward', let's
> > call it 'type lean_forward', where the 'lean_forwarders' might just
> > return an NS record and not a full result, and the requesting server
> > would have the responsibility to continue following up with the NS
> > record it received, as though it had started at the root.
> > Using 'type hint' just seemed like the most obvious place to start...
> > 
> > If it's a bad idea, could anyone please explain *why* ? 
> > (I wouldn't mind spending a few days/weeks/whatever on trying to cook
> > up a patch, but I'd hate to waste time if there's a good reason the
> > bind folks hate the idea behind it :) )
> > 
> > Thanks,
> > --Gabriel
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___

Re: Help with logrotate and bind

[Cathy Almond]

bind-sugg...@isc.org ?

I'm not sure how much attention it will get right this moment - it
depends on the persuasiveness of the argument for it, and the number of
folks popping up to say 'yes please, I need it too!'.

But it doesn't on the face of it sound too technically difficult and the
code is already there to 'do the log roll' - it's the control side that
needs more thought and effort (and it would probably have to be
specified by logging channel).

Chris Thompson wrote:
> On Feb 26 2010, Alan Clegg wrote:
> 
>> Diosney Sarmiento Herrera wrote:
>>
>>>I am trying to rotate my named logfile with logrotate and I
>>> configured it as I show:
>>
>> [...]
>>
>> This is much more a question for a list that discusses the logrotate
>> application than it is to bind-users.  I would recommend, however, that
>> you look into the built-in ability of named to roll log files:
>>
>>channel general_log {
>>file "logs/general.log" versions 2 size 2m;
>>severity info;
>>};
>>
>> will keep logs/general.log (current) and a .0 and .1 version of the
>> file, all of 2m in size.  When the primary log exceeds this size,
>> rolling is automatic.
> 
> As it happens, this has become an issue here as well. The context is
> Solaris 10_x86 and "logadm" (rather than Linux "logrotate") but the
> issues are similar.
> 
> We have BIND on our nameservers write notable messages to syslog whose
> files are rotated once a week. However, we also have it write more
> voluminous retrospectively-informative material to files that are
> cycled on size (as above). Some of these (especially query logs) are
> turned on only intermittently as operational requirements dictate.
> 
> Keeping auditors happy apparently requires that we put an upper limit
> on the length of time such logs are retained. (I make no comment on
> the sanity of this.) It isn't at all easy to ensure this with BIND's
> existing facilities. I have determined that it does open the log
> files with O_APPEND, so that one can truncate them while they are
> being written. So I could use logadm's -c option:
> 
> | -c
> | |Rotate the log file by copying  it  and  truncating  the
> |original  logfile  to  zero length, rather than renaming
> |the file.
> 
> (which was apparently invented for cycling the totally crappy Solaris
> cron log file /var/log/cron). But apart from the obvious window for
> losing data, there is also the alarming possibility that BIND might
> decide to cycle the log file for size reasons at the same time that
> logadm does for timing reasons.
> 
> Is there any prospect of BIND providing a rotate-log-file function at
> a particular time, or via rndc command?
> 

___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Notify message from slaves

[Matus UHLAR - fantomas]

Hello,

please configure your mailer to wrap lines below 80 characters per line.
72 to 75 is usually OK.

Thank you.

On 02.03.10 14:02, Fuat Demir (Garanti Teknoloji) wrote:
> I have 2 slave 1 master server.
> master is located in different subnet from the slaves.
> Lets say, 10.1.1.1 (ns1) and 10.1.1.2 (ns2) are the real ip addresses of the 
> slaves which have public NAT address for allowing queries from internet for 
> authoritive zones. These public address lets say 1.1.1.1 (ns1) and 1.1.1.2 
> (ns2).
> In conf file of slaves i have a statement that "notify no".

where? in the options {} statement? in the view {} statements? Or in the
zone {} statement for xxx.com?

> When i configured conf file and reconfigure in slaves, i see transfer logs 
> like this,
> 
> in the xfer log of ns1, it says "notify: info: client 1.1.1.2#25998: received 
> notify for zone 'xxx.com'
> 
> in the xfer log of ns2, it says "notify: info: client 1.1.1.1#25998: received 
> notify for zone 'xxx.com'
> 
> Please note that, ns1 recieves notify form the public address of ns2 and ns2 
> recieves notify from the public address of ns1.
> In both slave server, domain names for ns1 and ns2 are the public addresses 
> of itselves.

check all notify settings in config file. Maybe the one you see is not the
one that applies.
-- 
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.
BSE = Mad Cow Desease ... BSA = Mad Software Producents Desease
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Notify message from slaves

[Fuat Demir (Garanti Teknoloji)]

Hi all,

I have 2 slave 1 master server.
master is located in different subnet from the slaves.
Lets say, 10.1.1.1 (ns1) and 10.1.1.2 (ns2) are the real ip addresses of the 
slaves which have public NAT address for allowing queries from internet for 
authoritive zones. These public address lets say 1.1.1.1 (ns1) and 1.1.1.2 
(ns2).
In conf file of slaves i have a statement that "notify no".
When i configured conf file and reconfigure in slaves, i see transfer logs like 
this,

in the xfer log of ns1, it says "notify: info: client 1.1.1.2#25998: received 
notify for zone 'xxx.com'

in the xfer log of ns2, it says "notify: info: client 1.1.1.1#25998: received 
notify for zone 'xxx.com'

Please note that, ns1 recieves notify form the public address of ns2 and ns2 
recieves notify from the public address of ns1.
In both slave server, domain names for ns1 and ns2 are the public addresses of 
itselves.

And as a result, because i do not wait any notify from the public address of 
ns1 and ns2 (also private address, only waiting notify from the master one), in 
foo these notifications are refused for both.

In my opinion it works like this:
for xxx.com domain, ns1 and ns2 are the NS (lets say ns1.xxx.com and 
ns2.xxx.com)
when i reconfig on slaves, it resolves the public address for xxx.com domain 
and sends notifiaction to this public adddress (1.1.1.1 and 1.1.1.2).
However, it should not send any notification beacuse of notify statement.

slaves and master DNS are BIND 9.6.1-P3.

Does anyone have any idea about this problem ?

Regards,
Fuat




This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the message confidential. 
The sender has no responsibility for the accuracy or correctness of the 
information in the message and its attachments. Our company shall have no 
liability for any changes or late receiving, loss of integrity and 
confidentiality, viruses and any damages caused in anyway to your computer 
system.  

Bu mesaj ve ekleri, mesajda gonderildigi belirtilen kisi/kisilere ozeldir ve 
gizlidir. Bu mesajin muhatabi olmamaniza ragmen tarafiniza ulasmis olmasi 
halinde mesaj iceriginin gizliligi ve bu gizlilik yukumlulugune uyulmasi 
zorunlulugu tarafiniz icin de soz konusudur. Mesaj ve eklerinde yer alan 
bilgilerin dogrulugu ve guncelligi konusunda gonderenin ya da sirketimizin 
herhangi bir sorumlulugu bulunmamaktadir. Sirketimiz mesajin ve bilgilerinin 
size degisiklige ugrayarak veya gec ulasmasindan, butunlugunun ve gizliliginin 
korunamamasindan, virus icermesinden ve bilgisayar sisteminize verebilecegi 
herhangi bir zarardan sorumlu tutulamaz.<>___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: hosts or subnet number in delegation?

[sasa sasa]

could you please point out what is wrong in my delegation?




From: Doug Barton 
To: sasa sasa 
Cc: bind-users@lists.isc.org
Sent: Sat, February 27, 2010 3:10:28 AM
Subject: Re: hosts or subnet number in delegation?

On 02/23/10 23:01, sasa sasa wrote:
> Hello,
> 
> for a 192.168.199.64/26 in zone file to delegate to a customer;
> should i put subnet number:
> 
> 64/26 IN NS ns1.example.com.
> 64/26 IN NS ns2.example.com.
> 
> or host ranges:
> 
> 64-126 IN NS ns1.example.com.
> 64-126 IN NS ns2.example.com.
> 
> .
> .
> $GENERATE 65-126 $ CNAME $.65-126 

I always use the range for several reasons, mostly related to ease of
management. I like to give my zone files the same names as the zones
they represent, and names with / in them require subdirectories. The /
can also require special handling in scripts. Finally the range makes it
very clear exactly what IP addresses are intended to be part of the zone
which cuts down on errors in the parent /24 zone file (especially when
you correctly specify the range, which you did not do above). :)


hth,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/


  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: SERVFAIL for some domains on some servers

[Oliver Henriot]

named restart doesn't solve the problem for me.

Best regards,

Oliver

Dans sa grande sagesse, Cihan Subasi (Garanti Teknoloji) a écrit, le 
01/03/10 10:47 :

We have similar problem with a master with 9.5.1.p3 and 4 slaves with 9.5.2 
p1...We are getting SERVFAIL on slaves occasionally, and we resolve the issue 
with restarting the named. How did you resolve this issue? Or have you resolved 
it? Thank you



-Original Message-
From: bind-users-bounces+cihans=garanti.com...@lists.isc.org 
[mailto:bind-users-bounces+cihans=garanti.com...@lists.isc.org] On Behalf Of 
Oliver Henriot
Sent: Saturday, February 27, 2010 7:52 PM
To: bind-users@lists.isc.org
Subject: SERVFAIL for some domains on some servers

Dear list users,

Maybe you can help me out here. Please bear with me if I'm stating the obvious, 
but my computing skills are scarce and I still have a lot to learn.

I have a series of name servers, some of which fail to resolve hosts in other 
domains whereas others don't have any problem.

My setup is as follows :
- server "1" : master for my domain, recursion disabled for all except 
localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
- servers "2", "3" and "4" : slaves for my domain, recusrion allowed for all, 
official resolvers for my clients, same configuration on all 3.
Setup is DiG 9.3.6-P1 on CentOS 5.4.

Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3" have no problem (if 
interrogated locally for "1" of course). The error I get is :


dig -t A @"2" www.x.fr

;<<>>  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>  -t A @"2" www.x.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.x.fr.IN  A

;; Query time: 4622 msec
;; SERVER: "2"#53("2")
;; WHEN: Sat Feb 27 18:20:07 2010
;; MSG SIZE  rcvd: 40


The behavior is the same for "4" and for any host in domain x.fr (and
the domain itself).

It's not a network problem, I can telnet on port 53 of the name servers
for domain x.fr from "2" (obviously using the ip address as the name
can't be resolved by the server).

Also, reverse queries for hosts in domain x.fr from "2" do not fail.

Finally, even more strange, if I use dig's +trace option servers "2" and
"4" do not fail any more and can resolve www.x.fr (although the query
lags quite a bit when doing the last bit of resolving, from x.fr to
www.x.fr).

Here's the output :

dig www.x.fr @"2" +trace

;<<>>  DiG 9.5.1-P3<<>>  www.x.fr @"2" +trace
;; global options:  printcmd
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
;; Received 500 bytes from "2"#53("2") in 2 ms

fr. 172800  IN  NS  E.EXT.NIC.fr.
fr. 172800  IN  NS  B.EXT.NIC.fr.
fr. 172800  IN  NS  F.EXT.NIC.fr.
fr. 172800  IN  NS  A.NIC.fr.
fr. 172800  IN  NS  C.NIC.fr.
fr. 172800  IN  NS  G.EXT.NIC.fr.
fr. 172800  IN  NS  D.NIC.fr.
fr. 172800  IN  NS  D.EXT.NIC.fr.
;; Received 444 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 44 ms

x.fr. 172800  IN  NS  ns1.x.fr.
x.fr. 172800  IN  NS  ns2.x.fr.
;; Received 108 bytes from 193.176.144.6#53(E.EXT.NIC.fr) in 33 ms

www.x.fr. 300 IN  A   xxx.xxx.xxx.xxx
x.fr. 300 IN  NS  ns2.x.fr.
x.fr. 300 IN  NS  ns1.x.fr.
;; Received 124 bytes from xxx.xxx.xxx.xxx#53(ns1.x.fr) in 0 ms


I'm at a loss as to what's going on (or wrong) here and what I can to do
to solve the problem. Any help would be greatly appreciated.

Thanks in advance.

Oliver


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


This message and attachments are confidential and intended solely for the 
individual(s) stated in this message. If you received this message although you 
are not the addressee, you are responsible to keep the

Re: SERVFAIL for some domains on some servers

[Oliver Henriot]

Dear Sten,

I didn't give the domain I'm encountering problems with because it 
seemed irrelevant to me.


As Stéphane Bortzmeyer says in his message of 01/03/10 11:44, it's best 
to give names, so here goes :

x.fr is labanquepostale.fr
"1" is imag.imag.fr
"2" is brahma.imag.fr
"3" is isis.imag.fr
"4" is cosmos.imag.fr

As to a possible firewall problem, how could this be if the servers 
encountering problems don't have any access problems on TCP port 53?


Thanks.

Oliver

Dans sa grande sagesse, Sten Carlsen a écrit, le 27/02/10 19:06 :

Since you don't tell which domain is the problem and at least I get
perfect answers for imag.fr (my only possible guess) from all listed
servers, I can have no clue.

Best guess is still some firewall doing something stupid.


Oliver Henriot wrote:

Dear list users,

Maybe you can help me out here. Please bear with me if I'm stating the
obvious, but my computing skills are scarce and I still have a lot to
learn.

I have a series of name servers, some of which fail to resolve hosts
in other domains whereas others don't have any problem.

My setup is as follows :
- server "1" : master for my domain, recursion disabled for all except
localhost. Setup is BIND 9.5.1-P2 on SunOS 5.9.
- servers "2", "3" and "4" : slaves for my domain, recusrion allowed
for all, official resolvers for my clients, same configuration on all
3. Setup is DiG 9.3.6-P1 on CentOS 5.4.

Servers "2" and "4" fail to resolve domain x.fr whereas "1" and "3"
have no problem (if interrogated locally for "1" of course). The error
I get is :


dig -t A @"2" www.x.fr

;<<>>  DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2<<>>  -t A @"2" www.x.fr
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.x.fr.IN  A

;; Query time: 4622 msec
;; SERVER: "2"#53("2")
;; WHEN: Sat Feb 27 18:20:07 2010
;; MSG SIZE  rcvd: 40


The behavior is the same for "4" and for any host in domain x.fr (and
the domain itself).

It's not a network problem, I can telnet on port 53 of the name
servers for domain x.fr from "2" (obviously using the ip address as
the name can't be resolved by the server).

Also, reverse queries for hosts in domain x.fr from "2" do not fail.

Finally, even more strange, if I use dig's +trace option servers "2"
and "4" do not fail any more and can resolve www.x.fr (although the
query lags quite a bit when doing the last bit of resolving, from x.fr
to www.x.fr).

Here's the output :

dig www.x.fr @"2" +trace

;<<>>  DiG 9.5.1-P3<<>>  www.x.fr @"2" +trace
;; global options:  printcmd
.   518400  IN  NS  F.ROOT-SERVERS.NET.
.   518400  IN  NS  G.ROOT-SERVERS.NET.
.   518400  IN  NS  H.ROOT-SERVERS.NET.
.   518400  IN  NS  I.ROOT-SERVERS.NET.
.   518400  IN  NS  J.ROOT-SERVERS.NET.
.   518400  IN  NS  K.ROOT-SERVERS.NET.
.   518400  IN  NS  L.ROOT-SERVERS.NET.
.   518400  IN  NS  M.ROOT-SERVERS.NET.
.   518400  IN  NS  A.ROOT-SERVERS.NET.
.   518400  IN  NS  B.ROOT-SERVERS.NET.
.   518400  IN  NS  C.ROOT-SERVERS.NET.
.   518400  IN  NS  D.ROOT-SERVERS.NET.
.   518400  IN  NS  E.ROOT-SERVERS.NET.
;; Received 500 bytes from "2"#53("2") in 2 ms

fr. 172800  IN  NS  E.EXT.NIC.fr.
fr. 172800  IN  NS  B.EXT.NIC.fr.
fr. 172800  IN  NS  F.EXT.NIC.fr.
fr. 172800  IN  NS  A.NIC.fr.
fr. 172800  IN  NS  C.NIC.fr.
fr. 172800  IN  NS  G.EXT.NIC.fr.
fr. 172800  IN  NS  D.NIC.fr.
fr. 172800  IN  NS  D.EXT.NIC.fr.
;; Received 444 bytes from 192.58.128.30#53(J.ROOT-SERVERS.NET) in 44 ms

x.fr. 172800  IN  NS  ns1.x.fr.
x.fr. 172800  IN  NS  ns2.x.fr.
;; Received 108 bytes from 193.176.144.6#53(E.EXT.NIC.fr) in 33 ms

www.x.fr. 300 IN  A   xxx.xxx.xxx.xxx
x.fr. 300 IN  NS  ns2.x.fr.
x.fr. 300 IN  NS  ns1.x.fr.
;; Received 124 bytes from xxx.xxx.xxx.xxx#53(ns1.x.fr) in 0 ms


I'm at a loss as to what's going on (or wrong) here and what I can to
do to solve the problem. Any help would be greatly appreciated.

Thanks in advance.

Oliver


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users






smime.p7s
Description: S/MIME Cryptographic Signature
___
bind-users mailing list
bind-us

Re: SERVFAIL for some domains on some servers

[Oliver Henriot]

Cher Stéphane,

Dans sa grande sagesse, Stephane Bortzmeyer a écrit, le 01/03/10 11:44 :

On Sat, Feb 27, 2010 at 06:51:44PM +0100,
  Oliver Henriot  wrote
  a message of 104 lines which said:


but my computing skills are scarce and I still have a lot to learn.


For instance, that you should always use real names



Thanks for the info. Corrected in my reply to Sten Carlsen's message.
#joke mode on: If you have any questions concerning global tectonics and 
space geodesy, ask me; for computing, ask someone else.#joke mode off





- servers "2", "3" and "4" : slaves for my domain, recusrion allowed for
all, official resolvers for my clients, same configuration on all 3.


Bad setup: you should really completely separate authoritative and
recursive services.


No doubt. As soon as I have the time I'll follow your guidelines 
(http://www.bortzmeyer.org/fermer-les-recursifs-ouverts.html and 
http://www.afnic.fr/actu/nouvelles/general/NN20060404) I read a while ago.





Setup is DiG 9.3.6-P1 on CentOS 5.4.


That's a very old version.


Yes, but it's the one packaged in CentOS and unfortunately I don't have 
the time or the leisure to maintain hand built versions yet.





;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 37397


And the log?


I log severity info (which is pretty general) for these categories :
category default { general-log; default_syslog; };
category security { security-log; default_syslog; };
category config { config-log; default_syslog; };
category client { client-log; default_syslog; };
category config { config-log; default_syslog; };
category client { client-log; default_syslog; };
category notify { notify-log; default_syslog; };
category xfer-in { xfer-log; default_syslog; };
category xfer-out { xfer-log; default_syslog; };
category lame-servers { null; };

(I tried logging lame servers and gave up...)

but nothing shows up when carrying out the failed request. I even tried 
debug level and it gave nothing when I did :


dig www.labanquepostale.fr @129.88.30.10

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> 
www.labanquepostale.fr @129.88.30.10

;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35429
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.labanquepostale.fr.IN  A

;; Query time: 1513 msec
;; SERVER: 129.88.30.10#53(129.88.30.10)
;; WHEN: Tue Mar  2 10:51:46 2010
;; MSG SIZE  rcvd: 40


Thanks for your help (et pour votre travail sur le DNS en général).

Best regards,

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users