Subject: dnsop-ipv6-dns-issues-02

From: [email-masked]
Date: Wed, 19 Mar 2003 07:26:37 +0900

in the end of the talk (hum), you left one option out - icmp6 node
	information query.

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

---

From: Alain Durand <[email-masked]>
Date: Tue, 18 Mar 2003 14:42:19 -0800

> 	in the end of the talk (hum), you left one option out - icmp6 node

I'd be happy to change this in the draft. Is there any traction behind 
this proposal?

	- Alain.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Mar 2003 00:52:46 +0200 (EET)

> 	in the end of the talk (hum), you left one option out - icmp6 node

Reverse DNS for link-local addresses is an issue, but orthogonal to the
problem on the table.

-- 
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: [email-masked]
Date: Wed, 19 Mar 2003 07:59:12 +0900

>Reverse DNS for link-local addresses is an issue, but orthogonal to the

	you can use icmp6 node information query for global address (and site-
	local if you want to) as well.  what are you trying to mean?

itojun

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Mar 2003 01:06:53 +0200 (EET)

> 	local if you want to) as well.  what are you trying to mean?

Sorry, I should have said s/link-local addresses/link-local nodes/, typo.

Most traffic is not on the local link, rather connecting to service X over
the Internet.  Node information queries are not useful except on the local
link.

Why not?  One could consider why the mechanism is still "stuck" in the
IESG.  I totally agree with not publishing ICMP NI as long as it can be
(ab)used to query off-link nodes.

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Mar 2003 09:07:24 +1000

Radical Surgery proposal: stop doing reverse for IPv6.

straw poll of ADs and WG chairs are mutedly neutral. 

nobody is strongly in favour of continuing.

of course RIR will continue to fulfil reverse delegation role as long as the
community requires it. 

but, maybe its time to stop wanting it.

-George

---

From: bert hubert <[email-masked]>
Date: Wed, 19 Mar 2003 00:27:23 +0100

> nobody is strongly in favour of continuing.

We've been through this discussion already, check the archives. One of the
conclusions reached was that deprecating something is not equal to
discontinuing something. It might in fact render the IETF an 'irrelevant
debating society', if it isn't already.

Regards,

bert

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://lartc.org           Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl                         Consulting
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Mar 2003 10:48:00 +1000

ok. so you mean "any thread with draft-ietf-dnsop-inaddr-required-00.txt"

I'd say its hung jury. Time for a re-trial.

-George

---

From: George Michaelson <[email-masked]>
Date: Wed, 19 Mar 2003 10:43:09 +1000

> We've been through this discussion already, check the archives. 

No search engine. MHonArc lists are not simple to find data in. Pointers?
(even year/month clues would be good)

> One of the

so is that a vote for or against?

also  "that was then: this is now"

I stress, RIR are not about to arbitrarily stop doing reverse. The question
is, why are we doing it? sure, 'you want us to' but also some of "you" are
beginning to say "maybe not"

-George
-- 
George Michaelson       |  APNIC
Email: [email-masked]    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 19 Mar 2003 10:05:46 +0900

>Radical Surgery proposal: stop doing reverse for IPv6.

	i love it

itojun

---

From: Brad Knowles <[email-masked]>
Date: Wed, 19 Mar 2003 04:09:42 +0100

>  Radical Surgery proposal: stop doing reverse for IPv6.

	Why?  What's the problem with providing reverse DNS for IPv6?

-- 
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: Masataka Ohta <[email-masked]>
Date: Wed, 19 Mar 2003 13:04:33 +0859 ()

Brad;

> 	Why?  What's the problem with providing reverse DNS for IPv6?

There is none.

However, IPv6 people have been trying to attribute their problems
to something else.

Radical, but easy, surgery should be applied to IPv6.

							Masataka Ohta

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 19 Mar 2003 07:07:23 +0100

> 	Why?  What's the problem with providing reverse DNS for IPv6?

None, except that it is boring to manually calculate the addresses. 

But, we do have computers for that. 

(yes, I know it speaks of ip6.int, but I've mailed the author about
that...) 

$ sipcalc -r 2001:490:f002:128:260:1dff:fe1d:1fcb
-[ipv6 : 2001:490:f002:128:260:1dff:fe1d:1fcb] - 0

[IPV6 DNS]
Reverse DNS (ip6.int)   -
b.c.f.1.d.1.e.f.f.f.d.1.0.6.2.0.8.2.1.0.2.0.0.f.0.9.4.0.1.0.0.2.ip6.int.

I am all for continuing reverse DNS usage, if for nothing else to make
traceroutes prettier. 

The practice of mandating it is different.

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

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

---

From: Shane Kerr <[email-masked]>
Date: Wed, 19 Mar 2003 11:55:06 +0100

> None, except that it is boring to manually calculate the addresses. 

Not strictly true.  A pretty good presentation on this was given at
the IPv6-SIG at APNIC 15:

http://www.apnic.net/meetings/15/sigs/ipv6/docs/ipv6-fujisaki-reverse-dns.pdf

This doesn't even cover the tricky issue of how you update the reverse
securely for home users (the problem here is that the ISP and the home
have to share a secret somehow, not unsolvable but tricky).

For the record, I think ICMP name lookups would solve the problem of
address-to-name mapping sufficiently for users.  I support the
proposal of no longer doing reverse for IPv6 100%.

-- 
Shane Kerr
RIPE NCC

---

From: Paul Vixie <[email-masked]>
Date: 19 Mar 2003 15:25:12 +0000

> Radical Surgery proposal: stop doing reverse for IPv6.

i think this is the wrong approach.  at a minimum, folks want to be able
to postprocess their transaction logs at the end of a day and still be
able to do gethostbyaddr() even if many of the nodes that came to their
web servers (or whatever) are by that time offline or unreachable.  it's
also extremely important for abuse tracking.  then there's the inability
of network owners to enforce, should they choose, some kind of policy on
gethostbyname(gethostbyaddr(x))==x or the converse.

the right approach, in my opinion, is either some kind of synthesis or a
simple dns dynamic update rule allowing every host the authority to update
its own PTR RR as long as it uses TCP and maybe SIG(0) or maybe not.
-- 
Paul Vixie
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 Mar 2003 01:43:35 +1000

On 19 Mar 2003 15:25:12 +0000 Paul Vixie <[email-masked]> wrote:

> able to do gethostbyaddr() even if many of the nodes that came to theirh
> web servers (or whatever) are by that time offline or unreachable.  

12pm midnight local time, every machine combines to do a DDOS on the DNS,
walking their logfiles. doesn't sound good to me. 

also sounds the kind of thing which could work better from some other process.
when I ran a large FTP mirrors logfile processing, I used router BGP dumps and
pre-compiled prefix/len maps to do this activity. It was 3 orders of magnitude
faster than DNS lookups and more reliable.

I think the granularity of lookup is different for different people.

> it's

the mapping can come from somewhere else. Its demonstrably broken for a
significant space of the deployed network. I question the importance.

> its own PTR RR as long as it uses TCP and maybe SIG(0) or maybe not.

Sure. if you want to increase the value in the reverse, then the reverse has
an increased value, as a function of numbers AND of the innate value of any
one reverse.

but if its optional, and untrustworthy, and currently incomplete and broken,
and breaking other services, its worth questioning its value.

synthesis is interesting. if we're synthesizing, does that mean we're not
doing a top-down delegation model any more? or is this synthesis into
delegated spaces?  given how reverse works, it means a cable operator
has to either manage n * 255  spaces per 16 or one 65,000 host space to scale
this to their net. That might be ok, I don't know. But it doesn't look like it
would be completely straightforward to do for CiDR spaces.

-George

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 19 Mar 2003 17:51:43 +0100 (CET)

> walking their logfiles. doesn't sound good to me.

Its already a fact of life.  There are many 'transaction log' processing
scripts around, eg making pretty graphs out of http logs (for instance,
'webalizer').  These are run daily on the previous day's logs, and a lot
do reference the DNS to get their information.

Yes, some of that information is wrong since the DNS cannot always be
trusted, and there are better, more reliable ways of obtaining the
information (which aren't available to everyone), but there is this
activity happening every day, and its not a DDOS.

-- 
                             Bruce Campbell                            RIPE
                   Systems/Network Engineer                             NCC
                 www.ripe.net - PGP562C8B1B             Operations/Security

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 19 Mar 2003 12:53:05 -0500

>but, maybe its time to stop wanting it.
Reverse DNS for telecom gear (routers, switches, etc.) still makes sense 
IMO, because it demonstrably aids network troubleshooting. But I think 
we should stop recommending it for end nodes. End-node reverse DNS just 
nourishes the myth that you can reliably tell who/where/what 
something/someone is just by doing a reverse lookup on their source 
address, a myth from whence springs wrongheaded security methodologies, 
bogus "traffic-shaping" schemes and similar balderdash. More concisely, 
I think end-node reverse DNS fails cost/benefit analysis.

                                          - Kevin

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Mar 2003 10:07:52 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "George" == George Michaelson <[email-masked]> writes:
    George> Radical Surgery proposal: stop doing reverse for IPv6.

    George> straw poll of ADs and WG chairs are mutedly neutral. 

    George> nobody is strongly in favour of continuing.

  I am strongly in favour of continuing.

  The reverse map provides an authority model which closely matches the
real authority for IP addresses. Is is therefore *VERY* useful for locating
keying information for a node.
  HIP and IPsec is using this *NOW* in IPv4.  
  HIPv6 is very likely to use this. 
  Some people have suggested HIP as a base for multihoming.

  Yes, there are issues with how to get information into the reverse map
given IPv6 auto-configuration. 
  I have ideas on this, but they are not appropriate for this WG.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 Mar 2003 04:18:37 +1000

Let me get this right. You are saying that inherently, because its a top-down
hierarchical model, various security models are using it to find the KEY to
perform subsequent validation on the end-to-end trust.

So, for well behaved delegations, you assert it has real value for real work.

And this work (HIP, HIP6) is likely to have wider adoption in other WG as
well (ie multihoming)

Is that it? Because if so, that needs much bigger prominence in the DNS
activity, so we don't go on assuming nobody cares about this stuff. And, it is
going to need to be put into other ops forums, that lack of reverse management
is impeding other work. 

-George

 On Wed, 19 Mar 2003 10:07:52 -0800 Michael Richardson
<[email-masked]> wrote:

> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
> architect[] [email-masked] http://www.sandelman.ottawa.on.ca/
> |device driver[] panic("Just another Debian GNU/Linux using, kernel hacking,
> security guy"); [
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.7 (GNU/Linux)
> Comment: Finger me for keys
> 
> iQCVAwUBPnix9oqHRg3pndX9AQF+BQQAuL2u2hKTIuNqTCTJ1ccqQ08237HCqf+I
> T/zgiW9aHmw0ijLrCFzq2kHd1AnoMbQQf156H4dtM/2lW8NWy/UZ6XlqPnRy/HeW
> Wx9whfPV75z7J3aXXOYVRO9LY6CHo4bBumm8N11Mw/J3jET5qxsOodBkZIUalzcy
> fANGBCc8OwE=
> =qsfW
> -----END PGP SIGNATURE-----

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Mar 2003 10:51:43 -0800

This thread is a strong symptom of the (appearance of the) IETF 
degenerating into a debating society.  It's not the topic, it's the 
path of the discussion.

Whether or not reverse for IPv6 is done is not the real question.

The real questions are:

1) Will $<approach> for doing IPv6 reverse work?

2) If there are multiple positive answers to the above, do we need to 
find a best approach and/or what set of approaches having positive 
answers are interoperable?

