Re: [DNSOP] A conversational description of sentinel.

[Geoff Huston]

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

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-i
_xm_-u82aa292f-c13-s1518066940-i

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— appears to be a label that generally works when presented to 
browsers as part of a scripted URL to fetch.

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

thanks,

Geoff





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Matt Larson]

> On Feb 7, 2018, at 6:13 AM, Benno Overeinder  wrote:
> 
> On 07/02/2018 10:12, Warren Kumari wrote:
>> Whoops, last message was blank; finger fail.
>> 
>> 
>> On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari  wrote:
>>> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček  wrote:
 
 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-
 kskroll-sentinel-not-ta-
 is-ta--
 not-ta--
 
 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-
>> 
>> 
>> 
>> I personally like "kskroll-sentinel-is-ta-", or "is-ta--".
>> 
>> 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
> 
> 
> For what it is worth, I am with Warren, and particular like
> "kskroll-sentinel-is-ta-".

+1

Matt

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Bob Harold]

On Wed, Feb 7, 2018 at 6:13 AM, Benno Overeinder  wrote:

> On 07/02/2018 10:12, Warren Kumari wrote:
> > Whoops, last message was blank; finger fail.
> >
> >
> > On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari  wrote:
> >> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček  wrote:
> >>>
> >>> 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-
> >>> kskroll-sentinel-not-ta-
> >>> is-ta--
> >>> not-ta--
> >>>
> >>> 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-
> >
> > 
> >
> > I personally like "kskroll-sentinel-is-ta-", or "is-ta--".
> >
> > 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
>
>
> For what it is worth, I am with Warren, and particular like
> "kskroll-sentinel-is-ta-".
>
> +1


>
> -- Benno
>
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
>
>
-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Benno Overeinder]

On 07/02/2018 10:12, Warren Kumari wrote:
> Whoops, last message was blank; finger fail.
> 
> 
> On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari  wrote:
>> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček  wrote:
>>>
>>> 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-
>>> kskroll-sentinel-not-ta-
>>> is-ta--
>>> not-ta--
>>>
>>> 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-
> 
> 
> 
> I personally like "kskroll-sentinel-is-ta-", or "is-ta--".
> 
> 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


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


-- Benno

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Warren Kumari]

Whoops, last message was blank; finger fail.


On Wed, Feb 7, 2018 at 3:57 AM, Warren Kumari  wrote:
> On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček  wrote:
>>
>>
>> On 6.2.2018 17:13, Paul Hoffman wrote:
>>> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>>>
 On 6.2.2018 13:22, Tony Finch wrote:
> A. Schulze  wrote:
>>
>> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
>> I also prefer that longer variant.
>
> Yes, more friendly for web searches if someone is wondering about weird
> queries.

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

 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.
>>
>> 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-
>> kskroll-sentinel-not-ta-
>> is-ta--
>> not-ta--
>>
>> 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-



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

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 )

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


>>
>> (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
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>
> --
> 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



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Warren Kumari]

On Wed, Feb 7, 2018 at 2:15 AM, Petr Špaček  wrote:
>
>
> On 6.2.2018 17:13, Paul Hoffman wrote:
>> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>>
>>> On 6.2.2018 13:22, Tony Finch wrote:
 A. Schulze  wrote:
>
> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
> I also prefer that longer variant.

 Yes, more friendly for web searches if someone is wondering about weird
 queries.
>>>
>>> Bonus points if we can get a number reserved by RFC editor, it would
>>> allow us to use name like
>>> test-rfc-is-ta-
>>> test-rfc-not-ta-
>>>
>>> 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.
>
> 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-
> kskroll-sentinel-not-ta-
> is-ta--
> not-ta--
>
> 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-
>
> (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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Petr Špaček]

On 6.2.2018 17:13, Paul Hoffman wrote:
> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
> 
>> On 6.2.2018 13:22, Tony Finch wrote:
>>> A. Schulze  wrote:

 Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
 I also prefer that longer variant.
