On Tue, 2023-03-28 at 13:47 -0700, ToddAndMargo via users wrote:
> the ones that answered the queries that your name
> server asked of it
The general process for asking a real domain server for a domain name
like www.example.com is that it'd consult its records (*) to find a
root server, ask one of the various root servers who deals with .com,
then it'd ask one of the .com servers who has the records for
example.com, then it'd query it, for whatever subdomain you wanted
(www.example.com).
i.e. It reads the domain name backwards from how you do.
.
.com
example.com
www.example.com
* (Your name server will have these as part of its install, and it will
update them, or yum/dnf will with rpm updates.)
It's a wee bit more convoluted than that, it goes a bit like this:
who holds the records for <some domain-name>.
that's held by <someone-else by name>
what's the IP address for that <someone-else's name>
connect to that <someone-else's IP>
who holds the record for <some domain-name>
that's held by <another-someone-else by name>
what's the IP...
There's a reason why the queries might go along the line of who holds
the records for example.com? They're held by nameserver.example.net,
rather than being directly told they're being held at 93.184.216.34.
It allows a consistent nameserver name to be used for the records, but
the IP addresses may be variable.
If you look in your own domain records, it'll will give a nameserver
for your domain as a domain-NAME-address, further down will be a record
giving a numerical-IP-address for that domain-NAME-address.
I've had a few people go, "no, it doesn't work that way." Yes, it
does, look in the files for a nameserver!
There aren't a great number of steps for finding out domain name
records, it's reasonably straightforward, other than a couple of things
off the top of my head: If you're using forwarders, they're an extra
step. And if a domain uses glue records, that's another step.
If you have forwarders for certain domains, they'll follow a different
sequence. Likewise, if you forward all queries. Your server will ask
the forwarder to do that work. Essentially, your server will only
answer some queries (the ones without any forwarders).
Glue records: The public records may say that a domain is handled by a
big hosting server, everyone queries it. It has a record that
redirects them to some other host that actually handles them. I always
forget what advantage that's supposed to have. I do know of the
problems they can cause, where someone foollishly sets things up so the
records are held somewhere that isn't publicly accessible.
Some domains will have their records hosted by several name servers
(think of Google having 4 domain servers, to spread the load around).
Queries will randomly get responded to by one of them.
dig example.com will tell you
the records for that domain (the answer section)
the nameserver that holds those records (the authority section) [the one that
provided the answers]
and the one that directly answered you (the query section) [and that'll be your
server]
You can think of the last two as passing a note to you across the room.
It's generally all you need to know, until you're trying to track down
where something is going wrong. Such as sometimes you get an answer,
sometimes you don't. Is a server failing? Are four backup servers
handling the queries, and one of them is bad.
The dig tool will allow you to directly query individual servers, so
you can trace such things.
--
uname -rsvp
Linux 3.10.0-1160.88.1.el7.x86_64 #1 SMP Tue Mar 7 15:41:52 UTC 2023 x86_64
Boilerplate: All unexpected mail to my mailbox is automatically deleted.
I will only get to see the messages that are posted to the mailing list.
_______________________________________________
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
