Subject: [DNSOP] KSK-Sentinel -- "Walkin' on the SUN"?

From: Warren Kumari <[email-masked]>
Date: Mon, 14 May 2018 20:10:25 +0200

Dear DNSOP,

The KSK-Sentinel document (
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-12) makes use
of the (leftmost) labels root-key-sentinel-is-ta-<key-tag> and
root-key-sentinel-not-ta-<key-tag>. If a validating recursive resolver sees
these labels, it performs special handling.

Great, everyone is nodding along so far...

Gulp. Now for the question: Is root-key-sentinel-is-ta-<key-tag> an RFC6761
"Special-Use Domain Name"?

The authors are in disagreement - RFC6761 talks about "Special-Use Domain
*Names*", not "Special-Use Domain *Labels*", but Stuart has said that it
wasn't intended to be only for TLDs / pseudo-TLDs / things starting at the
top of the tree.
My view is that this probably is a SUN; it is a name which requires special
handling.
My co-authors (rightly) point out that "name" is poorly defined, this is a
label not a name, RFC6761 is vague in it's use of terminology, and all of
the examples and entries are right-anchored.

We've crafted answers to "the 7 questions" from RFC 6761 below; we don't
care which option the WG selects (we have the text and revisions are free),
but we (and I'm assuming the WG!) desperately don't want this to turn into
another extended discussion on SUN / names vs identifiers vs identities vs
contexts / who has policy control over root / internet governance / etc.

So, please, *clearly* state if you think that this:
A: is a SUN
B: is not a SUN

RFC 8244 [0] was fun, but I'm not sure how much more fun I can handle; we'd
love *clear* guidance by next Friday (May 25th)

'So don't delay, act now, supplies are running out
Allow, if you're still alive, six to eight years to arrive
And if you follow, there may be a tomorrow
But if the offer's shunned
You might as well be walking on the SUN"
     -- Smash Mouth

Note: We are answering the questions as asked, and so use 6761 terminology:
----------------------
IANA Considerations

The IANA is requested to make the following entries in the Special Use
Domain Names registry
(https://www.iana.org/assignments/special-use-domain-names/special-use-
domain-names.xhtml) referencing this RFC

root-key-sentinel-is-ta-<key-tag>.*          RFC XXXX
root-key-sentinel-not-ta-<key-tag>.*         RFC XXXX

Domain Name Reservation Considerations

This refers to the set DNS names where the left-most label matches the
specified patterns.
The answers to the seven questions listed in [RFC6761] are as follows:

1: Users:
Human users are not expected to use or recognize these names as
special, other than those who wish to perform testing of their DNS
resolution environment. It is expected that the majority of the testing
will be performed through automated means (e.g: using JavaScript to
cause the user's browser to trigger a DNS lookup), and so the majority
of users will never see these.

2.  Application Software:
No specified behavior is expected of application software.

3. Name Resolution APIs and Libraries:
   Name resolution libraries are not expected to recognize these names as
   special.

4.  Caching DNS Servers:
   Caching DNS servers which perform DNSSEC validation are
   expected to treat these labels specially, as described in this document.

Caching DNS servers which are NOT performing DNSSEC
validation are not expected to treat these names as special.

5.  Authoritative DNS Servers:
        Authoritative domain name servers are not expected to undertake any
        altered behaviour for these names.

6.  DNS Server Operators:
        These reserved Special-Use Domain Name have no potential impact on
        DNS server operators.

    7.  DNS Registries/Registrars:
        These names have a special behaviour only when used as the left-most
        label in a name resolution query. They have no special significance
        in any other context and are not required to be treated differently
        in the context of registeries and registrars.
------

W

[0]: The Abstract of RFC 8244 says:
"The policy defined in RFC 6761 for IANA registrations in the
"Special-Use Domain Names" registry has been shown, through
experience, to present challenges that were not anticipated when RFC
6761 was written.
...
This document should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of
Special-Use Domain Names."

--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
    ---maf

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 14 May 2018 14:48:03 -0400

It is a random label on the left that some random resolvers may generate
answers for,
thus it is not SUN (i.e. answer B)

Olafur

On Mon, May 14, 2018 at 2:10 PM, Warren Kumari <[email-masked]> wrote:

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

---

From: Paul Wouters <[email-masked]>
Date: Mon, 14 May 2018 14:49:11 -0400 (EDT)

> "Special-Use Domain Name"?

I think not, because it is a label :P

> We've crafted answers to "the 7 questions" from RFC 6761 below; we don't

AFAIK, using 6761 was specifically put on hold, which would mean this process
is not available right now?

Paul

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 May 2018 10:53:26 +0100

> wasn't intended to be only for TLDs / pseudo-TLDs / things starting at the

Hmm. I think that if RFC 6761 were supposed to cover arbitrary labels then
it ought to have said something about localhost as a subdomain.

> So, please, *clearly* state if you think that this:

KSK-sentinel feels like a new kind of thing, but I guess it has a lot in
common with let-localhost-be-localhost. So I think our answer should be
the same for both of them.

My initial reaction was (B), but after I compared with localhost I think
(A) is probably the right answer.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover, East Wight: Northerly 5 or 6. Slight or moderate. Fog
patches. Moderate, occasionally very poor.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 May 2018 12:18:11 -0400

It might be useful to compare this to labels like _tcp that appear in SRV
records and elsewhere.   Those are not listed in the SUDN registry.   I
think that this also doesn't make sense to list there.   It's an
interesting question, of course, but I think we have a precedent that
answers is.

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 15 May 2018 12:25:25 -0400

On 14 May 2018 at 14:10, Warren Kumari <[email-masked]> wrote:

> I think this is not a SUN.

6761 has a lot of opportunity in its text to refer to leftmost labels and
doesn't do that, not even in what could have been fairly obvious examples
(e.g. localhost.*).  Also, the SRV registry is not encapsulated in the SUDN
registry, and that seems to me to be the same issue.

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 May 2018 17:34:58 +0100

Ted Lemon <[email-masked]> wrote:

> records and elsewhere.

The reason for listing a name in the RCF 6761 registry is because it needs
special handling of some kind in DNS software. That isn't the case for the
_underscore names, which (from the DNS point of view) are just ordinary
domain names that have conventional uses in applications.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
promote human rights and open government

---

From: Petr Špaček <[email-masked]>
Date: Tue, 15 May 2018 18:39:16 +0200

On 14.5.2018 20:10, Warren Kumari wrote:
> So, please,*clearly*  state if you think that this:
> A: is a SUN
> B: is not a SUN

B: is not a SUN. In my view special label is different kind of beast 
than SUN.

-- 
Petr Špaček  @  CZ.NIC

---

From: Matthew Pounsett <[email-masked]>
Date: Tue, 15 May 2018 12:39:34 -0400

On 15 May 2018 at 12:34, Tony Finch <[email-masked]> wrote:

> I'm going to suggest a modification to your first sentence.  The reason
for listing a name int he RFC 6761 registry is because it needs special
handling of some kind in DNS software that would otherwise be unaware of
the special handling required by that name.  In this case, the only name
servers that need to handle these names specially are the ones implementing
the technology.. all other name servers treat them as ordinary names.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 May 2018 13:24:42 -0400

Hm, well, the analogy I was making is that this is essentially a signal to
an application, which happens to be a caching name server.  "Other name
servers treat them as ordinary names" is not a reason not to list a
special-use name in the registry.   Ideally we want names like this to have
as small an implementation footprint as possible.   The reason I am
objecting to the idea that this is a special-use name is that it doesn't
seem fundamentally different to _tcp, aside from the detail of what
software happens to consume it.   Special-use names do generally require
special treatment by the system, even though we hope that the footprint
will be as small as possible.   Right now entries in the table are either
not global names (which doesn't apply here) or are intended for special
purposes (e.g., example.com, invalid), or require a protocol other than DNS
to resolve (local, onion).

The case for handling this as a special-use name is that we'd want
implementors of naming software to find it in the registry so that they'd
know to do it, but I don't think that applies here—the downside to not
doing it is that you don't get the new feature, not that something breaks.
  That's very similar to the downside of not knowing what _tcp means.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 May 2018 10:05:39 +1000

Underscore prefix names are entirely user convention the same way as IN-ADDR.ARPA and IP6.ARPA are user convention.  There is NOTHING in resolvers or name servers that treat these names as special in any sort of way what so ever.

gethostbyname and getnameinfo just implement the user convention. 

ksk-sentinel requires validating recursive servers to have different code paths for names that start with these labels.  That makes them special.

As for nothing breaks if you don’t implement, that is true of most/all names in the special use registry to exactly the same extent as not implementing ksk-sentinel doesn’t break anything.

> On 16 May 2018, at 3:24 am, Ted Lemon <[email-masked]> wrote:
> 
> Hm, well, the analogy I was making is that this is essentially a signal to an application, which happens to be a caching name server.  "Other name servers treat them as ordinary names" is not a reason not to list a special-use name in the registry.   Ideally we want names like this to have as small an implementation footprint as possible.   The reason I am objecting to the idea that this is a special-use name is that it doesn't seem fundamentally different to _tcp, aside from the detail of what software happens to consume it.   Special-use names do generally require special treatment by the system, even though we hope that the footprint will be as small as possible.   Right now entries in the table are either not global names (which doesn't apply here) or are intended for special purposes (e.g., example.com, invalid), or require a protocol other than DNS to resolve (local, onion).
> 
> The case for handling this as a special-use name is that we'd want implementors of naming software to find it in the registry so that they'd know to do it, but I don't think that applies here—the downside to not doing it is that you don't get the new feature, not that something breaks.   That's very similar to the downside of not knowing what _tcp means.
> 
> On Tue, May 15, 2018 at 12:39 PM, Matthew Pounsett <[email-masked]> wrote:
> 
> 
> I'm going to suggest a modification to your first sentence.  The reason for listing a name int he RFC 6761 registry is because it needs special handling of some kind in DNS software that would otherwise be unaware of the special handling required by that name.  In this case, the only name servers that need to handle these names specially are the ones implementing the technology.. all other name servers treat them as ordinary names.
> 
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Tue, 15 May 2018 22:58:13 -0700

Mark Andrews wrote:
> Underscore prefix names are entirely user convention the same way as
> IN-ADDR.ARPA and IP6.ARPA are user convention.  There is NOTHING in
> resolvers or name servers that treat these names as special in any
> sort of way what so ever.
>
>...

i think the ability to log warnings or generate errors if A/AAAA owners 
or MX/NS targets are not RFC952-style "hostnames" (that is, if they have 
underscores in them) in BIND8 and BIND9, is a case of treating such 
names as if they are special.

"good? bad? i'm the one with the gun." --ash, in _army of darkness_

-- 
P Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 16 May 2018 11:35:31 +0100

Paul Vixie <[email-masked]> wrote:
>
> i think the ability to log warnings or generate errors if A/AAAA owners or
> MX/NS targets are not RFC952-style "hostnames" (that is, if they have
> underscores in them) in BIND8 and BIND9, is a case of treating such names as
> if they are special.

I think the hostname syntax check is really the other way round: it's
checking that normal names look normal. Underscore isn't special wrt
this check, it's just one of many abnormal cases.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
South Utsire: Northwesterly 6 to gale 8, perhaps severe gale 9 later.
Moderate, becoming rough or very rough. Fair. Good.

---

From: "Peter van Dijk" <[email-masked]>
Date: Thu, 17 May 2018 19:54:01 +0200

Hello Warren,

>    Name resolution libraries are not expected to recognize these names 

Nitpick: what if, for a given user, that is the (only) place where 
DNSSEC validation actually takes place? Perhaps we can blame 6761 for 
this lack of distinction though.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/