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

[Dean Anderson <dean@av8.com>]

I have specific comments:

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

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

Section 1

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

Section 2

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

Section 3

This entire section should be deleted:

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

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

Section 4

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

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

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

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

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

Section 5

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


On Wed, 2 Apr 2003, 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?
>
> Note to anyone who has not figured this out yet: the title of the
> draft is old, does not match the content of the draft as it evolved,
> and most likely would be changed before publication to match the
> current content of the draft.  Please READ THE DRAFT rather than
> jumping to conclusions about what it says based on the title.
>
> #----------------------------------------------------------------------
> # To unsubscribe, send a message to <dnsop-request@cafax.se>.
>


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