nslookup from WinNT machine

[Kevin Darcy]

Brad Knowles wrote:

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

You seem to be glossing over the fact that every time A records are changed, the
corresponding PTR records also need to be changed. They don't *automatically*
keep themeselves up to date. A person or a piece of software needs to do that.
Like I said, keeping PTRs up to date, while maybe not "hard", still requires the
exertion of effort, the use of resources, etc. The question is: are the benefits
of maintaining PTRs worth it?

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

I have never said that PTRs have "absolutely no value". I've always said that
they provide a degree of convenience, for instance. The question I am raising is:
does their (IMO negligible) value justify the cost of maintaining them? I do this
in the context of 2 major developments which have occurred since PTRs and the
in-addr.arpa namespace were first proposed:

1) Some records which were thought to the "useful" in the 80's, namely HINFO and
WKS, turned out to be not worth the trouble of maintaining. This refutes the idea
that the "primary architects of the DNS" were so prescient as to be able to
predict with 100% accuracy what record types would prove to be useful in 2001 or
beyond.

2) We have passed the age of innocence in terms of security methodologies.
Source-IP-based authentication, which reverse-DNS facilitates, has proven to be
inadequate and other crypto-based methodologies have evolved to take its place.

Is it so "extraordinary" to question whether, after the incredible explosion of
technology over the last decade or so, that the basic assumptions underlying the
recommendation to maintain reverse DNS, may have changed, or be completely
invalid? My opinion is that *whenever* someone tells me I "should" obey some rule
or another, and I see no value in doing so, that the burden of proof is on them
to show why I should comply. Doesn't matter whether the rule dates back to the
1980's or to Julius Caesar; the burden of proof still remains with the one
attempting to enforce or promulgate the rule.

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

I think you fail to grasp the difference between normative and informative
content. Sure, if there is *informative* documentation which explains why
maintaining in-addr.arpa is a Good Thing, then I'm open to that. But to try to
justify maintaining in-addr.arpa by referring only to *normative*
documentation/specification (i.e. basically "do it because we say so"), is
circular.

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

I assume you're referring to RFC 1912. Although that is technically an
"informational" RFC, I consider it mainly normative in content ("you should do
X", "you shouldn't do Y"), but lacking the force of a standard or even a Best
Current Practice. The relevant section reads as follows:


> Make sure your PTR and A records match.  For every IP address, there
>    should be a matching PTR record in the in-addr.arpa domain.  If a
>    host is multi-homed, (more than one IP address) make sure that all IP
>    addresses have a corresponding PTR record (not just the first one).
>    Failure to have matching PTR and A records can cause loss of Internet
>    services similar to not being registered in the DNS at all.
>
So basically this boils down to: "if you don't have good PTR records, some
servers may give you trouble". But, what is missing here is an explanation of
*why* that would be the case. The reason is because those servers are using PTRs
for *authentication*. But we've already established -- I think -- that this is
not a legitimate security methodology. As PTRs disappear, the servers which use
them for authentication will be upgraded to no longer do so. This is a migration
issue at most.

> Does someone have to physically come to your office and
> put a gun to your head and play Russian Roulette with six bulletsloaded in a
> revolver?!?

I don't think allusions to violence are called for.

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

Again, you're stumbling into a circularity. Maintenance of reverse
DNS *facilitates* the use of source-IP-based authentication. Take away reverse
DNS, and suddenly source-IP-based authentication becomes a lot less palatable --
every time the client's IP changes, the .rhosts/hosts.equiv file has to be
updated to reflect the new IP address. Reverse DNS "enables" source-IP-based
authentication in a psychobabble kind of way (i.e. like a person's family might
"enable" their substance abuse). Like I said, time to break the crutch. If you
get rid of reverse DNS, that will accelerate the demise of source-IP-based
authentication.

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

It doesn't need to be done simultaneously. It can be done incrementally and
gradually. One organization at a time, one project at a time. They switch over to
using crypto and then just don't bother maintaining PTRs any more. We're already
well along this curve. Perhaps this is why I'm sounding the clarion call. Because
PTRs don't have much value around here any more. In fact, they may have slipped
below 0 usefulness. And if it's true for a sluggish "old economy" organization
like ours, surely it'll be true for many other organizations in short order.

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

Well, it's not *quite* that simple. What do you do about multiple A records
pointing to the same address? You need some sort of convention and/or heuristic
for determining how the PTRs should look in that case. And what do you do when a
/24 is shared by devices belonging to different "peer" organizations, maybe even
different corporations? If you try to adapt RFC 2317 to such a situation, it can
be a political nightmare trying to determine who is "master" of the /24, not to
mention all of the ongoing co-ordination required whenever anything changes.

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

Actually, that's one of the reasons why I think we should get rid of the
reverse-DNS cruft before the IPv6 freight train pulls into the station. Out with
the old, in with the new. Let's prevent information overload.

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

We're already using IPSEC (gateway-to-gateway) over the ANX. I wasn't aware that
PTR records were implicated. Certainly no-one has approached me about maintaining
PTR records for our ANX presence. But if I remember, I'll ask our ANX firewall
guy about it...


- Kevin