>>>
>>> Yes, more friendly for web searches if someone is wondering about weird
>>> queries.
>>
>> Bonus points if we can get a number reserved by RFC editor, it would
>> allow us to use name like
>> test-rfc-is-ta-
>> test-rfc-not-ta-
>>
>> 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.

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-
kskroll-sentinel-not-ta-
is-ta--
not-ta--

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-

(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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Hoffman]

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Joe Abley]

On 6 Feb 2018, at 11:04, Petr Špaček  wrote:

> On 6.2.2018 13:22, Tony Finch wrote:
>> A. Schulze  wrote:
>> 
>>> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
>>> I also prefer that longer variant.
>> 
>> Yes, more friendly for web searches if someone is wondering about weird
>> queries.
> 
> Bonus points if we can get a number reserved by RFC editor, it would
> allow us to use name like
> test-rfc-is-ta-
> test-rfc-not-ta-
> 
> That would be super awesome.
> 
> 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 "" 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
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[joel jaeggli]

On 2/6/18 8:13 AM, Paul Hoffman wrote:
> On 6 Feb 2018, at 8:04, Petr Špaček wrote:
>
>> On 6.2.2018 13:22, Tony Finch wrote:
>>> A. Schulze  wrote:

 Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
 I also prefer that longer variant.
>>>
>>> Yes, more friendly for web searches if someone is wondering about weird
>>> queries.
>>
>> Bonus points if we can get a number reserved by RFC editor, it would
>> allow us to use name like
>> test-rfc-is-ta-
>> test-rfc-not-ta-
>>
>> That would be super awesome.
>
> ...and super-unlikely, given the history of the RFC Series.
>
>> 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.
> 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Hoffman]

On 6 Feb 2018, at 8:04, Petr Špaček wrote:


On 6.2.2018 13:22, Tony Finch wrote:

A. Schulze  wrote:


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


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

queries.


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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Petr Špaček]

On 6.2.2018 13:22, Tony Finch wrote:
> A. Schulze  wrote:
>>
>> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
>> I also prefer that longer variant.
> 
> Yes, more friendly for web searches if someone is wondering about weird
> queries.

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

That would be super awesome.

Is something like RFC number pre-allocation possible?

-- 
Petr Špaček  @  CZ.NIC

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Patrick Mevzek]

On 2018-02-05 14:18 -0500, Geoff Huston wrote:
> I thought this was due to some concern over the wording in RFC (some 
> IDN
> RFC whose number I can’t recall right now!) over a comment that the UC label 
> should not contain the starting sequence "  - -”

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
> contexts in the DNS?

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


Many ccTLDs have the same restriction.

-- 
Patrick Mevzek

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Tony Finch]

A. Schulze  wrote:
>
> Yes, "kskroll-sentinel-is-ta-" is more descriptive and specific.
> I also prefer that longer variant.

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

Tony.
-- 
f.anthony.n.finch    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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[A. Schulze]

Paul Hoffman:

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


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

Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Hoffman]

On 5 Feb 2018, at 11:18, Geoff Huston wrote:


On 5 Feb 2018, at 11:47 pm, Tony Finch  wrote:

Geoff Huston  wrote:


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?


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





I thought this was due to some concern over the wording in RFC 
(some IDN
RFC whose number I can’t recall right now!) over a comment that the 
UC label

should not contain the starting sequence "  - -”

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

contexts in the DNS?


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


--Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Geoff Huston]

> On 5 Feb 2018, at 11:47 pm, Tony Finch  wrote:
> 
> Geoff Huston  wrote:
>> 
>> 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?
> 
> Maybe put the -- in the middle somewhere? e.g. is-ta-- not-ta—
> 


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

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

geoff


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Tony Finch]

Geoff Huston  wrote:
>
> 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?

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

Tony.
-- 
f.anthony.n.finch    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.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Ray Bellis]