3) If there is no positive answer to the above, is there a compelling 
need to continue searching for an approach that will work?

So -
      of the approaches proposed to date, which ones 'work'?

And -
      does anyone want to make the compelling case we need despite the
      fact that there is apparently no 'working' approaches?  (Is so,
      this is input to the draft cited earlier in the thread.)

PS - I think it would be unwise to explicitly write off any effort in 
any context.  I can understand allocating no resources to an effort 
(effectively killing it via starvation) or ignoring an effort 
(banishing it).  But I don't see a reason to declare that no one 
shall continue to work on (the royal) 'it'.

Perhaps this is a reaction to an unintended interpretation of the 
wording of the proposal.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Mar 2003 11:00:42 -0800

Michael - I agree with this.  If what you say holds water (an' I 
ain't disagreeing, just supposin'), then it's good input to the 
'compelling reasons' draft.

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 Mar 2003 05:08:25 +1000

ok. in that spirit:

	top down delegation in reverse IPv6 works well to the ISP level. 
	ie, where delegation of responsibility over address resource follows
	BCP, then the mechanism to perform DNS reverse management follows in
	a natural manner. We do this. It works.

	it doesn't look to scale well for dynamic edge-host registration
	without confronting some inherently non-scaleable problems: /64
	(and /32 Ipv4 holders) don't have a sane way to promote themselves 
	into the process if more than one intermediate layer of address
	resource holder doesn't want to participate. There are very real
	issues with the probity of taking an edge resource claim, and
	lodging DNS reverse over the head of an intermediate resource
	manager.

	synthesized DNS looks to maybe offer ways out of this, the fusion
	of the ideas would suggest that down to the level of some address
	resource holder, a mechanism for dynamic synthesis on-the-fly would
	be interesting. Its not clear how DNSSEC would work over this.

	6to4 will scale well for large, centrally managed stable-IPv4 located
	gateways. dyanmic (short lifetime) services fall into one of the
	problems noted above.

	some people clearly want reverse. Few people who are providing
	registration services, or writing applications, place much value in
	it, but thats subjective. as long as its wanted, and community 
	supports the overheads, there is no reason to stop. but we do need
	to be clear where the limits lie on what its offering.

	I'll keep my subjective personal view that we should stop. Nothing
	you said Ed, appears to contradict the reasons why I think that.

cheers
	-George

---

From: George Michaelson <[email-masked]>
Date: Thu, 20 Mar 2003 05:12:00 +1000

As another comment here, about the only thing you can take from the DNS is the
->name<- of a key, if the use is to be applied outside of DNS as data in
itself. This came up in PKIX, and got sat on pretty quick.

Unless I mis-read the Security directorate black hat view, its not permissable
to use DNSSEC keys to secure any other aspect of the Internet, apart from the
DNS itself. 

So we'd be talking about an RR identifying a key, to be found in some other
context specific key distribution framework. Right?

-george

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 19 Mar 2003 20:15:01 +0100

--On Thursday, March 20, 2003 04:18:37 +1000 George Michaelson
<[email-masked]> wrote:

> 
> Let me get this right. You are saying that inherently, because its a
> top-down hierarchical model, various security models are using it to find
> the KEY to perform subsequent validation on the end-to-end trust.
> 
> activity, so we don't go on assuming nobody cares about this stuff. And,
> it is going to need to be put into other ops forums, that lack of reverse
> management is impeding other work. 

It IS impeding other work; basically because it is, as run today, at many
places grossly mismanaged. I agree that there are potential scaling
problems with registering all end devices, but as long as people invent
systems to do this (which they will, inband dynamic, secure or not,
$GENERATE ones or actually useful, not a matter for this forum, imho) we
should not discourage them from doing it. 

The reality is that regardless of the gaping holes in the reverse tree, the
parts where it works, are happy to have them working. Traceroutes are the
primary example of applications benefiting from working reverse, but by no
means the only one. 

> its own PTR RR as long as it uses TCP and maybe SIG(0) or maybe not.

I agree that this is probably the path forward for end nodes. 

To summarize: I benefit from reverse DNS and strongly object to any
document suggesting it is obsolete.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 19 Mar 2003 11:26:57 -0800

>>>>> "Shane" == Shane Kerr <[email-masked]> writes:
    Shane> Not strictly true.  A pretty good presentation on this was given at
    Shane> the IPv6-SIG at APNIC 15:

    Shane> http://www.apnic.net/meetings/15/sigs/ipv6/docs/ipv6-fujisaki-reverse-dns.pdf

    Shane> This doesn't even cover the tricky issue of how you update the
    Shane> reverse 
    Shane> securely for home users (the problem here is that the ISP and the
    Shane> home 
    Shane> have to share a secret somehow, not unsolvable but tricky).
  
  Use SIG(0).

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 19 Mar 2003 15:05:15 -0600

on 3/19/2003 11:53 AM Kevin Darcy wrote:

> we should stop recommending it for end nodes.

As soon as a viable alternative is in wide-spread production and which
doesn't have the same kinds of problems (or new ones which are worse), we
can do so. Until then, it's pretty much the only reasonable game in town
for the masses to use.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 19 Mar 2003 16:27:38 -0500

>can do so. Until then, it's pretty much the only reasonable game in town
No, a false sense of security is *worse* than nothing. And as long as 
the band-aid sticks, there little incentive to do things right.

                           - Kevin

---

From: Dean Anderson <[email-masked]>
Date: Wed, 19 Mar 2003 16:39:20 -0500 (EST)

> degenerating into a debating society.  It's not the topic, it's the

I think this is offtopic, but I'll say something on it anyway. Of course
the IETF is a "debating society", in the sense that technical issues are
debated, and decisions are reached democratically.

> Whether or not reverse for IPv6 is done is not the real question.

I think it is the real question. In the last discussion (on namedroppers),
it was explained why reverse DNS serves no useful purpose, and has the
harmful side-effect that many administrators place unfounded trust in it.
At best, reverse is an untrustable convenience function, with a harmful
side-effect.

One can assume the response for reverse dns is of the form
"h-octet-octet-octet-octet.assignee.in-addr.arpa", and similar for IPv6.
Since it is always this form, there is no need to actually do the query.
Millions or billions of unnecessary records (and unnecessary queries) are
stored to find comparatively infrequently accessed information. Anyone who
really desires to find the assignee, can query the address registry.

It makes sense to deprecate reverse lookup for IPv4 (its already
optional), and eliminate it for IPv6.

		--Dean

---

From: Edward Lewis <[email-masked]>
Date: Wed, 19 Mar 2003 14:11:36 -0800

>itself. This came up in PKIX, and got sat on pretty quick.

This isn't 100% accurate.  E.g., certificates can be in the DNS' CERT 
RR and they can contain public keys.  The reason this is acceptable 
is that the certificates are "secured" via the certification system's 
defined means.

The SIKED BOF, of some time ago, proposed to define a generic way to 
put application keys into DNS.  The resounding result was that 
finding a generic way would be a, umm, titanic waste of time.

IPSECKEY WG is chartered (more or less) to find a specific way to put 
one application's keys into DNS.  (In this instance, the application 
is IPsec, and yes, you can debate if it is an application, but...)

>to use DNSSEC keys to secure any other aspect of the Internet, apart from the

The fine hair to split here is that the DNS' KEY RR record is only to 
be used for DNSSEC keys.  The reason is that the KEY RR engenders 
special processing that is not appropriate for non-DNSSEC keys.

The discussion over RFC 3445 went to great lengths to say that the 
restrictions that KEY RR to DNSSEC did NOT mean that application keys 
could not/never be in the DNS, hence the IPsec key effort.

>context specific key distribution framework. Right?

I'll defer to Michael on this, I haven't been following IPSECKEY 
recently enough to answer.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 20 Mar 2003 00:57:04 +0100 (CET)

> to use DNSSEC keys to secure any other aspect of the Internet, apart from the

the KEY RR can only be used for DNSSEC itself. other RRs, like IPSECKEY,
can contain keys.

> context specific key distribution framework. Right?

the IPSECKEY RR contains the actual key and what security gateway to use.

	jakob

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 03:28:01 +0100

