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.
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
I am using Centos 7 and I would like to modify zone records in php so that I can add and remove domain names programatically.
Unfortunately, when I type find / named.conf into a terminal I get 0 results and I do not have the folder /var/named.
How can I find the files I need to modify so that I am able to write a script to add and removed domains names?
After running mydomain.com as #Leo suggested, I received:
dig #8.8.8.8 mydomain.com -t NS
; <<>> DiG 9.13.4 <<>> #8.8.8.8 mydomain.com -t NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33602
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mydomain.com. IN NS
;; ANSWER SECTION:
mydomain.com. 21599 IN NS ns2.contabo.net.
mydomain.com. 21599 IN NS ns1.contabo.net.
mydomain.com. 21599 IN NS ns3.contabo.net.
;; Query time: 55 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Tue Dec 25 02:35:26 GMT 2018
;; MSG SIZE rcvd: 110
Where are the DNS Zone files located?
Somewhere internal to your hosting provider. You aren't operating the DNS server, so its zone files won't be on your server.
Your provider may offer an API to update your DNS records. If they do, use it. (I can't say for sure if they do, because you haven't mentioned who they are.)
If that isn't an option, there are plenty of third-party DNS providers available who do have an API. A couple of the bigger ones to consider are Cloudflare (free), AWS Route 53 (~$0.50/zone/month), and Google Cloud DNS (~$0.20/zone/month).
To get a hint of where to start searching, look at reality; try:
dig #8.8.8.8 your.host.name -t NS
or drill, or kdig or etc.
dig #ns1.contabo.net. version.bind CH TXT tells that ns1 (which speculative truly might be the primary) is using PowerDNS.
The most common use (of many other options) of PowerDNS is i.c.w. MySQL.
So my best guess is that your ISP offers an web interface, to their database that holds the zone data.
To answer your question "Where are the DNS Zone files located?":
the zone data resides in several rows of a database table.
It's unlikely (but not impossible) that there are static zones-files.
And if so, I highly doubt that they would collect them from your filesystem.
For real answers better ask support at your supplier.
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.
I need to check a reverse dns using the DNS servers of some domains. But I'm having some problems.
dig -x 212.26.146.21 +short
mx20.gypost.com.
all ok
dig -x 212.26.146.21 #8.8.8.8 +short
mx20.gypost.com.
its ok too
dig SOA google.com +short
ns1.google.com. dns-admin.google.com. 2014021800 7200 1800 1209600 300
dig -x 212.26.146.21 #ns1.google.com +short
empty
I can't find reverse address using NS record of any domain. What i do wrong? And how i can check my reverse address using dns server of gmx.com, for example.
ns1.google.com (and the mail dns-admin.google.com) are used to handle the DNS zones of Google, they do not provide recursion thus you cannot query them for something that is not under their control.
Reverse-DNS entries are not part of the normal (i.e. forward) zones. To actually perform a reverse DNS lookup, you must reverse the order of octets in the ip address and add .in-addr.arpa and then perform a normal lookup.
So a reverse lookup for the address 212.26.146.21 actually translates to doing a lookup for 21.146.26.212.in-addr.arpa using the normal rules for finding nameservers from the top down. That is the correct way to find the authoritative nameservers for a reverse lookup.
Generally forward and reverse lookups are handled by quite different nameservers. The forward lookups are typically handled by nameservers provided by the entity that purchased the domain in question, while the reverse lookups are handled by whoever is administering the IP block in question (e.g. an ISP). So there is no direct link between nameservers responsible for resolving reverse lookups and whatever nameservers that are handling the normal (forward) domain.
So you either need to find the authoritative nameservers for the information you are looking for, or ask a recursive nameserver that by definition will do that work for you.
You are querying against the Authoritative nameserver for Google.
Your assumption here is that the same Google DNS server is authoritative for both the forward and reverse space, which is incorrect.
If you want to find the Authoritative nameserver for the reverse zone, you can do this with :
dig 146.26.212.in-addr.arpa NS
And if you want to then ask the reverse Authoritative Nameserver for the PTR record :
dig +norecurse #$(dig 146.26.212.in-addr.arpa NS +short | tail -1) 21.146.26.212.in-addr.arpa PTR
This gives me
; <<>> DiG 9.10.3-P4-Ubuntu <<>> +norecurse #ns.adamant.net. 21.146.26.212.in-addr.arpa PTR
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26088
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;21.146.26.212.in-addr.arpa. IN PTR
;; ANSWER SECTION:
21.146.26.212.in-addr.arpa. 86400 IN PTR telluris.com.ua.
;; Query time: 111 msec
;; SERVER: 212.26.128.2#53(212.26.128.2)
;; WHEN: Wed May 06 20:44:44 UTC 2020
;; MSG SIZE rcvd: 84
Made the purchase of a domain in a Brazilian company called UOL (Universo Online).
Once the domain has been registered, it came with the following standard DNS:
Nameserver: ns1.dominios.uol.com.br
Nameserver: ns2.dominios.uol.com.br
Nameserver: ns3.dominios.uol.com.br
I went into my hosting server and got the DNS server for me to upgrade in the field.
The DNS of the server hosting is:
http://i.imgur.com/kUTzcUZ.jpg
Went on the control panel of the company that bought the domain (UOL), removed the default DNS (ns1.dominios.uol.com.br, ns2 ... ns3 ...) and I upgraded to DNS of my webhost:
http://i.imgur.com/qk1VxB7.jpg
The company gave me a deadline 24-48 hours for DNS propagation.
I decided to enter the "intoDNS" (www.intodns.com) to check the situation and noticed that an error appears, see:
http://www.intodns.com/kiararockswithgnr.com
Is something wrong? Or is the DNS has not yet been propagated and I just wait?
According to the whois, the name servers for the domain are
Name Server: NS1.HOSTINGER.COM.BR
Name Server: NS2.HOSTINGER.COM.BR
Name Server: NS3.HOSTINGER.COM.BR
and this is confirmed by the DNS delegation
dig kiararockswithgnr.com +trace
kiararockswithgnr.com. 172800 IN NS ns1.hostinger.com.br.
kiararockswithgnr.com. 172800 IN NS ns2.hostinger.com.br.
kiararockswithgnr.com. 172800 IN NS ns3.hostinger.com.br.
;; Received 109 bytes from 192.42.93.30#53(192.42.93.30) in 2454 ms
If this is not what you are seeing, it's likely you are hitting a cached result.