dns probe finished nxdomain
October 16, 2018 6:53 PM Subscribe
I have a website hosted on a basic website host with a domain (the domain and the site are under the same provider), and a small percentage of people are saying the site isn't visible to them and is returning the error "dns probe finished nxdomain". I am in contact with the provider's tech support but I was wondering until I hear back from them, what can be done to resolve this by the domain provider?
Everything I googled is either things that people can do to resolve it from their browser which isn't what I'm looking for, or web hosting companies saying "Contact us if this is happening".
Everything I googled is either things that people can do to resolve it from their browser which isn't what I'm looking for, or web hosting companies saying "Contact us if this is happening".
Response by poster: It's been around for awhile and I didn't make any changes to where or how it's hosted as far as I know.
posted by bleep at 9:23 PM on October 16, 2018
posted by bleep at 9:23 PM on October 16, 2018
Best answer: The most useful thing would be if you can enlist aid from someone who is encountering the failure to try and pin down why it is happening in their environment.
But for starters.. Unless you are trying to do something fancy, most likely there two main places you should be looking for problems. You should start with the servers that are authoritative for your domain -- they will be listed in the NS RRset for your domain.
I will be using the "dig" tool because it's very useful for this sort of troubleshooting. It's provided as part of the BIND package and is available on many Linuxes and other Unix-like operating systems. The whole package is also available as Windows binaries available for download from https://www.isc.org/downloads -- however this is probably overkill for your purposes. But anyway..
Your domain will have a number of nameservers which are listed as authoritative for that domain and, while you can privately set up nameservers that are not listed in the domain's NS records, the other people who are experiencing failures are almost certainly using the publicly listed servers.
I'm going to use metafilter.com as an example domain because you have not given the name of your domain.
You should then query each of those nameservers directly in turn to check that they have the proper zone data, either by querying for the exact record you want or else check the serial number of the copy of zone data that they have. It's possible that the reason your domain works for most but fails for some is that one of the servers does not have a current copy of the zone data.
The first of those two queries asks a specific authoritative server for the Start of Authority (soa) record for the zone. The serial number is the third field (in this case, unusually, the serial number for the metafilter.com zone is 1. more often the number will either be a large integer that is incremented by one every time the zone is updated or an integer representing a date, e.g. 2018101601) The serial numbers returned by each of the authoritative servers should usually match whatever serial is current on the master server for the zone (which may or may not be one of the publicly listed nameservers.)
The second of those commands asks a specified authoritative server for the record associated with a name -- replace the server argument with one of the servers authoritative for your domain and the name argument with the name that your users are having trouble with. You should pay particular attention to the status code provided in the header section (in the example above: "status: NOERROR" but in at least some of your users' cases, "status: NXDOMAIN" -- check each server, they should all return NOERROR but if some of them return NXDOMAIN you are getting closer to isolating your problem..)
To confuse things even further it is the case that, because of the way the DNS works, old answers can be cached for a period of time, so that caching servers elsewhere in the net may return old answers even after you have updated the information on your authoritative servers. They should not cache that information longer than the TTL (time to live) value associated with any given record and *generally* that should be a fairly short period of time unless you have overridden the default values with huge TTLs for some reason, but it does mean that it is not possible to expect a fix to be instantly recognized everywhere even if you do get to the root of the problem.
I could go on but this is already a pretty long response and I fear I've given you a lot to digest. The "tl;dr" version is that I would recommend you start by directly querying each of the authoritative servers for the domain to make sure they are providing the right answers when asked, and I have provided one suggested way of doing that (but there are others.) But probably it makes sense to check first that all authoritative servers are answering from the correct copy of the zone data and are giving NOERROR responses with the proper value.
posted by Nerd of the North at 10:06 PM on October 16, 2018 [4 favorites]
But for starters.. Unless you are trying to do something fancy, most likely there two main places you should be looking for problems. You should start with the servers that are authoritative for your domain -- they will be listed in the NS RRset for your domain.
I will be using the "dig" tool because it's very useful for this sort of troubleshooting. It's provided as part of the BIND package and is available on many Linuxes and other Unix-like operating systems. The whole package is also available as Windows binaries available for download from https://www.isc.org/downloads -- however this is probably overkill for your purposes. But anyway..
Your domain will have a number of nameservers which are listed as authoritative for that domain and, while you can privately set up nameservers that are not listed in the domain's NS records, the other people who are experiencing failures are almost certainly using the publicly listed servers.
I'm going to use metafilter.com as an example domain because you have not given the name of your domain.
Metafilter.com has 4 authoritative nameservers publicly listed. Your domain may have some other number but should have at least two servers listed.$ dig +short metafilter.com ns ns-1074.awsdns-06.org. ns-1911.awsdns-46.co.uk. ns-488.awsdns-61.com. ns-934.awsdns-52.net.
You should then query each of those nameservers directly in turn to check that they have the proper zone data, either by querying for the exact record you want or else check the serial number of the copy of zone data that they have. It's possible that the reason your domain works for most but fails for some is that one of the servers does not have a current copy of the zone data.
In the commands above, the argument which starts with "@" should be replaced, in turn, with each of the authoritative nameservers for the domain. Specifying "@server" will make the dig tool ask the specific server you have selected, rather than directing the query to your local recursive resolver and letting it ask whatever server it finds by following the chain of delegations from the DNS root. The next argument is the name of the record you are trying to check. And optionally a record type can follow.$ dig +short @ns-1074.awsdns-06.org. metafilter.com soa ns-488.awsdns-61.com. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400-or-$ dig @ns-1074.awsdns-06.org www.metafilter.com ; DiG 9.12.2-P1 @ns-1074.awsdns-06.org www.metafilter.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33590 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.metafilter.com. IN A ;; ANSWER SECTION: www.metafilter.com. 300 IN CNAME metafilter.com. metafilter.com. 300 IN A 54.186.13.33 ;; AUTHORITY SECTION: metafilter.com. 172800 IN NS ns-1074.awsdns-06.org. metafilter.com. 172800 IN NS ns-1911.awsdns-46.co.uk. metafilter.com. 172800 IN NS ns-488.awsdns-61.com. metafilter.com. 172800 IN NS ns-934.awsdns-52.net. ;; Query time: 47 msec ;; SERVER: 205.251.196.50#53(205.251.196.50) ;; WHEN: Tue Oct 16 20:50:31 2018 ;; MSG SIZE rcvd: 203
The first of those two queries asks a specific authoritative server for the Start of Authority (soa) record for the zone. The serial number is the third field (in this case, unusually, the serial number for the metafilter.com zone is 1. more often the number will either be a large integer that is incremented by one every time the zone is updated or an integer representing a date, e.g. 2018101601) The serial numbers returned by each of the authoritative servers should usually match whatever serial is current on the master server for the zone (which may or may not be one of the publicly listed nameservers.)
The second of those commands asks a specified authoritative server for the record associated with a name -- replace the server argument with one of the servers authoritative for your domain and the name argument with the name that your users are having trouble with. You should pay particular attention to the status code provided in the header section (in the example above: "status: NOERROR" but in at least some of your users' cases, "status: NXDOMAIN" -- check each server, they should all return NOERROR but if some of them return NXDOMAIN you are getting closer to isolating your problem..)
To confuse things even further it is the case that, because of the way the DNS works, old answers can be cached for a period of time, so that caching servers elsewhere in the net may return old answers even after you have updated the information on your authoritative servers. They should not cache that information longer than the TTL (time to live) value associated with any given record and *generally* that should be a fairly short period of time unless you have overridden the default values with huge TTLs for some reason, but it does mean that it is not possible to expect a fix to be instantly recognized everywhere even if you do get to the root of the problem.
I could go on but this is already a pretty long response and I fear I've given you a lot to digest. The "tl;dr" version is that I would recommend you start by directly querying each of the authoritative servers for the domain to make sure they are providing the right answers when asked, and I have provided one suggested way of doing that (but there are others.) But probably it makes sense to check first that all authoritative servers are answering from the correct copy of the zone data and are giving NOERROR responses with the proper value.
posted by Nerd of the North at 10:06 PM on October 16, 2018 [4 favorites]
Best answer: Oh also.. DNSViz might be overkill but it's a web tool that can analyze a specified domain for a number of common problems. It's mostly targeted at DNSSEC validation but even if your zone is not signed it can help find problems with delegations and other issues.
posted by Nerd of the North at 10:26 PM on October 16, 2018 [1 favorite]
posted by Nerd of the North at 10:26 PM on October 16, 2018 [1 favorite]
This thread is closed to new comments.
It's possible it's just a matter of waiting for the DNS records to propagate and there's not really anything you can do to speed that up at this point.
In the meantime, you can try looking up your domain here to identify any DNS-related config problems:
http://www.dnssy.com
posted by sportbucket at 8:52 PM on October 16, 2018