I understand how I can change the dns settings for my domains by editing my bind configs, when I run my own name-servers. I know that I can define the name-servers with my registrar via their online control panels. But I have no idea how that part works...
How does my registrar store the data about the name-servers? Is it something clever, like them having the authority to store NS records in the root name-servers?
I'm confused by this part, can anyone explain?
The registrar is responsible for setting the Root DNS entry that says, "When someone asks for stackoverflow.com, tell them that the authoritative DNS is xxx.xxx.xxx.xxx". They have an interface that allows them to make changes to the records they own.
Then the requester must go to the authoritative DNS (Which is the one you specified to your registrar was your DNS) to find the IP for stackoverflow.com, any subdomain of it, email server, and other DNS records pertaining to that domain.
-Adam
I've just been shown this:
# dig +trace ns stackoverflow.com
; <<>> DiG 9.2.4 <<>> +trace ns stackoverflow.com
;; global options: printcmd
. 269431 IN NS B.ROOT-SERVERS.NET.
. 269431 IN NS C.ROOT-SERVERS.NET.
. 269431 IN NS D.ROOT-SERVERS.NET.
. 269431 IN NS E.ROOT-SERVERS.NET.
. 269431 IN NS F.ROOT-SERVERS.NET.
. 269431 IN NS G.ROOT-SERVERS.NET.
. 269431 IN NS H.ROOT-SERVERS.NET.
. 269431 IN NS I.ROOT-SERVERS.NET.
. 269431 IN NS J.ROOT-SERVERS.NET.
. 269431 IN NS K.ROOT-SERVERS.NET.
. 269431 IN NS L.ROOT-SERVERS.NET.
. 269431 IN NS M.ROOT-SERVERS.NET.
. 269431 IN NS A.ROOT-SERVERS.NET.
;; Received 504 bytes from 83.138.151.80#53(83.138.151.80) in 3 ms
com. 172800 IN NS A.GTLD-SERVERS.NET.
com. 172800 IN NS B.GTLD-SERVERS.NET.
com. 172800 IN NS C.GTLD-SERVERS.NET.
com. 172800 IN NS D.GTLD-SERVERS.NET.
com. 172800 IN NS E.GTLD-SERVERS.NET.
com. 172800 IN NS F.GTLD-SERVERS.NET.
com. 172800 IN NS G.GTLD-SERVERS.NET.
com. 172800 IN NS H.GTLD-SERVERS.NET.
com. 172800 IN NS I.GTLD-SERVERS.NET.
com. 172800 IN NS J.GTLD-SERVERS.NET.
com. 172800 IN NS K.GTLD-SERVERS.NET.
com. 172800 IN NS L.GTLD-SERVERS.NET.
com. 172800 IN NS M.GTLD-SERVERS.NET.
;; Received 495 bytes from 192.228.79.201#53(B.ROOT-SERVERS.NET) in 145 ms
stackoverflow.com. 172800 IN NS ns51.domaincontrol.com.
stackoverflow.com. 172800 IN NS ns52.domaincontrol.com.
;; Received 119 bytes from 192.5.6.30#53(A.GTLD-SERVERS.NET) in 156 ms
Does this tell me that the stackoverflow.com nameservers have been stored in the .com name servers?
Or is it just that they happen to be there now?
It may be helpful to understand the difference between a "registrar" and a "registry" to begin with. A registrar is a company that sells domain names (ie. godaddy) to buyers. Anyone can be a registrar. You can become a registrar.
A registry is an entity (chosen by ICANN) that maintains the master database of domain names. There are several registries out there. The Internet Society (ISOC) is the registry for all .org names, Verisign is the registry for all .com and .net domain names. There are others and each country has one for their domain. All the registrars access and update the registry databases.
A registry is responsible for maintaining the top level domain (TLD) which is the ultimate DNS server. A request to resolve a domain name, if it can't be resolved by any other DNS server will filter up to the TLD. Think of it as a hierarchy like a tree where the TLD is the trunk. At that point it will be resolved into an IP address or an error will be returned.
Sorry I can't help toooooo much, but go to http://twit.tv, and find the Security Now podcast - they did one a couple of weeks ago on DNS - get the first one. It has a good explanation of how it works etc (which may help).
The second one on that site is about how it's been "hacked" - the first one is the how it works.
To kinda answer it:
The "root servers" (for .com for eg) hold a record for stackoverflow.com. But they can't hold all the details, so they have an NS record (name server record) saying "if you want more info, go look over there". So your machine asks that target machine (ns1.stackoverflow.com) for www.stackoverflow.com, and gets back the A record (IP address), or MX (mail etc)
So, your domain register will store it in a database or whatever they chose, and when you do an update, they SOMEHOW (I dont know, but I guess it's published by NIC, but they DO have to pay to be a registrar, and be checked out etc) push that change to the (cluster of) root name servers. They would then push the changes for your domain (eg where www goes, where your mail goes etc) to their local server, which actually serves the domain info.
Hope that makes SOME sense :)
Does this tell me that the
stackoverflow.com nameservers have
been stored in the .com name servers?
Yes and no.
Its like you going calling directory assistance for everything ending in .com. You ask for stackoverflow - they tell you "if you want SO, call this number, and they can tell you how to get Jeff (www), Joel (mail), etc.".
The root server is the first directory assistance. Your register's name server is the one on the end of the second call (assuming you called it :) )
There are some mistakes in the answers so far (and I have not yet sufficient reputation to comment on them).
The ".com" name servers are in no way related with the root name servers. When you change the name servers of stackoverflow.com, through your registrar, the change is made in the ".com" name servers. Root name servers are unaffected.
It is not true that the registries are all chosen by ICANN. The ccTLD registries (country-code TLD like ".jp" or ".ca"), for instance, are chosen locally, by a process which depends on the country.
Not all TLD use a registry/registrar system.
Related
Some time ago (months), I updated the nameservers for a number of domains I control; both the old and new nameservers are run by the same hosting company.
The NS records are correct with the registrar, and the correct records are shown by a whois request, and a dig +trace
However, a dig NS and an nslookup for soa both show the old records.
Recently the old nameserver was retired (it no longer responds to dig requests), and I'm concerned that this might impact the websites.
Please forgive a slight scattershot of related questions – I'm trying to work out what's happening, but I'm not entirely sure what I should be asking:
Why are these tools returning the old nameserver? How is the old
nameserver still held by any systems, months after the change?
How do I find the canonical answer? Is that a valid question? What does 'canonical' mean in this sense – I'm assuming it should mean the setting at the registrar?
What tool gives me the pragmatically correct answer (i.e. the answer
that most of the internet is using to resolve my domains)? I'm assuming that the internet at large isn't actually using the info provided by dig's source.
Here's an example:
Dig shows the old nameserver ns1.OLDNAMESERVER.net
$ dig ns EXAMPLE.co.uk
; ANSWER SECTION:
EXAMPLE.co.uk. 600 IN NS ns2.OLDNAMESERVER.net.
EXAMPLE.co.uk. 600 IN NS ns1.OLDNAMESERVER.net.
as does nslookup:
$ nslookup
> set querytype=soa
> EXAMPLE.co.uk
Server: 1.2.3.4
Address: 1.2.3.4#53
Non-authoritative answer:
EXAMPLE.co.uk
origin = ns1.OLDNAMESERVER.net
whereas whois shows the correct nameserver ns1.NEWNAMESERVER.co.uk as set in the registrar:
$ whois EXAMPLE.co.uk
Name servers:
ns1.NEWNAMESERVER.co.uk 5.6.7.8
ns2.NEWNAMESERVER.co.uk 1.6.7.9
as does dig +trace:
$ dig +trace EXAMPLE.co.uk
EXAMPLE.co.uk. 172800 IN NS ns1.NEWNAMESERVER.co.uk.
EXAMPLE.co.uk. 172800 IN NS ns2.NEWNAMESERVER.co.uk.
You have NS records at your new name servers, pointed to the old ones. Go to the DNS settings of the domain (the DNS zone) and change the NS records, not the name servers. Dig +trace should be showing you that:
EXAMPLE.co.uk. 172800 IN NS ns2.NEWNAMESERVER.co.uk.
EXAMPLE.co.uk. 172800 IN NS ns1.NEWNAMESERVER.co.uk.
;; Received 643 bytes from 156.154.103.3#53(nsd.nic.uk) in 26 ms
EXAMPLE.co.uk. 86400 IN NS ns1.OLDNAMESERVER.net.
EXAMPLE.co.uk. 86400 IN NS ns2.OLDNAMESERVER.net.
;; Received 124 bytes from 5.6.7.8#53(ns2.NEWNAMESERVER.co.uk) in 43 ms
Long time listener, first time caller here.
I'm writing a DNS resolver with DNSSEC validation incorporated, and have noticed something that i can't really understand, after several read-throughs of the affected RFCs.
During a resolution that is a domain in the uk. (specifically co.uk.) TLD i encounter a DNSSEC validation triggered infinite loop.
For the sake of simplicity let's assume the process has all the root zone cached already, so let's proceed from there:
execute query for co.uk. IN NS at one of the registered uk. nameservers
; <<>> DiG 9.10.5 <<>> co.uk. NS #nsa.nic.uk +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54513
;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 14
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;co.uk. IN NS
;; ANSWER SECTION:
co.uk. 172800 IN NS dns3.nic.uk.
co.uk. 172800 IN NS dns2.nic.uk.
co.uk. 172800 IN NS dns1.nic.uk.
co.uk. 172800 IN NS nsb.nic.uk.
co.uk. 172800 IN NS nsc.nic.uk.
co.uk. 172800 IN NS nsa.nic.uk.
co.uk. 172800 IN NS nsd.nic.uk.
co.uk. 172800 IN NS dns4.nic.uk.
co.uk. 172800 IN RRSIG NS 8 2 172800 20180622150723 20180518150505 33621 co.uk. pYoHwxWpkPP6FfIUk14o5qsO0cxA3CaPvfKGT++MuBhW9Ls/7Xnl6WwE pyU3BIDylkVyELe6be6hCwVOfV3VWcT1JW86RJexhRtU74ZHWdVNnjYd +oQVOQ0V/rhDorVSKdA0G+uDyq11T6Z1ecCERlks63GF21aPM9bWEJD6 cOo=
;; ADDITIONAL SECTION:
nsa.nic.uk. 172800 IN A 156.154.100.3
nsb.nic.uk. 172800 IN A 156.154.101.3
nsc.nic.uk. 172800 IN A 156.154.102.3
nsd.nic.uk. 172800 IN A 156.154.103.3
dns1.nic.uk. 172800 IN A 213.248.216.1
dns2.nic.uk. 172800 IN A 103.49.80.1
dns3.nic.uk. 172800 IN A 213.248.220.1
dns4.nic.uk. 172800 IN A 43.230.48.1
nsa.nic.uk. 172800 IN AAAA 2001:502:ad09::3
dns1.nic.uk. 172800 IN AAAA 2a01:618:400::1
dns2.nic.uk. 172800 IN AAAA 2401:fd80:400::1
dns3.nic.uk. 172800 IN AAAA 2a01:618:404::1
dns4.nic.uk. 172800 IN AAAA 2401:fd80:404::1
before anything (like treating the response elements valid), DNSSEC validation should occur; so naturally we execute a query for the DNSKEY with which the RRSIG was signed (we notice that co.uk. is the signer of the records)
in order to obtain the DNSKEY for zone co.uk. we need to know the NS authoritative on that zone (reminder, that we already have that information, but didn't manage to validate it yet), therefore we launch a co.uk. IN NS query to the parent zone (uk.) nameserver, and we're back at the beginning.
I am certain that this is a design flaw, but can't really understand what. Logically (and the key step here, that triggers the loop is, that) one shouldn't consider using RRs before validation, and child zone delegation records, again, logically, shouldn't be signed with the child zone's DNSKEY, i think even if the parent zone is authoritative for the child zone too.
Please help and thank you in advance
As you noticed, the same name servers are authoritative for both .UK and CO.UK, so you didn't get a normal referral response from the parent zone, which would have DS and NS records in the authority section, but rather an authoritative response from the child zone, with NS records in the answer section.
So you do need an extra DS query to the .UK name servers, as you realized, but be aware that you don't need that DS record in order to validate the DNSKEY and RRSIG records for the NS records. The (non-apex) NS records returned in a normal delegation response are not signed, and do not require validation. When you get back a child zone response, the NS records are apex records, and (if the zone is DNSSEC-signed) there will be an RRSIG for the NS record set, but it is not required to validate those NS records before using them as name servers for the zone. A validating recursive name server only ever needs to validate NS records when it is processing an explicit NS query from a client.
Ultimately, DNSSEC relies on validating the data in zones, not the names or addresses of the name servers that are providing them. This is rather different than many other security protocols, like HTTPS, which authenticate the server (and possibly client) endpoints only.
When we inspect the DNS response after trackroute a website, in Wireshark, which section reflected "the information about nameservers"?
Authority RRS?
Additional RRS?
or within the Answers section (name, type, class, time, data)
Sorry, new to English and Wireshark.
Thank you
The authority section will contain the information about the nameservers. The "authority" section tells you just that: what servers are "authoritative" for that information.
Example query to .com's name servers for information about www.google.com:
> dig #f.gtld-servers.net. www.google.com A
; <<>> DiG 9.7.6-P2 <<>> #f.gtld-servers.net. www.google.com A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62133
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 4
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;www.google.com. IN A
;; AUTHORITY SECTION:
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns2.google.com. 172800 IN A 216.239.34.10
ns1.google.com. 172800 IN A 216.239.32.10
ns3.google.com. 172800 IN A 216.239.36.10
ns4.google.com. 172800 IN A 216.239.38.10
The above answer shows that there is no ANSWER section because .com doesn't know the address for google's A record. But it does know where you should go next: you should go talk to google's NS records, and those are listed in the authority section. And the additional section contains information about the addresses for google's name servers.
The Authority Section reflects the information of nameservers.
If you using UNIX like operating systems, you can use Dig to traceroute a website.
I've been told that there is a problem with the DNS records for for the following domain: horoscope-feeds.com, but I'm not yet convinced there is a problem with it.
When I do
host -C -a horoscope-feeds.com
I get the response
Trying "horoscope-feeds.com"
Received 184 bytes from 127.0.0.1#53 in 46 ms
Trying "horoscope-feeds.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21074
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;horoscope-feeds.com. IN SOA
;; ANSWER SECTION:
horoscope-feeds.com. 86400 IN SOA ns.horoscope-feeds.com. peter.ward33.btopenworld.com. 1341590337 10800 3600 604800 10800
;; AUTHORITY SECTION:
horoscope-feeds.com. 86400 IN NS ns.horoscope-feeds.com.
;; ADDITIONAL SECTION:
ns.horoscope-feeds.com. 86400 IN A 109.228.2.80
Received 131 bytes from 109.228.2.80#53 in 44 ms
Which I understand as meaning that the authoritative name server for this domain is ns.horoscope-feeds.com. However a whois lookup for the domain yeilds two nameservers:
Nameserver: ns1.horoscope-feeds.com
Nameserver: ns2.horoscope-feeds.com
I thought that whois information is not guaranteed to be accurate and that domain information should not be taken from this source.
Can anyone tell me if the DNS set up for this domain is wrong in any way and if so how? Also where is the final authority on the DNS records for a domain and how do I get that information?
Thanks
The DNS setup inconsistent because the registry (".com" - managed by Verisign) says that the authoritative nameservers are ns1.horoscope-feeds.com and ns2.horoscope-feeds.com, but if you query one of these servers, they answer that the authoritative server is ns.horoscope-feeds.com (having the same IP as ns2).
This may sound confusing, but it's important to understand that the main record type that a resolving client jump from the root down to your domain is the NS resource record type. For any given delegated domain, such as "horoscope-feeds.com", there are two sets of such NS records -- one published by the parent zone (registry) and one published by the zone itself. These two sets should match:
Ask the registry for the set of nameservers authoritative for your domain:
$ dig +noall +authority +add #a.gtld-servers.net horoscope-feeds.com
horoscope-feeds.com. 172800 IN NS ns1.horoscope-feeds.com.
horoscope-feeds.com. 172800 IN NS ns2.horoscope-feeds.com.
ns1.horoscope-feeds.com. 172800 IN A 109.228.2.79
ns2.horoscope-feeds.com. 172800 IN A 109.228.2.80
Ask one of those nameservers:
$ dig +noall +answer +add #109.228.2.79 horoscope-feeds.com ns
horoscope-feeds.com. 86400 IN NS ns.horoscope-feeds.com.
ns.horoscope-feeds.com. 86400 IN A 109.228.2.80
A similar diagnosis can be seen here.
Generally, the information published by Whois also comes from the TLD registry (if you query the right whois server). However, there is a possibility that the registry whois database is out of sync with what is published at the DNS. Since we're dealing with DNS problems, it's best to query the DNS, i.e. ask one of dig com. NS for domains that end with ".com") :)
As for fixing this inconsistency, you should either edit your zone (at your DNS provider) to match the registry.
When I try to add my domain and website to my app in the basic config for my app it keeps telling me it is and invalid domain, but it should work, it used to...
I try putting it into the "App Domains" and "Site Url" fields but get this error...
"Error
App Domains: illmethods.com is not a valid domain.
Site URL is not a valid URL."
The app name is IllMethods
If you asked the com authoritative DNS servers, you get these NS records and associated glue (A) records:
$ dig +norecurs +noall +auth +answer +additional illmethods.com #a.gtld-servers.net
illmethods.com. 172800 IN NS ns1.illmethods.com.
illmethods.com. 172800 IN NS ns2.illmethods.com.
ns1.illmethods.com. 172800 IN A 203.97.122.126
ns2.illmethods.com. 172800 IN A 125.236.226.87
but if you asked ns1.illmethods.com, the A record for "ns1.illmethods.com" is different from above:
$ dig +norecurs +noall +answer +additional illmethods.com #ns2.illmethods.com
illmethods.com. 14400 IN A 125.236.226.87
ns1.illmethods.com. 14400 IN A 125.236.226.87
ns2.illmethods.com. 14400 IN A 125.236.226.87
So "ns1" and "ns2" are essentially pointing to the same IP.
I think the issue is a culmination of a few factors:
negative caching. If your server was down at some point, Facebook's upstream DNS might have cached the negative response for some time.
inconsistent A records for name servers specified at the registrar vs. what's in the zone that you host.
Facebook probably has a very short timeout when it queries the DNS, since ns1 is actually not reachable (at least now from where I am), it will likely timeout before it manages to try the other IP.
So, I suggest that you remove ns1.illmethods.com at your registrar, and then remove the NS record of the same in your zone as well. Then, wait at least an hour (if you want to be doubly sure, wait 24hrs since you've specified 86400 in your SOA minimum field) and try again.
You should also use the dnscheck link that Sean Kinsey gave provided to make sure that your zone is free of errors, because these become hard-to-diagnose errors in the presence of caching and different DNS resolver implementations.
There are no valid NS servers listed for this domain and so Facebook probably can't verify it. Currently it has ns1.illmethods.com and ns2.illmethods.com, but that causes a catch 22 as you need the IP for the NS-servers in order to look up the IP for the NS-servers...
See http://dnscheck.pingdom.com/?domain=illmethods.com for more.