On Mon, Dec 21, 2009 at 12:16 PM, Olafur Gudmundsson <ogud(_at_)ogud(_dot_)com>
wrote:
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 :-)
Oh, absolutely. And I agree with the idea that documenting
what you are doing is a good thing, whether it is ugly hacking
or populating a registry.
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).
Fair enough. I was worried that sink.arpa might get special
cased in some software, since it is guaranteed never to have
any records. A permanent entry with NXDOMAIN in the local
cache, for example, might have some odd effects. Repeating
in the draft somewhere that this guarantee of non-existance should
not impact caching and expiry processing seems harmless and might be
useful.
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.
Which working groups reviewed the MX and MNAME use cases?
I'll go and read the archives.
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 ;-)
The current version still has the MX and MNAME uses,
in the example section, so it seems to be suggesting them.
If it is not meant to suggest them, then some additional language
suggesting that these still need operational specification would
be useful, at least in my opinion.
For an actual usage example take a look at draft
http://www.ietf.org/id/draft-bellis-dns-recursive-discovery-00.txt
A quick look at that seems to be for .local.arpa, which would be
a different entry. Is there a different draft for MX and MNAME
and sink.arpa?
Thanks for the quick response,
regards,
Ted Hardie
Olafur
Olafur
regards,
Ted Hardie
On Mon, Dec 21, 2009 at 10:40 AM, The IESG
<iesg-secretary(_at_)ietf(_dot_)org>
wrote:
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,
please
retain the beginning of the Subject line to allow automated sorting.
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-jabley-sink-arpa-02.txt
IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18558&rfc_flag=0
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf