Subject: Re: [DNSOP] A conversational description of sentinel.

From: Geoff Huston <[email-masked]>
Date: Fri, 2 Feb 2018 07:20:45 +1100

> On 26 Jan 2018, at 3:17 am, Paul Hoffman <[email-masked]> wrote:
> 
> On 25 Jan 2018, at 7:36, Warren Kumari wrote:
> 
>> On Thu, Jan 25, 2018 at 10:10 AM, Tony Finch <[email-masked]> wrote:
>>> Isn't this going to cause problems with software that checks hostname
>>> syntax?
> 
> Yes. However, that software will only be on the authoritative server side, yes? If you're a researcher who wants to run a sentinel test, you can use authoritative server software that doesn't block that. For example, I'm pretty sure Geoff's software either does not block that or could be tweaked easily to not block.
> 
>>> Wouldn't it be better to use something like a double hyphen to avoid
>>> collisions?
>> 
>> Possibly, or using CNAMES. I (personally) liked the underscores as it
>> separated this from the rest of the namespace, but the double hyphen
>> also sounds like an interesting idea.
>> What does the WG think?
> 
> Sentinel would be the first example of label-based special cases in resolver software. The special-case labels can be anything that would not ordinarily appear at the left. Using dcyen28c5wxcf95fcsxceexwwe1z-ta-12345.example.com works just as well, and would probably cause fewer implementers to make bad assumptions about the future. Underscores are already used for preventing those assumptions, but any unused string works.

the draft’s authors have discussed this, and it appears prudent to stick to the hostname syntax for this label.

What about if the sentinel spec proposes to use a left-most label of the form(s):

    xm—-is-ta-[key]

and

   xm—-not-ta-[key]

would this form of hostname be a reasonable way forward?

 Geoff

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 15:52:34 -0500

> would this form of hostname be a reasonable way forward?

Only if you want to create an IANA registry of labels with two
ASCII-letter-range octets followed by two hyphen-minus characters.
One of the IDNA documents reserves everything of that form, alas.

This registry business might be a good tidying effort anyway, though,
so I'm not opposed.  Just noting that it's work that would be needed.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 01 Feb 2018 12:56:51 -0800

> would this form of hostname be a reasonable way forward?

This was discussed in a different thread in the WG a few days ago, and a 
few of us had objections and alternate proposals.

--Paul Hoffman

---

From: Geoff Huston <[email-masked]>
Date: Fri, 2 Feb 2018 11:48:18 +1100

> On 2 Feb 2018, at 7:56 am, Paul Hoffman <[email-masked]> wrote:
> 
> This was discussed in a different thread in the WG a few days ago, and a few of us had objections and alternate proposals.

I’ve reviewed the (lengthening) thread on this draft, but while I saw posted objections to the use of “xm—" as the initial part of the left-most label here, I did not see any concrete alternate proposals. So on the assumption that I must’ve missed these, could you please resend/remind me of such proposals so that we can use one that we are happy with, and I’ll update the draft accordingly.

thanks,
  Geoff

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Feb 2018 16:52:34 -0800

rather than a conversational description, could someone perhaps produce 
a flow chart or pascal-style flow diagram of each actor's decision tree?

i am lost.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 01 Feb 2018 17:10:37 -0800

On 1 Feb 2018, at 16:48, Geoff Huston wrote:

> I’ve reviewed the (lengthening) thread on this draft, but while I 
> saw posted objections to the use of “xm—" as the initial part of 
> the left-most label here, I did not see any concrete alternate 
> proposals. So on the assumption that I must’ve missed these, could 
> you please resend/remind me of such proposals so that we can use one 
> that we are happy with, and I’ll update the draft accordingly.

The two that were discussed were:

1) No update needed: _is-ta-<tag-index> and _not-ta-<tag-index> are 
fine. The problem that Warren reported of BIND not allowing the 
underscore is easily fixed in BIND's configuration.

2) Some prefix other than <letter><letter><hyphen><hyphen> because of 
RFC 5891.

My preference is #1 because, in general, a label starting with _ has 
been meant for infrastructure, and that's what these labels are. Others 
might like #2 so they don't have to add configuration to BIND (and maybe 
other authoritative servers).

--Paul Hoffman

---

From: "A. Schulze" <[email-masked]>
Date: Fri, 02 Feb 2018 07:55:30 +0100

Paul Hoffman:

> been meant for infrastructure, and that's what these labels are.  
> Others might like #2 so they don't have to add configuration to BIND  
> (and maybe other authoritative servers).

just checked, my NSD and POWERDNS serve A record for _foo.examle.  
without noise...
so: #1