[RETRANSMIT -- At least one mail server didn't like my outbound mail 
relay (gotta get my co-lo set up ;-( ), and I'm not sure who may or 
may not have received this message.  Sorry! -- Brad]

>  walking their logfiles. doesn't sound good to me.

	That's what is already happening today.  I don't see any difference here.

>  faster than DNS lookups and more reliable.

	Granted, I didn't run the largest ftp server in the country, but 
I do know that it was one of the largest (probably still is) and that 
the President & CEO of TUCOWS asked me if he could have my machine 
that I was using to mirror his site, once I was done with it.  I 
never had any problem of the sort you mention.

>  and breaking other services, its worth questioning its value.

	DNS as a whole is optional.  Why do we need to use names at all? 
Why don't we all just memorize numbers and be done with it?

	Sorry, I don't buy this "if it's optional then we shouldn't do 
it" argument.

>  delegated spaces?

	You would be synthesizing only in the local part of the network 
you own.  Moreover, you would only be synthesizing things that need 
to be synthesized, since many servers would likely be assigned static 
addresses and would not be changing them frequently.

>                     given how reverse works, it means a cable operator

	It probably doesn't scale too well into pure CIDR spaces, just 
like reverse DNS today doesn't scale well into pure CIDR spaces.  The 
difference is that you can delegate on the nibble with IPv6, whereas 
with IPv4 you're forced to delegated on the byte.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 20 Mar 2003 10:16:07 +0100

On 2003-03-19 11:26:57 -0800, Michael Richardson wrote:
> Shane> This doesn't even cover the tricky issue of how you update
> Shane> the reverse securely for home users (the problem here is that
> Shane> the ISP and the home have to share a secret somehow, not
> Shane> unsolvable but tricky).
>   
> Use SIG(0).

As I understand SIG(0), the home user would have to generate a
public/private key pair and securely transmit the public key to their
ISP.  Frankly, it would be easier to use TSIG and use something based
on the user name and password - which home users have for checking
their e-mail if nothing else - as the secret key.

But the important implication is that each host will have to implement
DDNS, and that the home user will have to know enough to configure
their equipment with the secret somehow.  I don't necessarily think
this is bad, but AFAIK nobody has even proposed the IETF make such a
suggestion.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Mar 2003 01:20:15 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "George" == George Michaelson <[email-masked]> writes:
    George> Let me get this right. You are saying that inherently, because
    George> its a top-down hierarchical model, various security models are
    George> using it to find the KEY to perform subsequent validation on the
    George> end-to-end trust.

    George> So, for well behaved delegations, you assert it has real value
    George> for real work.

  yes!

    George> And this work (HIP, HIP6) is likely to have wider adoption in
    George> other WG as well (ie multihoming)

  It is one possibility, there are others. multi6 is far from close to
adopting anything.

    George> Is that it? Because if so, that needs much bigger prominence in
    George> the DNS activity, so we don't go on assuming nobody cares about
    George> this stuff. And, it is going to need to be put into other ops
    George> forums, that lack of reverse management is impeding other work.

  I agree.

---

From: Shane Kerr <[email-masked]>
Date: Thu, 20 Mar 2003 10:27:49 +0100

On 2003-03-20 05:08:25 +1000, George Michaelson wrote:
> 
> ok. in that spirit:
> 
> 	top down delegation in reverse IPv6 works well to the ISP
> 	level.  ie, where delegation of responsibility over address
> 	resource follows BCP, then the mechanism to perform DNS
> 	reverse management follows in a natural manner. We do this. It
> 	works.
> 
> 	it doesn't look to scale well for dynamic edge-host
> 	registration without confronting some inherently non-scaleable
> 	problems: /64 (and /32 Ipv4 holders) don't have a sane way to
> 	promote themselves into the process if more than one
> 	intermediate layer of address resource holder doesn't want to
> 	participate.  There are very real issues with the probity of
> 	taking an edge resource claim, and lodging DNS reverse over
> 	the head of an intermediate resource manager.

Since we apparently don't consider a /128 to be the goal of reverse
DNS, maybe the goal should be to define a reverse that has the option
of giving a CIDR block as the match.  That seems easy enough.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 02:36:46 +0100

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Mar 2003 10:25:24 -0500 (EST)

> Why don't we all just memorize numbers and be done with it?

Because there is a great deal of value, very little harm, and compared to
the value there is very little work to keep it up.

> 	Sorry, I don't buy this "if it's optional then we shouldn't do

Its not merely because reverse is optional part of a DNS server
implementation. It is the optionality, _and_ the harms that come with it,
_and_ the very little value of the information, _and_ the very large
amount of work to keep it up, which when taken together make it a
questionable service.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 02:06:29 +0100

>  b.c.f.1.d.1.e.f.f.f.d.1.0.6.2.0.8.2.1.0.2.0.0.f.0.9.4.0.1.0.0.2.ip6.int.

	This isn't a name.  This is just the label -- where does it point?

>  The practice of mandating it is different.

	Is reverse DNS for IPv4 mandated?  Why should IPv6 be treated any 
differently in this respect?

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 02:29:18 +0100

>  http://www.apnic.net/meetings/15/sigs/ipv6/docs/ipv6-fujisaki-reverse-dns.pdf

	I read this.  It doesn't really provide much in the way of 
details.  It just says it's "hard" and many don't do it, so it 
recommends that no one do it.

	I'm sorry, I just don't buy this logic.

>  have to share a secret somehow, not unsolvable but tricky).

	Follow the chain of delegations.  Each organization has a 
relatively small part of the space to manage, and internally they 
handle updates, etc... however they feel best.

	Sure, you could provide some tools to help make this easier, more 
fully integrating DNSUPDATE with DNSSEC in your DHCPv6 servers, and 
providing other tools to automate much of this work for machines with 
static IP addresses.  But I don't really see how this is any 
different from reverse DNS for IPv4.

>  proposal of no longer doing reverse for IPv6 100%.

	Too many sites filter ICMP at the border, and for good reason. 
Internally, this may work fine, and may be used to maintain a 
database somewhere -- which should probably be in the DNS, because we 
know that this solution will work and safely cross borders.

	Outside of the local network, I don't see how this could possibly function.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 02:04:27 +0100

>  However, IPv6 people have been trying to attribute their problems

	Okay, if there is no problem with providing reverse DNS for IPv6, 
and the problems lie elsewhere, then why do we have to break the DNS 
in order to try and fix something totally unrelated?

>  Radical, but easy, surgery should be applied to IPv6.

	Fine.  Apply it somewhere else.

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 23:53:34 +0100

[RETRANSMIT -- sorry, mail server problems again.  -Brad]

At 10:25 AM -0500 2003/03/20, Dean Anderson wrote:

>                  It is the optionality, _and_ the harms that come with it,

	You claim that reverse DNS causes harm.  Can you provide evidence 
for this claim?

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 23:43:25 +0100

---

From: Brad Knowles <[email-masked]>
Date: Thu, 20 Mar 2003 02:40:42 +0100

At 12:53 PM -0500 2003/03/19, Kevin Darcy wrote:

>                                                      But I think we
>  should stop recommending it for end nodes. End-node reverse DNS just
>  address, a myth from whence springs wrongheaded security
>  methodologies, bogus "traffic-shaping" schemes and similar balderdash.

	Just because something doesn't work all the time doesn't mean 
that it's not valuable.  My car doesn't work 100% of the time.  Does 
that mean that I should throw it away?

	Sorry, this is an absolutely ridiculous argument.

	There are spaces in which reverse DNS doesn't work as well as it 
could/should.  These primarily have to do with IP addresses that are 
dynamically assigned.  That issue can be resolved by having the 
process that assigns the dynamic address also update the reverse DNS. 
That could be further improved by having a secure mechanism for any 
node to update it's own reverse DNS for itself.

	Sure, it's not going to work 100% of the time.  But it's a damn 
site better than nothing, which is what you propose.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 20 Mar 2003 18:18:50 -0500

>         You claim that reverse DNS causes harm.  Can you provide evidence

The (un-Kerberized) versions of the "r-series" commands harm security
infrastructure, and reverse DNS enables them to function.

Simplistic spam-catching techniques based exclusively on reverse lookups harm
intended mail recipients with their frequent false positives.

- Kevin

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 21 Mar 2003 08:58:55 +0859 ()

Brad;

> in order to try and fix something totally unrelated?

Because their goal is to make stateless autoconfiguration or zeroconf
work on the public Internet.

It does work on isolated LANs. Beyond that, it can not.

Pursuing the impossible goal, they find a problem, try to solve it
only to find new problems.

They are behaving like alchemists not knowing the laws of
thermodynamics.

One of a psuedo solution is a link local solution.

> 	Fine.  Apply it somewhere else.

Yup. Surgery on IPv6 with no real install base is not a problem
at all.

Removing IPsec, autoconf, ND, jumbogram, PMTUD etc. IPv6 can be
almost as good as (considerign larger MTU requirement, a little
better than, maybe) IPv4.

							Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Mar 2003 19:44:30 -0500 (EST)

> 	You claim that reverse DNS causes harm.  Can you provide evidence

It was well hashed over in namedroppers. The short answer is that admins
and programmers place trust in it. This trust is misplaced, and results in
a number of harms. For example, useless logfile entries (because the
programmers fail to record the IP address), and it results in security
compromises, of the .rhosts nature, where admins put trust in the results
of a reverse query.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 02:38:54 +0100

>  compromises, of the .rhosts nature, where admins put trust in the results

	So, we should cripple the entire Internet, and all those people 
who have half a clue and know what the risks are, just because some 
morons are not capable of understanding the problem?

	I'm sorry, what was your reasonable argument again?

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 02:36:45 +0100

>  infrastructure, and reverse DNS enables them to function.

	So, we should break reverse DNS just so that r-commands don't 
work?  Excuse me?!?  Do you recommend killing the patient just so 
that you don't have to deal with their hangnail problem?!?

	I'm sorry, just because some morons choose to leave themselves 
open to the r-command problem is not sufficient justification for no 
longer doing reverse DNS.  Fix that problem where it exists, namely 
within the set of commands that are enabled by default from the 
vendors, or by updating the "best security practices" documentation 
to suit.

>  intended mail recipients with their frequent false positives.

	See above.  This would be like throwing out the whole planet with 
the bath water, not just the baby.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Mar 2003 21:19:38 -0500 (EST)

We wouldn't be "crippling" anything.

We would be admitting that reverse is a pointless endeavor, and at best an
untrustable convenience function for finding out who is assigned an
address.

How much clue one has does not have any bearing on whether reverse is
trustable.  You appear to be holding some false assumptions, demonstrating
the harms for me.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 20 Mar 2003 21:22:51 -0500 (EST)

