I think the question is why other domains use different nameservers. I’m also no DNS expert, but I don’t see why those domains couldn’t use the same nameservers.
They’re on completely different separate servers in my case.
webehostin.com. has 3 delegation NS records (with 1 IP) and 29 authoritative NS records (with 9 IPs).
cloudflare.com. has 5 NS records.
If webehostin.com. had 1 delegation NS record and 9 authoritative NS records it would function (or not function) in almost exactly the same way, with far smaller packets.
Or if the responses were more minimal.
(Edit: And Cloudflare demonstrates that it's not necessary to have nameservers used by other zones in that zone's NS record set.)
That's true. It also only comes into play because your domain does things that aren't needed.
1 Like
Not only are they unneeded, they’re ridiculous and performance impacting.
I think LE has made pretty clear they don’t intend to invest time in making this work, as the DNS setup is… uncommon in a way that suggests inexperience or misconceptions as pertains proper DNS function.
The OP would be well served by learning more about proper DNS architecture and administration.
So you’re saying if I remove ALL the NS records from my zone file except ns3, ns4, and ns5, other domains could still use phpdev (as an example) as a name server entry as long as just the A record is present? No NS record needed? Ok, fine, I’ll see if that’s even possible / will work by using .tk test domains…
Yes. They're not related at all.
The Cloudflare domains I posted earlier demonstrate it.
Edit: Though it still alarms me to see a domain with 1 nameserver IP.
I removed the NS entries, but I still don’t understand how this works in the big picture.
https://support.dnsimple.com/articles/ns-record/
Lots of articles trying to define NS records. Not sure when you need to create them in the parent zone (.com level) and at the domain zonefile level.
From what I can gather now, the additional NS records are only needed if you’re going to be building subdomains off of a subdomain on another server. For example, ns4.domain.com is the subdomain and from that you create a subdomain like test.ns4.domain.com. If you did that, you’d need a NS record to specify that delegation for the zone ns4.domain.com which points to a different server.
Well, in my case I don’t need to be doing this, but what if I were doing something like this? Again, Let’s Encrypt would fail. It should handle larger responses because this is 2018, and people CAN do things like that. Doesn’t mean they SHOULD, but it COULD happen, and programs are better when they work allowing FLEXIBILITY.
(emphasis added). This is a very good question, and one that I wasn't totally sure I understood the answer myself. I did a little research, and I think this is the best answer: What is the role of NS records at the apex of a DNS domain? - Server Fault. I'll rephrase in my own words and hopefully some of the DNS experts here will correct me if I'm wrong.
Generally speaking, you want the NS records configured at your registrar to be exactly the same as the NS records in your domain zonefile. The ones in your domain zonefile are considered "authoritative," while the ones configured at your registrar (that is, the ones stored in the parent domain's zonefile) are merely delegations. This seems backwards, since a full recursive resolution must get the NS records from the parent domain first in order to contact the nameservers for the subdomain. One could easily image a DNS-like system where the NS records in the parent domain were considered authoritative, and there was no need to maintain a copy in your own zone. However, for better or for worse, the DNS doesn't work like that, and the ones in your own zone are authoritative.
Now, the question is, why was DNS designed this way? Why design a system that has the same data in two places, possibly conflicting? I wasn't there at the time, so I can only read RFC 1034 and guess: The Internet was significantly different back then. In particular two things were much more common: (a) nameservers that acted as both recursive and authoritative resolvers at the same time, and (b) people querying hostnames within the same domain they were on. Also, updates to zonefiles were less automated, and so slower and less reliable.
So, for instance, imagine someone logged into compute.cs.example.edu who resolves storage.cs.example.edu using a local nameserver. If that nameserver is authoritative for example.edu, it could return a query quickly based on local data without having to recurse. In that situation, the delegation from edu is less "authoritative" because it doesn't need to be referenced. The local data is the most accurate and up-to-date. Of course, these days, that situation is very rare, and we are usually resolving hostnames that are under totally different domains than our own hostname.
I hope this sheds some light on the subject. DNS is often confusing, and it's a constant learning experience. 
This is mostly right. To rephrase it a different way: You can host arbitrarily deep subdomains without need for additional delegations, but if you want to further delegate a subdomain, for instance because the records in that subdomain change more frequently and need to be hosted by a different nameserver, you can do that by inserting additional NS records in your zone at the cut point. As with the com -> example.com delegation, you'd have two sets of NS records that would have to match: one set in the parent zone (the delegation) and one set in the subdomain zone (the authoritative records).
1 Like
I’d like to add a point of clarification to a DNS matter that the OP seemed to have some misgivings about as well.
The NS records in any given zone, such as those in “webehostin.com” have nothing to do with what servers may be allowed to be listed as name servers for other domains.
If, for example, you had a server called cust1ns defined in the webehostin.com infrastructure with an A record pointing to cust1ns’s public IPv4 IP address, and if cust1ns was configured with name server software - and had the other domain’s zone defined, you could absolutely list cust1ns.webehostin.com as an NS record in the other zone (otherdomain.com), both at the registrar and in the otherdomain.com zone within the DNS server.
The only outside facing reason to create an NS record at the top level of a particular zone is to indicate that “the server I mention here is an official name server of THIS zone.”
As mentioned elsewhere, the other reason for listing an NS record in a zone is to delegate a sub-tree of that zone to separate DNS servers.
For example, to delegate that the finance department has their own domain servers to control finance.yourdomain.com and everything below finance.yourdomain.com (ex: www.finance.yourdomain.com) to those other separate DNS servers, an NS record for finance.yourdomain.com NS whatever-other-dns-server.example.com would be inserted.
Also, standard DNS practice, even for some of the largest web properties in the world, would have only a small number of authoritative name servers listed in a given zone.
For examples, google.com:
appleprov1:~ mhardeman$ host -t NS google.com
google.com name server ns4.google.com.
google.com name server ns1.google.com.
google.com name server ns2.google.com.
google.com name server ns3.google.com.
Example, amazon.com (which hilariously doesn’t use Amazon Route53?):
appleprov1:~ mhardeman$ host -t NS amazon.com
amazon.com name server pdns1.ultradns.net.
amazon.com name server ns1.p31.dynect.net.
amazon.com name server ns3.p31.dynect.net.
amazon.com name server pdns6.ultradns.co.uk.
amazon.com name server ns4.p31.dynect.net.
amazon.com name server ns2.p31.dynect.net.
Example, overstock.com:
appleprov1:~ mhardeman$ host -t NS overstock.com
overstock.com name server ns4.p20.dynect.net.
overstock.com name server ns3.p20.dynect.net.
overstock.com name server ns2.p20.dynect.net.
overstock.com name server ns1.p20.dynect.net.
Example, bing.com:
appleprov1:~ mhardeman$ host -t NS bing.com
bing.com name server ns1.msedge.net.
bing.com name server ns2.msedge.net.
bing.com name server ns3.msedge.net.
bing.com name server ns4.msedge.net.
The big boys are not doing it this way because they are less experienced or have fewer resources than you (you generically as any typical sysadmin on the internet). They’re doing it this way because it is the correct way and balances the need for speed of lookups with quite sufficient redundancy.
1 Like
@mdhardeman Wow, that is so well written. Thank you for doing that. I’m writing a document that describes NS records better than what I’ve found on the internet. I’d very much appreciate it if you might be wiling to validate and possibly edit it. I plan to post it on my blog, and I’m definitely including a link to your post.
I was able to get the certificates I wanted. However, this problem could pop-up for someone else in the future with a valid use case for doing it this way, so I still wish Let’s Encrypt would allow it, but it’s all good for me.
I’d be happy to help however I’m able. If you write something up send it to me. I check in here pretty often.
@mdhardeman, is there a way to private message you here somehow?
EDIT, nvm figured it out.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.