Re: Core dumping DLZ

On Thu, May 07, 2009 at 09:20:28PM -0700, Scott Haneda wrote: > 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_fai

no NS but having A record

Hello, For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand entirely.. Thanks. # dig www.gdpu.cn ; <<>> DiG 9.5.0-P2 <<>> www.gdpu.cn ;; global options: printcmd ;; Got answer:

Re: no NS but having A record

Is it still happening? Can you show dig output for "dig gdpu.cn ns" On May 11, 2009, at 2:56 AM, Tech W. wrote: Hello, For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand enti

Re: no NS but having A record

On May 11, 2009, at 2:56 AM, Tech W. wrote: For this domain, gdpu.cn, I tried to find its ns record: dig gdpu.cn ns with no results. But I can dig its www record as below. why this happened? I can't understand entirely.. Thanks. Actually, here is what I get back: $dig gdpu.cn ns ; <<>> Di

Re: no NS but having A record

Hi, Firstly the DNS serveres for that domain is not mastered by me. I got the NS dig info as below. You can see, if I specify another public DNS (211.66.80.161), the results can be fetched. If I don't specify a DNS (use the default one 202.96.128.143 of my ISP), dig gets nothing. So I'm really

Re: no NS but having A record

The zone appears to be configured incorrectly. That is why your results and Scott's are so odd. I'll explain below, but in summary, the name servers to which the zone is delegated have what appears to be rubbish records. Specifically these: gdpu.cn.3600IN NS gdpu.cn.

Re: no NS but having A record

Thanks Kal. That let things be clear. --- On Mon, 11/5/09, Kal Feher wrote: > > Note that the reason your queries fail is because name > servers are supposed > to assume that the apex of the zone contains the most > correct data. > Therefore if the 2 name servers to which this zone is > delega

looking for reference to correct behavior

My apologies if this is considered to be too off-topic. I have a situation where my company uses a number of servers with a commercial DNS implementation (in addition to our BIND servers). The other implementation is Windows DNS, and there is some behavior that I do not think is acceptable,

Re: looking for reference to correct behavior

The "resolver algorithm" in RFC 1034, Section 5.3.3, states 1. See if the answer is in local information, and if so return it to the client. and is further detailed as Step 1 searches the cache for the desired data. If the data is in the cache, it is assumed to be goo

Several basic questions (and yes, I've looked at the documentation on the web)

What there is of it. It seems VERY outdated since, if I understand correctly, DLZ is now built into bind 9.5/9.6. I have downloaded and installed the following RPMs to my DNS server, which is a VM running RHEL 5.2: bind-9.5.1-2.P2.el5.pp.x86_64.rpm bind-libs-9.5.1-2.P2.el5.pp.x86_64.rpm bind-

Re: socket.c:4524: unexpected error

Jeremy C. Reed wrote: On Sat, 9 May 2009, WPPi Photo wrote: I've been seeing more and more of the following errors in all of our name servers running Bind 9.4.3-2 on CentOS 5.3 servers: Is that a CentOS or Red Hat package? Can you provide the spec files for it? It's actually a RPM

Re: Several basic questions (and yes, I've looked at the documentation on the web)

You may also want to take this to the DLZ users mailing list, I am really not sure the correct channel for these questions. I end up cross posting, which is probably not a good idea. On May 11, 2009, at 3:25 PM, Mike Toler wrote: What there is of it. It seems VERY outdated since, if I unde