nslookup from WinNT machine

[Kevin Darcy]

Are you sure you diagnosed the problem properly? Was it the MX record or the
lack of a PTR record that was causing the problem? Note that a preference value
of 1 is perfectly legal.

As for the general practice of mailers refusing mail from IP addresses that
don't reverse-resolve, I consider that one of the crudest and most
false-rejection-prone anti-spam mechanisms ever dreamed up. I put it in roughly
the same category as basing your remote-execution/remote-login security on
.rhosts and/or hosts.equiv files.


- Kevin

Klinkefus, David S wrote:

> 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.
> >
> >