On 04/02/2018 22:35, Petr Špaček wrote:

> Underscore is now out of the question because we know about the
> 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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Vladimír Čunát]

On 02/02/2018 04:45 PM, Warren Kumari wrote:
> were **NOT** able to fetch the "underscore" record
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Geoff Huston]

> 
> 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-rfc-dnssec-root-trust-anchor-key-trusted-yes-
> (63 octets, unlikely to colide with anything, self-explanatory)
> test-name-rfc-dnssec-root-trust-anchor-key-trusted-no-
> (62 octets)
> 
> Opinions?
> 
> Geoff, is it realistic to test that clients are able to resolve A
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Warren Kumari]

On Fri, Feb 2, 2018 at 4:41 AM, Petr Špaček  wrote:
> On 2.2.2018 09:32, Mark Andrews wrote:
>> 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.
>
> 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...
>


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.

>
> 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. 
> 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
>
>> Mark
>>
>>> On 2 Feb 2018, at 6:50 pm, Petr Špaček  wrote:
>>>
>>> On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman:
> 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).

 just checked, my NSD and POWERDNS serve A record for _foo.examle.
 without noise...
 so: #1
>>>
>>> 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
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Petr Špaček]

On 2.2.2018 09:32, Mark Andrews wrote:
> 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.

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

> Mark
> 
>> On 2 Feb 2018, at 6:50 pm, Petr Špaček  wrote:
>>
>> On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman:
 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).
>>>
>>> just checked, my NSD and POWERDNS serve A record for _foo.examle.
>>> without noise...
>>> so: #1
>>
>> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Ray Bellis]

On 02/02/2018 08:32, Mark Andrews wrote:

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

+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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Mark Andrews]

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  wrote:
> 
> On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman:
>>> 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).
>> 
>> just checked, my NSD and POWERDNS serve A record for _foo.examle.
>> without noise...
>> so: #1
> 
> 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
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Petr Špaček]

On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman:
>> 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).
> 
> just checked, my NSD and POWERDNS serve A record for _foo.examle.
> without noise...
> so: #1

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[A. Schulze]

Paul Hoffman:

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


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

so: #1

Andreas


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Hoffman]

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- and _not-ta- 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  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Vixie]

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Geoff Huston]

> On 2 Feb 2018, at 7:56 am, Paul Hoffman  wrote:
> 
> On 1 Feb 2018, at 12:20, Geoff Huston wrote:
> 
>> 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?
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Paul Hoffman]

On 1 Feb 2018, at 12:20, Geoff Huston wrote:

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?


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Andrew Sullivan]

On Fri, Feb 02, 2018 at 07:20:45AM +1100, Geoff Huston wrote:
> 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?

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
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Geoff Huston]

> On 26 Jan 2018, at 3:17 am, Paul Hoffman  wrote:
> 
> On 25 Jan 2018, at 7:36, Warren Kumari wrote:
> 
>> On Thu, Jan 25, 2018 at 10:10 AM, Tony Finch  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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Warren Kumari]

On Thu, Jan 25, 2018 at 10:10 AM, Tony Finch  wrote:
> (catching up on old messages)
>
> Warren Kumari  wrote (and I liberally snipped):
>>
>> I publish this in my a zone:
>>
>> _is-ta-12345.example.com.   600 IN  A   192.0.2.1
>> _is-ta-12345.example.com.   600 IN RRSIG   A 
>>
>> I now tell users to please browse to www.example.com, where I have a
>> webpage which includes the following links:
>> http://_is-ta-12345.example.com/
>
> Isn't this going to cause problems with software that checks hostname
> syntax?
>

Good catch; I stumbled into this on Monday when setting up an example...

BIND (for one) checks names with underscores, but only for A records:
$ ~/src/code/scripts/ddns.sh
> update add _tony.dnssec-example.com 600 IN A 127.0.0.1
check-names failed: bad owner '_tony.dnssec-example.com'
> update add _tony.dnssec-example.com 600 IN CNAME www.example.com
> ^c
$

