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

George Michaelson <> Wed, 31 January 2018 02:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EF9AA12EC15 for <>; Tue, 30 Jan 2018 18:50:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vXvaPUs9bZQ5 for <>; Tue, 30 Jan 2018 18:50:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2878412EA8D for <>; Tue, 30 Jan 2018 18:50:00 -0800 (PST)
Received: by with SMTP id l64so12947282qke.13 for <>; Tue, 30 Jan 2018 18:50:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+HM4zXYeOkJViq2700HtzGJobU0A9dkufALOpcpXsqY=; b=HWbB1feike3WDI86Z2BXb7zy33q/XdjmcQkBSc+qTJlZFxT5x6MbmgK0Awts2YsfdM JL4c3dqzavYsALlktfvzQzlZ+OUwUjpoFmcDBBtbwxiTiNF02MgUVD3id0Orn4vVZrPV isFpluLo1EGUMxk9NRPMOZKQZiXjxYeRUK1Tr9QMIhfVtVbaukt9e0lLfxcubmVWCHpH AeOBEfIJmKF9M3OvQR/9wQmsvTWo0T2p/T6BFJ912bua6+m/oGb2lKe1ZTdbUOWwQikW Q8mO7CmYTLK+Qc7cvFAjSfhbfLTjky9vkNWQrTEURT1ZtlW6kM6i7YedG8c94jsGRwi0 R3eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+HM4zXYeOkJViq2700HtzGJobU0A9dkufALOpcpXsqY=; b=lNgkkccRWjxe+yBqFnO5eHYmUjdg5PxPraE6JSOhYW9+MvyFATJzcSsT9YRZflp2SJ WR/b+j685hPK2kVceOuMGahY/aM8xImP/GytJE/I91STTY/82VY+NBkZTNT8kRv7F79U EDlUp2DYyKFWlrZqrf7uEg2JgcLnbzq+xZjYxujvcsyvEljg+wnL2/ptydnTJQVjE4NJ yRxtuyJoS1/GPXy0u8ZkOfI2+3th0F9E26lAmLUqNoS0VXHeorWJf1cS1uwNeNKxDXtD ZYl7Jc72KIGwHQW37AA2TGvO+Rc/CH6ASVpi6FkJJSeqI+U9KL5ANynZQDSJ0WNANnHd 5ybg==
X-Gm-Message-State: AKwxytcsz9cUODeEbThPrLWz/vp22uYOcN59tBYF0Gllll0NwjxxsAlm XToetLfDAZroa+fEDi8OlItJ5ickiNOU2FuamL8C5g==
X-Google-Smtp-Source: AH8x226EWhdfL/WrrRmNWuf7ySmcb2h5Qh36L4tzUt0fW3t6xzl7nq2n4U817/VWchIluuTajLV6099nSwqj25uJuYM=
X-Received: by with SMTP id r188mr46436230qkf.107.1517367000005; Tue, 30 Jan 2018 18:50:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 30 Jan 2018 18:49:59 -0800 (PST)
X-Originating-IP: [2001:dc0:2001:210:b1bd:7ad4:f7b9:9677]
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: George Michaelson <>
Date: Wed, 31 Jan 2018 12:49:59 +1000
Message-ID: <>
To: Paul Hoffman <>
Cc: Warren Kumari <>, dnsop WG <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Jan 2018 02:50:04 -0000

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


On Wed, Jan 31, 2018 at 10:58 AM, Paul Hoffman <> wrote:
> 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]
>> _not-ta-[key]
>> 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]
>> xm--not-ta-[key]
>> 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
> _______________________________________________
> DNSOP mailing list