Subject: [DNSOP] KSK-Sentinal: Once more down the naming rathole.

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Feb 2018 14:15:30 -0500

"There are 2 hard problems in computer science: cache invalidation,
naming things, and off-by-1 errors."

So, Petr pointed out that the draft says:
Section 3: "Note that the <tag-index> is specified in the DNS label
using hexadecimal notation."

and my demo site (and example presentations) has been using decimal notation.

Knot Resolver 2.1 already does the logic according to the draft (hex),
but is what the WG wants?

1: RFC1034, Sec 5.3: The DS RR Presentation Format sayeth:
  " The Key Tag field MUST be represented as an unsigned decimal
 integer."
2:  dig +multiline DNSKEY . shows keytags as decimal

3: The (authoritative?) IANA file
(http://data.iana.org/root-anchors/root-anchors.xml) lists the keytags
as decimal.

What does the WG prefer? Is the new KSK called "20326" or it is "4f66"?

Hex has the advantage that A: Knot already does this! B: it is shorter
as a label.

What would y'all like?

W
-- 
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: "Paul Hoffman" <[email-masked]>
Date: Wed, 21 Feb 2018 11:23:45 -0800

> Hex has the advantage that A: Knot already does this! B: it is shorter

Some preference for 20326 because it is easier to read and there is no 
possibility of mis-match due to capitalization. Would live with hex if 
you said "lowercase hex" for the presentation form.

--Paul Hoffman

---

From: Bob Harold <[email-masked]>
Date: Wed, 21 Feb 2018 14:43:02 -0500

On Wed, Feb 21, 2018 at 2:23 PM, Paul Hoffman <[email-masked]> wrote:

> possibility of mis-match due to capitalization. Would live with hex if you
> said "lowercase hex" for the presentation form.
>
> --Paul Hoffman
>
>
Prefer numeric, since RFC4034 specifies that for display, and everywhere I
see key tags in a google search they are always that way.  "dig" shows them
that way.

-- 
Bob Harold

---

From: Joe Abley <[email-masked]>
Date: Wed, 21 Feb 2018 11:53:24 -0800

On Feb 21, 2018, at 14:43, Bob Harold <[email-masked]> wrote:

> Prefer numeric, since RFC4034 specifies that for display, and everywhere I see key tags in a google search they are always that way.  "dig" shows them that way.

Me too, same reasons.

Why did 8145 specify hex? I don't remember the discussion.

Joe

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 21 Feb 2018 19:59:17 +0000

> On Feb 21, 2018, at 2:53 PM, Joe Abley <[email-masked]> wrote:
> 

I argued for hex and leading zeroes because I thought it might be beneficial to have some structure in the query name, in case there were false signals from name collisions, etc.  ie, _ta-0001 vs _ta-1.

DW

---

From: Edward Lewis <[email-masked]>
Date: Wed, 21 Feb 2018 20:42:25 +0000

>    I argued for hex and leading zeroes because I thought it might be beneficial to have some structure in the query name, in case there were false signals from name collisions, etc.  ie, _ta-0001 v…

I was (back then) for hex because it was fixed width.

Now I think sticking with the common/legacy/established way (base10) would be better.  I could live with leading 0's, but that's messy when someone it "talking the problem over" with another.

---

From: Petr Špaček <[email-masked]>
Date: Thu, 22 Feb 2018 10:03:08 +0100

> Now I think sticking with the common/legacy/established way (base10) would be better.  I could live with leading 0's, but that's messy when someone it "talking the problem over" with another.

I would prefer decimal for user-friendliness, and zero padding to make
implementation easier and faster.

-- 
Petr Špaček  @  CZ.NIC

---

From: Ralph Dolmans <[email-masked]>
Date: Thu, 22 Feb 2018 10:33:29 +0100

> implementation easier and faster.

+1, decimal and zero padded to 5 digits to make it fixed length labels.

-- Ralph

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Feb 2018 02:38:55 -0800

Hi Petr,

> On Feb 22, 2018, at 04:03, Petr Špaček <[email-masked]> wrote:
>

A few people now have mentioned that they like zero padding. What is
it about zero padding or fixed-size labels that makes implementation
easier than specifying no zero padding?

Since zero padding for key tags is not generally seen anywhere else it
seems more consistent (and hence perhaps less error-prone) to specify
no zero padding in labels.

Joe

---

From: Petr Špaček <[email-masked]>
Date: Thu, 22 Feb 2018 12:20:27 +0100

> easier than specifying no zero padding?

It is important to note that this 'special label trigger' is not seen
anywhere else in DNS, so this is first piece of code which has to match
DNS labels in the 'hot path'.

I think it is a good and easy optimization to minimize use of
regexes/string matching in the hot path, and simple condidion
if (label_len == X || label_len == Y)
before the heavy-weight pattern matching will reduce frequency of regex
use significantly.

We can live without it, but it is so cheap optimization that I do not
see a reason not do it.

Petr Špaček  @  CZ.NIC

> no zero padding in labels

---

From: Matt Larson <[email-masked]>
Date: Thu, 22 Feb 2018 09:45:50 -0500

> On Feb 22, 2018, at 4:33 AM, Ralph Dolmans <[email-masked]> wrote:
> 
> 

Another +1 from me.

Matt

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Feb 2018 10:05:47 -0500

> before the heavy-weight pattern matching will reduce frequency of regex

You could use the simple condition (X < label_len < Y) in the same way without zero-padding and I suspect get a similar benefit.

Really, so long as the format is standardised I don't think it matters much. It's not like we're going to see a significant number of experiments of this kind; more like a small flurry of Duane/Geoff action once every five years. [*]

But I think mandatory zero-padding is ugly, and it does make me a little bit sad. :-)

Joe

[*] perhaps try not to dwell too long on the phrase "Duane/Geoff action"