Subject: Re: Last Call: draft-jabley-sink-arpa (The Eternal Non-Existence of SINK.ARPA (and other stories)) to BCP

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Dec 2009 11:16:11 -0800

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.

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?

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.

regards,

Ted Hardie

On Mon, Dec 21, 2009 at 10:40 AM, The IESG <[email-masked]> 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
> [email-masked] mailing lists by 2010-01-18. Exceptionally,
> comments may be sent to [email-masked] 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 Dec 2009 15:16:56 -0500

>with it by the structure of the reverse tree.

True, but that is an ugly hack :-)

>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).

>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
http://www.ietf.org/id/draft-bellis-dns-recursive-discovery-00.txt

         Olafur

         Olafur

>Ietf mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Mon, 21 Dec 2009 12:38:58 -0800

> 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.

> 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.

> 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 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.

> 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

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 Dec 2009 16:00:59 -0500

>not impact caching and expiry processing seems harmless and might be

We will put that on our TODO list for this draft.

>I'll go and read the archives.

None

>be useful, at least in my opinion.

Added to the TODO list for next version.

>a different entry. Is there a different draft for MX and MNAME

not yet, someone that knows e-mail better than me should write that
one, we are only trying to provide tools not specify how to use them.

>Thanks for the quick response,

Thanks for asking the questions.

Olafur

---

From: SM <[email-masked]>
Date: Mon, 21 Dec 2009 14:18:57 -0800

>final comments on this action.  Please send substantive comments to the

The other stories are in Section 3 of this draft. :-)  Please update 
the SMTP protocol reference to RFC 5321.

If I understood the story, it is to get compliant MTAs not to attempt 
mail delivery to domains which do not wish to accept mail.  This does 
not really solve the implicit MX question but that's another story.

Here's some text from Section 5.1 of RFC 5321:

   "If MX records are  present, but none of them are usable, or the
    implicit MX is unusable, this situation MUST be reported as an error."

   "When a domain name associated with an MX RR is looked up and the
    associated data field obtained, the data field of that response MUST
    contain a domain name.  That domain name, when queried, MUST return
    at least one address record (e.g., A or AAAA RR) that gives the IP
    address of the SMTP server to which the message should be directed."

As the intended status of this draft is BCP, it may have to take into 
consideration the above text from RFC 5321 and see how to resolve the issue.

Regards,
-sm

---

From: Bill Manning <[email-masked]>
Date: Mon, 21 Dec 2009 15:51:54 -0800

> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18558&rfc_flag=0

	In the Internet, nothing is eternal.  In the DNS, due to local scoping,
	one can never prove non-existence.  I think this is a bad idea that can
	not ever be rigorously enforced - and its based entirely on the whim of
	the then current zone operator.  I think this is a bad idea.

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Dec 2009 23:57:16 -0500

--On Monday, December 21, 2009 14:18 -0800 SM <[email-masked]>
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
> 
> The other stories are in Section 3 of this draft. :-)  Please
> update the SMTP protocol reference to RFC 5321.
> 
> If I understood the story, it is to get compliant MTAs not to
> attempt mail delivery to domains which do not wish to accept
> mail.  This does not really solve the implicit MX question but
> that's another story.
> 
> As the intended status of this draft is BCP, it may have to
> take into consideration the above text from RFC 5321 and see
> how to resolve the issue.

Let me say this a little more strongly.  This proposal
effectively modifies RFC 5321 for one particular domain name at
the same time that it effectively (see notes by others)
advocates against coding the relevant domain name into anything
or treating it in a special way.  That combination doesn't seem
to me to work.

The issue that SM refers to as "implicit MX" has been hotly
debated in the email community and there was an explicit
decision (albeit with consensus that was fairly rough) to not
change things when RFC 5321 was approved.  If implicit MXs were
prohibited, then this proposal would be unnecessary to
accomplish the desired purposes for email.  If implicit MXs
continue to be permitted, this proposal, as I understand it,
would not work.

It seems to me to be a requirement that proposals that modify
existing standards be reviewed on the mailing list(s) associated
with those standards, preferably before going to IETF Last Call.
This proposal has not been reviewed on, or even exposed to,
those lists, at least with regard to email.

    john

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 22 Dec 2009 00:18:43 -0500

