nameserver question

What I have so far is


i want to create the subdomain test.drhealy.com , so will this drhealy.com.zone file do it?

Thanks.

looks fine to me

for my own edification...

will a stubzone\slave record need to be created?, or is zone file modified?

If I have the right idea but wrong terminology, please clarify howto?

thanks...Frog

If the stub or slave zone file doesn't exist it will be created by BIND. The created file is only read if you restart BIND. Problems may result if you have BIND restarted while the slave zone file is empty or has some manually composed content in the file.

this doesnt seem to be working for me.

I have to add drhealy.com.zone to named.conf correct?

yep, lookin good. However, if you're needing help, just say so and I'll get into the drivers seat here to figure out what's wrong.

Sir, I require Help

i uploaded named.conf, and two of my zone files (i added the txt extension so your internet browser can see them)

named.conf.txt
tehw00t.net.zone (this acts as the nameserver as well)
drhealysdiet.net.zone (the domain i'm trying to add)

A friend is running a DynamicIP Service for DrHealy's Diet.net, so the order of the nameservers are:
NS1.tehw00t.net
ns2.wshost.net
ns3.wshost.net

If ns1.tehw00t.net fails (which it is doing), it'll bump down to wshost.net nameservers, which automatically DynDNS's to 66.90.103.215.

tehw00t.net works great, all the subdomains run etc, I just have problems with drhealysdiet.net .

Thanks.

Well, I think that you need to change the file:
drhealysdiet.net.zone.txt

from:

tehw00t.net. 14400 IN NS ns1.tehw00t.net.
tehw00t.net. 14400 IN NS ns2.tehw00t.net.

to:

drhealysdiet.net. 14400 IN NS ns1.tehw00t.net.
drhealysdiet.net. 14400 IN NS ns2.tehw00t.net.

heh, that's for sure. Make the change Mr. Bung and tell us if you have any more problems.

>> so the order of the nameservers are ...

Wrong terminology. No ordering.

>> If ns1.tehw00t.net fails (which it is doing), it'll bump down to wshost.net nameservers

Wrong. The query chance are even for all 3 (randomly). If one is knowingly to be unreliable in availability, just remove it.

I had done some testing in the past to see whether if downed dns servers really does cause resolution failures *randomly* depending on what server was picked. When BIND is acting as the resolver I have found that it would test the first server, after it times out, it will log the lame server to the logfile (if configured to do so) then try the next server. This causes a delay in resolution on the first access, and afterward the target IP is cached so it no longer causes the delay (until it expires from cache).

However, that is just now BIND does it. I agree with freebsd that having a dns server that is offline *may* cause reliability problems cause not all resolvers will gracefully handle them. I have seen in the past where a domain did not resolve for me (before I installed BIND) and found that 2 out of 3 dns servers that hosted that domain were offline.