Subject: Re: [dnsop] misread the cutoff date/time...

From: Daniel Senie <[email-masked]>
Date: Sun, 20 Feb 2005 11:31:19 -0500

At 10:56 AM 10/30/2004, Pekka Savola wrote:
>On Mon, 25 Oct 2004, Daniel Senie wrote:
>>Well, I had put 5PM today in my calendar as the cutoff, and got the 
>>submission for draft-ietf-dnsop-inaddr-required in at about 10AM :(
>>
>>The version I was trying to submit is viewable online at:
>>
>>http://www.senie.com/dan/draft-ietf-dnsop-inaddr-required.txt
>>
>>I guess folks can read this and discuss at the meeting, and I'll push 
>>this version into the process once the queue opens up again.
>
>Comments below.  In short, I think there are still a couple of too strong 
>requirements which should have been removed, but I think a document like 
>this will be useful.
>
>Details below.
>
>...
>
>
>The Domain Name Service has provision for providing mapping of IP
>addresses to host names. It is common practice to ensure both name to
>address, and address to name mappings are provided for networks. This
>practice, while documented, has never been documented as a requirement
>placed upon those who control address blocks. This document fills this
>gap.
>
>
>==> 'requirement' ?  This should have been updated... The same here and 
>further
>along in the section:
>
>4.1 Delegation Recommendations
>
>Regional Registries and any Local Registries to whom they delegate
>should establish and convey a policy to those to whom they delegate
>blocks that IN-ADDR mappings are required.  Policies should require
>those receiving delegations to provide IN-ADDR service and/or delegate
>to downstream customers.

Some rewording has been undertaken to address these concerns.

>.........
>
>
>Web sites are in some cases using IN-ADDR checks to verify whether the
>client is located within a certain geopolitical entity. This is being
>employed for downloads of crypto software, for example, where export of
>that software is prohibited to some locales.
>
>==> are these for real?  If they would be serious about these checks, 
>they'd just check the IP address against the RIR allocations and possibly 
>the RIR->LIR allocations, because DNS operators cannot be trusted to deal 
>with this properly.  And what of '.com', '.net' or whatever?  Those could 
>reside in the restricted areas as well.

The comments are mostly out of scope. While certainly there are other 
mechanisms some sites use, and while on the surface they might seem better, 
they are unrelated to INADDR. There are commercial enterprises which 
attempt to sell services claiming to provide a country code in response to 
a lookup of an IP address. These of course fail to provide proper 
information for tunnelled networks, new allocations, and the like. The text 
suggests web sites should avoid use of the PTR record data for such 
lookups, and that remains valid.

>The popular TCP Wrappers program found on most Unix and Linux systems
>has options to enforce IN-ADDR checks and to reject any client that does
>not resolve.
>
>==> maybe it could be further said here that if the hostnames or domains
>(instead of IP addresses; using hostnames is a good idea) are used in tcp
>wrappers, the reverse+forward lookups obviously have to exist and match.

Many systems have more than one host name with A records pointing at a 
single IP address. The PTR record will match at most one of them. 
reverse+forward lookups are NOT, in my opinion, a valid security mechanism. 
At most you can tell someone has access to both the forward and reverse DNS 
zones. I adjusted the text a little bit, but not to encourage the use of 
reverse+forward as a security measure.

>Many web servers look up the IN-ADDR of visitors to be used in log
>analysis.  This adds to the server load, but in the case of IN-ADDR
>unavailability, it can lead to delayed responses for users.
>
>==> do the web servers also perform the forward mapping?  Note that most
>*external* log analysers only do the reverse mapping.

It would depend on the application, and how important the data is. The 
document is saying the data in the reverse mapping is not sufficient for 
security. That's the point.

For web statistics gathering, the question is whether there's sufficient 
harm done by someone spoofing the data. That's a matter for the person 
implementing the statistics gathering and those consuming the data. I can 
say that for sites we host for companies, the issue is not important, and 
that the additional costs to try and do something more detailed are not 
worthwhile. For some applications, that may not be sufficient. Your mileage 
may vary. I don't think it's something that needs more text in the document.

>Applications SHOULD NOT rely on IN-ADDR for proper operation. The use of
>IN-ADDR, sometimes in conjunction with a lookup of the name resulting
>from the PTR record provides no real security, can lead to erroneous
>results and generally just increases load on DNS servers. Further, in
>cases where address block holders fail to properly configure IN-ADDR,
>users of those blocks are penalized.
>
>==> you'll need to be careful to be specific when you are talking about
>reverse+forward checking, or just reverse lookup.  This was brought up
>in IESG evaluation by Thomas Narten on 
>draft-ietf-dnsop-ipv6-dns-issues-10.txt,
>so you might want to check how I resolved that particular terminology issue.

I stand by the text. If you need security, then do something that's secure. 
Verifying access to both forward and reverse zones is not security.

>    By recommending applications avoid using IN-ADDR as a security
>    mechanism this document points out that this practice, despite its
>    use by many applications, is an ineffective form of security.
>    Applications should use better mechanisms of authentication.
>
>
>==> this could probably be beefed up better, see e.g.
>draft-ietf-dnsop-ipv6-dns-issues-10.txt.  In particular, IMHO it should be 
>noted that:
>  1) simple reverse lookup offers no security at all
>  2) reverse+forward check is not a true form of security, but could be useful
>combined with other forms of checking