John, SM
do the changes that Ted Hardie asked for address your concern(s)?
see:
http://www.ietf.org/mail-archive/web/ietf/current/msg59759.html

All we want sink-arpa to do is to create a domain name with known
characteristics and create a mechanism to define other such domain
names that may have other characteristics for various applications.

         Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 22 Dec 2009 00:22:01 -0500

Correction the message should have been:
http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html

   Olafur

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Dec 2009 02:14:08 -0500

--On Tuesday, December 22, 2009 00:22 -0500 Olafur Gudmundsson
<[email-masked]> wrote:

>> do the changes that Ted Hardie asked for address your
>> concern(s)? see:

Olafur,

It seems to me that Ted's message asks for more clarity about
what is being specified, actual review by email-related groups
of email-related records and their implications, and so on.
Certainly I agree with those requests and concerns.  Your
response is fine, except I have no idea what is actually going
to get done, and what those reviews will produce, until I see
the results.  And those issues are sweeping enough that I really
wish the Last Call would be terminated and restarted only when
those reviews, and a document that reflects them, is in place.

>From that point of view, I'm objecting less to the content of
this proposal (as far as it goes), but to the fact that the
ducks don't seem to be lined up prior to its going out to IETF
Last Call.  The comments below are more substantive.

>> All we want sink-arpa to do is to create a domain name with
>> known characteristics and create a mechanism to define other
>> such domain names that may have other characteristics for
>> various applications.

But that is, from my perspective, a large part of the problem.
If SINK.ARPA (or its non-existence) is intended to support
various functions, those function should be enumerated and be
well-defined.  By contrast, this document does some handwaving
and includes two specific examples, at least one of which is a
little problematic (and that has not been reviewed by the
relevant community).

I see two other issues that are basically corollaries:

(1) In practice, there are many parts of the Internet today
where various diversion strategies for failed DNS lookups result
in a situation in which NXDOMAIN may not get back to the party
issuing the query, at least absent some special case work.  It
is not clear whether that special case work is harmonious with
the intent of this proposal; part of your response to Ted
suggests that it is not.  Perhaps DNSSEC will solve that
problem.  Perhaps the desire to commercially exploit those
diversions will inhibit the deployment of DNSSEC.  But it seems
to me that the document should at least contain an analysis of
those issues because they may constitute failure cases.

(2) Whether names are allocated or permanently reserved, I think
there are considerable advantages to keeping the logical second
level of .ARPA as small as reasonably possible -- the minimum
number of names that are operationally necessary and no more.
>From that perspective, creating an IANA registry into which one
can easily add names that are logically second-level domains in
.ARPA (even if they are never allocated) would be a mistake.  If
you were confident that exactly one such name were going to be
necessary, then maybe.  But, if you anticipate more such names,
as seems to be the case from the notion of setting up a
registry, then it seems to me that all of the traditional
arguments for hierarchy in the DNS apply and this should be set
up with the expectation, not of 

   sink.arpa.
   sunk.arpa.
   drowned.arpa.
   bitbucket.arpa.
   seriously-fubar.arpa.

etc., but as

   sink.bogus.arpa.
   sunk.bogus.arpa.
   drowned.bogus.arpa.
   bitbucket.bogus.arpa.
   seriously-fubar.bogus.arpa.

and so on.  As with the proposal in the document, the specific
names are not important; the structure is.

     john

---

From: Joe Abley <[email-masked]>
Date: Tue, 22 Dec 2009 11:02:59 +0000

> or treating it in a special way.  That combination doesn't seem

If that's the consensus of SMTP experts, then I would be more than happy to rip that example out (or the whole section, to be honest). I was quite enthusiastic about the previous revision's conscious decision not to include examples at all.

Incidentally, the "other stories" remark in the subject line was a reference to the fact that the document instantiates a registry which can be used by others to document particular characteristics of records in the ARPA zone. It wasn't intended to refer to the examples section (which, as I mentioned, was added only recently).

Joe

---

From: SM <[email-masked]>
Date: Tue, 22 Dec 2009 03:33:14 -0800

Hi Olafur,
>http://www.ietf.org/mail-archive/web/ietf/current/msg59761.html

The changes that Ted Hardie asked for does not address my concern as 
my comment was about the example in Section 3:

   "Installing an MX record whose RDATA includes SINK.ARPA in the
    EXCHANGE field ([RFC1034]) should cause compliant MTAs to make
    no connection: SINK.ARPA does not exist, and A and AAAA records
    should not be used when an MX record is present."

