5

(Updated the post with more detailed example)

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

  1. ns1.dns1.com
  2. ns2.dns1.com

I want to delegate authority for subdomain.example.com to another DNS provider, provider 2, which has nameservers:

  1. ns1.dns2.com
  2. ns2.dns2.com

For this my zone at provider 1 looks like this:

example.com IN NS ns1.dns1.com
example.com IN NS ns2.dns1.com
example.com IN A 127.0.0.1
subdomain.example.com IN NS ns1.dns2.com
subdomain.example.com IN NS ns2.dns2.com

At provider 2 i setup the zone: subdomain.example.com as follows:

subdomain.example.com IN NS ns1.dns2.com
subdomain.example.com IN NS ns2.dns2.com
subdomain.example.com IN A 1.1.1.1
test.subdomain.example.com IN A 1.1.1.2

The test:

# i get a reply (OK here)
dig a subdomain.example.com     

# i don't get a reply for this (error)
dig a test.subdomain.example.com

Is this normal ?

Update 2: For command dig a test.subdomain.example.com i get in the result the SOA record of domain example.com.

;; QUESTION SECTION:
;test.subdomain.example.com.            IN      A

;; AUTHORITY SECTION:
example.com.              86400   IN      SOA     ns1.dns1.com. hostmaster.example.com. 2011032805 28800 7200 604800 86400
Catalin
  • 53
  • 1
  • 1
  • 4

4 Answers4

3

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...

Jackson
  • 31
  • 2
  • So I am in a bit of a pickle now. I have a control on the DNS zone. I have as a original poster: `example.com IN NS ns1.dns1.com; example.com IN NS ns2.dns1.com; example.com IN A 127.0.0.1; subdomain.example.com IN NS ns1.dns2.com; subdomain.example.com IN NS ns2.dns2.com;` But I do not have control over dns2.com. I get SERVFAIL if I do nslookup of subdomain.example.com. If I understood correctly Jackson's answer, I need to add IN A records. But I do not understand what should be added as A? IP address of the ns1.dns2.com (ip address of other dns nameserver)? – Nemanja Martinovic Oct 31 '18 at 11:40
  • I think this answer can be misleading - You would need to add A or AAAA records for the NS delegated servers *only* if this server is also authoritative for the domain of the delegated servers. In this example, this is not the case, as their domain is `dnsX.com` (not `dnsX.example.com`) – LCC Aug 11 '21 at 09:52
2

I'd first make sure you're getting ns1/2.provider-dns.com back as an answer to this query:

dig subdomain.example.com 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 @ns1.provider-dns.com subdomain.example.com soa

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

Cakemox
  • 24,141
  • 6
  • 41
  • 67
  • SOA looks fine: subdomain.example.com. 14400 IN SOA ns1.dns2.com. hostmaster.example.com. 1301328368 10800 3600 604800 3600 – Catalin Mar 28 '11 at 16:37
  • The only thing I can think of is that your dns1.com is not allowing delegations or is misconfigured. You can check that your zone is loaded correctly at the dns2 servers with `dig @ns1.dns2.com test.subdomain.example.com` -- if that is working then it's some delegation problem. Based on what your example.com 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 @8.8.8.8 2.0.0.127.zen.spamhaus.org. a* – danorton Jun 10 '13 at 00:36
0

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

  • Right click the "subdomain.example.com" 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 "test.subdomain.example.com".
  • Setup a new Primary Forward Lookup zone on the new name server (NS3) for "test.subdomain.example.com"

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

HostBits
  • 11,776
  • 1
  • 24
  • 39
  • I have updated the post with more detailed example. I am trying this on Linux. I am trying to delegate only: subdomain.example.com to another NS. test.subdomain.example.com is now set up in the new zone only. – Catalin Mar 28 '11 at 16:32
-2

Have you tried another tool like host -t a test.subdomain.example.com instead ?

dig is pretty tricky to use.

Jonathan Ross
  • 2,173
  • 11
  • 14
  • 1
    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 me.com ns1.you.com" will say if the NS knows about the details. – Jonathan Ross Mar 28 '11 at 15:21