date:20090507

Re: tcp versus udp

2009-05-07 Thread Sam Wilson

In article ,
 Barry Margolin  wrote:

> In article ,
>  Sam Wilson  wrote:
> 
> > In article , Mark Elkins  
> > wrote:
> > 
> > > One place that TCP may make sense - if you are involved in a registry
> > > system and the process involves actually checking the information that
> > > you are given, including nameservers (do they exist, do they serve that
> > > zone - correctly?) - it may make a lot of sense to do TCP Digs for the
> > > information (though that should probably be after a failed UDP dig - as
> > > a number of people do insist on disallowing Port 53 TCP).
> > 
> > If the registry is testing for compliant servers then a failed TCP query 
> > should flag the server as non-working, as would a failed UDP query.
> 
> DNS servers MUST support UDP, and only SHOULD support TCP.  So a failed 
> TCP query should not flag the server as non-working.

You're right of course - my apologies.  A failed TCP query should flag 
the server as not supporting TCP queries, with reference to RFC 1123 
sections 6.1.3.2 and 1.3.2.  The registrar may or may not wish to 
comment on the advisability of that.  

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

Delegation not working

2009-05-07 Thread Mike Bernhardt

I attempted to delegate a subdomain last night, but it didn't work. When I
slave that subdomain it works fine, so I know that connectivity is not the
problem. The server is running BIND 9.3.4. Here is the dig response:

; <<>> DiG 9.3.4 <<>> +norec @athena adm.bart.gov NS
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57085
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;adm.bart.gov.  IN  NS

;; AUTHORITY SECTION:
adm.bart.gov.   14400   IN  NS  mrep-02.adm.bart.gov.
adm.bart.gov.   14400   IN  NS  dhcp-01.adm.bart.gov.

;; ADDITIONAL SECTION:
dhcp-01.adm.bart.gov.   14400   IN  A   148.165.126.87
mrep-02.adm.bart.gov.   14400   IN  A   10.2.242.222

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Wed May  6 22:52:25 2009
;; MSG SIZE  rcvd: 106

So it seems we are reading the delegation info correctly, but not getting
answers, or perhaps not asking? Here is my named.conf, and the db records.
Since I'm using h2n, the delegation info in the db files is actually via
$include statements pointing at spcl files. I know the $includes are read
properly because there is other info in them that works.

We are forwarding for internet names to our outside-facing server. I'm
wondering if forwarding is the problem? I was unable to experiment with
removing this as it's a production system.

***named.conf***
options {
directory "/var/named";
query-source address 148.165.30.30 port 53;
forwarders { 148.165.3.10; };
forward only;
allow-transfer { 148.165.7.200; 148.165.126.87; 10.2.242.222; };
transfer-source 148.165.30.30;
notify-source 148.165.30.30;
recursive-clients 2000;
zone-statistics yes;
};

zone "bart.gov" {
type master;
file "db.bart";
};

zone "165.148.in-addr.arpa" {
type master;
file "db.148.165";
};

zone "." {
type hint;
file "db.cache";
);


***db.bart***
$TTL 4H
@   SOA athena bernhardt ( 2009050701 4H 10M 1w3d 10M )
NS  athena
NS  Apollo
admIN  NS  dhcp-01.adm.bart.gov.
   IN  NS  mrep-02.adm.bart.gov.
dhcp-01.adm.bart.gov.  IN  A   148.165.126.87
mrep-02.adm.bart.gov.  IN  A   10.2.242.222

***db.10***
$TTL 4H
@   SOA athena.bart.gov. bernhardt.bart.gov. ( 2009050701 4H 10M
1w3d 10M )
NS  athena.bart.gov.
NS  apollo.bart.gov.
$GENERATE   0-127 $.10 NS   dhcp-01.adm.bart.gov.
$GENERATE   0-127 $.10 NS   mrep-02.adm.bart.gov.

Assistance appreciated!

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

Re: Delegation not working

2009-05-07 Thread Chris Buxton


On May 7, 2009, at 9:31 AM, Mike Bernhardt wrote:
I attempted to delegate a subdomain last night, but it didn't work.  
When I
slave that subdomain it works fine, so I know that connectivity is  
not the

problem. The server is running BIND 9.3.4. Here is the dig response:

;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2


Note: no "rd" flag.


;; AUTHORITY SECTION:
adm.bart.gov.   14400   IN  NS  mrep-02.adm.bart.gov.
adm.bart.gov.   14400   IN  NS  dhcp-01.adm.bart.gov.


This is a referral, as expected.

So it seems we are reading the delegation info correctly, but not  
getting

answers, or perhaps not asking?


What were you expecting to be different? You sent a non-recursive  
query (+norec) and received a referral to the child zone. It looks  
perfectly normal.


Were you expecting a final answer to the query? If so, then take out  
the "+norec" from your dig command. You'll also need to edit your  
bart.gov zone statement in named.conf (below).



Here is my named.conf, and the db records.
Since I'm using h2n, the delegation info in the db files is actually  
via
$include statements pointing at spcl files. I know the $includes are  
read

properly because there is other info in them that works.

We are forwarding for internet names to our outside-facing server. I'm
wondering if forwarding is the problem?


If you had not used "+norec", it would be the problem, yes. But there  
is a simple solution.



zone "bart.gov" {
   type master;
   file "db.bart";
};


Add one more statement inside the zone statement block:

forwarders { };

This will turn off forwarding for the bart.gov domain, which is larger  
than the bart.gov zone. It includes delegated subzones such as  
"adm.bart.gov", meaning the server will recurse to the subzone rather  
than forwarding to the outside world.


Chris Buxton
Professional Services
Men & Mice

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

Yeah, I pulled that dig request from another post that sounded similar
without taking the time to understand what the arguments meant. I will have
to learn dig properly.

Thanks for the help, I will try that tonight.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 10:17 AM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 9:31 AM, Mike Bernhardt wrote:
> I attempted to delegate a subdomain last night, but it didn't work.  
> When I
> slave that subdomain it works fine, so I know that connectivity is  
> not the
> problem. The server is running BIND 9.3.4. Here is the dig response:
>
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

Note: no "rd" flag.

> ;; AUTHORITY SECTION:
> adm.bart.gov.   14400   IN  NS  mrep-02.adm.bart.gov.
> adm.bart.gov.   14400   IN  NS  dhcp-01.adm.bart.gov.

This is a referral, as expected.

> So it seems we are reading the delegation info correctly, but not  
> getting
> answers, or perhaps not asking?

What were you expecting to be different? You sent a non-recursive  
query (+norec) and received a referral to the child zone. It looks  
perfectly normal.

Were you expecting a final answer to the query? If so, then take out  
the "+norec" from your dig command. You'll also need to edit your  
bart.gov zone statement in named.conf (below).

> Here is my named.conf, and the db records.
> Since I'm using h2n, the delegation info in the db files is actually  
> via
> $include statements pointing at spcl files. I know the $includes are  
> read
> properly because there is other info in them that works.
>
> We are forwarding for internet names to our outside-facing server. I'm
> wondering if forwarding is the problem?

If you had not used "+norec", it would be the problem, yes. But there  
is a simple solution.

> zone "bart.gov" {
>type master;
>file "db.bart";
> };

Add one more statement inside the zone statement block:

forwarders { };

This will turn off forwarding for the bart.gov domain, which is larger  
than the bart.gov zone. It includes delegated subzones such as  
"adm.bart.gov", meaning the server will recurse to the subzone rather  
than forwarding to the outside world.

Chris Buxton
Professional Services
Men & Mice

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

In order to test without killing important things, I have delegated a
reverse zone only. I made the suggesed change but still have the same issue.
Clearly the server is not following the delegation. Config files follow. Any
ideas?

dig -x +trace @athena 10.0.2.252
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 18117
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;+trace.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
in-addr.arpa.   10061   IN  SOA A.ROOT-SERVERS.NET.
dns-ops.ARIN.NET. 2009050704 1800 900 691200 10800

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 11:39:49 2009
;; MSG SIZE  rcvd: 104


; <<>> DiG 9.3.4 <<>> -x +trace @athena 10.0.2.252
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39199
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;10.0.2.252.IN  A

;; AUTHORITY SECTION:
.   10299   IN  SOA A.ROOT-SERVERS.NET.
NSTLD.VERISIGN-GRS.COM. 2009050700 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 11:39:49 2009
;; MSG SIZE  rcvd: 103

My named.conf is now:
options {
directory "/var/named";
query-source address 148.165.30.30 port 53;
forwarders { 148.165.3.10; };
forward only;
allow-transfer { 148.165.7.200; 148.165.126.87; 10.2.242.222; };
transfer-source 148.165.30.30;
notify-source 148.165.30.30;
recursive-clients 2000;
zone-statistics yes;
};

zone "bart.gov" {
type master;
file "db.bart";
forwarders { };
};

