Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt

From: Rob Austein <[email-masked]>
Date: Wed, 02 Apr 2003 17:32:12 -0500

So far we've heard from:

- Ray, who pointed out some RIR-related (specifically, ARIN-related)
  text that needs some work;

- Måns, who liked the draft and suggested adding text discussing IPv6;

- Dean, who says that we should not be working on this draft.

Does anybody -else- have comments on this draft?  In particular: does
anybody who has not yet spoken on this have an opinion on whether the
WG should be working on this?

Note to anyone who has not figured this out yet: the title of the
draft is old, does not match the content of the draft as it evolved,
and most likely would be changed before publication to match the
current content of the draft.  Please READ THE DRAFT rather than
jumping to conclusions about what it says based on the title.

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Ray Plzak" <[email-masked]>
Date: Wed, 2 Apr 2003 17:55:49 -0500

If the purpose of this draft is to propose policy, then it should not be
an item for the WG, but should be put into the RIR policy process.  If
the purpose of the draft is to define real technical reasons why in-addr
are required then the work should proceed and be judged on that merit.

Ray

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Rob Austein
> Sent: Wednesday, April 02, 2003 5:32 PM
> To: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
> 
> 
> So far we've heard from:
>

---

From: Randy Bush <[email-masked]>
Date: Wed, 2 Apr 2003 15:36:25 -0800

> an item for the WG, but should be put into the RIR policy process.

the document seems to suggest policy for both isps and for rirs.  do the
rirs see themselves as the venue to set *isps'* policies?  maybe we can
learn to share the blame <g>.

randy

---

From: Daniel Senie <[email-masked]>
Date: Wed, 02 Apr 2003 18:43:07 -0500

>an item for the WG, but should be put into the RIR policy process.

That is not the purpose. I would be happy to separately work with the RIRs 
on policy proposals.

>   If

It is the purpose of this draft to define the reasons to promote the use of 
INADDR, and to also discourage usage that can be harmful and which provides 
false security (please note that most or all of the text regarding NOT 
using INADDR came from contributions from the DNSOP WG at or shortly after 
the Pittsburgh IETF, and were not in the original document).

As Rob mentioned the tone and direction of this document has changed from 
the original I-D which I wrote some years back. The changes were largely 
brought about by input from the WG in the past. Echoing Rob, I encourage 
folks to read beyond the title line and evaluate the content. I am planning 
to replace "Require" with "Encourage" in the title of the document in the 
next revision, though the file naming will likely continue to have the word 
"required" in it.

---

From: Dean Anderson <[email-masked]>
Date: Wed, 2 Apr 2003 19:00:07 -0500 (EST)

I have specific comments:

According to RFC 2026, "Best Current Practices" are meant to express
community consensus on operational aspects. This draft modifies RFC 1034,
and RFC 1035, and it changes the requirements for nameserver software.
Also, a Best Current Practice RFC shouldn't affect how software
applications are written, only how they are operated.

Therefore this draft isn't suitable for the abbreviated BCP process.

Section 1

Paragraph 1 This section is clearly wrong. It says "This practice, while
documented, has never been documented as a requirement placed upon those
who control address blocks".  This is false. It suggests an omission,
where there is no omission. It has been documented as being optional in
various RFCs and in the policies of address registries.

Section 2

Should either be amended to remove specific reference to ARIN,
or be complete with respect to all registries.

Section 3

This entire section should be deleted:

It is flatly incorrect in some places:  "To ensure validity of claimed
names, some applications will look up IN-ADDR records..." and goes on to
describe the forward-reverse-foward procedure.  One cannot ensure validity
of names through this procedure, and so this is a false premise.  RFC's
should not promote clearly false claims.

There rest of this section just documents examples where this false
premise has been used.  That some persons accept these false premises does
not make the premise true. These practices are not followed by the vast
majority of servers of any type, nor by the vast majority of operators of
servers, though there are isolated contrary examples.

Section 4

The first paragraph is good. (Basically, this paragraph just repeats my
criticism of section 3.) However, including such statements does not
negate or remove the false premises that are contained elsewhere in the
document.

The second paragraph is erroneous. There are valid reasons where it is
appropriate or convenient for PTR records which are not the canonical
name. For example, this contradicts RFC 2317, which puts CNAMES in PTR
records.

The third paragraph should be deleted. It violates the security policies
of many organizations to identify the broadcast addresses of their
networks. Such addresses could be identifed by the lack of IN-ADDR.
Further, many organizations find it completely unacceptable that anyone
should be auditing its compliance with this RFC, or attempting to
determine its internal structure.  Such activity is a violation of federal
criminal statutes, and should not be encouraged by the IETF.

As was already pointed out, paragraph 4 should be removed. Each registry
has its own policy process.

Paragraph 5 should be removed, as it contradicts common practice at many
ISPs which implement automated reverse/forward trees of the form generally
like 'h-<octet1>-<octet2>-<octet3>-<octet4>.somedomain', where the trees
are not actually stored, but are simply made up on the fly in response to
queries. This places limitations on nameserver implementations, and
modifies RFC 1035.

Section 5

Encouraging the use of IN-ADDR has demonstrably negative effects on
security.  Several examples have been given where root and user access has
been granted, untraceable email has been granted, and logs have been made
useless.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 3 Apr 2003 03:52:43 +0200

>  WG should be working on this?

	I can make some comments on the draft regarding what I believe to 
be typos and incorrect grammar.  Is that what you're looking for, or 
do you want more substantive discussion?

>  jumping to conclusions about what it says based on the title.

	Well, I would have thought that my views on this subject were 
pretty well known.  I guess my question has to be -- what is the real 
purpose of this draft?

	Is the purpose to identify the current actual policies (once 
corrected) of the RIRs and mention the issues that have been raised 
here, perhaps to bring them to a wider audience?

	If so, then I think this draft is definitely something we should 
be working on, but we should make an effort to pull out some of the 
more emotionally charged language that has been used in the past, and 
to make it relatively neutral and simply state the facts.  We then 
collect the feedback, and see if we can get some consensus that would 
allow us to lay out a BCP.

	If the purpose is to propose policy changes, then I'm not sure 
that this is the right group to handle this topic.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: "Ray Plzak" <[email-masked]>
Date: Wed, 2 Apr 2003 22:11:23 -0500

