Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

From: Robert Story <[email-masked]>
Date: Sun, 28 Jan 2018 08:01:34 -0500

On Mon 2017-11-13 18:26:02-0800 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain Name System
> Operations WG of the IETF.

I was re-reading the draft today and noticed that Vold and Vnew are
inconsistent with Vold and Vnew with respect to non-SERVFAIL responses:

>  o  Vleg: A DNSSEC-Validating resolver that does not implement this
>     mechanism will respond with an A or AAAA RRSET response for "_is-
>     ta", an A record response for "_not-ta" and SERVFAIL for the
>     invalid name.

Shouldn't it be "an A or AAAA RRSET" for "_not-ta"?

>  o  nonV: A non-DNSSEC-Validating resolver will respond with an A
>     record response for "_is-ta", an A record response for "_not-ta"
>     and an A record response for the invalid name.

Similarly, shouldn't all three of these be "an A or AAAA record"?

The table following this text also only specifies "A" for responses.

-- 
Robert Story <http://www.isi.edu/~rstory>
USC Information Sciences Institute <http://www.isi.edu/>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jan 2018 16:10:42 -0500

> The table following this text also only specifies "A" for responses.

Yes, you are right -- for all places where there is 'A' it should be
'A or AAAA'; how do people feel about something along the lines of:

"Throughout this document, we are using A to refer to an Address
record (either 'A' or  'AAAA') " -- having "A or AAAA" scattered all
over the document makes it now flow as nicely...

W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> 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

---

From: Martin Hoffmann <[email-masked]>
Date: Mon, 29 Jan 2018 23:37:55 +0100

> over the document makes it now flow as nicely...

Perhaps define a term for "A or AAAA" such as "address record"? That
could potentially be useful as a general term in more contexts.

Kind regards,
Martin

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 29 Jan 2018 23:55:11 +0100

> over the document makes it now flow as nicely...

Just for fun, turn that around: "Throughout this document, we are
using AAAA ... either A of AAAA".

	jaap

---

From: Richard Gibson <[email-masked]>
Date: Mon, 29 Jan 2018 20:13:32 -0500

Indeed, the concept of "address record" has also come up in 
https://tools.ietf.org/html/draft-ietf-dnsop-aname-01 , which even 
suggests (but does not specify) the creation of an IANA registry.

On 01/29/2018 05:37 PM, Martin Hoffmann wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=IgPbrWR6stuN7EM0GwJxqlFLRK6hEx84qtzcWWHMExA&s=9h6luQk0E_2DJUP0z5j846tHq6g7w4VMI8v7-scoQfQ&e=

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jan 2018 10:24:59 -0500

On Mon, Jan 29, 2018 at 11:37:55PM +0100, Martin Hoffmann wrote:
> Perhaps define a term for "A or AAAA" such as "address record"?

I went and looked at terminology-bis and noted that we use "address
record" and parenthetically define it.  Should we define it more
formally?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joe Abley <[email-masked]>
Date: Tue, 30 Jan 2018 10:42:15 -0500

Hey,

> On Jan 30, 2018, at 10:24, Andrew Sullivan <[email-masked]> wrote:
> 

I realise that the following is not what anybody means in this thread, but just a gentle reminder that it is possible to express other addresses than those used in IPv4 and IPv6 in the DNS.

type 1 (A) "a host address"
type 19 (X25) "for X.25 PSDN address"
type 20 (ISDN) "for ISDN address"
type 22 (NSAP) "for NSAP address, NSAP style A record"
type 27 (GPOS) "geographical position"
type 28 (AAAA) "IPv6 address"
type 29 (LOC) "location information"
type 31 (EID) "endpoint identifier"
type 32 (NIMLOC) "nimrod locator"
type 34 (ATMA) "ATM address"
type 55 (HIP) "host identity protocol"
type 104 (NID) "identifier-locator network protocl (ILNP)"
type 105 (L32) "identifier-locator network protocol (ILNP)"
type 106 (L64) "identifier-locator network protocol (ILNP)"
type 108 (EUI48) "an EUI-48 address"
type 109 (EUI64) "an EUI-64 address"

I probably missed some. Anyway, I think when people are saying "address record" here they actually mean "IP address record".

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jan 2018 13:51:28 -0500

On Tue, Jan 30, 2018 at 10:42:15AM -0500, Joe Abley wrote:
> 
> I realise that the following is not what anybody means in this thread

Hmm.  Actually, I wasn't sure :-)

> I probably missed some. Anyway, I think when people are saying "address record" here they actually mean "IP address record".

We should probably say that, then, and also of course we should fix
the poor text in the teminology document to point this out.

A

-- 
Andrew Sullivan
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 31 Jan 2018 09:44:10 +1000

I think we're rat holing. I'm not an author on this draft, but I know
them both, and I work with one, and I believe the draft is basically
in the right space and .. well.. we're rat holing.

So, noting my disclaimer of bias, can we .. move on? Is there real
matters of substance left on this one? It feels like its close.

-G

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Jan 2018 19:29:35 -0500

> matters of substance left on this one? It feels like its close.

There is one matter of substance (but, IMO, very minor substance!) --
the original document said that the names are of the form:
_is-ta-[key].example.com
_not-ta-[key].example.com

This works, but some implementations really don't like having A/AAA
records for names which start with an underscore... So, we are
proposing to use instead:
xm--is-ta-[key].example.com
xm--not-ta-[key].example.com

Why XM--? Well, we wanted some sort of identifier (that isn't an
underscore), and XM-- felt "similar" to XN--. A quick look through the
.com and .net zonefiles didn't show any collisions (yes, I realize
that this is a tiny slice of the namespace, but it was quick and
easy), nor did looking in various passive-dns and similar places.

