nslookup from WinNT machine

[Klinkefus, David S]

The first thing that comes to mind for me is e-mail. I had a user that was
expecting an e-mail subscription service that was coming from
energycentral.com.
Since the MX record was setup as energycentral.com with a preference of 1.
Since
our firewall could not do successful lookup of the forward/reverse address
of the
mail server, namely energycentral.com, it wouldn't accept any messages from
that
domain. I **could** have added them to the allowed hosts list, but that is
not the
correct way to resolve this issue. 

I asked the admin to either change the preference on the MX record, or
remove it completely,
and he did remove the MX record, and the user is getting his e-mails from
the service once more.

So in short, that is one instance that I can think of where a **correct**
PTR record is a must!

Dave K.
MEC

-----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
Sent: Tuesday, May 29, 2001 4:15 PM
To: comp-protocols-dns-bind at moderators.isc.org
Subject: Re: nslookup from WinNT machine



I think you're putting the cart before the horse here. The reason that
HINFO and/or WKS were deprecated was because people stopped caring about
maintaining them. If people stopped caring about maintaining PTR records,
eventually the standards documents would probably deprecate them also.
Oftentimes standards lead common practice, but when it comes to deprecation,
they generally *follow* common practice. Things that don't get used
productively/consistently and just end up cluttering the protocol, generally
get deprecated eventually, to keep the protocols as clean as possible.

So, if the "do it because the standards say so, and the standards still say
so (as opposed to, say, HINFO and WKS records) only because people are still
doing it" argument is a circular one, are there any *non-circular* arguments
for maintaining PTR records?

I can think of a couple of arguments *against* maintaining PTR records:

1) Their existence encourages/fosters/enables bad security practices (e.g.
.rhosts and/or hosts.equiv files).

2) Newbies seem to always have problems comprehending the weirdo "reverse
the
octets and append in-addr.arpa" syntax of reverse records, let alone
classless delegation a la RFC 2317.

Lately, I've being starting to think that PTR records are more trouble than
they're worth. I still maintain them (well, actually my software maintains
them automatically), but over time I'm less and less sure why it makes sense
to do so. I'm losing my faith in the utility of PTRs, can anyone
reinvigorate
it?


- Kevin

Brad Knowles wrote:

> At 3:13 PM -0400 5/29/01, Kevin Darcy wrote:
>
> >>>  Well, I don't maintain HINFO or WKS records, is that a sign of my
> >>>  negligence or ignorance?
> >>
> >>  no, they are not needed to be a good 'netizen'. PTR records are.
> >
> >  Seems rather arbitrary to me.
>
>         Not really.  RFC 1123 (STD 0003) effectively deprecates WKS in
> sections 5.2.12 and 6.1.3.6.  RFC 2219 (BCP 0017) recommends a
> particular set of naming conventions to largely replace WKS in
> real-world practical use.
>
>         However, I have not yet found any more formal deprecation of WKS
> records.  If anyone knows of such, I would appreciate hearing about
> it.
>
>         HINFO records have been deprecated in practice for a while now,
> but I'm having some difficulty finding out exactly when that started
> happening, and if that fact has been written down anywhere
> semi-official.
>
>         I can tell you that if you look at the HINFO section of RFC 1700
> (the latest Assigned Numbers RFC, also STD 0002), you will see that
> the officially approved list of names is quite ancient (that's
> because the standard hasn't been updated since 1994), and you are
> referred to
> <ftp://ftp.isi.edu/in-notes/iana/assignments/machine-names> for the
> latest version.
>
>         I'm trying to download this file now, but I imagine that it
> probably hasn't been touched since 1994 either, and that would mean
> that the HINFO record has been effectively deprecated since then --
> actually, the time stamp on this file is Monday, February 19, 1996,
> but that's effectively the same thing.
>
>