Policies are applied to the ISPs to whom the address space is allocated
or assigned by the RIR.  If an upstream further assigns to a downstream,
they generally apply the policy of the RIR to that space as in the end
it will affect the relationship of the upstream to the RIR when
requesting additional space.   An example would be the reporting of
utilization.  In some cases there are policies that affect operations,
such as those pertaining to multihoming which are also generally passed
down by the upstream.  On the other hand there is no policy in regards
to setting filters with regard to the space allocated as this is the
purview of the operator as it is independent of the amount of space that
has been allocated by an RIR to an ISP and pertains to routing which is
not the purview of the RIR.  Hope this helps.

Ray  

> From: Randy Bush [mailto:[email-masked]] 
> Sent: Wednesday, April 02, 2003 6:36 PM
> To: Ray Plzak
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt
> 
>

---

From: "Ray Plzak" <[email-masked]>
Date: Wed, 2 Apr 2003 22:14:20 -0500

Daniel,

The ARIN Advisory Council and the ARIN staff will be glad to work with
you to facilitate your activity in the policy process.  Please contact
me off list if you wish to pursue a policy proposal.

Ray

> Behalf Of Daniel Senie
> Sent: Wednesday, April 02, 2003 6:43 PM
> To: [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Thu, 03 Apr 2003 09:45:39 +0200

> WG should be working on this?

With the promised changes in wording and trying to avoid the ``policy''
debate I am in favor of re-opening this issue and again accept this
draft as a work item for the WG.

Despite its potential abuses (we don't ban http, do we?) I believe reverse
mapping is a valuable resource. In addition, since we're unlikely to succeed
in changing the installed base, the factors DNS server load and latency,
as mentioned in the draft, suggest to "do something" about it.
Anyone operating a nameserver covering a larger amount of /16s down to the
leaves should have a look at their query statistics.

Reverse mapping for IPv6 should be dealt with in a seperate document.

-Peter

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 15:24:53 +0200

> draft as a work item for the WG.

I second that.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 3 Apr 2003 20:30:34 +0300 (EEST)

> WG should be working on this?

Yes, I believe this is quite useful.  I also belive in-addr are useful,
even though sometimes used improperly. The delegation chain should be
provided alongside with address allocations [this may fall upon the RIR
policies].  Whether the endsites fill those is their policy, and this 
draft should try to list the tradeoffs for such decisions.
 
> jumping to conclusions about what it says based on the title.

There are some remnants still, e.g. in the introduction, btw.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dean Anderson <[email-masked]>
Date: Thu, 3 Apr 2003 12:56:15 -0500 (EST)

> the Pittsburgh IETF, and were not in the original document).

Then it should include a statement to the effect of:

------------
IN-ADDR should not be used for any logging, auditing, identification,
authentication, or authorization purpose.  Its sole purpose is for
the convenience of such applications as traceroute.

Application developers should be aware that IN-ADDR may not be available
in IPV6, and IPV6 applications should be prepared to use ICMP node
identification or other alternatives.
------------

---

From: Markus Stumpf <[email-masked]>
Date: Thu, 3 Apr 2003 21:28:13 +0200

> WG should be working on this?

What I am missing is some kind of requirement of usefulness of the
IN-ADDR data. We have
    Internet providers and other users to whom a block of addresses are
    delegated SHOULD provide for lookup of host names from IP addresses.

Do PTR records within the following list qualify for the above statement,
i.e. do they qualify as "host names"?
(I picked those examples from a scrolling maillog file, so the listed hosts
are picked at random and not for the purpose to offend anyone)

    unknown.level3.net				64.157.143.50
    67.106.228.14.ptr.us.xo.net			67.106.228.14
    200-170-198-6.core01.spo.ifx.net.br		200.170.198.6
    0x50a2eb04.unknown.tele.dk			80.162.235.4

If these are considered to be valid "host names" it would IMHO be nice
if the, obviously generated, names mapping the IP address would also
carry some CIDR information. A naming scheme like in RFC 2317 could be
used:

Suppose you have two /25 for two different customers (no delegation)
   10.0.1.0/25		10.0.1.128/25
then the scheme could be (as with the above used hosts)

    10.0.1.0/25.0.rev.example.net.
    10.0.1.0/25.1.rev.example.net.
    10.0.1.0/25.2.rev.example.net.
    [ ... ]
    10.0.1.0/25.127.rev.example.net.

    10.0.1.128/25.128.rev.example.net.
    10.0.1.128/25.129.rev.example.net.
    [ ... ]
    10.0.1.128/25.255.rev.example.net.

This would help especially in cases where no assignment information
beyond /16 is available from the RIR databases to block out abusive
hosts/nets without risking collateral damage.

IMHO recommending this would be nice, but maybe this is beyond the
objective of that draft.

	\Maex

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 04 Apr 2003 13:36:27 +0900

>>>>> On Wed, 02 Apr 2003 17:32:12 -0500, 
>>>>> Rob Austein <[email-masked]> said:

> - Mxxs, who liked the draft and suggested adding text discussing IPv6;

('xx' seemed to be non-ascii characters)

> WG should be working on this?

Though I've mentioned this draft in a separate thread, I think I can
present my opinion since I'm not listed above.

I believe the wg should work on this, and I basically support the
intention of the draft.

The draft, however, will need several clarifications.

As already pointed out, the title (and the filename) does not reflect
the content well and will thus need to be revised.  Abstract and
introduction may also need a revise from this point of view.

Secondly, if I don't misunderstand the intention, the draft says two
things:

1. we need to try to build correct reverse mapping as much as
   possible.
2. applications should not rely on reverse mapping for several
   purposes as they currently do.  The discouraged purposes include:
   - rejecting ftp/telnet connections just due to the lack of reverse
     mapping or failure of reverse-forward-reverse match.
   - filtering rule in TCP wrappers due to the lack of reverse mapping
   - regarding e-mail messages as spam if the sender address does not
     have a reverse mapping

I don't much care about bullet 1, but I think bullet 2 needs some
clarification.

First, I'd like to confirm if my understanding above is correct.  The
draft basically just says:

   Applications SHOULD NOT rely on IN-ADDR for proper operation.

But it is not very clear what the "proper operation" means.  I picked
up the examples of the discouraged usage from Section 3 based on my
understanding of the draft.  If I read it correctly, however, then I'd
wonder why people who seemed to want rely on such a usage
(e.g. rejecting ftp connections) are supporting the draft.

Also, I'm not sure if all the examples in Section 3 are discouraged
based on the intention of the draft, which include:

  - (to try) logging the result of reverse lookup of a web client in a
    web server
  - reverse lookup in traceroute

Finally, Section 4 needs to be clearer.  The draft says

   The use
   of IN-ADDR, sometimes in conjunction with a lookup of the name
   resulting from the PTR record provides no real security, ...
                                          ^^^^^^^^^^^^^^^^

but, as already pointed out in this list, "security" is a broad term.
I believe the draft should be clear on what kind of "security" it is
talking about.

In summary, I'd like the draft

- to clarify the first paragraph of Section 4, and
- to add a concrete list of discouraged usage in Section 4

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 4 Apr 2003 09:57:49 +0200

At 1:36 PM +0900 2003/04/04, JINMEI Tatuya / 

>  ('xx' seemed to be non-ascii characters)

	I believe it was "Mans", where the "a" character had a circle 
above it.  I'm not sure what this character is called.

>     Applications SHOULD NOT rely on IN-ADDR for proper operation.

	Correct.

>  But it is not very clear what the "proper operation" means.

	"Proper operation" should also include any security-related functions.

>                                                               I picked

	It's a matter of what is done by the programmer (assuming some 
sort of "proper operation" based on rDNS), versus what may be done by 
the administrator/operator (choosing to configure their machines in a 
particular way so as to require correct rDNS before they allow you to 
proceed).

	We want to discourage programmers from depending on something 