reverse+forward checks is NOT security. You're verifying that someone has 
access to zone files, nothing more. So if the DNS servers (forward and 
reverse) for a CIDR block are within that block, and the block is hijacked 
(this is happening), then the hijacker can make you believe he's who you 
think he is, and all the DNS checks for reverse+forward verify it. Use a 
security mechanism if you want security. I don't agree there's any place 
for advocating reverse+forward in this document.

>editorial
>---------
>
>==> some sections are indented, some others are not.  I'd suggest
>converting to using a good tool such as xml2rfc to get this right.
>Proper indenting helps a lot for readability.

I gave up on xml2rfc after wasting much time trying to get it to work on my 
systems. It seemed to make no sense to spend more time on it for a document 
I'm trying to put to bed. I fixed the indent issues in about 2 minutes in 
NROFF.

>==> a placeholder IANA considerations section needs to be added,
>saying that there are no IANA considerations.

done.

>                Encouraging the use of DNS IN-ADDR Mapping
>
>==> s/IN-ADDR/Reverse/ (because this covers v6 as well)
>There are also numerous similar occurrences throughout the document,
>and these should be likewise replaced.

I disagree. As for covering v6, I adjusted the introductory text a bit more 
that covers this issue. The document uses IPv4 terminology, and the reader 
can and should apply it to IPv6 by understanding the issue.

>The assignment of blocks of IP Address space was delegated to three
>
>==> s/Address/address/

done.

>4. Requirements
>
>==> rename to 'Requirements and Recommendations' or just Recommendations.

done.

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2005 09:49:09 +0200 (EET)

Hi,

I think the document is roughly in relatively good shape, though I 
still have one issue.. inline.

On Sun, 20 Feb 2005, Daniel Senie wrote:
> security mechanism if you want security. I don't agree there's any place for 
> advocating reverse+forward in this document.

But yet, it _is_ a form of security.

For example, lots of people have tcp wrappers configuration in their 
SSHD, requiring that connection attempts come from host.example.com, 
.example.net or whatever (forward+reverse check).  This is especially 
useful when the server is at example.net, but has a couple of pinholes 
to the world.

In addition to that, there is a public key security or password 
authentication.

That kind of additional check _does_ increase the overall security of 
the system significantly (if you compare to a situation where you 
would not have any tcp wrappers checks).  So, I think the document is 
disconnected from the reality in its attempt to please the most 
stringent security communities.

The key point is that forward+reverse DNS check is not a sufficient 
security mechanism on its own, but almost always needs something more 
-- and that folks which use it need to understand its weaknesses in 
designing the additional security measures.

> I'm trying to put to bed. I fixed the indent issues in about 2 minutes in 

Luckily enough, you don't need to get it to work on your systems; I 
haven't even tried myself.  You can just edit the xml file and use the 
web interface at http://xml.resource.org.

> can and should apply it to IPv6 by understanding the issue.

I doubt that's going to satisfy the IESG, so I think this issue will 
come and bite us later on.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 11:15:03 -0500 (EST)

You have missed several issues, in my opinion.  There are others, which
I've pointed out, previously, including false and misleading "quotes" of
the policies for other authorities. For example, ARIN does not 

  "require ISPs to maintain IN-ADDR for /16 or larger allocations. For
  smaller allocations, ARIN can provide IN-ADDR for /24 and shorter
  prefixes."

This is a mistatement of ARIN's policy. ARIN doesn't provide IN-ADDR
mappings for ANYONE. ARIN does not require ANYONE to provide IN-ADDR
mapping.  ARIN only provides delegation records to those who WISH TO use
IN-ADDR. Let me say it again:  ARIN doesn't require anyone to use IN-ADDR. 
Senie's assertion otherwise is flat out wrong.

