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

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 31 January 2018 00:58 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F29E1250B8 for <dnsop@ietfa.amsl.com>; Tue, 30 Jan 2018 16:58:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emFdbKeNDDYB for <dnsop@ietfa.amsl.com>; Tue, 30 Jan 2018 16:58:03 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC3512EAB0 for <dnsop@ietf.org>; Tue, 30 Jan 2018 16:58:03 -0800 (PST)
Received: from [10.32.60.98] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w0V0vjE7098045 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Jan 2018 17:57:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.98]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: "Warren Kumari" <warren@kumari.net>
Cc: "dnsop WG" <dnsop@ietf.org>
Date: Tue, 30 Jan 2018 16:58:01 -0800
X-Mailer: MailMate (1.10r5443)
Message-ID: <344C35F8-30C0-4705-8B96-A8E07FDCC34C@vpnc.org>
In-Reply-To: <CAHw9_iJObyd4KPL9BsnARDCf-qaS_eYCMuWnn0SV+10OeYzgoQ@mail.gmail.com>
References: <151062636258.5917.14497839377888768972@ietfa.amsl.com> <20180128080134.24987d69@titan.int.futz.org> <CAHw9_iLDid5-3JJ5gffdsR_PMCAEwwxB3i7ORLiBVtKwmt0khQ@mail.gmail.com> <20180129233755.3697ee79@grisu.home.partim.org> <20180130152459.GE18485@mx4.yitter.info> <9787FD03-4E91-46DC-92E0-85513D6A9B40@hopcount.ca> <20180130185128.GI19193@mx4.yitter.info> <CAKr6gn0LSjtJL_zci1i=aUYq6bd7vDos_QfiEiS=W0kygXS_MQ@mail.gmail.com> <CAHw9_iJObyd4KPL9BsnARDCf-qaS_eYCMuWnn0SV+10OeYzgoQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eNrdymCV4lUR8hk9u5OECYnfKXM>
Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Jan 2018 00:58:05 -0000

On 30 Jan 2018, at 16:29, Warren Kumari wrote:

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

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

Thanks!

--Paul Hoffman