like this, while allowing owners/operators/administrators to choose 
to configure their machines in whatever way they feel is appropriate.

	This also means that software & OS vendors should not install 
their software in such a fashion that it depends on rDNS for "proper 
operation", as a default.  Most users will simply take whatever 
default they are given, without understanding the underlying 
assumptions that might not be appropriate for their situation.

	So, if someone wants to configure their machine to require 
correct rDNS before they will allow you to proceed, they should be 
able to do that.

	However, they shouldn't be forced to do that by the programmers 
who wrote the software, nor should the software be configured so as 
to do that by default.

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 4 Apr 2003 13:17:23 +0200

>     0x50a2eb04.unknown.tele.dk			80.162.235.4

They do convey something -- the operator has taken care of them,
perhaps only by $GENERATE, but still, and it has not been delegated
further, for whatever reason. I find this partially useful in
assessment och "credibility". That it is served is essentially the
most important part, (because of problems associated with unreachable
servers et al.) but there is also value in these autgenerated labels.
 
> carry some CIDR information. A naming scheme like in RFC 2317 could be
<snip> 
> IMHO recommending this would be nice, but maybe this is beyond the

Agree. 
-- 
Måns Nilsson         Systems Specialist
+46 70 681 7204         KTHNOC
                        MN1334-RIPE

The PILLSBURY DOUGHBOY is CRYING for an END to BURT REYNOLDS movies!!

---

From: Edward Lewis <[email-masked]>
Date: Fri, 4 Apr 2003 13:21:57 -0500

>WG should be working on this?

On whether the group should spend time on this, my answer is ... it depends.

If the document is intended to document the current environment 
surrounding the .arpa and/or more specifically, .in-addr.arpa, it 
will be useful.  Documenting the current state of affairs, the 
policies of the IRR's regarding delegations, and making informed 
statements on the relationship of the .(in-addr.)arpa and the 
application layer is a good thing.  Perhaps by clearly identifying 
the issues, the contents of .(in-addr.)arpa and the use thereof, will 
be cleaned up.

If, on the other hand, the document is going to try and specify 
policies for the use of the space, it will have a tough time 
proceeding.  I am not referring to an impact on IRR policy (as an 
employee of one, I have no say in that regard), but rather the 
general issue of the IETF having no enforcement arm.

E.g., let's assume that there's a "People with computers MUST 
populate the reverse tree" and I don't.  Who's going to come after 
me?  How is my failure to meet that MUST going to impact the rest of 
the network (where's the interoperability)?

I'd recommend only working on the document if the tone is of a report 
on the current state of affairs and not that of a mission statement 
to fix the ills of a broken reverse map.  The former is useful and 
closure can be reached, the latter a rat hole without bottom.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 4 Apr 2003 21:34:44 +0200

> the network (where's the interoperability)?

Maybe after a while it will be hurting you more than the rest of the
net. Not so many years ago a lot of public information servers (e.g.
FTP, gopher, http) sent you away if your RR didn't work. Some even had
paranoid settings enabled to that forward and reverse had to match.

With the rapid growth of the net these policies were removed more and
more because the RR zones were more and more broken. Bill Manning did
nice reports and I think we're by far on the "broken side" already.

If due to the draft/rfc people will start populating and repairing the
reverse tree those policies may come back and people not caring about
the reverse tree may lock themselves out.

It's often that a recommendation that has kinda official character can
change a lot, because people have something to point at while arguing
with other people.
   Off Topic: We had a lot of problems with mailservers and discussions
   with admins in the past because of "stray newlines". RFC 821 was a
   bit unclear about that. Now we have RFC 2821 and it /explicitly/ states
   that stray newlines are not allowed. Now, if an admin complains that he
   cannot send mail, I point at the document and they go away and install
   their patches/updates. Problem solved :-)

	\Maex

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 16:01:37 -0500 (EST)

> paranoid settings enabled to that forward and reverse had to match.

I have yet to see this capability in most FTP, gopher, or http server
software.  Without the capability, it can't even be configured. While the
capability could exist in some software somewhere, I have yet to
experience or get a complaint of an FTP, gopher, or http server refusing
connection for this reason. The only service that I have ever seen use
this to refuse connections was SMTP, and there are very few doing that.
Most didn't do it for long.

I think what has happened is that there is a small contingent pushing for
reverse, and there is a much larger contingent that doesn't do reverse,
perhaps just to spite the smaller group, or perhaps because it is
inconvenient, or in other cases (I have some) where multihomed mailservers
have different forward and reverse names, so the while there are in-addr
records, they don't match as the small contingent thinks they ought.  Of
course, the records still serve a convenience function for my purposes.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 16:50:57 -0500 (EST)

I think you are misunderstanding the draft.

> I believe the wg should work on this, and I basically support the

I think it could be turned into a useful report on how to use in-addr, and
how not to use it.  It will take some editing, though.

> 1. we need to try to build correct reverse mapping as much as

This sounds benign, and even laudable on the surface. However, as you
point out, the definition of "correct" is vague. The people who want to
use reverse as tool to identify spammers, and drop connections have a
particular notion of what "correct" is. That notion requires a "1-to-1 and
onto mapping" between forward and reverse. In other words, "correct" means
that every domain name must map to an IP address. The PTR record for that
IP must map back to that domain name.

This is exceedingly simplistic view of the network. For example:

(This is a made up example, but we do use this method) custrelay1.av8.net
has several IP addresses 130.105.0.1, 130.105.0.2).  This is so that one
IP address can be used for outbound connections, and the second can be
used for inbound connections. Only customers are given the forward name.
This reduces spam attempts. However, it you look up the name,
custrelay1.av8.net, you will find only one ip address:

