My Clients page cannot be accessed..

I have checked the client directory, the symbolic link "public_html" which points to the domain/....com/public_html is backgrounded with red.

And the user's domain cannot be readed or pinged. the user domain is under my domain which is abc.hkjzone.com

Is the symbolic link causing errors??

Thanks!

Possibly. Recreate the slink manually and it may work.

I have tried to remove the old link and create a new link using "ln -s" but.. the domain still cannot be dound by dns..

Has the domain propagated? Do the proper zone entries exist? (namely the *.domain.com A record?)

I'm not sure. Certainly no DNS guru here

l0rdphi1 said:

Has the domain propagated? Do the proper zone entries exist? (namely the *.domain.com A record?)

I'm not sure. Certainly no DNS guru here

Click to expand...

The domain should be propagated, there are nearly 3 days since the creation of domain, I use the "create user" inside reseller panel to create the account! ..

Hello,

Which means there is a typo in the NS lines.. you need to add a dot to the end of the NS values or else hkjzone.com. will be added to the end.

John

Thanks John, however, I would like to know what's the actual usage of the NS field in DirectAdmin?

It doesn't really "change" the nameserver of the domain, but it does affect the DNS server, what's going on?

I'll let Jeff (or someone else) answer if they know. I think it's just to confirm everything and another source for the info, but I'm not too sure.

John

For a definition, look here.

Men And Mice (who runs that site) is a recognized DNS authority .

Jeff

Thanks Jeff and John!

But what is actually effected if I set it wrontly?

And, if ns1.abc.com and ns1.hello.com both set to the same IP, the DNS of the server is set to be "ns1.abc.com". What if the NS record is set to be "ns1.hello.com" ?

Sorry I am not too familiar with DNS stuffs~

If it's incorrect several bad things happen, some of which may not be important to you:

One, since you're listing nameservers that aren't authoritative as authoritative for your domains, anyone who needs to trace or troubleshoot bad dns performance won't be able to.

Two, anyone who looks up your dns in dnsreport.com (for example your customers or prospective customers who may have experienced problems finding their site or your site because you're not running redundant DNS) will find out that the nameservers you report as authoritative aren't and the ones that are authoritative aren't reported as authoritative.

Three, any time you or anyone else tries to troubleshoot your DNS chain using dig won't be able to because the information dig returns will be invalid.

Four, slave nameservers, if any, won't be able to get zone transfers, while the nameservers you list will, even though they've got no reason to.

Five, any time you have a DNS problem you'll find that no one will be able to help you until you are willing to do it right.

DNS is the world's largest distributed database. Just because it's resilient is no reason for you to work hard to intentionally break it.

This is the last time I intend to justify doing it right in this thread. I hope you took the time to understand the link I sent you, and all the other links from that link... the link page is simply an authoritative dictionary. And all the words in the listed definition are available for definition in other links as well.

The people behind
"Men and Mice" are world renowned experts in DNS and I trust both them and their explanations.

Before you ask me to explain anything further, please take the time to read either the book "DNS and Bind" or the book "Linux DNS Server Administration"; both are excellent introductions to using "bind" (the program DA uses for DNS) for DNS administration. If you have a choice, "Linux DNS Server Administration" is probably an easier read.

Thanks.

Jeff

Lo and behold, I just found a discussion on the bind-users list (maintained by the company that wrote bind), which explains another serious problem resulting from the same issue:

People may not be able to send you email. This post response comes from the DNS administrator of a large international automobile manufacturer, who is well known for his knowledge of DNS. Note that I've obfuscated the real domain names involved:

<snip>
When the A records for ns[12].example.com expire from the cache
before the zone NS records expire, then the caching resolver is put into
the chicken-and-egg situation of having NS records for the zone --
therefore knowing that it *should* be able to fetch the A records of
ns[12].example.com from those nameservers -- but not knowing
the A records of the nameservers themselves. Then, if it goes up and
asks the parent for the glue, the parent doesn't know either, since it
only has glue records for dns[12].example.com, not
ns[12].example.com. Eventually the zone NS records expire from
cache, everything starts with a clean slate, the referral is followed,
the query is resolved, results are cached and the whole cycle starts
again...
</snip>

Jeff

Thanks Jeff!
will take time to get into it.