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

[Dean Anderson <dean@av8.com>]

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

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

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

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

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

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

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

		--Dean

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