[comp.protocols.tcp-ip] Confirming DNS name - what I really meant

ced@bcstec.uucp (Charles Derykus) (05/31/91)

>I thought telneting in through the "smtp" port and capturing the output 
>would be an option but the "smtp" output resists capture.
>
| By "resists capture", I presume you mean you wish to run this from a script.
| (Do you have 'mconnect', and if so, did you try this)?

Yes, I was working with a script. I'm not familiar with 'mconnect' and couldn't 
find it on the RS6000.

> I am not sure what you expect by telnetting to the smtp port.  That isn't
> going to tell you what the host calls itself.  It will tell you what the
> smtp software on the host call itself.  Given how common misconfigured
> mail software is, I would trust the DNS over the smtp dialogue for giving
> the name.

> Then there is the question of what you mean by "what the host actually
> calls itself".  A good guess is that when it is talking to itself, it
> usually calls itself 'localhost', but somehow I doubt that this is what
> you mean.

> Do you mean `hostname`?.  Do you mean `hostname`.`domainname` (assuming
> that domainname exists)?  Do you mean the result of canonicalizing one of
> these with a host table lookup?  or with a DNS lookup?  And in any case,
> why would you care?

My intent was to ensure that DNS matched machine x with its "real" name -
what was configured in smtp and hopefully the same as the /etc/hosts name
used for host name initialization during booting. If machine x's smtp name
mismatchs DNS's name for machine "x", won't mail delivery to "x" misfire
for example?


Charles DeRykus				Internet:   ced@bcstec.boeing.com
Boeing Computer Services		UUCP:	    ...!uunet!bcstec!ced
Renton, WA.  M/S 6R-37			(206) 234-9223

rickert@mp.cs.niu.edu (Neil Rickert) (05/31/91)

In article <895@bcstec.boeing.com> ced@bcstec.uucp (Charles Derykus) writes:
>
>My intent was to ensure that DNS matched machine x with its "real" name -
>what was configured in smtp and hopefully the same as the /etc/hosts name
>used for host name initialization during booting. If machine x's smtp name
>mismatchs DNS's name for machine "x", won't mail delivery to "x" misfire
>for example?

 If this kind of mismatch were so serious, probably half of the machines on
Internet would be unable to handle mail.  Actually you can usually tell
from the syslog entries or the 'Received:' headers whether your mailer
received mail from a system whose smtp name is different from its DNS
name.  The proportion of my syslog records showing this is not very high,
but that is because most of these misconfigured systems send their mail
to another system to forward it for them.

 If you are using 'sendmail', the SMTP name is determined by the $j
macro.  With most configuration setups, the handling of mail to your
domain is dependent on the class $=w, or perhaps $=w.$m .

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

jason@hpcndjdz.CND.HP.COM (Jason Zions) (06/03/91)

If the system you're interested in has an SNMP daemon running, then

% snmpget w.x.y.z public system.sysName.0

will usually do the trick. "public" is the community name for the SNMP
agent; this is the sort-of default and will work unless the admin folks
deliberately changed the configured community name.

If no daemon is running, or the community name is wrong, the request will
time out.
--
This is not an official statement of The Hewlett-Packard Company. No
warranty is expressed or implied. The information included herein is not to
be construed as a committment on HP's part. The devil made me do it. This
won't save me from the lawyers' wrath, but it can't hurt.

Jason Zions			The Hewlett-Packard Company
Colorado Networks Division	3404 E. Harmony Road
Mail Stop 102			Ft. Collins, CO  80525  USA
jason@cnd.hp.com		(303) 229-3800