#ThrowbackThursday Here is a ~20 year old plot showing the frequency distribution of client source port usage at an edu #DNS resolver. Notice how the most common ports started at around 1024? That was Microsoft Windows. This picture should look a lot different if I were to redraw this today.
@sahil If you want to see details about who and what is issuing queries for your names, it's a good idea.
If your name(s) are prone to attack, it might be a bad idea unless you partner with a provider who can host and help mitigate large floods.
If your zone(s) don't change very often and have few records, it is relatively easy to setup and run a couple of authoritative name servers, ideally on at least a couple of diverse networks using bind, unbound, or whatever you're comfortable with.
Don't provide answers (recursion) you're not authoritative for.
Don't forget to update your SOA serial every time you make a zone change.
Do run your zone through various zone checking online tools (e.g., zonemaster.fr).
Do use a provider who won't arbitrarily block networks/addresses or source ports.
Don't run anything else on your name server, but maybe just SSH and NTP - and protect those from unsolicted access.
You may not have a need for all their guidance, but see IETF RFCs 2870 ad 9199 for other ideas.
That happens to be the same set for tp.8e49140c2-frontier.amazon.com, which is where your dig ns aws.amazon.com query would have stopped.
aws.amazon.com and tp.8e49140c2-frontier.amazon.com. both happen to be CNAMEs that ultimately lead to dr49lng3n1n2s.cloudfront.net. Those three strung together make up a chain. All coincidentally have the same authoritative server set at present.
You say "actual NS domain". It might help to further explain if you say what you think the "domain" is in this case.
David Mills, a true Internet pioneer, passed away on January 17, 2024. Probably best known for having led the development and maintenance of #NTP for decades, he was also involved in a great deal of early Internet protocol development.