For this reason, when setting up my toy example I used CNAMES:

$dig _is-ta-20236.dnssec-example.com
...
;; ANSWER SECTION:
_is-ta-20236.dnssec-example.com. 30 IN  CNAME   ron.kumari.net.
ron.kumari.net. 600 IN  A   204.194.23.4


There is a (very incomplete) example at http://www.dnssec-example.com/
-- I had created this for some slides, and so the code favors length /
clarity over prettiness.
Also, the "invalid" part test doesn't work yet, because, well, BIND
keeps resigning my "invalid.dnssec-example.com" record and making it
valid :-)


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

W

>
> Tony.
> --
> f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
> Shannon, Rockall: Northwest backing south later, 5 to 7, occasionally gale 8,
> decreasing 4 for a time. Very rough or high, becoming rough or very rough.
> Showers, rain later. Mainly good.



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Tony Finch]

(catching up on old messages)

Warren Kumari  wrote (and I liberally snipped):
>
> I publish this in my a zone:
>
> _is-ta-12345.example.com.   600 IN  A   192.0.2.1
> _is-ta-12345.example.com.   600 IN RRSIG   A 
>
> I now tell users to please browse to www.example.com, where I have a
> webpage which includes the following links:
> http://_is-ta-12345.example.com/

Isn't this going to cause problems with software that checks hostname
syntax?

Wouldn't it be better to use something like a double hyphen to avoid
collisions?

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall: Northwest backing south later, 5 to 7, occasionally gale 8,
decreasing 4 for a time. Very rough or high, becoming rough or very rough.
Showers, rain later. Mainly good.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Warren Kumari]

On Mon, Jan 15, 2018 at 7:22 AM william manning 
wrote:

> your wrote,: "​In the real world, the user will not be expected to figure
> this out [...] --  a bit of JS on www.example.com will do the 3 fetches
> and report "You'll be just fine", "You will have issues, call your ISP and
> get them to install the new key" or "Sorry, cannot tell.​ Call your ISP and
> ask them to upgrade to a resolver which does this!"."
>
> I think its a bit  sad that for the DNS to work, one now needs to run
> http[s] and JS.   So much for stand alone protocols. Now if you could show
> how this works without JS or HTTP, then we might be getting somewhere.
>