Furthermore, as I've reported here previously, I've spoken to ARIN about
this, and ARIN has been considering not offering the Delegation function.  
It has gone so far as to research the issue with its attorneys, to find
out whether it is required to provide this, and the attorneys indicated it
was not so required.

The draft also mentions the notion of "the proper deployment of in-addr".  
This notion is flawed and wrong. First, the forward+reverse check can't be
performed 100% of the time, even if one wanted.

The people clamoring for this draft assert (wrongly) that a matching
forward/reverse configuration is always possible.  It isn't. For example,
1) it is benefiicial to have reverse pointing to a preferred name for
which the forward address has a preferred address.  These don't overlap.

2) One might have a large number of forward names with the same address,
for which there is no single reverse name, and all the names are too 
large for a DNS packet (virtual web hosts)

3) An address registry may not offer reverse delegation.

4) etc.

Section 3 is a rogues gallery of bad behavior by APPLICATIONS:

   Section 3. Examples of impact of missing IN-ADDR

   These are some examples of problems that may be introduced by
   reliance on IN-ADDR.

The examples given are not "problems caused by missing IN-ADDR", but
rather ABUSE of IN-ADDR.

The DNS Operations group is to give guidance to the application writers 
NOT TO USE IN-ADDR THAT WAY.  I can't make that any clearer.

Senie's draft suggests that the "problem" is caused by a missing IN-ADDR, 
and this is wrong. 

More inline:

> > access to zone files, nothing more. 

BTW, this is not quite correct. Its really much worse than that. DNS can 
be spoofed (and cache poised) in only 65000 packets). You have _not_ 
proven access to zone files. This check proves nothing, beyond a 
poisoned cached. 

> > So if the DNS servers (forward and 

Err, no. It is a security _Vulnerability_. Its a perception of security
(as you so demonstrate) that creates an security exposure. 

This forum should not be advocating the use of a security vulnerability.

> useful when the server is at example.net, but has a couple of pinholes 

This is an example of what should _NOT_ be done. Ever. 

But you are correct that people do that. That practice needs to be 
_DISCOURAGED_, not encouraged.

> would not have any tcp wrappers checks).  

The flaw is that you assume that you cannot use tcp-wrappers checks if you 
don't have reverse.  That is not true.

> So, I think the document is 

I think the author is disconnected from reality if they think that the
document attempts to please even the most un-stringent security community.  
It is a security _HARM_.

> designing the additional security measures.

"On its own"?  Its no check at all. Period.  Its a vulnerability, not a 
check.

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 11:37:08 -0500 (EST)

ARIN's own in-addr records don't satisfy the draft:

dig www.arin.net. +short
69.25.34.199
192.149.252.16
192.149.252.17
[dean@dakota dean]$ dig -x 192.149.252.16 +short
ww1.arin.net.
www.arin.net.
arin.net.
[dean@dakota dean]$ dig -x 192.149.252.17 +short
www.arin.net.
arin.net.
ww2.arin.net.
[dean@dakota dean]$ dig -x 69.25.34.199 +short
ashburn-199.arin.net.
host-34-199.arin.net.

They don't match. Indeed, there is no forward name "ashburn-199.arin.net".

"host-34-199.arin.net." is auto-generated. If all in-addr were so
auto-generated , there would be no point in having in-addr at all.

Often this auto-generation is done by the address registrant who received
the assignment to satisfy the zealots whose FTP or mail servers reject
connections. 

In-addr is a convenience function. It is not a "security" function.  The 
existance and "matching" of in-addr has no relationship to any of the 
commonly asserted claims by the anti-spammer zealots who insist on it:

They frequently make absurd claims such as:

1) matching in-addr means that email isn't spam.

2) matching in-addr means that address space isn't hijacked.

3) matching in-addr means that one can "trust" the name is who it claims 
to be.

One and Two above are just wrong. This is obvious to all but the zealots.

Number three is also wrong, as has been graphically proven over time.  
However, it is apparently not so obvious, as it was the false assumption
that made possible the BSD r-command exploits. This exploit is still
possible with some tcp-wrappers mis-configurations advocated by people on
this list.  Number Three also made possible (from roughly 1986 to 1993)  
anonymous relay abuse, whereby one could send anonymous email by faking or
removing the in-addr name. Sendmail relied on the correctness of the
in-addr. Indeed, this fault was made by our own chair, Rob Austein who
fell for number 3 in 1986, when he argued against including the IP address
in the Sendmail Received: header, believing wrongly that in-addr was
sufficent and if it wasn't "we should fix the silly net"