Nothing would break with the removal of reverse DNS, as no one is relying
on it for anything.  (Anyone who is relying on it, shouldn't be.)

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 10:07:12 +0100

>  on it for anything.  (Anyone who is relying on it, shouldn't be.)

	Then feel free to de-activate all programs and systems you have 
that might potentially make any possible use of reverse DNS.  But 
just because you want to shoot off your foot with a twelve-gauge 
shotgun using magnum 00-buckshot, please don't ask anyone else to 
join you.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 10:05:06 +0100

>  untrustable convenience function for finding out who is assigned an

	If you want to break reverse DNS for yourself, please feel free 
to go right ahead.  But don't ask me to break reverse DNS for myself 
just because you don't like it.  And you have absolutely no right 
whatsoever to ask the entire world to stop doing it just because you 
find it inconvenient.

	If you are really so worried about making sure that r-commands 
can't possibly work (which are perfectly safe in isolated networks), 
or there are other problems which are caused by reverse DNS 
functioning correctly (or not), then I suggest that you make some 
proposals that are actually useful, which will help make reverse DNS 
more idiot-resistant.

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Mar 2003 12:44:19 -0500

Brad Knowles wrote:

> work?  Excuse me?!?  Do you recommend killing the patient just so that 
> you don't have to deal with their hangnail problem?!?
>
> longer doing reverse DNS.  

Not in and of itself, no, but our increased, multi-decade knowledge of 
the uses and abuses of reverse DNS does alter the original cost-benefit 
analysis'es inputs, to the point where reverse DNS now seems like more 
pain than gain, at least with respect to end-nodes, and/or at least with 
respect to IPv6, which is going to increase the "pain" without any 
corresponding anticipated increase in "gain". So maybe it's time to let 
go of the old baggage and start anew.

                                             - Kevin

---

From: "Jessica Little" <[email-masked]>
Date: Fri, 21 Mar 2003 13:25:28 -0500

<2cents>

Start anew?!?... 

IMO, There's been a lot of progress, IPv6 wrt DNS, etc., 
Unfortunately, the Foo Factor, can manifest itself at all levels and stages
of the process... and cannot be always avoided by starting over...
</2cents>
 
JL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kevin
Darcy
Sent: Friday, March 21, 2003 12:44 PM
To: [email-masked]
Subject: Re: [RETRANSMIT] Re: Radical Surgery proposal: stop doingreverse
for IPv6.

                                             - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Fri, 21 Mar 2003 13:46:01 -0500

I was referring specifically to the use of reverse DNS as a 
pseudo-authentication mechanism. Kick out that crutch, and the folks who 
were using it will gravitate towards legitimate, crypto-based 
authentication mechanisms (which hopefully should be independent of the 
underlying -- IPv4 versus IPv6 -- protocol suites). Carry end-node 
reverse DNS forward into the IPv6 world, and you'll *never* get rid of 
the bogus authentication mechanisms...

                                                            - Kevin

---

From: "Jessica Little" <[email-masked]>
Date: Fri, 21 Mar 2003 13:59:05 -0500

Pls ignore last response. It was unintentionally sent.

Thanks

-----Original Message-----

                                             - Kevin

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Mar 2003 14:55:06 -0500 (EST)

Nothing I have would break if reverse doesn't work. It sounds like you
might have something that would break. Perhaps you are one shooting
yourself in the foot.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 21:00:46 +0100

At 1:46 PM -0500 2003/03/21, Kevin Darcy wrote:

>  pseudo-authentication mechanism.

	That is just one of many uses of the DNS, albeit not one of it's best.

>                                   Kick out that crutch, and the
>  folks who were using it will gravitate towards legitimate,
>  crypto-based authentication mechanisms (which hopefully should
>  be independent of the underlying -- IPv4 versus IPv6 --
>  protocol suites). Carry end-node reverse DNS forward into the
>  IPv6 world, and you'll *never* get rid of the bogus
>  authentication mechanisms...

	Okay, so we're going to break the DNS because one particular 
mis-application causes security issues elsewhere, such as with new 
protocol standards like IPv6.

	Do we break the DNS every single time some whacko comes up with a 
bizarre idea to abuse the DNS in yet another way to inappropriately 
solve some other problem?!?

	Seems to me that we could instead require that IPv6 be fixed to 
require crypto-enabled authentication, instead of breaking the DNS.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 20:47:37 +0100

At 12:44 PM -0500 2003/03/21, Kevin Darcy wrote:

>  Not in and of itself, no, but our increased, multi-decade knowledge
>  of the uses and abuses of reverse DNS does alter the original
>  cost-benefit analysis'es inputs, to the point where reverse DNS now
>  seems like more pain than gain, at least with respect to end-nodes,
>  and/or at least with respect to IPv6, which is going to increase
>  the "pain" without any corresponding anticipated increase in
>  "gain".

	It's still valuable for servers, IPv6 or not.  I don't think 
anyone can argue that it's not.

	Granted, it is more difficult for dial-up users and other people 
using dynamic addresses, but we can fix this problem.  Moreover, the 
DNSUPDATE protocol needs to be fixed anyway, to handle the issue of 
dynamically creating new zones.

>          So maybe it's time to let go of the old baggage and start
>  anew.

	I'm sorry.  I see reasons for fixing the DNS protocol, some of 
which may involve IPv6, but I see no justification whatsoever for us 
to simply abdicate our responsibility and recommend that people stop 
doing something just because it's difficult.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 21 Mar 2003 21:10:23 +0100

At 2:55 PM -0500 2003/03/21, Dean Anderson wrote:

>  Nothing I have would break if reverse doesn't work.

	So please turn off reverse DNS for all your zones, and let the 
rest of us make our own choice.

>                                                      It sounds like you

	Not at all.  I'm trying to prevent you from shooting me in the foot.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 21 Mar 2003 15:59:11 -0500 (EST)

The answer is "yes". You seem to be one of the "wacko's" (your term), that
are abusing reverse---Otherwise, you'd not be using terms like "break
DNS".  Non-wacko's (Ok, from now on I'll use another word) know that
Reverse is a convenience only. If it didn't exist, only the convenience of
seeing a name on a traceroute is lost.

Essentially, you are exemplary of the reason is should be deprecated:
People who share your beliefs about reverse put too much trust in it, they
_depend_ on it in some way, and that is bad enough that we need to get rid
of it.

Its just like 3-wheeled ATV's (banned in the US)--They handle like
snowmobiles, and really aren't much more dangerous, but some people put
too much faith in the concept that if you turn the wheel (without
leaning), the vehicle should still turn and not roll over.  Because of
that, the many people who can safely operate the 3wheelers are denied, for
the safety of those who can't.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Sat, 22 Mar 2003 00:14:47 +0100

At 3:59 PM -0500 2003/03/21, Dean Anderson wrote:

>         Non-wacko's (Ok, from now on I'll use another word) know that
>  Reverse is a convenience only.

	Fine.  If it's only a convenience, please disable all your 
applications which may potentially make any use whatsoever of reverse 
DNS, and don't come back to us until you have done so.

	This includes traceroute.

>                                 If it didn't exist, only the convenience of

	Others have already demonstrated what important uses that reverse 
DNS is being put to.  Instead of being a broken record, why don't you 
try to address those issues?

>  _depend_ on it in some way, and that is bad enough that we need to get rid

	I put absolutely no trust in reverse DNS.  However, I believe 
that people should have the right to expect that reverse DNS will 
mostly work, especially in cases where they control both ends of 
certain transactions, and where the applications are intelligent 
enough to do a full forward-reverse-forward check to ensure that they 
aren't being spoofed.

	I may disagree with their choice of methods, but until you can 
come up with real arguments as to why reverse DNS should be 
abolished, I will defend to the death their right to choose to do so.

>  the safety of those who can't.

	I am familiar with 3-wheeled ATVs.  A cousin of mine was a "world 
of outlaws" sprint car driver/mechanic, Chief Mechanic for Sammy 
Swindell (including the brief time he spent trying to break into 
NASCAR), and now has his own business building race cars (or parts 
thereof).  Both he and his brother are frequently involved in 
off-road activities.  They were (safely) riding 3-wheeled ATVs before 
they could legally drive, probably before they were teenagers.

	Reverse DNS is not a three-wheeled ATV.  It has important 
real-world uses, and does not begin to pose the kinds of dangers that 
you imply.

	If you can stop being a broken record and actually come up with 
serious arguments as to why the applications that have already been 
mentioned are not valid, and why reverse DNS is such a heinous crime 
to commit, you might have a chance of convincing me, and others.

	Until then, everything you've said is nothing but a pointless 
repetition of the same old vacuous claims, and you're not going to 
get very far.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 22 Mar 2003 13:16:50 -0500 (EST)

We have no responsibility to do reverse. Its an optional part of RFC 1034.

You seem to be depending far too much on reverse, and demonstrating the
harms of reverse.

---

From: Brad Knowles <[email-masked]>
Date: Sat, 22 Mar 2003 19:32:34 +0100

>  We have no responsibility to do reverse. Its an optional part of RFC 1034.

	Then stop doing it, please!  All I ask is that you don't try to 
stop others from doing it, if they so choose.

>  You seem to be depending far too much on reverse, and demonstrating the

	I will repeat, I do not depend on it at all.  However, there are 
others that have demonstrated that they have real applications which 
make valid use of it, and they are unable or unwilling to stand up 
for themselves.

	Either that, or they're perfectly willing to let me stand up and 
take the pot-shots from the likes of you, something which I am 
perfectly happy doing.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 22 Mar 2003 13:35:24 -0500 (EST)

> try to address those issues?

These issues have been addressed.  There are no "important uses" that are
appropriate for Reverse.  ANY use of reverse beyond a convenience function
is inappropriate, since those uses result in security vulnerabilities, or
log vulnernabilities. You keep repeating the claim that we haven't
addressed something. It is you who keep insisting that reverse can be used
for 'full foward-reverse-forward' checks, despite the now obvious
vulnerabilities.

> mostly work,

They have no right to ever expect this.  This assumption is at root of
most of the inappropriate use of reverse.

> especially in cases where they control both ends of
> certain transactions,

This is also a false assumption. One never controls "both ends".  An
intruder may always be present in between, and might be attempting to
spoof the fact that he is "one of the trusted ends". This is an
inappropriate use of reverse for establishing trust.  People (programmers
and admins) must not do this. That fact that people like you insist on
such inappropriate use is the harm caused by the existance of reverse.
Programmers who rely on your beliefs cause everyone harm.

> and where the applications are intelligent

There is no relationship between "full forward-reverse-forward check", and
"[not] being spoofed".  Yet, you assume (actually, you insist) there is.
It is your assertion that is vacuous. You are revealing exactly the wrong
assumptions and inappropriate use of reverse that require its removal.

> real-world uses, and does not begin to pose the kinds of dangers that

That you fail to acknowledge the danger is obvious. That you are wrong is
also obvious.  That is the primary harm to the existance of reverse.  I
like reverse. Its convenient, when properly used. I don't depend on it for
any "full forward-reverse-forward" checks to establish that I'm not being
spoofed.

> repetition of the same old vacuous claims, and you're not going to

Actaully, you are the one making vacuous claims, as pointed out above.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sat, 22 Mar 2003 13:59:23 -0500 (EST)

> stop others from doing it, if they so choose.

We have to stop people from doing damage, (programmers especially)
inappropriately relying on, or imputing trust based on a service that is
only an untrusted convenience.  That is our responsibility.

> make valid use of it

There are no valid uses of reverse, outside of an untrustable convenience
function.  No other valid uses have been demonstrated.

		--Dean

---

From: bert hubert <[email-masked]>
Date: Sat, 22 Mar 2003 20:27:29 +0100

> only an untrusted convenience.  That is our responsibility.

You may be in need of a rather large reality check. Where it comes to
telling people what NOT to do 'we' or the 'ietf' is an irrelevant debating
society and it is making itself only more so by deprecating functionality
perceived to be useful.

Regards,

bert

---

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

>>>>> On Wed, 19 Mar 2003 01:06:53 +0200 (EET), 
>>>>> Pekka Savola <[email-masked]> said:

> (ab)used to query off-link nodes.

You are apparently saying that the reason for the NI spec being
pending in the IESG queue is that it can be abused for off-link
nodes.  Is my understanding correct?  If so, could you give me a
pointer, please?  I do not remember the exact reason, actually.

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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 23 Mar 2003 15:51:55 +0900

>>>>> On Thu, 20 Mar 2003 05:08:25 +1000, 
>>>>> George Michaelson <[email-masked]> said:

> 	you said Ed, appears to contradict the reasons why I think that.

I have sympathy for you on this, but stopping reverse (for IPv6) seems
to me too radical to be accepted, and, in fact, has caused divergent
discussion.

I'm not sure if I can contribute to making this thread a bit more
productive, but, IMO, a key issue is whether we should continue to
rely on authentication / access control usage that reverse mapping
provides.  That include a simple check to see the existence of a
reverse mapping and the "forward-reverse-forward" check.

I believe everyone agrees that such a check is not very trustworthy
and can easily be spoofed (at least without ubiquitous DNSSEC
support).  A controversial point would be that some people still
believe in the "authenticity" provided by the DNS delegation hierarchy
and/or believe "something is better than nothing".

I also think we can agree that the additional check may cause a
"denial of service" or a service delay for a legitimate (or at least
not-bad) user.

Of course, the additional check will also increase DNS traffic and the
load of DNS servers, but, according to the discussion so far, it is
quite controversial on how serious this is.

So the question is if security benefits provided by reverse lookups
outweighs the disadvantages.

It would be nice If we can reach a consensus on this just by
continuing the discussion here, but I cannot be that optimistic. I have
no measurable evidence for or against the points, though.

					JINMEI, Tatuya

---

From: Andras Salamon <[email-masked]>
Date: Sun, 23 Mar 2003 11:26:20 +0200

On Sat, Mar 22, 2003 at 01:35:24PM -0500, Dean Anderson wrote:
> log vulnernabilities.

I agree that there are currently no appropriate uses for reverse DNS
that can't be addressed in other ways.

I disagree that because of this we should remove PTR records from the
DNS protocol (which seems to be what Dean is advocating).  For all I
know, some people want to use PTR records -- that doesn't put any extra
burden on me to add those records to my zones, I could ignore them.
(Just like most people in DNSOP seem to be ignoring Dean's increasingly
strident calls to drop reverse DNS.)

Reverse DNS is a klunky way to add another index to a database that was
designed around a specific index/lookup mechanism tied to domain names
as keys.  The reverse tree suffers from classic database brokenness,
by design, through duplication of existing data that not only is often
out of synch with existing data, but also has problems with the semantics
of multiple records matching a given key, eg.
    {a,b,c}.example.com <-> IP1, IP2, IP3.
This doesn't mean that it is invalid to want to index the database a
different way.

If we add a mechanism to allow dynamic injection of records into the
reverse tree, the landscape changes.  I would welcome discussion of
potentially useful uses of reverse DNS in this scenario.

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

---

From: Dean Anderson <[email-masked]>
Date: Sun, 23 Mar 2003 14:35:03 -0500 (EST)

> society and it is making itself only more so by deprecating functionality

A reality check is indeed in order.  Perception is not the same as
reality.  As you note, the usefulness is _perceived_.  The perceptions
that are inconsistent with reality need to be changed.  It is the role of
the IETF to promote standards that are consistent with reality, not to
promote demonstrably false and harmful perceptions.

		--Dean

---

From: bert hubert <[email-masked]>
Date: Sun, 23 Mar 2003 20:50:46 +0100

> promote demonstrably false and harmful perceptions.

I suggest we demote DNS while we are at it too, then. TCP can also easily be
sniffed so is probabably just as ripe for deprecation.

People are not going to drop things because the IETF has not decided to
issue guidance. In fact, issuing guidance is *all* that you should expect
this kind of standards body to do. People will do things anyhow, if you
specifiy them or not. If you do not specify anything, they will do it worse.

But I'm leaving this discussion - you and I obviously disagree about the
realities of life.

Regards,

bert

---

From: Dean Anderson <[email-masked]>
Date: Sun, 23 Mar 2003 15:33:40 -0500 (EST)

> DNS protocol (which seems to be what Dean is advocating).  For all I

I am only advocating we drop Reverse from IPV6.  With regard to IPv4, I am
only advocating we make it deprecated, which will not affect any current
users, except to put them on notice that they shouldn't be using reverse
except for non-critical convenience functions, and that they should not
expect this functionality in IPv6.

As far as being "increasingly strident", my language clearly hasn't been
strident at all. I am not the one using the strident, ad hominem terms
like "boorish and rude".  Nor am I repeating exaggerated assertions such
as "removing reverse will break DNS", or increasingly insistent demands
that those of us advocating this `not talk about removing reverse until we
have completely removed it from our servers'. Such statements have no
value in a rational debate of issues. I have tried to avoid responding to
them, and instead try to bring clarity to the arguments for our position
on reverse DNS.  Where I have entertained the looping, it is for the
purpose of demonstrating the unswerving and irrational insistence of those
who harbor false assumptions on reverse DNS, and to demonstrate that as a
harm, not merely from an administrative aspect, but also and probably more
importantly, from a programming aspect.

Our position on Reverse is not motivated purely by the lack of utility of
Reverse---Just the opposite. I find reverse to be convenient. Nor is it
compelling that some administrators might abuse reverse.  The most
compelling harm, and the reason the WG should act, is the combination of
the determination of believers that reverse DNS can be used for
authentication, and the fact that programmers embed these assumptions into
software, which is not easily changed by the end users.  The WG should act
to avert this problem.

Complications for doing reverse in IPV6 contribute to this argument, which
makes it even more sensible to not do reverse in IPV6. Deprecation in
IPV4, as I noted, puts users and implementors on notice about how Reverse
should and should not be used, without actually removing that convenience
from IPv4 networks.

		--Dean

---

From: Jim Reid <[email-masked]>
Date: Sun, 23 Mar 2003 13:30:17 -0800

Reverse DNS does uses, even for IPv6. They are not necessarily
related to authentication. When reverse lookups of the hosts sending
me email don't work, this is almost always an indication of spam. It
would be nice to use this heuristic as the first line of defence
against spam in an IPv6 world.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Mar 2003 00:18:28 +0200 (EET)

> pointer, please?  I do not remember the exact reason, actually.

I think I saw something wrt. "applicability statement" in the I-D tracker, 
but can't find it now.  There seem to be something pending, check 
IESG minutes from 2002-06-13.

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 23 Mar 2003 23:57:43 +0100

--On Sunday, March 23, 2003 15:51:55 +0900 "JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]>

> outweighs the disadvantages.

Security usage of reverse is so absurd (given that DNNSEC will not help if
someone tries to put another domain as RDATA in PTR records) that it is
irrelevant. 

Convenience of having it for less precise needs is not.

---

From: Måns Nilsson <[email-masked]>
Date: Mon, 24 Mar 2003 01:34:35 +0100

> function.  No other valid uses have been demonstrated.

So stop using it. But stop making noise about it, because some of us value
convenience high. If you are to stop everything that is dangerous you might
start by deprecating C. 

"Warning: Knife may be sharp."

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Mar 2003 11:51:15 -0500 (EST)

This is essentially an authentication. However, it is also based on a
false premise, and one that actually blocks more legitimate mail and
little spam.  Most spam comes from infected dialup hosts or rooted colo
hosts, and today most such hosts have trivial forward-reverse entries. So
very little spam is blocked using this "test".  Though perhaps years ago,
this was a rough approximation of dialup.  However, what is more common
today are multihomed mailservers where forward and reverse don't
necessarilly match. This results in "ham" that is blocked.  Spammers
typically have no choice in the DNS configuration, so there is no
correlation between lack of reverse or the presense of reverse, and
sending spam.  In the case of bonafide spamhouses, they have delegated
blocks and control of both forward and reverse, which are typically setup
to satisfy this so-called test.  Few people today use this test for mail,
as a result.  In time, the trend in trivial reverse will result in _only_
ham being blocked.

Another DNS related "heuristic" was domain checking. Out of roughly 100
spams per day, I get only about 3 that don't have valid domains on return
addresses. (I check this by accepting everything on inbound, and not
accepting bad domains on delivery. This results in a bounce, and I count
the bounces.)  So only about 3 percent of the spam has invalid domains.
This isn't a useful heuristic, either.  DNS is not a useful anti-spam
tool.  All users (even spammers) are (presently) authorized customers of
ISP's, and may have access to valid DNS domains.

This is slightly offtopic, though useful as an example of the
misapplication of assumptions about DNS.  However, if you are interested
in the topic of spam control, I suggest you review the material from the
MIT anti-spam conference at www.spamconference.org.

		--Dean

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Mar 2003 12:44:50 -0500

Jim Reid wrote:

>me email don't work, this is almost always an indication of spam. 
>
Which is just another way of saying you're using it as a (very porous) 
form of spammer-versus-not-spammer authentication.

                                       - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Mar 2003 12:48:37 -0500

Brad Knowles wrote:

>
>     I will repeat, I do not depend on [IPv4 reverse DNS] at all.  
> However, there are others that have demonstrated that they have real 
> applications which make valid use of it, and they are unable or 
> unwilling to stand up for themselves.

And what, exactly, qualifies you to be the mouthpiece for this "silent 
constituency"? If anyone has valid uses for reverse DNS, I say let them 
speak for themselves.

                                                         - Kevin

---

From: Jim Reid <[email-masked]>
Date: Mon, 24 Mar 2003 10:49:51 -0800

>>>>> "Kevin" == Kevin Darcy <[email-masked]> writes:

    >> related to authentication. When reverse lookups of the hosts
    >> sending me email don't work, this is almost always an
    >> indication of spam.

    Kevin> Which is just another way of saying you're using it as a
    Kevin> (very porous) form of spammer-versus-not-spammer
    Kevin> authentication.

Indeed. But it's an effective first line of defence. It's not the
only one.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 24 Mar 2003 20:32:22 +0100

At 12:48 PM -0500 2003/03/24, Kevin Darcy wrote:

>  And what, exactly, qualifies you to be the mouthpiece for this
>  "silent constituency"?

	Because I care, and I've got a skin thicker than you or anyone 
else can penetrate.

>                          If anyone has valid uses for reverse DNS,
>  I say let them speak for themselves.

	Which they (and others I was not aware of) have done.

	So, your moot point was ... what exactly?

---

From: Jim Reid <[email-masked]>
Date: Mon, 24 Mar 2003 10:47:36 -0800

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:

    Dean> This is essentially an authentication. However, it is also
    Dean> based on a false premise, and one that actually blocks more
    Dean> legitimate mail and little spam.  Most spam comes from
    Dean> infected dialup hosts or rooted colo hosts, and today most
    Dean> such hosts have trivial forward-reverse entries. So very
    Dean> little spam is blocked using this "test". 

You don't know what you're talking about. Unless you're the source of
most of my spam, you have no idea of the characteristics of my the
spam traffic I get or what are the most effective ways to deal with
it. The majority of spam I receive comes from hosts that have no
reverse DNS AT ALL. So far dropping SMTP connections from hosts with
addresses where reverse lookups return NXDOMAIN or SERVFAIL has not
caused a single false positive. Oh, and the heuristic I spoke about
just tests the result of a reverse lookup. It doesn't "authenticate"
that answer with what's in the SMTP dialogue or 822 headers.

So my example shows that there are valid and reasonable uses for
reverse lookups other than BSD rsh-style authentication which pretty
much everyone accepts is a bad idea.
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 24 Mar 2003 15:04:41 -0500 (EST)

> it.

Spam, like most group phenomena, is roughly uniform, unless there is a
reason for it to be different, such as a targeted attack on a specific
site.  My spam statistics should be roughly the same as your spam
statistics given a sufficient sample size, unless for example, one of us
is being attacked. While attacks happen, they don't usually last long
enough to really skew the statistics, especially if they are identified
and removed. (eg, 10,000 mails to [email-masked] in 1 hour probably isn't
spam, in the ordinary sense, and shouldn't be counted). To obtain my
statistics, no spam is dropped or deleted. It is all saved.

> The majority of spam I receive comes from hosts that have no

If you are dropping connections based on no reverse DNS, then you don't
know whether the message you dropped was spam or ham. You are just
assuming it is a spam, and perhaps you are counting the number of
connections dropped.  You mention that dropping connections on Servfail or
nxdomain results in not a single false positive. Apparently, in your
universe, real nameservers don't fail.  In my universe, only 3 percent of
spams have bogus domains.  (Note that my queuing system described
previously will not bounce messages that have transient failures, unlike
yours.)

Today, I got 128 spams. (very little is from bonafide spamhouses). 19 had
no reverse. Blocking these 19 make no difference.  However, a large amount
of non-spam email also has no matching reverse.  Blocking those do make a
difference, at least to most people, though perhaps not to everyone.

Further, as pointed out at the MIT anti-spam conference (which I
attended), people making claims like yours aren't really checking spam vs.
ham results, which is necessary to obtain results on effectiveness. Most
people simply put in some filters, which deletes some mail, and they have
no idea how much of the deleted mail is spam, vs how much is ham.  When
you report "not a single false positive" you are just reporting your
confidence in your methods, not the true effectiveness of your methods.

> much everyone accepts is a bad idea.

You are attempting to use DNS to make a decision about whether the person
communicating is a spammer. That is an authentication of the challenge
"Are you a spammer?".  DNS has no facility to make such an authentication
possible. Your assertion to the contrary is faulty. It does not represent
a valid use of Reverse.

		--Dean

---

From: steve ulrich <[email-masked]>
Date: Mon, 24 Mar 2003 14:48:52 -0600

when last we saw our hero (Monday, Mar 24, 2003), 
 Kevin Darcy was madly tapping out:
> >However, there are others that have demonstrated that they have
> >real applications which make valid use of it, and they are unable
> >or unwilling to stand up for themselves.
> 
> "silent constituency"? If anyone has valid uses for reverse DNS, I
> say let them speak for themselves.

why is this so difficult for folks?  there are perfectly valid reasons
for having reverse DNS.  if people choose to update and support rDNS
on their networks more power to them. POLA alone should be enough
reason to keep the functionality around.  

i don't think that anyone here is actively promoting f-r-f checks as a
comprehensive integrity check. however, there are existing IPv4
applications, admittedly poorly crafted - which expect this behavior.
ideally, they would fix this behavior as the move to IPv6.  but some
will not. 

for an incremental amount of additional effort they have their IPv6
DNS world behave like their IPv4 DNS world did.  what's it to you?
don't rob folks of convenience based on personal views on this matter.

-- 
steve ulrich                       [email-masked]
PGP: 8D0B 0EE9 E700 A6CF ABA7  AE5F 4FD4 07C9 133B FAFC
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Brad Knowles <[email-masked]>
Date: Mon, 24 Mar 2003 23:02:34 +0100

At 3:04 PM -0500 2003/03/24, Dean Anderson wrote:

>  site.

	On sufficiently large samples, this may be true.  However, when 
it comes to the spam that any individual gets, well there aren't any 
smaller sample sizes than that.  Any assumptions may make about the 
larger population may (probably will) be totally invalid when it 
comes to specific individuals.

>         My spam statistics should be roughly the same as your spam
>  statistics given a sufficient sample size,

	Maybe.  Maybe not.  Since you don't have access to all of Jim's 
e-mail over the past decade-plus, you will never know.

>  know whether the message you dropped was spam or ham.

	Again, maybe, maybe not.  However, you are making inaccurate 
conclusions based on incomplete data.  This is a case where you would 
be better off keeping your mouth shut and merely thought to be a fool.

>  confidence in your methods, not the true effectiveness of your methods.

	Tell me something.  How many decades have you been doing DNS? 
How many decades have you been doing e-mail?  Of those decades, how 
much of that work has been at the highest volume sites in the world, 
where millions and billions of spams are dealt with on a daily basis?

	Unless you have more experience doing the DNS than anyone in the 
world, and more experience doing e-mail and dealing with spam than 
anyone else in the world, and you can call on this experience in 
making proclamations about the kind of spam that other people might 
possibly be seeing and how the DNS might or might not be involved, 
you really don't have a leg to stand on.

	Personally, since your first name isn't Paul, or Eric, or some of 
the various other names I am familiar with, I don't think there's 
much chance of this.

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Mar 2003 17:57:29 -0500

>don't rob folks of convenience based on personal views on this matter.
Nobody's "robbing" anyone of anything. This is a matter of deprecation 
versus encouragement. Those who wish to deprecate end-node reverse DNS 
look forward to a day when reverse DNS is never used improperly as an 
authentication mechanism -- for spam detection or otherwise. Those who 
wish to encourage end-node reverse DNS apparently are comfortable with 
the continuation of this absurd and misleading practice.

                                                - Kevin

---

From: Kevin Darcy <[email-masked]>
Date: Mon, 24 Mar 2003 18:10:48 -0500

>     Because I care, and I've got a skin thicker than you or anyone 

Whatever. I haven't even _tried_ to penetrate your skin. Did you think I 
had?

>     Which they (and others I was not aware of) have done. 

And all of those allegedly "legitimate" uses have turned out to be 
doable better -- more securely, more reliably, whatever -- in other ways 
besides end-node reverse DNS. Got anything new to add to the discussion?

                                                         - Kevin

---

From: Rob Austein <[email-masked]>
Date: Mon, 24 Mar 2003 19:05:30 -0500

At Mon, 24 Mar 2003 12:48:37 -0500, Kevin Darcy wrote:
> 
> If anyone has valid uses for reverse DNS, I say let them speak for
> themselves.

<hat wg-chair=off just-another-bozo-on-this-bus=on>

Traceroute and various related debugging and monitoring tasks where
hostile intent, while possible, is less likely than dumb mistakes.
Yes, dumb mistakes can include DNS setup, but one can often extract
useful clues anyway.

MTA logs, where even in cases of hostile intent, the entity whose name
goes into the log is often just another victim.

The point is not that anybody in their right mind would -trust-
reverse DNS in the sense of making critical decisions based solely on
data that one finds there, but it's frequently a source of additional
data that some of us find useful, and sometimes it's easier to extract
information from the DNS then confirm it via other means than it would
be to figure out what's going on without using reverse DNS.

I don't buy the argument that we need to abolish reverse DNS just
because some people misuse it.

</hat>

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Mar 2003 17:01:22 -0800

brad and dean, could you two please take your silliness elsewhere.  it has
become a DoS to the rest of the people and work here.

randy

---

From: Brad Knowles <[email-masked]>
Date: Tue, 25 Mar 2003 01:58:36 +0100

At 6:10 PM -0500 2003/03/24, Kevin Darcy wrote:

>  doable better -- more securely, more reliably, whatever -- in other
>  ways besides end-node reverse DNS.

	Maybe, maybe not.  Best is the enemy of good enough -- do you 
have a perfect solution that can theoretically be delivered at some 
unknown point in the future?  If so, I think I'd prefer to use the 
tools I have today while waiting for this theoretically perfect 
solution, and I do *NOT* want you or anyone else trying to take those 
tools away from me.

>                                     Got anything new to add to the
>  discussion?

	Do you?

	If you are so violently opposed to reverse DNS, then please turn 
it off for all your systems and all your applications.  Don't come 
back to us until you are done.

	Meanwhile, I shall continue to insist that, regardless of 
whatever you may think is appropriate for you to do on your own 
systems, you do *NOT* stand in the way of other people doing what 
they feel is equally appropriate for their systems.

---

From: Brad Knowles <[email-masked]>
Date: Tue, 25 Mar 2003 02:38:24 +0100

>  become a DoS to the rest of the people and work here.

	In his role as WG chair, Rob privately asked us to agree to 
disagree.  I was willing to do that if Dean was.  However, Dean chose 
to make his reply on this subject (that he refused to agree to 
disagree) on the public mailing list.

	I continue to be willing to agree to disagree, and to let this 
discussion drop, but only if others do the same.

	Otherwsie, I'm not about to let Dean, Kevin, or other 
destructionists have the last word on this subject.

---

From: Randy Bush <[email-masked]>
Date: Mon, 24 Mar 2003 17:47:41 -0800

> destructionists have the last word on this subject.

i will send you each a bona fide "You Are Right" certificate if you
will both shut the hell up.  you are one message from my .procmailrc.
dean is a long-time entry.

randy

---

From: Dean Anderson <[email-masked]>
Date: Tue, 25 Mar 2003 16:17:06 -0500 (EST)

> because some people misuse it.

No, of course that isn't a good enough reason do abolish reverse.  You
missed this:

-------------------- From a previous message:

                                                              ^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

-------------------- From a previous message

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 26 Mar 2003 13:42:13 +0900

>>>>> On Mon, 24 Mar 2003 00:18:28 +0200 (EET), 

> IESG minutes from 2002-06-13.

Okay, so please find a clear pointer before using such an unfair,
misleading wording.

Thanks,

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Wed, 26 Mar 2003 13:53:56 +0900

>>>>> On Sun, 23 Mar 2003 23:57:43 +0100, 
>>>>> Måns Nilsson <[email-masked]> said:

> someone tries to put another domain as RDATA in PTR records) that it is

Can we all really agree on this point?  I know many people in this
thread (regardless of their position about reverse mapping) said a
similar point, but I still see those who believe in the "security
benefit" of reverse mapping.

If I'm wrong, then I'll be happy, and we can consider various
approaches for the "convenience" purposes which may coexist each
other.  Such approaches will include:

- wildcard reverse mapping for some upper zone
- ICMPv6 node information queries

					JINMEI, Tatuya

---

From: Dean Anderson <[email-masked]>
Date: Wed, 26 Mar 2003 11:42:35 -0500 (EST)

Yes, I agree with this.  Both of the methods you have listed replace the
convenience of having reverse.

		--Dean

---

From: Måns Nilsson <[email-masked]>
Date: Wed, 26 Mar 2003 18:03:29 +0100

--On Wednesday, March 26, 2003 13:53:56 +0900 "JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]>
wrote:

>> Security usage of reverse ...
> 

I think people confuse "security" with "order". For instance, several IRC
servers only let people in if forward and reverse match. This is just a
simple test, just to see if the client in some fuzzy way comes from "the
right side of the tracks". It does echo of "security", but it is really
just a matter of "order". The same goes for ftp servers. 

> Such approaches will include:
> 

I think, to a certain extent, that these proposals are the result of the
approach "Now we have a new IP version. Let's change everything that has
annoyed us even a little bit, be it only from an æstethic point of view"
which has shown itself in various places in discussions wrt IPv6. 

I argue that while the number of available addresses will be perceived as
close to infinite when comparing v6 to v4, but I find it hard to believe
that the number of hosts will increase 79228162514264337593543950336 
(2^128 / 2^32) times as soon as we have v6 deployment. On the contrary, I
believe that it will be gradual, pretty much as it was for v4, though I
think it will be considerably faster. 

Therefore, the present techniques will be adaptable to v6, and with
increasing automation (dhcp/dns interaction, dynamic updates,
autogeneration based on arp tables, and the old-fashioned
$EDITOR-in-zonefile), what have you, will be sufficent until we know (as
opposed to guessing) what number of hosts will be typically deployed. 

IPv6 is not magic, it is just more address space. When will people
understand?

---

From: Rob Austein <[email-masked]>
Date: Wed, 26 Mar 2003 13:08:32 -0500

Call me old fashioned, but I prefer to know what problem I'm trying to
solve before chatting about solutions.

George's original problem, paraphrased, was "the RIRs are putting some
work into maintaining reverse trees, and would like to know whether
anybody thinks this is useful."  The answer boiled down to "yes, some
people think that this is useful."

Jimmei appears to be asking a different question, but I haven't yet
figured out quite what it is.  Jinmei?

Attempting to respond to one specific point in Jinmei's message:

> benefit" of reverse mapping.

It's more complicated than that.  The fundamental problem is lack of a
clear authorization model for use of IP addresses (v4 or v6, doesn't
matter).  What we have now is a mixture of two models:

1) Net admin assigns addresses, either manually or via a protocol like
   DHCP (and perhaps using some enforcement mechanism to restrict
   usage to authorized nodes, but probably not);

2) Node performs some kind of "seize and defend" operation, whether
   through some kind of autoconf mechanism or manual configuration.

It's just barely possible that some of the work coming out of the SEND
(Securing Neighbor Discovery) WG will give us a third model for IPv6,
but that work isn't very far along yet and I might just be confused.

Various people have observed that while it's theoretically possible
for a node to prove that it has control over a DNS name (put a public
key at the name, node proves it has corresponding private key), this
does not solve the reverse tree problem in the general case, because
of the difficulty of demonstrating that some otherwise unknown node is
the authorized user of a particular IP address.

So while the general case is hard, there are certain situations in
which it is possible to put signed data into the reverse tree and have
some assurance that the data is correct (eg: model 1 above, using the
DHCP authentication model, which works in some cases but which has
known has scaling and mobility problems).

Whether such data is useful in the cases where it is possible is
another of those local usage questions that led us down the previous
rathole.

See also the IPSECKEY WG for another example of signed data that it
may be useful to put into the reverse tree.  YMMV.

Last, note that the authorization model for address prefixes isn't
as hopeless as the authorization model for addresses.  Whether that's
a useful distinction depends on what problem we're trying to solve.

--Rob

---

From: Daniel Senie <[email-masked]>
Date: Wed, 26 Mar 2003 15:51:28 -0500

>just a matter of "order". The same goes for ftp servers.

Order, as in: their broadband provider has a clue? Let's face it, there are 
lots of folks who don't have control over this. So if you claim this check 
isn't being done for security reasons, then it merely smacks of elitism.

I am glad there's so much discussion of INADDR. I was unable to get much 
discussion of it in the last few years in working on 
draft-ietf-dnsop-inaddr-required-xx with the intention of publishing as a 
BCP indicating best practices in this area. I'll revive this, either as an 
individual submission or WG item, if folks will actually provide 
constructive input.

Dan

---

From: Paul Vixie <[email-masked]>
Date: 26 Mar 2003 21:13:36 +0000

[email-masked] (JINMEI Tatuya / 神明達哉) writes:

> > Security usage of reverse is so absurd (given that DNNSEC will not help
> > if someone tries to put another domain as RDATA in PTR records) that it
> > is irrelevant.
> 

"security" is a broad term.  if you mean "use it for authorization" or "use
it for authentication" then no, the contents of a PTR RR are not useful for
security, or even relevant to security.  if however you want to know what
the network's owner thinks a host is called, and you're going to use this to
prevent or detect or follow up on certain kinds of errors, or if you want to
be able to find some kind of hostname hint even if the host is offline or
refusing to give out such hints, and if you think that any of those things
are related to "security", then a PTR RR has security uses.
-- 
Paul Vixie

---

From: Tom Limoncelli <[email-masked]>
Date: Thu, 27 Mar 2003 08:12:11 -0500

I agree.

Also...
There are many non-security purposes that go under the category of 
"operations".  For example, the first step to fixing a routing issue is 
usually doing a traceroute between the affected networks.  Seeing the 
names of the intervening routers is a big part of the "detective work" 
that is done before one can determine the fix.  There are many 
non-security examples.

Add this to Vixie's list of examples:  It's very nice to be able to 
look up an IP address of a machine that I can't actually access due to 
a firewall.  Having reverse lookups being handled by a machine other 
than the actual machine itself is very powerful.

I do think that IPv6 will mean the end of flat-files for DNS databases, 
but that just seems to be how things progress in life.  All systems 
grow in complexity until they require an SQL back-end. :-)

--tal

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 27 Mar 2003 23:56:10 +0900

>>>>> On Wed, 26 Mar 2003 13:08:32 -0500, 
>>>>> Rob Austein <[email-masked]> said:

> people think that this is useful."

I think this is oversimplification, for example, according to the
latest message from George (attached).  But, anyway,

> figured out quite what it is.  Jinmei?

I was probably unclear, and perhaps made a logical leap.

I wanted to see a consensus (if we can reach it) on how much we should
(continue to) rely on reverse mapping.  In particular, I'd like to
know cases where reverse mapping must be provided and other approaches
cannot apply.

For example, the address to name mapping for traceroute can be
provided by ICMP node information messages (of course, it depends on
whether intermediate routers support and allow the ICMP, and reply a
useful node name.  But similar arguments apply to DNS reverse mapping
as well.)

Some servers reject connections if the remote address does not have a
DNS PTR (i.e. reverse) record or the "gethostbyname(gethostbyaddr())"
check fails.  However, I don't understand if such a policy provides a
benefit that can outweigh disadvantages like denial of "non-bad" users
or connection setup delay.

Some spam filters regard an e-mail message as a spam if the sender
address does not have a DNS PTR record.  This may be a good first
filter, but may also have a disadvantage to reject a valid message
(which happens to be sent from an address that does not have a PTR).
Also, many other spams are also sent from a "valid" address in terms
of the DNS reverse mapping.  If we really want to start rejecting
spams, we'll need a more intelligent filter after all (this is at
least the case for me).  So, again, I don't understand if this
filtering really provides a benefit that can outweigh the
disadvantage.

Of course, this kind of issues are relatively matter-of-taste ones,
and it will be very difficult, or at least ineffective, to make
administrators to change these policies.  However, if we can agree on
some "moderate" usage of reverse mapping that provides a good tradeoff
between benefits and disadvantages, we can perhaps move to the ideal
operation gradually.  At least I don't think the current practice
provides a good tradeoff.

Regarding messages from George, if we can move to a slightly different
operation which is less dependent on reverse mapping, some of his
frustration (e.g., load of top level servers) might be mitigated.  On
that point I think my points is related to his message.

> It's more complicated than that.
(snip)

I admit the word "security" was too broad, as others also pointed
out.  I tried to be more concrete above, so I won't respond to this
part.

I hope I'm clear this time, even though others may still disagree with
me.

					JINMEI, Tatuya

Subject: Re: Radical Surgery proposal: stop doing reverse for IPv6.
From: George Michaelson <[email-masked]>
To: Edward Lewis <[email-masked]>
Cc: [email-masked]
Date: Thu, 20 Mar 2003 05:08:25 +1000

ok. in that spirit:

cheers
	-George

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 28 Mar 2003 00:19:46 +0900

>>>>> On Wed, 26 Mar 2003 18:03:29 +0100, 

> just a matter of "order". The same goes for ftp servers. 

As others pointed out, I admit the wording "security" was too broad.
However, I don't see difference between "security" and "order" in
terms of the tradeoffs between benefits and disadvantages.

> which has shown itself in various places in discussions wrt IPv6. 

I see your frustration, but I'd respectfully say this is a subjective
argument that cannot make a productive result.  I, for one, have tried
to be rather conservative and not to propose changing existing
protocol/practices/implementations just because "we now have a new IP
version."  You may simply disagree, though.

> opposed to guessing) what number of hosts will be typically deployed. 

Probably they will, but this does not prohibit us from exploring a
"better" solution (at least for those who don't think the current
situation is best) that can be introduced gradually.

> IPv6 is not magic, it is just more address space. When will people

I don't know who are "people" or when the people will understand that,
but I've never believed or said IPv6 is a magic.  I've always
understood it is essentially just more address space (though there are
still some unique characteristics, of course.)

					JINMEI, Tatuya

---

From: [email-masked]
Date: Thu, 27 Mar 2003 08:03:44 -0800

On Thu, Mar 27, 2003 at 11:56:10PM +0900, JINMEI Tatuya / ?$B?@L@C#:H?(B wrote:[...]
> useful node name.  But similar arguments apply to DNS reverse mapping

IPV4 reverse mapping is currently deployed, and therefore provides a
functioning operational/software model for IPV6 node identification. 
Any scenario involving deployment of a new mechanism necessarily creates
a substantial extra burden, in a number of areas. 

Kent

---

From: Paul Vixie <[email-masked]>
Date: 27 Mar 2003 18:28:52 +0000

> know cases where reverse mapping must be provided and other approaches

the reverse mapping function provided by PTR RR's in both ipv4 and ipv6
provides an unauthenticated but still useful indication of the strength of
the relationship between the operator of a network and the operator of a
host on that network.  icmp, for example, wouldn't do this.

very few host//network configuration errors shown by a failure in reverse
mapping are limited to just reverse mapping failures -- there's almost
always something else wrong, of which a reverse mapping failure is the
mere "tip of the iceberg."

problems related to maintaining the reverse mapping, either via synthesis
or dynamic update or preallocation or whatever, are really just problems
in trying to support a strong enough relationship between the operator of
a network and the operators of hosts on that network, if the number of
hosts grows the way we expect it to.  that's a technical problem, let's
solve it, rather than declaring a priori that the gain isn't worth the pain.
-- 
Paul Vixie

---

From: Dean Anderson <[email-masked]>
Date: Thu, 27 Mar 2003 14:37:27 -0500 (EST)

The very thing we have demonstrated is that reverse provides no indication
of the strength of the relationship between the operator of a network and
the operator of a host.  None whatsoever.  People using reverse as a
strength indication are assuming the DNS data in reverse is authentic, and
that more than one entity is controlling the forward and reverse zones.
Such an assumption is invalid.  As has been shown, this is a harmful use
of reverse.  The addition of the word "unauthenticated" to your
description does not remove the false assumption made and the harms of
that false assumption.

One of the things Jinmei is saying is that there are alternatives for the
convenience functions, such as traceroute's use of reverse.  ICMP does
fullfill this useful function for IPV6.  This is a step forward. It also
shows that reverse is unnecessary in IPV6.

A so-called "reverse mapping failure" may be "indicated" when the provider
has multihomed hosts, so that forward doesn't match reverse. Or simply
isn't doing reverse (as they may optionally decide not to do).  This isn't
a "failure", and doesn't indicate anything is wrong.

Given the harms of reverse,
Given the complications of doing reverse in IPV6,
Given the alternatives for its useful convenience functions in IPV6,

There is no need to have Reverse in IPV6.

On 27 Mar 2003, Paul Vixie wrote:

> [email-masked] (JINMEI Tatuya / ����ã��) writes:
>

---

From: Bill Manning <[email-masked]>
Date: Thu, 27 Mar 2003 14:58:22 -0800 (PST)

[Charset X-UNKNOWN unsupported, skipping...]

Dean, no one is forcing you to populate the reverse maps that you 
might be responsible for.  If you feel strongly about the issue, 
then act within your scope and don't do it.  

However...  please don't try and force me to adopt your stance.
I like/use the reverse maps and others do as well and intend to
use them for all my delegations.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 27 Mar 2003 18:40:05 -0500 (EST)

That would be fine, except that some people like Vixie and others tend to
write software that puts reverse map entries in log files. Then
consultants go in and try to figure out who rooted a server, and find
bogus reverse entries, and no IP addresses.  The culprit gets away because
someone told people (or implemented it directly) that they can use reverse
as a way to determine the relationship between the network operator and
the host operator.  They also mislead people about the use of reverse, so
that your assertion (according to them, anyway) that "no one is forcing
[me] to populate reverse maps" is false.  Vixie again repeats the
assertion that not having reverse is a sign something is broken, in his
last email on the subject.

The rest of your argument seems to be completely IPV4 specific. We are
talking about an IPV6 problem. There are no reverse maps for IPv6, and
there are problems creating them.  There is also no need (for tools like
traceroute) in IPv6 to have reverse because there are alternatives such as
ICMP node identification.

The people who feel so strongly for reverse want us to undertake
considerable effort to make reverse work in IPV6, including eliminating
certain structure. This is a waste of time, for the harms given, and for
the reason that there are adequate alternatives in IPV6.

		--Dean

---

From: Brad Knowles <[email-masked]>
Date: Fri, 28 Mar 2003 03:06:34 +0100

At 6:40 PM -0500 2003/03/27, Dean Anderson wrote:

>  write software that puts reverse map entries in log files.

	You seem to be saying that the one and only security 
vulnerability these days is reverse DNS.  In fact, there are many 
modern security vulnerabilities.  Even if the IP address were 
provided in all possible cases, IP addresses can be spoofed.  Buffer 
overflows can result in bogus IP addresses being logged.  Off-by-one 
errors can cause incorrect IP addresses to be recognized.  Insecure 
applications elsewhere on the machine can result in a local redirect 
that makes the connection appear to come from the machine itself (or 
elsewhere on the local network).

	There are plenty of security vulnerabilities around.  Paul Vixie 
is certainly not the only programmer in the world, and I'm sure that 
he's made a few programming errors which resulted in security 
vulnerabilities.  However, I don't see any justification for publicly 
vilifying him as one of the biggest "criminals" responsible for 
creating security vulnerabilities, when in fact, you have provided no 
evidence that he has participated in this kind of short-sighted 
programming in recent history, and in fact has been one of the best 
champions we've got for improving security in code related to the DNS.

>                                                              Then
>  bogus reverse entries, and no IP addresses.

	That's the fault of the people who wrote the program which failed 
to record both the IP address(es) and the reverse DNS data.  This is 
not the fault of Paul Vixie, or BIND.

>                      They also mislead people about the use of reverse, so
>  [me] to populate reverse maps" is false.

	Who misleads people?

>  there are problems creating them.

	So, you're saying that ip6.arpa and ip6.int don't exist?  I don't think so.

>                                     There is also no need (for tools like

	Do you honestly think that anyone is going to let ICMP 
information escape their network?  Do you bother to monitor the NANOG 
mailing list?  It seems like every week we hear about yet another 
network that is being stupid and using large packet sizes and Path 
MTU discovery, but are blocking all forms of ICMP at their border 
that would allow PMTUd to actually function correctly.

	Many, many more networks selectively block ICMP, allowing only 
those bits that are needed to support PTMUd, and blocking all other 
forms of ICMP -- which breaks most implementations of traceroute.

	ICMP may be sufficient within a particular network or subnetwork, 
but you can't count on it beyond the first router.  Other means have 
to be used to bridge that gap.

	Now, maybe reverse DNS isn't the best way to do that, but that's 
a different discussion.

>  certain structure.

	Eliminating what structure?  Where have I (or anyone else) 
advocated "eliminating" anything in favour of reverse DNS?

	Personally, I don't want you to do anything you don't want to do.

	If you don't want to do reverse DNS, then you should have that 
option.  However, I do not feel that you should have the power to try 
to force other people to follow your same philosophy.

>                     This is a waste of time, for the harms given, and for

	Please prove this assertion.

	And if this message results in my being filtered by Randy, then 
so be it.  I am trying very hard to be a "good boy" and stay out of 
this argument as much as possible, but there are some things I just 
can't leave unsaid.

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 28 Mar 2003 13:05:14 +0900

>>>>> On 27 Mar 2003 18:28:52 +0000, 
>>>>> Paul Vixie <[email-masked]> said:

> host on that network.  icmp, for example, wouldn't do this.

I understand that.  My question is, in which case and how much we
should rely on the useful indication.

> mere "tip of the iceberg."

From my own, of course limited, experiences, this is not necessarily
true (that's why I don't think the current situation provides a good
tradeoff).  But I don't have a statistical evidence and thus can only
make an apriori argument, so I'll stop here on this point.

> solve it, rather than declaring a priori that the gain isn't worth the pain.

Sure, I don't oppose to making reverse mapping robust as long as the
effort is effective and can provide a good tradeoff.  (And I don't
think I declared the gain isn't worth the pain, though I surely said I
don't understand the gain is worth the pain in the current operational
practice.)

At the same time, I still believe it is good for us to study cases
where we should really rely on reverse mapping and cases where we
don't have to (but we currently do), as a part of solving the
"technical problem."  In this sense, I want the
draft-ietf-dnsop-inaddr-required draft to be discussed further.

And also, I believe there should be cases where we don't have to rely
on reverse mapping and can apply other approaches, as a part of
solving the technical problem.

All of three are ongoing efforts to solve the same problem, and none
of them can reject pursuing others at this moment.  Of course, if some
of the efforts complete, it may affect the others.  For example, if
the first approach can provide a perfect solution, the rest may be
unnecessary.  Similarly, if we can agree on some applicability in the
second approach (this is my main opinion in this thread), it may make
the first approach easier and more effective.

					JINMEI, Tatuya

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 28 Mar 2003 15:26:00 +0100

--On Wednesday, March 26, 2003 15:51:28 -0500 Daniel Senie <[email-masked]>
wrote:

> 
> Order, as in: their broadband provider has a clue? Let's face it, there
> are lots of folks who don't have control over this. So if you claim this
> check isn't being done for security reasons, then it merely smacks of
> elitism.

No, for order reasons. It might be a feature that the end-user cannot
update the reverse. It tells me things about the hosts that try to connect.
Things I may choose to disregard or not. But I want them. 

> BCP indicating best practices in this area. I'll revive this, either as
> an individual submission or WG item, if folks will actually provide
> constructive input.

I wholeheartedly support this draft. Please do resubmit or hand the token
over if you do not want to yourself.

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 28 Mar 2003 15:22:12 +0100

--On Friday, March 28, 2003 00:19:46 +0900 "JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]>

> terms of the tradeoffs between benefits and disadvantages.

Perhaps. I do not trust the data I get from reverse, not until DNSSEC. But,
I might find it convenient to use for a first judgement -- is this a well
kept host on a good network, regardless of its intentions? 

> version."  You may simply disagree, though.

Sure, it is subjective. And no, I am not trying to point you out. My
apologies it so received. 

>> Therefore, the present techniques will be adaptable to v6, <snip>
> 

Of course. There is also a "legacy cost" associated with keeping the old
system, should we decide to develop a new one. I am aware of that. I think
that the force should be directed in configuration management; to develop
protocols that allow us to autoupdate the present structure, and do so
securely and trustworthy. 

> still some unique characteristics, of course.)

Again, nothing personal. Again, apologies if so received. Now, there are
(and these are the ones I mean) people who try to reform the routing
system, both allocation-wise and in terms of router/host number
relationships, not to mention site-local. I think this is unecessary, and
the one thing we need is more, working addresses. Moore /will/ deal with
some of the non-problems people are trying to solve.

---

From: Måns Nilsson <[email-masked]>
Date: Fri, 28 Mar 2003 15:48:25 +0100

--On Thursday, March 27, 2003 23:56:10 +0900 "JINMEI Tatuya /
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" <[email-masked]>

> useful node name.  But similar arguments apply to DNS reverse mapping

I think you will find *much* more ICMP blocking than DNS blocking. People
are afraid of ICMP but realise that they need DNS to surf the web. 

> that point I think my points is related to his message.

I run a box that has:

11 slave /8
21 master /16
55 slave /16
2 master /32 v6
12 slave /32 or shorter prefixes. 

and it does receive a fair amount of traffic regarding these, though I do
not see the problem. Granted, it is mainly slaves, so they "just work", but
running it is not very hard or resource-consuming.

---

From: Dean Anderson <[email-masked]>
Date: Fri, 28 Mar 2003 11:48:43 -0500 (EST)

> information escape their network?

Yes. Path MTU and other things depend on it.

> Do you bother to monitor the NANOG mailing list?  It seems like every
> week we hear about yet another network that is being stupid and using
> large packet sizes and Path MTU discovery, but are blocking all forms of
> ICMP at their border that would allow PMTUd to actually function
> correctly.

I do. And it seems they don't block ICMP for long. Usually, they block all
ICMP instead of merely ICMP redirects. However, Like I said previously, it
is not compelling that some administrator may make a mistake. It is
compelling that programmers give them no choice.

> 	Please prove this assertion.

Fair enough. There are several suggestions on the table for alternatives.
Both of the possibilities suggested by Jinmei work. I suppose a
demonstration of traceroute could be arranged.  If you are convinced of
the alternatives, will you agree that reverse should be removed from IPV6?

		--Dean