This morning I tried to visit a website I run, only to see that the dns lookup failed, this problem is visible on multiple devices and broswers. This was surprising to me - things were running fine yesterday. What are some possible causes for why a websites dns can just stop resolving?
The specific domain I'm working with is candocomputing.com. [Warning: commercial link]
Answer from 192.5.6.30 (a.gtld-servers.net):
;; QUESTION SECTION (1 record)
;; candocomputing.com. IN A
;; AUTHORITY SECTION (2 records)
candocomputing.com. 172800 IN NS ns2.verification-hold.suspended-domain.com.
candocomputing.com. 172800 IN NS ns1.verification-hold.suspended-domain.com.
According to this, looks like you did not respond to verification email within 15 days after registration and now your domain is suspended.
Related
When setting up Google Adsense or Gmail as a site owner, you are required to modify a CNAME record for verification. Microsoft does the same thing.
I am building a website where I would like an owner of a group to verify ownership of a domain in the same way. How do I accomplish this?
There's lots of ways to do this. Listed in order of preference:
microid
whois (check email address and/or name)
OpenID w/ delegation
DNS TXT (or CNAME if you must)
Insert HTML comment <!-- verify code --> into main page
I would recommend implementing some combination of these. The last one should be a measure of last resort for people who can't insert things into the <head> section of their sites. Done well, many users might be able to claim ownership of their domain without having to take any action at all, provided they've supplied you with an email address already.
For the specific issue of getting DNS information, try this:
$ dig TXT google.com
; <<>> DiG 9.4.3-P3 <<>> TXT google.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4045
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;google.com. IN TXT
;; ANSWER SECTION:
google.com. 3600 IN TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all"
;; Query time: 131 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Sat Oct 24 16:50:56 2009
;; MSG SIZE rcvd: 122
This particular query gives you the SPF entries for google.com. You could just as easily do:
dig TXT verify.example.com
Then check the confirmation code in the answer section.
You need to query DNS server for the CNAME record of that domain. It can be as simple as using dig/nslookup/etc and scraping data from it or using name resolving capabilities of your platform/language.
You might also be aware of this technique and already dismissed it (since this really shows who has control over a site rather than a domain as you specify), but you could ask the person to place a file of a specific name and content on the root level of the domain.
For example:
http://www.blahdeblah.net/**verify.txt**
The one advantage is that once they do this you don't have to wait for changes to propagate, its immediate.
I want to use branch.io fro deep-linking but my custom domain doesn't register with the service.
At link settings, where I define my custom link I have this message:
Domain is incorrectly set up; please use the nameservers below as your NS record. A CNAME record is not required. If you've already done this, note that it can take up to several hours to propagate.
ns-1104.awsdns-10.org.
ns-19.awsdns-02.com.
ns-666.awsdns-19.net.
ns-1742.awsdns-25.co.uk.
And this is how I've set it up in my domain settings (goDaddy):
I've done this about 3-4 days ago. What am I doing wrong?
I'm trying to set up my root domain as my link in the link settings form.
when I put it I get this warning.
Domain is incorrectly set up; please use the nameservers below as your
NS record. A CNAME record is not required. If you've already done
this, note that it can take up to several hours to propagate.
ns-907.awsdns-49.net.
ns-1438.awsdns-51.org.
ns-1683.awsdns-18.co.uk.
ns-401.awsdns-50.com.
So I changed my ns in goddady to those
now if I run $ host -t NS getgogro.com I get 2 different outputs randomly
getgogro.com name server ns64.domaincontrol.com.
getgogro.com name server ns63.domaincontrol.com.
I believe this 2 are still godaddy's default dns, but I dont always get that output
and http://getgogro.com/ already takes me to branch.io
but in the Link Settings section I sell get the same warning
Domain is incorrectly set up; please use the nameservers below as your
NS record. A CNAME record is not required. If you've already done
this, note that it can take up to several hours to propagate.
ns-907.awsdns-49.net.
ns-1438.awsdns-51.org.
ns-1683.awsdns-18.co.uk.
ns-401.awsdns-50.com.
Thanks for reaching out to Branch. Let me follow up with you directly via email!
I setup a couple of nameservers and updated my domain to use them, and as far as I can tell everything went fine and the nameservers have been updated, or so says every whois and dnstools type site ive used, (intodns, who.is etc are all saying the same thing: the new nameserrvers are in effect, and the site points to the new ip just fine). Problem is that The site is not showing up, and dig tells me that the old ip/nameservers are still effective.
In my DNS Records I have:
domain. A IN NS ns1.newnameserver
domain. A IN NS ns2.newnameserver
ns1 IN A newipaddress
ns2 IN A newipaddress
domain. IN A newipaddress
I'm very short on time and haven't found anything on the interweb, so any help would be much appreciated
The old IP address is probably being cached by the server you queried. First of all, check that BOTH your new authoritative nameservers are publishing the correct address by querying them directly with dig:
dig #ns1.newnameserver domain. a
dig #ns2.newnameserver domain. a
Assuming those queries give correct answers, dig some other servers that aren't:
dig domain. a # Use the system's default resolvers
dig #8.8.8.8 domain. a # Use Google's public resolver
dig #some.other.ip.address domain. a
If it gives the old answer, look at the TTL. That's the numeric field listed in the answer just after the name and before "IN". That's how many seconds you have to wait until the server you queried discards its cached data and will query the authoritative servers again.
Ask those same nameservers where they think "domain." is delegated:
dig domain. ns # Use the system's default resolvers
dig #8.8.8.8 domain. ns # Use Google's public resolver
dig #some.other.ip.address domain. ns
You want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver", but the resolvers likewise cache that information so they might still have the old nameservers. If so, look at the TTL on those NS records too. If the TTL on those records is longer than the TTL on the A records, those resolvers may still go to the old nameservers to get "domain."'s A records even when their currently cached copy expires... so you may need to wait for that TTL to expire first, and then for the TTL on the actual A record to expire again!
Another thing you can do is query some of the authoritative nameservers for the PARENT domain of your domain to see if they are indeed delegating it to "ns1.newnameserver" and "ns2.newnameserver". This will verify that the delegation in DNS matches what's in WHOIS.
dig com. ns # If your domain's parent domain is "com."
dig #<one-of-the-servers-that-resulted-from-that-query> domain. ns
Again, you want to see 2 NS reocrds for "domain.", one pointing to "ns1.newnamserver" and the other one to "ns2.newnameserver".
If the old nameservers are still running, either:
make sure they aren't, or
make sure they've also got the new zone data
Some people will still be talking to the old nameservers, and until they either stop answering or give the right answer, they won't learn the new nameservers from the parent zone.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I haven't found the answer to this question anywhere and I'm a bit confused.. I want to know if the root DNS servers are queried iteratively or recursively?
As far as my understanding of the subject goes, they can be queried recursively,as they are the 'last option' to resove a name, so they must answer with the IP address/error message. Am I correct? Please make this clear for me. Thanks.
Queries to any DNS server, regardless of whether they're the root server or not, get answered with information that the server is allowed to give out about names they know something about. What that means is that if you query a server for a name it doesn't know about, but it does know who owns part of it, it'll refer you to the next place to ask.
Lets say you need to find out where www.example.com is. If you use the dig utility from the bind package, you can query the root for the answer and see what it will tell you:
# dig #b.root-servers.net. www.example.com a
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
; [...11 more authority servers for .com not shown...]
;; ADDITIONAL SECTION:
h.gtld-servers.net. 172800 IN A 192.54.112.30
d.gtld-servers.net. 172800 IN A 192.31.80.30
; [...11 more IP addresses for .com not shown...]
The effect of the above response is the root server telling you "I
don't know where www.exmaple.com is. You'll need to go ask .com next,
which is at the following list of addresses.
And so off you'd march to ask the .com server's the same question:
# dig #h.gtld-servers.net. www.example.com a
;; QUESTION SECTION:
;www.example.com. IN A
;; AUTHORITY SECTION:
example.com. 172800 IN NS a.iana-servers.net.
example.com. 172800 IN NS b.iana-servers.net.
;; ADDITIONAL SECTION:
a.iana-servers.net. 172800 IN A 199.43.132.53
a.iana-servers.net. 172800 IN AAAA 2001:500:8c::53
b.iana-servers.net. 172800 IN A 193.0.0.236
b.iana-servers.net. 172800 IN AAAA 2001:610:240:2::c100:ec
This answer helps you further by saying "I don't know either, but go
ask the owners of example.com". Asking them will finally get you a
real answer you were looking for:
# dig #a.iana-servers.net. www.example.com a
;; ANSWER SECTION:
www.example.com. 172800 IN A 192.0.32.10
And finally we have a server that is willing to give us the real
answer.
Note, however, we asked each server in turn, starting from the root
and going down. At each step someone either said "I have the answer"
or "I don't have the answer, but I know who you should talk to next".
Recursive servers (i.e. the ones serving end-user clients) perform iterative queries to authoritative servers.
In response to those iterative queries, each authoritative server in the chain down from the root will either return the answer if it's authoritative for that domain, or a referral to the next servers down the chain that might have the answer.
The root name servers do not offer fully recursive service, only referrals to the name servers run by each TLD.