Andreas

---

From: Petr Špaček <[email-masked]>
Date: Fri, 2 Feb 2018 08:50:32 +0100

> just checked, my NSD and POWERDNS serve A record for _foo.examle.

For the record, I also like more the underscore variant (#1 above).

BIND spits a warning about it and I like it. After all, this whole KSK
sentinel bussiness is quite specialized thing to do and should be done
only by people who know what they are doing, so warning is appropriate.

After all, what is your guess about number of zones containing such
names? 10? 20 zones globally? I cannot see more, and most likely vast
majority of people who would like to create such zones is following this
dicussion.

Please do not overcomplicate things. The technology seems okay to me.
(I've implemented it including tests, see Knot Resolver 2.0.0.)
Could we polish the text and publish it, pretty please?

(BTW I have seen underscore names with A records in Microsoft Active
Direcotry DNS years ago, so this is not the first time _ A is used.)

-- 
Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Fri, 2 Feb 2018 19:32:37 +1100

This isn’t about whether name servers load A records with non LDH names
as they all can.

The real question is do the name lookup api’s in the web browsers barf
on non IDN, non LDH names since that is the mechanism being proposed
for people to test this.

Mark

> On 2 Feb 2018, at 6:50 pm, Petr Špaček <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Ray Bellis <[email-masked]>
Date: Fri, 2 Feb 2018 09:24:33 +0000

> on non IDN, non LDH names since that is the mechanism being proposed

+1 - that's my concern too.

The browsers that refuse to accept an underscore label might only be a
small portion of the possible clients in Geoff's experiments, but it's
an outcome that should be allowed for so as to prevent false readings.

Ray

---

From: Petr Špaček <[email-masked]>
Date: Fri, 2 Feb 2018 10:41:43 +0100

> on non IDN, non LDH names since that is the mechanism being proposed

Sure. Given that MS AD users underscore A records in its integrated DNS
server (at least in older versions), it is going to work with DNS
resolver distributed with Windows. This covers 99 % of clients which can
potentially be target of potential ad campaign.

So, now, we need to test browsers...

Talk is cheap, let's get hands dirty!

I just tested Firefox 58.0.1 on Fedora 27
URL http://_test.example

Result: The Firefox under test issued DNS queries
_test.example. A
_test.example. AAAA
just fine.

nsswitch.conf:
hosts:      files mdns4_minimal [NOTFOUND=return] dns myhostnam

I do not have other desktop system at hand, so I will defer other
experiments to others.

Please do experiments and report your results.
Petr Špaček  @  CZ.NIC

---

From: Warren Kumari <[email-masked]>
Date: Fri, 2 Feb 2018 10:45:28 -0500

> So, now, we need to test browsers...

For those who would like to test this, while not having to get their
hands quite as dirty, I've added:
_www     IN CNAME ron.kumari.net
xm--www   IN A 204.194.23.4
to ksk-test.net, and have updated the JavaScript to test these as well.

On Chome and Safari on both OS X and IOS I get:
These below 2 tests are just for debugging / to understand browser
behavior. You:
were able to fetch the "underscore" record
were able to fetch the "dashdash" record

Surprisingly, on Chrome on Android and Samsung Internet (the browser
on Samsung Galaxy Note devices) I get:
These below 2 tests are just for debugging / to understand browser
behavior. You:
were **NOT** able to fetch the "underscore" record
were able to fetch the "dashdash" record

I must admit that I was not expecting this - can others please also test this?

I personally don't really care what the labels are -- we could make it
I-Heart-KennyG-is-ta-[foo] for all I care[0].

W
[0]: Note: anyone who suggests a: an emoticon or b: some cute unicode
hack is dead to me.

-- 
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: Petr Špaček <[email-masked]>
Date: Sun, 4 Feb 2018 23:35:27 +0100

> I must admit that I was not expecting this - can others please also test this?
Huh, this totally surprised me, but yeah, data trumphs any intuition here.

> I-Heart-KennyG-is-ta-[foo] for all I care[0].

Now when I see that this kind of problems is real, it is probably the
right time to ask Geoff to use his tools and get some data from large
scale measurement...

Underscore is now out of the question because we know about the
Android/Chrome problem se might test alternative labels.

??-- variant is out of question because it goest against
https://tools.ietf.org/html/rfc5891#section-5.4

So, to have something realistic and testable, I propse to use strings:

test-name-rfcXXXX-dnssec-root-trust-anchor-key-trusted-yes-0000
(63 octets, unlikely to colide with anything, self-explanatory)
test-name-rfcXXXX-dnssec-root-trust-anchor-key-trusted-no-0000
(62 octets)

Opinions?

Geoff, is it realistic to test that clients are able to resolve A
records containing these leftmost labels?

Petr Špaček  @  CZ.NIC

---

From: Geoff Huston <[email-masked]>
Date: Mon, 5 Feb 2018 10:05:15 +1100

> records containing these leftmost labels?

It is an interesting question, and one we should probably measure.

My outstanding question is to Paul Hoffman (and anyone else who caress):
if not  underscores and IF “xm—“ as a leading substring is not acceptable for 
some reason, then what label format would be acceptable for this 
measure?

thanks

  Geoff

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 5 Feb 2018 12:56:47 +0100

> were able to fetch the "dashdash" record

Current Firefox 58.0.1 and old Chromium 61.0.3163.79, Linux, same
result.  The system resolver does fetch _www.ksk-test.net. OK.  (I can't
say I understand what happens.)

--Vladimir

---

From: Ray Bellis <[email-masked]>
Date: Mon, 5 Feb 2018 12:22:50 +0000

> Android/Chrome problem se might test alternative labels.

I don't think that's necessarily true.

It may just mean that there's an additional set of possible responses
that the draft needs to consider, and that anyone performing such tests
would need to disregard from their analysis.

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Feb 2018 12:47:11 +0000

> some reason, then what label format would be acceptable for this

Maybe put the -- in the middle somewhere? e.g. is-ta--NNNN not-ta--NNNN

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
East Sole, Lundy, Fastnet: Northeasterly 4 or 5, backing northerly 6 to gale 8
later. Moderate or rough, becoming very rough later in west. Rain or sleet
later. Good, occasionally poor later.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 6 Feb 2018 06:18:07 +1100

> On 5 Feb 2018, at 11:47 pm, Tony Finch <[email-masked]> wrote:
> 
> Maybe put the -- in the middle somewhere? e.g. is-ta--NNNN not-ta—NNNN
> 

I thought this was due to some concern over the wording in RFC <mumble>(some IDN
RFC whose number I can’t recall right now!) over a comment that the UC label 
should not contain the starting sequence "<letter> <letter> - -”

Is there a broader concern over the use of double hypens in labels in hostname
contexts in the DNS?

geoff

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 05 Feb 2018 18:21:07 -0800

> Is there a broader concern over the use of double hypens in labels in 

Not from me. I think Tony's idea is likely fine, but I also think 
kskroll-sentinel-is-ta-NNNN is perfectly fine as well.

--Paul

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 06 Feb 2018 09:42:15 +0100

Paul Hoffman:

> I think Tony's idea is likely fine, but I also think  

Yes, "kskroll-sentinel-is-ta-NNNN" is more descriptive and specific.
I also prefer that longer variant.

Andreas

---

From: Tony Finch <[email-masked]>
Date: Tue, 6 Feb 2018 12:22:40 +0000

> I also prefer that longer variant.

Yes, more friendly for web searches if someone is wondering about weird
queries.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Northerly 5 to 7, occasionally gale 8 at first in south, backing
westerly 4 or 5 later. Slight or moderate, occasionally rough at first. Wintry
showers. Good, occasionally poor.

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 6 Feb 2018 09:39:45 -0500

> should not contain the starting sequence "<letter> <letter> - -”

RFC5890 point 2.3.1

   To facilitate clear description, two new subsets of LDH labels are
   created by the introduction of IDNA.  These are called Reserved LDH
   labels (R-LDH labels) and Non-Reserved LDH labels (NR-LDH labels).
   Reserved LDH labels, known as "tagged domain names" in some other
   contexts, have the property that they contain "--" in the third and
   fourth characters but which otherwise conform to LDH label rules.
   Only a subset of the R-LDH labels can be used in IDNA-aware
   applications.  That subset consists of the class of labels that begin
   with the prefix "xn--" (case independent), but otherwise conform to
   the rules for LDH labels.

And also:

Labels within the class of R-LDH labels that are not prefixed with
   "xn--" are also not valid IDNA labels.  To allow for future use of
   mechanisms similar to IDNA, those labels MUST NOT be processed as
   ordinary LDH labels by IDNA-conforming programs and SHOULD NOT be
   mixed with IDNA labels in the same zone.

   These distinctions among possible LDH labels are only of significance
   for software that is IDNA-aware or for future extensions that use
   extensions based on the same "prefix and encoding" model.  For
   IDNA-aware systems, the valid label types are: A-labels, U-labels,
   and NR-LDH labels.

> Is there a broader concern over the use of double hypens in labels in hostname

Double hyphens anywhere that is ok, but at position 3 and 4 it will be a
problem for many registries.

ICANN contract with registries, Specification 6 ("Registry
Interoperability and Continuity Specifications") point 1.1 says:
DNS labels may only include hyphens in the
third and fourth position if they represent valid IDNs (as specified
above) in their ASCII encoding (e.g., “xn--ndk061n”).
</quote>

Many ccTLDs have the same restriction.

-- 
Patrick Mevzek

---

From: Petr Špaček <[email-masked]>
Date: Tue, 6 Feb 2018 17:04:45 +0100

> Yes, more friendly for web searches if someone is wondering about weird

Bonus points if we can get a number reserved by RFC editor, it would
allow us to use name like
test-rfc0000-is-ta-NNNN
test-rfc0000-not-ta-NNNN

That would be super awesome.

Is something like RFC number pre-allocation possible?

-- 
Petr Špaček  @  CZ.NIC

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 06 Feb 2018 08:13:55 -0800

> That would be super awesome.

...and super-unlikely, given the history of the RFC Series.

> Is something like RFC number pre-allocation possible?

Sometimes (rarely), after Working Group Last Call. That's why I 
suggested "kskroll-sentinel" since those words are in the WG draft name, 
and will probably appear in the IETF Datatracker forever.

--Paul Hoffman

---

From: joel jaeggli <[email-masked]>
Date: Tue, 6 Feb 2018 08:21:54 -0800

>> Is something like RFC number pre-allocation possible?
Not really, nor is specifying them. Allocation is the domain of the RFC
editor and occurs once they enter the editor queue. until then they're
just internet drafts.
 
Naming something properly can with specific instructions be done at the
time of editing. as for example is done with IANA instructions,
references and so on... That's pretty much the opposite of early allocation.
> suggested "kskroll-sentinel" since those words are in the WG draft
> name, and will probably appear in the IETF Datatracker forever.
>
> --Paul Hoffman
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 6 Feb 2018 11:31:39 -0500

> Is something like RFC number pre-allocation possible?

You can include instructions to the RFC editor to replace some token in the document by the assigned RFC number. I've done this before in IANA Considerations sections where it is necessary to specify a reference; I've included something like "<this document>" in a table and specified in a note to be removed before publication that that text be replaced by the RFC number.

This seems perfectly possible for this document, but it doesn't help early implementers, and presumably runs the risk of having resolvers deployed that handle different magic sentinel labels depending on when they were released (unless, perhaps, the resolver handling is based on a pattern and not a specific label that has to be matched exactly).

Some other RFC numbers were clearly reserved for specific documents in the past (e.g. see RFC 2821/2, obsoleting RFC 821/2) but perhaps those were special cases.

Joe

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 06 Feb 2018 09:02:28 -0800

On 6 Feb 2018, at 8:31, Joe Abley wrote:

> Some other RFC numbers were clearly reserved for specific documents in 
> the past (e.g. see RFC 2821/2, obsoleting RFC 821/2) but perhaps those 
> were special cases.

It was special, and very much regretted by the RFC Editor at the time. 
This badly screwed up the numbering at the time because 2821/2822 ended 
up being over a year late.

--Paul Hoffman

---

From: Petr Špaček <[email-masked]>
Date: Wed, 7 Feb 2018 08:15:35 +0100

> and will probably appear in the IETF Datatracker forever.

Fine. Now we need to have something actionable, e.g. set of names for
Geoff to test.

Can we have couple proposals and test them in one go, so results are
comparable?

I've gathered these:

kskroll-sentinel-is-ta-NNNN
kskroll-sentinel-not-ta-NNNN
is-ta--NNNN
not-ta--NNNN

I propose longer but more descriptive variant:
kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN
kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-no-NNNN

(I imagine that real meaning of name "kskroll-sentinel" will be known by
dozen people but hunders or thousands people will encounter it in
tcpdump, so why not make life easier for them. It costs almost nothing...)

Do we have other proposals?

-- 
Petr Špaček  @  CZ.NIC

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Feb 2018 03:57:36 -0500

---

From: Warren Kumari <[email-masked]>
Date: Wed, 7 Feb 2018 04:12:28 -0500

Whoops, last message was blank; finger fail.

>> kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-no-NNNN

<no hats>

I personally like "kskroll-sentinel-is-ta-NNNN", or "is-ta--NNNN".

I really do not like
"kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN" as:
$echo "kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN" | wc -c
   62

(I note that you left off the last N in the "yes" version. While 62 is
within spec, it feels like we are getting really close; I cannot think
of any current issue that this might cause, but I *can* imagine
someone many years from now cursing us when Key IDs get expanded to
128bits to <insert unlikely but possible scenario here>)

I also think that we are getting into the beauty contest territory
here -- some of which may be caused by the fact that the authors
really owe the WG an update.

Whoever would have predicted that a discussion on naming things would
generate so much discussion?! :-)

W

I also note that you ignored my "I-heart-KennyG" suggestion. This
makes me sad. :-P
</no hats>

---

From: Benno Overeinder <[email-masked]>
Date: Wed, 7 Feb 2018 12:13:53 +0100

> $echo "kskroll-sentinel-dnssec-root-trust-anchor-key-trusted-yes-NNN" | wc -c

For what it is worth, I am with Warren, and particular like
"kskroll-sentinel-is-ta-NNNN".

-- Benno

-- 
Benno J. Overeinder
NLnet Labs
https://www.nlnetlabs.nl/

---

From: Bob Harold <[email-masked]>
Date: Wed, 7 Feb 2018 10:37:29 -0500

On Wed, Feb 7, 2018 at 6:13 AM, Benno Overeinder <[email-masked]> wrote:

> +1

-- 
Bob Harold

---

From: Matt Larson <[email-masked]>
Date: Wed, 7 Feb 2018 11:32:04 -0500

> On Feb 7, 2018, at 6:13 AM, Benno Overeinder <[email-masked]> wrote:
> 

+1

Matt

---

From: Geoff Huston <[email-masked]>
Date: Thu, 8 Feb 2018 16:46:38 +1100

> Fine. Now we need to have something actionable, e.g. set of names for

The first test I’ve undertaken is to test two name forms in an ad campaign over the past few days:

heres an example of the test:

xm--u82aa292f-c13-s1518066940-i00000000
_xm_-u82aa292f-c13-s1518066940-i00000000

test 1: the label starts with the characters: x m - -

test 2: the label starts with an underscore and contain an underscore within the label

results

Test 1: tested across 15,168,394 presented ads. 96.9% of end systems resolved the name and fetched the web object, 3.1% failed to fetch the web object

Test 2: 39.7% of end systems resolved the name and fetched the web object. 60.3% failed to fetch the web object
 
There is always a ‘drop out’ of users who do not fetch the web object, and 3% falls within the experiments error bounds. 

xm—<whatever> appears to be a label that generally works when presented to browsers as part of a scripted URL to fetch.

_<whatever> appears to trigger some response from many systems that preclude its use in URLs presented to browsers to fetch

thanks,

Geoff

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Feb 2018 12:28:20 +0100

On Mon, Feb 05, 2018 at 12:56:47PM +0100,
 Vladimír Čunát <[email-masked]> wrote 
 a message of 8 lines which said:

> result.  The system resolver does fetch _www.ksk-test.net. OK.  (I
> can't say I understand what happens.)

Isn't is simply because some browsers rely on the standard library's
getaddrinfo() and this routine does not accept all domain names? On Linux:

#define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
		   || ((c) >= 0x61 && (c) <= 0x7a))
#define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)

#define borderchar(c) (alphachar(c) || digitchar(c))
#define middlechar(c) (borderchar(c) || hyphenchar(c) || underscorechar(c))
#define	domainchar(c) ((c) > 0x20 && (c) < 0x7f)

int
res_hnok(const char *dn) {
	int pch = PERIOD, ch = *dn++;

	while (ch != '\0') {
		int nch = *dn++;

		if (periodchar(ch)) {
			(void)NULL;
		} else if (periodchar(pch)) {
			if (!borderchar(ch))
				return (0);
		} else if (periodchar(nch) || nch == '\0') {
			if (!borderchar(ch))
				return (0);
		} else {
			if (!middlechar(ch))
				return (0);
		}
		pch = ch, ch = nch;
	}
	return (1);
}	

Underscores are not accepted at the beginning of a name.

% dig +short +nodnssec _www.ksk-test.net
ron.kumari.net.
204.194.23.4

% ping _www.ksk-test.net          
ping: _www.ksk-test.net: Name or service not known

If you want to check on FreeBSD, it's here:

https://svnweb.freebsd.org/base/head/lib/libc/net/gethostbydns.c?view=markup#l140

---

From: Vladimír Čunát <[email-masked]>
Date: Mon, 12 Feb 2018 16:25:23 +0100

> getaddrinfo() and this routine does not accept all domain names? On Linux:

Right, that's most likely the problem.  IIRC Firefox uses getaddrinfo
for DNS, at least on Linux.  Even if we discount Firefox, it would seem
better to choose names compatible with glibc's getaddrinfo.

--Vladimir