Haven't we learned our lesson already?

		--Dean

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 12:45:53 -0500 (EST)

This deserves further analysis:

> In addition to that, there is a public key security or password 

The illogic of this can't be ignored.

If public key or password authentication are "in addition" to some
security, then we can consider what security is left without 'public key
or password'.  So lets do that: Well, this is exactly the bsd r-command
EXPLOIT.  No security remains.  

In-addr checks are not security: They are not "a form of", not "a little
bit"; But none at all. They are worse than none at all even: it is an
EXPLOIT, a vulnerability, a weakness.

Absolutely, one should never, ever depend on or use in-addr as security in
their tcp-wrappers or system security configuration. That includes
logging.  Putting it in logs is not necessarilly harmful, but relying on
it is harmful.  Too frequently, zealots don't grasp the difference.

If one changed all non-convenience (ie traceroute) use of in-addr from a
question of "what is the name of this host?" to "should I record possible
evidence of a poisoned cache?", one might get better usage patterns from
applications.

		--Dean

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2005 19:59:58 +0200 (EET)

You have sent a number of messages on this, and it seems unproductive 
to respond.  However, I'll address this one.

First off, there are at least two ways to perform forward+reverse 
checking.  I'm not sure you can see these as separate.

  1) check that forward and reverse entries match, but don't check what 
the name actually is (this could be phrased as a "consistency check").

  2) check that foeward and reverse entries match, and the name is 
included in a list of names.

I agree that 1) appears to serve no security purpose.  However, I 
think 2) is still useful as an additional security mechanism. 
Obviously, property 2) is not needed for those hosts which won't be 
used in this kind of manner, so your argument about www.arin.net does 
not hold for 2).

Inline..

> EXPLOIT.  No security remains.

I'll assume you meant method 2) above.

I think this is an incorrect consideration.  If reverse+forward 
matching to a specific hostname was done _after_ password or public 
key authentication, this might be closer (but not quite) the truth.

However, applying a reverse+forward matching to a specific, configured 
hostname as the _first_ measure of check restricts the attackers to 
those which can control the particilar reverse and forward trees, or 
spoof the DNS in a particular way.

This is certainly very useful.  It'll prevent random script kiddies 
and port scanners (for example) from attacking a particular service.

It may not be 100% protection against the most determined crackers, 
but that's what the _additional_ protections are for.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 14:45:32 -0500 (EST)

> to respond.  However, I'll address this one.

I agree, it seems unproductive to respond.  These points have been brought 
up repeatedly in the past, and you still don't get them.  Why rehash this? 

Only you continue to posit this draft with its many inconsistencies and 
incorrect statements, and bad recommendations.

> the name actually is (this could be phrased as a "consistency check").

You check that there are two records, but you don't check them.  How is
that a consistency check?

> think 2) is still useful as an additional security mechanism. 

Your number 1 above makes no sense to me at all. I hadn't considered it.

> used in this kind of manner, so your argument about www.arin.net does 

www.arin.net is merely a high profile example where a check such as your
2) fails.

> key authentication, this might be closer (but not quite) the truth.

You didn't read my message. To find out what security was present before 
'the addition' of either public key or password authentication, we 
consider the security without them.

> spoof the DNS in a particular way.

No, it provides NO RESTRICTION WHATSOEVER.

> and port scanners (for example) from attacking a particular service.

Only in your dreams.

> but that's what the _additional_ protections are for.

Its 0% protection. Spoofing DNS is well within the reach of every script 
kiddie.

		--Dean

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 15:08:55 -0500 (EST)

> but that's what the _additional_ protections are for.

As this concept was rather spectacularly shown to be false on a number of
occasions involving attackers' spoofing of bsd r-commands, is it safe to
assume that there is general consensus that the concept of DNS-based
security has no merit, and needs not be discussed?

The notion of r-command security seems to me to serve to discredit the
contents of this draft. I cannot believe we are actually debating the view
that the bsd r-commands security, that is, the in-addr based "security"  
assumption, is actually a good idea.

		--Dean

.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Feb 2005 22:15:44 +0200 (EET)

On Tue, 22 Feb 2005, Dean Anderson wrote:
> Only you continue to posit this draft [...]

An interesting view.  In contrary -- I think only you are one strongly 
opposed to this draft.

> that a consistency check?

For example an SMTP might check that the SMTP session that initiated 
from IP address 1.2.3.4 would have the reverse for 1.2.3.4 point to a 
name, which refers back to the PTR record.  The system, however, would 
not have white or blacklisted hosts or IP address which to check 
against -- this would be applied to all connections, with intention, 
"we don't want to allow sessions from anyone whose reverse and forward 
DNS entries aren't consistent, though we don't actually care at all 
what those DNS entries are as long as they are equivalent".

This might be more or less misguided "hijacked IP address" consistency 
check (where the assumption would be that those "hijacking" addresses 
might not be able to get a reverse delegation -- which may or may not 
be false).

I will not bother responding to the rest as it doesn't seem 
constructive, except in your later post:

>contents of this draft. I cannot believe we are actually debating the 
>view that the bsd r-commands security, that is, the in-addr based 
>"security" assumption, is actually a good idea.

You are deliberately trying to confuse this issue, or just don't get 
it.

The r-command security was based on DNS, yes.  But that was ALL. 
There was _no_ additional security at all.

Here, we have setups which are very secure already in itself (e.g., 
SSH with a public key), but the administrator just wants to get 
additional security by cutting out 99.99% of attacks before they hit 
the servers' port 22 -- port scans, typical script kiddie attacks, 
etc.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 16:49:21 -0500 (EST)

I would very much like to hear the authors address their mis-statements of 
Registries' policies. I've brought this up against every draft so far, and 
it is still not addressed.

   ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
   allocations.

ARIN's policy says just the opposite. Contrary to the draft, ARIN's policy
is more about what it won't do: ARIN says it won't provide DELEGATION for
blocks of /16 or larger beyond the first or second octet boundary. It will
not provide DELEGATION for blocks smaller than /24. In other words, ARIN
won't do RFC2317 delegation.  ARIN will remove delegations to lame
servers. If you don't have servers to perform IN-ADDR, ARIN is not going
to waste the delegation traffic.  ARIN wants as little to do with IN-ADDR
as possible. As does, it seems, APNIC.

Also, the [ARIN] reference link in the draft is incorrect.
ARIN's policy is now at http://www.arin.net/policy/index.html#seven1 
I didn't check the links provided for APNIC and RIPE policies.

Indeed, no registry requires an ISP to provide IN-ADDR mappings for its
assigned address space.  The statements in the draft are intentionally
misleading.  The policies simply put the responsibility for maintenance on
the recipient of the allocation (usually ISPs) The Registries won't do it. 
That is a lot different from what the draft claims.

The following is a quote from the most current draft, and shows their 
false assertions about requirements for IN-ADDR:

   As we can see, the regional registries have their own policies for
   recommendations and/or requirements for IN-ADDR maintenance. It
   should be noted, however, that many address blocks were allocated
   before the creation of the regional registries, and thus it is
   unclear whether any of the policies of the registries are binding on
   those who hold blocks from that era.

Its hard to read this in any way except with respect to IN-ADDR MAPPING.  
It makes no sense with respect to IN-ADDR Delegation.  Those who held
blocks before the creation of the registration have delegation in the same
in-addr.arpa as everyone else.  The recipient has no control of the
in-addr.arpa zone. Only the registries control delegations. It makes no
sense to think of the policy of registries' delegation binding the
recipient. That isn't possible.  It could be possible to 'bind' recipients
to provide MAPPING. But that isn't the case.

The sentence about address blocks allocated before the creation of the
regional registries claims wrongly that it is 'unclear whether policies
are binding on blocks from that era'. Implicitly assuming as though
IN-ADDR policy might be less binding on some blocks.  There is no binding
requirement for providing IN-ADDR on any block.   Indeed, there is no 
binding requirement on the registries to delegate in-addr.

As an administrator of a block from 'that era', I know a little bit about
how those blocks are handled. There are a few grandfathered provisions.  
In-addr isn't one of them.  All blocks from all era's are subject to
exactly the same in-addr policies of their respective registry.  All
blocks are allocated from _some_ registry, whether they were originally
allocated from SRI/DARPA, or not. A new registry was designated for old
blocks.  ARIN provides delegation records for all blocks in its allocation
as described by its policies.  As does RIPE, as does APNIC.  There is no
difference in policy or performance. In-addr performs the same whether a
block was alloated in 1988 or 2005.  However, the paragraph makes it seem
like somehow the Registries' policies refer to MAPPING instead of
DELEGATION, and that is clearly wrong.

