Dig is just like using nslookup, similar but reports quite a bit of info. So it depends which on you prefer using. You can also do:
the type option helps us filter, instead of it returning A records or CNAME’s, etc. Anyway, it all depends on how you want doc.mashweb.club to resolve, to go to the Cloudflare pages site, or to host it somewhere else and have it resolved at DO instead (or if you can have it resolved differently with custom info on CF side).
As for dig, you can do:
which will return A records. If you want to check other types, then:
@iwalker Very nice recap of dig features. I got some of that from the man page. Apparently nslookup is old and has some bugs in some OSs, according to what I read.
At first I was putting the ‘cname’ or ‘mx’ part in front of the domain name. You can imagine that didn’t work out.
I don’t understand DNS very well, but from what I gather, its basics are simple. Can you point me to a kind of 5-minute explanation of how it works? This is my guess:
(1) When anyone sends a DNS query, he should target a DNS name server using DNS internet protocol. (But which name server should he query if he is a web client trying to get an IP address for TCP/IP requests?)
(2) In response, the name server he queries will send back an IP address (or set of IP addresses?). If the name server doesn’t know, it will forward the request to another name server, and so on until the request arrives at a name server that knows.
(3) Somehow (directly from the name server that knows? or backwards through the chain of requestees?) the IP address (or set of IP addresses?) gets back to the original querier.
Is that correct? Could you please fill out the blanks in the above 1-minute overview?
If I query doc.mashweb.club or mashweb.club to get a name server by using the ‘ns’ type, what is the particular name server in the response? Is it the name server that knows the IP address(es)?
I wish I could see an annotation of a dig response with links and less cryptic labels. For instance, when my shell executes the command ‘dig @220.127.116.11 doc.mashweb.club ns’ I get a column full of the abbreviation or word ‘IN’. Does that refer to an ISO country code?
I just bought a cheap but neat little app for my iPhone that makes things easier to understand for me. I still need to learn some lingo, but it’s comforting to an old guy like me to see simple things kept simple. The app is available at Network Utility on the App Store . It even shows the suspicious answers when digging doc.mashweb.clug: the CNAME record and 2 A records. By contrast, the host command was about as cryptic as the dig command.
On the ‘Getting Started’ guide to Cloudflare Pages, I see this section:
Adding a custom domain
While every Cloudflare Pages site receives a custom subdomain during deployment, you may also wish to point custom domains (or subdomains) to your site. To do this, select the Custom domains section in your site dashboard.
Each domain will have it’s own authoritative DNS server or authoritative set of DNS servers. So when you make it request for example to Google DNS or OpenDNS, they will know which nameservers are responsible for resolving that domain and the request will be made to those servers, even though you yourself asked Google or OpenDNS. As you found, in this instance Cloudflare was still responsible for your doc.mashweb.club so Google/OpenDNS would forward to Cloudflare’s nameservers as they are the authoritative servers for your domain - at least until you configure it otherwise.
So yes, when you request in your browser doc.mashweb.club, it will ask your nameservers to provide the IP address assigned to it, or in your case the CNAME which is then redirected to the .dev address. Or for example, if your domain had doc.mashweb.club as the MX record for sending/receiving emails, then it would use that when attempting to send emails.
as mentioned, the authoritative DNS servers reply with the appropriate information required. If your authoritative DNS servers don’t reply, then in reality no IP will be retrieved and the connection will fail. This is why it’s best to have more than one DNS server available.
When you make a request for NS or MX or A or CNAME you get the appropriate information back from the server. So when we do dig ns doc.mashweb.club then we get returned a list of the authoritative NS or nameservers for that domain. The IN column you don’t need to worry about, what is more important is what comes in the column after this:
;; ANSWER SECTION:
doc.mashweb.club. 30 IN CNAME doc-948.pages.dev.
doc-948.pages.dev. 86400 IN NS indie.ns.cloudflare.com.
doc-948.pages.dev. 86400 IN NS troy.ns.cloudflare.com.
you can see here CNAME and NS entries. You checked NS for doc.mashweb.club which is a CNAME, so that then went deeper to find the NS servers for doc-948.pages.dev. Hence the Cloudflare entries.
There are no suspicious entries in the DNS, this is just how you have it configured so it replies with exactly how it should. If this is incorrect, then you just need to change it accordingly, either remove the CNAME for doc.mashweb.club and configure this with an IP address as an A record instead on your DO nameservers. Or by fixing it accordingly on Cloudflare pages, or wherever you have that stuff set up.
NS type is a DNS record, which is not the same as domain authoritative nameserver.
Usually, we use NS type DNS record when we want to use for example ns1.mydomain.com and ns2.mydomain.com to provide DNS service for some other domains under our domain → eg. example.org would change their domain nameservers to ns1.mydomain.com and ns2.mydomain.com.
NS record Identifies authoritative DNS servers for a domain.
There knows to be a small confussion at first, or users put Cloudflare nameservers (or any other) into the “NS” field of their domain registrar, instead putting them into the desired “nameserver” field.
More detailed about it can be read at the Learning Center at the link from below:
@fritex Thank you. That adds some more pieces to the puzzle.
The basics of DNS (not the details of the protocols or formats of packets or such minutiae) seem so simple to me that why they have eluded me all these years could only be due to my laziness. However, having been bitten by the problem with my subdomain, I thought I’d look for a clear and succinct explanation and found one: How DNS Works Visually - YouTube
I know, I know. I should learn this by reading. However, it’s actually faster for me if I watch a video with good diagrams and good narration. If the video is on YouTube I typically speed it up by a factor of about 1.5 to save my time.
Here’s a schematic view of how a DNS request gets resolved for a client like a web browser: