Creating a nameserver pointing to another nameserver... is it slower? - dns

I'm creating a project on Microsoft Azure. We only get a nameserver instead of an IP address. Since I have multiple domains pointing to Azure, I would like to redirect all my domains to a nameserver that is redirecting to Azure. This way, if Azure change my nameserver, I’ll only have to change one nameserver instead of changing it for all my domains.
However, is it a bad practice to create a nameserver pointing to another nameserver. Is it slower to resolve the IP address ?
Thank you !

I guess you mean having NS records point to a CNAME record?
It's not allowed. However, it usually works. Doing this has always been discouraged but the original DNS specification was never perfectly clear about it.
RFC 2181 clarifies that it is not allowed, and RFC 1912 is relevant too. This ServerFault question contains more details and is where I found the refences to those two RFCs.
Nonetheless, it "usually" works (but I wouldn't recommend doing it). In answer to your question, yes, it will be slightly slower (there's an extra name that must be resolved) but not significantly, and resolvers will cache everything after the first time anyway.

Related

Defining two sub domains of my domain as nameservers of another domain

Suppose that I own example.com that is served by my own DNS server and I can create every records that I want.
Now imagine that one of my friends get a new domain called new-domain.com and I want to help him manage his domain with his own DNS server.
So in my dns system for example.com, I create two A records as:
my.ns1.example.com -> some.ip.addr
and
my.ns2.example.com -> some.ip.addr
(some.ip.addr is the ip address of his DNS server)
and ask him to set my.ns1.example.com and my.ns2.example.com as name servers for his domain.
But he cannot set them because it gets invalid nameserver error!
Its my understanding that because example.com is working properly in DNS system and thus my.ns1.example.com and my.ns2.example.com are resolved to the IP address properly, so nothing can prevent them to be used as nameservers.
I searched around and found that some people say the nameservers should be registered. I understand registering when we have to ask for setting glue records, but for this case I have no idea why would we need to register those name.
To be more specific with real life example, why would jobs.ns.cloudflare.com is a valid nameserver but www.cloudflare.com is not?
I asked the same question on serverfault.com with this link
There, I quote important part of the answer here,
From a pure DNS perspective, an authoritative nameserver (such as those for com) should not perform any kind of recursion to learn the IP address of the nameservers that are defined in your example.com zone. Instead, the registry permits registrars to add glue records to the com domain, and those registrars can provide a user interface so that the owners of the domains that these custom nameservers live in can do so. (example: Namecheap - How do I register personal nameservers for my domain?)
(To address the elephant in the room...no, these glue records are not strictly required. But policies are policies, and if the registrar interface requires the registry level glue to be present, you have little choice in the matter.)
While the answer does not answer my updated part of the question, I picked it as the answer and decided to ask another question.
The problem does not lie in the names: my.ns1.example.com and my.ns2.example.com are fine.
The registry, and sometimes even the registrar, normally perform a few checks before approving a nameserver change. If your nameservers are rejected as invalid they are most likely not yet correctly configured for your friend's domain. I mean, the servers at my.ns1.example.com and my.ns2.example.com do not contain the minimum required records for new-domain.com.
That said, the registrar support team should be able to provide more details: if it's them who reject the change they should let you know what part of the automatic tests fails and even provide the test output so you can see by yourself. On the other hand, if they just pass the change to the registry (your friend should see a "operation pending at registry level" notice in his control panel for some time) they could do the extra effort of helping you out by providing hints based on their experience with that particular TLD. That is, if your friend didn't grab a promo offer in the 0.99$-5.99$ a year range for the domain: if he pays them something in the 20$-50$ a year range then he should expect and demand a proper, helpful support. I use one of the cheapest registrars and if my nameserver change gets rejected I still get a full report:
Dear customer,
The registry did not accept the nameservers you tried assigning to
new-domain.com because they did not pass the registry tests. Please
check the report we got from the registry below, fix the errors
and try assigning the nameservers again.
Nameservers Resolvable Test: ERROR
my.ns1.example.com. ERROR Unresolvable host my.ns1.example.com.
my.ns2.example.com. ERROR Unresolvable host my.ns2.example.com.
my.ns3.example.com. OK
my.ns4.example.com. OK
SOAQueryAnswerTest: ERROR
my.ns1.example.com. ERROR java.net.SocketTimeoutException
my.ns2.example.com. ERROR java.net.SocketTimeoutException
my.ns3.example.com. OK
my.ns4.example.com. OK
... ... ...
Update: The OP posted an update saying that as soon as the nameservers were registered with the registry, they were accepted in his friend's control panel. It appears that particular registrar checks for glue records and rejects the nameservers if they have none. This is an unnecessary check because glue records are only needed if the nameservers are within the same domain they serve, as explained in these questions. Registrars usually explain this very clearly or at least mention this above the nameserver change form:
Please note that in most cases the ip address is not required and will actually be ignored. It is only necessary if the nameservers you are entering are sub-domains of the selected domain (also called custom nameservers or vanity nameservers).
We can conclude that the friend's registrar performs an unnecessary blocking test and does not respond to user inquiries in a helpful matter. Since the OP has the following need (citation from his updated post on serverfault):
I need to be able to create dynamic nameservers programmatically and ask my users to enter their specific nameservers for their domains in their registrars.
I warmly recommend he does some research looking for a decent and reasonably priced registrar he can point his customers/friends to in case they have any issues with their current ones.

