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
0
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
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->st
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 rea
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 kee
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 happ
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.
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
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 Bernhard
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 c
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 an
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.
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 you
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
;; QUESTIO
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
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
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 appl
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:
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.
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
;
+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 configu
+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
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
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:
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,
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<<- opc
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]
Se
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:
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,
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)
;; glob
30 matches
Mail list logo