I am aware of the operational angle and that the above has been on 
the SMTP shopping list for some time.  I am not sure whether it 
solves the problem instead of the symptom.  I won't suggest an 
informative reference to RFC 1882. :-)

If SMTP is to be the topical example, you may wish to get the draft 
reviewed by a mail-related working group.  The shortest path would be 
to drop the first example.

This draft requires IAB review and approval.  The following paragraph 
may require some scrutiny:

      "INVALID is poorly characterised from a DNS perspective in
       [RFC2606]; that is, the specification that INVALID does not exist
       as a Top Level Domain (TLD) is imprecise given the various uses of
       the term TLD in policy forums;"

Section 5.1 is quite a change compared to what is in Section 2.1 of 
RFC 3172.  The existing text says:

   'The "arpa" sub-domains are used for those protocol object sets
    defined as part of the Internet Standards Process [4], and are
    recommended to be managed as infrastructure protocol objects.'

This proposal turns it into a registry of ARPA Reserved Names where 
the registration procedure is "IETF Standards Action and IAB 
approval".  Unless I missed something, there is a lack of clarity 
about what "arpa" sub-domains will be used for in future.

Regards,
-sm

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Dec 2009 13:50:17 +0000

On Mon, 21 Dec 2009, SM wrote:
>
> If I understood the story, it is to get compliant MTAs not to attempt mail
> delivery to domains which do not wish to accept mail.  This does not really
> solve the implicit MX question but that's another story.

The idea of using sink.arpa as an MX target (like the null MX proposal) is
to define a conventional form of MX record that indicates a domain is not
a valid mail domain. It solves the implicit MX problem for sites that use
it, but obviously not for sites that don't. It's much cheaper to deploy
than RFC 1864 (which specifies the SMTP 521 initial greeting).

> Here's some text from Section 5.1 of RFC 5321: [snip]
>

What issue? As far as I can tell there's no conflict between Joe's draft
and RFC 5321, except that the choice of words in the example needs
improvement.

In particular, this sentence:
                                                  Installing an MX
       record whose RDATA includes SINK.ARPA in the EXCHANGE field
       ([RFC1034]) should cause compliant MTAs to make no connection:
       SINK.ARPA does not exist, and A and AAAA records should not be
       used when an MX record is present.

ought to be written:
                                                  Installing an MX
       record whose RDATA includes SINK.ARPA in the EXCHANGE field
       ([RFC1035]) shall cause compliant MTAs to make no connection:
       SINK.ARPA does not exist, and A and AAAA records shall not be
       used when an MX record is present.

so that it agrees with the strength of the RFC 2119 mustard in RFC 5321.
Also the reference to RFC 1034 should be a reference to RFC 1035 since
that is where the EXCHANGE field is specified.

Note that any MX target domain name with no A or AAAA RRs will do the same
job as sink.arpa or . (the dns root as proposed in the null MX draft); the
advantage of a conventional name is that MTAs can skip the target address
lookups since they already know the MX is unusable..

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Joe Abley <[email-masked]>
Date: Tue, 22 Dec 2009 14:23:15 +0000

On 2009-12-22, at 11:33, SM wrote:

> This draft requires IAB review and approval.

You'll note that we asked for it in section 6. 

>  The following paragraph may require some scrutiny:
> 
> Section 5.1 is quite a change compared to what is in Section 2.1 of RFC 3172.  The existing text says:
> 
> This proposal turns it into a registry of ARPA Reserved Names where the registration procedure is "IETF Standards Action and IAB approval".  Unless I missed something, there is a lack of clarity about what "arpa" sub-domains will be used for in future.

The goal was to provide a set of additional requirements that the IAB would take into consideration when carrying out the duties as described in 3172. For example, some far future IAB might overlook that one obscure document amongst the 50,000 that exist specifies that SINK.ARPA should not exist, if that was the only place it was documented.

The proposed IANA registry would be useful for such a future IAB in that it would list all the names that required special attention, together with a reference in each case to the document that described it.

My reading of the text is consistent with the goal as described above. I would not object to further clarifying the goal by spelling out that the special criteria found via the new proposed registry do not trump the opinion of the IAB (i.e. the IAB can still say no, even if the criteria are all met).