zone "10.in-addr.arpa" {
type master;
file "db.10";
forwarders { };

The zone db.10 still contains:
$TTL 4H
@   SOA athena.bart.gov. bernhardt.bart.gov. ( 2009050701 4H 10M
1w3d 10M )
NS  athena.bart.gov.
NS  apollo.bart.gov.
$GENERATE   0-127 $.10 NS   dhcp-01.adm.bart.gov.
$GENERATE   0-127 $.10 NS   mrep-02.adm.bart.gov.

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

Re: Delegation not working

2009-05-07 Thread Chris Buxton


On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:

dig -x +trace @athena 10.0.2.252

;; QUESTION SECTION:
;+trace.in-addr.arpa.   IN  PTR

;; QUESTION SECTION:
;10.0.2.252.IN  A


You've given dig the wrong arguments. You gave it two queries,  
indicated above, neither of which is what you wanted.


Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

I had already tried that to no avail:
dig @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.600 IN  SOA athena.bart.gov.
bernhardt.bart.gov. 2009050703 14400 600 864000 600

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 12:21:13 2009
;; MSG SIZE  rcvd: 102



-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
> dig -x +trace @athena 10.0.2.252
>
> ;; QUESTION SECTION:
> ;+trace.in-addr.arpa.   IN  PTR
>
> ;; QUESTION SECTION:
> ;10.0.2.252.IN  A

You've given dig the wrong arguments. You gave it two queries,  
indicated above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

Reformatting the dig request gives the following:

dig +trace @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> +trace @athena -x 10.0.2.252
; (1 server found)
;; global options:  printcmd
.   163824  IN  NS  K.ROOT-SERVERS.NET.
.   163824  IN  NS  L.ROOT-SERVERS.NET.
.   163824  IN  NS  M.ROOT-SERVERS.NET.
.   163824  IN  NS  A.ROOT-SERVERS.NET.
.   163824  IN  NS  B.ROOT-SERVERS.NET.
.   163824  IN  NS  C.ROOT-SERVERS.NET.
.   163824  IN  NS  D.ROOT-SERVERS.NET.
.   163824  IN  NS  E.ROOT-SERVERS.NET.
.   163824  IN  NS  F.ROOT-SERVERS.NET.
.   163824  IN  NS  G.ROOT-SERVERS.NET.
.   163824  IN  NS  H.ROOT-SERVERS.NET.
.   163824  IN  NS  I.ROOT-SERVERS.NET.
.   163824  IN  NS  J.ROOT-SERVERS.NET.

;; Received 500 bytes from 148.165.30.30#53(148.165.30.30) in 0 ms

;; connection timed out; no servers could be reached
Since this server can't reach the root servers, this makes sense. But
apparently it isn't following delegation.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
> dig -x +trace @athena 10.0.2.252
>
> ;; QUESTION SECTION:
> ;+trace.in-addr.arpa.   IN  PTR
>
> ;; QUESTION SECTION:
> ;10.0.2.252.IN  A

You've given dig the wrong arguments. You gave it two queries,  
indicated above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice

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

Re: Delegation not working

2009-05-07 Thread Chris Buxton

+trace turns on the recursor in the 'dig' command itself. It tells you  
absolutely nothing about the server you specified.


Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:22 PM, Mike Bernhardt wrote:


Reformatting the dig request gives the following:

dig +trace @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> +trace @athena -x 10.0.2.252
; (1 server found)
;; global options:  printcmd
.   163824  IN  NS  K.ROOT-SERVERS.NET.
.   163824  IN  NS  L.ROOT-SERVERS.NET.
.   163824  IN  NS  M.ROOT-SERVERS.NET.
.   163824  IN  NS  A.ROOT-SERVERS.NET.
.   163824  IN  NS  B.ROOT-SERVERS.NET.
.   163824  IN  NS  C.ROOT-SERVERS.NET.
.   163824  IN  NS  D.ROOT-SERVERS.NET.
.   163824  IN  NS  E.ROOT-SERVERS.NET.
.   163824  IN  NS  F.ROOT-SERVERS.NET.
.   163824  IN  NS  G.ROOT-SERVERS.NET.
.   163824  IN  NS  H.ROOT-SERVERS.NET.
.   163824  IN  NS  I.ROOT-SERVERS.NET.
.   163824  IN  NS  J.ROOT-SERVERS.NET.

;; Received 500 bytes from 148.165.30.30#53(148.165.30.30) in 0 ms

;; connection timed out; no servers could be reached
Since this server can't reach the root servers, this makes sense. But
apparently it isn't following delegation.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com]
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:

dig -x +trace @athena 10.0.2.252

;; QUESTION SECTION:
;+trace.in-addr.arpa.   IN  PTR

;; QUESTION SECTION:
;10.0.2.252.IN  A


You've given dig the wrong arguments. You gave it two queries,
indicated above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice



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

RE: Delegation not working

2009-05-07 Thread Todd Snyder

+trace forces the server to go to the root.  It doesn't necessarily
represent the path your query would normally take.  If the server you
are querying is authoritative for the zone you are querying, it will
still trace from the root.  This feature is, sadly, not as useful in an
internal DNS configuration, where recursion from the root isn't used.
That seems to be the situation you're in (not able to reach the root)

At least, that is my interpretation of it.

Todd.

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mike Bernhardt
Sent: Thursday, May 07, 2009 3:22 PM
To: 'Chris Buxton'
Cc: bind-users@lists.isc.org
Subject: RE: Delegation not working

Reformatting the dig request gives the following:

dig +trace @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> +trace @athena -x 10.0.2.252 ; (1 server found) ;;
global options:  printcmd
.   163824  IN  NS  K.ROOT-SERVERS.NET.
.   163824  IN  NS  L.ROOT-SERVERS.NET.
.   163824  IN  NS  M.ROOT-SERVERS.NET.
.   163824  IN  NS  A.ROOT-SERVERS.NET.
.   163824  IN  NS  B.ROOT-SERVERS.NET.
.   163824  IN  NS  C.ROOT-SERVERS.NET.
.   163824  IN  NS  D.ROOT-SERVERS.NET.
.   163824  IN  NS  E.ROOT-SERVERS.NET.
.   163824  IN  NS  F.ROOT-SERVERS.NET.
.   163824  IN  NS  G.ROOT-SERVERS.NET.
.   163824  IN  NS  H.ROOT-SERVERS.NET.
.   163824  IN  NS  I.ROOT-SERVERS.NET.
.   163824  IN  NS  J.ROOT-SERVERS.NET.

;; Received 500 bytes from 148.165.30.30#53(148.165.30.30) in 0 ms

;; connection timed out; no servers could be reached Since this server
can't reach the root servers, this makes sense. But apparently it isn't
following delegation.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com]
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
> dig -x +trace @athena 10.0.2.252
>
> ;; QUESTION SECTION:
> ;+trace.in-addr.arpa.   IN  PTR
>
> ;; QUESTION SECTION:
> ;10.0.2.252.IN  A

You've given dig the wrong arguments. You gave it two queries, indicated
above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice

___
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: Delegation not working

2009-05-07 Thread Chris Buxton

Your delegation $GENERATE'd records don't cover this query. You've  
delegated 0.10.10.in-addr.arpa, but not 2.0.10.in-addr.arpa.


Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:18 PM, Mike Bernhardt wrote:


I had already tried that to no avail:
dig @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,  
ADDITIONAL: 0


;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.600 IN  SOA athena.bart.gov.
bernhardt.bart.gov. 2009050703 14400 600 864000 600

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 12:21:13 2009
;; MSG SIZE  rcvd: 102



-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com]
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:

dig -x +trace @athena 10.0.2.252

;; QUESTION SECTION:
;+trace.in-addr.arpa.   IN  PTR

;; QUESTION SECTION:
;10.0.2.252.IN  A


You've given dig the wrong arguments. You gave it two queries,
indicated above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice



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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

OK. I have modified the $GENERATE to this:
$GENERATE   0-127 $ NS  dhcp-01.adm.bart.gov.
$GENERATE   0-127 $ NS  mrep-02.adm.bart.gov.

And dig gives me this:
dig +norec @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> +norec @athena -x 10.0.2.252
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36136
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.

;; ADDITIONAL SECTION:
dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 12:38:05 2009
;; MSG SIZE  rcvd: 129

Without +norec, it times out.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 12:29 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

Your delegation $GENERATE'd records don't cover this query. You've  
delegated 0.10.10.in-addr.arpa, but not 2.0.10.in-addr.arpa.

Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:18 PM, Mike Bernhardt wrote:

> I had already tried that to no avail:
> dig @athena -x 10.0.2.252
>
> ; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252
> ; (1 server found)
> ;; global options:  printcmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,  
> ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;252.2.0.10.in-addr.arpa.   IN  PTR
>
> ;; AUTHORITY SECTION:
> 10.in-addr.arpa.600 IN  SOA athena.bart.gov.
> bernhardt.bart.gov. 2009050703 14400 600 864000 600
>
> ;; Query time: 0 msec
> ;; SERVER: 148.165.30.30#53(148.165.30.30)
> ;; WHEN: Thu May  7 12:21:13 2009
> ;; MSG SIZE  rcvd: 102
>
>
>
> -Original Message-
> From: Chris Buxton [mailto:cbux...@menandmice.com]
> Sent: Thursday, May 07, 2009 12:19 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
>
> On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
>> dig -x +trace @athena 10.0.2.252
>>
>> ;; QUESTION SECTION:
>> ;+trace.in-addr.arpa.   IN  PTR
>>
>> ;; QUESTION SECTION:
>> ;10.0.2.252.IN  A
>
> You've given dig the wrong arguments. You gave it two queries,
> indicated above, neither of which is what you wanted.
>
> Try this:
>
> dig @athena -x 10.0.2.252
>
> Chris Buxton
> Professional Services
> Men & Mice
>

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

