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

Question

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?

score 7 · Answer 1 · answered Oct 28 '13 at 20:49

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

Regan · Accepted Answer · 2013-10-28T11:24:21.230

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

Is this something that's in the RFCs as I couldn't find anything before posting the question? If so, could you link to it? — F21, Oct 28 '13 at 10:46
I don't know where it is in the RFCs, but I have diagnosed a lot of broken DNS systems (I'm a consultant), this configuration as you described has happened before on accident, and it causes intermittent problems (depends which nameserver you hit, depends on which response you get). The subdomain pointing to another nameserver is very common, and is actually how ".com" works, com is a domain, and each "subdomain" of ".com" has it's own records, and you could cascade it as many as you wish. I'll look and see if I can dig up the reference in one of my books — Regan, Oct 28 '13 at 11:03
I let my fingers type faster than my thoughts in my answer, please recheck. Basically, once you set NS records, you are telling the world "I'm not the nameserver holding the records for this domain, please see X nameserver for the answers" — Regan, Oct 28 '13 at 11:11

score 1 · Answer 3 · answered Oct 29 '13 at 02:33

1

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.

answered Oct 29 '13 at 02:33

Sandman4

4,045
2
20
27

score 0 · Answer 4 · answered Oct 28 '13 at 09:47

That's not a valid setup, you won't never know where you will be redirected.

When you define the NS records on your domain, that DNS becomes the authority. If someone ask for your domain's IP, it will check his cache and if there is no record then It will ask to the DNS listed in your NS records.

And what happens now if you create another A record (2.2.2.2) to your domain in another DNS? Then all the clients that use that DNS, would get your "new" IP (2.2.2.2) and not the real one.

score 0 · Answer 5 · answered Oct 28 '13 at 11:19

0

It is completely valid, but not the way you're thinking.

Once you've delegated a subdomain to another set of name servers, they are authoritative. They may quite lawfully advertise an A record for the domain; indeed, it's normal practice to do so, see, eg dig google.com.

I have no idea what happens if you advertise the A record on the delegating name servers - nothing good, I suspect, as everyone else is rightly advising you. But to advertise such a record is perfectly valid on the delegated servers, which is probably why you can find no prohibition in the RFCs.

So the problem isn't in the existence of both A and NS records for a domain; it's in trying to advertise both those records from the same nameservers.

answered Oct 28 '13 at 11:19

MadHatter

78,442
20
178
229

See my test, it doesn't work at all, once an NS record is come across, you are referred on. In his question, he's trying to pass an A record for the subdomain AND list NS records for that same subdomain (test.example.com) The only time you can have both an A and NS record, is if the A record is FOR the resulting NS record destination (to have glue) – Regan Oct 28 '13 at 11:32
Please read what I wrote. Your comment is a good one, and doubtless right, but it doesn't relate to my answer. I understand that you've answered the question the OP ought to have asked, and answered it well (imo, +1 from me) - but I thought it worth answering the question (s)he **actually** asked: "*Is a subdomain with both A records and NS records valid?*". – MadHatter Oct 28 '13 at 11:53
I don't mean to argue, but I am missing something that you are mentioning. To have an A record and NS record to the same subdomain will only result in the NS record ever being used (it's just going to refer it on) If the delegating nameserver has both an A and NS record, that shouldn't be valid as the delegating server no longer has authority to return an A record. I also don't see where google does it. -- I am genuinely curious – Regan Oct 28 '13 at 12:15
Ok, I re-read your answer very carefully, ignoring what I know about the OP. While the information you provided is accurate, it's that in the OP, he's asking to have an A *and* NS record to the same subdomain (subzone) on a *delegating* nameserver, that part is invalid (meaning, it's a waste of a line, it doesn't cause an error per-say, but it won't ever return that A record so long as the NS record exists). – Regan Oct 28 '13 at 12:32
I completely agree with you. – MadHatter Oct 28 '13 at 14:05

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

5 Answers5