Joe

---

From: Ted Hardie <[email-masked]>
Date: Tue, 22 Dec 2009 08:55:52 -0800

> Last Call.  The comments below are more substantive.

Hi John,

My take on this is that this idea is worth exploring, and this document
can take us down the right road for that by adding the caching clarification
and removing the examples.  Removing the apparent force of the examples by
clarifying that they indicate potential future lines of exploration rather than
worked updates to the relevant standards also works for me.  If we
want to explore
the idea in a .bogus.arpa subdomain rather than using sink.arpa, I
don't think that's
a big deal one way or the other.

The real question for me is how do we get off the chicken-and-egg problem?
If we have no document specifying the behavior of a guaranteed non-existent
name, it is hard to get much actual deployment and experience, and I think
that's what is required here.  We may well find that this works in some contexts
and fails utterly in others, based on the silly domain name tricks pulled on
a per-application basis.  But we can't find that out easily without an agreed
upon way of trying this.

Maybe that makes this an experiment; maybe it makes it a likely-to-be-ephemeral
best current practice.  But it does get the egg hatched, and that seems to be
useful to me.

regards,

Ted Hardie

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Dec 2009 17:19:29 +0000

On Mon, 21 Dec 2009, John C Klensin wrote:
>
> If implicit MXs continue to be permitted, this proposal, as I understand
> it, would not work.

I believe it will work. RFC 5321 explains it twice:

   If an empty list of MXs is returned, the address is treated as if it
   was associated with an implicit MX RR, with a preference of 0, pointing
   to that host. If MX records are present, but none of them are usable,
   or the implicit MX is unusable, this situation MUST be reported as an
   error.

   If one or more MX RRs are found for a given name, SMTP systems MUST
   NOT utilize any address RRs associated with that name unless they are
   located using the MX RRs; the "implicit MX" rule above applies only
   if there are no MX records present.  If MX records are present, but
   none of them are usable, this situation MUST be reported as an error.

Tony.

---

From: SM <[email-masked]>
Date: Tue, 22 Dec 2009 10:32:32 -0800

>and RFC 5321, except that the choice of words in the example needs

The wording in the draft is at odds with what is in RFC 5321.  This 
can be discussed in the relevant working group.

>You'll note that we asked for it in section 6.

Yes.

>The goal was to provide a set of additional requirements that the 
>IAB would take into consideration when carrying out the duties as 
>described in 3172. For example, some far future IAB might overlook 
>that one obscure document amongst the 50,000 that exist specifies 
>that SINK.ARPA should not exist, if that was the only place it was documented.
>
>The proposed IANA registry would be useful for such a future IAB in 
>that it would list all the names that required special attention, 
>together with a reference in each case to the document that described it.

If that is the goal, the draft would have to register all the "arpa" 
sub-domains.

>My reading of the text is consistent with the goal as described 
>above. I would not object to further clarifying the goal by spelling 
>out that the special criteria found via the new proposed registry do 
>not trump the opinion of the IAB (i.e. the IAB can still say no, 
>even if the criteria are all met).

The procedures for registration are documented in Section 2.1 and 
Section 3.0 of RFC 3172.  You could reference those sections instead 
of having Section 5.0 and Section 5.1.

The main parts of this draft are about the eternal non-existence of 
sink.arpa.  If the examples are removed, there isn't any text that 
explains the operational utility.  I am not arguing for keeping the 
examples.  The operational utility could be addressed by a project 
similar to AS112.

Regards,
-sm

---

From: Tony Finch <[email-masked]>
Date: Tue, 22 Dec 2009 18:40:40 +0000

On Tue, 22 Dec 2009, SM wrote:
> The wording in the draft is at odds with what is in RFC 5321.  This can be
> discussed in the relevant working group.

Which wording? Which working group?

Tony.

---

From: Joe Abley <[email-masked]>
Date: Tue, 22 Dec 2009 19:05:04 +0000

On 2009-12-22, at 18:32, SM wrote:

> If that is the goal, the draft would have to register all the "arpa" sub-domains.

Why?

> The procedures for registration are documented in Section 2.1 and Section 3.0 of RFC 3172.

Section 2.1 and 3.0 deal with delegations.

> You could reference those sections instead of having Section 5.0 and Section 5.1.