RE: Delegation not working

2009-05-07 Thread Ben Bridges

Isn't the $GENERATE directive a purely textual substitution without any
semantic processing?  In that case, I believe you have actually
delegated 0.1010.in-addr.arpa, 1.1010.in-addr.arpa, 2.1010.in-addr.arpa,
... , 127.1010.in-addr.arpa instead of 0.10.in-addr.arpa,
1.10.in-addr.arpa, ... , 127.10.in-addr.arpa.  Try changing your
$GENERATE directives to

$GENERATE   0-127 $.10.in-addr.arpa. NS   dhcp-01.adm.bart.gov.
$GENERATE   0-127 $.10.in-addr.arpa. NS   mrep-02.adm.bart.gov.

and see if that works.

Ben Bridges


> -Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Buxton
> Sent: Thursday, May 07, 2009 2:29 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
> 
> Your delegation $GENERATE'd records don't cover this query. 
> You've delegated 0.10.10.in-addr.arpa, but not 2.0.10.in-addr.arpa.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 
> On May 7, 2009, at 12:18 PM, Mike Bernhardt wrote:
> 
> > I had already tried that to no avail:
> > dig @athena -x 10.0.2.252
> >
> > ; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252 ; (1 server found) ;; 
> > global options:  printcmd ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310 
> ;; flags: qr 
> > aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> > ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;252.2.0.10.in-addr.arpa.   IN  PTR
> >
> > ;; AUTHORITY SECTION:
> > 10.in-addr.arpa.600 IN  SOA athena.bart.gov.
> > bernhardt.bart.gov. 2009050703 14400 600 864000 600
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 148.165.30.30#53(148.165.30.30) ;; WHEN: Thu May  7 
> > 12:21:13 2009 ;; MSG SIZE  rcvd: 102
> >
> >
> >
> > -Original Message-
> > From: Chris Buxton [mailto:cbux...@menandmice.com]
> > Sent: Thursday, May 07, 2009 12:19 PM
> > To: Mike Bernhardt
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Delegation not working
> >
> > On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
> >> dig -x +trace @athena 10.0.2.252
> >>
> >> ;; QUESTION SECTION:
> >> ;+trace.in-addr.arpa.   IN  PTR
> >>
> >> ;; QUESTION SECTION:
> >> ;10.0.2.252.IN  A
> >
> > You've given dig the wrong arguments. You gave it two queries, 
> > indicated above, neither of which is what you wanted.
> >
> > Try this:
> >
> > dig @athena -x 10.0.2.252
> >
> > Chris Buxton
> > Professional Services
> > Men & Mice
> >
> 
> ___
> 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: Delegation not working

2009-05-07 Thread Chris Buxton

You're right that no semantic processing takes place as part of the  
$GENERATE statement, but the original statement said:


$GENERATE 0-127 $.10 NS [...]

This is identical to typing:

0.10 NS [...]
1.10 NS [...]
[...]
127.10 NS [...]

But the origin here is 10.in-addr.arpa. So the origin is applied  
normally to the results of the $GENERATE, and so you get 0.10.10.in- 
addr.arpa, not "0.1010". The extra dot between the first and second  
10's is implied as part of the application of the origin.


Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:42 PM, Ben Bridges wrote:

Isn't the $GENERATE directive a purely textual substitution without  
any

semantic processing?  In that case, I believe you have actually
delegated 0.1010.in-addr.arpa, 1.1010.in-addr.arpa, 2.1010.in- 
addr.arpa,

... , 127.1010.in-addr.arpa instead of 0.10.in-addr.arpa,
1.10.in-addr.arpa, ... , 127.10.in-addr.arpa.  Try changing your
$GENERATE directives to

$GENERATE   0-127 $.10.in-addr.arpa. NS   dhcp-01.adm.bart.gov.
$GENERATE   0-127 $.10.in-addr.arpa. NS   mrep-02.adm.bart.gov.

and see if that works.

Ben Bridges



-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Buxton
Sent: Thursday, May 07, 2009 2:29 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

Your delegation $GENERATE'd records don't cover this query.
You've delegated 0.10.10.in-addr.arpa, but not 2.0.10.in-addr.arpa.

Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:18 PM, Mike Bernhardt wrote:


I had already tried that to no avail:
dig @athena -x 10.0.2.252

; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252 ; (1 server found) ;;
global options:  printcmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310

;; flags: qr

aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 0

;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
10.in-addr.arpa.600 IN  SOA athena.bart.gov.
bernhardt.bart.gov. 2009050703 14400 600 864000 600

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30) ;; WHEN: Thu May  7
12:21:13 2009 ;; MSG SIZE  rcvd: 102



-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com]
Sent: Thursday, May 07, 2009 12:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:

dig -x +trace @athena 10.0.2.252

;; QUESTION SECTION:
;+trace.in-addr.arpa.   IN  PTR

;; QUESTION SECTION:
;10.0.2.252.IN  A


You've given dig the wrong arguments. You gave it two queries,
indicated above, neither of which is what you wanted.

Try this:

dig @athena -x 10.0.2.252

Chris Buxton
Professional Services
Men & Mice



___
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: Delegation not working

2009-05-07 Thread Ben Bridges

I wasn't thinking straight.  Ignore that.  My apologies.


