Here is the main problem:
dig maktabkhooneh.info +trace
works perfectly fine and returns the right answer.
dig maktabkhooneh.info
(without +trace) returns:
; <<>> DiG 9.8.1-P1 <<>> maktabkhooneh.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58716
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
What could be the reason? I was reading this. Is it the only possible reason that I changed domain data 12hrs ago? Isn't there any other possible reason for SERVFAIL?
extra info:
I have two BIND servers working on 168.144.251.73 (master) and 168.144.92.50 (slave).
and on the master I have:
$TTL 300
maktabkhooneh.info. IN SOA ns1.maktabkhooneh.info.
admin.maktabkhooneh.info. (
2012060201 ; Serial
86400 ; Refresh
7200 ; Retry
3600000 ; Expire
300 ) ; Minimum
maktabkhooneh.info. IN A 168.144.97.83
maktabkhooneh.info. IN NS ns1.maktabkhooneh.info.
maktabkhooneh.info. IN NS ns2.maktabkhooneh.info.
ns1 IN A 168.144.251.73
ns2 IN A 168.144.92.50
www IN CNAME maktabkhooneh.info.
dig +trace follows the whole chain from the beginning - it queries root servers, then .info servers then your namservers. Thus it avoids any caching resolvers, and also avoids propagation issues.
dig +notrace (the default) queries your default DNS resolver (on Linux, whatever specified in /etc/resolv.conf).
There's some problem with that resolver - maybe it's misconfigured, maybe it has old data in its caches, maybe it can not reach your authoritative nameservers, etc.
In my case was a problem related to /etc/named.conf file. I could resolve this with the previous answer from Sandman and googling the way to fix a corrupted named.conf in cpanel. I had to access to shell console and type the following commands:
for backup the file
mv /etc/named.conf /etc/named.conf.bak
for rebuild the file
/usr/local/cpanel/scripts/rebuilddnsconfig
for restart the named service
/etc/init.d/named restart
ref: https://www.web24.com.au/tutorials/named-conf-fix-corrupted-named-conf-cpanel
Related
I want to make a relative path DNS query with dig. I have referenced the following documentation for dig(1) and resolv.conf(5).
dig(1) says:
+ndots=D
Set the number of dots that have to appear in name to D for it to be considered absolute. The default value is that defined using
the ndots statement in /etc/resolv.conf, or 1 if no ndots statement is
present. Names with fewer dots are interpreted as relative names and
will be searched for in the domains listed in the search or domain
directive in /etc/resolv.conf.
resolv.conf(5) says:
domain Local domain name.
Most queries for names within this domain can use short names relative
to the local domain. If set to '.', the root domain is considered.
If no domain entry is present, the domain is determined from the local
hostname returned by gethostname(2); the domain part is taken to be
everything after the first '.'. Finally, if the hostname does not
contain a domain part, the root domain is assumed.
My /etc/resolv.conf:
options timeout:2 attempts:3 rotate single-request-reopen
; generated by /usr/sbin/dhclient-script
domain nonexist.com
nameserver 100.100.2.136
nameserver 100.100.2.138
But running dig abc on a CentOS Linux release 7.6.1810 (Core) 64 bit OS results:
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> abc
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13347
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;abc. IN A
;; AUTHORITY SECTION:
abc. 9080 IN SOA ac1.nstld.com. info.verisign-grs.com. 1573282493 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 100.100.2.136#53(100.100.2.136)
;; WHEN: Sat Nov 09 15:23:42 CST 2019
;; MSG SIZE rcvd: 99
My expection is that abc should be suffixed with nonexist.com. and abc.nonexist.com. is used in the DNS query. But the above QUESTION SECTION has abc. instead of abc.nonexist.com.
Can anyone point out what is wrong with my setup?
dig(1) says:
+[no]search
Use [do not use] the search list defined by the searchlist or domain directive in resolv.conf (if any). The search list is not
used by default
This seems like I am either missing something obvious, or it would have been asked before. When I query dig using the -t parameter to specify a DNS record type, the result seems to contain an answer even if the record returned is a different record type. Here is an example:
$ dig -t A -q polestar.databaseguy.com.
; <<>> DiG 9.11.3-1ubuntu1.3-Ubuntu <<>> -t A polestar.databaseguy.com.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33130
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A
;; ANSWER SECTION:
polestar.databaseguy.com. 3600 IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net. 60 IN A 173.19.127.251
;; Query time: 30 msec
;; SERVER: 10.0.10.1#53(10.0.10.1)
;; WHEN: Mon Dec 10 14:41:50 STD 2018
;; MSG SIZE rcvd: 103
The CNAME and A records listed in the ANSWER SECTION are correct. However, the CNAME is for polestar.databaseguy.com. and the A is for databaseguy.ddns.net.. There is no A record forpolestar.databaseguy.com., which is what I queried for, so I expected there to be no results.
I am pretty confident this is the correct behavior, but I don't understand it and didn't see any explanation in the man dig pages. I also could not find other discussions online, either on this site or elsewhere. Can someone help me understand this?
This is the expected behaviour, that decreases the amount of exchanges needed, and is specific of the CNAME record.
It is covered by the core documents on DNS: RFC1034, section 3.6.2
See this:
CNAME RRs cause special action in DNS software. When a name server
fails to find a desired RR in the resource set associated with the
domain name, it checks to see if the resource set consists of a CNAME
record with a matching class. If so, the name server includes the
CNAME record in the response and restarts the query at the domain name
specified in the data field of the CNAME record. The one exception to
this rule is that queries which match the CNAME type are not
restarted.
With the clear example that completely matches your case:
For example, suppose a name server was processing a query with for
USC-ISIC.ARPA, asking for type A information, and had the following
resource records:
USC-ISIC.ARPA IN CNAME C.ISI.EDU
C.ISI.EDU IN A 10.0.0.52
Both of these RRs would be returned in the response to the type A
query, while a type CNAME or * query should return just the CNAME.
See section 5.2.2 for other points.
Sections 6.2.7 and 6.2.8 also gives examples.
It also depends if you query a recursive or an authoritative nameserver.
databaseguy.com has for nameservers:
pdns01.domaincontrol.com.
pdns02.domaincontrol.com.
If you query one of them:
$ dig A polestar.databaseguy.com. #pdns01.domaincontrol.com.
; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. #pdns01.domaincontrol.com.
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: e45ebc418c94c90a
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A
;; QUERY SIZE: 65
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64115
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;polestar.databaseguy.com. IN A
;; ANSWER SECTION:
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
You get only the CNAME value because this authoritative nameserver knows only that, and is not authoritative for ddns.net.
But if you ask any recursive nameserver it does the job of recursing and giving you the "full" reply:
$ for ns in 1.1.1.1 8.8.8.8 9.9.9.9 80.80.80.80 ; do dig A polestar.databaseguy.com. #$ns +noall +ans ; done
; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. #1.1.1.1 +noall +ans
;; global options: +cmd
;; connection timed out; no servers could be reached
; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. #8.8.8.8 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 59m59s IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net. 59s IN A 173.19.127.251
; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. #9.9.9.9 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net. 1m IN A 173.19.127.251
; <<>> DiG 9.12.0 <<>> A polestar.databaseguy.com. #80.80.80.80 +noall +ans
;; global options: +cmd
polestar.databaseguy.com. 1h IN CNAME databaseguy.ddns.net.
databaseguy.ddns.net. 1m IN A 173.19.127.251
(1.1.1.1 did not reply to my query but this is irrelevant here for this question)
So about "There is no A record forpolestar.databaseguy.com., which is what I queried for, so I expected there to be no results." this is halfway wrong because that name has a CNAME which means another canonical name and this canonical name has an A record so at the end of the day it is exactly as if the starting name had an A record. Any application locally asking the OS for the IP address of that host will get the A record, as the OS will take care of the full recursive resolution and "dereferencing" the CNAME.
I have some DNS issues and I am trying to figure out if this is a correct I should get when I run this on VPS
getent hosts test.com
69.xx.xx.xxx server.test.com server www.test.com www test.com test testuser
for other sites the answer looks like this
getent hosts justhost.com
74.220.195.132 justhost.com
Are the first result ok? where are the values taken from?
Update:
If it helps
nslookup test.com 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#53
server can't find test.com: NXDOMAIN
dig #localhost test.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56197
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;test.com. IN A
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Feb 24 14:32:24 2015
;; MSG SIZE rcvd: 41
Pinging the ns1 gives me the correct server ip
Pinging the domain name gives me the old server ip
Is this usual?
From an analysis on intoDNS (http://www.intodns.com/blackcatadvertising.com) it seems that the nameserver are not setted properly. Check both on your DNS provider (if it's not you) and on cPanel how they are setted. If you are sure that they are right as they are right now I would ask when did you created the domain? Sometime is required after the creation in order to let the DNS spread
fixed via How to fix a dig command with status: REFUSED?, basically I had to edit names.conf to have allow-query to any, and restart names
Some time ago I setup a site with some subdomains (example.com, test.example.com...)
Last week I added a new subdomain new.example.com and today I've realize that when I dig to the secondary server I get the SOA record as a response, not the answer itself:
root#Nigeria:~$ dig new.example.com #ns.kimsufi.com
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> new.example.com #ns.kimsufi.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11559
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;new.example.com. IN A
;; AUTHORITY SECTION:
example.com. 86400 IN SOA ns345678.ip-93-122-113.eu. info.test.com. 2015021005 28800 7200 604800 86400
;; Query time: 36 msec
;; SERVER: 213.186.33.199#53(213.186.33.199)
;; WHEN: Mon Feb 16 11:14:35 2015
;; MSG SIZE rcvd: 108
I'm wondering why I'm getting an authority response instead of the right response. If I dig into 'ns345678.ip-93-122-113.eu' which is the right server where my website and my DNS server is hosted, I get the expected response:
;; ANSWER SECTION:
new.example.com. 86400 IN A 93.122.113.255
Why the secondary DNS is not giving an answer to the new subdomain? It is giving an answer to old subdomains like 'test.example.com'. And how I must interpret the SOA response? What does it mean?
A SOA record in the Authority segment together with having the AA flag set is an indication that the reply is authoritative. So what the response you pasted means is that ns.kimsufi.com says that it knows with certainty that the name you asked for (new.example.com) does not exist.
And if you hadn't hidden the actual domain name, someone might have been able to tell you the reason you're not getting the response you expect. But as it is, this is about all you will get.
My server is a Ubuntu, and I have installed webmin/virtualmin and I´m trying to create my NSRecord ns1 and ns2.
I run this command:
dig #localhost mydomain.info
; DiG 9.7.3 #localhost mydomain.info
; (1 server found)
;; global options: +cmd
;; Got answer:
;; HEADER opcode: QUERY, status: NOERROR, id: 64570
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;mydomain.info. IN A
;; ANSWER SECTION:
mydomain.info. 38400 IN A 10.28.166.120
;; AUTHORITY SECTION:
mydomain.info. 38400 IN NS ns1.mydomain.info.
;; ADDITIONAL SECTION:
ns1.mydomain.info. 38400 IN A 10.28.166.120
But 10.28.166.120 it´s my local IP, I try to find any information on /var/log/syslog about Bind and I didn´t see anything.
In Firewall I configured the ports like this:
Incoming open ports:
TCP/53
UDP/53
Outgoing open ports:
TCP/53
UDP/53
TCP/1024-65535
UDP/1024-65535
So, know I put my complete dns record:
$ttl 38400
# IN SOA ns1.mydomain.info. root.ns1.mydomain.info. (
1342267814
10800
3600
604800
38400 )
# IN NS ns1.mydomain.info.
mydomain.info. IN A 10.28.166.120
www.mydomain.info. IN A 10.28.166.120
ftp.mydomain.info. IN A 10.28.166.120
m.mydomain.info. IN A 10.28.166.120
ns1.mydomain.info. IN A 999.999.999.999
localhost.mydomain.info. IN A 127.0.0.1
webmail.mydomain.info. IN A 10.28.166.120
admin.mydomain.info. IN A 10.28.166.120
mydomain.info. IN TXT "v=spf1 a mx a:mydomain.info ip4:10.28.166.120 ?all"
999.999.999.999 = my external IP
I´m tried post some questions like this and anyone help on other forums. If anyone don´t undestand something I will try to explain.
Thank´s.
BIND runs as named, so that is what you should look for in the logs. (Though nothing is actually wrong with this setup, so I doubt there would be anything in the logs).
I'm not sure how you've set up the records in your zone, but each NS record points to an A record. The NS record looks fine, but the A record is wrong. The other NS record and/or its corresponding A record are missing. You will have to change the A record for ns1.mydomain.info. to your external address. There is no simple way to use both an internal and external IP for a single machine (for a complicated way, see split-horizon views).