Subject: [DNSOP] draft-huston-kskroll-sentinel - naming format?

From: Ray Bellis <[email-masked]>
Date: Mon, 30 Oct 2017 16:40:40 +0000

I see that this draft uses a syntax similar to RFC 8145 Trust Anchor
Telemetry RFC (which uses _ta-<hex_id>) albeit without the leading
underscore, i.e. .ta-<hex_id>.

I'd like to propose instead <hex-id>._ta.<domain>

This would allow _ta to be registered as a standalone entry in the
underscore label registry, whilst also avoid the risk of collisions with
"plain" labels that happen to match ta-<hex>

FWIW, I think in retrospect that RFC 8145 should have taken a similar
approach too.

Ray

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Oct 2017 17:40:52 +0000

> FWIW, I think in retrospect that RFC 8145 should have taken a similar

IIRC we discussed it, and were concerned that _ta. could be cached as
nonexistent by servers implementing QNAME minimization.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Oct 2017 11:27:30 +0000

> nonexistent by servers implementing QNAME minimization.

How would that happen, at least so long as _ta responds like any other
empty non-terminal?

Ray

---

From: Tony Finch <[email-masked]>
Date: Tue, 31 Oct 2017 14:34:40 +0000

> How would that happen, at least so long as _ta responds like any other

It's NXDOMAIN. (It'll also fall foul of RFCs 8020 and 8198.)

The problem occurs if you have a validator behind a cache. The cache will
prevent downstream id._ta. queries from reaching the root, so any
downstream trust anchor variation will be lost.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Viking, North Utsire: Southwesterly 5 or 6, veering westerly 5 to 7 later.
Moderate or rough, occasionally slight in North Utsire. Rain or showers, fog
patches in Viking. Moderate or poor, occasionally very poor in Viking.

---

From: Joe Abley <[email-masked]>
Date: Tue, 31 Oct 2017 10:56:41 -0400

> How would that happen, at least so long as _ta responds like any other

Perhaps I missed something, but how do you ensure that _ta is an empty non-terminal?

Joe

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Oct 2017 14:56:54 +0000

> downstream trust anchor variation will be lost.

Right, but if it's _defined_ to be an ENT instead (with NOERROR) then
that problem shouldn't arise?

In any event, for the proposed new mechanism the queries don't reach the
root, they're handled internally within the resolver.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Tue, 31 Oct 2017 15:01:01 +0000

> Perhaps I missed something, but how do you ensure that _ta is an

By having that be part of the required server logic to implement the
sentinel mechanism?

That said, I'm not sure this would be consistent with the draft's
proposed use of SERVFAIL.

Ray

---

From: Geoff Huston <[email-masked]>
Date: Tue, 31 Oct 2017 19:23:10 +0400

> On 31 Oct 2017, at 6:34 pm, Tony Finch <[email-masked]> wrote:
> 

The mechanism does not rely on these queries reaching the root. The key aspect is the signal back to the querier. So even caching is quite ok here. The critical aspect of this mechanism is that it is not intended to measure resolvers, but detect if an end user has a DNS resolution environment that will (or will not) be impacted by a roll in the KSK to a named (via a key tag value) new KSK.

Certainly it would remove some of the QNAME minimisation issues if the test is based on a single label as defined in the draft, and on reflection I _think_ its probably more robust if its the terminal label, but frankly I’m not sure about that latter point. 

Geoff

---

From: Geoff Huston <[email-masked]>
Date: Tue, 31 Oct 2017 19:27:06 +0400

> downstream trust anchor variation will be lost.

The mechanism does not rely on these queries reaching the root. It's the signal back to the querier that’s important here. So even caching is quite ok. The critical aspect of this mechanism is that it is not intended to measure resolvers, but detect if an end user has a DNS resolution environment that will (or will not) be impacted by a roll in the KSK to a named (via a key tag value) new KSK.

Geoff

---

From: Joe Abley <[email-masked]>
Date: Tue, 31 Oct 2017 11:51:27 -0400

> By having that be part of the required server logic to implement the

If a format is going to be specified that specifically prohibits a zone cut, doesn't it make more sense to choose one that can't possibly involve one because there are no potential label boundaries?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Tue, 31 Oct 2017 11:10:01 -0700

Joe Abley wrote:
> If a format is going to be specified that specifically prohibits a
> zone cut, doesn't it make more sense to choose one that can't
> possibly involve one because there are no potential label
> boundaries?

+1.

-- 
P Vixie