A few days ago I asked the following question:
>We are running NIS to resolve our local hostnames but use DNS to resolve non
>local hostnames. I noticed a strange problem with reverse lookups where the
>nameserver knows the hostname but sometimes NIS can not get the information.
>As you can see in the example below the reverse lookup through NIS fails for
>Princeton.NJ.NSS.NSF.NET but succeeds for nss.sura.net. Does anyone know what
>is going on?
The answer is simple: This is a security feature!
email@example.com (Casper H.S. Dik) writes:
>It is quite simple, really.When NIS does a reverse lookup, it
>follows that lookup with a lookup of the name found. If
>the address isn't one of the addresses returned for that host,
>the lookup fails. This is to prevent spoofing rlogind rshd mountd
>and other that rely on being able to reliably map addreses to names.
Christopher Davis <firstname.lastname@example.org> writes:
>This is because of a combination of NSFNET stupidity and Sun paranoia.
>Sun's gethostbyaddr (which gets fed to the ypmatch in this case) will
>not report a name unless the PTR record is matched by an A record for
>the same host (to prevent some security problems with hosts.equiv/rhosts).
>The NSFNET NSSes are not mapped properly on the A record side, i.e. a
>lookup for Princeton.NJ.NSS.NSF.NET *will not* return 188.8.131.52.
>This is why you're getting this "mixed result".
Thanks to all who replied:
email@example.com (Casper H.S. Dik)
firstname.lastname@example.org (Andy Feldt)
Christopher Davis <email@example.com>
lars@CMC.COM (Lars Poulsen)
firstname.lastname@example.org (Chris Burgess)
email@example.com (Per Hedeland)
jxh@attain.ICD.Teradyne.COM (Jim Hickstein)
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:35 CDT