% dig invalid.example.com
A: Did I get an answer (SERVFAIL isn't an answer)? I'm not validating.
Keyroll won't affect me.

% dig _is-ta-12345.example.com
% dig _not-ta-12345.example.com
B: Did I get an answer to both?  My resolvers haven't been upgraded, I
cannot tell what will happen.

C: Did I get an answer for _is-ta-12345.example.com and a SERVFAIL for _
not-ta-12345.example.com ? My resolver supports sentinal (is sentinent?!),
and has the new key. I'll be fine.

D: Did I get a SERFVAIL for _is-ta-12345.example.com and an answer for _
not-ta-12345.example.com ? My resolver supports sentinal, and does not have
the new key. I'll die during the rollover.

This works just fine without JS or HTTP -- but expecting users (which is
ultimatly what we are trying to measure) to do the above, and then report
that back somewhere is not really viable.

RFC8145 tried to measure using the DNS only -- but that only lets you know
what *resolvers* will be OK, which is fairly meaningless; I have a resolver
in my basement which only has the old key, but seeing as no users are
querying it, it it's nearly as important as my local ISP, whose resolver
services thousands of users.

If you have a better proposal, we are all ears...
W


>
> /Wm
>
> On Sun, Jan 14, 2018 at 5:51 PM, Warren Kumari  wrote:
>
>> Hi all,
>>
>> I had a conversation with a friend earlier today, who had carefully read
>> the document
>> ​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​
>> , but had not managed to understand it at all
>> ​.​
>> ​Since
>>  this friend is bright, and really understand
>> ​s​
>> DNS, I figured that the document doesn't do as good a job explaining how
>> this would be used in practice as it should. Sometimes it is easier to
>> explain things in an informal manner, and so here is a (hopefully better)
>> description of draft-ietf-dnsop-kskroll-sentinel).
>>
>> 2 things seemed to be causing confusion:
>> 1: The only "magic" that happens is in validating recursive resolvers,
>> right before they send the response to a query
>> ​. T​
>> here is no magic / change needed in authoritative servers, stubs, or
>> anywhere else.
>>
>> 2: Anyone who wants to provide a service like this
>> ​(see below) ​
>> can - you don't need to be in any special location in the DNS tree to do
>> this.
>>
>>
>> The (new) rules:
>> A: If the qname starts with _is-ta, and the included keyid is *NOT* in
>> the trust store, the resolver changes the answer to a SERVFAIL (otherwise
>> things proceed normally).
>> B: If the qname starts with _not-ta and the included keyid *IS* in the
>> trust store, the resolver changes the answer to a SERVFAIL (otherwise
>> things proceed normally).
>>
>> (There is some pseudo-code below, but it makes this look much more
>> complex (and I dislike pseudo-code - it's hard to guess at the level of
>> abstraction to use!).
>>
>>
>> ​Let's pretend ​
>> I'm the operator of example.com, and I'd like to help users know if the
>> resolvers that they use will survive the new keyroll (with key id 12345).
>>
>> I publish this in my a zone:
>>
>> _is-ta-12345.example.com.   600 IN  A   192.0.2.1
>> _is-ta-12345.example.com.   600 IN RRSIG   A 
>>
>> _not-ta-12345.example.com.   600 IN  A   192.0.2.2
>> _not-ta-12345.example.com.   600 IN RRSIG   A 
>>
>> invalid.example.com. 600 IN  A   192.0.2.3
>> invalid.example.com. 600 IN  RRSIG A <0x (an invalid
>> signature)>
>>
>> ​I also run 3 webservers:
>> ​
>> 192.0.2.1
>> ​   -- a picture of a cute kitten
>> 192.0.2.
>> ​2   -- a picture of a puppy
>> 192.0.2.
>> ​3  -- a picture of a fish.​
>> ​
>> ​
>>
>>
>>
>> I now tell users to please browse to www.example.com, where I have a
>> webpage which includes the following links: http://_
>> is-ta-12345.example.com/
>> ​(​
>> kitten) , http://_not-ta-12345.example.com/ (puppy),
>> http://invalid.example.com/ (fish).
>> ​The pictures the user can see tells them if they will survive the
>> rollover.
>> ​
>>
>>
>> The user can be in one of 4 classes, depending on which animals they see:
>>
>> 1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the
>> URLs (including http://invalid.example.com/). If they see a Fish, they
>> are not using a validating resolver and so will 

Re: [DNSOP] A conversational description of sentinel.

[Ralph Dolmans]

Hi Warren, all,

On 15-01-18 02:51, Warren Kumari wrote:
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in
> the trust store, the resolver changes the answer to a SERVFAIL
> (otherwise things proceed normally).
> B: If the qname starts with _not-ta and the included keyid *IS* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).

It is still not clear to me which trust anchor a validator should use
for the sentinel processing. Is that (1) the root trust anchor with
corresponding keyid, (2) the trust anchor with matching keyid for the
domain that is queried, so the example.com trust anchor in your example,
or (3) any trust anchor from the trust store with a matching keyid?

1. Does not require changes in the root zone and makes it possible for
anyone to create a root KSK test. It also means that this test can not
be used for any non-root trust anchor.
2. Requires changes in the root zone, but makes it possible to test the
trust anchor for any zone.
3. Reduces the usefulness of the data. You know that a trust anchor for
that keyid is configured, but you don't know for which zone. Given the
limited number of keyids this does not sound like a good option. A trust
anchor in the trust store with the keyid of the new root KSK does then
not imply that validation will work after the keyroll.

-- Ralph

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[Joe Abley]

On 15 Jan 2018, at 07:22, KenM  wrote:

> I think its a bit  sad that for the DNS to work, one now needs to run http[s] 
> and JS.   So much for stand alone protocols. Now if you could show how this 
> works without JS or HTTP, then we might be getting somewhere.

We could write the client test code in java or a tangle of perl libraries, or 
load custom software onto tiny, USB-powered computers and hand them out to 
literally tens of people that we meet in niche technical meetings around the 
world. Or use the preferred devops approach of wget | sh as root, although I'm 
not sure we should insist on that level of security.


Joe
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

[william manning]

your wrote,: "​In the real world, the user will not be expected to figure
this out [...] --  a bit of JS on www.example.com will do the 3 fetches and
report "You'll be just fine", "You will have issues, call your ISP and get
them to install the new key" or "Sorry, cannot tell.​ Call your ISP and ask
them to upgrade to a resolver which does this!"."

I think its a bit  sad that for the DNS to work, one now needs to run
http[s] and JS.   So much for stand alone protocols. Now if you could show
how this works without JS or HTTP, then we might be getting somewhere.

/Wm

On Sun, Jan 14, 2018 at 5:51 PM, Warren Kumari  wrote:

> Hi all,
>
> I had a conversation with a friend earlier today, who had carefully read
> the document
> ​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​
> , but had not managed to understand it at all
> ​.​
> ​Since
>  this friend is bright, and really understand
> ​s​
> DNS, I figured that the document doesn't do as good a job explaining how
> this would be used in practice as it should. Sometimes it is easier to
> explain things in an informal manner, and so here is a (hopefully better)
> description of draft-ietf-dnsop-kskroll-sentinel).
>
> 2 things seemed to be causing confusion:
> 1: The only "magic" that happens is in validating recursive resolvers,
> right before they send the response to a query
> ​. T​
> here is no magic / change needed in authoritative servers, stubs, or
> anywhere else.
>
> 2: Anyone who wants to provide a service like this
> ​(see below) ​
> can - you don't need to be in any special location in the DNS tree to do
> this.
>
>
> The (new) rules:
> A: If the qname starts with _is-ta, and the included keyid is *NOT* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).
> B: If the qname starts with _not-ta and the included keyid *IS* in the
> trust store, the resolver changes the answer to a SERVFAIL (otherwise
> things proceed normally).
>
> (There is some pseudo-code below, but it makes this look much more complex
> (and I dislike pseudo-code - it's hard to guess at the level of abstraction
> to use!).
>
>
> ​Let's pretend ​
> I'm the operator of example.com, and I'd like to help users know if the
> resolvers that they use will survive the new keyroll (with key id 12345).
>
> I publish this in my a zone:
>
> _is-ta-12345.example.com.   600 IN  A   192.0.2.1
> _is-ta-12345.example.com.   600 IN RRSIG   A 
>
> _not-ta-12345.example.com.   600 IN  A   192.0.2.2
> _not-ta-12345.example.com.   600 IN RRSIG   A 
>
> invalid.example.com. 600 IN  A   192.0.2.3
> invalid.example.com. 600 IN  RRSIG A <0x (an invalid
> signature)>
>
> ​I also run 3 webservers:
> ​
> 192.0.2.1
> ​   -- a picture of a cute kitten
> 192.0.2.
> ​2   -- a picture of a puppy
> 192.0.2.
> ​3  -- a picture of a fish.​
> ​
> ​
>
>
>
> I now tell users to please browse to www.example.com, where I have a
> webpage which includes the following links: http://_is-ta-12345.example.
> com/
> ​(​
> kitten) , http://_not-ta-12345.example.com/ (puppy),
> http://invalid.example.com/ (fish).
> ​The pictures the user can see tells them if they will survive the
> rollover.
> ​
>
>
> The user can be in one of 4 classes, depending on which animals they see:
>
> 1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the
> URLs (including http://invalid.example.com/). If they see a Fish, they
> are not using a validating resolver and so will survive the keyroll (it
> actually means that at least 1 of their resolvers is not validating). The
> user is happy and goes to have ice-cream (nonV).
>
> 2: The user sees a only Kitten and a Puppy (they fetched http://_
> is-ta-12345.example.com/ and http://_not-ta-12345.example.com/, but not
> http://invalid.example.com/.) This means that they are using a
> ​legacy ​
> validating resolver
> ​ (it ​
> doesn't implement this mechanism
> ​)​
> .
> ​They cannot tell, and this test doesn't tell them anything
>  (Vleg).
>
> 3: They see only a Kitten (they fetched http://_is-ta-12345.example.com/,
> not http://_not-ta-12345.example.com/, and not http://invalid.example.com/).
> The user is behind a validating resolver which implements this mechanism,
> and knows about the new key. They are happy, and go have ice-cream (Vnew).
>
> 4: The user sees only a Puppy (they did not fetch http://_
> is-ta-12345.example.com/, they did fetch http://_not-ta-12345.example.com/,
> they did not fetch http://invalid.example.com). The user is behind a
> validating resolver which implements this mechanism, but does NOT have the
> new key). The user is sad, and calls their ISP to complain (and has cold
> porridge for dinner) (Vold).
>
> +-+--+---++
> | Type\Query  |  _is-ta  |  _not-ta  |  invalid   |
> +-+--+---++
> | Vnew|A |  SERVFAIL | 

Re: [DNSOP] A conversational description of sentinel.

[Joe Abley]

Hi Warren,

On 14 Jan 2018, at 20:51, Warren Kumari  wrote:

> I had a conversation with a friend earlier today, who had carefully read the 
> document​ 
> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​, but 
> had not managed to understand it at all​.​ ​Since this friend is bright, and 
> really understand​s​ DNS, I figured that the document doesn't do as good a 
> job explaining how this would be used in practice as it should. Sometimes it 
> is easier to explain things in an informal manner, and so here is a 
> (hopefully better) description of draft-ietf-dnsop-kskroll-sentinel).
> 
> 2 things seemed to be causing confusion:

I think the document would benefit from some explicit advice for zone 
administrators and some explicit requirements for validating resolvers, and 
having them both separated into obviously-distinct sections. An example of a 
specific experiment would also be useful.

A careful review of some of the terminology would also probably help. At the 
moment the text contains contains phrases like "query name that is signed with 
a DNSEC signature" that I think adds to the ambiguity and confusion (query 
names are not signed; RRSets are signed, and the corresponding part of an RRSet 
to a QNAME in the sense that I think is intended is an owner name).

I definitely agree that even with some prior idea of what this mechanism is 
trying to do (and some prior exposure to the geoffsperiments that provide 
context) this draft is quite hard to understand. The small handful of slides I 
saw Geoff present about this seemed far easier to understand than the draft, in 
fact.

I would be happy to suggest text if that seems useful, but I haven't done that 
here since it seems likely that other text changes are already in the pipeline, 
based on reviews on this list so far.


Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] A conversational description of sentinel.

[Warren Kumari]

Hi all,

I had a conversation with a friend earlier today, who had carefully read
the document
​ (https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/)​
, but had not managed to understand it at all
​.​
​Since
 this friend is bright, and really understand
​s​
DNS, I figured that the document doesn't do as good a job explaining how
this would be used in practice as it should. Sometimes it is easier to
explain things in an informal manner, and so here is a (hopefully better)
description of draft-ietf-dnsop-kskroll-sentinel).

