Bypass subdomain limit by hosting own DNS server - dns

The following is more theoretical than practical, I want to test if I have understood the DNS system.
I'm currently renting a domain, lets call it example.com, from a provider.
I also own a server with a static ip.
Using the webinterface of my domain provider, I created an A-Record for my domain to point to my server.
Now everyone pinging example.com will find that A-Record (that should distribute itself to serveral more DNS servers) and thus ping my server.
Now I want a subdomain, which points to a different ip address.
My provider on the other hand won't let me create subdomains.
I can simply host an own DNS server at example.com, where I can add (arbitraryly) many records for any domain that is a subdomain to example.com (so not only subdomain.example.com but also subdomain.subdomain.example.com).
Now, if someone pings subdomain.example.com the following will happen:
They go to their favourite DNS server, which has an entry for example.com by now (due to distribution, see above)
Since there is no entry for subdomain.example.com, the will send an DNS request on udp port 53 to the A-Record ip behind example.com (my server)
My server will reply with the correct ip of subdomain.example.com
They send their ping to the correct ip
Is my understanding correct?

It's not far off, but there are more subtle things under the hood. If you want to host your example.com zone yourself, then you need to have your parent (.com) have NS records that point to your nameserver on your static IP. You would need to register that within your parent through your registrar that you bought the DNS registration with.
.com would need to host:
example.com. NS myns.example.com
myns.example.com. A YOURIP
And in your zone running on your machine, you would need something like:
example.com. SOA ....
example.com. NS myns.example.com
myns.example.com. A YOURIP
subdomain.example.com A SUBDOMINIP
If "subdomain" (your wording) is actually supposed to be in another zone enirely, then you need to use NS/A records to point to its DNS server (which can be the same).
You might go look for a good tutorial about how the DNS works in general. It will take you a lot further.

Related

DNS: forward root domain to www... when there are other DNS subdomains

I currently have a DNS setup where all content and applications are hosted on the same cloud server - example.com.
The presentation website is on example.com, www is forwarded to example.com with a CNAME and then various internal apps, eg app.example.com, are also forwarded with CNAME records to example.com. NGINX running on my server takes it from there, routing subdomains to the different apps.
I'd like to host the presentational website on an external service, and I'm confused about how to update my DNS config - specifically what to do with my A record.
I'm ok with creating a CNAME for www that will forward www.example.com to my external hosting service. But example.com is still pointing to my own server... and if I have understood correctly, if I forward example.com to www.example.com, then all my apps at eg app.example.com will break.
What are my options for handling this ?
My idea (from searching around) is that if I want example.com to point to an external service, then I should
1) create a new domain api-example.com whose A record points to a server where all my apps are hosted
2) make CNAME records for all my app subdomains on example.com which point to api-example.com
3) forward example.com to www.example.com, and forward www.example.com to the external service.
Will this configuration work ? Is there a simpler way to get the same result ?
Your plan is fine, except for maybe one thing: generally, you can't have a CNAME record for the root (apex) of your domain. This means that your external presentation website hosting will have to provide an IP address, and you will create an A record that will point example.com to that address. Then you can have a CNAME record simply aliasing www.example.com to example.com.
Also make sure that you leave enough time between the steps, to make sure that all DNS TTLs expired so you don't encounter DNS caching issues.
For explanation (and possible workarounds) for domain apex CNAMEing issue, look at https://stackoverflow.com/a/33027309/1145196

Prefix to domain

If I have a domain, such as example.com, how would I go about pointing special.example.com to a different website, say www.google.com?
Go to your Domain Name Service providers web console (the place where you are managing domain records for mydomain.com), and add CNAME record:
special CNAME www.google.com
Keep in mind that this will only point special.mydomain.com to ip address of www.google.com which does not guarantee that the web server there will respond to requests for Host: special.mydomain.com (though some probably will).
(btw, the domain to use in questions/examples/documentation is not mydomain.com but usually example.com, as specified by RFC2606)

How to map domain to hosting server

My client have a dedicated server on liquedweb cloud service and we my web app is hosted on that server. We want our users to map their domain to our server. So they can enjoy our web app by using their domain name. What information I need to provide to my user so he can map domain and what information I need from them?
I don't know much(in fact anything) about domain mapping
thanks
It depends if the server has a dedicated IP address or is natted.
If the server has a dedicated IP address you can ask your clients to point their entire domain to you server by adding the following A records:
Host TTL Protocol Type IP Address
# 300 IN A 1.1.1.1
www 300 IN A 1.1.1.1
Not all domain hosts ask for TTL,if not dont worry about it.
If you want just their subdomain to point to your server (subdomain.website.com)
subdomain IN A 0.0.0.1
TTL is optional in some systems, in this case the default will be used.
Generally it is recommended that you use an IP for the Apex record and not a domain name. EG: example.com is the apex, www.example.com is the www subdomain.
A typical configuration would be below:
Host TTL Protocol Type Result
# 300 IN A 1.1.1.1
www 300 IN CNAME example.com
This is the same config as the top example but using CNAME example.com. It is the same as using A 1.1.1.1, it just means you only need to change one record.
If your server details are a hostname and not an IP address, most systems will not let you use the hostname for the apex so you will need to find out the IP address. (A simple method is to use the nslookup command or dig command).
TTL is how long in seconds a record last before it expires. If you are unsure what you are doing I recommend lowering this so you can correct mistakes more quickly.
Different methods for the different servers. For most of the servers, you have to change the nameservers of your domain.
This mostly needs when your domain registrar and hosting provider both are different.
First Login into your hosting account, navigate to the account details,
then copy the nameservers from there...which would be like :- dns1.hostingprovider.com
dns2.hostingprovider.com
After that, Go to control panel of your domain. Navigate to the nameservers
You will see the link:- dns1.domainregistrar.com
dns2.domainregistrar.com
Paste the above links at the place of below links.
They need the IP address (and possibly instructions on how to configure their DNS servers (which means a variety of different sets of instructions for different servers and control panels)).
You need the domain name.