> -Original Message-
> From: bind-users-boun...@lists.isc.org 
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Ben Bridges
> Sent: Thursday, May 07, 2009 2:42 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: RE: Delegation not working
> 
> Isn't the $GENERATE directive a purely textual substitution 
> without any semantic processing?  In that case, I believe you 
> have actually delegated 0.1010.in-addr.arpa, 
> 1.1010.in-addr.arpa, 2.1010.in-addr.arpa, ... , 
> 127.1010.in-addr.arpa instead of 0.10.in-addr.arpa, 
> 1.10.in-addr.arpa, ... , 127.10.in-addr.arpa.  Try changing 
> your $GENERATE directives to
> 
> $GENERATE   0-127 $.10.in-addr.arpa. NS   dhcp-01.adm.bart.gov.
> $GENERATE   0-127 $.10.in-addr.arpa. NS   mrep-02.adm.bart.gov.
> 
> and see if that works.
> 
> Ben Bridges
> 
> 
> > -Original Message-
> > From: bind-users-boun...@lists.isc.org 
> > [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Buxton
> > Sent: Thursday, May 07, 2009 2:29 PM
> > To: Mike Bernhardt
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Delegation not working
> > 
> > Your delegation $GENERATE'd records don't cover this query. 
> > You've delegated 0.10.10.in-addr.arpa, but not 2.0.10.in-addr.arpa.
> > 
> > Chris Buxton
> > Professional Services
> > Men & Mice
> > 
> > On May 7, 2009, at 12:18 PM, Mike Bernhardt wrote:
> > 
> > > I had already tried that to no avail:
> > > dig @athena -x 10.0.2.252
> > >
> > > ; <<>> DiG 9.3.4 <<>> @athena -x 10.0.2.252 ; (1 server found) ;; 
> > > global options:  printcmd ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7310
> > ;; flags: qr
> > > aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
> > > ADDITIONAL: 0
> > >
> > > ;; QUESTION SECTION:
> > > ;252.2.0.10.in-addr.arpa.   IN  PTR
> > >
> > > ;; AUTHORITY SECTION:
> > > 10.in-addr.arpa.600 IN  SOA athena.bart.gov.
> > > bernhardt.bart.gov. 2009050703 14400 600 864000 600
> > >
> > > ;; Query time: 0 msec
> > > ;; SERVER: 148.165.30.30#53(148.165.30.30) ;; WHEN: Thu May  7
> > > 12:21:13 2009 ;; MSG SIZE  rcvd: 102
> > >
> > >
> > >
> > > -Original Message-
> > > From: Chris Buxton [mailto:cbux...@menandmice.com]
> > > Sent: Thursday, May 07, 2009 12:19 PM
> > > To: Mike Bernhardt
> > > Cc: bind-users@lists.isc.org
> > > Subject: Re: Delegation not working
> > >
> > > On May 7, 2009, at 12:06 PM, Mike Bernhardt wrote:
> > >> dig -x +trace @athena 10.0.2.252
> > >>
> > >> ;; QUESTION SECTION:
> > >> ;+trace.in-addr.arpa.   IN  PTR
> > >>
> > >> ;; QUESTION SECTION:
> > >> ;10.0.2.252.IN  A
> > >
> > > You've given dig the wrong arguments. You gave it two queries, 
> > > indicated above, neither of which is what you wanted.
> > >
> > > Try this:
> > >
> > > dig @athena -x 10.0.2.252
> > >
> > > Chris Buxton
> > > Professional Services
> > > Men & Mice
> > >
> > 
> > ___
> > 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
> 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegation not working

2009-05-07 Thread Chris Buxton


On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:

And dig gives me this:
dig +norec @athena -x 10.0.2.252

;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.

;; ADDITIONAL SECTION:
dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222


That looks perfect.


Without +norec, it times out.



OK, now we're getting somewhere. Why would the server "athena" have  
trouble querying those two servers? Try this from "athena" itself:


dig +norec -x 10.0.2.252 @148.165.126.87
dig +norec -x 10.0.2.252 @10.2.242.222

Chris Buxton
Professional Services
Men & Mice

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

That gave me:
dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
@10.2.242.222
;; connection timed out; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;dig.   IN  A

;; AUTHORITY SECTION:
.   162058  IN  NS  C.ROOT-SERVERS.NET.
.   162058  IN  NS  D.ROOT-SERVERS.NET.
.   162058  IN  NS  E.ROOT-SERVERS.NET.
.   162058  IN  NS  F.ROOT-SERVERS.NET.
.   162058  IN  NS  G.ROOT-SERVERS.NET.
.   162058  IN  NS  H.ROOT-SERVERS.NET.
.   162058  IN  NS  I.ROOT-SERVERS.NET.
.   162058  IN  NS  J.ROOT-SERVERS.NET.
.   162058  IN  NS  K.ROOT-SERVERS.NET.
.   162058  IN  NS  L.ROOT-SERVERS.NET.
.   162058  IN  NS  M.ROOT-SERVERS.NET.
.   162058  IN  NS  A.ROOT-SERVERS.NET.
.   162058  IN  NS  B.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 12:52:39 2009
;; MSG SIZE  rcvd: 504


; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x
10.0.2.252 @10.2.242.222
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 12:50 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:
> And dig gives me this:
> dig +norec @athena -x 10.0.2.252
>
> ;; QUESTION SECTION:
> ;252.2.0.10.in-addr.arpa.   IN  PTR
>
> ;; AUTHORITY SECTION:
> 0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
> 0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.
>
> ;; ADDITIONAL SECTION:
> dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
> mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222

That looks perfect.

> Without +norec, it times out.


OK, now we're getting somewhere. Why would the server "athena" have  
trouble querying those two servers? Try this from "athena" itself:

dig +norec -x 10.0.2.252 @148.165.126.87
dig +norec -x 10.0.2.252 @10.2.242.222

Chris Buxton
Professional Services
Men & Mice

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

Re: Delegation not working

2009-05-07 Thread Chris Buxton


Mike,

That was two separate commands.

dig +norec -x 10.0.2.252 @148.165.126.87

and

dig +norec -x 10.0.2.252 @10.2.242.222

So most of what you sent back is gibberish. However, at the top, there  
is the message "connection timed out; no servers could be reached".  
There's at least part of your problem.


Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:


That gave me:
dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
@10.2.242.222
;; connection timed out; no servers could be reached
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14

;; QUESTION SECTION:
;dig.   IN  A

;; AUTHORITY SECTION:
.   162058  IN  NS  C.ROOT-SERVERS.NET.
.   162058  IN  NS  D.ROOT-SERVERS.NET.
.   162058  IN  NS  E.ROOT-SERVERS.NET.
.   162058  IN  NS  F.ROOT-SERVERS.NET.
.   162058  IN  NS  G.ROOT-SERVERS.NET.
.   162058  IN  NS  H.ROOT-SERVERS.NET.
.   162058  IN  NS  I.ROOT-SERVERS.NET.
.   162058  IN  NS  J.ROOT-SERVERS.NET.
.   162058  IN  NS  K.ROOT-SERVERS.NET.
.   162058  IN  NS  L.ROOT-SERVERS.NET.
.   162058  IN  NS  M.ROOT-SERVERS.NET.
.   162058  IN  NS  A.ROOT-SERVERS.NET.
.   162058  IN  NS  B.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30

;; Query time: 0 msec
;; SERVER: 148.165.30.30#53(148.165.30.30)
;; WHEN: Thu May  7 12:52:39 2009
;; MSG SIZE  rcvd: 504


; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig  
+norec -x

10.0.2.252 @10.2.242.222
; (1 server found)
;; global options:  printcmd
;; connection timed out; no servers could be reached

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com]
Sent: Thursday, May 07, 2009 12:50 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:

And dig gives me this:
dig +norec @athena -x 10.0.2.252

;; QUESTION SECTION:
;252.2.0.10.in-addr.arpa.   IN  PTR

;; AUTHORITY SECTION:
0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.

;; ADDITIONAL SECTION:
dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222


That looks perfect.


Without +norec, it times out.



OK, now we're getting somewhere. Why would the server "athena" have
trouble querying those two servers? Try this from "athena" itself:

dig +norec -x 10.0.2.252 @148.165.126.87
dig +norec -x 10.0.2.252 @10.2.242.222

Chris Buxton
Professional Services
Men & Mice



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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

Exactly. I'm going to have to trace the queries with a sniffer or something
and see where things are dying. I tried 
dig -b 148.165.30.30 +norec +tcp -x 10.0.2.252 @148.165.126.87
and it worked, which makes sense since I'm slaving their forward zone at the
moment. For some reason UDP isn't working. I'll get back when I have a
better idea what's going on but it apparently isn't my configuration at this
point.

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 1:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

Mike,

That was two separate commands.

dig +norec -x 10.0.2.252 @148.165.126.87

and

dig +norec -x 10.0.2.252 @10.2.242.222

So most of what you sent back is gibberish. However, at the top, there  
is the message "connection timed out; no servers could be reached".  
There's at least part of your problem.

Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:

> That gave me:
> dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
> @10.2.242.222
> ;; connection timed out; no servers could be reached
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
>
> ;; QUESTION SECTION:
> ;dig.   IN  A
>
> ;; AUTHORITY SECTION:
> .   162058  IN  NS  C.ROOT-SERVERS.NET.
> .   162058  IN  NS  D.ROOT-SERVERS.NET.
> .   162058  IN  NS  E.ROOT-SERVERS.NET.
> .   162058  IN  NS  F.ROOT-SERVERS.NET.
> .   162058  IN  NS  G.ROOT-SERVERS.NET.
> .   162058  IN  NS  H.ROOT-SERVERS.NET.
> .   162058  IN  NS  I.ROOT-SERVERS.NET.
> .   162058  IN  NS  J.ROOT-SERVERS.NET.
> .   162058  IN  NS  K.ROOT-SERVERS.NET.
> .   162058  IN  NS  L.ROOT-SERVERS.NET.
> .   162058  IN  NS  M.ROOT-SERVERS.NET.
> .   162058  IN  NS  A.ROOT-SERVERS.NET.
> .   162058  IN  NS  B.ROOT-SERVERS.NET.
>
> ;; ADDITIONAL SECTION:
> A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
> A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
> B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
> C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
> D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
> E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
> F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
> F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
> G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
> H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
> H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
> I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
> J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
> J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30
>
> ;; Query time: 0 msec
> ;; SERVER: 148.165.30.30#53(148.165.30.30)
> ;; WHEN: Thu May  7 12:52:39 2009
> ;; MSG SIZE  rcvd: 504
>
>
> ; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig  
> +norec -x
> 10.0.2.252 @10.2.242.222
> ; (1 server found)
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
>
> -Original Message-
> From: Chris Buxton [mailto:cbux...@menandmice.com]
> Sent: Thursday, May 07, 2009 12:50 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
>
> On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:
>> And dig gives me this:
>> dig +norec @athena -x 10.0.2.252
>>
>> ;; QUESTION SECTION:
>> ;252.2.0.10.in-addr.arpa.   IN  PTR
>>
>> ;; AUTHORITY SECTION:
>> 0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
>> 0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.
>>
>> ;; ADDITIONAL SECTION:
>> dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
>> mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222
>
> That looks perfect.
>
>> Without +norec, it times out.
>
>
> OK, now we're getting somewhere. Why would the server "athena" have
> trouble querying those two servers? Try this from "athena" itself:
>
> dig +norec -x 10.0.2.252 @148.165.126.87
> dig +norec -x 10.0.2.252 @10.2.242.222
>
> Chris Buxton
> Professional Services
> Men & Mice
>

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

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

I found the problem. After the various delegation config issues were cleared
and it still didn't work, I started doing some traces. The problem turned
out to be
1. We had a query source port of 53 configured that was left over from some
old legacy compatibility issues.
2. The firewall between us and the subdomain authority was only allowing
queries from high-numbered ports.
3. The dns rule in the firewall was configured to not log, so the drops
didn't show up when I looked previously.

I removed the query source-port option and all is now good. Thank you to
Chris Buxton for all of his patience. I learned a few things along the way.

Mike

-Original Message-
From: Chris Buxton [mailto:cbux...@menandmice.com] 
Sent: Thursday, May 07, 2009 1:19 PM
To: Mike Bernhardt
Cc: bind-users@lists.isc.org
Subject: Re: Delegation not working

Mike,

That was two separate commands.

dig +norec -x 10.0.2.252 @148.165.126.87

and

dig +norec -x 10.0.2.252 @10.2.242.222

So most of what you sent back is gibberish. However, at the top, there  
is the message "connection timed out; no servers could be reached".  
There's at least part of your problem.

Chris Buxton
Professional Services
Men & Mice

On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:

