nslookup from WinNT machine

[Kevin Darcy]

Brad Knowles wrote:

> At 5:14 PM -0400 5/29/01, Kevin Darcy wrote:
>
> >  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.
>
>         Not at all.  They were deprecated in practice because they were
> more hassle than they were worth (hard to keep up-to-date with
> whatever the machine was actually running at the moment), or even
> made it easier for people to successfully attack your systems.
>
>         Neither of these statements is anywhere near remotely true for PTR records.

I agree that the security (gratuitous information-disclosure) flaws of HINFO and/or
WKS records don't really apply to PTR records. But as for "more hassle than they [a]re
worth", that's open to debate. And as for "hard to keep up-to-date", that's true even
of PTR, to a point. Certainly -- trivially -- not maintaining PTRs at all is easier
than maintaining them.

> >  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.
>
>         As far as it goes, this much is true.  However, you still have
> not (nor will you be capable of) demonstrating how PTR records are
> not useful in practice, and therefore your entire premise falls flat.

Why should I have to prove a negative? Seems like it makes more sense for the
proponents of PTR to prove that they are worth the time and effort and expense it
takes to maintain them. The burden of proof IMO should be on those that expect others
to expend resources in the name of "best practice" than on the skeptics who ask "why
bother?" or "what's in it for me?".

> >  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?
>
>         Read RFC 1912 "Common DNS Errors".  PTR records are important
> enough that they rate being discussed first of all DNS RR types, in
> section 2.1 (SOA records get discussed in section 2.2).  Section
> 2.6.1 and 2.6.2 address WKS and HINFO, although in practice HINFO has
> fallen into disuse far beyond what is described and at the very least
> almost certainly is no longer worth bothering with.
>
>         RP records (2.6.4) never really took off, although I think that
> they could have been a good idea.  Personally, I suggest that you
> just skip section 2.7, but Dave would probably disagree with me.
>
>         Most of the rest of this RFC is discussing typical problems and
> how to debug them, although section 4.1 (file format for
> /etc/named.boot) is obviously no longer relevant to BIND 8 & 9.

Again, you're citing RFCs to justify the maintenance of PTRs. But I see this as
fundamentally a circular argument, since features of the protocol which are maintained
poorly or not at all tend to get officially deprecated eventually. If adherence to the
standard is the *only* reason for maintaining a particular record type, and the
*only* reason that the feature hasn't been deprecated because it's still in active
use, then that's a tautology. Lots of things were recommended in the early days of DNS
(and over the subsequent years) that really haven't proven their utility. HINFO and
WKS are obvious examples; RP is borderline and PTR is highly arguable. So saying "one
should maintain PTRs because the RFCs say so" doesn't carry much weight with me,
without other supporting justifications for why PTRs are any more intrinsically useful
or necessary than HINFO and WKS records, etc. were thought to be way back when.

An _a_propos_ quote I saw today on a local mailing list:


> I am now going to make you a gift that will stay with you the rest of your
>   life.  For the rest of your life, every time you say "we've always done it
>   that way," my ghost will appear and haunt you for twenty-four hours.
>                                                       -- Grace Murray Hopper
>


> >  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).
>
>         Where on earth did you come up with this?  Anybody who ever does
> anything with IP/name level security knows that you always do a
> combined backwards/forwards/backwards resolution (following CNAME
> chains when necessary, and collecting answers from multiple paths if
> such exist), before even bothering to compare what you've got on one
> side with what you've got on the other.
>
>         Indeed, I can't think of any modern applications which do any
> amount of this kind of checking that do not do the proper
> backwards/forwards/backwards resolution.

I think you missed my point. IMO, one shouldn't be using DNS *at*all* for
authenticating remote-execution or remote-login. Doesn't matter if one does
double/triple/forward/reverse/somersault lookups or whatever, DNS just isn't secure
enough at present to rely on it for authentication. One needs crypto, as you yourself
appear to have admitted in another post in this thread. The absence of PTR records
discourages people from using DNS as an authentication method, which in turn
encourages them to look towards cryptographic solutions. Which I think is a Good
Thing.

> >  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.
>
>         Then they need to be using better management tools, or better
> yet, they need to understand what the hell it is they're supposed to
> be doing.

The point is, the screwy in-addr.arpa namespace has a steep learning curve. Some
people "get it" fairly quickly, but many do not. And you can't expect a whiz-bang
management tool to do your thinking for you -- it's just a tool after all. The
inherent incomprehensibility of reverse DNS *is* a negative, the question is, is it
enough of a negative, along with the other negatives, to outweigh the convenience of
having it?

> >  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?
>
>         You need to talk to Bill Manning and Dave Barr.  Maybe Paul Vixie, too.

Maybe I'll do just that.


- Kevin