1.0.105.130.in-addr.arpa.  1H IN PTR  relay1.av8.net.
2.0.105.130.in-addr.arpa.  1H IN PTR  relay2.av8.net.

custrelay1.av8.net.       1H IN A         130.105.0.2
relay1.av8.net.           1H IN A         127.0.0.1
relay2.av8.net.           1H IN A         127.0.0.1

Outbound connections using 130.105.0.1 don't "match". Spammers or abusers
harvesting headers from mail messages won't get a mail relay. Incoming
connections to 130.105.0.1 get a lot of OOB data and automatic
blacklisting, because no one should be connecting on this address.  And if
the abusers get wise, we can change things around a bit, using the other
address for inbound, etc. It doesn't affect my customers in the least.
They aren't even aware of a changes.  Some people assert this is somehow
incorrect usage. However, it is correct, and becoming more and more
common.  Its tremendously effective at stopping relay abuse, and for
detecting and blocking relay scanners. (though it is odd that the people
most upset by this are the relay blacklists)

>    - regarding e-mail messages as spam if the sender address does not

This is where you misunderstand. Although it seems contradictory to some
of the other language in the draft, the proponents don't think these are
inappropriate uses.  The idea is to make everyone else change their usage
of reverse so that these kinds of uses won't deny large numbers regular,
ordinary users, as is the case now.

>    resulting from the PTR record provides no real security, ...

This is a concession to the people like me who have pointed out that there
is no security whatsoever.  It does not matter how broadly one defines
security, there is no implication that a matching forward and reverse
response indicate some kind of trust relationship between anyone,
anywhere.

> - to add a concrete list of discouraged usage in Section 4

I think if the draft were changed so that the uses listed in section 3
were really discouraged, then the proponents would find it "turned on its
head" so to speak.

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 4 Apr 2003 23:58:21 +0200

> capability could exist in some software somewhere, I have yet to

Then you should probably go and RTFM.
    tcpd(8)	tcp/ip daemon wrapper program.
    tcpserver	http://cr.yp.to/ucspi-tcp/tcpserver.html
are starting points. google will also be of help.

> I think what has happened is that there is a small contingent pushing for

I did maintain big servers at the time it happend. And nearly none of the
"big" FTP servers at that time like
    wuarchive.wustl.edu
    ftp.funet.fi
    prep.ai.mit.edu
    gatekeeper.dec.com
    [ ... ]
had let you in without proper RR DNS.
But with the dotcom rush it became lame to add RR DNS and the server
admins stopped using 

> records, they don't match as the small contingent thinks they ought.  Of

And there is no reason for it as DNS also has provisions for that case:
    $ dig -x 195.30.254.85

But this discussion is getting offtopic for this group.

	\Maex

---

From: Brad Knowles <[email-masked]>
Date: Sat, 5 Apr 2003 03:03:01 +0200

>      tcpd(8)	tcp/ip daemon wrapper program.

	As in TCP-Wrappers, by Wietse Venema?  I'll agree to that.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 21:46:10 -0500 (EST)

TCP wrappers only works on services that run out of inetd.  Most large
sites doen't run FTP, gopher, or HTTP out of inetd.

And of course, this doesn't work on Windows or VMS, or MVS. 

As someone already posted, most sites don't drop connections for this
reason anymore.

		--Dean

---

From: Doug Barton <[email-masked]>
Date: Fri, 4 Apr 2003 19:15:06 -0800 (PST)

> sites doen't run FTP, gopher, or HTTP out of inetd.

This is not correct. You can link with the tcp wrappers library for just
about any network service. Most of the FreeBSD network services are
configured this way, for example.

Doug

-- 

    If it's moving, encrypt it. If it's not moving, encrypt
        it till it moves, then encrypt it some more.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 23:09:02 -0500 (EST)

I think you are confusing tcp-wrappers with socks. No doubt that
socks-like library could be made from tcp-wrappers, but I don't think
there has been. Its kind of a mute point though, since as has been pointed
out, no one uses this functionality, and large sites don't run these
servers out of inetd.

Could such services be built? Sure.

Are they built? No.

From the tcp-wrappers readme:
===
There are two ways to use the wrapper programs:

1) The easy way: move network daemons to some other directory and fill
   the resulting holes with copies of the wrapper programs.  This
   approach involves no changes to system configuration files, so there
   is very little risk of breaking things.

2) The advanced way: leave the network daemons alone and modify the
   inetd configuration file.  For example, an entry such as:

     tftp  dgram  udp  wait  root  /usr/etc/tcpd  in.tftpd -s /tftpboot
===

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 4 Apr 2003 23:29:54 -0500 (EST)

> And there is no reason for it as DNS also has provisions for that case:

This returns a long list of PTR records, indicating which customers are on
this host. That is clearly undesirable for my case--I don't want to give
out that information. So there is a good reason for it in my example.

And frankly, your competitors will no doubt find the list of your
customers useful. Perhaps you want to rethink that long PTR list. And at
some point, it will be too big for a UDP reply.  I hadn't even thought
about that until I looked at your big list.  Then what?

There is really a lot wrong with such a proposal than first catches the
eye.

		--Dean

---

From: Pekka Savola <[email-masked]>
Date: Sat, 5 Apr 2003 09:07:42 +0300 (EEST)

Use the source Luke!

Do not have blind belief in readme's.  I've every confidence that Doug
knows how services are in FreeBSD -- you might want to have a look at
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-committers.html
-- and as it happens, I happen to use tcp-wrappers a lot with non-inetd
programs also, and a *LOT* of others do so as well.

Just to mention a very common one, OpenSSH.

---

From: Brad Knowles <[email-masked]>
Date: Sat, 5 Apr 2003 19:54:41 +0200

>  sites doen't run FTP, gopher, or HTTP out of inetd.

	Or any program that is linked with the TCP-Wrappers library, and 
most programs these days at least allow for that possibility.

---

From: Markus Stumpf <[email-masked]>
Date: Mon, 7 Apr 2003 20:11:22 +0200

> out that information. So there is a good reason for it in my example.

You mean security by obscurity?
There is a much easier way to find out all the domains hosted by us than
to ask for the PTR records of each and every IP of e.g. our /16.

> customers useful.

So what? We don't fear competitors. Most customers that went away came
back, without us having to do something. Quality sells.

> Perhaps you want to rethink that long PTR list. And at

