[SOLVED] Why nslookup fails for certain domain?

postcd · 01-02-2014, 06:58 AM

When i do this:

Code:

nslookup -type=ns zlatapraha.cz
;; Got SERVFAIL reply from 8.8.8.8, trying next server
;; Got SERVFAIL reply from 8.8.8.8, trying next server
Server:         8.8.4.4
Address:        8.8.4.4#53

** server can't find zlatapraha.cz: SERVFAIL

I get an error, but in whois output of this domain im getting nameservers. Why it failed?

Here is another domain .cz which dont fails...

Code:

nslookup -type=ns seznam.cz
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
seznam.cz       nameserver = ms.seznam.cz.
seznam.cz       nameserver = ns.seznam.cz.

Authoritative answers can be found from:

Im interested how to fix the failure with first domain, why it dont output nameservers?

--
another serv fail im getting with domain: vpscorner.co.uk for example

zhjim · 01-02-2014, 07:49 AM

My bold guess is that the ns server for zlatapraha.cz does not have any RR's for the domain itself. Its like going to a certain street and address to only found the house not beeing there.

Have ns.gransy.com to have valid resource records for zlataphra.cz.

jefro · 01-02-2014, 08:34 PM

Use more dns server ip's. Best to use one in your area or country specific.

Worse comes to worse, use a hosts entry but don't forget it is there.

postcd · 01-03-2014, 04:24 AM

Quote:

Originally Posted by zhjim

does not have any RR's for the domain itself

What are RRs?

Quote:

Originally Posted by zhjim

Have ... to have valid resource records for ....

Please what are these resource records, i dont understand

Quote:

Originally Posted by jefro

Worse comes to worse, use a hosts entry but don't forget it is there.

I dont understand what you mean there

wildwizard · 01-03-2014, 05:10 AM

Quote:

Originally Posted by postcd

When i do this:

Code:

nslookup -type=ns zlatapraha.cz

nslookup is a waste of time

Code:

michael@indigo:~$ dig +trace zlatapraha.cz

; <<>> DiG 9.9.3-P2 <<>> +trace zlatapraha.cz
;; global options: +cmd
.                       516935  IN      NS      f.root-servers.net.
.                       516935  IN      NS      k.root-servers.net.
.                       516935  IN      NS      l.root-servers.net.
.                       516935  IN      NS      j.root-servers.net.
.                       516935  IN      NS      c.root-servers.net.
.                       516935  IN      NS      b.root-servers.net.
.                       516935  IN      NS      m.root-servers.net.
.                       516935  IN      NS      a.root-servers.net.
.                       516935  IN      NS      i.root-servers.net.
.                       516935  IN      NS      d.root-servers.net.
.                       516935  IN      NS      h.root-servers.net.
.                       516935  IN      NS      e.root-servers.net.
.                       516935  IN      NS      g.root-servers.net.
.                       517673  IN      RRSIG   NS 8 0 518400 20140110000000 20140102230000 33655 . <RRSIG SNIPPED>
;; Received 857 bytes from 127.0.0.1#53(127.0.0.1) in 4 ms

cz.                     172800  IN      NS      a.ns.nic.cz.
cz.                     172800  IN      NS      c.ns.nic.cz.
cz.                     172800  IN      NS      d.ns.nic.cz.
cz.                     172800  IN      NS      b.ns.nic.cz.
cz.                     86400   IN      DS      54576 10 2 397E50C85EDE9CDE33F363A9E66FD1B216D788F8DD438A57A423A386 869C8F06
cz.                     86400   IN      RRSIG   DS 8 1 86400 20140110000000 20140102230000 33655 . <RRSIG SNIPPED>
;; Received 496 bytes from 192.5.5.241#53(f.root-servers.net) in 166 ms

zlatapraha.cz.          18000   IN      NS      ns.gransy.com.
zlatapraha.cz.          18000   IN      NS      ns2.gransy.com.
zlatapraha.cz.          18000   IN      NS      ns3.gransy.com.
zlatapraha.cz.          18000   IN      NS      ns4.gransy.com.
zlatapraha.cz.          18000   IN      NS      ns5.gransy.com.
u097cni3ftnhse37q4ghrjcvskj7qu6c.cz. 900 IN NSEC3 1 0 10 34215ABE4C2AF1F5 U0995C52JEJFKIRT9FP0EIPPO3BQ5ECA NS
u097cni3ftnhse37q4ghrjcvskj7qu6c.cz. 900 IN RRSIG NSEC3 10 2 900 20140110164137 20131227220727 40877 cz. <RRSIG SNIPPED>
;; Received 385 bytes from 194.0.13.1#53(b.ns.nic.cz) in 364 ms

;; Received 42 bytes from 89.187.132.100#53(ns2.gransy.com) in 349 ms

From this we get the DNS servers that are shown by the DNS system to be authoritative for the domain, but no actual response other than 42 bytes.

Perhaps if we query those servers directly and see what that response is :-

Code:

michael@indigo:~$ dig @ns.gransy.com zlatapraha.cz

; <<>> DiG 9.9.3-P2 <<>> @ns.gransy.com zlatapraha.cz
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 9744
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;zlatapraha.cz.                 IN      A

;; Query time: 386 msec
;; SERVER: 77.78.104.149#53(77.78.104.149)
;; WHEN: Fri Jan 03 20:00:11 EST 2014
;; MSG SIZE  rcvd: 42

So now we can see that the server that has been listed as authoritative doesn't actually think that it is and since it denies recursion the lookup fails at that point.

To fix this you need to either change the whois DNS data to the real servers or contact the gransy.com administrators and get them to add the domain to their servers.

jeffmonte · 01-03-2014, 05:25 AM

When you look at http://www.intodns.com/seznam.cz and http://www.intodns.com/zlatapraha.cz you will see the DNS zones for the authoritative name servers defined at registrar end are missing for the domain zlatapraha.cz. It has to be addressed with creating DNS zone records (A records for ns name servers) at their respective host.

zhjim · 01-03-2014, 08:52 AM

Quote:

Originally Posted by postcd

What are RRs?

Please what are these resource records, i dont understand

RR = resource records

http://en.wikipedia.org/wiki/Resourc...source_records

Quote:

Originally Posted by postcd

I dont understand what you mean there

You have a /etc/hosts file that works as a basic name resolution thingy. man hosts for the rescue

*edit*
Thanks for sharing intodns. Looking nice.

Mani84 · 01-03-2014, 10:35 AM

I am suspecting its an issue with EDNS.

This DNS query fails all the time for this domain or if you try few times,does it work?

Habitual · 01-03-2014, 02:06 PM

n/m.
Speed posting, again.

ie. what jeffmonte "said"

jefro · 01-04-2014, 03:40 PM

A method to fix name to ip resolution was common a very long time ago. It is a file called hosts. In that hosts file you can add in local machines or use to fix bad sites or correct dns by adding a name to ip.

Hosts file is always looked up first in every OS that I know of. There is one exception and that is when a proxy.pac file is used in browser. That over rides hosts.

If a country specific dns is used, it sometimes has more correct data. Use that dns server as first in order.

nslookup isn't a bad command at all. It along with dig can be used.

wildwizard · 01-05-2014, 03:00 AM

Quote:

Originally Posted by jefro

Hosts file is always looked up first in every OS that I know of. There is one exception and that is when a proxy.pac file is used in browser. That over rides hosts.

proxy.pac is just a automated method of setting up proxy servers.

The problem with hosts and any proxy server is the proxy server has to do the DNS lookup as well as the client and if that proxy server is some other machine then you will get the results that that machine gets instead of what the client thinks.

FYI the problem the OP has should not to be fixed with a host file as the domain is real and needs to be fixed properly not with some "hack"

jefro · 01-05-2014, 11:00 AM

Hosts files are not a hack at all. They are a common task for admins. Almost OS for the last 30 years has a hosts and uses it. It is not there for wasting disk space.

His choice of dns and their reply is the problem isn't it? Sometimes the simple fixes are the best. If only one or two sites caused me issues, I'd not waste time trying to correct dns records above me.

Just saying that if the OP uses proxy.pac then they need to create a custom proxy.pac file that has a direct to match up the correct name to ip. Similar edit to what one would do in hosts file. I've used proxy.pac files for decades.

wildwizard · 01-06-2014, 03:30 AM

Quote:

Originally Posted by jefro

His choice of dns and their reply is the problem isn't it? Sometimes the simple fixes are the best. If only one or two sites caused me issues, I'd not waste time trying to correct dns records above me.

The OP asked for a fix not a hack.

postcd · 01-06-2014, 09:55 AM

The domains im mentioning are not mine, so i cant do anything with them.....
I just wanted to know why it fails, and if i can fix it any other way from linux CLI, and to discover what are actual that domain nameservers. (except dig + trace)

jefro · 01-06-2014, 10:11 AM

To fix it use a hosts file entry. It is not a hack. If it were a hack, they you would not have a hosts file in every distro made.

The other way to fix it would be to use a dns server that offers correct name resolution.

The other way to fix it is to correct the dns server that you are using.

The other way to fix it is to create you own local dns server and use corrected ip addresses for some names.

Admin's tip.

By the way, to speed up internet use, one could put the names of the 200 (or more) most common web sites that they access. It takes much less time to access the hosts file than it does to access a dns server. The hosts file is ALWAYS looked up by default still.