Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

(Updated the post with more detailed example)

I have my domain: setup at DNS provider 1. Provider 1 has nameservers:


I want to delegate authority for to another DNS provider, provider 2, which has nameservers:


For this my zone at provider 1 looks like this: IN NS IN NS IN A IN NS IN NS

At provider 2 i setup the zone: as follows: IN NS IN NS IN A IN A

The test:

# i get a reply (OK here)
dig a     

# i don't get a reply for this (error)
dig a 

Is this normal ?

Update 2: For command dig a i get in the result the SOA record of domain

;            IN      A

;; AUTHORITY SECTION:              86400   IN      SOA 2011032805 28800 7200 604800 86400
share|improve this question
up vote 1 down vote accepted

I'd first make sure you're getting ns1/ back as an answer to this query:

dig ns

You might also want to check that the zone is loaded on the nameservers to which you've delegated. Check that you get a correct serial number back:

dig soa

If that isn't working, check with whomever is running ns1/ to make sure your zone is being loaded.

share|improve this answer
SOA looks fine: 14400 IN SOA 1301328368 10800 3600 604800 3600 – Catalin Mar 28 '11 at 16:37
The only thing I can think of is that your is not allowing delegations or is misconfigured. You can check that your zone is loaded correctly at the dns2 servers with dig -- if that is working then it's some delegation problem. Based on what your zone looks like, it's not clear why. I would check for typos or make sure you don't have $ORIGIN set since you don't appear to be using a trailing dot for your RR names. – Cakemox Mar 28 '11 at 20:21
I was seeing a similar issue today and traced it to Google's Public DNS service. e.g. this fails ==> dig +short @ a – danorton Jun 10 '13 at 0:36

In case anyone ever actually reads this article again, and is wondering what the resolution was, I second Jonathan Ross' comment.

On provider one, you added 2 NS records. But you didn't add 2 A records for those 2 NS records.

Without the A records on provider one, the 2 NS records are just names, that have no associated IP. So DNS requests for the subdomain can't make it to the NS for the subdomain. Because there is no IP associated with subdomain's NS record.

It may seem logical (until you understand these record differences, many "stories" you tell yourself make sense) to think "oh the IP will get resolved over at provider 2". The request doesn't make it to provider 2 (unless you of course open up dig or nslookup and connect directly to it).

Hope this helps...

share|improve this answer

Are you trying to Delegate the zone " to another NS? You only speak of NS1 and NS2 and from what you have specified you have Primary Forward Lookup Zones created for "" on each of those. If you want to delegate authority for "" to another name server:

  • Right click the "" zone on both NS1 and NS2 and setup a new delegation.
  • Use the zone name "test" and point to another name server you want to be authoritative for the "".
  • Setup a new Primary Forward Lookup zone on the new name server (NS3) for ""

If you are trying to delegate "" follow the same process but one domain level higher.

share|improve this answer
I have updated the post with more detailed example. I am trying this on Linux. I am trying to delegate only: to another NS. is now set up in the new zone only. – Catalin Mar 28 '11 at 16:32

Have you tried another tool like host -t a instead ?

dig is pretty tricky to use.

share|improve this answer
Dig is not the issue. The problem is if it's enough for a subdomain delegation to just do: IN NS entries. – Catalin Mar 28 '11 at 14:50
I see. You need A records too when you announce a hostname or subdomain because otherwise it's not pointing anywahere. As below "host" will say if the NS knows about the details. – Jonathan Ross Mar 28 '11 at 15:21

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.