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?
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 fromtest.example.comand below to another name server. The normal place for the A record fortest.net-me.netwould be onns1.anotherdnshost.com.Now your question may be rephrased - is it OK to have
test.example.comA ...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.comdelegated tons1.anotherdnshost.com, records fortest.example.comand below, which happen to exist (for any reason) on any servers other thanns1.anotherdnshost.comare not authoritative anymore.Parent zone server, when it replies to
test.example.comquery, a) Must send the NS record pointing tons1.anotherdnshost.comand b) May or may not send A record fortest.example.comit 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 thattest.example.comis delagated, should consider only answers from it's authoritative server -ns1.anotherdnshost.com).I tested such configuration with bind9:
test.example.com A 1.1.1.1would 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
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:
On test.shadowrpg.net's nameserver (saber):
The first result, is with saber not configured, to show the referral.
And with saber configured:
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).
test.example.com A 2.2.2.2should be returned as it is the authoritative ("dominant").This setup does not violate RFCs.
Reasoning see in my longer answer here.
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.
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.