Xref: utzoo comp.protocols.tcp-ip:16325 comp.unix.questions:31874
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!crdgw1!uunet!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!mouse
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.protocols.tcp-ip,comp.unix.questions
Subject: Re: Confirming DNS name matches local host name
Message-ID: <1991Jun1.201158.26109@thunder.mcrcim.mcgill.edu>
Date: 1 Jun 91 20:11:58 GMT
References: <891@bcstec.boeing.com>
Distribution: na
Organization: McGill Research Centre for Intelligent Machines
Lines: 62

In article <891@bcstec.boeing.com>, ced@bcstec.uucp (Charles Derykus) writes:

> Given an internet IP, is there a way to retrieve what the host at
> that IP actually calls itself.
(Questions generally end with `?', not `.'.)
> In other words, I want to confirm that what DNS says actually matches
> the local host name.

The generally-accepted way to do this is to ask the DNS for a PTR
record corresponding to the dotted-quad address with the quads reversed
and .in-addr.arpa appended.  For example, if I see a connection from
132.206.73.1, I might do something like

	[Thunder] 106> nstest 132.206.1.1
(132.206.1.1 is the local nameserver.)
	> p1.73.206.132.in-addr.arpa
(the p means ask for a PTR record; the rest is as I described above.)
	res_mkquery(0, 1.73.206.132.in-addr.arpa, 1, 12)
	res_send()
	HEADER:
		opcode = QUERY, id = 1, rcode = NOERROR
		header flags:  rd
		qdcount = 1, ancount = 0, nscount = 0, arcount = 0
		
	QUESTIONS:
		1.73.206.132.in-addr.arpa, type = PTR, class = IN
		
	Querying server (# 1) address = 132.206.1.1
	got answer:
	HEADER:
		opcode = QUERY, id = 1, rcode = NOERROR
		header flags:  qr aa rd ra
		qdcount = 1, ancount = 1, nscount = 0, arcount = 0
		
	QUESTIONS:
		1.73.206.132.in-addr.arpa, type = PTR, class = IN
		
	ANSWERS:
		1.73.206.132.in-addr.arpa
		type = PTR, class = IN, ttl = 86400, dlen = 29
		domain name = Lightning.McRCIM.McGill.EDU
		
	> 
(and there you are: 132.206.73.1 is Lightning.McRCIM.McGill.EDU.)

> I thought telneting in through the "smtp" port and capturing the
> output would be an option but the "smtp" output resists capture.

Check out the script(1) program; if you have it, that should be able to
deal with grabbing a copy of the session.

In any case, that's not really reliable.  The name reported on the SMTP
greeting message is all too often only vaguely related to the DNS name
of the machine.  (The first part is usually accurate, but the rest is
often the local YP - oops, NIS - or netinfo domain instead of the DNS
domain the machine is in, or sometimes absent altogether.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu