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

[Daniel Senie <dts@senie.com>]

At 06:13 PM 4/10/2003, you wrote:
>The draft is a bad draft. First of all, from a strictly editorial 
>standpoint, there is much
>language in it which appears on the surface to be normative, but it is far 
>from clear
>whether it is intended as such. I am referring to the lowercase "must"s 
>and the "are
>permitted" language.

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


>But, more fundamentally, the draft basically comes off as saying "it's a 
>bad idea to rely on
>X, but you have to (or _should_, see my above comment about 
>pseudo-normative language) do X
>anyway", where X is, of course, "maintain reverse records". What's the 
>point of this?

The point is to:

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

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


>  Either
>it's a bad idea to use reverse records, for security/auditing/logging 
>purposes, or it is
>not. If it's a bad idea, we shouldn't be recommending that the practice be 
>continued.

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

>  If
>it's *not* a bad idea, then it should be explained not only why it's a 
>good idea, but
>specifically how the benefits outweigh the costs (false positives, etc.) 
>of doing it.

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


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