Re: [DNSOP] A conversational description of sentinel.

Petr Špaček <petr.spacek@nic.cz> Sun, 04 February 2018 22:35 UTC

Return-Path: <petr.spacek@nic.cz>
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 D7144124BFA for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 14:35:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level:
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 s2FmbSBJA5QR for <dnsop@ietfa.amsl.com>; Sun, 4 Feb 2018 14:35:30 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 CFFB6120721 for <dnsop@ietf.org>; Sun, 4 Feb 2018 14:35:29 -0800 (PST)
Received: from [192.168.0.157] (cable-85.28.109.138.coditel.net [85.28.109.138]) by mail.nic.cz (Postfix) with ESMTPSA id 0051062B47; Sun, 4 Feb 2018 23:35:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1517783728; bh=SufWDWH/Ztrt4wQDrqvWOvvj+/GLU1clcOnnNRpEy1k=; h=To:From:Date; b=yGA8ZaT9xUW5LuasdxyUlBAjCQyowKu7MJBLeXziZefxUIcwjiXs5brEdPuFy3crv uUZgRh+jQ/ZRTMa8JakSvxN6HrKXRtqIwA553dFIeLfTNtX5ZjTReCS11CWJGo+quv 0LAeMQyHPPgP4pH3sNYz8UdEiVf+yrXuFcKkC4bw=
To: dnsop@ietf.org, Geoff Huston <gih@apnic.net>
References: <CAHw9_iKnD4WtTKyof=nm4ChmDZ5mAPqA7a_-m1t_Lauugf4Uow@mail.gmail.com> <alpine.DEB.2.11.1801251505070.5022@grey.csi.cam.ac.uk> <CAHw9_iJ-gwC1ZoWQ3YiJraD3eoUf-9-Ay--rPYzy1zWYUzvYmg@mail.gmail.com> <FDCED4D6-A7CE-465B-8344-CA89753ADF19@vpnc.org> <74C0CA59-6D53-4A60-ACBA-4AF5B51FE3FF@apnic.net> <D5D013D4-1EAD-434B-863A-29CB1BBEF4E4@vpnc.org> <496EFA88-BA70-460B-BFB2-69B2C7BC905D@apnic.net> <4540A279-4A37-4245-AE61-BEE5342E3F72@vpnc.org> <20180202075530.Horde.UWaxe9eenZ7PyxWYFHCFGdN@andreasschulze.de> <e8ac7bd0-26e6-cf97-e2ef-0ead50dc18ce@nic.cz> <88E7D27C-048E-44CB-B317-C892EA603D31@isc.org> <0c2a4a38-49d7-2b46-1ac8-1dda0812e217@nic.cz> <CAHw9_iJ6yL12OaGW5+fm8M3YUkrj46CvC2-ob7Xrc5HEaA_Z1Q@mail.gmail.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <f9861a96-a930-bd08-7cf5-5c6b003f706e@nic.cz>
Date: Sun, 04 Feb 2018 23:35:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <CAHw9_iJ6yL12OaGW5+fm8M3YUkrj46CvC2-ob7Xrc5HEaA_Z1Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XBKZrwAENupkwJ0yKRhgexxC2iM>
Subject: Re: [DNSOP] A conversational description of sentinel.
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: Sun, 04 Feb 2018 22:35:33 -0000

On 2.2.2018 16:45, Warren Kumari wrote:
> On Fri, Feb 2, 2018 at 4:41 AM, Petr Špaček <petr.spacek@nic.cz> 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?
Huh, this totally surprised me, but yeah, data trumphs any intuition here.

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

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-rfcXXXX-dnssec-root-trust-anchor-key-trusted-yes-0000
(63 octets, unlikely to colide with anything, self-explanatory)
test-name-rfcXXXX-dnssec-root-trust-anchor-key-trusted-no-0000
(62 octets)

Opinions?

Geoff, is it realistic to test that clients are able to resolve A
records containing these leftmost labels?

Petr Špaček  @  CZ.NIC


> 
> 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. AAAA
>> 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 <petr.spacek@nic.cz> 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