Then we don't add other names. But this was an example that there is no
problem adding more than one PTR record, because you stated in a
previous post:
*> or in other cases (I have some) where multihomed mailservers
*> have different forward and reverse names, so the while there are in-addr
*> records, they don't match as the small contingent thinks they ought.
There is no reason why there shouldn't be more than one PTR records
if it would be crucial.

> There is really a lot wrong with such a proposal than first catches the

The only valid reason against this proposal I have seen upto now was from
Stephane. It shows operational problems that the legit "owners" of the IP
block would be unable to solve.

	\Maex

---

From: Alain Durand <[email-masked]>
Date: Mon, 07 Apr 2003 11:41:59 -0700

> WG should be working on this?

Catching up on e-mail in this wg...
I just read the draft, here are my comments:

1- This document should talk about IPv6 and suggest practices
      that are viable in both world, v4 & v6 . Sentences like:
      "Only IP addresses not presently in use within a block, or that are
        not valid for use (zeros or ones broadcast addresses) are 
permitted
        to have no mapping." have a big impact on IPv6, as the address 
space
       is so large! See draft-dnsop-ipv6-dns-issues-02.txt
      On the same line, the document should mention ip6.arpa as long as 
in-addr.arpa.

2- The rationale why the reverse tree has to be populated is weak:
      - checking reverse mapping is far from a good security mechanism
      - doing log analysis on PTR records is not very good, better 
alternative
        exists
      - export control based on PTR is, hum, questionable.

3- Several people have made the case that apps who rely on the 
existence of PTR
      are broken and should be fixed. Although I have some sympathy for
      this argument, I consider it a long term goal. In the meantime, 
there
      is an operation issue when the reverse tree is not populated 
correctly,
      and I understand it would be good to RECOMMEND to populate it.

4- Not populating the reverse tree has different effects, depending 
which part is
     not populated and who suffer the consequences.
     e.g:
    - Mail relays with no PTR exposed themselves to big problems
    - In Enterprise environment, some weak internal access control based 
on PTR
       is often deployed, failure to deploy PTR internally leads to IT 
problems
    - Home ISPs who fail to pre-populate the reverse for their customer 
could
       face high volume call on their help desk when customers can not 
access
       some FTP site that still do PTR enforcement.
    - When PTR are not populated correctly for web proxies (and 
transparent proxies)
      Web server log analyst could arrive to bogus conclusion. What is 
the point to discuss
      5% vs 7% TLD access when 30% or more of the queries do not resolve?

It is unclear to me what the current draft is trying to optimize, who 
gets the benefits
and who bares the cost.

So I would like to see this draft take another approach at the problem,
and issue more targeted recommendations with a softer language
(RECOMMEND vs SHOULD)

	- Alain.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 7 Apr 2003 16:30:05 -0400 (EDT)

> You mean security by obscurity?

No, security by password.  The forward domain name is a password for our
customers.  Of course, all security is through obsurity of the key.

> to ask for the PTR records of each and every IP of e.g. our /16.

Really? What is it?

> back, without us having to do something. Quality sells.

So, you expect everyone to give out their customer lists?  Not every ISP
shares your hubris.

> Then we don't add other names.

If you don't add them, then their reverse is broken, according to this
proposal.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 07 Apr 2003 18:13:35 -0400

>      and I understand it would be good to RECOMMEND to populate it. 

So, if I interpret you correctly, you want to pay lip service to fixing 
broken apps (that have broken for years) while at the same time removing 
a significant incentive for those apps to get fixed.

"Long-term" == "never", in many contexts, and this is one of them IMO.

                                                - Kevin

---

From: Brad Knowles <[email-masked]>
Date: Tue, 8 Apr 2003 02:13:45 +0200

At 6:13 PM -0400 2003/04/07, Kevin Darcy wrote:

>  So, if I interpret you correctly, you want to pay lip service to
>  fixing broken apps (that have broken for years) while at the same
>  time removing a significant incentive for those apps to get fixed.

	So, if I understand you correctly, we should jump right to 
breaking all applications without any intermediate step where we 
suggest that people stop depending on certain behaviour by default.

	Ready, fire, aim!

---

From: Alain Durand <[email-masked]>
Date: Mon, 07 Apr 2003 23:11:17 -0700

On Monday, April 7, 2003, at 03:13  PM, Kevin Darcy wrote:

> fixing broken apps (that have broken for years) while at the same time 
> removing a significant incentive for those apps to get fixed.

No. I recognize those apps do exist. What I'm saying is:
"If you care about them, make sure they work".
Just being pragmatic.

	- Alain.

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 8 Apr 2003 15:38:14 +0200

> > to ask for the PTR records of each and every IP of e.g. our /16.

Know your tools and ask your LIRs.

> So, you expect everyone to give out their customer lists?  Not every ISP

That's not our fault. And if you mean that it's impossible, if I want
Example Co Ltd as a customer, to find out where they have Internet
connectivity from, just because you don't add reverse records, you're
rather naive.
Oh btw. the example I made is one customer, so adding one or 100 PTR
records doesn't make much difference in matters of losing customers
and it was the explicit wish of that customer to add the records.

> If you don't add them, then their reverse is broken, according to this

1) it isn't, according to this proposal
2) the software knows about reverse resolving first, as it gets the IP
   address, looks up the PTR and validates the info by doing a forward
   lookup of the name(s) it got from the PTR.
   If it doesn't get names in the PTR it will not lookup these names.
3) if UDP buffer is too small DNS software automatically switches to TCP
   (or at least it should).

	\Maex

---

From: Kevin Darcy <[email-masked]>
Date: Tue, 08 Apr 2003 13:21:44 -0400

> suggest that people stop depending on certain behaviour by default.

It's not the job of the IETF to project-manage each organization's migration
from a standards-non-compliant piece of software to a standards-compliant one.
That's something each organization will have to work out for itself, in its own
way, in its own time.

As for "breaking all applications", it's a little naive to think that everyone
will immediately remove all of their PTR records the moment that the RFC is
published. But, I think if our long-term goal is to eliminate all software
dependencies on reverse DNS, we should at the very least make recommendations
that are consistent with that long-term goal, rather than recommendations, e.g.
"you SHOULD continue to populate reverse DNS" which are plainly incompatible
with that goal. Otherwise, we've got horses pulling the cart in opposite
directions and that doesn't exactly facilitate steady progress...

- Kevin

---

From: Dean Anderson <[email-masked]>
Date: Tue, 8 Apr 2003 19:04:35 -0400 (EDT)