2 things seemed to be causing confusion:
1: The only "magic" that happens is in validating recursive resolvers,
right before they send the response to a query
​. T​
here is no magic / change needed in authoritative servers, stubs, or
anywhere else.

2: Anyone who wants to provide a service like this
​(see below) ​
can - you don't need to be in any special location in the DNS tree to do
this.


The (new) rules:
A: If the qname starts with _is-ta, and the included keyid is *NOT* in the
trust store, the resolver changes the answer to a SERVFAIL (otherwise
things proceed normally).
B: If the qname starts with _not-ta and the included keyid *IS* in the
trust store, the resolver changes the answer to a SERVFAIL (otherwise
things proceed normally).

(There is some pseudo-code below, but it makes this look much more complex
(and I dislike pseudo-code - it's hard to guess at the level of abstraction
to use!).


​Let's pretend ​
I'm the operator of example.com, and I'd like to help users know if the
resolvers that they use will survive the new keyroll (with key id 12345).

I publish this in my a zone:

_is-ta-12345.example.com.   600 IN  A   192.0.2.1
_is-ta-12345.example.com.   600 IN RRSIG   A 

_not-ta-12345.example.com.   600 IN  A   192.0.2.2
_not-ta-12345.example.com.   600 IN RRSIG   A 

invalid.example.com. 600 IN  A   192.0.2.3
invalid.example.com. 600 IN  RRSIG A <0x (an invalid signature)>

​I also run 3 webservers:
​
192.0.2.1
​   -- a picture of a cute kitten
192.0.2.
​2   -- a picture of a puppy
192.0.2.
​3  -- a picture of a fish.​
​
​



I now tell users to please browse to www.example.com, where I have a
webpage which includes the following links: http://_is-ta-12345.example.com/
​(​
kitten) , http://_not-ta-12345.example.com/ (puppy),
http://invalid.example.com/ (fish).
​The pictures the user can see tells them if they will survive the rollover.
​


The user can be in one of 4 classes, depending on which animals they see:

1: The user sees a Fish, a Kitten and a Puppy  -- they fetched all the URLs
(including http://invalid.example.com/). If they see a Fish, they are not
using a validating resolver and so will survive the keyroll (it actually
means that at least 1 of their resolvers is not validating). The user is
happy and goes to have ice-cream (nonV).

2: The user sees a only Kitten and a Puppy (they fetched http://_
is-ta-12345.example.com/ and http://_not-ta-12345.example.com/, but not
http://invalid.example.com/.) This means that they are using a
​legacy ​
validating resolver
​ (it ​
doesn't implement this mechanism
​)​
.
​They cannot tell, and this test doesn't tell them anything
 (Vleg).

3: They see only a Kitten (they fetched http://_is-ta-12345.example.com/,
not http://_not-ta-12345.example.com/, and not http://invalid.example.com/).
The user is behind a validating resolver which implements this mechanism,
and knows about the new key. They are happy, and go have ice-cream (Vnew).

4: The user sees only a Puppy (they did not fetch http://_
is-ta-12345.example.com/, they did fetch http://_not-ta-12345.example.com/,
they did not fetch http://invalid.example.com). The user is behind a
validating resolver which implements this mechanism, but does NOT have the
new key). The user is sad, and calls their ISP to complain (and has cold
porridge for dinner) (Vold).

+-+--+---++
| Type\Query  |  _is-ta  |  _not-ta  |  invalid   |
+-+--+---++
| Vnew|A |  SERVFAIL |  SERVFAIL  |
| Vold| SERVFAIL |  A|  SERVFAIL  |
| Vleg|A |  A|  SERVFAIL  |
| nonV|A |  A| A  |
+-+--+---++

​In the real world, the user will not be expected to figure this out from
looking at pictures --  a bit of JS on www.example.com will do the 3
fetches and report "You'll be just fine", "You will have issues, call your
ISP and get them to install the new key" or "Sorry, cannot tell.​ Call your
ISP and ask them to upgrade to a resolver which does this!". There will
also likely be some Geoffvertisement which will do this on a large scale
and report back.

​Hopefully this clears things up some -- the only code change needs to
happen on recursive resolvers, the A record returned is unmolested (so that
if can be used for something) and