Not really, since the goal is to provide a framework for inserting other records into the ARPA zone apart from those associated with delegations.

> The main parts of this draft are about the eternal non-existence of sink.arpa.  If the examples are removed, there isn't any text that explains the operational utility.  I am not arguing for keeping the examples.  The operational utility could be addressed by a project similar to AS112.

The purposes of the document under review is described fairly succinctly in section 1:

   1.  to create a new IANA registry called "ARPA Reserved Names" (see
       Section 4);

   2.  to define the special considerations of a single name SINK.ARPA,
       a name which is defined never to exist (see Section 2);

   3.  to allow the procedures by which the ARPA zone is maintained, as
       documented in [RFC3172], to be modified for names present in the
       ARPA Reserved Names registry according to the special
       characteristics of those names (see Section 5).

Which of those three purposes are you suggesting the AS112 project could help with?

Joe

---

From: SM <[email-masked]>
Date: Tue, 22 Dec 2009 14:34:08 -0800

>Why?

Some future IAB would have a list of names and the appropriate reference.

>Which of those three purposes are you suggesting the AS112 project 

None of the above.  I said "The operational utility could be 
addressed by a project similar to AS112" [1].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/ietf/current/msg59778.html

---

From: John C Klensin <[email-masked]>
Date: Wed, 23 Dec 2009 02:33:12 -0500

--On Tuesday, December 22, 2009 08:55 -0800 Ted Hardie
<[email-masked]> wrote:

>...
> Hi John,
> 
> My take on this is that this idea is worth exploring, and this
> document can take us down the right road for that by adding
> the caching clarification and removing the examples.  Removing
> the apparent force of the examples by clarifying that they
> indicate potential future lines of exploration rather than
> worked updates to the relevant standards also works for me.

Agreed.

> If we want to explore
> the idea in a .bogus.arpa subdomain rather than using
> sink.arpa, I don't think that's a big deal one way or the
other.

I guess the issue for me is that I want to see either 

	(i) Exactly one name allocated, with no hand waving
	about registries and other, similar names.  In other
	words, if someone later wants another
	allocated-but-not-delegated name, they go through
	exactly the same process as for this one, with the added
	obligation of having to justify "another one" to the
	community.
	
	(ii) A subtree delegation and setup, with a registry,
	but with the entries in that registry applying at the
	third level (e.g., sink.bogus.arpa.) and not as
	immediate subdomains of .ARPA.
 
> The real question for me is how do we get off the
> chicken-and-egg problem? If we have no document specifying the
> behavior of a guaranteed non-existent name, it is hard to get
> much actual deployment and experience, and I think that's what
> is required here.  We may well find that this works in some
> contexts and fails utterly in others, based on the silly
> domain name tricks pulled on a per-application basis.  But we
> can't find that out easily without an agreed upon way of
> trying this.
> 
> Maybe that makes this an experiment; maybe it makes it a
> likely-to-be-ephemeral best current practice.  But it does get
> the egg hatched, and that seems to be useful to me.

I'm ok with this, but it seems to me that the document now does
two things.  One is to set up the experiment (or possibly
long-term arrangement) that you describe above.  Another is to
set up a registry that would make little sense unless it had
multiple names in it and a mechanism for populating that
registry.  I'd like to either separate the two, move the
registry down a level in the DNS, or both.

    john

---

From: Alan Barrett <[email-masked]>
Date: Wed, 23 Dec 2009 13:19:27 +0200

>    <draft-jabley-sink-arpa-02.txt> as a BCP

I would like to see a requirement (or at least a recommendation)
that DNS or application software must/should not have any special
knowledge of the fact that SINK.ARPA does not exist; they should
discover its nonexistence when and if they try to follow a reference
to the name, in the same way that they discover the nonexistence
of any other domain names.

In the examples, I would like to see reinforcement of the above
principle.  For example, the "should" in "Installing an MX record
...  should cause compliant MTAs to ..." is a prediction about the
behaviour of compliant MTAs when encountering *any* nonexistent
domain name; it is not a requirement for special treatment of the
SINK.ARPA name, but some people might interpret the exmple as a
requirement for special treatment.

I don't like the name SINK much; calling something a sink implies
that traffic can be sent to it, and that such traffic will be read
and discarded, but that's not what's going on here.  I prefer
NONEXISTENT.ARPA or some variation on that theme.