> Know your tools and ask your LIRs.

Most registries won't give this information out anymore. (for the obvious
reason).  One can't easily get copies of the com or net zones (to look for
domains with certain nameservers).

> connectivity from, just because you don't add reverse records, you're

Thats the reverse of what I stated. Given a company, Of course, I can
certainly find out something about its IP addresses, for some obvious
public names, anyway.  Certain agencies host their public sites on
different connections just to hide this information.

You have done something different: This proposal maks possible an easy
answer to the question: Given an ISP, who are the customers?

> and it was the explicit wish of that customer to add the records.

I don't have too many customers ask for in-addr. I usually give it to them
if they ask, but I frequently don't setup anything that isn't convenient,
or isn't useful traceroutes.  I know of a number of very large ISPs that
refuse such requests flat out.  If you have one or more /8's, it gets to
be a lot of work to manage 16 million reverse entries. Most places don't
want to fully populate that.  Maybe that's why few or none of the big
ISP's are asking for this.

Ok, lets play along. Assuming for the moment that in-addr could be

> 1) it isn't, according to this proposal

Not every IP and domain needs forward and reverse?  Really?  I must have
misunderstood the proposal somewhere.  If you drop xcust.com from your PTR
list, then when I see a message from xcust.com in my logs, and I do a
forward/reverse/forward test on xcust.com, that test will fail.  That
violates this proposal, right?

>    If it doesn't get names in the PTR it will not lookup these names.

So if you have a thousand domains on one IP, and I have to do this test, I
have to test a thousand domains?

What happens if you have a PTR record (say ycust.com), that you haven't
removed yet, and ycust.com has changed the forward address, so that when I
test the forward (having gotten it on your list of PTRs), the test fails.
Then what?  I should keep doing the test until it succeeds?  Or should I
reject it as "not completely working according to this draft"?

> 3) if UDP buffer is too small DNS software automatically switches to TCP

Ok, but that adds a lot of overhead. Now we have to consider many more tcp
connections on servers, leading to resource starvation.

Sounds pretty complicated, for such a "simple" proposal.

I'm not convinced that even if there were trust in in-addr, that your
scheme works in common cases.

		--Dean

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 09 Apr 2003 23:34:55 +0900

>>>>> On Fri, 4 Apr 2003 16:50:57 -0500 (EST), 
>>>>> Dean Anderson <[email-masked]> said:

> I think you are misunderstanding the draft.

(snip)

> ordinary users, as is the case now.

I won't be surprised if I misunderstand the intention, and, in fact,
your understanding and mine are different.  So, I'd first like to hear
from the author about the intention.  Then we can go back to Rob's
original question.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 09 Apr 2003 23:14:59 +0900

>>>>> On Fri, 4 Apr 2003 09:57:49 +0200, 
>>>>> Brad Knowles <[email-masked]> said:

> to configure their machines in whatever way they feel is appropriate.

Okay, but I still see a subtle point.  According to your message,

- The draft wants to discourage programmers from depending on rDNS for
  "proper operation."
- The draft will still (implicitly?) allow
  owners/operators/administrators to choose depending on rDNS for
  "proper operation."

But,

  Does the draft also ***want to discourage***
  owners/operators/administrators from depending on rDNS for proper
  operation?

					JINMEI, Tatuya

---

From: Brad Knowles <[email-masked]>
Date: Thu, 10 Apr 2003 00:19:10 +0200

At 11:14 PM +0900 2003/04/09, JINMEI Tatuya / 

	Correct.

>    owners/operators/administrators to choose depending on rDNS for

	Also correct.

>    owners/operators/administrators from depending on rDNS for proper

	My view is that the draft should say something like:

		... owners/operators/administrators MAY choose to configure
		their software to make use of rDNS as an added source of
		information when deciding whether or not to provide some
		service, or the level of service to be provided.

		However, rDNS (or the lack thereof) SHOULD NOT be used as
		the only source of information when making decisions of
		this sort.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 10 Apr 2003 11:36:22 -0400

>                 the only source of information when making decisions of

So, a little bogosity is fine, just don't go overboard (???)

Come on, let's not dance around the point here. Either reverse DNS is bogus or
it isn't. We should say what we mean and mean what we say. Dithering gets us
nowhere.

- Kevin

---

From: Brad Knowles <[email-masked]>
Date: Thu, 10 Apr 2003 23:41:45 +0200

>  it isn't. We should say what we mean and mean what we say. Dithering gets us

	Reverse DNS is not the sole arbiter of what is good and what is 
not, and should not be treated as such.  It remains a useful tool.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 10 Apr 2003 18:13:01 -0400

The draft is a bad draft. First of all, from a strictly editorial standpoint, there is much
language in it which appears on the surface to be normative, but it is far from clear
whether it is intended as such. I am referring to the lowercase "must"s and the "are
permitted" language.

But, more fundamentally, the draft basically comes off as saying "it's a bad idea to rely on
X, but you have to (or _should_, see my above comment about pseudo-normative language) do X
anyway", where X is, of course, "maintain reverse records". What's the point of this? Either
it's a bad idea to use reverse records, for security/auditing/logging purposes, or it is
not. If it's a bad idea, we shouldn't be recommending that the practice be continued. If
it's *not* a bad idea, then it should be explained not only why it's a good idea, but
specifically how the benefits outweigh the costs (false positives, etc.) of doing it.

- Kevin

[email-masked] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations Working Group of the IETF.
>
>         Title           : Requiring DNS IN-ADDR Mapping
>         Author(s)       : D. Senie
>         Filename        : draft-ietf-dnsop-inaddr-required-04.txt
>         Pages           : 5
>         Date            : 2003-3-28
>
> Mapping of addresses to names has been a feature of DNS. Many sites,
> implement it, many others don't. Some applications attempt to use it
> as a part of a security strategy. The goal of this document is to
> encourage proper deployment of address to name mappings, and provide
> guidance for their use.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dnsop-inaddr-required-04.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-dnsop-inaddr-required-04.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
>         [email-masked].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-dnsop-inaddr-required-04.txt".
>
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 10 Apr 2003 18:12:17 -0400

> not, and should not be treated as such.  It remains a useful tool.

For leaf nodes at least, the cost of its abuses outweighs the benefits of its
uses. IMO.

- Kevin

---

From: Daniel Senie <[email-masked]>
Date: Thu, 10 Apr 2003 19:22:14 -0400

>whether it is intended as such. I am referring to the lowercase "must"s 

Thank you for that feedback. I'll improve the language in the next revision.

>anyway", where X is, of course, "maintain reverse records". What's the 
>point of this?

The point is to:

a) instruct application writers that Best Current Practice is to NOT rely 
on INADDR as a means of "authentication" and

b) instruct Network Operators that Best Current Practice is to implement 
and provide INADDR.

>  Either
>not. If it's a bad idea, we shouldn't be recommending that the practice be 
>continued.

It is bad practice to make use of INADDR in an automated fashion within 
applications. It is however quite useful to have the INADDR information in 
logs and auditing as one of many clues when looking at historical 
information, and it is quite helpful to have functional INADDR information 
when trying to track down problems with routing, peering, etc.

>specifically how the benefits outweigh the costs (false positives, etc.) 

What appears to be needed, if following my a & b above, is to strengthen 
the arguments on both sides, explaining at the same time why INADDR really 
SHOULD be implemented by network operators, and why application writers 
SHOULD NOT rely on this information.

---

From: Doug Barton <[email-masked]>
Date: Thu, 10 Apr 2003 17:00:18 -0700 (PDT)

> SHOULD NOT rely on this information.

I think this is getting closer to something reasonable, except that I'd
change the last bit to say, "and why all consumers of INADDR information
should be aware of the limitations of same."

We're making a big mistake if we assume that we can speak authoritatively
on the quality of all INADDR data on the net. I have a very high degree of
confidence in the quality of the INADDR information on the hundreds of
netblocks that I maintain because it's a priority in my enterprise. OTOH,
I have a high degree of skepticism for someone else's data, and I act
accordingly.

In the FreeBSD project we have a saying, "Tools, not policy." I think that
perspective is very valuable here as well.

Doug

-- 
I'm the kind of man a woman thinks she can change
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 11 Apr 2003 02:49:41 +0200

>  For leaf nodes at least, the cost of its abuses outweighs the benefits of its

	Perhaps.  Perhaps not.  In your sphere of influence, you get to 
make that decision.  However, neither you nor anyone else should be 
making the decision to prohibit others from making their own decision 
in this regard.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 11 Apr 2003 02:53:46 +0200

At 6:13 PM -0400 2003/04/10, Kevin Darcy wrote:

>  The draft is a bad draft.

	Then propose something better.  Or at least propose improvements 
to what's there.

>  But, more fundamentally, the draft basically comes off as saying "it's
>  a bad idea to rely on X, but you have to (or _should_, see my above
>  comment about pseudo-normative language) do X anyway", where X is, of
>  course, "maintain reverse records". What's the point of this? Either
>  it's a bad idea to use reverse records, for security/auditing/logging
>  purposes, or it is not. If it's a bad idea, we shouldn't be recommending
>  that the practice be continued. If it's *not* a bad idea, then it should
>  be explained not only why it's a good idea, but specifically how the
>  benefits outweigh the costs (false positives, etc.) of doing it.

	As said before, it's a bad idea to depend on rDNS as the sole 
source of information as to what is good or bad, but it remains a 
useful tool to help provide additional data when making decisions.

	Therefore, rDNS SHOULD be maintained for both IPv4 and IPv6 
(either manually or using some sort of automated tools).

	What I believe that we are trying to discourage is the 
programmers who decide to depend on rDNS as the sole arbiter of all 
goodness.  This is the bad behaviour that should be eliminated.

---

From: Andras Salamon <[email-masked]>
Date: Fri, 11 Apr 2003 10:29:00 +0200

> b) instruct Network Operators that Best Current Practice is to implement 