Why does getaddrinfo sometimes behave differently with "example.com" and "www.example.com"?

This is a code example from MSDN: getaddrinfo.
You can use "baidu.com" and "www.baidu.com" to test.
Because baidu.com and www.baidu.com are different addresses!
www.example.com is registered in DNS with an A type record (or a CNAME, which points to an A record - this is slightly simplified) An A record is a name, in this case www that points to an IP Address 12.34.56.78. (as I'm sure you already know!)
example.com can also have an A record registered (though not a CNAME) this is called the Apex (or naked!) domain. example.com's A record could very well point to 123.45.67.89
A little history
Part of the reason that this came about, is that in the early days of the internet, a server would have a hostname of something like LOCUS.UC.EDU because it can be difficult to know what services LOCUS might provide. you could attach the CNAME FTP.UC.EDU to point to that machine. that way people knew what services it offered. at that point, www was just another service, it had no special place in the collective consciousness. (all of this was happening over the decade or two that the internet was developing!) but you could also quite probably want bob#UC.EDU to work. so UC.EDU needed to be a host name also
In actual fact it started with just the hostname (and host records that got telexed - I do love that fact) - but we'll ignore that for this case.
back to the facts
What usually - should - happen is that there is an A record registered at the Apex and a CNAME registered at www But there is certainly no requirement for this and you can have whatever records you wish at your domain.

Advanced DNS settings for BIND regarding a sub domain for my local home network that integrates nicely into its parent domain (on an external network)

The intent of this post is that I ran into things I had a hard time understanding and wish to implement things in a more professional and objectively better way. Some of my choices I simply don't know to be good or bad. I believe the open questions are very instructive for people that can follow documentation to set up a working local DNS server - but wish to understand and learn how things are done the right way. Hence I opted to ask here!
I have a domain sakujo.tld and use namecheap's FreeDNS service as the authorized DNS. I configured entries for the following host.domains in their zone configuration
nas.home.sakujo.tld, gateway.home.sakujo.tld (A record via DDNS via curl via cron to my router)
vps.sakujo.tld (A record to my VPS on lowendspirit)
*.home.sakujo.tld, home.sakujo.tld (they map to CNAME gateway.home.sakujo.tld)
mysql, ns01, nzbget, sonarr (.sakujo.tld) (they map to CNAME nas.home.sakujo.tld)
So far so good and very simple. I run a home NAS based on Arch linux on an eeePc that can handle quite a lot of things at once apparently. One of them is now a bind installation. My intent is to override home.sakujo.tld and all its hosts but apparently I have to introduce quite a bit of redundancy to achieve those things.
The need for a second zone
I want to achieve a set-up, naively speaking like this
gateway IN A 192.168.0.1
nas IN A 192.168.0.91
phone IN A 192.168.0.41
user2.phone IN A 192.168.0.42
tab IN A 192.168.0.43
htpc IN A 192.168.0.51
tv IN A 192.168.0.55
quad IN A 192.168.0.101
red IN A 192.168.0.111
I was hoping that a zone set up like this one would be all that is needed but sadly this turned out to be too naive and did not suffice. My hopes were that
nas.home.sakujo.tld (and gateway.home.sakujo.tld) would now resolve to 192.168.0.91 (and 192.168.0.1) instead of the DDNS A record on namecheap's external DNS.
That way, if I used mysql.sakujo.tld or for instance sonarr.sakujo.tld, a DNS look up would first find the canonical name (CNAME) nas.home.sakujo.tld (as it of course does) and I was hoping that that canonical name had an A record to now 192.168.0.91 as defined in the zone file above. Sadly, in reality, mysql or sonarr resolve to nas.home.sakujo.tld (which is fine and wanted), but that one still has the external A record as defined on namecheap (the place that also defined the CNAME for nas.home.sakujo.tld).
So in essence I had to set up a second zone. I already had home.sakujo.tld and now I added sakujo.tld. That new zone now uses all the info that is already defined in namecheap's configuration I have externally. It goes like this:
mysql IN CNAME nas.home
nzbget IN CNAME nas.home
sonarr IN CNAME nas.home (I can't seem to get code to work here, apologies)
But mysql, nzbget, sonarr already have the zone entries set on namecheap exactly this way. This seems redundant. Do I have to do this? Or can I make some vodoo entry somewhere on namecheap or in home.sakujo.tld and have it transfer/update/authority whatnot (I really don't understand things from here on out at all anymore, you probably noticed I tried to learn and understand everything that leads up to this point - from now on I am 5 years old).
The # and NS entries
First thing's quick: I don't know what to put into sakujo.tld # A record and just have it point to 127.0.0.1. Ideally I would just leave that entry out as I don't have anything that makes sense to map sakujo.tld to.
Next on, I am told / need to add these lines into the zones to make them "good"
$TTL 30
; home.sakujo.tld
# IN SOA ns01.home.sakujo.tld. postmaster.home.sakujo.tld. (
2015041917 ; Serial
28800 ; Refresh
1800 ; Retry
604800 ; Expire - 1 week
86400 ) ; Minimum
IN NS ns01
IN NS ns02
ns01 IN A 192.168.0.91
ns02 IN A 192.168.0.91
# IN A 192.168.0.1
I know what the TTL is, the comment is probably irrelevant. I am sure I can look up the things in the brackets and I already know the Serial setting. My questions on this one are of more practical nature. Do I need all those entries?
both NS entries and both A records referring them?
The # A record?
The # SOA entry? (I understand this is a very likely yes - heck I ask because chances are this is related to the first paragraph)
I also tried to replace the A record for # with a CNAME entry to no avail. It would not resolve.
Either way, I read a lot that I should have two name servers. I guess it makes sense to set up another external DNS on a VPS? Is that trivial/would be identical to how I set up the first one? I guess there is a relation between the two ns01 entries and the appearance of ns01 in the SOA entry as well.
Are there best practices I am missing?
Are domains even supposed to be set up that way? I currently use two distinct kinds of entries
Unique FQDNs for physical/virtual hosts like nas.home.sakujo.tld for my NAS or tv.home.sakujo.tld for the tv (home being the location, a subnet) - so that is why for instance vps.sakujo.tld is not under home.
Aliases that are semantically labeled. Like mysql.sakujo.tld. This will be my main MySQL server - I currently only use a single db in a MariaDB installation. Or sonarr.sakujo.tld - so that should map to whichever physical machine hosts my Sonarr installation. The advantage of this is that in a year I might use another machine for the MySQL database so the references in my configuration and data should be agnostic of the physical/virtual host .
Maybe there are things I don't see? Even if it is things like "It's more common to name your router portal/router instead of gateway".
For posterity, I pasted my complete /etc/named.conf and zone files. Now that I mention that I don't really know if I need the allow-update and notify settings but that part of the documentation I am able to follow myself (I just thought I'd mention this in case there are questions about why I have them in, I simply don't know)
named.conf
named.conf
zone config
Now that I think about things it would be best to have the following nameservers set up
ns01.sakujo.tld pointing to nas.home.sakujo.tld
ns02.sakujo.tld pointing to the namecheap DNS
Can I use CNAMEs here? Do I have to set up ns0#.home.sakujo.tld as well? If so can I use CNAMEs there?
Edit
Somebody in #bind on freenode wondered why I was using a separate subdomain for my home network to begin with. He advised me to use views instead.
Is it not arbitrary whether I put the hosts on my local network into their own subdomain? After all they are in their own subnet, too and semantically speaking it seems to make sense.
I read up a bit on views, but his advise does not seem to apply to me on a first quick and naive glance. I mean I don't intend to expose my local DNS to the internet so there is no point in having separate zone configuration for different clients. I want all the zone configuration to apply to all clients that use the DNS.
Maybe he was suggesting to use views on namecheap's DNS instead? Would that even work? Also, how would namecheap tell whether I make the DNS request from my home network or an external network to begin with? After all mapping my hosts on home.sakujo.tld to 192.168.0.0/24 would not help all that much when I am not in my local subnet.

Is DNS lookup time affected by the use of subdomains and CNAME?

Is DNS lookup time slowed down by the use of subdomains and CNAME? As I understand it, if a client wants to lookup for example rweb.stat.ucla.edu at least four steps are needed:
[registrar] NS ucla.edu ==> ns2.dns.ucla.edu
[ns2.dns.ucla.edu] NS stat.ucla.edu ==> dns.stat.ucla.edu
[dns.stat.ucla.edu] CNAME rweb.stat.ucla.edu ==> id-86-243.stat.ucla.edu
[dns.stat.ucla.edu] A id-86-243.stat.ucla.edu ==> 128.97.86.243
Does this mean the client has to connect to each of these servers when visiting the page? Or do the DNS servers connect to each other and directly resolve (and cache) rweb.stat.ucla.edu ==> 128.97.86.243? Also it is not clear to me how much work is involved in finding the initial record for the root domain?
First of all, the registrar is never involved in the actual DNS lookup. Registrars (and indeed, registries) are administrative entities outside the scope of the DNS protocol. The actual lookup process looks more like this:
Ask root servers for A of rweb.stat.ucla.edu..
They won't tell you, but they'll point you to servers for edu..
Ask the edu. servers for A of rweb.stat.ucla.edu..
They won't tell you, but they'll point you to servers for ucla.edu.
Ask the ucla.edu servers for A of rweb.stat.ucla.edu..
stat.ucla.edu could be a zone that is delegated to yet another set of nameservers, in which case you'll get a referral answer for the third time.
But let't say it's not.
You get an answer: rweb.stat.ucla.edu. has CNAME id-86-243.stat.ucla.edu.
Now you have to start all over again and look up id-86-243.stat.ucla.edu...
...except that because the target of the CNAME is inside the same zone as the original record (or, in general, inside any zone that happens to be served from the same nameserver), the nameserver will helpfully give you the A record for id-86-243.stat.ucla.edu in the additional section of the DNS response. The resolver will notice this and won't have to run after the A record itself.
Because resolvers cache answers, many queries can be answered from the cache and don't actually have to be asked every time. Especially the first few steps of the query are all likely to be already cached by the resolver, except immediately after it starts up with a cold cache. So the resolver can probably usually start at step 3 (because it remembers what the nameservers for ucla.edu. are from its cache) or at least at step 2 (because it remembers what the nameservers for edu. are) if it doesn't already know the final answer.
So the short answer to your question is yes, using CNAME makes more work for the resolver and makes the resolution process take longer. But in practice it doesn't matter very much because the resolver's cache is so helpful. And if the CNAME's target is in the same zone as the CNAME record itself, it matters even less because of the helpful additional record.

How can (say) ns1.example.com be a name server of example.com?

Clearly I don't know much about DNS, so bear with me on this issue, which has been puzzling me me for a while.
Some WHOIS records show (say) ns1.example.com and ns2.example.com as name servers for example.com. Then how is the actual IP address found? Isn't this circular?
This question probably belongs on Severfault rather than Stackoverflow, but for the explanation you should read about glue records.
Name servers in delegations are
identified by name, rather than by IP
address. This means that a resolving
name server must issue another DNS
request to find out the IP address of
the server to which it has been
referred. If the name given in the
delegation is a subdomain of the
domain for which the delegation is
being provided, there is a circular
dependency. In this case the
nameserver providing the delegation
must also provide one or more IP
addresses for the authoritative
nameserver mentioned in the
delegation. This information is called
glue. The delegating name server
provides this glue in the form of
records in the additional section of
the DNS response, and provides the
delegation in the answer section of
the response.
There is also a nice explanation in this FAQ.
I hope this is taken the right way, but have a good read at this, particularly the section on "Domain Name Space" (even more specifically, "Domain name formulation").
http://en.wikipedia.org/wiki/Domain_Name_System
It explains the way in which a name is resolved and way, way more.

Resources