> That gave me:
> dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
> @10.2.242.222
> ;; connection timed out; no servers could be reached
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
>
> ;; QUESTION SECTION:
> ;dig.   IN  A
>
> ;; AUTHORITY SECTION:
> .   162058  IN  NS  C.ROOT-SERVERS.NET.
> .   162058  IN  NS  D.ROOT-SERVERS.NET.
> .   162058  IN  NS  E.ROOT-SERVERS.NET.
> .   162058  IN  NS  F.ROOT-SERVERS.NET.
> .   162058  IN  NS  G.ROOT-SERVERS.NET.
> .   162058  IN  NS  H.ROOT-SERVERS.NET.
> .   162058  IN  NS  I.ROOT-SERVERS.NET.
> .   162058  IN  NS  J.ROOT-SERVERS.NET.
> .   162058  IN  NS  K.ROOT-SERVERS.NET.
> .   162058  IN  NS  L.ROOT-SERVERS.NET.
> .   162058  IN  NS  M.ROOT-SERVERS.NET.
> .   162058  IN  NS  A.ROOT-SERVERS.NET.
> .   162058  IN  NS  B.ROOT-SERVERS.NET.
>
> ;; ADDITIONAL SECTION:
> A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
> A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
> B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
> C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
> D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
> E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
> F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
> F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
> G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
> H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
> H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
> I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
> J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
> J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30
>
> ;; Query time: 0 msec
> ;; SERVER: 148.165.30.30#53(148.165.30.30)
> ;; WHEN: Thu May  7 12:52:39 2009
> ;; MSG SIZE  rcvd: 504
>
>
> ; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig  
> +norec -x
> 10.0.2.252 @10.2.242.222
> ; (1 server found)
> ;; global options:  printcmd
> ;; connection timed out; no servers could be reached
>
> -Original Message-
> From: Chris Buxton [mailto:cbux...@menandmice.com]
> Sent: Thursday, May 07, 2009 12:50 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
>
> On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:
>> And dig gives me this:
>> dig +norec @athena -x 10.0.2.252
>>
>> ;; QUESTION SECTION:
>> ;252.2.0.10.in-addr.arpa.   IN  PTR
>>
>> ;; AUTHORITY SECTION:
>> 0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
>> 0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.
>>
>> ;; ADDITIONAL SECTION:
>> dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126.87
>> mrep-02.adm.bart.gov.   86400   IN  A   10.2.242.222
>
> That looks perfect.
>
>> Without +norec, it times out.
>
>
> OK, now we're getting somewhere. Why would the server "athena" have
> trouble querying those two servers? Try this from "athena" itself:
>
> dig +norec -x 10.0.2.252 @148.165.126.87
> dig +norec -x 10.0.2.252 @10.2.242.222
>
> Chris Buxton
> Professional Services
> Men & Mice
>

___
bind-users mailing list

Re: Delegation not working

2009-05-07 Thread Mark Andrews


In message , "Mike 
Bernhardt" writes:
> I found the problem. After the various delegation config issues were cleared
> and it still didn't work, I started doing some traces. The problem turned
> out to be
> 1. We had a query source port of 53 configured that was left over from some
> old legacy compatibility issues.
> 2. The firewall between us and the subdomain authority was only allowing
> queries from high-numbered ports.
> 3. The dns rule in the firewall was configured to not log, so the drops
> didn't show up when I looked previously.
> 
> I removed the query source-port option and all is now good. Thank you to
> Chris Buxton for all of his patience. I learned a few things along the way.

I hope you also fixed the firewall not to care about the
source port of DNS queries.  There is no requirement for
DNS queries to be sourced from any particular port range.

Mark
 
> Mike
> 
> -Original Message-
> From: Chris Buxton [mailto:cbux...@menandmice.com] 
> Sent: Thursday, May 07, 2009 1:19 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
> 
> Mike,
> 
> That was two separate commands.
> 
> dig +norec -x 10.0.2.252 @148.165.126.87
> 
> and
> 
> dig +norec -x 10.0.2.252 @10.2.242.222
> 
> So most of what you sent back is gibberish. However, at the top, there  
> is the message "connection timed out; no servers could be reached".  
> There's at least part of your problem.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 
> On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:
> 
> > That gave me:
> > dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
> > @10.2.242.222
> > ;; connection timed out; no servers could be reached
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
> > ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
> >
> > ;; QUESTION SECTION:
> > ;dig.   IN  A
> >
> > ;; AUTHORITY SECTION:
> > .   162058  IN  NS  C.ROOT-SERVERS.NET.
> > .   162058  IN  NS  D.ROOT-SERVERS.NET.
> > .   162058  IN  NS  E.ROOT-SERVERS.NET.
> > .   162058  IN  NS  F.ROOT-SERVERS.NET.
> > .   162058  IN  NS  G.ROOT-SERVERS.NET.
> > .   162058  IN  NS  H.ROOT-SERVERS.NET.
> > .   162058  IN  NS  I.ROOT-SERVERS.NET.
> > .   162058  IN  NS  J.ROOT-SERVERS.NET.
> > .   162058  IN  NS  K.ROOT-SERVERS.NET.
> > .   162058  IN  NS  L.ROOT-SERVERS.NET.
> > .   162058  IN  NS  M.ROOT-SERVERS.NET.
> > .   162058  IN  NS  A.ROOT-SERVERS.NET.
> > .   162058  IN  NS  B.ROOT-SERVERS.NET.
> >
> > ;; ADDITIONAL SECTION:
> > A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
> > A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
> > B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
> > C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
> > D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
> > E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
> > F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
> > F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
> > G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
> > H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
> > H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
> > I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
> > J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
> > J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 148.165.30.30#53(148.165.30.30)
> > ;; WHEN: Thu May  7 12:52:39 2009
> > ;; MSG SIZE  rcvd: 504
> >
> >
> > ; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig  
> > +norec -x
> > 10.0.2.252 @10.2.242.222
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; connection timed out; no servers could be reached
> >
> > -Original Message-
> > From: Chris Buxton [mailto:cbux...@menandmice.com]
> > Sent: Thursday, May 07, 2009 12:50 PM
> > To: Mike Bernhardt
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Delegation not working
> >
> > On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:
> >> And dig gives me this:
> >> dig +norec @athena -x 10.0.2.252
> >>
> >> ;; QUESTION SECTION:
> >> ;252.2.0.10.in-addr.arpa.   IN  PTR
> >>
> >> ;; AUTHORITY SECTION:
> >> 0.10.in-addr.arpa.  14400   IN  NS  mrep-02.adm.bart.gov.
> >> 0.10.in-addr.arpa.  14400   IN  NS  dhcp-01.adm.bart.gov.
> >>
> >> ;; ADDITIONAL SECTION:
> >> dhcp-01.adm.bart.gov.   86400   IN  A   148.165.126

RE: Delegation not working

2009-05-07 Thread Mike Bernhardt

Do you mean that BIND *COULD* query from a low-numbered random port? I
thought applications that don't source from a specific port always sourced
from > 1023?

-Original Message-
From: mark_andr...@isc.org [mailto:mark_andr...@isc.org] 
Sent: Thursday, May 07, 2009 3:33 PM
To: Mike Bernhardt
Cc: 'Chris Buxton'; bind-users@lists.isc.org
Subject: Re: Delegation not working 


In message , "Mike
Bernhardt" writes:
> I found the problem. After the various delegation config issues were
cleared
> and it still didn't work, I started doing some traces. The problem turned
> out to be
> 1. We had a query source port of 53 configured that was left over from
some
> old legacy compatibility issues.
> 2. The firewall between us and the subdomain authority was only allowing
> queries from high-numbered ports.
> 3. The dns rule in the firewall was configured to not log, so the drops
> didn't show up when I looked previously.
> 
> I removed the query source-port option and all is now good. Thank you to
> Chris Buxton for all of his patience. I learned a few things along the
way.

I hope you also fixed the firewall not to care about the
source port of DNS queries.  There is no requirement for
DNS queries to be sourced from any particular port range.

Mark
 
