nslookup from WinNT machine

[Brad Knowles]

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.

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

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

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

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

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

-- 
Brad Knowles, <brad.knowles at skynet.be>

/*        efdtt.c  Author:  Charles M. Hannum <root at ihack.net>          */
/*       Represented as 1045 digit prime number by Phil Carmody         */
/*     Prime as DNS cname chain by Roy Arends and Walter Belgers        */
/*                                                                      */
/*     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob        */
/*   where title-key = "153 2 8 105 225" or other similar 5-byte key    */

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'