For folk who would like try this, I have a PoC / toy implementation at
https://www.ksk-test.net  - note that this uses JS and I'm *so* not a
JavaScript programmer. It works on the browsers that I tested, that's
all I'll commit to :-)

The document could really benefit from a better introduction /
explanation of how this will be used (similar to my earlier
conversational description) and integrating the comments received.
The authors intend to publish this soon.

W

---

From: George Michaelson <[email-masked]>
Date: Wed, 31 Jan 2018 10:32:22 +1000

I tested this. you can bind _label onto CNAME but not A/AAAA. bind
won't serve zones with it.

So yea.. I think the change is needed.

thats substantful.

-G

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 30 Jan 2018 16:58:01 -0800

> easy), nor did looking in various passive-dns and similar places.

Please, no. As the originator of the original 
<letter><letter><hyphen><hyphen> hack, I think this is the wrong thing 
to do for many reasons. The biggest one is, sadly, the fact that some 
software now has <letter><letter><hyphen><hyphen> as reserved even 
though it should not.

Further, it is not needed. When you say but some implementations really 
don't like having A/AAA records for names which start with an 
underscore", you could have easily added "...but they allow it with a 
minor configuration change".

The problem you hit was in BIND. To get around it, you simply add 
"check-names master warn;" to the options.

The purpose of the special label in this draft is to mark the whole name 
as being used for testing. Making that more obvious with an underscore 
prefix seems a lot better than making it seem like a label that would 
work in a normal host name.

And if you really hate the _ and want to use 
<letter><letter><hyphen><hyphen>, please do *not* use something that 
will look a lot like an invalid IDN. There are plenty of other choices.

> The authors intend to publish this soon.

Thanks!

--Paul Hoffman

---

From: George Michaelson <[email-masked]>
Date: Wed, 31 Jan 2018 12:49:59 +1000

>The problem you hit was in BIND. To get around it, you simply add "check-names master warn;" to the options.

And with this.. he was good again. So, modulo the implementation
cost/consequence, I'm good here.

But, if this is detail, then I'm back at 10,000ft: noting the IETF is
all about detail, are we mostly good here?

Because.. I really want this closed off.

-G

On Wed, Jan 31, 2018 at 10:58 AM, Paul Hoffman <[email-masked]> wrote:
> <letter><letter><hyphen><hyphen> hack, I think this is the wrong thing to do
> for many reasons. The biggest one is, sadly, the fact that some software now
> has <letter><letter><hyphen><hyphen> as reserved even though it should not.
>
> don't like having A/AAA records for names which start with an underscore",
> you could have easily added "...but they allow it with a minor configuration
> change".
>
> The purpose of the special label in this draft is to mark the whole name as
> being used for testing. Making that more obvious with an underscore prefix
> seems a lot better than making it seem like a label that would work in a
> normal host name.
>
> <letter><letter><hyphen><hyphen>, please do *not* use something that will
> look a lot like an invalid IDN. There are plenty of other choices.
>

---

From: Joe Abley <[email-masked]>
Date: Tue, 30 Jan 2018 22:40:11 -0500

Hi George,

> Because.. I really want this closed off.

I like it, and I am keen for it to be implemented. I dislike Warren's compromise on xm-- for all the reasons Paul mentioned (but also "oh my god no, please no" just on general principles). I would like it to proceed so we can see the kind of swift implementation that will teach us something about the DNS.

I made a comment some time ago in response to someone's (Warren's again, I think, but I'm not sure) observed confusion in others about the draft. I recall that I suggested that the draft include some explicit advice for all the various actors here (resolver implementers, zone managers) so that it was more clear who was doing what.

I'm stil willing to contribute text if anybody cares, since I seem to remember feeling correct about that observation, and I don't *think* I have noticed a rev of the draft since then, but I also didn't notice any other people say anything like that and I'm perfectly willing to be overwhelmed by the silent majority or to have a more recent revision pointed out to me with the patience normally reserved for the young and the dangerously insane.

Joe

---

From: George Michaelson <[email-masked]>
Date: Wed, 31 Jan 2018 13:56:36 +1000

I stress, I'm not an author on this one. I'm also heavily biassed by
role and relationship(s) with the authors.

I'm trying to play nice, in that context: I want it shipped. I think
its a net useful contribution.

So, I think your suggestion of guiding words is good. If it was my
draft, I'd welcome them.

But... its not my draft.

I guess .. its "all of us's draft" now. So.. hells yea. Write words.

-G

---

From: Ray Bellis <[email-masked]>
Date: Wed, 31 Jan 2018 10:10:50 +0000

> "check-names master warn;" to the options.

If you're doing that, please put it in the zone specific stanza, and not
in the global options for the server:

zone "foo" {
   type master;
   check-names warn;
   ...
};

Ray

---

From: Robert Story <[email-masked]>
Date: Wed, 31 Jan 2018 05:36:12 -0500

On Tue 2018-01-30 22:40:11-0500 Joe wrote:
> I made a comment some time ago in response to someone's (Warren's
> again, I think, but I'm not sure) observed confusion in others about
> the draft. I recall that I suggested that the draft include some
> explicit advice for all the various actors here (resolver
> implementers, zone managers) so that it was more clear who was doing
> what.

I agree that the draft should be clearer on who needs to do what.

---

From: Bob Harold <[email-masked]>
Date: Wed, 31 Jan 2018 08:44:22 -0500

On Wed, Jan 31, 2018 at 5:36 AM, Robert Story <[email-masked]> wrote:

> +1

Bob Harold