At 14:16 21/12/2009, Ted Hardie wrote:
I have not objection to the creation of sink.arpa, but
I will repeat comments I made on the NANOG list
that there are ways of accomplishing the same thing
which do not require the creation of this registry. One
example method would be to create MX records which
point to 257.in-addr.arpa; this address is already
guaranteed not to have any resource records associated
with it by the structure of the reverse tree.
True, but that is an ugly hack :-)
The tricky bit here is, in fact, not the creation of the
record which is guaranteed not to have a resource
record, it is generating good practices for when this
would get used and how. Can I point a CNAME to
sink.arpa, for example? How do I manage the expiration
in that case, given that the negative existence of
sink.arpa is declared to be infinite?
I fail to see your problem, if the CNAME target does not
exist then that results in a failed lookup.
There is no requirement CNAME target MUST exist.
The TTL on the CNAME or the negative cache value for the zone
where the CNAME exists in will dictate the caching of that answer,
(to be more precise the lowest TTL/negative TTL in the chain will control
how long the negative entry can be stored).
The MX case may very well be useful, and I repeat
that I have no objection. But the IESG may want to
consider whether referral to a WG for either the BCP
aspects in relation to mail or the DNS itself is warranted.
Usage cases of sink.arpa and other similar names added to the
registry of special names for arpa should be reviewed by
working groups. We are not proposing any such uses, including
the cute hack "QN=sink.arpa. QT=A QC=IN" as a test
if your resolver is lying to you ;-)
For an actual usage example take a look at draft
On Mon, Dec 21, 2009 at 10:40 AM, The IESG <iesg-secretary(_at_)ietf(_dot_)org>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'The Eternal Non-Existence of SINK.ARPA (and other stories) '
> <draft-jabley-sink-arpa-02.txt> as a BCP
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf(_at_)ietf(_dot_)org mailing lists by 2010-01-18. Exceptionally,
> comments may be sent to iesg(_at_)ietf(_dot_)org instead. In either case,
> retain the beginning of the Subject line to allow automated sorting.
> The file can be obtained via
> IESG discussion can be tracked via
> IETF-Announce mailing list
Ietf mailing list
Ietf mailing list