nslookup from WinNT machine

[Brad Knowles]

At 8:54 PM -0400 5/29/01, Kevin Darcy wrote:

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

	Obviously, you have to have IP addresses assigned to the names in 
question -- there would be nothing else to put in the DNS otherwise. 
With that information, you have all you need to maintain PTR records. 
The same cannot be said for WKS or HINFO.

	Both WKS and HINFO require knowledge of what the machine is 
currently running today, and how that may be different from what it 
was running yesterday, or what it will be running tomorrow -- either 
in terms of programs & services, or the hardware, or the OS (and 
version).

	Now, tell me -- how many people in the world do you honestly 
think do proper resource management to the level that they can tell 
you at a moments notice precisely what version of what OS is running 
on precisely what hardware and precisely what programs & services 
should be running on that machine?


	PTR requires none of this.  PTR requires only knowing what the 
canonical name for the machine is, and what its IP address is. 
That's it.  That's information you should already have for each and 
every machine you have listed in your DNS.

	You can't lower the bar to access much more than this.

>  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 proponents of PTR records are the guys who invented the DNS 
and who have been the primary architects of the DNS since its 
invention.

	To paraphrase Carl Sagan, if you want to make an extraordinary 
claim that PTR records have absolutely no value whatsoever and should 
not continue to be maintained, then the burden is on *YOU* to come up 
with the extraordinary proof of your claims.

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

	I see your complaint as a fundamentally circular argument.  You 
refuse to accept the proof of the only documents which are capable of 
providing the proof, and yet you ask for more proof.

	Just what the fsck kind of proof would you actually accept 
then?!?  If you don't take Dave Barr's word for it, in the document 
he wrote on the subject, just who would you actually be willing to 
listen to?  Does someone have to physically come to your office and 
put a gun to your head and play Russian Roulette with six bullets 
loaded in a revolver?!?

>  I think you missed my point. IMO, one shouldn't be using DNS *at*all* for
>  authenticating remote-execution or remote-login.

	I'll agree with that statement.  Absolutely no authentication 
should be done that does not make proper and secure use of strong 
cryptographic techniques.

	However, unless you're willing to shut off all your computers 
until such time as all computer access of any sort is gated through 
proper and secure use of strong cryptographic techniques, you really 
don't have a leg to stand on.  The methods simply *WILL* be used that 
are available, and you have to deal with that -- whether you like it 
or not.

>                   The absence of PTR records discourages people from using
>  DNS as an authentication method, which in turn encourages them to look
>  towards cryptographic solutions.

	If everyone in the world did that at the same time, and everyone 
in the world was willing to abandon all non-cryptographic forms of 
authentication, that might be true.

	However, you're never going to get everyone in the world to agree 
to anything, especially when it comes up to giving up what little 
they may have achieved so far, and you cannot yet deliver to them the 
Panacea to take the place of everything else they've lost.


	Put your money where your mouth is, by turning off every single 
computer or electronic device you own or are directly or indirectly 
responsible for.  Then I might be willing to listen to your arguments.

>  The point is, the screwy in-addr.arpa namespace has a steep learning curve.

	Granted.

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

	In the case of PTR records, I believe you actually can -- they 
don't require any additional information beyond what you already have.


	All you have to do is take all your forward records and convert 
them into appropriately formatted reverse records, and then check 
your delegations to make sure that they are correct.

	These are things that are well within the capabilities of tools 
today, because we already have tools today that can check these 
things to see if you've done them correctly.

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

	Having a tool manage all this for you is certainly no substitute 
for properly understanding it all yourself.


	But you think that PTR records today are bad?  You just wait for 
IPv6.  The nightmare you know today cannot *BEGIN* to compare to the 
mega-nightmare to come.

	IIRC, PTR records are a critical part of IPsec which is integral 
to IPv6, so if you think you're in bad shape now, you cannot *BEGIN* 
to comprehend just how bad off you will be.

-- 
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,$_)}'