ced@bcstec.uucp (Charles Derykus) (05/31/91)
Given an internet IP, is there a way to retrieve what the host at that IP actually calls itself. In other words, I want to confirm that what DNS says actually matches the local host name. I thought telneting in through the "smtp" port and capturing the output would be an option but the "smtp" output resists capture. Any help or suggestions would be greatly appreciated. Charles DeRykus Internet: ced@bcstec.boeing.com Boeing Computer Services UUCP: ...!uunet!bcstec!ced Renton, WA. M/S 6R-37 (206) 234-9223
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/02/91)
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