strange nslookup replies

[Jim Reid]

>>>>> "Kapil" == Kapil Sethi <kapil.sethi at fluxart.com> writes:

    >> # whois -h www.networksolutions.com nick.com Domain servers in
    >> listed order:
    >> 
    >> NS1.VISNETOPS.COM 166.77.12.11 
    >> AUTH02.NS.UU.NET 198.6.1.82 
    >> MADISON.VISLAB.COM 166.77.18.11
    >> FIRE-NYC.VIACOM.COM 166.77.235.211
    >> 
    >> This shows that ns1.visnetops.com is the primary server for the
    >> domain.

How do you figure that out? Where does it say that the first listed
name server in a whois answer is the zone's master (primary) server?

    >> But on the other hand, when I use one of the root servers and
    >> do a nslookup query on it, this is what i get
    >> 
    >> # nslookup
    >> 
    >> > set type=SOA 
    >> > server A.ROOT-SERVERS.NET 
    >> Server:A.ROOT-SERVERS.NET
    >> Address: 198.41.0.4
    >> > www.nick.com 
    >> Server: A.ROOT-SERVERS.NET
    >> Address: 198.41.0.4
    >> Authoritative answers can be found from: 
    >> NICK.COM	nameserver = AUTH02.NS.UU.NET
    >> NICK.COM nameserver = MADISON.VISLAB.COM
    >> NICK.COM nameserver = NS1.VISNETOPS.COM 
    >> NICK.COM nameserver = FIRE-NYC.VIACOM.COM
    >> AUTH02.NS.UU.NET internet address = 198.6.1.82
    >> MADISON.VISLAB.COM internet address = 166.77.18.11
    >> NS1.VISNETOPS.COM internet address = 166.77.12.11
    >> FIRE-NYC.VIACOM.COM internet address = 166.77.235.211
    >> 
    >> This is what I get????

    >> Why is there difference in the order??? Any reason.

The order is different because name servers round-robin resource
records of the same name and type. So when some zone has name servers
A, B and C, the first answer the name server hands out has the 3 NS
records in order A, B, C. The next has B, C, A. The one after that is
C, B, A and the query after that is gets an answer A, B, C. Note that
the answer is the same - the same RRs are returned every time - even
though the ordering of the RRs is different.

You seem to be under the misconception that DNS lookups always go to
the master (primary) server first and fall back to the slave
(secondary) servers. This is not so. Name servers keep track of the
round-trip time (RTT) to other name servers. They tend to use the one
that has the lowest RTT because it's closest. It doesn't matter
whether that server is master or not for the zone. In some cases, DNS
administrators don't even advertise their master name server in either
the DNS or the whois database.

    Kapil> to my knowledge either the SOA record is missing

The answer you got from a.root-servers.net was a referral. The root
servers don't recurse. They haven't got the horsepower to do that
given how many queries they get. So the answer you got from
a.root-servers.net say "go and ask these name servers about nick.com,
don't ask me". If you'd asked a server which did handle recursive
queries, it would have given you the SOA record for nick.com:

	gromit% dig nick.com soa
	
	; <<>> DiG 8.2 <<>> nick.com soa 
	;; res options: init recurs defnam dnsrch
	;; got answer:
	;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
	;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4
	;; QUERY SECTION:
	;;      nick.com, type = SOA, class = IN

	;; ANSWER SECTION:
	nick.com.               8H IN SOA       ns1.visnetops.com. hostmaster.visnetops.com. (
                                        2000061201      ; serial
                                        1H              ; refresh
                                        30M             ; retry
                                        3D              ; expiry
                                        8H )            ; minimum


	;; AUTHORITY SECTION:
	nick.com.               8H IN NS        ns1.visnetops.com.
	nick.com.               8H IN NS        madison.vislab.com.
	nick.com.               8H IN NS        fire-nyc.viacom.com.
	nick.com.               8H IN NS        auth02.ns.uu.net.

	;; ADDITIONAL SECTION:
	ns1.visnetops.com.      8H IN A         166.77.12.11
	madison.vislab.com.     2H IN A         166.77.18.11
	fire-nyc.viacom.com.    12H IN A        166.77.235.211
	auth02.ns.uu.net.       1d22h31m24s IN A  198.6.1.82

	;; Total query time: 253 msec
	;; FROM: gromit.rfc1035.com to SERVER: default -- 62.6.242.9
	;; WHEN: Wed Jun 14 07:23:40 2000
	;; MSG SIZE  sent: 26  rcvd: 257


On and PLEASE use dig for dns lookups. It's a far, far better tool
than nslookup. nslookup is abysmally bad. It does all sorts of stupid
and unnecessary things - like a reverse lookup of the server it queries
- and then breaks if these fail. I hope you can see from the above
example that dig's output is much more informative than nslookup.