How forward and reverse DNS works

What I understand about how DNS works is like this: first let's assume mydomain.com has the IP address 12.34.56.78. Now when I put the url mydomain.com in the browser, the browser sends a dns lookup to its local dns server, asking, hey, do you know the ip address for mydomain.com. If the local dns server does not know about it, it will ask the parent dns servers, if the parent also does not know, then it keeps asking all the way up until the root dns server. The root dns server will ask some server in charge of the .com tld. The dns server in charge of the .com will have knowledge about mydomain.com because mydomain.com is the .com family. Then the answer will be returned back to the initial asker. Also the answer quite likely will be cached in the dns servers involved in the asking process. Would anyone correct my understanding if it is wrong.
So my real question is about how reverse dns lookup works. Let's say if I want to find out what domain name is for the ip 12.34.56.78. I run the command dig -x 12.34.56.78. If my local dns server does not know the answer, which server does it further ask? Is it 12.in-addr.arpa., or 34.12.in-addr.arpa.? If this is the case, are these names like 12.in-addr.arpa. valid domain names? And where should they be deployed so that the reverse lookup requests will know whom to ask?
How a reverse DNS lookup is accomplished:
The DNS resolver reverses the IP, and adds it to ".in-addr.arpa" (or ".ip6.arpa" for IPv6 lookups), turning 192.0.2.25 into 25.2.0.192.in-addr.arpa.
The DNS resolver then looks up the PTR record for 25.2.0.192.in-addr.arpa.
The DNS resolver asks the root servers for the PTR record for 25.2.0.192.in-addr.arpa.
The root servers refer the DNS resolver to the DNS servers in charge of the Class A range (192.in-addr.arpa, which covers all IPs that begin with 192).
In almost all cases, the root servers will refer the DNS resolver to a "RIR" ("Regional Internet Registry"). These are the organizations that allocate IPs. In general, ARIN handles North American IPs, APNIC handles Asian-Pacific IPs, and RIPE handles European IPs.
The DNS resolver will ask the ARIN DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
The ARIN DNS servers will refer the DNS resolver to the DNS servers of the organization that was originally given the IP range. These are usually the DNS servers of your ISP, or their bandwidth provider.
The DNS resolver will ask the ISP's DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
The ISP's DNS servers will refer the DNS resolver to the organization's DNS servers.
The DNS resolver will ask the organization's DNS servers for the PTR record for 25.2.0.192.in-addr.arpa.
The organization's DNS servers will respond with "host.example.com".
Source here.

Is it normal for a DNS server to not respond until the name servers are switched on the whois record?

I have someone telling me that DNS servers only start responding after the whois record is updated to point at their DNS servers. Is this normal behaviour? Or should a DNS server respond before the whois record is updated?
Also, once the domain is active, (so either after the domain is added or after the whois record is update, depending on the answer to the above question) how long till the name servers should start responding?
I'm not referring to the time that it takes to propagate acorss the internet, but just the time on the name server for the domain. I am also not concerned with when the rest of the internet sees the change, only wondering when that DNS server should respond when using a command such as:
nslookup www.example.com ns1.dnsserver.com
For the DNS servers to be found what you call the whois record must know where to find them.
Stricly speaking, the whois record contains much more than just the DNS servers for a domain, but let's not nitpick.
Say your DesktopA needs to connect to example.com, the following servers will be contacted, assuming the answer wasn't already cached by your ISP's DNS or the local machine.
DesktopA has DNS settings pointing to the ISP, so DektopA will ask the ISP's DNS servers if they know where example.com. is located (its IP).
ISP DNS server doesn't know, so it will contact the root domain database for com. (all Fully Qualified Domain Names end in a ., even though we generally don't use it explicitly, but you can try insert it in web requests, it should work fine).
This bootstrap list of global root servers is usually updated by the OS regularly.
The root servers will know which Top Level Domain TLD server to contact for each global domain such as .com, .org, .uk, etc.
In our example, the ISP will ask the root which server to query for com domains.
The root server answers with the IP address of one of the the .COM TLD servers.
The ISP DNS server will now contact the .COM TLD server and ask it where to find EXAMPLE.
The .COM database record for example.com will contain the 2 (or more) DNS servers registered along with the domain name example.com. These are part of your whois record.
The ISP now has the IP addresses of the DNS servers for example.com as setup in the whois. It will query the first one (or the second one if the first isn't available) and ask it: what's the IP of 'example.com'?
The DNS server for example.com will look in its records and return the A record defined for the example.com domain as IP 1.2.3.4 for instance.
Your ISP's DNS server will cache this information for a predetermined amount of time (TTL) and return the IP 1.2.3.4 to DesktopA.
Desktop A can now contact the server for example.com directly by its IP.
DesktopA may cache this information for a little while for fast lookup.
Tis would be the same for subdomains such as www.example.com or john.people.example.com. Everything before the domain example.com must be declared in your DNS server so when someone query for their address, your DNS server for example.com can look up the definitions and answer them (it could very well pass them on to another server as well if necessary).
In conclusion
So, to go back to your question, your whois record must be set with the proper DNS records for your domain before anyone can access them using that domain name.
DNS Servers operate completely separate from the Whois server. The relation of how fast DNS is updated after Whois depends completely on the registrar. A registrar or web host may update DNS within a second or 2 of a customer making a change in the control panel, or it may take minutes or hours if they make updates in batch mode.
Ideally all DNS changes that a customer request should happen very quickly on the DNS server (within a few seconds), but as you note, there may be a delay until changes propagate across the internet.

Resources