As has been said many times by now, No registry requires anyone or any
block to provide in-addr mappings. No registry that I know of provides
in-addr mapping for anyone but themselves.

The draft seems to be a scheme to convince the registries to change their
policy by misleading the IETF that this policy already exists.  As well as
justify the continued abuse of IN-ADDR by applications developers and
system administrators.

Coincidentally, on Feb 11th, I asked the maintainer of the ADNS resolver
to remove code from the adnshost program that prevents it from reporting
the in-addr data for any query it decides is not "consistent", according
to Pekka's definition of "consistent".  The -x option of the adnshost
program (similar to the -x option in dig), is supposed to report the
in-addr record for the IP address provided. Dig correctly reports the
in-addr record. The adnshost program does not.  This has little to do with
our discussion, except to demonstrate the kind of abuse of in-addr that
goes on.  Approval of this draft would only encourage more such abuse. 
Instead, the DNS Operations Working Group should make clear that the 
operation of programs such as adnshost are incorrect, or at least 
discouraged.

   5. Security Considerations

   This document has no negative impact on security. While it could be
   argued that lack of PTR record capabilities provides a degree of
   anonymity, this is really not valid. Trace routes, whois lookups and
   other sources will still provide methods for discovering identity.

I don't know where to start on this. The concept of DNS-based security
certainly has a long history of spectacularly negative impact on security.  
This statement just seems to deny history. The reason for abuse of in-addr
by applications is the mis-placed trust in in-addr shown by Pekka, despite
all the lip-service given in the draft.

Specifically, though, the notion of anonymity by lack of PTR record is a
valid concept held by many, despite the cavalier dismissal of it in the
draft.  Traceroute uses in-addr, (except in IPV6, where it uses HostInfo,
in-addr is presently broken in IPV6)  and whois does not give you
hostnames. It is not clear what "other methods" exist to discover the
hostname of an arbitrary IP address, without in-addr.  If in-addr is
replaced with generic, autogenerated names the ISP, then there is no point
in having in-addr, since in that case it merely spends a lot of time and
packets, and diskspace doing what can be done by a single whois lookup.

		--Dean

.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 22 Feb 2005 17:30:39 -0500 (EST)

> what those DNS entries are as long as they are equivalent".

The above has been discredited as an anti-spam measure, with all but
certain small number of zealots.  There are large blocks of space for
which IN-ADDR is not available in africa and elsewhere. There are many
examples where it is possible, but not done.  Here is a recent example:

==============================================================
From: Pat <[email-masked]>
To: [email-masked]
Subject: no reverse delegation policy

I recently switched connectivity providers (to save some $$$) and come to
find out they don't want to delegate reverse ip resolution to my name
servers.   
==============================================================

Apparently, you don't have to exchange mail with all of the world. Or
perhaps you just want to require everyone to do IN-ADDR so complaints such
as the one above don't happen, and so that your wrong assertions about
SMTP in-addr checking don't dump so much genuine mail, which spammers
using stolen residential systems send tons of junk because the residential
ISPs are quite happy with the auto-generated IN-ADDR.

Rather than admit to being wrong about the validity of the IN-ADDR check, 
just change the world to make it less obviously wrong.

> You are deliberately trying to confuse this issue, or just don't get 

Err, no. I think its you who doesn't get it.  I'm perhaps foolish to be 
arguing with you about it.

> There was _no_ additional security at all.

Exactly.  Not only was there no _additional_ security in the r-commands,
there was _NO_ security, as a result. In other words, an exploit. I refer
you back to your original message:

> In addition to that, there is a public key security or password

There is no security to be in addition to: Take out the "addition" of
public key and password and there is nothing left.  There being nothing
left, there is no security in DNS checks, refuting your claim that it is a
form of security.

> the servers' port 22 -- port scans, typical script kiddie attacks, 

There is no additional security. No real attacks are cut out. Only your
naive scans are cut out. Worse, additional real attacks are created: Bad
guys know you configure your firewalls using DNS information. So, a bad
guy can penetrate your security by spoofing DNS. It may be as simple as
getting your firewall to reboot, and getting it to treat his bad IP as a
trusted server.  Meanwhile, you falsely conclude no one can penetrate your
naive "security", because you used tcp-wrappers, or whatever.

I guess you haven't read the draft where it says that.  I'd say my point
about giving lip-service in the draft to DNS non-security but ignoring
that in practice, is pretty much at the
driven-home-through-concrete-losing-points-to-overkill stage.

		--Dean

.