This is a nice crisp way to summarise the draft.  In an IN-ADDR context,
this is just a restatement of the usual `conservative in generation,
liberal in acceptance' credo of the IETF, so I don't think one can
disagree with it without also disagreeing with the basic principles of
the IETF.

It would be useful to emphasize this specific wording in the draft,
perhaps in the abstract or as a preamble to section 4.

-- Andras Salamon                   [email-masked]
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Peter Koch <[email-masked]>
Date: Fri, 11 Apr 2003 16:54:56 +0200

> disagree with it without also disagreeing with the basic principles of

but it leads to these typical no-win situations in case of problems.
If one end "relies" upon proper reverse mapping and the other end does not
provide for it, would you think both are equally wrong?

-Peter

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Apr 2003 12:26:11 -0400 (EDT)

> on INADDR as a means of "authentication" and

Of course, the obvious flaw is that most if not all of the proponents
don't see any of the uses described in Section 3 as being
"authentication".  The only thing they acknowledge as being
"authentication" seems to be the BSD r-commands.

> b) instruct Network Operators that Best Current Practice is to implement

For what purpose? So that the persons doing activities described in
Section 3 can do so? They aren't doing these things now, largely, only
because so many sites don't maintain reverse records to their liking.

I have an idea. Some people have created nameserver extensions that
automatically create an A record response to queries of a certain form
h-<ipaddress>.theirzone, and likewise handle in-addr.arpa queries to
return names of this format.  These responses are generated from the
contents of the query, so no maintanence is required.

Lets just extend and standardize this idea and create a f-addr.arpa zone.
The purpose of this zone is to automatically generate A records for
queries of the form h-<octet1>-<octet2>-<octet3>-<octet4>.f-addr.arpa.
The A record returned will have to form: 'IN A
<octet1>-<octet2>-<octet3>-<octet4>'

Since we know the answer from the contents of both these queries, we can
push this functionality into the resolver, so that the nameserver isn't
bothered having to respond to these trivial queries.  With a couple
special cases added to the resolver, everyone is happy. Much load is
removed from nameservers, and the people who want consistent responses to
in-addr, have them.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Sat, 12 Apr 2003 02:58:04 +0200

>  contents of the query, so no maintanence is required.

	Doesn't work.  This removes control over the data from the person 
who has been assigned the space.

>  removed from nameservers, and the people who want consistent responses to

	Also doesn't work.

	Since you are so into making optimizations, let's try this -- 
since everything liquid or solid going into your body is only going 
to come back out again, why not optimize this process and eliminate 
both the entrance and the exit?  Sure would make things a lot 
cleaner, in a whole lot of ways.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 11 Apr 2003 22:41:27 -0400 (EDT)

> who has been assigned the space.

Who needs control when you have consistency?

> >  removed from nameservers, and the people who want consistent responses to

Why? Are you saying this can't be programmed into the resolver?

Its seems that when you say "doesn't work", you really mean "I don't want
that". (followed by wah, wah, wah).

> cleaner, in a whole lot of ways.

I have to give credit for this idea to you: Entrance and Exit are the
same, so they can be optimized away.

---

From: Brad Knowles <[email-masked]>
Date: Sat, 12 Apr 2003 12:08:47 +0200

>  Who needs control when you have consistency?

	Okay, so if someone were to fire a gun at your head every second 
precisely on the second, that would be okay because they have 
consistency, even though you don't have control?

>  that". (followed by wah, wah, wah).

	See above.  It is a further "optimization" of an "optimization" 
that is proven to be false.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 12 Apr 2003 10:06:29 -0400 (EDT)

> consistency, even though you don't have control?

As long as they consistently fire in exactly the same direction, at
exactly the same time, yes. I can duck--they taught me to do that at MIT.
Actually, they taught me not to pee on my fingers, but that's another (but
strangely similar) story... Never mind, you wouldn't understand.

		--Dean

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 14 Apr 2003 13:23:24 -0400

>         Then propose something better.  Or at least propose improvements

"Accept what is proposed or propose something yourself" is a false dilemma As a
third alternative, we could do *nothing* and let reverse DNS wither away of its
own accord, as it becomes less and less reliable over time.

If we want to publish a document that says *only* to not rely on reverse DNS,
I'd be OK with that. It's the "X is bad, but still keep on supporting X",
schizoid part that I'm having a problem with...

- Kevin

---

From: Brad Knowles <[email-masked]>
Date: Thu, 17 Apr 2003 14:48:45 +0200

At 1:23 PM -0400 2003/04/14, Kevin Darcy wrote:

>                       It's the "X is bad, but still keep on supporting X",

	Therein lies the problem.

	We're not saying "X is bad, but still keep on supporting X". 
We're saying "X *by itself* is bad -- you should not use X this way. 
X is useful when utilized correctly, so you should keep supporting X".

---

From: Måns Nilsson <[email-masked]>
Date: Thu, 24 Apr 2003 17:58:12 +0200

> domains with certain nameservers).

Hey, come on. All the RIRen have public whois. You can pretty much find out
anything about any network that is routed on the Net (and a bunch of
others, too) via whois queries. The format is not coherent, it is not
scalable, but it is there. 

That together with a decent public looking-glass will tell the interested
person pretty much anything you might want to know. 

DNS need not be applied in this process, it is merely the pretty-traceroute
icing on an already sweet cake of data. 

So, how about talking DNS operations again, for a change? 
-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 24 Apr 2003 22:46:52 -0400 (EDT)

> person pretty much anything you might want to know.

You can find out about the ISP, which is appropriate. You cannot find out
about the ISP's customers, which is not always appropriate.

> icing on an already sweet cake of data.

I agree it is pretty traceroute icing. I also agree that DNS need not be
applied to this process.  Maybe we are getting somewhere.

		--Dean

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 25 Apr 2003 07:32:16 +0200

> about the ISP's customers, which is not always appropriate.

Worng. Let's look at the source addres of your mail and mine. 

$ whois -a 130.105.11.4

OrgName:    Open Software Foundation 
OrgID:      OSF
Address:    529 Main St.
City:       Boston
StateProv:  MA
PostalCode: 02129
Country:    US

NetRange:   130.105.0.0 - 130.105.255.255 
CIDR:       130.105.0.0/16 
NetName:    OSF
NetHandle:  NET-130-105-0-0-1
Parent:     NET-130-0-0-0-0
NetType:    Direct Allocation
NameServer: STARSHIP.AV8.COM
NameServer: CONCORDE.AV8.COM
Comment:    
RegDate:    1988-07-20
Updated:    1998-12-21

TechHandle: DA31-ARIN
TechName:   Anderson, Dean A.
TechPhone:  +1-617-242-3091
TechEmail:  [email-masked] 

# ARIN WHOIS database, last updated 2003-04-24 20:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

ARIN needs a step for the route info too, so we get the source AS from BGP,
and find the following AS-path: 2603 1239 2548 11784 which is Nordunet,
Sprint, Allegiance Telecom and finally you. 

$ whois -a AS11784 

OrgName:    Plain Aivation, Inc 
OrgID:      PLAINA 
Address:    P.O. Box 7286
City:       Nashua
StateProv:  NH
PostalCode: 03060
Country:    US

ASNumber:   11784  
ASName:     ASN-AV8 
ASHandle:   AS11784 
Comment:     
RegDate:    1998-12-17
Updated:    1998-12-17

TechHandle: DA31-ARIN
TechName:   Anderson, Dean A.
TechPhone:  +1-617-242-3091
TechEmail:  [email-masked]

# ARIN WHOIS database, last updated 2003-04-24 20:10
# Enter ? for additional hints on searching ARIN's WHOIS database.

and over to mine: 

$ whois -r 213.212.3.212 
% This is the RIPE Whois server.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/ripencc/pub-services/db/copyright.html

inetnum:      213.212.3.192 - 213.212.3.223
netname:      MANSNILSSON
descr:        Mans Nilsson
country:      SE
admin-c:      MN1334-RIPE
tech-c:       MN1334-RIPE
status:       ASSIGNED PA
mnt-by:       DPNOC
changed:      [email-masked] 20000203
source:       RIPE

route:       213.212.0.0/18
descr:       Dataphone Communication Networks
origin:      AS8289
mnt-by:      DPNOC
changed:     [email-masked] 19990914
source:      RIPE

person:       Mans Nilsson
address:      Royal Institute of Technology
address:      KTH/SUNET
address:      S-100 44  STOCKHOLM
address:      SE
phone:        +46 8 790 60 00
fax-no:       +46 8 24 11 79
e-mail:       [email-masked]
nic-hdl:      MN1334-RIPE
mnt-by:       SUNET-MNT
changed:      [email-masked] 20010321
changed:      [email-masked] 20021216
source:       RIPE

I haven't bothered with the traceroutes. It should by now be painfully
obvious to most people that there is no privacy gained from removing
reverse DNS, and your argument for this is not holding water.. 

>> DNS need not be applied in this process, it is merely the
>> pretty-traceroute icing on an already sweet cake of data.
> 

Come on, and read what I write. I am trying to tell you that it is
orthagonal to the issue at hand. Can we drop the privacy argument, please?

---

From: Dean Anderson <[email-masked]>
Date: Fri, 25 Apr 2003 02:01:02 -0400 (EDT)

Maybe you want to look more closely.  That hasn't revealed anything about
my customers.

As I recall, you were the person with all your customers on your in-addr,
right?

	--Dean

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 25 Apr 2003 08:27:02 +0200

> Maybe you want to look more closely.  That hasn't revealed anything about

No, but about you. EOFFTOPIC: This communication will now end.