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

[Alain Durand <Alain.Durand@Sun.COM>]

On Wednesday, April 2, 2003, at 02:32  PM, Rob Austein wrote:

> So far we've heard from:
>
> - Ray, who pointed out some RIR-related (specifically, ARIN-related)
>   text that needs some work;
>
> - Måns, who liked the draft and suggested adding text discussing IPv6;
>
> - Dean, who says that we should not be working on this draft.
>
> Does anybody -else- have comments on this draft?  In particular: does
> anybody who has not yet spoken on this have an opinion on whether the
> WG should be working on this?

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

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

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

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

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

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

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

	- Alain.



#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.