On Mon, Dec 21, 2009 at 12:16 PM, Olafur Gudmundsson <ogud@xxxxxxxx> 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@xxxxxxxx> >> 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@xxxxxxxx mailing lists by 2010-01-18. Exceptionally, >> > comments may be sent to iesg@xxxxxxxx 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@xxxxxxxx >> > https://www.ietf.org/mailman/listinfo/ietf-announce >> > >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf