Is a subdomain with both A records and NS records valid?

Let's say I own example.com.

I then create an A record on test.example.com to 1.1.1.1.

I then create a NS record on test.example.com to ns1.anotherdnshost.com.

At another DNS host, I add an A record for the root (test.example.com) to 2.2.2.2.

When the client queries test.example.com, which A record will be returned? Which would be the more "dominant" A record? Is a setup like this valid?

Solution 1:

This is not valid, no. It will probably return the 1.1.1.1 as it would get returned by the first server that resolves but the "correct" value should be whichever nameserver is registered as the primary by the SOA record. But, what gets returned may depend on which version of nameserver software is run. See below, it will just forward it on to the next nameserver, and 1.1.1.1 will never get shown.

Now it IS correct to list other NS records in your zone, but the other NS should be nameservers with identical zones. You can point your subdomains to alternate nameservers however.

So example.com by your registrar points to ns1.example.com and ns2.example.com with 1.2.3.4 and 2.3.4.5 IPs from the registrar nameserver (glue).

You would then have a zone with the SOA choosing ns1 or ns2 as the primary, and then you would have two NS records pointing to ns1.example.com and ns2.example.com with the A records for that domain (and mx, txt, cname, etc).

Both NS1 and NS2.example.com should have identical zones and they should replicate to each other automatically.

Now it IS valid, to take test.example.com and point that to ns1.somethingelse.com and ns2.somethingelse.com but NO A records for test.example.com on ns1 and ns2.example.com's nameservers, except ns1 and ns2.example.com should automatically send the IPs for ns1 and ns2.somethingelse.com if it has glue. (It won't if the TLD is different, ie .com and .org)

I hope that all made sense, I can clarify more if any of it is confusing.

Here's a test of what happens:

On shadowrpg.net's nameserver:

$ttl 38400
@   IN  SOA shell2.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  shell2.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.1
test.shadowrpg.net. IN  NS  saber.reganw.com.

On test.shadowrpg.net's nameserver (saber):

$ttl 38400
@   IN  SOA saber.reganw.com. root.shell2.reganw.com. (
            1298345653
            10800
            3600
            604800
            38400 )
@   IN  NS  saber.reganw.com.
test.shadowrpg.net.     IN  A   127.0.0.2
test.shadowrpg.net. IN  NS  saber.reganw.com.

The first result, is with saber not configured, to show the referral.

[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  G.ROOT-SERVERS.NET.
.           518400  IN  NS  C.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  a.gtld-servers.net.
net.            172800  IN  NS  m.gtld-servers.net. (snip)
;; Received 493 bytes from 199.7.83.42#53(199.7.83.42) in 55 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.35.51.30#53(192.35.51.30) in 54 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 2123 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 81 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 82 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; BAD (HORIZONTAL) REFERRAL
;; Received 110 bytes from 173.45.238.245#53(173.45.238.245) in 112 ms

And with saber configured:

^C[regan@gamma ~]$ dig +trace test.shadowrpg.net

; <<>> DiG 9.7.3-P1-RedHat-9.7.3-2.P1.fc13 <<>> +trace test.shadowrpg.net
;; global options: +cmd
.           518400  IN  NS  L.ROOT-SERVERS.NET.
.           518400  IN  NS  J.ROOT-SERVERS.NET. (snip)
;; Received 512 bytes from 127.0.0.1#53(127.0.0.1) in 2 ms

net.            172800  IN  NS  m.gtld-servers.net.
net.            172800  IN  NS  a.gtld-servers.net. (snip)
;; Received 493 bytes from 198.41.0.4#53(198.41.0.4) in 129 ms

shadowrpg.net.      172800  IN  NS  ns1.reganw.com.
shadowrpg.net.      172800  IN  NS  ns2.reganw.com.
shadowrpg.net.      172800  IN  NS  ns3.reganw.com.
;; Received 232 bytes from 192.12.94.30#53(192.12.94.30) in 165 ms

test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 110 bytes from 209.161.6.3#53(209.161.6.3) in 38 ms

test.shadowrpg.net. 38400   IN  A   127.0.0.2
test.shadowrpg.net. 38400   IN  NS  saber.reganw.com.
;; Received 126 bytes from 173.45.238.245#53(173.45.238.245) in 80 ms

[regan@gamma ~]$ 

So once you add an NS record, it refers it on, and it ignores any query to itself. Now if you add an A record for the nameserver, it will pass with the NS record as a glue (so the resolver doesn't have to then look up the IP for the new nameserver).

Solution 2:

This issue is somewhat subtle, so let me explain one-by-one.

The correct configuration would be of course to have only one of the two - either NS or any other records.

When you add NS record for test.example.com, you delegate everything from test.example.com and below to another name server. The normal place for the A record for test.net-me.net would be on ns1.anotherdnshost.com.

Now your question may be rephrased - is it OK to have test.example.com A ...in the "parent" example.com zone ? The same question may be asked regardless of any records which may exist or not in thedelegated` zone on anotherhost.

My answer will be dialectic :) 1. Yes, it is OK to have such records in the "parent" zone. But 2. Since test.example.com delegated to ns1.anotherdnshost.com, records for test.example.com and below, which happen to exist (for any reason) on any servers other than ns1.anotherdnshost.com are not authoritative anymore.

Parent zone server, when it replies to test.example.com query, a) Must send the NS record pointing to ns1.anotherdnshost.com and b) May or may not send A record for test.example.com it happens to have, c) even if it does sends the record, it must not flag it as an "authoritative" answer, d) even if it lies and flags such answer as authoritative, resolver which receives such a reply, since it knows that test.example.com is delagated, should consider only answers from it's authoritative server - ns1.anotherdnshost.com).

I tested such configuration with bind9:

• named, nor named-checkzone does not complains on such a zone - apparently this zone considered correct.
• When I query parent server for test.example.com, it returns only NS records, like if the test.example.com A 1.1.1.1 would not exist at all.

Other DNS servers software may behave differently, but anyway must obey general rules above.

This related article by Verisign helped me understand this issue.

I am sorry for all the blah blah blah

Solution 3:

test.example.com A 2.2.2.2 should be returned as it is the authoritative ("dominant").

This setup does not violate RFCs.

Reasoning see in my longer answer here.