--apb (Alan Barrett)

---

From: John Levine <[email-masked]>
Date: 23 Dec 2009 14:34:08 -0000

If it's a good idea to have a registry of DNS names with special
meanings, I'd rather see one RFC that establishes and populates
a registry of them, perhaps as an update to RFC 2606.

Such a registry might also usefully include names that have special
meanings within DNS names such as _<service> from 2782 and _domainkey
from 4871.

At this point I'm agnostic about the utility of adding SINK.ARPA to
such a registry, since I don't know how much in practice the "helpful"
rewriting of NXDOMAIN by some caches would interfere with its use.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 25 Dec 2009 12:02:07 +0100

John C Klensin writes:
>         about registries and other, similar names.

+1, but I want to add a question: What is the actual difference between 
the proposed sink.arpa and the existing .invalid?

Arnt

---

From: Joe Abley <[email-masked]>
Date: Sun, 27 Dec 2009 11:14:48 -0500

On 2009-12-25, at 06:02, Arnt Gulbrandsen wrote:

> What is the actual difference between the proposed sink.arpa and the existing .invalid?

(a) Our idea when we chose that name was to try and make the policy environment within which the (non-) assignment rule was to be instituted clear. The administration of ARPA is fairly clearly defined, and lies fairly clearly within the policy control of the IETF and the IAB. The administration of the root zone has a far greater audience of participation, and is hence more likely to be subject to future change. Naming the (non-existent) name under ARPA avoided this potential headache.

(b) SINK.ARPA is a hostname whereas INVALID is not, according to certain interpretations of (I think) RFC 952. (I think I last saw reference to this when Mark Andrews was discussing potential problems with apex MX records in TLD zones, in the context of discussing expansion of the root zone). This perhaps makes INVALID less appropriate for applications where a non-existent hostname is required.

Joe

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 27 Dec 2009 19:07:40 +0100

Joe Abley writes:
> (a) Our idea when we chose that name was to try and make the policy 
> environment within which the (non-) assignment rule was to be 
> instituted clear. The administration of ARPA is fairly clearly 
> defined, and lies fairly clearly within the policy control of the 
> IETF and the IAB. The administration of the root zone has a far 
> greater audience of participation, and is hence more likely to be 
> subject to future change. Naming the (non-existent) name under ARPA 
> avoided this potential headache.

I don't get it. Are you saying that you think it's possible that someone 
will come along and overturn RFC 2606, and that that someone wouldn't 
overturn any .arpa-related rules?

> (b) SINK.ARPA is a hostname whereas INVALID is not,

This is a strawman; every subdomain of .invalid, so 2606 provides 
something like 36^254 invalid hostnames.

Arnt

---

From: Joe Abley <[email-masked]>
Date: Sun, 27 Dec 2009 18:46:32 -0500

On 2009-12-27, at 13:07, Arnt Gulbrandsen wrote:

> I don't get it. Are you saying that you think it's possible that someone will come along and overturn RFC 2606, and that that someone wouldn't overturn any .arpa-related rules?

I'm saying that the body that administers the root zone is not the IETF. Not being a policy person I don't have any specific fears, but I'll observe that the set of people who make policy that affects administration of the root zone has a fairly small intersection with the set of people who participate in the IETF.

> This is a strawman; every subdomain of .invalid, so 2606 provides something like 36^254 invalid hostnames.

OK, so in response to your third question of whether there's a difference in use between SINK.ARPA and LABEL-SET-OF-YOUR-CHOICE.INVALID, the difference is that the NXDOMAIN responses for those names come from root servers, and not from ARPA servers.

I appreciate that the set of ARPA servers and the set of root servers today are very nearly the same, but it is a difference.

Joe

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 28 Dec 2009 11:18:44 +0100

Joe Abley writes:
> I'm saying that the body that administers the root zone is not the 
> IETF. Not being a policy person I don't have any specific fears, but 
> I'll observe that the set of people who make policy that affects 
> administration of the root zone has a fairly small intersection with 
> the set of people who participate in the IETF.

Yes. Which is a reason, but IMO not a sufficient one. Your judgment 
obviously differs.

> I appreciate that the set of ARPA servers and the set of root servers 
> today are very nearly the same, but it is a difference.

Yes.

Arnt