> Mike
> 
> -Original Message-
> From: Chris Buxton [mailto:cbux...@menandmice.com] 
> Sent: Thursday, May 07, 2009 1:19 PM
> To: Mike Bernhardt
> Cc: bind-users@lists.isc.org
> Subject: Re: Delegation not working
> 
> Mike,
> 
> That was two separate commands.
> 
> dig +norec -x 10.0.2.252 @148.165.126.87
> 
> and
> 
> dig +norec -x 10.0.2.252 @10.2.242.222
> 
> So most of what you sent back is gibberish. However, at the top, there  
> is the message "connection timed out; no servers could be reached".  
> There's at least part of your problem.
> 
> Chris Buxton
> Professional Services
> Men & Mice
> 
> On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:
> 
> > That gave me:
> > dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
> > @10.2.242.222
> > ;; connection timed out; no servers could be reached
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
> > ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
> >
> > ;; QUESTION SECTION:
> > ;dig.   IN  A
> >
> > ;; AUTHORITY SECTION:
> > .   162058  IN  NS  C.ROOT-SERVERS.NET.
> > .   162058  IN  NS  D.ROOT-SERVERS.NET.
> > .   162058  IN  NS  E.ROOT-SERVERS.NET.
> > .   162058  IN  NS  F.ROOT-SERVERS.NET.
> > .   162058  IN  NS  G.ROOT-SERVERS.NET.
> > .   162058  IN  NS  H.ROOT-SERVERS.NET.
> > .   162058  IN  NS  I.ROOT-SERVERS.NET.
> > .   162058  IN  NS  J.ROOT-SERVERS.NET.
> > .   162058  IN  NS  K.ROOT-SERVERS.NET.
> > .   162058  IN  NS  L.ROOT-SERVERS.NET.
> > .   162058  IN  NS  M.ROOT-SERVERS.NET.
> > .   162058  IN  NS  A.ROOT-SERVERS.NET.
> > .   162058  IN  NS  B.ROOT-SERVERS.NET.
> >
> > ;; ADDITIONAL SECTION:
> > A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
> > A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
> > B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
> > C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
> > D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
> > E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
> > F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
> > F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
> > G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
> > H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
> > H.ROOT-SERVERS.NET. 552012  IN  2001:500:1::803f:235
> > I.ROOT-SERVERS.NET. 599092  IN  A   192.36.148.17
> > J.ROOT-SERVERS.NET. 208142  IN  A   192.58.128.30
> > J.ROOT-SERVERS.NET. 208142  IN  2001:503:c27::2:30
> >
> > ;; Query time: 0 msec
> > ;; SERVER: 148.165.30.30#53(148.165.30.30)
> > ;; WHEN: Thu May  7 12:52:39 2009
> > ;; MSG SIZE  rcvd: 504
> >
> >
> > ; <<>> DiG 9.3.4 <<>> +norec -x 10.0.2.252 @148.165.126.87 dig  
> > +norec -x
> > 10.0.2.252 @10.2.242.222
> > ; (1 server found)
> > ;; global options:  printcmd
> > ;; connection timed out; no servers could be reached
> >
> > -Original Message-
> > From: Chris Buxton [mailto:cbux...@menandmice.com]
> > Sent: Thursday, May 07, 2009 12:50 PM
> > To: Mike Bernhardt
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Delegation not working
> >
> > On May 7, 2009, at 12:37 PM, Mike Bernhardt wrote:
> >> And dig gives me this:
> >> dig +nore

Re: Delegation not working

2009-05-07 Thread Mark Andrews


In message <0e6dc7d76aa144a4b068e4b552026...@netadmin.bart.gov>, "Mike 
Bernhardt" writes:
> Do you mean that BIND *COULD* query from a low-numbered random port? I
> thought applications that don't source from a specific port always sourced
> from > 1023?

BIND is not the only application that makes queries.  POSIX
is not the only platform that makes queries.  Even if you
have a POSIX box middleware may change the port to something
less than 1024.

When you restrict the source ports to something other than
the entire range you are making lots of assumptions about
the sender and all the middleware involved that actually
don't hold true in many cases.

Your problem was caused by a misconfigured firewall.  That
firewall should be fixed.  It remains a potential source
of problems until it is fixed.

Mark
 
> -Original Message-
> From: mark_andr...@isc.org [mailto:mark_andr...@isc.org] 
> Sent: Thursday, May 07, 2009 3:33 PM
> To: Mike Bernhardt
> Cc: 'Chris Buxton'; bind-users@lists.isc.org
> Subject: Re: Delegation not working 
> 
> 
> In message , "Mike
> Bernhardt" writes:
> > I found the problem. After the various delegation config issues were
> cleared
> > and it still didn't work, I started doing some traces. The problem turned
> > out to be
> > 1. We had a query source port of 53 configured that was left over from
> some
> > old legacy compatibility issues.
> > 2. The firewall between us and the subdomain authority was only allowing
> > queries from high-numbered ports.
> > 3. The dns rule in the firewall was configured to not log, so the drops
> > didn't show up when I looked previously.
> > 
> > I removed the query source-port option and all is now good. Thank you to
> > Chris Buxton for all of his patience. I learned a few things along the
> way.
> 
>   I hope you also fixed the firewall not to care about the
>   source port of DNS queries.  There is no requirement for
>   DNS queries to be sourced from any particular port range.
> 
>   Mark
>  
> > Mike
> > 
> > -Original Message-
> > From: Chris Buxton [mailto:cbux...@menandmice.com] 
> > Sent: Thursday, May 07, 2009 1:19 PM
> > To: Mike Bernhardt
> > Cc: bind-users@lists.isc.org
> > Subject: Re: Delegation not working
> > 
> > Mike,
> > 
> > That was two separate commands.
> > 
> > dig +norec -x 10.0.2.252 @148.165.126.87
> > 
> > and
> > 
> > dig +norec -x 10.0.2.252 @10.2.242.222
> > 
> > So most of what you sent back is gibberish. However, at the top, there  
> > is the message "connection timed out; no servers could be reached".  
> > There's at least part of your problem.
> > 
> > Chris Buxton
> > Professional Services
> > Men & Mice
> > 
> > On May 7, 2009, at 12:50 PM, Mike Bernhardt wrote:
> > 
> > > That gave me:
> > > dig +norec -x 10.0.2.252 @148.165.126.87 dig +norec -x 10.0.2.252
> > > @10.2.242.222
> > > ;; connection timed out; no servers could be reached
> > > ;; Got answer:
> > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34563
> > > ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 14
> > >
> > > ;; QUESTION SECTION:
> > > ;dig.   IN  A
> > >
> > > ;; AUTHORITY SECTION:
> > > .   162058  IN  NS  C.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  D.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  E.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  F.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  G.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  H.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  I.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  J.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  K.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  L.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  M.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  A.ROOT-SERVERS.NET.
> > > .   162058  IN  NS  B.ROOT-SERVERS.NET.
> > >
> > > ;; ADDITIONAL SECTION:
> > > A.ROOT-SERVERS.NET. 599086  IN  A   198.41.0.4
> > > A.ROOT-SERVERS.NET. 552012  IN  2001:503:ba3e::2:30
> > > B.ROOT-SERVERS.NET. 35325   IN  A   192.228.79.201
> > > C.ROOT-SERVERS.NET. 599099  IN  A   192.33.4.12
> > > D.ROOT-SERVERS.NET. 599100  IN  A   128.8.10.90
> > > E.ROOT-SERVERS.NET. 599101  IN  A   192.203.230.10
> > > F.ROOT-SERVERS.NET. 599102  IN  A   192.5.5.241
> > > F.ROOT-SERVERS.NET. 552012  IN  2001:500:2f::f
> > > G.ROOT-SERVERS.NET. 599090  IN  A   192.112.36.4
> > > H.ROOT-SERVERS.NET. 599091  IN  A   128.63.2.53
> > > H.ROOT-SERVERS.NET. 552012  IN

Core dumping DLZ

2009-05-07 Thread Scott Haneda

Hello, I posted this to the DLZ testers list, cross posting it here,  
mainly because I am not sure which list to best address this to.


I deployed a DLZ system for a client on RHEL.  This is the
first time I have used RHEL, mostly sticking to other OS's.  I kept
pretty good notes as I went along.

If I look in /var/named I am seeing a good deal or large core dump
files.  Previously I saw these, but traced them to malformed mysql
inputs to DLZ.  I do not believe that to be a issue anymore.

What can a core dump tell me to help trace this issue down and solve
it?  Named is going deaf/dead for some reason, perhaps related, I need
it to keep up.

Here is what I did to the RHEL to get where I am now:

uanme -r
2.6.18-128.el5

Remove outdated stuff
"yum remove bind bind-chroot bind-libs bind-utils"

Unable to build from source due to openSSL issues I could not reconcile.

I went this route:
rpm -i http://people.redhat.com/atkac/bind/bind-9.6.0-2.P1.fc11.src.rpm
yum install libtool
yum install libcap-devel
yum install openldap-devel
yum install postgresql-devel
yum install rpmbuild

rpmbuild -bb /usr/src/redhat/SPECS/bind.spec

rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-libs-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-utils-9.6.0-2.P1.x86_64.rpm
rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-devel-9.6.0-2.P1.x86_64.rpm

rpm -ivh /usr/src/redhat/RPMS/x86_64/bind-sdb-9.6.0-2.P1.x86_64.rpm

edited /etc/sysconfig/named
copied /usr/share/doc/bind-9.3.4/sample/etc/* to /etc/
copied /usr/share/doc/bind-9.3.4/sample/var/* to /var/
edited /etc/named.conf

I did a few other things, configs, keygen etc, which I do not think
are related.
--
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

Re: Core dumping DLZ

2009-05-07 Thread Scott Haneda


On May 7, 2009, at 6:08 PM, Scott Haneda wrote:


What can a core dump tell me to help trace this issue down and solve
it?  Named is going deaf/dead for some reason, perhaps related, I need
it to keep up.



I did a little searching and found how to look into the core dumps,  
here is what is happening.  How can I solve this?


r...@host [core_dumps:] $ gdb /usr/sbin/named-sdb core.9810
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show  
copying"

and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
Loaded symbols for /usr/sbin/named-sdb
Reading symbols from /usr/lib64/liblwres.so.50...done.
Loaded symbols for /usr/lib64/liblwres.so.50
Reading symbols from /usr/lib64/libdns.so.50...done.
Loaded symbols for /usr/lib64/libdns.so.50
Reading symbols from /usr/lib64/libbind9.so.50...done.
Loaded symbols for /usr/lib64/libbind9.so.50
Reading symbols from /usr/lib64/libisccfg.so.50...done.
Loaded symbols for /usr/lib64/libisccfg.so.50
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libcrypto.so.6...done.
Loaded symbols for /lib64/libcrypto.so.6
Reading symbols from /usr/lib64/libisccc.so.50...done.
Loaded symbols for /usr/lib64/libisccc.so.50
Reading symbols from /usr/lib64/libisc.so.50...done.
Loaded symbols for /usr/lib64/libisc.so.50
Reading symbols from /usr/lib64/mysql/libmysqlclient.so.15...done.
Loaded symbols for /usr/lib64/mysql/libmysqlclient.so.15
Reading symbols from /lib64/libcrypt.so.1...done.
Loaded symbols for /lib64/libcrypt.so.1
Reading symbols from /usr/lib64/libldap-2.3.so.0...done.
Loaded symbols for /usr/lib64/libldap-2.3.so.0
Reading symbols from /usr/lib64/liblber-2.3.so.0...done.
Loaded symbols for /usr/lib64/liblber-2.3.so.0
Reading symbols from /usr/lib64/libpq.so.4...done.
Loaded symbols for /usr/lib64/libpq.so.4
Reading symbols from /usr/lib64/libsqlite3.so.0...done.
Loaded symbols for /usr/lib64/libsqlite3.so.0
Reading symbols from /lib64/libcap.so.1...done.
Loaded symbols for /lib64/libcap.so.1
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/libpthread.so.0...done.
Loaded symbols for /lib64/libpthread.so.0
Reading symbols from /usr/lib64/libxml2.so.2...done.
Loaded symbols for /usr/lib64/libxml2.so.2
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /lib64/libm.so.6...done.
Loaded symbols for /lib64/libm.so.6
Reading symbols from /lib64/libc.so.6...done.
Loaded symbols for /lib64/libc.so.6
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libkrb5support.so.0...done.
Loaded symbols for /usr/lib64/libkrb5support.so.0
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/libkeyutils.so.1...done.
Loaded symbols for /lib64/libkeyutils.so.1
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libssl.so.6...done.
Loaded symbols for /lib64/libssl.so.6
Reading symbols from /usr/lib64/libsasl2.so.2...done.
Loaded symbols for /usr/lib64/libsasl2.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libselinux.so.1...done.
Loaded symbols for /lib64/libselinux.so.1
Reading symbols from /lib64/libsepol.so.1...done.
Loaded symbols for /lib64/libsepol.so.1
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
Core was generated by `/usr/sbin/named-sdb -u named'.
Program terminated with signal 6, Aborted.
[New process 9810]
#0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
(gdb) backtrace
#0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
#1  0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6
#2  0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b  
"mem.c", line=918, type=, cond=0x2adb292245b5  
"ctx->stats[i].gets == 0U")

at ./main.c:166
#3  0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
#4  0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at  
mem.c:1067
#5  0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./ 
main.c:1064

--
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

Re: Core dumping DLZ

2009-05-07 Thread Mark Andrews


In message <8b717588-3e36-4596-9b11-de03e1ca4...@newgeo.com>, Scott Haneda writ
es:
> On May 7, 2009, at 6:08 PM, Scott Haneda wrote:
> 
> > What can a core dump tell me to help trace this issue down and solve
> > it?  Named is going deaf/dead for some reason, perhaps related, I need
> > it to keep up.
> 
> 
> I did a little searching and found how to look into the core dumps,  
> here is what is happening.  How can I solve this?
> 
> r...@host [core_dumps:] $ gdb /usr/sbin/named-sdb core.9810
> GNU gdb Fedora (6.8-27.el5)
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later   >
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show  
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu"...
> Loaded symbols for /usr/sbin/named-sdb
> Reading symbols from /usr/lib64/liblwres.so.50...done.
> Loaded symbols for /usr/lib64/liblwres.so.50
> Reading symbols from /usr/lib64/libdns.so.50...done.
> Loaded symbols for /usr/lib64/libdns.so.50
> Reading symbols from /usr/lib64/libbind9.so.50...done.
> Loaded symbols for /usr/lib64/libbind9.so.50
> Reading symbols from /usr/lib64/libisccfg.so.50...done.
> Loaded symbols for /usr/lib64/libisccfg.so.50
> Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
> Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
> Reading symbols from /lib64/libcrypto.so.6...done.
> Loaded symbols for /lib64/libcrypto.so.6
> Reading symbols from /usr/lib64/libisccc.so.50...done.
> Loaded symbols for /usr/lib64/libisccc.so.50
> Reading symbols from /usr/lib64/libisc.so.50...done.
> Loaded symbols for /usr/lib64/libisc.so.50
> Reading symbols from /usr/lib64/mysql/libmysqlclient.so.15...done.
> Loaded symbols for /usr/lib64/mysql/libmysqlclient.so.15
> Reading symbols from /lib64/libcrypt.so.1...done.
> Loaded symbols for /lib64/libcrypt.so.1
> Reading symbols from /usr/lib64/libldap-2.3.so.0...done.
> Loaded symbols for /usr/lib64/libldap-2.3.so.0
> Reading symbols from /usr/lib64/liblber-2.3.so.0...done.
> Loaded symbols for /usr/lib64/liblber-2.3.so.0
> Reading symbols from /usr/lib64/libpq.so.4...done.
> Loaded symbols for /usr/lib64/libpq.so.4
> Reading symbols from /usr/lib64/libsqlite3.so.0...done.
> Loaded symbols for /usr/lib64/libsqlite3.so.0
> Reading symbols from /lib64/libcap.so.1...done.
> Loaded symbols for /lib64/libcap.so.1
> Reading symbols from /lib64/libnsl.so.1...done.
> Loaded symbols for /lib64/libnsl.so.1
> Reading symbols from /lib64/libpthread.so.0...done.
> Loaded symbols for /lib64/libpthread.so.0
> Reading symbols from /usr/lib64/libxml2.so.2...done.
> Loaded symbols for /usr/lib64/libxml2.so.2
> Reading symbols from /usr/lib64/libz.so.1...done.
> Loaded symbols for /usr/lib64/libz.so.1
> Reading symbols from /lib64/libm.so.6...done.
> Loaded symbols for /lib64/libm.so.6
> Reading symbols from /lib64/libc.so.6...done.
> Loaded symbols for /lib64/libc.so.6
> Reading symbols from /usr/lib64/libkrb5.so.3...done.
> Loaded symbols for /usr/lib64/libkrb5.so.3
> Reading symbols from /usr/lib64/libk5crypto.so.3...done.
> Loaded symbols for /usr/lib64/libk5crypto.so.3
> Reading symbols from /lib64/libcom_err.so.2...done.
> Loaded symbols for /lib64/libcom_err.so.2
> Reading symbols from /usr/lib64/libkrb5support.so.0...done.
> Loaded symbols for /usr/lib64/libkrb5support.so.0
> Reading symbols from /lib64/libdl.so.2...done.
> Loaded symbols for /lib64/libdl.so.2
> Reading symbols from /lib64/libkeyutils.so.1...done.
> Loaded symbols for /lib64/libkeyutils.so.1
> Reading symbols from /lib64/libresolv.so.2...done.
> Loaded symbols for /lib64/libresolv.so.2
> Reading symbols from /lib64/libssl.so.6...done.
> Loaded symbols for /lib64/libssl.so.6
> Reading symbols from /usr/lib64/libsasl2.so.2...done.
> Loaded symbols for /usr/lib64/libsasl2.so.2
> Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
> Loaded symbols for /lib64/ld-linux-x86-64.so.2
> Reading symbols from /lib64/libselinux.so.1...done.
> Loaded symbols for /lib64/libselinux.so.1
> Reading symbols from /lib64/libsepol.so.1...done.
> Loaded symbols for /lib64/libsepol.so.1
> Reading symbols from /lib64/libnss_files.so.2...done.
> Loaded symbols for /lib64/libnss_files.so.2
> Core was generated by `/usr/sbin/named-sdb -u named'.
> Program terminated with signal 6, Aborted.
> [New process 9810]
> #0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
> (gdb) backtrace
> #0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
> #1  0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6
> #2  0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b  
> "mem.c", line=918, type=, cond=0x2adb292245b5  
> "ctx->stats[i].gets == 0U")
>  at ./main.c:166
> #3  0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
> #4  0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at  
> mem.c:1

Re: Core dumping DLZ

2009-05-07 Thread Scott Haneda


On May 7, 2009, at 6:51 PM, Mark Andrews wrote:

In message <8b717588-3e36-4596-9b11-de03e1ca4...@newgeo.com>, Scott  
Haneda writ

es:

On May 7, 2009, at 6:08 PM, Scott Haneda wrote:


What can a core dump tell me to help trace this issue down and solve
it?  Named is going deaf/dead for some reason, perhaps related, I  
need

it to keep up.


I did a little searching and found how to look into the core dumps,
here is what is happening.  How can I solve this?

r...@host [core_dumps:] $ gdb /usr/sbin/named-sdb core.9810
GNU gdb Fedora (6.8-27.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later stats[i].gets == 0U")
at ./main.c:166
#3  0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
#4  0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at
mem.c:1067
#5  0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./
main.c:1064


This is indicative of a memory / reference leak being
detected on shutdown.


Hi Mark, thanks.  No one ever shuts down the server/process/app, so  
something else must be causing that.  Would that mean this particular  
core dump is a result of some other crash causing it to shut down?


Is this http://people.redhat.com/atkac/bind/ the only place I can get  
a srpm for dlz/sdb?  Sorry, I am not familiar with rpm or red hat, and  
just need to do my best to resolve this, or find a consultant who can  
help me resolve this.


I will go explore the other core dumps and see if they tell anything  
more interesting.  Thanks for your help.

--
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

Re: Core dumping DLZ

2009-05-07 Thread Scott Haneda


On May 7, 2009, at 6:51 PM, Mark Andrews wrote:


(gdb) backtrace
#0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
#1  0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6
#2  0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b
"mem.c", line=918, type=, cond=0x2adb292245b5
"ctx->stats[i].gets == 0U")
at ./main.c:166
#3  0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
#4  0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at
mem.c:1067
#5  0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./
main.c:1064


This is indicative of a memory / reference leak being
detected on shutdown.



I just had two more happen.  This is not even a production server as  
of yet, it is being readied for that though.  There should be very  
little hitting named-sdb at this point...


(gdb) backtrace
#0  0x2af5a089fdfb in ?? () from /usr/lib64/mysql/ 
libmysqlclient.so.15
#1  0x2af5a08a0179 in my_net_read () from /usr/lib64/mysql/ 
libmysqlclient.so.15
#2  0x2af5a0899922 in cli_safe_read () from /usr/lib64/mysql/ 
libmysqlclient.so.15
#3  0x2af5a089a9f9 in ?? () from /usr/lib64/mysql/ 
libmysqlclient.so.15

#4  0x2af5a0898f9e in mysql_real_query ()
   from /usr/lib64/mysql/libmysqlclient.so.15
#5  0x2af59f09c67a in mysql_get_resultset (zone=0x4542f960  
"ns1.*.com",
record=, client=0x0, query=4,  
dbdata=0x2af59f3391e0,

rs=0x4542f918) at ../../contrib/dlz/drivers/dlz_mysql_driver.c:324
#6  0x2af59f09c80b in mysql_findzone (driverarg=out>,

dbdata=0x2af59f3391e0, name=0x4542f960 "ns1.**.com")
at ../../contrib/dlz/drivers/dlz_mysql_driver.c:515
#7  0x2af59f7c8353 in dns_sdlzfindzone (driverarg=0x2af59f2fc410,
dbdata=0x2af59f3391e0, mctx=0x2af59f2ea6c0, rdclass=1,  
name=0x4542fdf0,

dbp=0x45430058) at sdlz.c:1461
#8  0x2af59f72cf22 in dns_dlzfindzone (view=0x2af59f3d8d20,  
name=0x2afda090,

minlabels=3, dbp=0x45430058) at dlz.c:294
#9  0x2af59f06add4 in query_getdb (client=0x2afd1b20,  
name=0x2afda090,
qtype=, options=0, zonep=0x45431050,  
dbp=0x454310b8,

versionp=0x45431058, is_zonep=0x454310cc) at query.c:925
#10 0x2af59f06fe92 in query_find (client=0x2afd1b20,  
event=0x0, qtype=1)

at query.c:3805
#11 0x2af59f0735cd in ns_query_start (client=0x2afd1b20) at  
query.c:5095

#12 0x2af59f06026d in client_request (task=,
event=) at client.c:1898
#13 0x2af5a0629e2c in run (uap=) at task.c:862
#14 0x2af5a1ae2367 in start_thread () from /lib64/libpthread.so.0
#15 0x2af5a259f0ad in clone () from /lib64/libc.so.6

This looks MySql related.  I have mysql query logging enabled, so I  
can see what comes in.  So far, nothing looks malformed, which is a  
sure fire way to make one of these core dumps happen.

--
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

Re: Core dumping DLZ

2009-05-07 Thread Mark Andrews


In message , Scott Haneda writ
es:
> On May 7, 2009, at 6:51 PM, Mark Andrews wrote:
> 
> > In message <8b717588-3e36-4596-9b11-de03e1ca4...@newgeo.com>, Scott  
> > Haneda writ
> > es:
> >> On May 7, 2009, at 6:08 PM, Scott Haneda wrote:
> >>
> >>> What can a core dump tell me to help trace this issue down and solve
> >>> it?  Named is going deaf/dead for some reason, perhaps related, I  
> >>> need
> >>> it to keep up.
> >>
> >> I did a little searching and found how to look into the core dumps,
> >> here is what is happening.  How can I solve this?
> >>
> >> r...@host [core_dumps:] $ gdb /usr/sbin/named-sdb core.9810
> >> GNU gdb Fedora (6.8-27.el5)
> >> Copyright (C) 2008 Free Software Foundation, Inc.
> >> License GPLv3+: GNU GPL version 3 or later  ml
> >>
> >>
> >> [snip.. loading symbols]
> >>
> >> Loaded symbols for /lib64/libsepol.so.1
> >> Reading symbols from /lib64/libnss_files.so.2...done.
> >> Loaded symbols for /lib64/libnss_files.so.2
> >> Core was generated by `/usr/sbin/named-sdb -u named'.
> >> Program terminated with signal 6, Aborted.
> >> [New process 9810]
> >> #0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
> >> (gdb) backtrace
> >> #0  0x2adb2b0e0215 in raise () from /lib64/libc.so.6
> >> #1  0x2adb2b0e1cc0 in abort () from /lib64/libc.so.6
> >> #2  0x2adb27c4c9e0 in assertion_failed (file=0x2adb2922428b
> >> "mem.c", line=918, type=, cond=0x2adb292245b5
> >> "ctx->stats[i].gets == 0U")
> >> at ./main.c:166
> >> #3  0x2adb29202488 in destroy (ctx=0x2adb27ece6c0) at mem.c:918
> >> #4  0x2adb29202755 in isc_mem_destroy (ctxp=0x2adb27ea0340) at
> >> mem.c:1067
> >> #5  0x2adb27c4dc78 in main (argc=0, argv=0x7fff82e7e928) at ./
> >> main.c:1064
> >
> > This is indicative of a memory / reference leak being
> > detected on shutdown.
> 
> Hi Mark, thanks.  No one ever shuts down the server/process/app, so  
> something else must be causing that.  Would that mean this particular  
> core dump is a result of some other crash causing it to shut down?

I beg to differ.  Named only gets to this position in the
code if it has been told to shut itself down.  Note this
may happen as a side effect of shutting the machine itself
down.
 
> Is this http://people.redhat.com/atkac/bind/ the only place I can get  
> a srpm for dlz/sdb?  Sorry, I am not familiar with rpm or red hat, and  
> just need to do my best to resolve this, or find a consultant who can  
> help me resolve this.
> 
> I will go explore the other core dumps and see if they tell anything  
> more interesting.  Thanks for your help.
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *
> 
-- 
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

could not mark server as lame: out of memory Errors

2009-05-07 Thread Raghvendra1 . Singh

Hi 

We are getting  "could not mark server as lame: out of memory" Errors 
Intermetemtly  in DNS bind version BIND 9.4.3 on Solaris 


08-May-2009 11:52:57.090 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:07.204 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:08.004 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:08.237 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:08.281 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:08.610 resolver: could not mark server as lame: out of 
memory
08-May-2009 11:53:08.943 resolver: could not mark server as lame: out of 
memory

can someone help us to find exact cause of this error and how we can 
eliminate this issue 

raghav
This e-mail and any files transmitted with it are for the sole use of the 
intended recipient(s) and may contain confidential and privileged information. 
If you are not the intended recipient, please contact the sender by reply 
e-mail and destroy all copies and the original message. Any unauthorized 
review, use, disclosure,dissemination, forwarding, printing or copying of this 
email or any action taken in reliance on this e-mail is strictly prohibited and 
may be unlawful.
The recipient acknowledges that Bharti Airtel Limited or its subsidiaries and 
associated companies(collectively "Bharti Airtel Limited"),are unable to 
exercise control or ensure or guarantee the integrity of/overthe contents of 
the information contained in e-mail transmissions and further acknowledges that 
any views expressed in this message are those of the individual sender and no 
binding nature of the message shall be implied or assumed unless the sender 
does so expressly with due authority of Bharti Airtel Limited. Before opening 
any attachments please check them for viruses and defects.

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

Re: tcp versus udp

Delegation not working

Re: Delegation not working

RE: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

RE: Delegation not working

Re: Delegation not working

RE: Delegation not working

Re: Delegation not working

Core dumping DLZ

Re: Core dumping DLZ

Re: Core dumping DLZ

Re: Core dumping DLZ

Re: Core dumping DLZ

Re: Core dumping DLZ

could not mark server as lame: out of memory Errors

30 matches

Site Navigation

Mail list logo

Footer information