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.
Related
From the output I can understand there was no errors, yet there aren't any answers section to the query. Just to be sure the right question was even asked:
"Dig +norecurse #s.nic.dk MX www.dtu.dk"
parsing this to:
"without recursion, query dtu mail exchange servers through the nameserver s.nic.dk"
Is the query not supposed to return nameservers of dtu MX?
No, it isn't supposed to, because you are asking the authoritative name server of the TLD (s.nic.dk) for the answer. It does not have this answer, but gives you the details of the name servers that do: that is why you receive the authority section (and additional section).
However, even if you do query the authoritative name servers (for example: #dns1.dtu.dk) there is no MX record for the domain name www.dtu.dk, but rather for dtu.dk. Which means your query should be: dig #dns1.dtu.dk MX dtu.dk.
For note, the addition of +norecurse shouldn't make a difference when you're querying an authoritative name server directly.
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.
I have a page up at amongmany.github.io and I have followed the instructions here for a custom domain. I made those changes roughly 16 hours ago. Now, I know that DNS records "can take up to 24 hours" but in my experience it never does. So I'm trying to confirm that I've set things up correctly.
Here are my DNS settings and I have added the CNAME file to my project which appears to be working as amongmany.github.io is redirecting to 1amongmany.com already.
Am I doing something wrong?
Something's missing from your information:
root#ent01:/etc/bind# dig +noall +answer amongmany.github.io
amongmany.github.io. 3547 IN CNAME github.map.fastly.net.
github.map.fastly.net. 23 IN A 185.31.17.133
root#ent01:/etc/bind# dig +noall +answer 1amongmany.com
1amongmany.com. 1789 IN A 66.6.44.4
There is a 301 redirect from http://amongmany.github.io/ to Location:http://1amongmany.com/. However, your www returns a 404, and does not appear to be resolving to the addresses above:
root#ent01:/etc/bind# dig +short www.amongmany.github.io
github.map.fastly.net.
185.31.17.133
I guess I'm still a little confused as to what result are you trying to achieve?
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.