From nobody Tue Aug 1 03:49:17 2017 Return-Path: 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 420B8132CFB for ; Tue, 1 Aug 2017 03:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 N-ak5Df14PjB for ; Tue, 1 Aug 2017 03:49:13 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F55132CF6 for ; Tue, 1 Aug 2017 03:49:13 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id x3so11526468oia.1 for ; Tue, 01 Aug 2017 03:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yOXh8MnnriB32nyq3WLpHBT/d5zMrCSe8+CcXwZa9Oo=; b=cLxy5FdaTLbdsKRN4r1DsyNSpKsEbCAA3zXB117jG7bTK+eE9wj+x8Exx6DaZmFWiE dk83KIVNObmgjEPTvm4vNJhkE3w8DkHvPEBczRP7kPv+KX8b1WsP+c2rwpxaCf/lkPyI FkFSsnotf+AtJZNvSp3ze1fOndoCFS09n124sVsgi04Lms5+UrWx9FZAfXoZ1AK2FuZp SEDfBMm3PdEtxI741FO1iizh3qXqdl32KSALqctnQuhc8Zacp7sN5YIXbQGFpbMcscTk WRwNKV+2GOEi307tjokPq0rnX+L3KCufaKoK5Dm2yGsBXLeGpGzrx0TPCQGX1rabcsLm TT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yOXh8MnnriB32nyq3WLpHBT/d5zMrCSe8+CcXwZa9Oo=; b=ClcpYn1c8/uaqSv2ZAA41UOsVYWht6f10/1PBEE2XmtaFtH0O2E6bdjNWwCVQlVGKY PBEGBSA1+V+8zgSGXxJ04xcDVjcdt7vfcFEh3q/GnnIIXeChm0OY66LBaEmcvfbTXkR7 67rq7yiVy7nH4VPEQByiGaSqFFSwBrpLoItlDe2EN276+KWvxM5PBSBF24vidyqyz/TP jcmfO3rcWQLGLqu3d/W+bY292tVUG7btaHumUh7vvT1aKwPVjWs+I2oX7DQyMR3HHPFl yuM9hCLj4KdqrtEW2ULcISzIwpZ3lbBN9xg4bpMGpba/hvOrZhcmmg+upQ0f9QOQwEvH chjQ== X-Gm-Message-State: AIVw111AvvpzG4RSMTkVIlc+aX2IDwln+siYuztP0gxftuXzo1oaeptq EQremnoK6safU3lJwRwgkX5lggIJBjoo X-Received: by 10.202.199.138 with SMTP id x132mr15100487oif.52.1501584552353; Tue, 01 Aug 2017 03:49:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.47.5 with HTTP; Tue, 1 Aug 2017 03:48:51 -0700 (PDT) In-Reply-To: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> From: Mike West Date: Tue, 1 Aug 2017 12:48:51 +0200 Message-ID: To: Jacob Hoffman-Andrews Cc: dnsop WG , Suzanne Woolf , Richard Barnes , John R Levine Content-Type: multipart/alternative; boundary="001a11c18044d883fe0555aee59e" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Tue, 01 Aug 2017 10:49:15 -0000 --001a11c18044d883fe0555aee59e Content-Type: text/plain; charset="UTF-8" Hey Jacob, thanks for flagging this! I'm also interested in getting this draft moving again, and I'm willing to poke at it in whatever ways the group's happy with. The only open issue I know of is some discussion in the thread at https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I need help synthesizing into the draft. I don't know enough about the subtleties here to have a strong opinion, and I'm happy to accept the consensus of the group. Coincidental, I raised the draft again briefly with a few folks in Prague (CC'd here), and I'm hoping for some feedback about reasonable next steps. -mike On Tue, Aug 1, 2017 at 1:17 AM, Jacob Hoffman-Andrews wrote: > Hi, > > I'm interested in seeing > https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03 > move from draft status to become a standard. In particular, it would > allow browsers to start treating "localhost" as a secure context, which > would reduce attempts by application developers to abuse the public Web > PKI in order to issue certificates for localhost, which harms security. > See: > > https://groups.google.com/d/msg/mozilla.dev.security. > policy/T6emeoE-lCU/-k-A2dEdAQAJ > https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/ > wsj5zpbbAQAJ > > What further steps are needed to move this draft along, and how can I help? > > Thanks, > Jacob > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a11c18044d883fe0555aee59e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Jacob, thanks for flagging this! I'm also interest= ed in getting this draft moving again, and I'm willing to poke at it in= whatever ways the group's happy with.

The only open= issue I know of is some discussion in the thread at https://www.ietf.or= g/mail-archive/web/dnsop/current/msg18690.html that I need help synthes= izing into the draft. I don't know enough about the subtleties here to = have a strong opinion, and I'm happy to accept the consensus of the gro= up.

Coincidental, I raised the draft again briefly= with a few folks in Prague (CC'd here), and I'm hoping for some fe= edback about reasonable next steps.

-mike
<= /div>

On Tue, Aug 1, 2017 at 1:17 AM, Jacob Hoffma= n-Andrews <jsha@eff.org> wrote:
Hi,

I'm interested in seeing
https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03
move from draft status to become a standard. In particular, it would
allow browsers to start treating "localhost" as a secure context,= which
would reduce attempts by application developers to abuse the public Web
PKI in order to issue certificates for localhost, which harms security. See= :

https://groups.g= oogle.com/d/msg/mozilla.dev.security.policy/T6emeoE-lCU/-k-A= 2dEdAQAJ
https://groups.g= oogle.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/wsj5= zpbbAQAJ

What further steps are needed to move this draft along, and how can I help?=

Thanks,
Jacob

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

--001a11c18044d883fe0555aee59e-- From nobody Tue Aug 1 11:53:39 2017 Return-Path: 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 0989F1322AF for ; Tue, 1 Aug 2017 11:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 NKYitai43Wr0 for ; Tue, 1 Aug 2017 11:53:34 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 821B81322A1 for ; Tue, 1 Aug 2017 11:53:34 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x191so14458929qka.5 for ; Tue, 01 Aug 2017 11:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3+CPQr56zyyMKLAUAUhQO/OIFTbBAe2WrsNf2qT2imA=; b=J08uPlFE22wCnUz728Z4QNktygnJuuHiBg1ub2smZC21RuJG7YYJ5pWI+5jpk0nTwU Pcv6l9E3UO0htSw2YAu4dFSJsmsB4z/QztI0KZJUX6jBWvIoe++1UnrKt17xK94Z3sz3 iN2sSD573zqWJkhLA+TcT51wB2vVOq9dEzl1zP1Uuu0+aQnD8hcsnbcwhZmoQcXqf1n0 bw6dtRKehgUXerp6uT0jA+Z4K9+2R4aEoY5HujhCWlOdAdu0hFoqtkzQ1aMh1ddwA30c jUM1UB4JM6dF/kslS7fbSOF29zX52OI3BeAMeUZyvRMRwRzuXnkcNXONBUNwV1ZKk1Uc qxnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3+CPQr56zyyMKLAUAUhQO/OIFTbBAe2WrsNf2qT2imA=; b=k83svOX8kUZsmcMHzReYiJhZFSg5yjPDx/n2ltQglCfGqSMy1x89wIegRndcnqHrWt QQ9zrUz+bkLhCC1zOA+k1vSe9ZRFvXAYWzG3mW0q2hi5JVL5YFf16n+ua8B1ZcAurTMy jdhxAhQJog0ZMPzL/uDrT5zjRiXs9anMhSS5pDNJoQdm92bY642fm7ValZSEuvOx5GCf +6B4CS99Y9pBS+fL2+6iAnAGDE36CNdzff391bzXiLD+ZkUIhxJ3XWG/zCK7ESwVIcjd qQJ7uzeD4yllpwxvg2R01HHYpE7wP2ffekSGZcgmbBLhXBQoEG0Xuhd4UUqwYXGHt5Ae evjw== X-Gm-Message-State: AIVw1125ZSe14AWmGnka6u3ZDm5kXEz+mVcUvX9193H0dcghpQV2Mt9D nqcWx3F2Szky1K6FE/TGNwlcnO2QDw== X-Received: by 10.55.40.194 with SMTP id o63mr25325284qko.310.1501613613393; Tue, 01 Aug 2017 11:53:33 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 1 Aug 2017 11:53:33 -0700 (PDT) In-Reply-To: <08EEC562-8BD2-4485-9D7D-73665CF94EC5@hopcount.ca> References: <08EEC562-8BD2-4485-9D7D-73665CF94EC5@hopcount.ca> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 1 Aug 2017 11:53:33 -0700 X-Google-Sender-Auth: S-rnxWPuCsvRrAAdp3DSPFts49g Message-ID: To: Joe Abley Cc: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] =?utf-8?q?draft-ietf-dnsop-refuse-any=3A_points_from_?= =?utf-8?b?56We5piO6YGU5ZOJ?= X-BeenThere: dnsop@ietf.org 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: Tue, 01 Aug 2017 18:53:37 -0000 Hi, sorry for the delayed response. At Tue, 25 Jul 2017 16:53:12 -0400, Joe Abley wrote: > https://mailarchive.ietf.org/arch/msg/dnsop/zy86pvg139PaKFXo-BO6SPUfh3k > > > I've reviewed the 04 version. I still do not think it's ready to move > > forward as it still abuses HINFO. I understand some other people > > don't care about this point, and some others may even love the idea > > (those who are using it right now). But I've also seen yet some other > > people have the same concern, so it shouldn't be only me. I don't > > think we have a clear consensus on this point yet. > > The draft at present doesn't require an implementer to abuse HINFO; > it provides options to avoid doing so whilst still meeting the > described objectives of the proposal. Since abusing HINFO is not > mandatory, I presume you are objecting to the proposal sanctioning > such shenanigans at all. (If I understand the subtle nuance of this text:-) I think your understanding is correct. > > If I have that right (please correct me if I'm wrong) I don't think > I am the right person to make the call, being just a lowly document > scribe. If this remains a concern for you, I suggest that we defer > that question to our chairs and ask them to gauge consensus. My own Agreed - I think we have to agree to disagree here and I think neither of us can convince the other. It should better be left to the wg decision. > personal views of pragmatism vs. elegance shouldn't enter into it; > this is a working group document. > > To be hopefully a bit more productive, I have a specific counter > > proposal: remove the mandatory text about the use of HINFO, e.g., > > > > - remove this bullet from section 4 > > 2. A DNS responder can return a synthesised HINFO resource record. > > See Section 6 for discussion of the use of HINFO. > > - remove ', in which case...' from Section 4.2 > > If there is no CNAME present at the owner name matching the QNAME, > > the resource record returned in the response MAY instead be > > synthesised, in which case a single HINFO resource record SHOULD be > > returned. > > > > In fact, in terms of externally observable behavior, synthesizing > > HINFO is just one form of "selecting one RRset of the QNAME"; the > > HINFO is added and immediately removed at the time of answering the > > ANY query, so in that sense we don't have to bother to mention it with > > normative keywords. > > This text suggests that my interpretation above is wrong, and what > you are objecting to is just the way that the HINFO approach is > described. I think the specification is more clear if we spell out > the whole synth-HINFO approach in its entirety and don't try to > subsume it into the "return a subset of { RRSets that there } u { > RRSets that we just synthesised }". (As I said above) I believe you interpreted my objection correctly. This suggestion was an attempt of compromise, assuming people already (ab)using HINFO want to continue their practice. [...] > I am not sure I understand the benefit of not including it, given > that it is observable behaviour for a large number of domains today > (even if that is so due to the volume of domains hosted at a single > operator). I think we do better service to operators and > implementors by describing what is implemented. As you point out, > Cloudflare's implementation may be less general-purpose than BIND9 > or NSD, and that might be a reason for the implementation choices to > be different. Cloudflare is unlikely to be the last non-general > implementation, however, so perhaps the mechanism most appropriate > there will be relevant to others. I agree that being silent for existing deployment may not be ideal. If we (wg) can reach a consensus that the HINFO-based approach is an abuse, however, we can think of other way to address it. For example, we could mention it and clarify that it should be considered an abuse, should be discouraged, and newer implementations should use other approaches. My suggestion was just based on the anticipation that we can probably not reach this kind of consensus (especially about the discouragement). > > I've also noticed a couple of other points I raised in my previous > > review ( > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18746.html > > ) > > were not yet addressed. These are (section numbers are for 03): > > > > - Section 3 > > > > 1. A DNS responder can choose to select one or subset of RRSets at > > the QNAME. > > > > 'one or subset of RRSets' sounds a bit awkward to me > > I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset" seems wrong, actually; since some vestigial fragment of a set theory lecture in the depths of my pre-history is telling me that the empty set is always a valid subset. > > > - Section 4 > > > > A DNS responder which receives an ANY query MAY decline to provide a > > conventional response, or MAY instead send a response with a single > > RRSet in the answer section. > > > > "a single RRSet" doesn't seem to be fully consistent of "one or > > subset of RRSets" stated in the preceding section (see the previous > > bullet). > > Agreed. That should be made consistent. Regarding these two, we've already discussed this on ML and I thought we had some consensus. I'd suggest you to look into the archive. -- JINMEI, Tatuya From nobody Tue Aug 1 11:59:45 2017 Return-Path: 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 A0965129AB2 for ; Tue, 1 Aug 2017 11:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 qr1I-Eqmo805 for ; Tue, 1 Aug 2017 11:59:43 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38E141322AF for ; Tue, 1 Aug 2017 11:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=9XwZQpCaZxmSJIdPhaX8P1f5cICO9SagFCXr2pRJhL8=; b=G6kzaYe+nCWOnGJmOfIrLXrmfsvKIzRom0V2T5/Me/ceaQ/m8ph22rMBlGoTUWk9Le9YnvwMXr3F/CXoOqzPgTuhMVXS9V1V4qUeI/mf2itwSCh68tTtbaGV8TTlaQsYdS8cxp8kkqY8uoKeDsX7S/wcPw5q+VWTTr1eCfblEfw=; Received: ; Tue, 01 Aug 2017 11:59:41 -0700 To: dnsop@ietf.org References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> From: Jacob Hoffman-Andrews Message-ID: <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> Date: Tue, 1 Aug 2017 11:59:42 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Tue, 01 Aug 2017 18:59:44 -0000 On 08/01/2017 03:48 AM, Mike West wrote: > The only open issue I know of is some discussion in the thread at > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I > need help synthesizing into the draft. I don't know enough about the > subtleties here to have a strong opinion, and I'm happy to accept the > consensus of the group. Reading back through this thread, it seems like the concerns were about how to represent the ".localhost" TLD in the root zone, or how to use DNSSEC to express that the root zone will not speak for ".localhost". However, I think we don't need either. This draft attempts to codify the idea that queries for "localhost" or "foo.localhost" should never leave the local system, and so it doesn't matter what the root zone says about ".localhost". I would even take it a step further: It would be a mistake to add any records for ".localhost" to the root zone, because it would mask implementation errors. If a local resolver accidentally allows a query for "foo.localhost" to hit the wire, it should result in an error. IMHO, the document is good as it stands. From nobody Tue Aug 1 16:36:32 2017 Return-Path: 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 89410129ADA for ; Tue, 1 Aug 2017 16:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 FeV0zPzZRtQu for ; Tue, 1 Aug 2017 16:36:28 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F459126CD6 for ; Tue, 1 Aug 2017 16:36:28 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 1 Aug 2017 16:36:25 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Tue, 1 Aug 2017 16:36:25 -0700 From: Richard Lamb To: Mark Andrews , Tony Finch CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] CDS/CDNSKEY RRSet authentication Thread-Index: AQHTCK3LJhx9rEooSEGyV8mpBhYmkqJrhxDygASk34A= Date: Tue, 1 Aug 2017 23:36:25 +0000 Message-ID: <8ae21b517cc247359a045fd56492b2f9@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <20170730003832.EF6828069BE6@rock.dv.isc.org> In-Reply-To: <20170730003832.EF6828069BE6@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication X-BeenThere: dnsop@ietf.org 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: Tue, 01 Aug 2017 23:36:30 -0000 Good catch. Thanks for identifying this and making it signed by both. -Ric= k > -----Original Message----- > From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Mark Andrews > Sent: Saturday, July 29, 2017 5:39 PM > To: Tony Finch > Cc: dnsop@ietf.org > Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication >=20 >=20 > In message , > Tony Finch > writes: > > I think I have spotted a lacuna or possibly erratum in RFC 7344. > > > > In section 4.1 bullet 2 it says: > > > > o Signer: MUST be signed with a key that is represented in both the > > current DNSKEY and DS RRsets, unless [unusual case] >=20 > It just means that signers that know about ksk/zsk have special rules for= cds > and cdnskey. This is from BIND's dnssec-signzone and causes the cds and > cdnskey rrsets to be signed with both ksk and zsk dnskeys. >=20 > } else if (set->type =3D=3D dns_rdatatype_cds || > set->type =3D=3D dns_rdatatype_cdnskey || > iszsk(key)) { >=20 From nobody Tue Aug 1 18:24:00 2017 Return-Path: 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 92101129A96 for ; Tue, 1 Aug 2017 18:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 0gM5e3-dh7MV for ; Tue, 1 Aug 2017 18:23:57 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEE8126D46 for ; Tue, 1 Aug 2017 18:23:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 408FF24AE0D; Wed, 2 Aug 2017 01:23:43 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 6FBDE160041; Wed, 2 Aug 2017 01:23:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5598516004A; Wed, 2 Aug 2017 01:23:48 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0Pk05Qt3pF7v; Wed, 2 Aug 2017 01:23:48 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 071DE160041; Wed, 2 Aug 2017 01:23:48 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 2CE2680BCC5E; Wed, 2 Aug 2017 11:23:45 +1000 (AEST) To: Jacob Hoffman-Andrews Cc: dnsop@ietf.org From: Mark Andrews References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> In-reply-to: Your message of "Tue, 01 Aug 2017 11:59:42 -0700." <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> Date: Wed, 02 Aug 2017 11:23:45 +1000 Message-Id: <20170802012345.2CE2680BCC5E@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 01:23:59 -0000 In message <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org>, Jacob Hoffman-Andrews writes: > On 08/01/2017 03:48 AM, Mike West wrote: > > The only open issue I know of is some discussion in the thread at > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I > > need help synthesizing into the draft. I don't know enough about the > > subtleties here to have a strong opinion, and I'm happy to accept the > > consensus of the group. > > Reading back through this thread, it seems like the concerns were about > how to represent the ".localhost" TLD in the root zone, or how to use > DNSSEC to express that the root zone will not speak for ".localhost". > However, I think we don't need either. This draft attempts to codify the > idea that queries for "localhost" or "foo.localhost" should never leave > the local system, and so it doesn't matter what the root zone says about > ".localhost". > > I would even take it a step further: It would be a mistake to add any > records for ".localhost" to the root zone, because it would mask > implementation errors. If a local resolver accidentally allows a query > for "foo.localhost" to hit the wire, it should result in an error. > > IMHO, the document is good as it stands. The query for foo.localhost doesn't need to hit-the-wire for this to be a issue. Ask your self why RFC 6303, Security section has As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA namespaces, the zones listed above will need to be delegated as insecure delegations, or be within insecure zones. This will allow DNSSEC validation to succeed for queries in these spaces despite not being answered from the delegated servers. or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa". We didn't add the requirement for insecure delegations for the fun of it. We added it so that the tools that validate will not break when those names are being used. The only difference between the names in the above documents and .localhost is the size of the space where they are valid. It is restricted to the node rather than the site. Mark > _______________________________________________ > 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: marka@isc.org From nobody Wed Aug 2 01:55:15 2017 Return-Path: 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 2CF29131C9D for ; Wed, 2 Aug 2017 01:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 vPBFSVDnnvgZ for ; Wed, 2 Aug 2017 01:55:11 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 954FE131D36 for ; Wed, 2 Aug 2017 01:55:11 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id u133so15435833vke.3 for ; Wed, 02 Aug 2017 01:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6tqh/NbISgOemPhFhsW0InDlufZ8fO7EpDEkS9CyTeI=; b=rN4zLB1AS39/M+ijCEnQr+fRcce1vtvrVvnJIEaj+sWdNiqWnz7OGx2D7XOAjbb2Jt t/M1rl9XHrNON+O2ymA2MzBiLTYeEJtTFGk7mVuXqczLUoWR0HJSmS6qf3xvMBaOlFRL Gz8AqckzOJ0/ktKPSrNrzHhiPZw0OCbwsRpwEcvBv2RQD2xsZ+mRK2mRsS0QYGFN4R3t YLKHV9Hjl/BmvDuAKaU1U0eL6Zx3M8IoQm8S/HvItOn6zsD4FQ3mVsC/IfMx2sjmh9bE 1CcdjGd6z8+7DUIbn2ubGGY8jVOaAjwlknhDNWv8LGPMwfkUhY3gITUFCE2YJizxSL2d iZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6tqh/NbISgOemPhFhsW0InDlufZ8fO7EpDEkS9CyTeI=; b=odf7sls0PbRuKaYl+JvMnMfP/EeV77dL4J1ZERTipzF+Y4RcFcWilUjhx6SW9ovYjg JuL9ylcl5oHITKynLCFRNKIyjRppduKKD52OipMwhcCDCz7DEXxO7Hzz4Y2G1uUB3Q0+ O8vPhgUxVDNeJgcaeJjkb1Yt6A7QadeoDbiFRF9Mtnsp/6Ph6RpU+j/S+sYihm0Jvr6p QwRHX/IUXaCKoRc3lLImeUY46tmI+ouOzloIWtbq+vnFWnRfR0E15SOxA5x9dcLO0rxa 2hJyJ+h0paVEQU1Oa10tuhX+kIvgE+aUxZMGxWmh/zVRgF41WSdbHOd3U0kN985THZWd QAmA== X-Gm-Message-State: AIVw112v1MBtAp8G/P5eydVBmm6feCeMl8g3JkIH64RUNEg70w0yilfv nggECibVz+HEfj6gBWbbW3zQCHwaGZkZ X-Received: by 10.31.8.82 with SMTP id 79mr15137743vki.93.1501664110522; Wed, 02 Aug 2017 01:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.82.1 with HTTP; Wed, 2 Aug 2017 01:54:50 -0700 (PDT) In-Reply-To: <20170802012345.2CE2680BCC5E@rock.dv.isc.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> From: Mike West Date: Wed, 2 Aug 2017 10:54:50 +0200 Message-ID: To: Mark Andrews Cc: Jacob Hoffman-Andrews , dnsop WG Content-Type: multipart/alternative; boundary="001a1143dd90e1b7170555c16be0" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 08:55:14 -0000 --001a1143dd90e1b7170555c16be0 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 3:23 AM, Mark Andrews wrote: > In message <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org>, Jacob > Hoffman-Andrews writes: > > On 08/01/2017 03:48 AM, Mike West wrote: > > > The only open issue I know of is some discussion in the thread at > > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html > that I > > > need help synthesizing into the draft. I don't know enough about the > > > subtleties here to have a strong opinion, and I'm happy to accept the > > > consensus of the group. > > > > Reading back through this thread, it seems like the concerns were about > > how to represent the ".localhost" TLD in the root zone, or how to use > > DNSSEC to express that the root zone will not speak for ".localhost". > > However, I think we don't need either. This draft attempts to codify the > > idea that queries for "localhost" or "foo.localhost" should never leave > > the local system, and so it doesn't matter what the root zone says about > > ".localhost". > > > > I would even take it a step further: It would be a mistake to add any > > records for ".localhost" to the root zone, because it would mask > > implementation errors. If a local resolver accidentally allows a query > > for "foo.localhost" to hit the wire, it should result in an error. > > > > IMHO, the document is good as it stands. > > The query for foo.localhost doesn't need to hit-the-wire for this > to be a issue. Ask your self why RFC 6303, Security section has > > As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA > namespaces, the zones listed above will need to be delegated as > insecure delegations, or be within insecure zones. This will > allow DNSSEC validation to succeed for queries in these spaces > despite not being answered from the delegated servers. > > or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa". > > We didn't add the requirement for insecure delegations for the fun > of it. We added it so that the tools that validate will not break > when those names are being used. > > The only difference between the names in the above documents and > .localhost is the size of the space where they are valid. It is > restricted to the node rather than the site. > Thanks for the feedback, Mark! What would you like to see in the document in order to address this concern? A requirement that a `localhost` zone be created and delegated as an insecure delegation, using some of the language from the draft above (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record, and MUST point to one or more black hole servers, for example ' blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")? -mike --001a1143dd90e1b7170555c16be0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 2, 2017 at 3:23 AM, Mark Andrews <marka@isc.org> wrote:<= br>
In message <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org>, Jacob Hoffm= an-Andrews writes:
> On 08/01/2017 03:48 AM, Mike West wrote:
> > The only open issue I know of is some discussion in the thread at=
> > https://www.ietf.org/mail= -archive/web/dnsop/current/msg18690.html that I
> > need help synthesizing into the draft. I don't know enough ab= out the
> > subtleties here to have a strong opinion, and I'm happy to ac= cept the
> > consensus of the group.
>
> Reading back through this thread, it seems like the concerns were abou= t
> how to represent the=C2=A0 ".localhost" TLD in the root zone= , or how to use
> DNSSEC to express that the root zone will not speak for ".localho= st".
> However, I think we don't need either. This draft attempts to codi= fy the
> idea that queries for "localhost" or "foo.localhost&quo= t; should never leave
> the local system, and so it doesn't matter what the root zone says= about
> ".localhost".
>
> I would even take it a step further: It would be a mistake to add any<= br> > records for ".localhost" to the root zone, because it would = mask
> implementation errors. If a local resolver accidentally allows a query=
> for "foo.localhost" to hit the wire, it should result in an = error.
>
> IMHO, the document is good as it stands.

The query for foo.localhost doesn't need to hit-the-wire for thi= s
to be a issue.=C2=A0 Ask your self why RFC 6303, Security section has

=C2=A0 =C2=A0As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
=C2=A0 =C2=A0namespaces, the zones listed above will need to be delegated a= s
=C2=A0 =C2=A0insecure delegations, or be within insecure zones.=C2=A0 This = will
=C2=A0 =C2=A0allow DNSSEC validation to succeed for queries in these spaces=
=C2=A0 =C2=A0despite not being answered from the delegated servers.

or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa&qu= ot;.

We didn't add the requirement for insecure delegations for the fun
of it.=C2=A0 We added it so that the tools that validate will not break
when those names are being used.

The only difference between the names in the above documents and
.localhost is the size of the space where they are valid.=C2=A0 It is
restricted to the node rather than the site.

Thanks for the feedback, Mark!

What would yo= u like to see in the document in order to address this concern? A requireme= nt that a `localhost` zone be created and delegated as an insecure delegati= on, using some of the language from the draft above (e.g. "This delega= tion MUST NOT be signed, MUST NOT include a DS record, and MUST point to on= e or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.&#= 39;.")?

-mike
--001a1143dd90e1b7170555c16be0-- From nobody Wed Aug 2 03:39:52 2017 Return-Path: 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 1C499131EB8 for ; Wed, 2 Aug 2017 03:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 vwDNNFgHKhIz for ; Wed, 2 Aug 2017 03:39:49 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29706131EAD for ; Wed, 2 Aug 2017 03:39:49 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g13so18642418ioj.5 for ; Wed, 02 Aug 2017 03:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rwGtgo/syosi6EC7k4cxBmaLfmEEljud9Wo42qj6Xw0=; b=hjI+sOFWVaBnSTyVSGZi5lwfiPFeMmHca9CPe1qeeLYGDfT6HHH93PRviTDJMMXlyP b8n3r0lB1GIVODXggE+nhIcJMcOYQgJIYZW0LNueztvHHyJNph3acAf0sV4/M9PkdLu1 uetwNbrSi/PaDgTJTQbgfjLpgPLFrPzqZA7GKT2ou36cg9WZg960r2KnroQFzopt6X7B OH2LYZV7GJQUZkOL6q4lvfusxWHemPePlxI+kvr9y53bbhWYSByfmbzWY88ChFE93u3L VJxQO5D2/JJ3Him/GILm0rBT0MjFex3lPgbjcbzOudvcPT2BNq0dsXo5MxTOmtVHUmfx x1oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rwGtgo/syosi6EC7k4cxBmaLfmEEljud9Wo42qj6Xw0=; b=FCumUCs20juGuvMGvyqSEKVoxNPA1puJIZogqo+V7/o9upt1sArLkrf0T1H8xE6/e/ JbFTuHIxjvPtNE5d4ZmT4c99sKnPAFQh+VFeWZdE8/uaTFVJr/26h3lDgSvk8Hv0Zf6b CvJklXSfjoi2V3CDK7oCAKxlPBQi89PN43oRU/VeUGnuglUv7F06tP+kw6oOmKT8HH77 1S79dJTraeqND0LgSz4gpjCCfplSPB8w5B9RDmUwgId6DnuyBEXBfS5wiXpuAPSmHvxz 8x+mYdW6vUjAlSXFXZidEXrua9MuXIth9yI3pXwwM9Pb7wpmZzTFMpR1Bo4/dd4Ru5Rj +12A== X-Gm-Message-State: AIVw111mZ5a3qqneEdMy04SCg1EOcPgiEGaGL9DSVfg03sivfBqFVBII wuDYnns8D+o1rl4zLOTF09Bob48CAA== X-Received: by 10.107.134.87 with SMTP id i84mr25294575iod.293.1501670388533; Wed, 02 Aug 2017 03:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.160.146 with HTTP; Wed, 2 Aug 2017 03:39:47 -0700 (PDT) In-Reply-To: <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> From: william manning Date: Wed, 2 Aug 2017 03:39:47 -0700 Message-ID: To: Jacob Hoffman-Andrews Cc: dnsop Content-Type: multipart/alternative; boundary="001a113f0b82140e2c0555c2e284" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 10:39:51 -0000 --001a113f0b82140e2c0555c2e284 Content-Type: text/plain; charset="UTF-8" localhost is just a string, like www or mail or supralingua. A DNS operator may chose to map any given string to any given IP address. restricting ::1 so that it never leaves the host is pretty straight forward. if I map localhost to 3ffe::53:dead:beef and NOT ::1 in my systems, why should you care? if you are concerned that completion logic is broken in resolvers and the string "localhost" is not appended to the domain, then you really are asking for the root servers to backstop the query with an entry for localhost. and for the first 20 years of the DNS, there was an entry for localhost. in many of the root servers. it was phased out for several reasons, two key ones were DNSSEC and the fact that most resolvers had corrected their broken completion logic. There is no good reason to bring it back for special processing. It's just a string. /Wm On Tue, Aug 1, 2017 at 11:59 AM, Jacob Hoffman-Andrews wrote: > On 08/01/2017 03:48 AM, Mike West wrote: > > The only open issue I know of is some discussion in the thread at > > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I > > need help synthesizing into the draft. I don't know enough about the > > subtleties here to have a strong opinion, and I'm happy to accept the > > consensus of the group. > > Reading back through this thread, it seems like the concerns were about > how to represent the ".localhost" TLD in the root zone, or how to use > DNSSEC to express that the root zone will not speak for ".localhost". > However, I think we don't need either. This draft attempts to codify the > idea that queries for "localhost" or "foo.localhost" should never leave > the local system, and so it doesn't matter what the root zone says about > ".localhost". > > I would even take it a step further: It would be a mistake to add any > records for ".localhost" to the root zone, because it would mask > implementation errors. If a local resolver accidentally allows a query > for "foo.localhost" to hit the wire, it should result in an error. > > IMHO, the document is good as it stands. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113f0b82140e2c0555c2e284 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
localhost is just a string, like www or mail or supralingu= a.=C2=A0 A DNS operator may
chose to map any given string to any given = IP address. =C2=A0restricting =C2=A0::1 =C2=A0so that it never leaves
=
the host is pretty straight forward. =C2=A0if I map localhost to 3ffe:= :53:dead:beef and NOT ::1 in my
systems, why should you care? =C2= =A0
if you are concerned that completion logic is broken in resol= vers and the string "localhost" is not=C2=A0
appended t= o the domain, then you really are asking for the root servers to backstop t= he query with
an entry for localhost. =C2=A0and for the first 20 = years of the DNS, there was an entry for localhost. in=C2=A0
many= of the root servers. =C2=A0it was phased out for several reasons, two key = ones were DNSSEC and=C2=A0
the fact that most resolvers had corre= cted their broken completion logic.
There is no good reason to br= ing it back for special processing.=C2=A0 It's just a string.

/Wm

On Tue, Aug 1, 2017 at 11:59 AM, Jacob Hoffman-Andrews <jsha@eff.= org> wrote:
On 08/01/2017 0= 3:48 AM, Mike West wrote:
> The only open issue I know of is some discussion in the thread at
> https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that I
> need help synthesizing into the draft. I don't know enough about t= he
> subtleties here to have a strong opinion, and I'm happy to accept = the
> consensus of the group.

Reading back through this thread, it seems like the concerns were about
how to represent the=C2=A0 ".localhost" TLD in the root zone, or = how to use
DNSSEC to express that the root zone will not speak for ".localhost&qu= ot;.
However, I think we don't need either. This draft attempts to codify th= e
idea that queries for "localhost" or "foo.localhost" sh= ould never leave
the local system, and so it doesn't matter what the root zone says abou= t
".localhost".

I would even take it a step further: It would be a mistake to add any
records for ".localhost" to the root zone, because it would mask<= br> implementation errors. If a local resolver accidentally allows a query
for "foo.localhost" to hit the wire, it should result in an error= .

IMHO, the document is good as it stands.

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

--001a113f0b82140e2c0555c2e284-- From nobody Wed Aug 2 05:40:37 2017 Return-Path: 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 CB16313207C for ; Wed, 2 Aug 2017 05:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 2kB1qabVv03l for ; Wed, 2 Aug 2017 05:40:34 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B52132070 for ; Wed, 2 Aug 2017 05:40:34 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id m85so40444699wma.0 for ; Wed, 02 Aug 2017 05:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PyQ9dJBzl39Y0bE+wPm6gLPRLAFrqh2VMnok0Kw+680=; b=AiM45TqFZ/caHzNKtS8f7bRHZ8u6mQtdMsvaLeIQp/rYuCWcQkMN9pj93U5YD4bk7j Tg/Lr/TTEj8O/L7RCI1M7NL6hAhUbHQ/vZ/amqDWSTFrIniyA1abWDpJNcMaQMAv1sOU PAGSZWZ3GDTUABxQ4uBLzmvkPPCPJf7DuQ+9WDZvhcLr6TdZYLT61Moi3WtBcCYDv80G zFd5xdCdc1dKDGAWj+8mTbu2xfKwyHceYXp37DTwrfzqlr4CUK9miIhZTho6QpWybM5Y e9Mz707CV1FgOOj0sVSLs+tb2R9al85xpMYDfC+gsKoSKx5ZeBuRpmfXix1fhjNcT5wd P2sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PyQ9dJBzl39Y0bE+wPm6gLPRLAFrqh2VMnok0Kw+680=; b=JA4LVZIvhUCArl0iVYu+ZDDtbU7woyJAK0utAgt90WqmvQ8/bo3V71TP6V6OmXgSzI aPnOHz/+3eUkbdXEfQ7PIi1Qcf/PLk2TOCoFu+Nwr2ObbWVVSv09CcF/URIGbjwHfjV2 VRX6gWaiGZfQT7pD7vXbmgVJPyd/oiI1Uc2MubvTah96c8eaqO3gnVppIhuIF2uM0BK9 +BfAxtE/uKQEZjJ+kiN4vcUkiz8yUbkyDQo9YFiTubkJpEmp2QOmZjpZvzwh2RvoNOqN thF1w33CcTr8U0xx4PUqspHpFgxWLkOzA/GqJc9EdjC2kEUbFOWKmsLfwlMzHLFoLW9m 0Xyw== X-Gm-Message-State: AIVw110vsh9axmbaDtrisg0QnnPpdTQ8G4xoyXZXID1X122m1zCkDLkH wmx8lyiU2DtBjGqbL8D2g8KRCDlMm+Qc X-Received: by 10.28.27.69 with SMTP id b66mr3952978wmb.11.1501677632557; Wed, 02 Aug 2017 05:40:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 05:40:32 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> From: Richard Barnes Date: Wed, 2 Aug 2017 08:40:32 -0400 Message-ID: To: william manning Cc: Jacob Hoffman-Andrews , dnsop Content-Type: multipart/alternative; boundary="001a114b2950db2caa0555c49152" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 12:40:37 -0000 --001a114b2950db2caa0555c49152 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 6:39 AM, william manning wrote: > localhost is just a string, like www or mail or supralingua. A DNS > operator may > chose to map any given string to any given IP address. restricting ::1 > so that it never leaves > the host is pretty straight forward. if I map localhost to > 3ffe::53:dead:beef and NOT ::1 in my > systems, why should you care? > The underlying need here is that application software would like to make use of the fact that it is connecting to "localhost" (vs. other domain names) to make security decisions based on whether traffic is going to leave the host. So if the network layer remaps localhost to something other than a loopback interface without telling the applications, then you're going to have security problems. The point of this document is to avoid this disconnect by discouraging the sorts of remappings you're talking about. --Richard > if you are concerned that completion logic is broken in resolvers and the > string "localhost" is not > appended to the domain, then you really are asking for the root servers to > backstop the query with > an entry for localhost. and for the first 20 years of the DNS, there was > an entry for localhost. in > many of the root servers. it was phased out for several reasons, two key > ones were DNSSEC and > the fact that most resolvers had corrected their broken completion logic. > There is no good reason to bring it back for special processing. It's > just a string. > > /Wm > > On Tue, Aug 1, 2017 at 11:59 AM, Jacob Hoffman-Andrews > wrote: > >> On 08/01/2017 03:48 AM, Mike West wrote: >> > The only open issue I know of is some discussion in the thread at >> > https://www.ietf.org/mail-archive/web/dnsop/current/msg18690.html that >> I >> > need help synthesizing into the draft. I don't know enough about the >> > subtleties here to have a strong opinion, and I'm happy to accept the >> > consensus of the group. >> >> Reading back through this thread, it seems like the concerns were about >> how to represent the ".localhost" TLD in the root zone, or how to use >> DNSSEC to express that the root zone will not speak for ".localhost". >> However, I think we don't need either. This draft attempts to codify the >> idea that queries for "localhost" or "foo.localhost" should never leave >> the local system, and so it doesn't matter what the root zone says about >> ".localhost". >> >> I would even take it a step further: It would be a mistake to add any >> records for ".localhost" to the root zone, because it would mask >> implementation errors. If a local resolver accidentally allows a query >> for "foo.localhost" to hit the wire, it should result in an error. >> >> IMHO, the document is good as it stands. >> >> _______________________________________________ >> 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 > > --001a114b2950db2caa0555c49152 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 6:39 AM, william manning <<= a href=3D"mailto:chinese.apricot@gmail.com" target=3D"_blank">chinese.apric= ot@gmail.com> wrote:
localhost is just a string, like www or mail or supralingua.=C2= =A0 A DNS operator may
chose to map any given string to any given IP ad= dress. =C2=A0restricting =C2=A0::1 =C2=A0so that it never leaves
= the host is pretty straight forward. =C2=A0if I map localhost to 3ffe::53:d= ead:beef and NOT ::1 in my
systems, why should you care? =C2=A0

The underlying need here is that= application software would like to make use of the fact that it is connect= ing to "localhost" (vs. other domain names) to make security deci= sions based on whether traffic is going to leave the host.=C2=A0 So if the = network layer remaps localhost to something other than a loopback interface= without telling the applications, then you're going to have security p= roblems.

The point of this document is to avoid th= is disconnect by discouraging the sorts of remappings you're talking ab= out.

--Richard

=C2=A0
if you are concerned= that completion logic is broken in resolvers and the string "localhos= t" is not=C2=A0
appended to the domain, then you really are = asking for the root servers to backstop the query with
an entry f= or localhost. =C2=A0and for the first 20 years of the DNS, there was an ent= ry for localhost. in=C2=A0
many of the root servers. =C2=A0it was= phased out for several reasons, two key ones were DNSSEC and=C2=A0
the fact that most resolvers had corrected their broken completion logic= .
There is no good reason to bring it back for special processing= .=C2=A0 It's just a string.

/Wm

On Tue, Aug 1, 2017 at 11:59 AM, Jacob Hoffman-Andrews <jsha@eff.org&= gt; wrote:
On 08/01/2017 03:48 AM,= Mike West wrote:
> The only open issue I know of is some discussion in the thread at
> https://www.ietf.org/mail-arch= ive/web/dnsop/current/msg18690.html that I
> need help synthesizing into the draft. I don't know enough about t= he
> subtleties here to have a strong opinion, and I'm happy to accept = the
> consensus of the group.

Reading back through this thread, it seems like the concerns were about
how to represent the=C2=A0 ".localhost" TLD in the root zone, or = how to use
DNSSEC to express that the root zone will not speak for ".localhost&qu= ot;.
However, I think we don't need either. This draft attempts to codify th= e
idea that queries for "localhost" or "foo.localhost" sh= ould never leave
the local system, and so it doesn't matter what the root zone says abou= t
".localhost".

I would even take it a step further: It would be a mistake to add any
records for ".localhost" to the root zone, because it would mask<= br> implementation errors. If a local resolver accidentally allows a query
for "foo.localhost" to hit the wire, it should result in an error= .

IMHO, the document is good as it stands.

_______________________________________________
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


--001a114b2950db2caa0555c49152-- From nobody Wed Aug 2 05:48:32 2017 Return-Path: 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 47A1A131CD7 for ; Wed, 2 Aug 2017 05:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 7q3Qp8d-WYUH for ; Wed, 2 Aug 2017 05:48:28 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD037132070 for ; Wed, 2 Aug 2017 05:48:28 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id v29so26048591qtv.3 for ; Wed, 02 Aug 2017 05:48:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Z4nZrf59xhkcvSkFMGNYVVauCdZuJQ0pNTRKZF36Te4=; b=rqhcN2FEZ9Lz5cwPuQCnUTlj7xLAKC3w6hYpYQX/fcnabHTyy+fIgCqFPc3sg38nBj xzdIPMdQfULpeXGG0cv6sPBQnAuvNFD+QUXSWWjt/BQMB1hGCQH/uJlcAz7JneztKAAU 8ODWc61nA0GIIup6F6jFUU9gTI4C45NDWBJVavIvVs9lw7zc/VdSbMNEQRkSPu2hLgsa xzmCTsXM1HjvJ0ddOO4uLPSabXtifH4UdJOwNshFYOLdUmiAMhH9hKtyg93xjtSCl1q7 pBJh5+qF9W4G7Zmll1yqfEDwFLY3f3ZyitB0OOVV5n9jYmGIftHKlHEg16QZ07/fZsy9 kzkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Z4nZrf59xhkcvSkFMGNYVVauCdZuJQ0pNTRKZF36Te4=; b=ZIbUDWZAjTks6iKY1HrXE/MiEEnSk0k6xkFCsWimrI4bsdSWNOyxTUPPEravwVcQ3O 19ZsfuZHUALvQO/i/52R5ROK1xXUplS0s0QOsDI3DayvCn1vIAVDgJOiQyFUjHChxLmL RMq513m7TAlepD8/Nfnq5WIazQ2CpwcEEMdSnDpi6HS2VD0C+HWhQSWSOLBpd7+sBUQh djlzZ8iYZQoOko+6m8jBE1vHDz7dH5RXVvwEw2wsTKpc7/y9lYVKGanRzIU0iYijFc6O hmq5BQ87g4o64JUeWazHSmXiz8LdtthAR0kHokW55rRfLw9g9GXy/CXyNZzPhGAIEp6p 5NFQ== X-Gm-Message-State: AIVw1125BRHL6yjb1qI129WmM00W01ddkQYDalwVBFpuPJYwjYmS2yHc 5ugpY+Hn4qjdSQUs3aaNGw== X-Received: by 10.237.43.134 with SMTP id e6mr23463004qtd.125.1501678107654; Wed, 02 Aug 2017 05:48:27 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s32sm15432589qth.71.2017.08.02.05.48.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 05:48:26 -0700 (PDT) From: Ted Lemon Message-Id: <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A199776-7AAA-4E81-BE0D-F3CAB6CA2C39" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 Aug 2017 08:48:24 -0400 In-Reply-To: Cc: william manning , dnsop , Jacob Hoffman-Andrews To: Richard Barnes References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 12:48:30 -0000 --Apple-Mail=_9A199776-7AAA-4E81-BE0D-F3CAB6CA2C39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 2, 2017, at 8:40 AM, Richard Barnes wrote: > The underlying need here is that application software would like to = make use of the fact that it is connecting to "localhost" (vs. other = domain names) to make security decisions based on whether traffic is = going to leave the host. So if the network layer remaps localhost to = something other than a loopback interface without telling the = applications, then you're going to have security problems. >=20 > The point of this document is to avoid this disconnect by discouraging = the sorts of remappings you're talking about. Of course, arguably this is the wrong approach. Perhaps the right = approach is to understand that the security characteristics of = "localhost" are not the ones that we want when our goal is to be sure we = are connecting to the local host. Apps don't control the name = resolution software that's running on the local host. If they want to = be sure they are connecting locally, perhaps they should be using ::1 = instead of localhost as their explicit destination identifier. --Apple-Mail=_9A199776-7AAA-4E81-BE0D-F3CAB6CA2C39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 2, 2017, at 8:40 AM, Richard Barnes <rlb@ipv.sx> = wrote:
The= underlying need here is that application software would like to make = use of the fact that it is connecting to "localhost" (vs. other domain = names) to make security decisions based on whether traffic is going to = leave the host.  So if the network layer remaps localhost to = something other than a loopback interface without telling the = applications, then you're going to have security problems.
The point of this document = is to avoid this disconnect by discouraging the sorts of remappings = you're talking about.

Of course, arguably this is the wrong approach.   = Perhaps the right approach is to understand that the security = characteristics of "localhost" are not the ones that we want when our = goal is to be sure we are connecting to the local host.   Apps = don't control the name resolution software that's running on the local = host.   If they want to be sure they are connecting locally, = perhaps they should be using ::1 instead of localhost as their explicit = destination identifier.

= --Apple-Mail=_9A199776-7AAA-4E81-BE0D-F3CAB6CA2C39-- From nobody Wed Aug 2 06:02:31 2017 Return-Path: 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 5ADFF132094 for ; Wed, 2 Aug 2017 06:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 nKmR-d2FLf-r for ; Wed, 2 Aug 2017 06:02:29 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3671132007 for ; Wed, 2 Aug 2017 06:02:28 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y43so18476230wrd.3 for ; Wed, 02 Aug 2017 06:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qXIAEuPkC7DNFV/p2PKSPLQufOwCYMAtXxd8kIL2cRg=; b=ZUSaMgh2jX4rrxcvJi47Bp0H1Wpg9Qw49r23kUbdmKPR861mlp0V40HQYELSigO3mg 8z+h5OGurZ+UpRT8KMybyMKOYyE1XUHRQg1oFLqcb5eyNGX2poIQcVpaRpQvSuQDqMUA 7A8LZRMGrqwSmSCwvb1QhB434rBikqun1Og8gSYJGCIbRAxX1Q5ghBoq0Dn1WVlqCCVJ VP+WZ6BrM56n9yXz1Z2Sc+BVc2fqlkV/RKfUEh5+Nm3QUQ1ReKM8Tozoo9yEa0Ep8bZU 5ZlRS3p00+Hcm0fh+T8xLCLdP8RWpeULyV9wMRYMVUk2HD5njeJbZgYw3fAFrgOaX5in nh9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qXIAEuPkC7DNFV/p2PKSPLQufOwCYMAtXxd8kIL2cRg=; b=rISHsbyvtTtwQxWo34FUq+N3dPkh10UiTlzdw47ae9StypiKtGM8Y5P88SBJoiFpBm UlHthNi1HTh3O18g0KqeULFncGhwuij7UkzFPo/0J8kSh6NU/zB1DeHh0/O6hUK4EOMi lwY8GmwUSF7ryWuTXnRFd8OChO958CVRd1eNrWFY9CHzbOZkwtMDVo9b6//sxmGa6pfd p13d52K2vPW4Fyh2REQVQmwO0/IC1m79Fn23WrEGy9EPPh0bNc+RiFUo91SFTUJKuRhq maP+kxGIZiKtDvyoSon96/o2WCrM9HlsxXxrFIMC64mzBEbR2eATtxBtzBDYRXr8lXkp yJ+A== X-Gm-Message-State: AIVw112INtQxAhNBl1xOmNroVyRO+INuOYI6dWMLyEBEYHvlsJymfv9Y hM97l9RZ9/uWYG8T8GwwQnoitTqO1b3y X-Received: by 10.223.179.13 with SMTP id j13mr16690970wrd.228.1501678947001; Wed, 02 Aug 2017 06:02:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:02:26 -0700 (PDT) In-Reply-To: <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> From: Richard Barnes Date: Wed, 2 Aug 2017 09:02:26 -0400 Message-ID: To: Ted Lemon Cc: william manning , dnsop , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="94eb2c1b4eb43443170555c4e026" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:02:30 -0000 --94eb2c1b4eb43443170555c4e026 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon wrote: > On Aug 2, 2017, at 8:40 AM, Richard Barnes wrote: > > The underlying need here is that application software would like to make > use of the fact that it is connecting to "localhost" (vs. other domain > names) to make security decisions based on whether traffic is going to > leave the host. So if the network layer remaps localhost to something > other than a loopback interface without telling the applications, then > you're going to have security problems. > > The point of this document is to avoid this disconnect by discouraging the > sorts of remappings you're talking about. > > > Of course, arguably this is the wrong approach. Perhaps the right > approach is to understand that the security characteristics of "localhost" > are not the ones that we want when our goal is to be sure we are connecting > to the local host. Apps don't control the name resolution software that's > running on the local host. If they want to be sure they are connecting > locally, perhaps they should be using ::1 instead of localhost as their > explicit destination identifier. > This is indeed what happens today. https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy But of course having IP addresses in URLs is both a PITA for developers and an anti-pattern more generally. If "localhost" were properly defined to be loopback, then applications could just hard-wire resolution, and not depend on the good graces of the platform resolver. As, for example, Firefox does with ".onion" today: http://searchfox.org/mozilla-central/source/netwerk/dns/nsDNSService2.cpp#708 (The "localhost" stuff in that method is unrelated to this discussion BTW; it relates to a Firefox-internal mapping of other domains to localhost.) --94eb2c1b4eb43443170555c4e026 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <mellon@fugue.com> wrote:
On Aug 2, 2017, at 8= :40 AM, Richard Barnes <= rlb@ipv.sx> wrote:
The underlying= need here is that application software would like to make use of the fact = that it is connecting to "localhost" (vs. other domain names) to = make security decisions based on whether traffic is going to leave the host= .=C2=A0 So if the network layer remaps localhost to something other than a = loopback interface without telling the applications, then you're going = to have security problems.

The point of this document is to = avoid this disconnect by discouraging the sorts of remappings you're ta= lking about.

Of course, argua= bly this is the wrong approach. =C2=A0 Perhaps the right approach is to und= erstand that the security characteristics of "localhost" are not = the ones that we want when our goal is to be sure we are connecting to the = local host. =C2=A0 Apps don't control the name resolution software that= 's running on the local host. =C2=A0 If they want to be sure they are c= onnecting locally, perhaps they should be using ::1 instead of localhost as= their explicit destination identifier.
(The "localhost" stuff in that = method is unrelated to this discussion BTW; it relates to a Firefox-interna= l mapping of other domains to localhost.)
--94eb2c1b4eb43443170555c4e026-- From nobody Wed Aug 2 06:08:10 2017 Return-Path: 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 AC3F91320A3 for ; Wed, 2 Aug 2017 06:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 O18fHosjIVAp for ; Wed, 2 Aug 2017 06:08:06 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA5C31320AC for ; Wed, 2 Aug 2017 06:08:05 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x3so43732782oia.1 for ; Wed, 02 Aug 2017 06:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vaK1lcxavvRB7URJW/pC12qM8XtaRcBCePEXKmDobCE=; b=NElCoM5j5SlaOed8zZWHxrRpRsoatY6oz1QYZRnniraAHkcKg0uDVSayvcJ08wbLzW EtstoaAdsTbp9i552X+fo8+9UEC73+NCqo7VhvYXCQMMKkhpFhMkaZ04lU105QxT4jgh hCft72cKdm40DGKtzZUUG426odDqYdgqheU7C7XN5ubAap4dh+vlgM0z1k9Y3wi/mx8v j8iGwSmtEHQiqs4gXKvmZtrsg6rbNWQHdfFp9jDBGNW+vPs7joccP+Mf/jz00GVzeW+I 7918PB668kIW0ennwIGSxCs2m3sLAkkLebE0CzTypMrmYVF4kd8DdGVV21a9TKksGp84 Chww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vaK1lcxavvRB7URJW/pC12qM8XtaRcBCePEXKmDobCE=; b=BEX0dUnQpz4AYQ9N2TijlYdHEUl94bPOiCu4ndIYPs4gnf8jlhkeHJva4YM3ZckH+n YJyRARIZvpbE/0+ghVCq1c2qgqkh2lToc8L5jJGZ2m6vz0L6Gaq3+Xe8cFTinyKt6ySH vMx2LjyVmTE3LNGTF2EKWj9Cwcqb1wpZ7JeOGrfMKPef6lvz6WOzqYRp9yUnQIAJSLRz fd6zmkz4DwYkIxmnnH6qDKAj8FxhzTCSwigoDhwcB6eAiMA8zuO3XKsia6effoumjvUg Sds+0w3XUUactqKSsZXBTpemBCS2a7ssaLghuk1JQ/c4UF/TQA/Gw1AwV2BAcbNvRKwM /C2Q== X-Gm-Message-State: AIVw111NL2AypFSkNmRUiXIP/9DkRd9u/FP+uCvjsIvsv66NAw9Alhlq MOlI3ZFy9exVDZqxXpWsMw17d6JuRLOz X-Received: by 10.202.199.138 with SMTP id x132mr18264350oif.52.1501679283862; Wed, 02 Aug 2017 06:08:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.47.5 with HTTP; Wed, 2 Aug 2017 06:07:43 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> From: Mike West Date: Wed, 2 Aug 2017 15:07:43 +0200 Message-ID: To: Richard Barnes Cc: Ted Lemon , dnsop , Jacob Hoffman-Andrews , william manning Content-Type: multipart/alternative; boundary="001a11c180444bb9dc0555c4f4a6" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:08:08 -0000 --001a11c180444bb9dc0555c4f4a6 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 3:02 PM, Richard Barnes wrote: > On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon wrote: > >> On Aug 2, 2017, at 8:40 AM, Richard Barnes wrote: >> >> The underlying need here is that application software would like to make >> use of the fact that it is connecting to "localhost" (vs. other domain >> names) to make security decisions based on whether traffic is going to >> leave the host. So if the network layer remaps localhost to something >> other than a loopback interface without telling the applications, then >> you're going to have security problems. >> >> The point of this document is to avoid this disconnect by discouraging >> the sorts of remappings you're talking about. >> >> >> Of course, arguably this is the wrong approach. Perhaps the right >> approach is to understand that the security characteristics of "localhost" >> are not the ones that we want when our goal is to be sure we are connecting >> to the local host. Apps don't control the name resolution software that's >> running on the local host. If they want to be sure they are connecting >> locally, perhaps they should be using ::1 instead of localhost as their >> explicit destination identifier. >> > > This is indeed what happens today. > > https://w3c.github.io/webappsec-secure-contexts/#is-origin-trustworthy > > But of course having IP addresses in URLs is both a PITA for developers > and an anti-pattern more generally. > > If "localhost" were properly defined to be loopback, then applications > could just hard-wire resolution, and not depend on the good graces of the > platform resolver. As, for example, Firefox does with ".onion" today: > > http://searchfox.org/mozilla-central/source/netwerk/dns/ > nsDNSService2.cpp#708 > > (The "localhost" stuff in that method is unrelated to this discussion BTW; > it relates to a Firefox-internal mapping of other domains to localhost.) > I was typing basically this when Richard's message came in. So I'll simply add that Problem 8 in https://tools.ietf.org/html/draft-ietf-sunset4- gapanalysis-09#section-5 suggests that we already know that this kind of hard-coding will cause issues for future migrations. Just as we'd like to discourage folks from hard-coding `127.0.0.1` to be certain that they're talking to the loopback interface, it seems reasonable to discourage folks from hard-coding `::1`. -mike --001a11c180444bb9dc0555c4f4a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 2, 2017 at 3:02 PM, Richard Barnes <rlb@ipv.sx> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
O= n Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon <mellon@fugue.com> w= rote:
On Aug 2, 2017, at 8:40 AM, Richard = Barnes <rlb@ipv.sx&g= t; wrote:
The underlying need here is th= at application software would like to make use of the fact that it is conne= cting to "localhost" (vs. other domain names) to make security de= cisions based on whether traffic is going to leave the host.=C2=A0 So if th= e network layer remaps localhost to something other than a loopback interfa= ce without telling the applications, then you're going to have security= problems.

The point of this document is to avoid this disco= nnect by discouraging the sorts of remappings you're talking about.

Of course, arguably this is the = wrong approach. =C2=A0 Perhaps the right approach is to understand that the= security characteristics of "localhost" are not the ones that we= want when our goal is to be sure we are connecting to the local host. =C2= =A0 Apps don't control the name resolution software that's running = on the local host. =C2=A0 If they want to be sure they are connecting local= ly, perhaps they should be using ::1 instead of localhost as their explicit= destination identifier.

This is indeed what happens today.


But of course hav= ing IP addresses in URLs is both a PITA for developers and an anti-pattern = more generally.

If "localhost" were prop= erly defined to be loopback, then applications could just hard-wire resolut= ion, and not depend on the good graces of the platform resolver.=C2=A0 As, = for example, Firefox does with ".onion" today:
(The "localhost" stuff in that method is unrelated= to this discussion BTW; it relates to a Firefox-internal mapping of other = domains to localhost.)

I wa= s typing basically this when Richard's message came in. So I'll sim= ply add that Problem 8 in=C2=A0https://tools.iet= f.org/html/draft-ietf-sunset4-gapanalysis-09#section-5=C2=A0s= uggests that we already know that this kind of hard-coding will cause issue= s for future migrations. Just as we'd like to discourage folks from har= d-coding `127.0.0.1` to be certain that they're talking to the loopback= interface, it seems reasonable to discourage folks from hard-coding `::1`.=

-mike
--001a11c180444bb9dc0555c4f4a6-- From nobody Wed Aug 2 06:10:52 2017 Return-Path: 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 9544D1320A9 for ; Wed, 2 Aug 2017 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 5B3KRbhKzX5L for ; Wed, 2 Aug 2017 06:10:49 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5907132091 for ; Wed, 2 Aug 2017 06:10:49 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id 16so26414203qtz.4 for ; Wed, 02 Aug 2017 06:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EbSeJO0n/e6OaCDBY/gFQh3Jpo0RQvR/WxfsPljSC8E=; b=Cgg84RYoCCsWHRMiUDKNrNxw5hYhXY8uySU1GXorKLPC+3ALtuPkNyYfyYzgNJqk+V hmA+p69dANW4gXJBAvMH8AX57/sQ4tHQDLHpoQf6hxf7SbQQGmV7VN6oS6LEdXKOPRcH Gsfdmh8v3FThx9LW6Ib3mnWWM8fAffviuVcyHF0/TDS8LqnYHk7nmnxL7wvB6OF0G1dF hJxOtR22Spkt2rF2tldEbyTQworIdEol8rxV2Vu6r1BvVLNshtDJber9pTZluKwN402l SwtMMwtz3gtI39nmQJqdifl03sZ4O/RCvB0LEN9Xd9U1N4bbCqQ8GnFtBSMTdiQl6M6D oW1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EbSeJO0n/e6OaCDBY/gFQh3Jpo0RQvR/WxfsPljSC8E=; b=OAFZAe/fUFKIsgrZeoNeiMVa5zAWBU+IP/NHlvFcVqzuGAbOsUbbpzoJLYyYY1Ma0s OITMH0R0D8KiMFBjwomFSmjdvFs6I1IwCSMe+J5ZeGZFb2EgeT95kkv07ijYz3Qn6M4q zZYJWcjt5LHgYOsrF5t8neMyHawIVkQA2qGox2+VBMnw9vgLPcDZic71Lc4eTcnLQKHE /0cT2xH/5xHxiAEB0C0QtClMzbha0egfQJYH8tedt4QdsJ6wRo+SoCyvqIr2W1by+CU8 2EDo60T3NPydrUbZNQfcYVWxfBGAnJcUCryDzRP4jFO2NL2H6eLFywNWm+QprrIKgM/J ZOHA== X-Gm-Message-State: AIVw112OYrPcgMd3c41r0It3CmtpcYgisQYO4nK+ZegryhLnd7k82swY mvM+ut1CVlTISnjB X-Received: by 10.200.56.48 with SMTP id q45mr30542491qtb.36.1501679448728; Wed, 02 Aug 2017 06:10:48 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id n14sm703068qtc.28.2017.08.02.06.10.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:10:48 -0700 (PDT) From: Ted Lemon Message-Id: <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_AE6D2235-E817-4DBE-ACB9-FFFD4EC3EC4F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 Aug 2017 09:10:45 -0400 In-Reply-To: Cc: william manning , dnsop , Jacob Hoffman-Andrews To: Richard Barnes References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:10:50 -0000 --Apple-Mail=_AE6D2235-E817-4DBE-ACB9-FFFD4EC3EC4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: > But of course having IP addresses in URLs is both a PITA for = developers and an anti-pattern more generally. While true, I would argue that this is actually a problem. E.g., I = actually literally cannot surf to a link-local URL without having a DNS = record for it, because http://[ = fe80::1806:ec37:3d5f:9580%e= n0]/ has an interface = identifier in it, and modern browsers consider this an anti-pattern, I = guess. And you don't want to put link-local addresses in DNS, even if = it made sense to do so, so what is one to do? I'm not convinced that = this anti-pattern is the wrong anti-pattern, but here we have two = examples of it being problematic, in the least. > If "localhost" were properly defined to be loopback, then applications = could just hard-wire resolution, and not depend on the good graces of = the platform resolver. As, for example, Firefox does with ".onion" = today: Right. But there was actually a long discussion on why that's = problematic when we were doing the .onion RFC. The reason is that one = can't count on any particular piece of application software correctly = interpreting the rightmost label. We can write RFCs encouraging it, = but if I am writing a URL into a piece of HTML, I have no idea whether = the thing that interprets the HTML will or will not do the right thing. We just accept that as a risk with .onion because we don't have a better = option, but for localhost we definitely do have a better option. = That's all I'm saying. --Apple-Mail=_AE6D2235-E817-4DBE-ACB9-FFFD4EC3EC4F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 2, 2017, at 9:02 AM, Richard Barnes <rlb@ipv.sx> = wrote:
But= of course having IP addresses in URLs is both a PITA for developers and = an anti-pattern more generally.

While true, I would argue that this is actually a = problem.   E.g., I actually literally cannot surf to a link-local = URL without having a DNS record for it, because http://[fe80::1806:ec37:3d5f:9580%en0]/ has an interface = identifier in it, and modern browsers consider this an anti-pattern, I = guess.   And you don't want to put link-local addresses in DNS, = even if it made sense to do so, so what is one to do?   I'm not = convinced that this anti-pattern is the wrong anti-pattern, but here we = have two examples of it being problematic, in the least.

If = "localhost" were properly defined to be loopback, then applications = could just hard-wire resolution, and not depend on the good graces of = the platform resolver.  As, for example, Firefox does with ".onion" = today:

Right.   = But there was actually a long discussion on why that's problematic when = we were doing the .onion RFC.   The reason is that one can't count = on any particular piece of application software correctly interpreting = the rightmost label.   We can write RFCs encouraging it, but if I = am writing a URL into a piece of HTML, I have no idea whether the thing = that interprets the HTML will or will not do the right = thing.

We just accept that as a risk = with .onion because we don't have a better option, but for localhost we = definitely do have a better option.   That's all I'm = saying.


= --Apple-Mail=_AE6D2235-E817-4DBE-ACB9-FFFD4EC3EC4F-- From nobody Wed Aug 2 06:17:40 2017 Return-Path: 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 B9A7E126B7E for ; Wed, 2 Aug 2017 06:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 V4l3DzYz0lcW for ; Wed, 2 Aug 2017 06:17:36 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EA811320AF for ; Wed, 2 Aug 2017 06:17:36 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id a77so26355635qkb.0 for ; Wed, 02 Aug 2017 06:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=b2bjcT/YBspJ5PUveymnQgJPGzS4/f2e8kSDy9RYAC8=; b=pnhzP4kjCeqK4vDqhvC5JlMy1ZcaUxrTtHvXaDF4pymxHjOyMaIWL2iNHFkBKXVzAi gz3wSRnYGrFrI2mzEfzzJqcxBe9dql8mMhyScwHUFPw404ZBLM2SxvHaycDqhX0XJ1M8 i6ajm0HcdljhUJSznZVyKv8rbCk3ebuRkjeYZRX0rcwmC8lcI9+rpa8ZS2VpnQpKb42/ vlzdkvwWR+u7TzPTjhU/W79oD2Np5/Qh66AThZE490ZgDI552oVIsbcyLVnZHUvlA1XN Ugi19Vm64uylbOXPufila8oAEELkbA2UxbPsdHfu77vkN9NlRUqxEjsSJr429eDfUILb rXgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=b2bjcT/YBspJ5PUveymnQgJPGzS4/f2e8kSDy9RYAC8=; b=GgAy/DovTx4CveXDHaGFcSKkVPE81x9Stg+bioXJ56m5g9UNRQ0Kn53VtMvaJ97/lJ Xz/rCO6yD9fJJ97JFXsWe+FBF0ZVawWkriHkE+iDbq0I8ETJAC+6Yvez/3I9MGKUg/jp VPJqev7Bfm8dN1etWZHg84ns5rl9M8tNyTxvLm1N0HSLdV42eqlYDGBPO+oJu0LbOMyl MuNxaXDv9khOKpf3CQ3WEERz2LPUAUmKZbC8LsnkqaXnFiJcUdn1TobvEfmwG/ReT2k2 lboNtWRjk9IVefKlVqWiK0Jdsc/kF4U/dmQgMjgv4UvbfymeVj6ZCKjhR3C6oDiHaSmn vUQA== X-Gm-Message-State: AIVw112FCZ88ed0s4C5a5STsIdu0xAhBc6jIBLR2XLBnpnTm6d6ebzpg 1jTCME8mZbe9iA9k X-Received: by 10.55.33.195 with SMTP id f64mr31542068qki.208.1501679855297; Wed, 02 Aug 2017 06:17:35 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 58sm25302050qtu.88.2017.08.02.06.17.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:17:34 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C886CD2B-B7E6-4FDA-B608-26047921BF62" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 Aug 2017 09:17:26 -0400 In-Reply-To: Cc: Richard Barnes , dnsop , Jacob Hoffman-Andrews , william manning To: Mike West References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:17:38 -0000 --Apple-Mail=_C886CD2B-B7E6-4FDA-B608-26047921BF62 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 2, 2017, at 9:07 AM, Mike West wrote: > I was typing basically this when Richard's message came in. So I'll = simply add that Problem 8 in = https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 = = suggests that we already know that this kind of hard-coding will cause = issues for future migrations. Just as we'd like to discourage folks from = hard-coding `127.0.0.1` to be certain that they're talking to the = loopback interface, it seems reasonable to discourage folks from = hard-coding `::1`. I don't think I agree. It's entirely possible that at some future = time, [::1] will have symbolic meaning but will not refer to a transport = protocol destination address. But we are arguing that "localhost" = should be treated specially by every piece of software that looks at it, = when its default meaning is "look up localhost in the DNS and connect to = one of the addresses that you get in response." The default meaning of = "[::1]" is "connect to the local host." There isn't even an implicit = indirection there. So if you have a host running IPv10, where [::1] doesn't have an = explicit meaning, one of two things will be the case: either the piece = of software looking at [::1] will do an explicit transformation from = [::1] to the right thing, or it won't. If it does, things just work. = If it doesn't, they fail safe: the connection fails. With localhost, = if the software does the wrong thing, it does not fail safe. --Apple-Mail=_C886CD2B-B7E6-4FDA-B608-26047921BF62 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On Aug 2, 2017, at 9:07 AM, Mike West <mkwst@google.com> = wrote:
I was typing basically this when = Richard's message came in. So I'll simply add that Problem 8 = in https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 suggests that we already know that = this kind of hard-coding will cause issues for future migrations. Just = as we'd like to discourage folks from hard-coding `127.0.0.1` to be = certain that they're talking to the loopback interface, it seems = reasonable to discourage folks from hard-coding = `::1`.

I = don't think I agree.   It's entirely possible that at some future = time, [::1] will have symbolic meaning but will not refer to a transport = protocol destination address.   But we are arguing that "localhost" = should be treated specially by every piece of software that looks at it, = when its default meaning is "look up localhost in the DNS and connect to = one of the addresses that you get in response."   The default = meaning of "[::1]" is "connect to the local host."   There isn't = even an implicit indirection there.

So if you have a host running IPv10, = where [::1] doesn't have an explicit meaning, one of two things will be = the case: either the piece of software looking at [::1] will do an = explicit transformation from [::1] to the right thing, or it won't. =   If it does, things just work.   If it doesn't, they fail = safe: the connection fails.   With localhost, if the software does = the wrong thing, it does not fail safe.

= --Apple-Mail=_C886CD2B-B7E6-4FDA-B608-26047921BF62-- From nobody Wed Aug 2 06:18:31 2017 Return-Path: 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 9DA451320C5 for ; Wed, 2 Aug 2017 06:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.473 X-Spam-Level: X-Spam-Status: No, score=-1.473 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 zrafixbnYVUZ for ; Wed, 2 Aug 2017 06:18:28 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9941320B9 for ; Wed, 2 Aug 2017 06:18:27 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id k20so30152341wmg.0 for ; Wed, 02 Aug 2017 06:18:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/086kHfQh7YjoOjcozxaMirWdFgCQH2R4aABNk1z72Y=; b=Y9J46SlwaDu9bKZD0dhS2NsgVsm/5MIaTy40CRrzeOrkBA8p2l7q0kQkBFi6zo6254 EjimU4NLpTfhGJw9DBuloFoYNHlBRkaJpxCONKj88EROcvZ2c7PJDYeBbYslLlT4G182 easBLv4/zmP12C2HfQCdTC4HUmcssX6Hg1w1A56eyC+bd3pRenhwu6sCcXgzrBk4grFF mSxmU+8oCCAHx/eZEY+CZ9Hiu03DNgWV5lNiDJ4e69eHf6x7Vv+AkFLxa1wQSTelNmxD n0UDY6N9CaU8GXgHVe6qRaV4en8vOkO8P5Zs3Hy3eIXuWEs5ogWONBMjuTaATZzh/lky jV8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/086kHfQh7YjoOjcozxaMirWdFgCQH2R4aABNk1z72Y=; b=Trd9kYoddzTyDe3wtEMPNrRTMUGGKX0oGtXdHURopdAMI9KR252g6y1aOkcWxnK3ll MMAcwfgI6VLyVvDVWuhPMgoc5y7UjR3LjPIL16P4w/A3oI7IckYbK2TExYTVHgdgWpY1 hWEg6kY1x+/JxjYw7exTBlV4wyGTO1lM2gg+0+VXYYdcmvlPrykZEuLQRmX9XHJqOOFj n9kf1+SQT6vC69XyaKvfd9shU44pzBIkeBW50Md+8Q0BDyJwtALrskkI0XNawAFLVo1K N7Mi1gXKPlJAJPasMA/7M+r3eyfm3/S4lXGejL3v+HdK+yx0AnhVObNl382bHXd/+sNP JmAg== X-Gm-Message-State: AIVw111I8ig+Rkkp5ZcLYTlFGEFLichyy8slFnfA0fKHxVxHt5RGfLlp LO8BOUVyccPmEe8CdaHrh/Z6S9iBtyPm X-Received: by 10.28.129.205 with SMTP id c196mr3827239wmd.120.1501679905864; Wed, 02 Aug 2017 06:18:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:18:25 -0700 (PDT) In-Reply-To: <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> From: Richard Barnes Date: Wed, 2 Aug 2017 09:18:25 -0400 Message-ID: To: Ted Lemon Cc: william manning , dnsop , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a1142486e5b49940555c51908" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:18:30 -0000 --001a1142486e5b49940555c51908 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon wrote: > On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: > > But of course having IP addresses in URLs is both a PITA for developers > and an anti-pattern more generally. > > > While true, I would argue that this is actually a problem. E.g., I > actually literally cannot surf to a link-local URL without having a DNS > record for it, because http://[ > fe80::1806:ec37:3d5f: > 9580%en0]/ has an > interface identifier in it, and modern browsers consider this an > anti-pattern, I guess. And you don't want to put link-local addresses in > DNS, even if it made sense to do so, so what is one to do? I'm not > convinced that this anti-pattern is the wrong anti-pattern, but here we > have two examples of it being problematic, in the least. > > If "localhost" were properly defined to be loopback, then applications > could just hard-wire resolution, and not depend on the good graces of the > platform resolver. As, for example, Firefox does with ".onion" today: > > > Right. But there was actually a long discussion on why that's > problematic when we were doing the .onion RFC. The reason is that one > can't count on any particular piece of application software correctly > interpreting the rightmost label. We can write RFCs encouraging it, but > if I am writing a URL into a piece of HTML, I have no idea whether the > thing that interprets the HTML will or will not do the right thing. > The point you're missing here is that the application is both the thing relying on the definition of "localhost" and the thing empowered to enforce the RFC. If the application doesn't care whether "localhost" resolves to anything special, then it can pass it to the platform and take its chances. If it does, it can hard-wire it to loopback. > We just accept that as a risk with .onion because we don't have a better > option, but for localhost we definitely do have a better option. That's > all I'm saying. > Using IP addresses is not a better option. --Richard --001a1142486e5b49940555c51908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon <mellon@fugue.com> wrote:
On Aug 2, 2017, at 9:02 AM, Richard Barnes <rlb@ipv.sx> wrote:=
But of course having I= P addresses in URLs is both a PITA for developers and an anti-pattern more = generally.

While true, I woul= d argue that this is actually a problem. =C2=A0 E.g., I actually literally = cannot surf to a link-local URL without having a DNS record for it, because= http://[fe80::1806:ec37:3d5f:9580%en0]/=C2=A0has an interfa= ce identifier in it, and modern browsers consider this an anti-pattern, I g= uess. =C2=A0 And you don't want to put link-local addresses in DNS, eve= n if it made sense to do so, so what is one to do? =C2=A0 I'm not convi= nced that this anti-pattern is the wrong anti-pattern, but here we have two= examples of it being problematic, in the least.

If "localhost" were properly = defined to be loopback, then applications could just hard-wire resolution, = and not depend on the good graces of the platform resolver.=C2=A0 As, for e= xample, Firefox does with ".onion" today:

Right. =C2=A0 But there was actually a long discussi= on on why that's problematic when we were doing the .onion RFC. =C2=A0 = The reason is that one can't count on any particular piece of applicati= on software correctly interpreting the rightmost label. =C2=A0 We can write= RFCs encouraging it, but if I am writing a URL into a piece of HTML, I hav= e no idea whether the thing that interprets the HTML will or will not do th= e right thing.

The point you= 9;re missing here is that the application is both the thing relying on the = definition of "localhost" and the thing empowered to enforce the = RFC.=C2=A0 If the application doesn't care whether "localhost"= ; resolves to anything special, then it can pass it to the platform and tak= e its chances.=C2=A0 If it does, it can hard-wire it to loopback.
=
=C2=A0
We just accept that as a risk with .onion because we don'= t have a better option, but for localhost we definitely do have a better op= tion. =C2=A0 That's all I'm saying.
<= /div>

Using = IP addresses is not a better option.

--Richard
--001a1142486e5b49940555c51908-- From nobody Wed Aug 2 06:34:22 2017 Return-Path: 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 9A5061320D2 for ; Wed, 2 Aug 2017 06:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 YHa41kh-p2_f for ; Wed, 2 Aug 2017 06:34:19 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBA5B1320AC for ; Wed, 2 Aug 2017 06:34:18 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 12so18886742wrb.1 for ; Wed, 02 Aug 2017 06:34:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TAJ4NVMnKOM9o5LIfc0/tpWrk/CJnukhzcXH6qZYh1c=; b=QzpaGu+r4STVTb7yOJx2pcgJeg1E9htPoJUcsR6qXNsoI7onsujTY7cuN7eyDNc1RD gPCR31uoPvX6WthXCsmFyOGCPlvE4ruMPlPzdQS0Ju4h3Dmoo2FAyKK/2Mk/QzR+nXCm vI4mQWSk4k14SCnJtpLgiMHlI/Y75jNvaf+1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TAJ4NVMnKOM9o5LIfc0/tpWrk/CJnukhzcXH6qZYh1c=; b=CTiMz86OQ9jkOEs0RpaG/U1/pWCYUZyH1GAs/YGYgSAvh+r5LIjBAxeqhW6MFshjRG GuB1cBgZGiVRXs6oLO1/+4SW5eZqvnVGFqYmP0yTluaE3DgBbq7r+INrwvAOBsUMmC/q jFaLa7gXxQv0isCOWUPRZ2vxTTlA1xUIAM0ZFY3V3vhkMt6mct2gLNT9QgnglP0txkUN PXO9yDFRjC6O2xK6rsaDKEE04IWzxSbHpOdPUko3MHUuc5Z/h27zjpQkBT5Hh4Yzag3N gvaKVDuKzGE/4qtNye27TE5lqbA4dJCfN6jCKDkA3ERiGAFTjwkc9vZ/VyArjUOyvWk1 Wq4Q== X-Gm-Message-State: AIVw111kuZDb5vawW8ynV6vuud7Z+u9OrsbA8ja+ksu/5esEv7q/5fST z396+r2qKiVMit9P X-Received: by 10.223.161.19 with SMTP id o19mr20319129wro.235.1501680857175; Wed, 02 Aug 2017 06:34:17 -0700 (PDT) Received: from [10.0.1.189] (host86-148-234-108.range86-148.btcentralplus.com. [86.148.234.108]) by smtp.gmail.com with ESMTPSA id l29sm20018849wre.46.2017.08.02.06.34.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:34:16 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-E1A79475-1FD3-4D02-9FBD-7240745FB488 Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (14G60) In-Reply-To: Date: Wed, 2 Aug 2017 14:34:15 +0100 Cc: Mark Andrews , dnsop WG , Jacob Hoffman-Andrews Content-Transfer-Encoding: 7bit Message-Id: <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> To: Mike West Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:34:20 -0000 --Apple-Mail-E1A79475-1FD3-4D02-9FBD-7240745FB488 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Mike, On Aug 2, 2017, at 09:54, Mike West wrote: > What would you like to see in the document in order to address this concer= n? A requirement that a `localhost` zone be created and delegated as an inse= cure delegation, using some of the language from the draft above (e.g. "This= delegation MUST NOT be signed, MUST NOT include a DS record, and MUST point= to one or more black hole servers, for example 'blackhole-1.iana.org.' and '= blackhole-2.iana.org.'.")? Any such delegation would be lame, and is a bad idea just for that reason. T= here's no foolproof way to add or drop zones hosted on the whole AS112 serve= r ssystem due to the lack of coordination between AS112 node operators -- de= spite the good communication between many such operators, there's no good wa= y to tell what nodes you don't know about. If you really wanted to sink queries in the top-level domain LOCALHOST a bet= ter approach would to use DNAME (see RFC 7535). But note that I'm not expres= sing an opinion on whether that's a good idea, either philosophically or pra= ctically, in this specific example. Joe= --Apple-Mail-E1A79475-1FD3-4D02-9FBD-7240745FB488 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Aug 2, 2017, at 09:54, Mike West <<= a href=3D"mailto:mkwst@google.com">mkwst@google.com> wrote:
=

What would you like to see in the docu= ment in order to address this concern? A requirement that a `localhost` zone= be created and delegated as an insecure delegation, using some of the langu= age from the draft above (e.g. "This delegation MUST NOT be signed, MUST NOT= include a DS record, and MUST point to one or more black hole servers, for e= xample 'blackhole-1.iana.org.' a= nd 'blackhole-2.iana.org.'.")?
Any such delegation would be lame, and is= a bad idea just for that reason. There's no foolproof way to add or drop zo= nes hosted on the whole AS112 server ssystem due to the lack of coordination= between AS112 node operators -- despite the good communication between many= such operators, there's no good way to tell what nodes you don't know about= .

If yo= u really wanted to sink queries in the top-level domain LOCALHOST a better a= pproach would to use DNAME (see RFC 7535). But note that I'm not expressing a= n opinion on whether that's a good idea, either philosophically or practical= ly, in this specific example.


Joe
<= /div>
= --Apple-Mail-E1A79475-1FD3-4D02-9FBD-7240745FB488-- From nobody Wed Aug 2 06:38:17 2017 Return-Path: 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 51E0D132010 for ; Wed, 2 Aug 2017 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 Y-IWjrothUTS for ; Wed, 2 Aug 2017 06:38:14 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C62513204F for ; Wed, 2 Aug 2017 06:38:14 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id y43so18876570wrd.3 for ; Wed, 02 Aug 2017 06:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xgzzLQsfnlPaxMNoANq5rn3rzdYk8T/c2A1teClYi10=; b=of6QnFABllmzonxUwz91YaKVq+WBJS8EIn4d36op59HVouLHwK1f4eOck/DltkTkkt ruPOgG2HKr6I8EaA63ONZHZYvtmT9sA7sLbrjU1Mk40vAMVaf2fPUA4HV5SMCbUrMtxE WfXd2bGdfaVC0YiI9tVQWSNzKH7T4U+Zbhmrwpvf78RM3K6GAiFU8xA6CsFaE966KrwH XwSaUj6n2c+cEGgh6yG6mQ1MYXLGAxcOO06kZli/wzLNxklJoVpL1arlMzI7ZqEl9Zlu EM3YDbNwiY77QOf8rYyGOMDKbXhxueMDSRWpywKryrz7PyTyPaweydTpkNee1UOjcQ/+ iFDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xgzzLQsfnlPaxMNoANq5rn3rzdYk8T/c2A1teClYi10=; b=HjiPbtBcCLFINdZHDuI908E/91/tKdlARWZCPMZDoGnVNzWw1zelcXoCIGsfLl3mrN D+1SNc2jexqhFKZJ/0r+00OXZV4rCkQdzL42KaRuXw2O7dVGWLzu0veT9HUgckJJ4RcA 4uROuO+O++Qe8yXtyevmIy+nrWuBRsH2+jJzwbGawDa33uoXXrIHtSkZnlrCovoIKs0j 0e9WbFVZhg0l6xyGk4/X9+rCIwsRNNDZakkHMnMX0fpjC19YLEQBczgv0Y1tYegYgOCu 7ELST2Nfhlgn1unet2av8z1LO7s4UPIgQqm0Cna7wuDHCChosmUeh9oKgiijMbv2q98Y 08GA== X-Gm-Message-State: AIVw1126WrpnWj1eNtzgFPvdXgLLdQi3N60lvz3zxjc8znmzy6ya232B eArbHcKLze6qaD8b5U0aVPzESNfu5quS X-Received: by 10.223.161.84 with SMTP id r20mr18525957wrr.91.1501681092751; Wed, 02 Aug 2017 06:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:38:12 -0700 (PDT) In-Reply-To: <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> From: Richard Barnes Date: Wed, 2 Aug 2017 09:38:12 -0400 Message-ID: To: Joe Abley Cc: Mike West , dnsop WG , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="f403045e302c19cd5b0555c5609e" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:38:16 -0000 --f403045e302c19cd5b0555c5609e Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley wrote: > Hi Mike, > > On Aug 2, 2017, at 09:54, Mike West wrote: > > What would you like to see in the document in order to address this > concern? A requirement that a `localhost` zone be created and delegated as > an insecure delegation, using some of the language from the draft above > (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record, > and MUST point to one or more black hole servers, for example ' > blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")? > Any such delegation would be lame, and is a bad idea just for that reason. > There's no foolproof way to add or drop zones hosted on the whole AS112 > server ssystem due to the lack of coordination between AS112 node operators > -- despite the good communication between many such operators, there's no > good way to tell what nodes you don't know about. > > If you really wanted to sink queries in the top-level domain LOCALHOST a > better approach would to use DNAME (see RFC 7535). But note that I'm not > expressing an opinion on whether that's a good idea, either philosophically > or practically, in this specific example. > It seems like the desired behavior for the DNS infrastructure here is the same as for .onion -- return NXDOMAIN. After all, these are queries that should never leave the end host, so anything not on the host should handle them as an error. cf. https://tools.ietf.org/html/rfc7686#section-2 > > > Joe > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --f403045e302c19cd5b0555c5609e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley <jabley@hopcount.ca>= wrote:
Hi Mike,

On Aug 2, 2017, at 09:54, Mike West &l= t;mkwst@google.com> wrote:

What would you like to see in the document in order to add= ress this concern? A requirement that a `localhost` zone be created and del= egated as an insecure delegation, using some of the language from the draft= above (e.g. "This delegation MUST NOT be signed, MUST NOT include a D= S record, and MUST point to one or more black hole servers, for example = 9;blackhole-1.ian= a.org.' and 'blackhole-2.iana.org.'.")?
Any such delegation would be lame, and is a bad idea just = for that reason. There's no foolproof way to add or drop zones hosted o= n the whole AS112 server ssystem due to the lack of coordination between AS= 112 node operators -- despite the good communication between many such oper= ators, there's no good way to tell what nodes you don't know about.=

If yo= u really wanted to sink queries in the top-level domain LOCALHOST a better = approach would to use DNAME (see RFC 7535). But note that I'm not expre= ssing an opinion on whether that's a good idea, either philosophically = or practically, in this specific example.

It seems like the desired behavior for t= he DNS infrastructure here is the same as for .onion -- return NXDOMAIN.=C2= =A0 After all, these are queries that should never leave the end host, so a= nything not on the host should handle them as an error.
=C2=A0
=


Joe

______________= _________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


--f403045e302c19cd5b0555c5609e-- From nobody Wed Aug 2 06:44:28 2017 Return-Path: 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 DC1B713209A for ; Wed, 2 Aug 2017 06:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 QT_VXVaBX2ct for ; Wed, 2 Aug 2017 06:44:25 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F285A131C58 for ; Wed, 2 Aug 2017 06:44:24 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id x3so44714021oia.1 for ; Wed, 02 Aug 2017 06:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YN/vaZcjBbAzmKoF6LJsTGmHhExKe6IlDHP2rbVI1dY=; b=J7p6uuBwy04tu+Qrupsz1nN5wo5gvk/CAQxVngN90pF/OO1pYkssItNUOr8trilCUh q3/URJuvTxiQ3XKymE9hEfFohDM3HQxtuMO6ZGsh1VWkkoZCuDVmpPwg63mnrzJyoKVm MPQ7twh+HEPhdGgZ9BXjarmRlAbmigpX+dXciYj5Pn0nj2eay4aIppWiw6z/H+QkkVm7 ONMsnxjjCLOv9fKZJhH1tQw8lIkmj1nxavLky9yPG0DZMp34qCALU/3zgKJksf+RF6+N ssmNanTYAcG0y1h2uUZwODN03GtqmIsrWCXRsiCX4Qf5qcliv7EgpBEA/3MR+tkGLHPd mmUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YN/vaZcjBbAzmKoF6LJsTGmHhExKe6IlDHP2rbVI1dY=; b=umX8eaeLDRvk5GcGlUp27caVi2Rrpbb++IjbyWzPGXI59YTQ1uupjnMhx46+3vZhxQ 9DpXng4tCruQNIgpGtDjVj2X03iz9MLckltti0oDOPdi8aDq2F/2vVyuyubETUIzLA4X HDKEsITSoGS1g0VM+GxahzYqMeH49LmMmYsFAtRq5DDbSmTBQPzN7KdEhfH9p6NKpn7J FHbm8C+atv2N2xu+J4qDH0XWbxDfEIH575K9bptId6+aNAet+XFiu4hXD3JwTliYd9Hw YStUzE/shy8BG8EDMV5S7WpM/ACerA07qw4LN3KXsb/t9oSJe5SMaHZTgBJaZQp9BTX1 XRJQ== X-Gm-Message-State: AIVw1135+PznFN5GN9wGM79srrHbTtRJaRR0p/y2x4236SQKJVOcY3KP 6iuw604bfC5h4tf9HUk6ANz9ne+gXmE3G/oc+w== X-Received: by 10.202.243.5 with SMTP id r5mr13951049oih.321.1501681464024; Wed, 02 Aug 2017 06:44:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.47.5 with HTTP; Wed, 2 Aug 2017 06:44:03 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> From: Mike West Date: Wed, 2 Aug 2017 15:44:03 +0200 Message-ID: To: Richard Barnes Cc: Joe Abley , dnsop WG , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="94eb2c0956503b32a50555c576e0" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:44:27 -0000 --94eb2c0956503b32a50555c576e0 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes wrote: > On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley wrote: > >> Hi Mike, >> >> On Aug 2, 2017, at 09:54, Mike West wrote: >> >> What would you like to see in the document in order to address this >> concern? A requirement that a `localhost` zone be created and delegated as >> an insecure delegation, using some of the language from the draft above >> (e.g. "This delegation MUST NOT be signed, MUST NOT include a DS record, >> and MUST point to one or more black hole servers, for example ' >> blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")? >> Any such delegation would be lame, and is a bad idea just for that >> reason. There's no foolproof way to add or drop zones hosted on the whole >> AS112 server ssystem due to the lack of coordination between AS112 node >> operators -- despite the good communication between many such operators, >> there's no good way to tell what nodes you don't know about. >> >> If you really wanted to sink queries in the top-level domain LOCALHOST a >> better approach would to use DNAME (see RFC 7535). But note that I'm not >> expressing an opinion on whether that's a good idea, either philosophically >> or practically, in this specific example. >> > > It seems like the desired behavior for the DNS infrastructure here is the > same as for .onion -- return NXDOMAIN. After all, these are queries that > should never leave the end host, so anything not on the host should handle > them as an error. > > cf. https://tools.ietf.org/html/rfc7686#section-2 > I'm pretty sure this is what the draft we're discussing attempts to do. See #2 under https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-03#section-3. It could be more explicit about the response, however... I can address that in a -04 if folks agree with the approach. (I also wonder whether it would be a better idea to reframe this draft as something akin to the "onion" RFC: that is, defining the behavior as a stand-alone document rather than monkey-patching RFC 6761.) -mike --94eb2c0956503b32a50555c576e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 2, 2017 at 3:38 PM, Richard Barnes <rlb@ipv.sx> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On Wed,= Aug 2, 2017 at 9:34 AM, Joe Abley <jabley@hopcount.ca> wro= te:
=
Hi Mike,

On Aug 2, 2017, at 09= :54, Mike West <mk= wst@google.com> wrote:

What would you= like to see in the document in order to address this concern? A requiremen= t that a `localhost` zone be created and delegated as an insecure delegatio= n, using some of the language from the draft above (e.g. "This delegat= ion MUST NOT be signed, MUST NOT include a DS record, and MUST point to one= or more black hole servers, for example 'blackhole-1.iana.org.' and 'blackhole-2.iana.org.'.")?
Any such delega= tion would be lame, and is a bad idea just for that reason. There's no = foolproof way to add or drop zones hosted on the whole AS112 server ssystem= due to the lack of coordination between AS112 node operators -- despite th= e good communication between many such operators, there's no good way t= o tell what nodes you don't know about.

If you really wanted to sink queries = in the top-level domain LOCALHOST a better approach would to use DNAME (see= RFC 7535). But note that I'm not expressing an opinion on whether that= 's a good idea, either philosophically or practically, in this specific= example.



I'm pretty sure this is what the draft we'= ;re discussing attempts to do. See #2 under=C2=A0https://to= ols.ietf.org/html/draft-west-let-localhost-be-localhost-03#section-3. I= t could be more explicit about the response, however... I can address that = in a -04 if folks agree with the approach.

(I also= wonder whether it would be a better idea to reframe this draft as somethin= g akin to the "onion" RFC: that is, defining the behavior as a st= and-alone document rather than monkey-patching RFC 6761.)

-mike
--94eb2c0956503b32a50555c576e0-- From nobody Wed Aug 2 06:48:28 2017 Return-Path: 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 6B0A712F280 for ; Wed, 2 Aug 2017 06:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca 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 A8Ki07EkV30L for ; Wed, 2 Aug 2017 06:48:25 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1392126C83 for ; Wed, 2 Aug 2017 06:48:24 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id 33so18966019wrz.4 for ; Wed, 02 Aug 2017 06:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wbA/wX820RlQFr8XyjFTkMxVEkpMGK+bCPGtA1393DE=; b=S829I+lWKwrvLKNnKcmJstf9QxDfvPcXEnOLLwomOrb+nOj9nft9dt2iy2VxPqSGLn L+iMLPxGEvIjxfeFIjTl75/XT1zWLIc9LnDGl8FgjQrPQa0hoSaJuPcVUX/wzTOvIaLv tJd3tsvjS6sfpGU9NOuFhpuMjXWhDhFY3yiWU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wbA/wX820RlQFr8XyjFTkMxVEkpMGK+bCPGtA1393DE=; b=ufgtRYjtgX1jv7y9Mf48Lbrn1AW7bfxN+d67Jsw/RT3upak6/P9e5b+36Fsk1jhdsg AUuSwKe/RyhUw3f/Vgwd34QvsBRppSZ6ZUMn3cpwyRpnGaQ8eKGf3BCnDIk4aLBLHRZT YlZNvi9eF6SoB3pN4TNeiog/hz3b+A7fMs/u2Pa1lRLRigTz7X9RaG6wy/6x+S/KITNA lc3E4weGyY3g9dVSDx2GGeDsneVfeGHdd0AilACMpdgigzCUyBKWvw3u58mAamgMzwzQ pAVR5FB56YJz5OYZO1uciBb71gbRDlIcTbwJu2Jx8rmMLktmkRyqt0JWiakm6q3c5u0k Av0Q== X-Gm-Message-State: AIVw110gyyrE2fY32pxW6gICl4TTmNi0q7DeBVBaCgRyr2j9JivEv7vQ eQsE4Tlf4UttjHbc X-Received: by 10.223.169.68 with SMTP id u62mr16679278wrc.285.1501681703496; Wed, 02 Aug 2017 06:48:23 -0700 (PDT) Received: from [10.0.1.189] (host86-148-234-108.range86-148.btcentralplus.com. [86.148.234.108]) by smtp.gmail.com with ESMTPSA id o76sm3811844wmg.43.2017.08.02.06.48.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 06:48:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-81CD603F-A24E-4C40-8A02-DA5B75EB797E Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (14G60) In-Reply-To: <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> Date: Wed, 2 Aug 2017 14:48:21 +0100 Cc: Mark Andrews , dnsop WG , Jacob Hoffman-Andrews Content-Transfer-Encoding: 7bit Message-Id: <54BC9FB5-4943-4D64-8419-E6B32E4CF0A7@hopcount.ca> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> To: Mike West Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:48:26 -0000 --Apple-Mail-81CD603F-A24E-4C40-8A02-DA5B75EB797E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Wow. That was horribly-formatted. Apologies for the iPad MIME-crime. > On Aug 2, 2017, at 14:34, Joe Abley wrote: >=20 > Hi Mike, >=20 > On Aug 2, 2017, at 09:54, Mike West wrote: >=20 > What would you like to see in the document in order to address this concer= n? A requirement that a `localhost` zone be created and delegated as an inse= cure [...]= --Apple-Mail-81CD603F-A24E-4C40-8A02-DA5B75EB797E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Wow. That was horribly-formatted. Apologies for the iPad MIME-crime.

On Aug 2, 2017, at 14:34, Joe Abley <jabley@hopcount.ca> wrote:

Hi Mike,

On Aug 2, 2017, at 09:54, Mike West <mkwst@google.com> wrote:

What would you like to see in the document in order to address this concern? A requirement that a `localhost` zone be created and delegated as an insecure

[...] --Apple-Mail-81CD603F-A24E-4C40-8A02-DA5B75EB797E-- From nobody Wed Aug 2 06:58:50 2017 Return-Path: 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 B8FC2126C83 for ; Wed, 2 Aug 2017 06:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 mp1BMs4ATTY5 for ; Wed, 2 Aug 2017 06:58:47 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB4912008A for ; Wed, 2 Aug 2017 06:58:47 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v105so19136118wrb.0 for ; Wed, 02 Aug 2017 06:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8rOT+LZkD6gCdYU8igsCFeawUgutx3cB4V8z050TQEE=; b=zCwKMzej3o6NpA9w4ZwY/1GYAdao+jG0xr7VOHeN4koBZo5EKy7nJk7bwx4pRK7U+1 ED9JKakjshT0VP+QsH8ULbld77GXSLN7ZTtXguonw80m5uwvfyTZ2RludfzG+Q0PmRTe +JqblSJXPlWiBrexShMDj+AzYNkU5VKQLEb+fsnMSMOcXgOk3dd9Hd7YnXeCJaeIMPZH 6Wh5GqQwpxWMd8EIfVNdfnDZPhOluCw5ZpMB5+pjLEQtfWz5+hvy5CUHxMT8qw1kZatb uXF/vaCjPO/w9RVb0phL2DEVAjbARo57Xn49bjOHQ5alcsViUXr/Q/cikQdToNqg5H3X 5jSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8rOT+LZkD6gCdYU8igsCFeawUgutx3cB4V8z050TQEE=; b=SWftsqioqDWZxoaREg8c213/kSm6MCiY+d95xrDYeupon5Kxo3dL0bj7B5ahf51S3A orNALZuicWJjeKpbdaXSJU1qsPc/sNKOSznX/JmlAtr3zg3w9lM28SvtN05vWyS7zhiR jgUPG9f7U/IkrCTWryUfS0CZf/WosGMA1qyrquvsKSQotZBIHmN/qd88TLoXsFH5FgXe m3g8wLgNxyKU77wKj+rjtxeyEOYUDDDBFbI/1Vh3hBVWbcEOwMpPx0e6cjb/lRrMA+NI k01f1Ud8ZhiNWcz/j1ZQ1oka/b1OgFCEu2pqWrg1ImlzmLee1ZIb+jClhC5lq67TCJku v0SQ== X-Gm-Message-State: AIVw111WbqZ1MRARzPakMEPUXKEU0cQUQmLC3eTljWLpeIb9GPZ+eImW BIKcv++dBsnDh9zv7H2xxymDaQNTBUC9 X-Received: by 10.223.149.102 with SMTP id 93mr16624751wrs.25.1501682325747; Wed, 02 Aug 2017 06:58:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 06:58:44 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> From: Richard Barnes Date: Wed, 2 Aug 2017 09:58:44 -0400 Message-ID: To: Ted Lemon Cc: william manning , dnsop , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="94eb2c0df18c9791f50555c5a9b7" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 13:58:49 -0000 --94eb2c0df18c9791f50555c5a9b7 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 9:18 AM, Richard Barnes wrote: > > > On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon wrote: > >> On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: >> >> But of course having IP addresses in URLs is both a PITA for developers >> and an anti-pattern more generally. >> >> >> While true, I would argue that this is actually a problem. E.g., I >> actually literally cannot surf to a link-local URL without having a DNS >> record for it, because http://[ >> fe80::1806:ec37:3d5f:9 >> 580%en0]/ has an >> interface identifier in it, and modern browsers consider this an >> anti-pattern, I guess. And you don't want to put link-local addresses in >> DNS, even if it made sense to do so, so what is one to do? I'm not >> convinced that this anti-pattern is the wrong anti-pattern, but here we >> have two examples of it being problematic, in the least. >> >> If "localhost" were properly defined to be loopback, then applications >> could just hard-wire resolution, and not depend on the good graces of the >> platform resolver. As, for example, Firefox does with ".onion" today: >> >> >> Right. But there was actually a long discussion on why that's >> problematic when we were doing the .onion RFC. The reason is that one >> can't count on any particular piece of application software correctly >> interpreting the rightmost label. We can write RFCs encouraging it, but >> if I am writing a URL into a piece of HTML, I have no idea whether the >> thing that interprets the HTML will or will not do the right thing. >> > > The point you're missing here is that the application is both the thing > relying on the definition of "localhost" and the thing empowered to enforce > the RFC. If the application doesn't care whether "localhost" resolves to > anything special, then it can pass it to the platform and take its > chances. If it does, it can hard-wire it to loopback. > To address the concerns of HTML authors here: As with any change to web semantics, this introduces a challenge for web developers because different versions of browsers will interpret things differently. For example, if the W3C Secure Contexts spec changes to treat "localhost" URLs as secure, and browsers implement that, then if you load " http://localhost" in a new browser, it will be get access to certain APIs that it wouldn't on earlier versions. Two points here: 1. It's up to the browsers to make this transition fail safe, in the sense that if you write code that depends on "localhost" being secure, then your code will break if the browser is not going to ensure that "localhost" is loopback. This is what the Secure Contexts spec is for, and the gist of my comments above. 2. Web developers have to deal with this sort of incompatibility all the time anyway, because their sites are accessed by many different browsers with different capabilities. In other words, there's only breakage risk here (not security risk), only for new things, and not any worse than web developers already have to deal with. And based on the feedback from web developers so far, the risk of breakage is strongly preferred to the pain of hard-coding IP addresses. --Richard > >> We just accept that as a risk with .onion because we don't have a better >> option, but for localhost we definitely do have a better option. That's >> all I'm saying. >> > > Using IP addresses is not a better option. > > --Richard > --94eb2c0df18c9791f50555c5a9b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 9:18 AM, Richard Barnes <rlb@ipv.sx> wro= te:


On Wed, Aug 2, 2= 017 at 9:10 AM, Ted Lemon <mellon@fugue.com> wrote:
On Aug 2= , 2017, at 9:02 AM, Richard Barnes <rlb@ipv.sx> wrote:
But of course having IP addresses in URLs is both a PITA for dev= elopers and an anti-pattern more generally.
While true, I would argue that this is actually a problem. = =C2=A0 E.g., I actually literally cannot surf to a link-local URL without h= aving a DNS record for it, because http://[fe80::1806:ec37:3d5f:9580%en0]/=C2=A0has an interface identifier in it, and modern browsers = consider this an anti-pattern, I guess. =C2=A0 And you don't want to pu= t link-local addresses in DNS, even if it made sense to do so, so what is o= ne to do? =C2=A0 I'm not convinced that this anti-pattern is the wrong = anti-pattern, but here we have two examples of it being problematic, in the= least.

If "localho= st" were properly defined to be loopback, then applications could just= hard-wire resolution, and not depend on the good graces of the platform re= solver.=C2=A0 As, for example, Firefox does with ".onion" today:<= /div>

Right. =C2=A0 But there was a= ctually a long discussion on why that's problematic when we were doing = the .onion RFC. =C2=A0 The reason is that one can't count on any partic= ular piece of application software correctly interpreting the rightmost lab= el. =C2=A0 We can write RFCs encouraging it, but if I am writing a URL into= a piece of HTML, I have no idea whether the thing that interprets the HTML= will or will not do the right thing.

The point you're missing here is that the application is = both the thing relying on the definition of "localhost" and the t= hing empowered to enforce the RFC.=C2=A0 If the application doesn't car= e whether "localhost" resolves to anything special, then it can p= ass it to the platform and take its chances.=C2=A0 If it does, it can hard-= wire it to loopback.

To address the concerns of HTML authors here:

As with any change to web semantics, this introduces a challenge for web = developers because different versions of browsers will interpret things dif= ferently.=C2=A0 For example, if the W3C Secure Contexts spec changes to tre= at "localhost" URLs as secure, and browsers implement that, then = if you load "http://localhost" i= n a new browser, it will be get access to certain APIs that it wouldn't= on earlier versions.

Two points here:
<= br>
1. It's up to the browsers to make this transition fail s= afe, in the sense that if you write code that depends on "localhost&qu= ot; being secure, then your code will break if the browser is not going to = ensure that "localhost" is loopback.=C2=A0 This is what the Secur= e Contexts spec is for, and the gist of my comments above.
2. Web developers have to deal with this sort of incompatibili= ty all the time anyway, because their sites are accessed by many different = browsers with different capabilities.

In other wor= ds, there's only breakage risk here (not security risk), only for new t= hings, and not any worse than web developers already have to deal with.=C2= =A0

And based on the feedback from web develo= pers so far, the risk of breakage is strongly preferred to the pain of hard= -coding IP addresses.

--Richard
= =C2=A0


<= /div>
=C2=A0
We just accept that as a risk with .oni= on because we don't have a better option, but for localhost we definite= ly do have a better option. =C2=A0 That's all I'm saying.

Using IP addresses is not a better option.

<= /div>
--Richard

--94eb2c0df18c9791f50555c5a9b7-- From nobody Wed Aug 2 07:12:43 2017 Return-Path: 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 BCE29126BFD for ; Wed, 2 Aug 2017 07:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 9spAyC9xneVg for ; Wed, 2 Aug 2017 07:12:40 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 1643C126C83 for ; Wed, 2 Aug 2017 07:12:40 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:43465) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dcuO6-000asX-d0 (Exim 4.89) for dnsop@ietf.org (return-path ); Wed, 02 Aug 2017 15:12:38 +0100 Date: Wed, 2 Aug 2017 15:12:37 +0100 From: Tony Finch To: dnsop@ietf.org In-Reply-To: <20170731201310.GI8146@mournblade.imrryr.org> Message-ID: References: <20170731171107.GA42492@isc.org> <306070B3-DD80-41F2-A0AA-2004131D0F23@nohats.ca> <53F8E12A-85F9-44F1-9CA5-F546244832D0@time-travellers.org> <8506D4D8-E31B-4AEB-AC7E-4C89EAEEA9DC@hopcount.ca> <20170730074253.GA33522@isc.org> <20170731171107.GA42492@isc.org> <20170731201310.GI8146@mournblade.imrryr.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 14:12:42 -0000 Viktor Dukhovni wrote: > On Mon, Jul 31, 2017 at 05:11:07PM +0000, Evan Hunt wrote: > > > Are there applications specifically trusting AD=1 and behaving differently > > than with AD=0? > > On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote: > > > Postfix is one but last I knew only when resolv contains localhost. > > Not only Postfix, also Exim, and perhaps also Sendmail some day > if/when DANE support appears there, And ssh can be configured to use the AD bit for SSHFP authentication. There are a few alternatives for ssh + DNSSEC and they interact in ways that are not always ideal - see http://fanf.livejournal.com/130577.html > The AD bit is exactly the right DNSSEC interface. All that's > missing from the traditional libresolv (and not missing from recent > innovations in res_ninit(), res_nsearch(), ...) is the ability to > specify the loopback address as the sole resolver in the application. Yep. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Forties, Cromarty: South 3 or 4, backing east 5 or 6, becoming cyclonic, then southwest 4 or 5 later. Slight becoming moderate. Rain or showers. Moderate or good. From nobody Wed Aug 2 07:26:52 2017 Return-Path: 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 5706E132017 for ; Wed, 2 Aug 2017 07:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 nk_-JC-VExJm for ; Wed, 2 Aug 2017 07:26:50 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 321BF1275F4 for ; Wed, 2 Aug 2017 07:26:50 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:43823) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dcubm-000mB9-fM (Exim 4.89) (return-path ); Wed, 02 Aug 2017 15:26:46 +0100 Date: Wed, 2 Aug 2017 15:26:46 +0100 From: Tony Finch To: Ted Lemon cc: Richard Barnes , dnsop , Jacob Hoffman-Andrews , william manning In-Reply-To: <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> Message-ID: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <7066211F-69B4-4B69-840B-A811D19980BF@fugue.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 14:26:51 -0000 Ted Lemon wrote: > > And you don't want to put link-local addresses in DNS, even if > it made sense to do so, so what is one to do? As far as I know it isn't even possible :-) (Some time ago I investigated support for link-local addresses in stub resolvers, and I found that it was usually broken or nonexistent. A common bug is to squash the recursive server into a 128 bit v6 address and 16 bit port, omitting any interface ID.) Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode North Utsire, South Utsire: Southwesterly 3 or 4, backing southerly or southeasterly 5 to 7, perhaps gale 8 later in South Utsire. Slight becoming moderate. Showers then rain. Moderate or good. From nobody Wed Aug 2 07:41:47 2017 Return-Path: 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 01048131C34 for ; Wed, 2 Aug 2017 07:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 BwMCE2BDpEbr for ; Wed, 2 Aug 2017 07:41:45 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 D0F1F1274A5 for ; Wed, 2 Aug 2017 07:41:44 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:44192) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dcuqE-000ymF-fr (Exim 4.89) (return-path ); Wed, 02 Aug 2017 15:41:42 +0100 Date: Wed, 2 Aug 2017 15:41:42 +0100 From: Tony Finch To: Mark Andrews cc: dnsop@ietf.org In-Reply-To: <20170730003832.EF6828069BE6@rock.dv.isc.org> Message-ID: References: <20170730003832.EF6828069BE6@rock.dv.isc.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] CDS/CDNSKEY RRSet authentication X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 14:41:46 -0000 Mark Andrews wrote: > > The purpose was for the CDS/CDNSKEY tools to not have to fetch the > current DNSKEY RRset to be able to validate the records provided they > have a current KSK. Oh, that's neat, thanks! Having thought about it a bit more I understand why the draft says what it does and why that makes sense. It's difficult that KSK can mean four different and not necessarily congruent things: 1. keys with the SEP bit set 2. keys that sign the DNSKEY RRset 3. keys with digests in the DS RRset 4. keys that are trust anchors My understanding is that for a validator the SEP bit is irrelevant. For 2 and 3 the distinction I needed is that the DS keys are the ones authenticated by the parent; the signing of the DNSKEY RRset allows the child to authenticate additional keys (i.e. ZSKs). But from the parent's point of view what matters is that the RRset as a whole is signed by a parentally authenticated key. Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Tyne, Dogger, Fisher, German Bight: South or southwest 3 or 4, increasing 5 or 6, occasionally 7 later. Slight becoming moderate. Rain then showers. Moderate or good. From nobody Wed Aug 2 07:45:16 2017 Return-Path: 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 0AB2613211D for ; Wed, 2 Aug 2017 07:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 Jmvl6uX3a8lF for ; Wed, 2 Aug 2017 07:45:15 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51F1A131CA2 for ; Wed, 2 Aug 2017 07:45:15 -0700 (PDT) Received: from [192.168.1.33] (unknown [47.143.68.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B61A461FF3; Wed, 2 Aug 2017 14:45:13 +0000 (UTC) Message-ID: <5981E579.1040808@redbarn.org> Date: Wed, 02 Aug 2017 07:45:13 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: william manning CC: Jacob Hoffman-Andrews , dnsop References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 14:45:16 -0000 william manning wrote: > ... > if you are concerned that completion logic is broken in resolvers > and the string "localhost" is not appended to the domain, then you > really are asking for the root servers to backstop the query with an > entry for localhost. and for the first 20 years of the DNS, there was > an entry for localhost. in many of the root servers. it was phased > out for several reasons, two key ones were DNSSEC and the fact that > most resolvers had corrected their broken completion logic. There is > no good reason to bring it back for special processing. It's just a > string. +1. -- P Vixie From nobody Wed Aug 2 07:56:36 2017 Return-Path: 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 06B7D124207 for ; Wed, 2 Aug 2017 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 s6SQS8BbKLez for ; Wed, 2 Aug 2017 07:56:33 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A007D120727 for ; Wed, 2 Aug 2017 07:56:33 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 Aug 2017 07:56:31 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Wed, 2 Aug 2017 07:56:31 -0700 From: Edward Lewis To: Shane Kerr , "dnsop@ietf.org" , Paul Wouters Thread-Topic: Trusting what you see - was Re: [Ext] Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error Thread-Index: AQHTC5+Gjh/LhWYWr0mo/goIazwVqA== Date: Wed, 2 Aug 2017 14:56:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.1.170721 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.236] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3584505391_1665324243" MIME-Version: 1.0 Archived-At: Subject: [DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 14:56:35 -0000 --B_3584505391_1665324243 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" wrote: >... >I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? If a receiver can't trust what it gets from the network, you can't run a protocol. Dead in the water. No matter what, what a receiver does next will depend on what it gets from the network (or doesn't get/timeout). That happens now, in an unmanaged way. IMHO, it would be good to address that (the reactions, as opposed to elaborating on the error). If you are worried about having trustable error codes, think of a way to secure the channel (like TSIG). If you are worried and can't secure the channel, then it doesn't matter whether RCODES are extended or not - you have nothing trustable to act upon. (See: dead in the water.) Once you have faith that there's usefulness in the error/response code you do receive, then you can design what the reaction is. (If you are worried, you need to do what is necessary to build the faith or this will not be solvable.) I sent a long message urging that the response indicate the next step, not so much indicating what went bad. I won't belabor that - my motivation comes from the observation that many folks are used to "debugging" DNS via query/resposnse as they are not the authorized operator of the answering system. Extending RCODEs should be about solving the protocol's needs, not about preserving the ability of remote debugging of servers, leave that to the authorized operator. --B_3584505391_1665324243 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBQAYOBVzRWVkVkQXq+/GxWOgZPfPjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDIxNDU2MzFaMA0GCSqGSIb3 DQEBAQUABIIBAAigZECpoKj+uZG2NZMNRwFt0SIYuENJFhyat/xioaCTNnHG9kSic2Ua0jSL gv8I7sJFvXtUbPh6qZH3URvrw8Smxl3GZZHwKmxocVDZSInF95nzyMGYDb9VvIegnmcqyFSp NpffNMAumNXGMB5a15NULoNULQZCtQ323LtY0w5KsVvB71s2Nlp24Tr4XAL6Bt35U5U/NvOF A2Fwe+1zQ5ahqCip3wddKGnQvqB5WnnxrlUIMbRVlWq9j0XS7quwBtPq246BPVoNeIx4YVck dpRVzanahiR1Zqdj0WBx9PSBInYGkg5Ynh32bXGzC+FGYYQ480+pCLxF1MM35gB3WQU= --B_3584505391_1665324243-- From nobody Wed Aug 2 10:24:08 2017 Return-Path: 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 8AE31131FC0 for ; Wed, 2 Aug 2017 10:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.002 X-Spam-Level: X-Spam-Status: No, score=-7.002 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 dCs0zbaxww7s for ; Wed, 2 Aug 2017 10:24:05 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2724131E9F for ; Wed, 2 Aug 2017 10:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=KlMoKDcll+xxxVPuZ4k9hoRTp4zC+wLscyFRz4yKSFA=; b=hvD9Uqs+i5/Q69nWWvzsSnjhcjMJ+GKYxQ2NYAPuVDdxQICbowHlj5KYM30gFqlMurXbu8CIdASt9rv1HkZSm5pYHDovLHwnyI4UszGOuIIRoLMH9hiSRGJSjQNlnT863v/VhN+WmjTTmYkmatO1J6L3i2f2t8lOf42l0umM9lE=; Received: ; Wed, 02 Aug 2017 10:24:04 -0700 To: Mark Andrews Cc: dnsop@ietf.org References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> From: Jacob Hoffman-Andrews Message-ID: <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> Date: Wed, 2 Aug 2017 10:24:05 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170802012345.2CE2680BCC5E@rock.dv.isc.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 17:24:08 -0000 On 08/01/2017 06:23 PM, Mark Andrews wrote: > The query for foo.localhost doesn't need to hit-the-wire for this > to be a issue. Ask your self why RFC 6303, Security section has > > As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA > namespaces, the zones listed above will need to be delegated as > insecure delegations, or be within insecure zones. This will > allow DNSSEC validation to succeed for queries in these spaces > despite not being answered from the delegated servers. > > or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa". RFC 6303 says "as DNSSEC is deployed within...". There's no plan to deploy DNSSEC within .localhost, because it doesn't make sense there; all resolutions should be handled locally. > We didn't add the requirement for insecure delegations for the fun > of it. We added it so that the tools that validate will not break > when those names are being used. Can you tell me more about what type of tools you're thinking of here? Are those tools expected to handle "foo.localhost" domains? If so, what do they currently do with such domains? To put it another way: is your concern about new potential for breakage under this draft, or are you saying that there is existing breakage that we might as well fix as long as we are touching ".localhost"? From nobody Wed Aug 2 11:02:25 2017 Return-Path: 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 DBBB4129417 for ; Wed, 2 Aug 2017 11:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 m6X2nI-IFKEL for ; Wed, 2 Aug 2017 11:02:22 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C494126E3A for ; Wed, 2 Aug 2017 11:02:22 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id D7BB712C0F92; Wed, 2 Aug 2017 14:02:21 -0400 (EDT) Date: Wed, 2 Aug 2017 14:02:21 -0400 From: Robert Edmonds To: Ted Lemon Cc: Mike West , Richard Barnes , dnsop , Jacob Hoffman-Andrews , william manning Message-ID: <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 18:02:24 -0000 Ted Lemon wrote: > But we are arguing that "localhost" should be treated specially by every piece of software that looks at it, when its default meaning is "look up localhost in the DNS and connect to one of the addresses that you get in response." RFC 6761 §6.3 already says that "localhost" should be treated specially by pretty much every piece of software that looks at it. But especially: 2. Application software MAY recognize localhost names as special, or MAY pass them to name resolution APIs as they would for other domain names. 3. Name resolution APIs and libraries SHOULD recognize localhost names as special and SHOULD always return the IP loopback address for address queries and negative responses for all other query types. Name resolution APIs SHOULD NOT send queries for localhost names to their configured caching DNS server(s). (In practice, "localhost" already does get treated specially, especially by operating systems that place a "Name Service Switch" or similar component in front of the DNS stub resolver. If you put "http://localhost/" into your browser bar, you shouldn't see a DNS query for "localhost" leave your machine.) Doesn't "Application software MAY recognize localhost names as special" already give more than enough permission for browser developers to treat "localhost" (and any subdomain of "localhost") specially, for instance by hardcoding the names to a loopback address, or filtering the result from the system's name resolver to verify that only a loopback address is used? Or only allowing the "Secure Context" flag to be set when the localhost name resolves to a loopback address. draft-west-let-localhost-be-localhost-03 upgrades the requirements in RFC 6761 §6.3 to make them much stricter, for all applications, converting SHOULDs to MUSTs, etc. So we're not arguing about whether localhost "should" be treated specially, but whether it MUST be treated specially, by all applications. Can the W3C not impose stricter requirements on browser developers even if 6761 doesn't impose mandatory treatment for "localhost"? Maybe a smaller addition to RFC 6761 §6.3 would be sufficient for the W3C? Something like: Application software specifications MAY require that application software recognize localhost names as special. But that seems weird because it's arguably just a specific case of requirement #2. -- Robert Edmonds From nobody Wed Aug 2 12:09:40 2017 Return-Path: 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 538D9131D37 for ; Wed, 2 Aug 2017 12:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 vsIkLgLNu0rd for ; Wed, 2 Aug 2017 12:09:38 -0700 (PDT) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B5C131C82 for ; Wed, 2 Aug 2017 12:09:37 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id x10so21589510vkd.0 for ; Wed, 02 Aug 2017 12:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Zepk+uVnPxT/krz3r7HhS3Sccp0CuoqIXsb9sfIgtkE=; b=HT7kX8Dy9EqAknhJtQJAk9hByckhy6dxkTaVGzTud+lHHtTLaA0rkOehmfmvt1N3FV dkJLqgJjIIpH+2LlSH0Soc47qQTQRrJH3MFBPbZ9j7JBUkUP1/turwOrPp5rcRKxA3Nl a5EPHiq/ZjuziFgjikzDmMjai6Y0/P3+syD0Y2+hBESkCRP4u5m48f/4ZsLM6bmIO7WX CPrIcy0cxRooH0Wy3nNMf3YP1IsF2Gs/eqZEAjX0mBGNekvGjNgiYSIVc7Ue+SJVne5n u0ryhoQOxyE4ZgSaLfsyEq461SAwzKgqosNQjpaPtc1zNu3lvcwgYodHH020BsHBaprQ EwTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Zepk+uVnPxT/krz3r7HhS3Sccp0CuoqIXsb9sfIgtkE=; b=kY49K4tGWNY+AiAxHDW3hmR/0Xvw8hDN1SkZYNYtxotw/TFhx1zQvsu6NNWv5/m0W4 0JLYQNK1z1cAxufrG9MK1Y/Kz51p/ameiQHl5yr5WzLGFbW1rbEZd+FB+cm8sd5GmoT3 ye9mytrz5eNYhA7dBQccN9ZUbevcIBmmwxAEQgRlPfdwr9Gz2Hs8b/FPaJ/f9R+pAL6G zrDA8X686SR8jCTIn1nO2Ane+UQ3SiYo7YNFoVO7P35+WBMIcPwzC2AQb7IjMAAiMN5q QOzgV4LivW9gkUiLipASNbeAAbSpv2c8xDu1nsKe1UWOPqXbB7o3vTrtzPEewJQaqyV3 BTHw== X-Gm-Message-State: AIVw110pPU+XpF0+m/1WpAdGAFqQ44fFENx6QJTaee4A7P6LWrhUEkiM WSkmMjIImIsmXQsYvh1FAHKYTvwELP/Ngef3kw== X-Received: by 10.31.0.69 with SMTP id 66mr15559889vka.96.1501700976426; Wed, 02 Aug 2017 12:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.14 with HTTP; Wed, 2 Aug 2017 12:09:35 -0700 (PDT) In-Reply-To: <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> From: Matthew Pounsett Date: Wed, 2 Aug 2017 15:09:35 -0400 Message-ID: To: Jacob Hoffman-Andrews Cc: Mark Andrews , dnsop Content-Type: multipart/alternative; boundary="001a113da99a42710f0555ca0127" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 19:09:39 -0000 --001a113da99a42710f0555ca0127 Content-Type: text/plain; charset="UTF-8" On 2 August 2017 at 13:24, Jacob Hoffman-Andrews wrote: > On 08/01/2017 06:23 PM, Mark Andrews wrote: > > The query for foo.localhost doesn't need to hit-the-wire for this > > to be a issue. Ask your self why RFC 6303, Security section has > > > > As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA > > namespaces, the zones listed above will need to be delegated as > > insecure delegations, or be within insecure zones. This will > > allow DNSSEC validation to succeed for queries in these spaces > > despite not being answered from the delegated servers. > > > > or draft-ietf-homenet-dot-10 is doing the same thing for "home.arpa". > > RFC 6303 says "as DNSSEC is deployed within...". There's no plan to > deploy DNSSEC within .localhost, because it doesn't make sense there; > all resolutions should be handled locally. > 6303 is talking about what to do with DNS zones for RFC1918 and other local-scope address space when their global-scope parent zones are signed. The correct rephrasing of that quote which would apply to .localhost is "as DNSSEC is deployed within the root namespace..." An event which is long past. In the case where 'localhost' is being passed to DNS resolution software, a validating stub (for example inside a web browser) needs a way to know that the 'localhost' TLD should be treated as insecure. In that case, the only way to accomplish that is with an insecure delegation at the root. --001a113da99a42710f0555ca0127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 2 August 2017 at 13:24, Jacob Hoffman-Andrews <= jsha@eff.org> wrote:
On 08/01/2017 06:23 PM, Mark Andrews wrote:
> The query for foo.localhost doesn't need to hit-the-wire for this<= br> > to be a issue.=C2=A0 Ask your self why RFC 6303, Security section has<= br> >
>=C2=A0 =C2=A0 As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARP= A
>=C2=A0 =C2=A0 namespaces, the zones listed above will need to be delega= ted as
>=C2=A0 =C2=A0 insecure delegations, or be within insecure zones.=C2=A0 = This will
>=C2=A0 =C2=A0 allow DNSSEC validation to succeed for queries in these s= paces
>=C2=A0 =C2=A0 despite not being answered from the delegated servers. >
> or draft-ietf-homenet-dot-10 is doing the same thing for "home.ar= pa".

RFC 6303 says "as DNSSEC is deployed within...". There'= ;s no plan to
deploy DNSSEC within .localhost, because it doesn't make sense there; all resolutions should be handled locally.

<= div>
6303 is talking about what to do with DNS zones for RFC1918 and ot= her local-scope address space when their global-scope parent zones are sign= ed. The correct rephrasing of that quote which would apply to .localhost is= "as DNSSEC is deployed within the root namespace..." =C2=A0An ev= ent which is long past.

In the case where 'loc= alhost' is being passed to DNS resolution software, a validating stub (= for example inside a web browser) needs a way to know that the 'localho= st' TLD should be treated as insecure.=C2=A0 In that case, the only way= to accomplish that is with an insecure delegation at the root.
=


--001a113da99a42710f0555ca0127-- From nobody Wed Aug 2 13:27:52 2017 Return-Path: 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 04633131C84 for ; Wed, 2 Aug 2017 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 zImiS8CSd8RZ for ; Wed, 2 Aug 2017 13:27:49 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8958131C3B for ; Wed, 2 Aug 2017 13:27:48 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id d136so33666790qkg.3 for ; Wed, 02 Aug 2017 13:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QQ7anu2Q45Li/SCATdoGqHxFujHA4TtoBWkvxNu5c9k=; b=ys9YzzFLlG0E4EQGhPaV6z+O5M9ZodpOQGP8LNNBQOEIGxkahsOKiojEKiZCgIbsYG pHd4evp7qJoVBLX3JOoVUt5geUlpMRQKTwIw2xtJlMffJwXZmGtWS4/rP8L6DxdDyoKW xbu5jomsLusvWm36DunLWXYKXfAw2esQEwNnBNYnf+Yd0Zljw4DlcsDIS9G5EfUZmXP2 bNj7KOfChsSh0gavD8bow6VkQhSoeRM2QtpxvQGzWZ8IUsRdYzK3Yij/nmS0gu84sbIP wsHzfFJKRwhHozBMdB+QujspIOsPuHQ1Qc+4yVn6+E9sHmGBF3AxnCNnSQUPsP7o7Pq2 kTDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QQ7anu2Q45Li/SCATdoGqHxFujHA4TtoBWkvxNu5c9k=; b=KuYw9tgpsr8D1d0thW+bABrJfW0uhcPEJzOa8WpnROsgwLdp82hzCdfkzRW7QffFor QIgumgknj0ajA9OkDuM5snjnJ4INj+2KbTWf0HbC/Tvd4JMIYx21ciE0NU6x6DmtCvho 9tH5lnu/8JOkLbT50op8a7YSXr+a2cpNaf+m/Ieu4VzZlkCo/k/iR596vVVyOQbZP9lf UAqHOPQ7BlJKZusfiCi5FdvaO4XtQ46RD4DB6zNTn0kVTXzp9bVhXId3K+FySbG/WYqP OqZQ38sRXX0g9861kRY5Whg7DQPknQ1IfqKR9OCc3dGy4UBvh8zfcy5QOKuHPIjAmGlH 2EeQ== X-Gm-Message-State: AIVw110Ty9f+YOeM9hb5L2hJC/1eNtDUBEGxFo0laZb7zQ9nDVkNAcP2 qv4BEtRWFGPFREAw X-Received: by 10.55.133.195 with SMTP id h186mr31178099qkd.21.1501705668054; Wed, 02 Aug 2017 13:27:48 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id v64sm23909135qkd.96.2017.08.02.13.27.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 13:27:47 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F2F41092-B93E-4544-A6E4-3DE1B038F04A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 2 Aug 2017 16:27:45 -0400 In-Reply-To: <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> Cc: Mike West , Richard Barnes , dnsop , Jacob Hoffman-Andrews , william manning To: Robert Edmonds References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 20:27:51 -0000 --Apple-Mail=_F2F41092-B93E-4544-A6E4-3DE1B038F04A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Aug 2, 2017, at 2:02 PM, Robert Edmonds wrote: > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 =C2=A76.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguing about whether > localhost "should" be treated specially, but whether it MUST be = treated > specially, by all applications. Can the W3C not impose stricter > requirements on browser developers even if 6761 doesn't impose = mandatory > treatment for "localhost"? It should be MUST in both cases. But writing that in an RFC doesn't = make it so. Bear in mind when you look at the W3C document that it is = talking about what would be ideal, not what is actually present in = browsers. As an app developer worried about security footprint, I would be wiser = to be cautious and use ::1 or 127.0.0.1, rather than using localhost and = relying on the name resolution infrastructure. But the use case that I = would be most skeptical about is using localhost in a URL. I think = that should be MUST NOT. Apparently there is not wholehearted = agreement on this topic, however... :) --Apple-Mail=_F2F41092-B93E-4544-A6E4-3DE1B038F04A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Aug 2, 2017, at 2:02 PM, Robert Edmonds <edmonds@mycre.ws> = wrote:
draft-west-let-localhost-be-localhost-03 upgrades the = requirements in
RFC 6761 =C2=A76.3 = to make them much stricter, for all applications,
converting SHOULDs to MUSTs, etc. So we're not = arguing about whether
localhost "should" = be treated specially, but whether it MUST be treated
specially, by all applications. Can the W3C not = impose stricter
requirements on = browser developers even if 6761 doesn't impose mandatory
treatment for = "localhost"?

It should be MUST in both cases.   But writing that in = an RFC doesn't make it so.   Bear in mind when you look at the W3C = document that it is talking about what would be ideal, not what is = actually present in browsers.

As an app developer worried about = security footprint, I would be wiser to be cautious and use ::1 or = 127.0.0.1, rather than using localhost and relying on the name = resolution infrastructure.   But the use case that I would be most = skeptical about is using localhost in a URL.   I think that should = be MUST NOT.   Apparently there is not wholehearted agreement on = this topic, however... :)

= --Apple-Mail=_F2F41092-B93E-4544-A6E4-3DE1B038F04A-- From nobody Wed Aug 2 14:06:24 2017 Return-Path: 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 E56E2132179 for ; Wed, 2 Aug 2017 14:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 4N0dnxyidUFA for ; Wed, 2 Aug 2017 14:06:21 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC71132177 for ; Wed, 2 Aug 2017 14:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=R/O3JxHm+59boKJqdz9BtkxzKgN1IT+/YIo6pJpezi8=; b=laJlsHlWa/hJIl95qKHHtBujxxKszxD7mdBkztbP0yZ1ZwHrsS45N3FADuCZPR/a56rEa7UFnkSiYQIZYCPiOtpLhCByH87TPLZnAN1iAFVR+hEAQR20/9dTKUOH2tvreLQaKVRTfJ2FWnmYSGxXmoa/4+x7SKwaIqwm3FqSf8E=; Received: ; Wed, 02 Aug 2017 14:06:19 -0700 To: Matthew Pounsett Cc: Mark Andrews , dnsop References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> From: Jacob Hoffman-Andrews Message-ID: <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> Date: Wed, 2 Aug 2017 14:06:20 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Received-SPF: skipped for local relay Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 21:06:23 -0000 On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > In the case where 'localhost' is being passed to DNS resolution > software, a validating stub (for example inside a web browser) Ah, this may be where we are finding a disconnect. I believe web browsers never operate validating stub resolvers, but generally ask the operating system resolver library. Do you have a counter-example? I think it's also rare for operating system resolver libraries to validate DNSSEC (rather than leaving it to an upstream recursive resolver). However, even if we take it as a given that operating system stub resolvers should implement DNSSEC validation, they clearly already treat localhost specially, so there is no reason to believe that they would start trying to validate it with DNSSEC once this document is finalized. From nobody Wed Aug 2 15:55:45 2017 Return-Path: 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 A1A181321A0 for ; Wed, 2 Aug 2017 15:55:44 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com 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 ICnJj3eKUvas for ; Wed, 2 Aug 2017 15:55:43 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5D0513219B for ; Wed, 2 Aug 2017 15:55:42 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w45so27135751uac.5 for ; Wed, 02 Aug 2017 15:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=O99IbdsfEyJ6msZFtDhaO2VC+Sp3BLYpCzdDwWgSl+U=; b=YKMOjvKlT4xTqianBiUe7igMdHz9WpQ5n34GGq6SGUhXGKOl+nPgFSi6hOEzqxJQXC j4JHtqTeZzpQgUdqmbnvpBy1vq1yr7chVfewJkiScpo4wTZpCA1heLklXC/5Kg1el7uI ip3UZLBwCdYt9jUTZVeqhwd177rfkkZvbM7j2V961ECjKIqGi8Sg1D0DWgERrw9Z5YB6 XAl1kYRpjFlQTWnCfkUeak6YJ10GRAuV3HyRSwEuNGH6lArcWzsZ/2p0PkEYLdeHnD/T cGv6x/wKGPK6HVI1WOnfwuXspaZJgnD0wgHGzFpnCK4uQVDTxW4vI8qYQnUGxkYiZKSC MWfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=O99IbdsfEyJ6msZFtDhaO2VC+Sp3BLYpCzdDwWgSl+U=; b=Vhg+MMmX22dl2XqeMaIm1R5aZXhT/krxFNI0BVBUVZBijGicPjYTf2lHrfLLEH9MHG bdIeKBeq24GsMD8ML/zvad4nHiXJOrXl/oaeGp4cNcW0quBEXJfMplflxYU+L3npljqT JkDSq07W5qulhDMC6PwVf68BUqifWo+MMZePmvr1FOVaZg7FeIAnP6lWHZlOPNoZrqKF hHVj1heU02ktrZq8lbnmPEZBpqrQYt9F3CdUFPGIxRR5yiSzZhzIzKtky4kDhO2DRl1M tcAQP8OOb5kTQsuT5ex1Vqj0mo5JXcHzvzJBkAg6svTPno/2a7gAwlSkJYqY9e5Dq57h W4xw== X-Gm-Message-State: AIVw110BcMkL3PNK9OTyPEIlx5eiUJ05XMT9SQZ1/BypIBtjrwIsxaaL kcqlJwKw//0gz1ni6vPFxIUrFt6lmiU96Nw= X-Received: by 10.176.94.100 with SMTP id a36mr18078136uah.85.1501714541658; Wed, 02 Aug 2017 15:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.146.194 with HTTP; Wed, 2 Aug 2017 15:55:41 -0700 (PDT) X-Originating-IP: [2001:dc0:2001:210:19b4:4f3:c347:76ab] In-Reply-To: <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> From: George Michaelson Date: Thu, 3 Aug 2017 08:55:41 +1000 Message-ID: To: dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 22:55:44 -0000 A possibly stupid random thought: is there a strong barrier in *all* kernels which enforces 127.0.0.0/8 and ::1 to actually *have* to be local? The 240/4 problem is 5-6 lines of code in *some* UNIX. It wasn't in any sense globally applied. I suspect localhost is somewhat more strongly coded, but I did wonder because Ted's suggestion that use of the literal IP address in either family would the stronger 'keep it local' made me think: what if somebody hand installed a route which somehow took it off-box? I think proscriptive/definitive language over the FQDN/label localhost in DNSSEC is probably still a good thing. IETF is defining behaviours for home.arpa in HOMENET which logistically fall into a very similar bucket (for me at least) so its not like we can't chose to say what behaviours we expect of a label. -G From nobody Wed Aug 2 16:27:46 2017 Return-Path: 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 E7D46131C89 for ; Wed, 2 Aug 2017 16:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 VKBMSRLMOkWn for ; Wed, 2 Aug 2017 16:27:43 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D2EC1241FC for ; Wed, 2 Aug 2017 16:27:43 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t201so1764534wmt.1 for ; Wed, 02 Aug 2017 16:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SLtPwlo2jn9I/Ict/rhgFwjBinx0JcVd+dLDQPJA0hg=; b=urvmdNANzetsiB6bvJ+m8ylNCUKWUfJhmRJbJGOrMsrnPuLtq3KQPlD57P6t6phtFN CMFkDdy/UsjiNpmyvnSw4Jdgrc8FmlrCcBT6SE3uTvdqqsmMo04oAfrBlvuVM9J4VKHR YNEv+YAwFRvQxeKB/naF0u7MhgMfLpzHxUrta19BLrzuLNCSZB6BHXsxeg7ddFybjFnk ebJBAGRCxbOPX7Fip5TLiZBtoXbSp1LcBYxLlagXPxwH64U0yfNSd5UQN7ODDgm1ParZ BvhbP1hXSPNcDLFCFoLoDlYVR6i2kavFVJwA8hC2TLKvIAqApslC2GxZsGONGrRj/pPE UKbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SLtPwlo2jn9I/Ict/rhgFwjBinx0JcVd+dLDQPJA0hg=; b=AT7yiIZ27vU1B2tVcHS3xwgsiX8gjU0/GKLAKfdnkjhIa69yqzy5S0ef12icAtKLfd 2YldU9TUbXi0SzcHQ86xjBfVz3EjtXlpkjBNT1FvMeP4TDlElusLKPz6ZMTqsm3Syi82 xoPHzczmseEP9HHjOk2ZXOGe/ITu1+rFrAfiRcWfhHEDv1WE/x9BgTZLNEP1EEjboGoU aEUqkaZ+baIwuNZzp0097LKEDD8MnmZ/ls3xs68Jj1DPmHDt8CrSAkOzL2SoLfUkYfDm Mmcd0femYvI8Anf9CLEkeB1/PDS5Qem/W/kznusgutRlkMY0OjIktBKqel/EY7HUE+u7 1jbw== X-Gm-Message-State: AIVw113DbwqHnsRQrV0teAO/F3gstm2tGn+KMZLw7n9+tiy2vBIi1Aeh UrVoEjmhtThEQq72MGLMJWoCjzwNJOA1 X-Received: by 10.28.203.206 with SMTP id b197mr4908067wmg.120.1501716461814; Wed, 02 Aug 2017 16:27:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 16:27:40 -0700 (PDT) Received: by 10.28.225.5 with HTTP; Wed, 2 Aug 2017 16:27:40 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> From: Richard Barnes Date: Wed, 2 Aug 2017 19:27:40 -0400 Message-ID: To: Ted Lemon Cc: Robert Edmonds , Mike West , dnsop , Jacob Hoffman-Andrews , william manning Content-Type: multipart/alternative; boundary="94eb2c12f37c42a4ae0555cd9cc3" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 23:27:45 -0000 --94eb2c12f37c42a4ae0555cd9cc3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon wrote: > On Aug 2, 2017, at 2:02 PM, Robert Edmonds wrote: > > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 =C2=A76.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguing about whether > localhost "should" be treated specially, but whether it MUST be treated > specially, by all applications. Can the W3C not impose stricter > requirements on browser developers even if 6761 doesn't impose mandatory > treatment for "localhost"? > > > It should be MUST in both cases. But writing that in an RFC doesn't mak= e > it so. Bear in mind when you look at the W3C document that it is talkin= g > about what would be ideal, not what is actually present in browsers. > > As an app developer worried about security footprint, I would be wiser to > be cautious and use ::1 or 127.0.0.1, rather than using localhost and > relying on the name resolution infrastructure. But the use case that I > would be most skeptical about is using localhost in a URL. I think that > should be MUST NOT. Apparently there is not wholehearted agreement on > this topic, however... :) > You have this backwards. Browser today do take the more cautious, IP-based approach. It sucks for developers. They want to be able to use "localhost", but in order to do it safely, they will need to hard-wire it internally (since as you say, writing an RFC doesn't make resolvers change). And they don't want to hard-wire unless that's the clear semantic because standards are what make the web work. --Richard --94eb2c12f37c42a4ae0555cd9cc3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon <mellon@f= ugue.com> wrote:
On Aug 2, 2017, at 2:02 PM, Robert Edmond= s <edmonds@mycre.w= s> wrote:
draft-west-let-localhost-be-localhost-03 upgrades th= e requirements in
RFC 676= 1 =C2=A76.3 to make them much stricter, for all applications,
converting SHOULDs to MUSTs, etc. So w= e're not arguing about whether
localhost "should" be treated specially, but whether it= MUST be treated
speciall= y, by all applications. Can the W3C not impose stricter
requirements on browser developers even if 6= 761 doesn't impose mandatory
treatment for "localhost"?

It should be MUST in both cases. =C2=A0 But writing that i= n an RFC doesn't make it so. =C2=A0 Bear in mind when you look at the W= 3C document that it is talking about what would be ideal, not what is actua= lly present in browsers.

As an app developer worri= ed about security footprint, I would be wiser to be cautious and use ::1 or= 127.0.0.1, rather than using localhost and relying on the name resolution = infrastructure. =C2=A0 But the use case that I would be most skeptical abou= t is using localhost in a URL. =C2=A0 I think that should be MUST NOT. =C2= =A0 Apparently there is not wholehearted agreement on this topic, however..= . :)

You have this backwards.= =C2=A0 Browser today do take the more cautious, IP-based approach.=C2=A0 It= sucks for developers.=C2=A0 They want to be able to use "localhost&qu= ot;, but in order to do it safely, they will need to hard-wire it internall= y (since as you say, writing an RFC doesn't make resolvers change).=C2= =A0 And they don't want to hard-wire unless that's the clear semant= ic because standards are what make the web work.

-= -Richard

--94eb2c12f37c42a4ae0555cd9cc3-- From nobody Wed Aug 2 16:39:31 2017 Return-Path: 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 225F0131C51 for ; Wed, 2 Aug 2017 16:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 MzFWAZvXrH_y for ; Wed, 2 Aug 2017 16:39:27 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 C8E6F1294A2 for ; Wed, 2 Aug 2017 16:39:27 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 645D234BCDC; Wed, 2 Aug 2017 23:39:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 49CB5160051; Wed, 2 Aug 2017 23:39:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 27266160050; Wed, 2 Aug 2017 23:39:25 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id JfcQDfFr5r4c; Wed, 2 Aug 2017 23:39:25 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B64E216003A; Wed, 2 Aug 2017 23:39:24 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BEDA280D9BB0; Thu, 3 Aug 2017 09:39:21 +1000 (AEST) To: Jacob Hoffman-Andrews Cc: Matthew Pounsett , dnsop From: Mark Andrews References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> In-reply-to: Your message of "Wed, 02 Aug 2017 14:06:20 -0700." <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> Date: Thu, 03 Aug 2017 09:39:21 +1000 Message-Id: <20170802233921.BEDA280D9BB0@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 02 Aug 2017 23:39:29 -0000 In message <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org>, Jacob Hoffman-Andrew s writes: > On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > > In the case where 'localhost' is being passed to DNS resolution > > software, a validating stub (for example inside a web browser) > Ah, this may be where we are finding a disconnect. I believe web > browsers never operate validating stub resolvers, but generally ask the > operating system resolver library. Do you have a counter-example? > > I think it's also rare for operating system resolver libraries to > validate DNSSEC (rather than leaving it to an upstream recursive > resolver). However, even if we take it as a given that operating system > stub resolvers should implement DNSSEC validation, they clearly already > treat localhost specially, so there is no reason to believe that they > would start trying to validate it with DNSSEC once this document is > finalized. The deployment goal of DNSSEC was to have *every* machine/application validating DNSSEC responses or to have a crytographically secure path to one that did for which you knew and accepted its security policy. DNSSEC was designed with this in mind. DNSSEC also requires recursive servers to validate responses or else you can't handle certain threats DNSSEC is designed to handle. Turning on DNSSEC in resolvers also provides some protection from some threats to non-validating clients. Getting validation turned on in recursive servers is the first step in this multi-year plan. We are at about the 60% level for recursive servers and a few percent (maybe) for the machine/application level. Most OS's don't treat localhost specially. It is just a entry in /etc/hosts and/or a zone in the local recursive server and/or localhost. in a zone on the search list. The last of these is how localhost is actually resolved on my machine (MacOS 10.12.6) as the resolver doesn't treat "localhost" as special. It's processed the same way as any other single label name. When you look at foo.localhost the resolution mechanisms /etc/hosts and/or a zone in the local recursive server. If you are mad you apply the search list. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 3 03:52:16 2017 Return-Path: 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 28EE9131D27 for ; Thu, 3 Aug 2017 03:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 BDf80-w4xsMH for ; Thu, 3 Aug 2017 03:52:12 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BDFB131D6B for ; Thu, 3 Aug 2017 03:52:12 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id d71so9106228oih.0 for ; Thu, 03 Aug 2017 03:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bQNA7FHyw+MCv7aSIXI9rwuVGNsief6xzAmdh3jTJJY=; b=vY3KUjaXBP6oIFAwk1qRLG96xdpJzpBEo89V1pP01YfLHPaIAAJP0YEV3K6g2Nrbb8 rX3wu0FH9PQobK4I6QoG3e3vLPU1tNhnTCI2K04d1uvpMApJKVXO8bao2g6iDBkBYIVm BVK3Kuz6Vupr6BQqK3VWgvtrc7Is/MtqOnCBhJkltkCQU82Q4DN3hwV3lYLYx9QNC/vf hGWht/XB0woMrloec6Z1Z790nAit9bIUO4d53AKOTKZsx3lRy+nhyp5Dt1L5I/PV2vuS icpbN3rRYXdHRUE378Sec4X0l0yj5lx7qnGGs0iv2+VUh469FQuIppuTAppJQTKGLX++ 8zIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bQNA7FHyw+MCv7aSIXI9rwuVGNsief6xzAmdh3jTJJY=; b=FQkOZGwF6ESG3POLK+/om+juUixV+BGagAhFbhUXxqld/EQJ96TXepyYSrIkepwdG5 /aVoJSBZE512+JN5Ke7LagVx9b4T05BPCytEQUJcrTN64gb/4IVyw6l94tvRe2Y73YuF JvFOAoPTup6Cm8jXR3cwRXoMOLjid4Zin0PLKCiqJKgNpIHpaFRVg65+THjboiMURVCP ESz7qGIVD7QVTuxfhqzyUo5DiR0mkulwaCtZouw4jIBysTD6X3lof98Crjvwa7EOPX4s PFywkcpNulbErjOiD00fFVfQoORNVz7bDTnZEYmYgDcP3jv8dU9D7oRIHvnALgbQ4zQl fXOw== X-Gm-Message-State: AIVw1117z1tXVgn2o0Pv07iXYfiHkulFvWYc3sJcvPEOvNhSc1RDSEHl +fSIBVqNOxtnaU2QWBYJaP3wvmT24GeJ X-Received: by 10.202.199.138 with SMTP id x132mr1065287oif.52.1501757531339; Thu, 03 Aug 2017 03:52:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.47.5 with HTTP; Thu, 3 Aug 2017 03:51:50 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> From: Mike West Date: Thu, 3 Aug 2017 12:51:50 +0200 Message-ID: To: Richard Barnes Cc: Ted Lemon , Robert Edmonds , dnsop , Jacob Hoffman-Andrews , william manning , Erik Nygren Content-Type: multipart/alternative; boundary="001a11c180443375e60555d72c16" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 10:52:15 -0000 --001a11c180443375e60555d72c16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It seems like there's clear agreement that `localhost` "should" map to loopback addresses. That's what the RFC already says, after all, and it matches my anecdata from conversations with developers (I haven't talked to anyone (outside this group) who expected `localhost` to ever resolve anywhere else). So, that's a good place to start. Some folks in this thread (including me) think that "should" is too weak, and that it would be helpful to make a stronger guarantee that `localhost` matches its colloquial meaning. I think there are some pretty reasonable arguments for this position: 1. RFC6761 says that users "may assume that IPv4 and IPv6 address queries for localhost names will always resolve to the respective IP loopback address". It violates the principle of least astonishment to allow the underlying platform to behave at odds with that assumption. I'd suggest that we should either harden the requirements below, or stop inviting users to make incorrect assumptions. Given the widespread acceptance of those assumptions, the former seems like the right course of action to me. :) 2. Various bits of software behave in various (and inconsistent) ways when presented with a DNS query for `localhost`. "Should" has not been as effective as I'd like in creating an environment in which user expectations are met. Chrome is the client I'm most familiar with, and it takes advantage of the "should"'s and "may"'s in some circumstances to hard-code resolution of `localhost`. That behavior isn't consistent across platforms, however, and, as Richard notes, it would be helpful in our decision-making if we clarified the guarantees the platform ought to provide. 3. Groups like SUNSET4 are actively opposed to hard-coding IP addresses like `127.0.0.1`, but if that's the only way that developers can really ensure users' expectations are met, that's what they'll end up doing. As Richard has noted a few times in this thread: that would be a worse outcome than making stronger guarantees about the meaning of an mapped label. If y'all decide that this is really just something that browsers need to care about, then it's of course possible to address Chrome's use case by overriding RFC 6761 in a W3C spec. If that's the course of action y'all would prefer, I can do that. It seems like taking browsers' handling of `localhost` out of the hands of DNSOP/IETF would be a bad outcome for this group, but it's certainly an option. With regard to DNSSEC delegations, my intuition is that Jacob's assessment is reasonable, but I recognize that I don't know nearly enough about DNSSEC to have a meaningful opinion. I'm happy to accept the group's assessment on this point. Thanks for continuing the conversation! -mike On Thu, Aug 3, 2017 at 1:27 AM, Richard Barnes wrote: > > > On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon wrote: > >> On Aug 2, 2017, at 2:02 PM, Robert Edmonds wrote: >> >> draft-west-let-localhost-be-localhost-03 upgrades the requirements in >> RFC 6761 =C2=A76.3 to make them much stricter, for all applications, >> converting SHOULDs to MUSTs, etc. So we're not arguing about whether >> localhost "should" be treated specially, but whether it MUST be treated >> specially, by all applications. Can the W3C not impose stricter >> requirements on browser developers even if 6761 doesn't impose mandatory >> treatment for "localhost"? >> >> >> It should be MUST in both cases. But writing that in an RFC doesn't >> make it so. Bear in mind when you look at the W3C document that it is >> talking about what would be ideal, not what is actually present in brows= ers. >> >> As an app developer worried about security footprint, I would be wiser t= o >> be cautious and use ::1 or 127.0.0.1, rather than using localhost and >> relying on the name resolution infrastructure. But the use case that I >> would be most skeptical about is using localhost in a URL. I think tha= t >> should be MUST NOT. Apparently there is not wholehearted agreement on >> this topic, however... :) >> > > You have this backwards. Browser today do take the more cautious, > IP-based approach. It sucks for developers. They want to be able to use > "localhost", but in order to do it safely, they will need to hard-wire it > internally (since as you say, writing an RFC doesn't make resolvers > change). And they don't want to hard-wire unless that's the clear semant= ic > because standards are what make the web work. > > --Richard > > --001a11c180443375e60555d72c16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems like there's clear agreement that `local= host` "should" map to loopback addresses. That's what the RFC= already says, after all, and it matches my anecdata from conversations wit= h developers (I haven't talked to anyone (outside this group) who expec= ted `localhost` to ever resolve anywhere else). So, that's a good place= to start.

Some folks in this thread (includin= g me) think that "should" is too weak, and that it would be helpf= ul to make a stronger guarantee that `localhost` matches its colloquial mea= ning. I think there are some pretty reasonable arguments for this position:=

1. =C2=A0RFC6761 says that users "may assume that IPv4 = and IPv6 address queries for localhost names will always resolve to the res= pective IP loopback address". It violates the principle of least aston= ishment to allow the underlying platform to behave at odds with that assump= tion. I'd suggest that we should either harden the requirements below, = or stop inviting users to make incorrect assumptions. Given the widespread = acceptance of those assumptions, the former seems like the right course of = action to me. :)

2.=C2=A0 Various bits of software= behave in various (and inconsistent) ways when presented with a DNS query = for `localhost`. "Should" has not been as effective as I'd li= ke in creating an environment in which user expectations are met. Chrome is= the client I'm most familiar with, and it takes advantage of the "= ;should"'s and "may"'s in some circumstances to hard= -code resolution of `localhost`. That behavior isn't consistent across = platforms, however, and, as Richard notes, it would be helpful in our decis= ion-making if we clarified the guarantees the platform ought to provide.

3.=C2=A0 Groups like SUNSET4 are actively opposed to= hard-coding IP addresses like `127.0.0.1`, but if that's the only way = that developers can really ensure users' expectations are met, that'= ;s what they'll end up doing. As Richard has noted a few times in this = thread: that would be a worse outcome than making stronger guarantees about= the meaning of an mapped label.

If y'all = decide that this is really just something that browsers need to care about,= then it's of course possible to address Chrome's use case by overr= iding RFC 6761 in a W3C spec. If that's the course of action y'all = would prefer, I can do that. It seems like taking browsers' handling of= `localhost` out of the hands of DNSOP/IETF would be a bad outcome for this= group, but it's certainly an option.

With reg= ard to DNSSEC delegations, my intuition is that Jacob's assessment is r= easonable, but I recognize that I don't know nearly enough about DNSSEC= to have a meaningful opinion. I'm happy to accept the group's asse= ssment on this point.

Thanks for continuing the co= nversation!

-mike

On Thu, Aug 3, 2017 at 1:27 AM, Richard Barn= es <rl= b@ipv.sx> wrote:


On Wed, Aug 2, 2017 at 4:27 PM, Ted Le= mon <mellon@fugue.com> wrote:
On Aug 2, 2017, at 2:02 PM, Ro= bert Edmonds <edmo= nds@mycre.ws> wrote:
draft-west-let-localhost-be-localhost-03= upgrades the requirements in
RFC 6761 =C2=A76.3 to make them much stricter, for all applications,
converting SHOULDs to MUST= s, etc. So we're not arguing about whether
localhost "should" be treated specially, bu= t whether it MUST be treated
specially, by all applications. Can the W3C not impose stricter<= br style=3D"font-family:Menlo-Regular;font-size:18px;font-style:normal;font= -variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:st= art;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px= ">requirements on browser develope= rs even if 6761 doesn't impose mandatory
treatment for "localhost"?

It should be MUST in both cases. =C2=A0 But wr= iting that in an RFC doesn't make it so. =C2=A0 Bear in mind when you l= ook at the W3C document that it is talking about what would be ideal, not w= hat is actually present in browsers.

As an app dev= eloper worried about security footprint, I would be wiser to be cautious an= d use ::1 or 127.0.0.1, rather than using localhost and relying on the name= resolution infrastructure. =C2=A0 But the use case that I would be most sk= eptical about is using localhost in a URL. =C2=A0 I think that should be MU= ST NOT. =C2=A0 Apparently there is not wholehearted agreement on this topic= , however... :)

You= have this backwards.=C2=A0 Browser today do take the more cautious, IP-bas= ed approach.=C2=A0 It sucks for developers.=C2=A0 They want to be able to u= se "localhost", but in order to do it safely, they will need to h= ard-wire it internally (since as you say, writing an RFC doesn't make r= esolvers change).=C2=A0 And they don't want to hard-wire unless that= 9;s the clear semantic because standards are what make the web work.
<= span class=3D"HOEnZb">

--Richard=


--001a11c180443375e60555d72c16-- From nobody Thu Aug 3 08:52:04 2017 Return-Path: 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 464EE1323A7 for ; Thu, 3 Aug 2017 08:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 uaFUGHPdH23j for ; Thu, 3 Aug 2017 08:52:01 -0700 (PDT) Received: from relay72.bu.edu (relay72.bu.edu [128.197.228.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86BD11320C5 for ; Thu, 3 Aug 2017 08:52:01 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by relay72.bu.edu (8.14.3/8.14.3) with ESMTP id v73FoVAp008145 for ; Thu, 3 Aug 2017 11:50:32 -0400 Received: by mail-oi0-f72.google.com with SMTP id v68so1280295oia.14 for ; Thu, 03 Aug 2017 08:50:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Lks11ybAR3UlusD/hC7HGvsllizF9itcwHuoBNMZldQ=; b=maD2FGodLqq7LaF2HZzKsBzTAttzHSlGVyD0bpj2GqGh2fCMUQb6PGMrYWGrtPSiUo Nwt6WXI0hS8M0GbUTI5uilbjSMb8y91JItJkZXKfJtxvmb0sZtgIeYwVYkKOS9obABjN WosYkTWO0Cbs732nnUvZXIp7qdUBuWC+OfuoWJRfw+wmqVjuPqB452j3FH3o4nZjCnEl honcZP+G8LSXoHQ3ld/OzmAJ8WU0fv/nLvX1GhWon3wcKjy9kaBTdmHDcDxqDqqChC+e ZmSRWyNF5gcwOeSclpjMxS3ACa9jInMXPoMqRx27IpG+jxzWwsAQWM+hnRAsviKJ7Z7L KqzA== X-Gm-Message-State: AHYfb5i5XFaRiysfj4X6IeitS9QDkaJWIEeTrGI46OdHMeY8J3VIk1Uc xCvxPqnxTVVktlrsXfOffFNY40qrdu6kHAErO/umUMF5ePadyk01QMmtgLF9CinLql6uDJsYqpB Z4ATzF/sRkyyyGg== X-Received: by 10.202.208.79 with SMTP id h76mr2092365oig.65.1501775431536; Thu, 03 Aug 2017 08:50:31 -0700 (PDT) X-Received: by 10.202.208.79 with SMTP id h76mr2092353oig.65.1501775431291; Thu, 03 Aug 2017 08:50:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.152.129 with HTTP; Thu, 3 Aug 2017 08:50:10 -0700 (PDT) From: Aanchal Malhotra Date: Thu, 3 Aug 2017 17:50:10 +0200 Message-ID: To: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a113e40381d6db30555db570c" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 15:52:03 -0000 --001a113e40381d6db30555db570c Content-Type: text/plain; charset="UTF-8" Dear all, May be this has been discussed long ago on the list or elsewhere. Please guide me to proper pointers, if any. Section 11.2.1 in [1] states the following for KSK rollover for *locally secure zones*: "*In rolling over the KSK, the secure zone may not know which resolvers have stored the public key as a trust anchor. If the network administrator has an out-of-band method of contacting resolver administrators that have stored the public key as a trust anchor (such as e-mail), the network administrator should send out appropriate warnings and set up a trusted means of disseminating the new trust anchor. Otherwise, the DNS administrator can do nothing except pre-publish the new KSK with ample time to give resolver administrators enough time to learn the new KSK.*" I have the following questions: a) This might work in case of an active KSK rollover. However in case of KSK compromise, which would require an emergency KSK rollover, what does the network administrator do in the '*Otherwise*' situation from the above quote? b) I am just curious to know if this is even an issue or do network administrators care about it? And if it is, Is there any RFC or relevant doc or mailing list that discusses this problem/solutions, etc.? References: [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf Thanks, Aanchal Malhotra. --001a113e40381d6db30555db570c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

May be this= has been discussed long ago on the list or elsewhere. Please guide me to p= roper pointers, if any.

Section 11.2.1 in [1] states the following for = KSK rollover for locally secure zones:

"In rolling over the KSK, the se= cure zone may not know which resolvers have stored the public key as a trus= t anchor. If the network administrator has an out-of-band method of contact= ing resolver administrators that have stored the public key as a trust anch= or (such as e-mail), the network administrator should send out appropriate = warnings and set up a trusted means of disseminating the new trust anchor. = Otherwise, the DNS administrator can do nothing except pre-publish the n= ew KSK with ample time to give resolver administrators enough time to learn= the new KSK."

I have the following questi= ons:

a) This might work in case of an active KSK rollover. However i= n case of KSK compromise, which would require an emergency KSK rollover, wh= at does the network administrator do in the 'Otherwise' situ= ation from the above quote?

b) I am just curious to know if this is= even an issue or do network administrators care about it? And if it is, Is= there any RFC or relevant doc or mailing list that discusses this problem/= solutions, etc.?

References:
[1] http= ://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf
Thanks,
Aanchal Malhotra.
--001a113e40381d6db30555db570c-- From nobody Thu Aug 3 09:18:29 2017 Return-Path: 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 64D781320BB for ; Thu, 3 Aug 2017 09:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 LTDq77BFYBFS for ; Thu, 3 Aug 2017 09:18:25 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3311320AC for ; Thu, 3 Aug 2017 09:18:25 -0700 (PDT) Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 3 Aug 2017 12:18:15 -0400 Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.361.1; Thu, 3 Aug 2017 12:18:22 -0400 Received: from [129.6.140.7] (7-140.antd.nist.gov [129.6.140.7]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id v73GHw0I017110; Thu, 3 Aug 2017 12:17:58 -0400 From: "Rose, Scott" To: Aanchal Malhotra CC: Date: Thu, 3 Aug 2017 12:17:58 -0400 Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B8FFCD02-A361-4B6B-B39C-DCA3239A5172_=" Content-Transfer-Encoding: 8bit Embedded-HTML: [{"HTML":[1209, 2102], "plain":[888, 1505], "uuid":"1A686D2C-D7D0-4A56-BD46-B04344F5C7AA"}] X-Mailer: MailMate (1.9.6r5347) X-NIST-MailScanner-Information: Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 16:18:28 -0000 --=_MailMate_B8FFCD02-A361-4B6B-B39C-DCA3239A5172_= Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Hi, (800-81 author here) That needs to be updated as it was from the earlier revision of 800-81. It really should stress the use of RFC 5011 automated trust anchor update process. The first version of the doc assumed RFC 5011 was not available in the majority of implementations, which is not the case now. I’d probably update that to recommend (and stress) to always use the RFC 5011 rollover process. As for emergency rollovers, some admins do worry about it and plan for it by having a pre-published KSK in the DNSKEY RRset at all times (not just during an actual rollover process). RFC 5011 can be used there too (see the “Scenarios” section in RFC 5011). There isn’t a single doc that focuses on KSK rollovers, but it is discussed in the BCP docs like RFC 6781 and other implementation-specific documents. Scott On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote: > Dear all, > > May be this has been discussed long ago on the list or elsewhere. > Please > guide me to proper pointers, if any. > > Section 11.2.1 in [1] > > states the following for KSK rollover for *locally secure zones*: > > "*In rolling over the KSK, the secure zone may not know which > resolvers > have stored the public key as a trust anchor. If the network > administrator > has an out-of-band method of contacting resolver administrators that > have > stored the public key as a trust anchor (such as e-mail), the network > administrator should send out appropriate warnings and set up a > trusted > means of disseminating the new trust anchor. Otherwise, the DNS > administrator can do nothing except pre-publish the new KSK with ample > time > to give resolver administrators enough time to learn the new KSK.*" > > I have the following questions: > > a) This might work in case of an active KSK rollover. However in case > of > KSK compromise, which would require an emergency KSK rollover, what > does > the network administrator do in the '*Otherwise*' situation from the > above > quote? > > b) I am just curious to know if this is even an issue or do network > administrators care about it? And if it is, Is there any RFC or > relevant > doc or mailing list that discusses this problem/solutions, etc.? > > References: > [1] > http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf > > Thanks, > Aanchal Malhotra. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop =================================== Scott Rose NIST ITL scott.rose@nist.gov +1-301-975-8439 GV: +1-571-249-3671 =================================== --=_MailMate_B8FFCD02-A361-4B6B-B39C-DCA3239A5172_= Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

(800-81 author here)

That needs to be updated as it was from the earlier revis= ion of 800-81. It really should stress the use of RFC 5011 automated tru= st anchor update process. The first version of the doc assumed RFC 5011 = was not available in the majority of implementations, which is not the ca= se now. I=E2=80=99d probably update that to recommend (and stress) to al= ways use the RFC 5011 rollover process.

As for emergency rollovers, some admins do worry about it= and plan for it by having a pre-published KSK in the DNSKEY RRset at all= times (not just during an actual rollover process). RFC 5011 can be use= d there too (see the =E2=80=9CScenarios=E2=80=9D section in RFC 5011). Th= ere isn=E2=80=99t a single doc that focuses on KSK rollovers, but it is d= iscussed in the BCP docs like RFC 6781 and other implementation-specific = documents.

Scott


On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote:

De= ar all,

<= /div>
May be this has b= een discussed long ago on the list or elsewhere. Please guide me to prope= r pointers, if any.

Section 11.2.1 in [1] states the following fo= r KSK rollover for locally secure zones:

"In rolling over the KSK, = the secure zone may not know which resolvers have stored the public key a= s a trust anchor. If the network administrator has an out-of-band method = of contacting resolver administrators that have stored the public key as = a trust anchor (such as e-mail), the network administrator should send ou= t appropriate warnings and set up a trusted means of disseminating the ne= w trust anchor. Otherwise, the DNS administrator can do nothing except= pre-publish the new KSK with ample time to give resolver administrators = enough time to learn the new KSK."

I hav= e the following questions:

a) This might work in case of an active= KSK rollover. However in case of KSK compromise, which would require an = emergency KSK rollover, what does the network administrator do in the 'Otherwise' situation from the above quote?

b) I am just curi= ous to know if this is even an issue or do network administrators care ab= out it? And if it is, Is there any RFC or relevant doc or mailing list th= at discusses this problem/solutions, etc.?

Refere= nces:
[1] http://nvlpubs.nist.gov/nistpubs/SpecialPublica= tions/NIST.SP.800-81-2.pdf

Thanks,
Aanchal Malh= otra.

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


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST ITL
scott.rose@nist.gov
+1-301-975-8439
GV: +1-571-249-3671
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--=_MailMate_B8FFCD02-A361-4B6B-B39C-DCA3239A5172_=-- From nobody Thu Aug 3 11:29:40 2017 Return-Path: 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 573AE131822 for ; Thu, 3 Aug 2017 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 axbW16Zldmuf for ; Thu, 3 Aug 2017 11:29:34 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20954127B73 for ; Thu, 3 Aug 2017 11:29:34 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z18so12480989qka.4 for ; Thu, 03 Aug 2017 11:29:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GIv6N9/IdCMnqfg8ka3OVm6lt/JiXpyyQWjJK/rP9cc=; b=HFAoef6VbddL6+p+Zjpb+RVcH6wqwMFr1zZRbzs8oJdvDknR1LKg+/+aCTWYu5DASK w46tvntWdSlqutJDi+8ue+GiUdtRZ05MJBTBTDnCV3LNUIRXnBiBo/Y41kq+IYmeEIDH n3twcgnLqm6fhMgN8FBdGAgtb/FLzNkrGzrW/LnLSchdUq6jnDoagl/bNqS1bTfQIJwn xBIUdy3/f2K6AVtPWohwKK6Q1iTrXWAfrQIT/gTt9aRsoy/VES3mZjQA0pVL1ERHZZR5 JHQpOk0QXuEVjvPbLsFrYOaNNL3UFBjsGJDEo5EYU+PWN+7jcIlMcpxMrIQpDeLNJXJw LnIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=GIv6N9/IdCMnqfg8ka3OVm6lt/JiXpyyQWjJK/rP9cc=; b=jg2LC3ADzopCmQQJQynJ6fMEv8Z/xbuXfR1mW2tiAxQHhNHQsS58mR4sI1P/5yc4EJ dl6p2jc9p8NQnWg7ZCjguz1b50T+4onD6pWxralywM1uscMBjpevKtjbJHMT7MxVxJLn vdkINmZ4liCqjO/cWd8dvysFVRgybeq+LnIwugB9k4n2pijF2kk/SUGkpFJAmdD6EMQK gNf966Nv2K/p3VVFpo3Mxn0hcjTvSjBmLLd0DTjO82dSpMjqjocVhjCk8hDqc07ZK5Z+ QQgd816HduedZS/7OgnXM5ilbjzbvQVjsNTi5rCzyZ6egP2Mx5u6ZdlhFqWOSgIWOAu8 NJPQ== X-Gm-Message-State: AHYfb5jRbEkTtIUcjxTpmrYKpy8n6XIDf4/1+HFofkWWVC8LGPbsHj+q 8RfDy2qtYC+qfPb4vBUUunoXhEfW/BkBJjQ= X-Received: by 10.55.144.130 with SMTP id s124mr3812592qkd.136.1501784973161; Thu, 03 Aug 2017 11:29:33 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Thu, 3 Aug 2017 11:29:32 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Thu, 3 Aug 2017 11:29:32 -0700 X-Google-Sender-Auth: _Cc7hY0BXeqvZWlTtp6-GVe9Qxg Message-ID: To: Tony Finch Cc: tjw ietf , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 18:29:38 -0000 At Sat, 29 Jul 2017 14:27:57 +0100, Tony Finch wrote: > > - One possible idea of another extended error code: one that indicates > > a type-ANY query is responded with just one type of RRset when there > > can be more. > > Note that it is almost always the case that ANY answers from > non-authoritative servers are a subset of the records :-) > > And it seems difficult for a cache to determine when to use this extended > error code. If the cache was populated by an A query (say) it can't know > if this is a subset of the owner's records or not; if it populated the > cache from an ANY query then the records can expire at different times, so > it would have to keep track of this to know if the extended error becomes > relevant. Good point, I was not thinking about the full path from auth via recursive to stub when I made this comment. As you said it's not straightforward. This could still be possible, e.g., if the authoritative server deliberately returns a single RRset to an ANY query with the extended (error) code and the recursive server caches it with marking the sense of the extended code. But it will introduce additional special case to the recursive server implementation, and the benefit may not be worth the complexity. -- JINMEI, Tatuya From nobody Thu Aug 3 11:55:26 2017 Return-Path: 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 F1415124B18 for ; Thu, 3 Aug 2017 11:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 cMfiXUt3eZQv for ; Thu, 3 Aug 2017 11:55:23 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7491200F3 for ; Thu, 3 Aug 2017 11:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2135; q=dns/txt; s=VRSN; t=1501786523; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=3VB8Jmt7RMVCV+mlYtOVyLmcd1nxhdtHKOq0CG0gxKg=; b=TZ3FTtbMJJTxQGQdCE9JMCwSI/rf9h/koBVe21XGjIVNRfsyUwwgNkMt PHaKQy/W+yqtgn4YnRVz6LBELk0SE7XlHD0kLTwyYVqcdijJXw1qPZjP2 cqDlJ8WXdNVt4afBfRy2QvhpXtbEQIHRlk47BsZlILiVj6J7SgVQ3hrey AlKYOyQYYPi2XaJ25bBDcKHhR0CQorw5EqDsBpx3jnJF+9TecbrNtotiR YqUcme1PxacFTTc9+gQQN9wsp4mP5a7hkR4AwyuxbINA5cRCNhluUBafs PrMopfjebUocd0XwrP8fWbPC9WG2kcnd+KKoRYx3zwMYXyd+uSKqTAV2p g==; X-IronPort-AV: E=Sophos;i="5.41,317,1498521600"; d="scan'208";a="2076805" IronPort-PHdr: =?us-ascii?q?9a23=3AQzn62xZEu/YAm9Yoy7ndMev/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZrsiybnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7Sc8kaRW5cVchPUSJPDJ63?= =?us-ascii?q?Y48WA+cAOOpVqZT2qVkTohukHQSiBP3hxCJUhnH43qM63eYuEQDa0wIvEN0Dq2?= =?us-ascii?q?jUrMzwNKsOTey50LfEwDPeZP1Wwzf9743Ifwgvrf6MQ71watHRxlcrFwPellmb?= =?us-ascii?q?tILrPy6P2eQLrWeX4fdrWOWyhG8ptQ5xuSOvydkoionSnY8V1E7L9T94wIYuJN?= =?us-ascii?q?24R0h7bcS4H5tXsiGXLo17Sd4sTWFvvSY10LwGuZijcSgMyZQn3ALfZ+aIc4iP?= =?us-ascii?q?/BLvTOeRLilkhHJrYr6/gAyy8Uemx+bhVce0yE5HojdZntXWq3wA1RLe5tKaRv?= =?us-ascii?q?Z98EqtwyiD2g/c5+1cPEw4ibDXJ4Mjz7IsjJYfrEvOEyzslEnrj6KbcFgv9PKy?= =?us-ascii?q?5OT9eLrmo4eRN4pzig7jLKsjgte/AeEkMggWWGib5Pi82KXj/ULnRLVKieU7nb?= =?us-ascii?q?LDsJDcOMgboqG4AwpP3YYi7xa/CCqm0MgEkXUaNl5FZgyIj5LoO1HVIfD4AvG/?= =?us-ascii?q?j06wnzdswvDKJrzhApPTIXjfiLrtYKpx51RBxAcxw91T/Y9YB7EPLf7pREP8u9?= =?us-ascii?q?PVAgc8MwOuwubnDNt91pkZWWKKGqKWLa3TvkGT5uI0PeaMYJQVtS3jK/c7/f7u?= =?us-ascii?q?jGQ5mV4Sfamvx5cYdHe4HvF+L0WDfXXsmssBEXsNvgcmUePqjkaCUTlLZ3upXq?= =?us-ascii?q?Iz+C07CIy8AYfEXICtj6SL3D2nEZ1OemBGFleMHG/yeIqeXfcDdCKSLdVlkjEL?= =?us-ascii?q?TrWuUJIh2QuwuwDn1ro0ZtbTrwQRs5nj3dw9wuTXlRYu7zU8W82U1WqNRmUotm?= =?us-ascii?q?kVATI6wfYsj1Z6zwLJ7qVjmPFcDpgby+5AVApwfcrQ0OFhEN32QSrfc82IU1ep?= =?us-ascii?q?RJOtBjRnHYF5+MMHf0soQ4bqtRvExSf/RuZNybE=3D?= X-IPAS-Result: =?us-ascii?q?A2FvAADlcINZ//SZrQpcDg0BAQEDAQEBCQEBARYBAQEDAQE?= =?us-ascii?q?BCQEBAYQTgRQHjgiRdpYVDoFBOgkhDYUZAoR9GAEBAQEBAQEBAQEBAoEQgjMkA?= =?us-ascii?q?Q1GJgYBAQEBAQEmAQEBAQEBAQEBAQEBAQEBGgIeIBIBARgBAQEBAQEBAQE4NAs?= =?us-ascii?q?FCwIBCA0LHhAnCyUCBA4FG4oMGK9ki0EBAQEBAQEBAwEBAQEBAQEBAQEBHYMog?= =?us-ascii?q?0+BYiuCfIQ9NoNDgjEFn3cGAodRjmlZhH+KYZYBH4FDdxVJEgGEf4FJP3YBAYc?= =?us-ascii?q?GK4EFgQ8BAQE?= Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02 [10.173.152.206]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v73ItL9i004625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 14:55:21 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 3 Aug 2017 14:55:21 -0400 From: "Wessels, Duane" To: Aanchal Malhotra CC: "dnsop@ietf.org" Thread-Topic: [EXTERNAL] [DNSOP] Emergency KSK Rollover for locally secure zones. Thread-Index: AQHTDIoOxZbUM6GsDU+V9YFHHp6NJg== Date: Thu, 3 Aug 2017 18:55:20 +0000 Message-ID: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 18:55:25 -0000 Hello Aanchal, I don't know if you consider this a solution, but you may want to take a lo= ok at RFC 8145, aka "Signaling Trust Anchor Knowledge." Per this RFC, validators can convey trust anchor contents to zone operators= via periodic queries. By looking at the signal data you can see how many = (and which) validators have old versus new keys. It is implemented in recent versions of BIND and Unbound. DW > On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra wrote: >=20 > Dear all, >=20 > May be this has been discussed long ago on the list or elsewhere. Please = guide me to proper pointers, if any. >=20 > Section 11.2.1 in [1] states the following for KSK rollover for locally s= ecure zones: >=20 > "In rolling over the KSK, the secure zone may not know which resolvers ha= ve stored the public key as a trust anchor. If the network administrator ha= s an out-of-band method of contacting resolver administrators that have sto= red the public key as a trust anchor (such as e-mail), the network administ= rator should send out appropriate warnings and set up a trusted means of di= sseminating the new trust anchor. Otherwise, the DNS administrator can do n= othing except pre-publish the new KSK with ample time to give resolver admi= nistrators enough time to learn the new KSK." >=20 > I have the following questions: >=20 > a) This might work in case of an active KSK rollover. However in case of = KSK compromise, which would require an emergency KSK rollover, what does th= e network administrator do in the 'Otherwise' situation from the above quot= e?=20 >=20 > b) I am just curious to know if this is even an issue or do network admin= istrators care about it? And if it is, Is there any RFC or relevant doc or = mailing list that discusses this problem/solutions, etc.? >=20 > References: > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2= .pdf >=20 > Thanks, > Aanchal Malhotra. > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Aug 3 12:02:50 2017 Return-Path: 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 32325127B73 for ; Thu, 3 Aug 2017 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 sBJN1xI3R1z1 for ; Thu, 3 Aug 2017 12:02:47 -0700 (PDT) Received: from relay55.bu.edu (relay55.bu.edu [128.197.228.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3671270AC for ; Thu, 3 Aug 2017 12:02:46 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f72.google.com (mail-oi0-f72.google.com [209.85.218.72]) by relay55.bu.edu (8.14.3/8.14.3) with ESMTP id v73J2EA2032556 for ; Thu, 3 Aug 2017 15:02:14 -0400 Received: by mail-oi0-f72.google.com with SMTP id g131so1611254oic.10 for ; Thu, 03 Aug 2017 12:02:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G62TliZLE8GswJ8Yp81lOqxImj2DkuyIbzImDfLCTaA=; b=sVHYapV9txlM9oK5nCGG+2U1mc28V8rogsLamIZh5Fy0vJ1u4U3LdYU5YLiCB89ur5 hBbYF4pU7KQ6p0LoZPb+RKC64VFMHGzg+JlSUsFNy8S7JSbyRRcWT7IeMoqvPqvms0Rp /nhqHvLfb5MGgWfo+JG+E2HXWVfadLxLp9ZVjiNCMbzLQDzmIHzM7JDAnCg6FRzdBWh+ qUMV143IdyZ/MOYQDiA3RXbQwJDB/mujRbwKqqyRGqjYcsWrz5fb1g68o4ZlszghERY0 vkrm5iMsYt6aOeoFl/nZWoJrtSiDjZY0lcyfA5dtJtECe0RjLB1dHi/UqBLiQB74SM5Z fldA== X-Gm-Message-State: AHYfb5g4b9fZ2FlU72NZqn3k3+XE+Fcokm83NVWbJ1f9ld0KPQoXK0y/ qguWtShc2FgDmGyyEWMks815p9YsVatboBd+pzaaQUk5jqvM3HQwyzEHlHOu375UUFXUwXAVPuM grFSPjbWDS4YwoA== X-Received: by 10.202.208.79 with SMTP id h76mr2621137oig.65.1501786934055; Thu, 03 Aug 2017 12:02:14 -0700 (PDT) X-Received: by 10.202.208.79 with SMTP id h76mr2621122oig.65.1501786933688; Thu, 03 Aug 2017 12:02:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 12:01:52 -0700 (PDT) In-Reply-To: References: From: Aanchal Malhotra Date: Thu, 3 Aug 2017 21:01:52 +0200 Message-ID: To: "Rose, Scott" Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a113e4038b6133a0555de04ac" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 19:02:49 -0000 --001a113e4038b6133a0555de04ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Scott, Thanks for the response. I have another question in that case. Please see below. On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott wrote: > Hi, > > (800-81 author here) > > That needs to be updated as it was from the earlier revision of 800-81. I= t > really should stress the use of RFC 5011 automated trust anchor update > process. The first version of the doc assumed RFC 5011 was not available = in > the majority of implementations, which is not the case now. I=E2=80=99d p= robably > update that to recommend (and stress) to always use the RFC 5011 rollover > process. > > As for emergency rollovers, some admins do worry about it and plan for it > by having a pre-published KSK in the DNSKEY RRset at all times (not just > during an actual rollover process). RFC 5011 can be used there too (see t= he > =E2=80=9CScenarios=E2=80=9D section in RFC 5011). > A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new T*rust Anchor *for the resolver? > There isn=E2=80=99t a single doc that focuses on KSK rollovers, but it is > discussed in the BCP docs like RFC 6781 and other implementation-specific > documents. > > Scott > > On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote: > > Dear all, > > May be this has been discussed long ago on the list or elsewhere. Please > guide me to proper pointers, if any. > > Section 11.2.1 in [1] > > states the following for KSK rollover for *locally secure zones*: > > "*In rolling over the KSK, the secure zone may not know which resolvers > have stored the public key as a trust anchor. If the network administrato= r > has an out-of-band method of contacting resolver administrators that have > stored the public key as a trust anchor (such as e-mail), the network > administrator should send out appropriate warnings and set up a trusted > means of disseminating the new trust anchor. Otherwise, the DNS > administrator can do nothing except pre-publish the new KSK with ample ti= me > to give resolver administrators enough time to learn the new KSK.*" > > I have the following questions: > > a) This might work in case of an active KSK rollover. However in case of > KSK compromise, which would require an emergency KSK rollover, what does > the network administrator do in the '*Otherwise*' situation from the > above quote? > > b) I am just curious to know if this is even an issue or do network > administrators care about it? And if it is, Is there any RFC or relevant > doc or mailing list that discusses this problem/solutions, etc.? > > References: > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ > NIST.SP.800-81-2.pdf > > Thanks, > Aanchal Malhotra. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Scott Rose > NIST ITL > scott.rose@nist.gov > +1-301-975-8439 <%28301%29%20975-8439> > GV: +1-571-249-3671 <%28571%29%20249-3671> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --001a113e4038b6133a0555de04ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Scott,

Thanks for the response. I hav= e another question in that case. Please see below.


On Thu, Aug 3, 2017 at 6:17= PM, Rose, Scott <scott.rose@nist.gov> wrote:

Hi,

(800-81 author here)

That needs to be updated as it was from the earlier revisio= n of 800-81. It really should stress the use of RFC 5011 automated trust a= nchor update process. The first version of the doc assumed RFC 5011 was no= t available in the majority of implementations, which is not the case now. = I=E2=80=99d probably update that to recommend (and stress) to always use t= he RFC 5011 rollover process.

As for emergency rollovers, some admins do worry about it a= nd plan for it by having a pre-published KSK in the DNSKEY RRset at all tim= es (not just during an actual rollover process). RFC 5011 can be used ther= e too (see the =E2=80=9CScenarios=E2=80=9D section in RFC 5011).

=
A DNSKEY RRset with pre-published KSK is sign= ed by the old (now compromised) KSK. When the resolver uses RFC 5011 for th= e trust anchor update, the attacker can inject a new KSK (signed by the com= promised KSK). Which KSK is now the new Trust Anchor=C2=A0 for the r= esolver?
=C2=A0

Ther= e isn=E2=80=99t a single doc that focuses on KSK rollovers, but it is discu= ssed in the BCP docs like RFC 6781 and other implementation-specific docume= nts.

Scott


On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote:

Dear all,

May be this has been discussed long ago on the list or elsewhere. Please = guide me to proper pointers, if any.

Section 11.2.1 in [1= ] states the following for KSK rollover for locally secure zones= :

"= In rolling over the KSK, the secure zone may not know which resolvers have = stored the public key as a trust anchor. If the network administrator has a= n out-of-band method of contacting resolver administrators that have stored= the public key as a trust anchor (such as e-mail), the network administrat= or should send out appropriate warnings and set up a trusted means of disse= minating the new trust anchor. Otherwise, the DNS administrator can do n= othing except pre-publish the new KSK with ample time to give resolver admi= nistrators enough time to learn the new KSK."

<= div>I have the following questions:

a) This might work in case of an= active KSK rollover. However in case of KSK compromise, which would requir= e an emergency KSK rollover, what does the network administrator do in the = 'Otherwise' situation from the above quote?

b) I am = just curious to know if this is even an issue or do network administrators = care about it? And if it is, Is there any RFC or relevant doc or mailing li= st that discusses this problem/solutions, etc.?

Ref= erences:
[1] http://nvlpubs.nist.gov/n= istpubs/SpecialPublications/NIST.SP.800-81-2.pdf

Than= ks,
Aanchal Malhotra.

_________________________________________= ______
DNSOP mailing list
DNSOP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnsop


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Scott Rose
NIST ITL
scott.rose@nist.go= v
+1-301-975-8439
GV: +1-571-249-3671
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


--001a113e4038b6133a0555de04ac-- From nobody Thu Aug 3 12:51:58 2017 Return-Path: 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 50792129B26 for ; Thu, 3 Aug 2017 12:51:56 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 Ftxk0ky6lr9b for ; Thu, 3 Aug 2017 12:51:54 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9F9129A84 for ; Thu, 3 Aug 2017 12:51:54 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id w45so10734049uac.5 for ; Thu, 03 Aug 2017 12:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=un7qiHMHmdqccEGqb9iUfq2eI4/HubN7PxKLZFuEOs8=; b=E+U0o11BoG9C6FIKBeLUGTnyqlm+49FzwsyScLVtAKnya+OwiHQluxGU/BQo/W78Lf 7DIYy0/D7kbd9IBLF+ojd8TpdgPOHx82BIuGU8YGXibHId4A03OmPFShV2U80bde6aLV thLLY8kgbzGdkD9eQioMj4sz8vShrcNRry45YRB/74TpBWrpW0ro95SeQeUPje11p+m8 PGMSr32GXkrcbuehYDjuNiEnoJO75TqjyUzLBg04hJ/Kg6yCrNeRrvxIr8ofRdU6iCiD dZQGb4qo2v4nsPgpP4Xo7YQfPlcIngwID8zNolLkjUFFgfRYH/41BwEjp6pglpevnCMJ K0DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=un7qiHMHmdqccEGqb9iUfq2eI4/HubN7PxKLZFuEOs8=; b=Py9DsRJfI2yYso6rLOWMtN+eE7kmDMIXy2d3N17VYvL9gXW/3kKGyQb1pYIeGNyO6W OONtXgoi3wzFfeDeh5tuqWHf/9pt40It/Db8xiY81RToOD6pA47yCBi5sFgjeq1Cdm9q D2UlHKNbfXcErLvX1a7MVcrzqsBqBh0N9OfCzQghlw0F7x5yNFtbySmtbtF1rMlJbuX5 iLdy1JNHYKlkhItpOBEDMDY5yB/hCBuR7HbVagUNUViiERgMMTcI4B3dFo+6ugwRRSN7 zfhwgOB40SXWymR8F96XN+DRdks0So//bXwZmAWGUMuVaLuFACt4NDBF9aw0yeMvPCiX TRww== X-Gm-Message-State: AIVw110QknBtdUyjgen5K1iDk7lfVheY+yO7lNHBZYJB87FDWnvmENqn hg5WYu1tMBE8kTN1rPa6W2UwaSduKn+D X-Received: by 10.176.9.75 with SMTP id c11mr1959347uah.145.1501789912958; Thu, 03 Aug 2017 12:51:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.9.231 with HTTP; Thu, 3 Aug 2017 12:51:12 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Thu, 3 Aug 2017 15:51:12 -0400 Message-ID: To: Aanchal Malhotra Cc: "Rose, Scott" , dnsop Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 19:51:56 -0000 On Thu, Aug 3, 2017 at 3:01 PM, Aanchal Malhotra wrote: > Hi Scott, > > Thanks for the response. I have another question in that case. Please see > below. > > > On Thu, Aug 3, 2017 at 6:17 PM, Rose, Scott wrote: >> >> Hi, >> >> (800-81 author here) >> >> That needs to be updated as it was from the earlier revision of 800-81. = It >> really should stress the use of RFC 5011 automated trust anchor update >> process. The first version of the doc assumed RFC 5011 was not available= in >> the majority of implementations, which is not the case now. I=E2=80=99d = probably >> update that to recommend (and stress) to always use the RFC 5011 rollove= r >> process. >> >> As for emergency rollovers, some admins do worry about it and plan for i= t >> by having a pre-published KSK in the DNSKEY RRset at all times (not just >> during an actual rollover process). RFC 5011 can be used there too (see = the >> =E2=80=9CScenarios=E2=80=9D section in RFC 5011). > > A DNSKEY RRset with pre-published KSK is signed by the old (now compromis= ed) > KSK. When the resolver uses RFC 5011 for the trust anchor update, the > attacker can inject a new KSK (signed by the compromised KSK). Which KSK = is > now the new Trust Anchor for the resolver? Yeah, 5011 as currently used does very little for emergency rollovers. An attacker who has compromised a key can indeed continue to keep their foothold (or possibly increase it) through the 5011 roll. RFC5011 is only intended for scheduled rollovers, and the old key needs to be revoked "shortly" after the new one is introduced. The timing of all this is, er, subtle - see https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-consider= ations/ for some of it... The plan at one point was to have 2 trust anchors, a primary one (being used for signing) and a backup one, which would be published, but not used for signing. If the primary is suspected to be compromised, the backup one can start to be used, and the primary revoked. This would buy some time to figure out what happens next :-P There has been much discussion over the years if this makes things safer or not -- having 2 times as many keys means that a (brute-force) attacker it more likely to be able to factor a key, it is unclear under what scenarios the primary would be compromised while still maintaining trust is the backup, etc.... W > >> >> There isn=E2=80=99t a single doc that focuses on KSK rollovers, but it i= s >> discussed in the BCP docs like RFC 6781 and other implementation-specifi= c >> documents. >> >> Scott >> >> >> On 3 Aug 2017, at 11:50, Aanchal Malhotra wrote: >> >> Dear all, >> >> May be this has been discussed long ago on the list or elsewhere. Please >> guide me to proper pointers, if any. >> >> Section 11.2.1 in [1] states the following for KSK rollover for locally >> secure zones: >> >> "In rolling over the KSK, the secure zone may not know which resolvers >> have stored the public key as a trust anchor. If the network administrat= or >> has an out-of-band method of contacting resolver administrators that hav= e >> stored the public key as a trust anchor (such as e-mail), the network >> administrator should send out appropriate warnings and set up a trusted >> means of disseminating the new trust anchor. Otherwise, the DNS >> administrator can do nothing except pre-publish the new KSK with ample t= ime >> to give resolver administrators enough time to learn the new KSK." >> >> I have the following questions: >> >> a) This might work in case of an active KSK rollover. However in case of >> KSK compromise, which would require an emergency KSK rollover, what does= the >> network administrator do in the 'Otherwise' situation from the above quo= te? >> >> b) I am just curious to know if this is even an issue or do network >> administrators care about it? And if it is, Is there any RFC or relevant= doc >> or mailing list that discusses this problem/solutions, etc.? >> >> References: >> [1] >> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pd= f >> >> Thanks, >> Aanchal Malhotra. >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Scott Rose >> NIST ITL >> scott.rose@nist.gov >> +1-301-975-8439 >> GV: +1-571-249-3671 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 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 nobody Thu Aug 3 12:59:01 2017 Return-Path: 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 6F53C131891 for ; Thu, 3 Aug 2017 12:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 DDiwAxOP_kKk for ; Thu, 3 Aug 2017 12:58:58 -0700 (PDT) Received: from relay77.bu.edu (relay77.bu.edu [128.197.228.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C554131C2D for ; Thu, 3 Aug 2017 12:58:56 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by relay77.bu.edu (8.14.3/8.14.3) with ESMTP id v73JwPQR024307 for ; Thu, 3 Aug 2017 15:58:26 -0400 Received: by mail-oi0-f71.google.com with SMTP id x3so1708835oia.8 for ; Thu, 03 Aug 2017 12:58:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p3XlyuTPKJy39M3HsaJzCfmE5z8fKtO4skWPSL21U2M=; b=miBQUTsmS1a/f4aSvgn2MPxdoVnuxAAQFKSbtFGo+svzOf9SoGXtGjTkY/QE02diWC zenFoYh2me+9bNVXF58Es1r87ZLyJiCidwoEY/gPsAJEfq+A6d7aYi/8X/qEsrYCjDkM LWgtfiUnNqz33wVcmBRr3COKU9/e2Bb5f4zsFmMulFZ6e/MJX6W+gZJdeBEAP2sFeFOa 9KHyI+VVCnthxKHontYnAyO+GbXJO6V7lPTnPLs/ZTFlS3XCjACkgofKmUg8jr9Dv9rz kvOW52wAPzGyI3zLqz6SMjmjPzqXN+8T6drKlJabyh3dvWSJEztIwn5GgBqs7k7gEyAE FE+g== X-Gm-Message-State: AHYfb5j4CmDAguFhqCvoKnJ3usxfuIxLU3yoLu7RWO8StD5R6ovf5aw6 X8Ool5+rjFLV7RVrJEixLPM3wj9Rq0GzBHd5g8Iddc+2g3eQVqLwnzMy5d1O7oVwvF3kwxo28rW 3QtIcGUY9h41qqw== X-Received: by 10.202.166.196 with SMTP id t65mr2994293oij.63.1501790305372; Thu, 03 Aug 2017 12:58:25 -0700 (PDT) X-Received: by 10.202.166.196 with SMTP id t65mr2994278oij.63.1501790305095; Thu, 03 Aug 2017 12:58:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 12:58:04 -0700 (PDT) In-Reply-To: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com> References: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com> From: Aanchal Malhotra Date: Thu, 3 Aug 2017 21:58:04 +0200 Message-ID: To: "Wessels, Duane" Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a113e7cf2a9aaf30555decd28" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 19:59:00 -0000 --001a113e7cf2a9aaf30555decd28 Content-Type: text/plain; charset="UTF-8" Hi Duane, Thanks for pointing to RFC 8145. It's a very nice mechanism to allow zone administrators to know the status of key rollover in the DNSSEC signed zone to take further decisions. However, I still don't see how it would help in case of trust anchor/KSK compromise. With RFC 8145, the zone administrator would know that the resolvers are using old (now compromised) trust anchor/KSK for validating the data. But there is no way for them to roll-over this trust anchor/KSK in an authentic way. In other words, this RFC might help in detecting the problem (when a resolver signals a key that is not the zone's trust anchor). But I don't see anything in the RFC that says what a zone administrator can do in such a case. Am I missing something? Thx, Aanchal Malhotra. On Thu, Aug 3, 2017 at 8:55 PM, Wessels, Duane wrote: > Hello Aanchal, > > I don't know if you consider this a solution, but you may want to take a > look at RFC 8145, aka "Signaling Trust Anchor Knowledge." > > Per this RFC, validators can convey trust anchor contents to zone > operators via periodic queries. By looking at the signal data you can see > how many (and which) validators have old versus new keys. > > It is implemented in recent versions of BIND and Unbound. > > DW > > > > > On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra wrote: > > > > Dear all, > > > > May be this has been discussed long ago on the list or elsewhere. Please > guide me to proper pointers, if any. > > > > Section 11.2.1 in [1] states the following for KSK rollover for locally > secure zones: > > > > "In rolling over the KSK, the secure zone may not know which resolvers > have stored the public key as a trust anchor. If the network administrator > has an out-of-band method of contacting resolver administrators that have > stored the public key as a trust anchor (such as e-mail), the network > administrator should send out appropriate warnings and set up a trusted > means of disseminating the new trust anchor. Otherwise, the DNS > administrator can do nothing except pre-publish the new KSK with ample time > to give resolver administrators enough time to learn the new KSK." > > > > I have the following questions: > > > > a) This might work in case of an active KSK rollover. However in case of > KSK compromise, which would require an emergency KSK rollover, what does > the network administrator do in the 'Otherwise' situation from the above > quote? > > > > b) I am just curious to know if this is even an issue or do network > administrators care about it? And if it is, Is there any RFC or relevant > doc or mailing list that discusses this problem/solutions, etc.? > > > > References: > > [1] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/ > NIST.SP.800-81-2.pdf > > > > Thanks, > > Aanchal Malhotra. > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > --001a113e7cf2a9aaf30555decd28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Duane,

Thanks for= pointing to RFC 8145. It's a very nice mechanism to allow zone adminis= trators to know the status of key rollover in the DNSSEC signed zone to tak= e further decisions.

However, I still don't see how = it would help in case of trust anchor/KSK compromise. With RFC 8145, the zo= ne administrator would know that the resolvers are using old (now compromis= ed) trust anchor/KSK for validating the data. But there is no way for them = to roll-over this trust anchor/KSK in an authentic way. In other words, thi= s RFC might help in detecting the problem (when a resolver signals a key th= at is not the zone's trust anchor). But I don't see anything in the= RFC that says what a zone administrator can do in such a case. Am I missin= g something?

Thx,
Aanchal Malhotra.

=

On Thu, Aug 3, 2017 at 8:55 PM, Wessels, Duane <dwessels@verisign.com= > wrote:
Hello Aanchal,

I don't know if you consider this a solution, but you may want to take = a look at RFC 8145, aka "Signaling Trust Anchor Knowledge."

Per this RFC, validators can convey trust anchor contents to zone operators= via periodic queries.=C2=A0 By looking at the signal data you can see how = many (and which) validators have old versus new keys.

It is implemented in recent versions of BIND and Unbound.

DW



> On Aug 3, 2017, at 8:50 AM, Aanchal Malhotra <aanchal4@bu.edu> wrote:
>
> Dear all,
>
> May be this has been discussed long ago on the list or elsewhere. Plea= se guide me to proper pointers, if any.
>
> Section 11.2.1 in [1] states the following for KSK rollover for locall= y secure zones:
>
> "In rolling over the KSK, the secure zone may not know which reso= lvers have stored the public key as a trust anchor. If the network administ= rator has an out-of-band method of contacting resolver administrators that = have stored the public key as a trust anchor (such as e-mail), the network = administrator should send out appropriate warnings and set up a trusted mea= ns of disseminating the new trust anchor. Otherwise, the DNS administrator = can do nothing except pre-publish the new KSK with ample time to give resol= ver administrators enough time to learn the new KSK."
>
> I have the following questions:
>
> a) This might work in case of an active KSK rollover. However in case = of KSK compromise, which would require an emergency KSK rollover, what does= the network administrator do in the 'Otherwise' situation from the= above quote?
>
> b) I am just curious to know if this is even an issue or do network ad= ministrators care about it? And if it is, Is there any RFC or relevant doc = or mailing list that discusses this problem/solutions, etc.?
>
> References:
> [1] http://nvlpubs.nis= t.gov/nistpubs/SpecialPublications/NIST.SP.800-81-2.pdf
>
> Thanks,
> Aanchal Malhotra.
> __________________= _____________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop=


--001a113e7cf2a9aaf30555decd28-- From nobody Thu Aug 3 13:06:52 2017 Return-Path: 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 97CEC131D1D for ; Thu, 3 Aug 2017 13:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 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_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 rCoBDLyz86wy for ; Thu, 3 Aug 2017 13:06:49 -0700 (PDT) Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98476131C7F for ; Thu, 3 Aug 2017 13:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=627; q=dns/txt; s=VRSN; t=1501790809; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=fdmEA0CNx0rUkZhNH32rpqxxH/Q2W0BgwZfEFIt4+3I=; b=Qxl+yGJ5HD6RVG83Q40va8XcaLD1ZPowLbMikwHkhDA4+EFBI7NKzi7d WiJJEpnBiLxhaHaljZxbC69C40o5WXtCYuvSdnFC9pNp/bEkBI0XZ+RmI OoCDnbpa0ZiItMGi4//sgLpMxZi/deD+dSfZScPpoawVrI6e622Iutmw4 rxxnyqHP6MI+/ryr05js9IM1YTWx0Meqj+buIWpU5laOWAxIqo/uO4G61 yhxN/pa97KpctsbwOfeRqssd0rwEmNanIPMiRTYuuXPBKwBNM1d3Nj8bN qLonPWXkczcsn0fTvo7X/z04LC58K8k7XosbYglJ+625Npu5EjbdQtaby w==; X-IronPort-AV: E=Sophos;i="5.41,317,1498521600"; d="scan'208";a="4162873" IronPort-PHdr: =?us-ascii?q?9a23=3AtcBUTR17p8t0Sqd0smDT+DRfVm0co7zxezQtwd8Z?= =?us-ascii?q?seIRKvad9pjvdHbS+e9qxAeQG96Ku7Qc06L/iOPJYSQ4+5GPsXQPItRndiQuro?= =?us-ascii?q?EopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBgvwNRZv?= =?us-ascii?q?JuTyB4Xek9m72/q89pDXYAhEniaxba9vJxiqsAvdsdUbj5F/Iagr0BvJpXVIe+?= =?us-ascii?q?VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PGAv5c3krgfM?= =?us-ascii?q?QA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7Vq4/Vyi84Kh3SR/okC?= =?us-ascii?q?YHOCA/8GHLkcx7kaZXrAu8qxBj34LYZYeYP+d8cKzAZ9MXXWpPUNhMWSxdDI2y?= =?us-ascii?q?bIUPAOgAPelEoIfyqEADrQenBQmpGO/j1iNEimHw0KYn0+ohCwbG3Ak4Et4AsH?= =?us-ascii?q?vbss71NLwMXuCx16nE1SjIYf1L2Tjn7ojHbB4tquyLUL1tf8ve11IvFxjbgVWU?= =?us-ascii?q?sozoJC2V2foXs2ia9OpgVO2vi2g9pw5tpTivw94hh4/UjYwW0lDJ7Th1zJovKd?= =?us-ascii?q?GlSkN2b8SoHIZQuiyULYd6XMwvTm5wtCon1rEKo4O3cSoWxJg92hLSZP+Kf5KV?= =?us-ascii?q?7h/gUuuaPC12i2h/eL2lgha/6U2gyurhWcaqyFtKtS9FksXUtnAKyhzT9tCLSv?= =?us-ascii?q?tj8Uel3jaCzxvc6vtCIUwpkaraJJshzaQxlpoXtkTDAzP2lFnrgKOMaEUr5PKo?= =?us-ascii?q?6+X8YrXnqZ+cMZV4hR35MqQrgsC/AOI4PRYSX2WD5OiwyKfv8VD7TbhElPE6j6?= =?us-ascii?q?nUvZ7AKcgFqaO0DBdZ0oM55Ba+Czem3s4YnX4CLF9dZR2GgZbmO0rVIP/mCfe/?= =?us-ascii?q?mE+hkCl1yPDcP73hGZTNLnfFkLv7Ybl97EtcxBIpzd9D/5JUFq0BIPXrV0Dsst?= =?us-ascii?q?zYFRg5MxSvzubmFtp9yo0eVXiIAq+DP6PYqUWI6f43I+mQeI8Vvy7wJOI/6P7o?= =?us-ascii?q?kXA5mUUSfa2m0JYMc3+4A+5qLFuEbnrx0Z89FjIjtww1TOXuwHiLVT5Ue2y7F/?= =?us-ascii?q?Y17zcwCIuiUa/JW8agjKHXjwmhGZgDLF9LEUuBFWysP6mZUvEBImrGLtBsiScJ?= =?us-ascii?q?UaOJVYI71Aqvuwm8wL1ieLmHshYEvI7ugYAmr9bYkgs/oHktV5yQ?= X-IPAS-Result: =?us-ascii?q?A2EFAQDXgYNZ//SZrQpdDg0BAQEDAQEBCQEBARYBAQEDAQE?= =?us-ascii?q?BCQEBAYUnB44IkVQilhUOggSFRwKEfRgBAQEBAQEBAQEBAQKBEIIzJAGCQAEBA?= =?us-ascii?q?QECATo/BQsCAQgNCx4QMiUCBA4FG4oMr3+LRAEBAQEBAQQBAQEBAQEBASCDKIN?= =?us-ascii?q?Pgg0LgnGEQAESAR+DQ4IxBZ93BgKWIhiQOYlejCMfgTgLdxVbAYR/gUk/docVg?= =?us-ascii?q?SOBDwEBAQ?= Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01 [10.173.152.205]) by brn1lxmailout01.verisign.com (8.13.8/8.13.8) with ESMTP id v73K6mUp012762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Aug 2017 16:06:48 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.03.0301.000; Thu, 3 Aug 2017 16:06:47 -0400 From: "Wessels, Duane" To: Aanchal Malhotra CC: "dnsop@ietf.org" Thread-Topic: [EXTERNAL] Re: [DNSOP] Emergency KSK Rollover for locally secure zones. Thread-Index: AQHTDJLnzWOD/u3mWEKUgRN2+IFyGKJzUfiA Date: Thu, 3 Aug 2017 20:06:47 +0000 Message-ID: <16161C24-1E34-4180-8A07-FE6F78DCEB81@verisign.com> References: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B53FC1E772EAC43B8AEB243F13EF4CF@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 20:06:51 -0000 > On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra wrote: >=20 > However, I still don't see how it would help in case of trust anchor/KSK = compromise. This is why I wrote "I don't know if you consider it a solution." Even so, I think it could be useful, depending on the nature and scale of t= he zone in question. For example, if you had to perform an emergency KSK r= ollover you might do something like email a group of administrators with in= structions to manually update their trust anchors. RFC 8145 would help you= know how many administrators followed through on that request. DW From nobody Thu Aug 3 13:12:16 2017 Return-Path: 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 3C13213178D for ; Thu, 3 Aug 2017 13:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 VeTgZ-Gh59VZ for ; Thu, 3 Aug 2017 13:12:14 -0700 (PDT) Received: from relay58.bu.edu (relay58.bu.edu [128.197.228.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07E312EE45 for ; Thu, 3 Aug 2017 13:12:13 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by relay58.bu.edu (8.14.3/8.14.3) with ESMTP id v73KBmD9005244 for ; Thu, 3 Aug 2017 16:11:48 -0400 Received: by mail-oi0-f70.google.com with SMTP id h4so1751833oic.0 for ; Thu, 03 Aug 2017 13:11:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ABBuI5Xd4SKkY1gEc11gmuJjWsWvO5Cy3V7NuU24wHY=; b=YoY+MuC/rIj3CbrS9OOZ+36Cf4FdAZcqnxc18XCCfbEIk/Jr8cwuIiAm1zLE3g7m33 8a8dzXM6cQlo+jjLozd4PF3lES7ky2HjuTirhiCbyRCdfAyeiqaD9dgQ5bvAVuRAhy4H yJ3+dSPWwTrrX+3bXqwP1U6WNEpvHoZGxqVOwwJtjqPlnYKHqsNfo/nyQLCqq6ci6+jN v1Z7fOnsClxdpVkC+U2CSpHKI7msyAxnoAHTulHw+SoLpmUz8Uo9ZvDbfs0LIM8nY5Wx c6MeEMSRb25O138NgbZwBtSpfovq4DRDg+OXvR6QLnSfRL4Ny8gIHMEwTajKxox00915 GEiQ== X-Gm-Message-State: AIVw11318Zw9zYiy3M2RI6ZBY6cciWqVdnNLjFSl0FQD1P/szEyU98lu dGAKsRFDvVGNZ1MShvil9rBHJ6YrJmG4NQdP8OWsTN0AWODo5xnwtIm6RAkepXtb9eUTN4m39ms Rvo9ol1RqMXiFVQ== X-Received: by 10.202.44.19 with SMTP id s19mr2386479ois.243.1501791108274; Thu, 03 Aug 2017 13:11:48 -0700 (PDT) X-Received: by 10.202.44.19 with SMTP id s19mr2386467ois.243.1501791108069; Thu, 03 Aug 2017 13:11:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 13:11:27 -0700 (PDT) In-Reply-To: <16161C24-1E34-4180-8A07-FE6F78DCEB81@verisign.com> References: <2EDD433D-BD40-4A54-BE52-57BC512C5988@verisign.com> <16161C24-1E34-4180-8A07-FE6F78DCEB81@verisign.com> From: Aanchal Malhotra Date: Thu, 3 Aug 2017 22:11:27 +0200 Message-ID: To: "Wessels, Duane" Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a1137baae860e1a0555defd2a" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 20:12:15 -0000 --001a1137baae860e1a0555defd2a Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 10:06 PM, Wessels, Duane wrote: > > > On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra wrote: > > > > However, I still don't see how it would help in case of trust anchor/KSK > compromise. > > This is why I wrote "I don't know if you consider it a solution." > > Even so, I think it could be useful, depending on the nature and scale of > the zone in question. For example, if you had to perform an emergency KSK > rollover you might do something like email a group of administrators with > instructions to manually update their trust anchors. RFC 8145 would help > you know how many administrators followed through on that request. > * "If the network administrator has an out-of-band method of contacting resolver administrators that have stored the public key as a trust anchor (such as e-mail), the network administrator should send out appropriate warnings and set up a trusted means of disseminating the new trust anchor. Otherwise, the DNS administrator can do nothing except pre-publish the new KSK with ample time to give resolver administrators enough time to learn the new KSK."* Sure you are right! But my question was for the "Otherwise" situation. > > DW > > --001a1137baae860e1a0555defd2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 10:06 PM, Wessels, Duane <<= a href=3D"mailto:dwessels@verisign.com" target=3D"_blank">dwessels@verisign= .com> wrote:

> On Aug 3, 2017, at 12:58 PM, Aanchal Malhotra <aanchal4@bu.edu> wrote:
>
> However, I still don't see how it would help in case of trust anch= or/KSK compromise.

This is why I wrote "I don't know if you consider it a solu= tion."

Even so, I think it could be useful, depending on the nature and scale of t= he zone in question.=C2=A0 For example, if you had to perform an emergency = KSK rollover you might do something like email a group of administrators wi= th instructions to manually update their trust anchors.=C2=A0 RFC 8145 woul= d help you know how many administrators followed through on that request.

"If the network administrator has an out-o= f-band method of contacting resolver administrators that have stored the public key as a trust=20 anchor (such as e-mail), the network administrator should send out=20 appropriate warnings and set up a trusted means of disseminating the new trust anchor. Otherwise, the DNS administrator can do nothing except pre-publish the new KSK with ample time to give resolver administrators enough time to learn the new KSK."

Sure you= are right! But my question was for the "Otherwise" situation.

DW


--001a1137baae860e1a0555defd2a-- From nobody Thu Aug 3 13:47:47 2017 Return-Path: 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 94057131CCC for ; Thu, 3 Aug 2017 13:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 CW9--3u8QTaL for ; Thu, 3 Aug 2017 13:47:45 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2045A131CC2 for ; Thu, 3 Aug 2017 13:47:45 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id x191so14540897qka.5 for ; Thu, 03 Aug 2017 13:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=GzzcWfvJkmuaYfeynx2kn5/Ojr4UkA1nqlMO8Bzd5xg=; b=gypDz0I2AeuQBgsbU9oSqQqVY0XXewSKQOPYqjdaCfRePFyrVPNcNbmg7yMylr5F0/ qtdd4JojNVFdYIRHaz3XEyn8ivN+GyXF6XbC48Z6k7RWPJPWIwf/NOzSfOQKarigwFwK D/7W6ko7N1mA7FKs783aJFSsiYBCweuriu6rBZQ9igKmhuwWsjZ67YcYm2dlfKD/oZSo gdlE0wRrsBHym+VIIcwFacNzBZ0vTkX87TgYzUWhVG2VANefqKff6Wpc8BO1+p/sXoho /0DrnJhD+5lf5N3c5M+8oz42EJ/WdgMjjN6K3ewCIWhx4wJi6i8TQn3d5MS/qfEeiBlH 8Fhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=GzzcWfvJkmuaYfeynx2kn5/Ojr4UkA1nqlMO8Bzd5xg=; b=r9GlgTe9TMn80KN/bJSH50Hjk5MKrJcndLSuP8R0Vlp5hTweV0lhK4ji5jf7627nqp KB4bWdu0FFt+866sklL95BJwxSxYArzmNgON+v3SXk68Vi5v71/KKRGO08bNBHQy8kKR qnmo9eUauPyE2dPHCLar1hELZIlnikxKj+PzPgtzi+W8961UKa2K/JURkP8XjfgL9wI+ zq+W/fx2N6GU6XUb5HHjCrSli9MOvfhFnzp+tmGgh0+a7pLwuqNbJkqSbBZbpAnb/oqC Q8nxgtaG1YqmpJgbyDKrsRd9mHYqcS+FucJTrD3BhfTVFJhQ82LgCAO2TQoTj9kLzqMj AfRg== X-Gm-Message-State: AHYfb5h6TU+jTVR4mfxj/QieGoYQxYSGfhDTCxuNHGh9WLvyWYoJNL/F e4XBT6HAovZpBp2EjYc= X-Received: by 10.55.7.139 with SMTP id 133mr103974qkh.165.1501793263860; Thu, 03 Aug 2017 13:47:43 -0700 (PDT) Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id a15sm13320075qte.10.2017.08.03.13.47.42 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 13:47:42 -0700 (PDT) To: dnsop@ietf.org References: From: Michael StJohns Message-ID: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> Date: Thu, 3 Aug 2017 16:47:40 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------09686E559DA270C474C7BBAE" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 20:47:47 -0000 This is a multi-part message in MIME format. --------------09686E559DA270C474C7BBAE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: > A DNSKEY RRset with pre-published KSK is signed by the old (now > compromised) KSK. When the resolver uses RFC 5011 for the trust anchor > update, the attacker can inject a new KSK (signed by the compromised > KSK). Which KSK is now the new T/rust Anchor /for the resolver? The resolver trust point trust anchor set contains both the old and pre-published stand-by key. When the old KSK is compromised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK. The stand by key does not trace its trust through the old key except during the process of being added. The attempt to inject the new KSK is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s). At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor. Mike --------------09686E559DA270C474C7BBAE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new Trust Anchor  for the resolver?

The resolver trust point trust anchor set contains both the old and pre-published stand-by key.   When the old KSK is compromised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK.   The stand by key does not trace its trust through the old key except during the process of being added.   The attempt to inject the new KSK is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s).


At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor.

Mike


--------------09686E559DA270C474C7BBAE-- From nobody Thu Aug 3 14:07:46 2017 Return-Path: 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 CE299129AEB for ; Thu, 3 Aug 2017 14:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 HbVl-1dJXpY9 for ; Thu, 3 Aug 2017 14:07:43 -0700 (PDT) Received: from relay74.bu.edu (relay74.bu.edu [128.197.228.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1775012940A for ; Thu, 3 Aug 2017 14:07:42 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f71.google.com (mail-oi0-f71.google.com [209.85.218.71]) by relay74.bu.edu (8.14.3/8.14.3) with ESMTP id v73L68Jm019703 for ; Thu, 3 Aug 2017 17:06:08 -0400 Received: by mail-oi0-f71.google.com with SMTP id b184so1815903oih.9 for ; Thu, 03 Aug 2017 14:06:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MVggKEWAXI6VSHo5YcMt5gZWoRPxhsaIAu1DzuBkyTQ=; b=q+QpArRWlHoRpn6G9joVtPfAXNojyS40m+Snt8iovaulQUBZITWqYJYCOvLK6OJQFc sArN9Eno9GTjGzpxJhJ/BcX66k5tlfVF76Pzbzokxn9VHDLmZhD4WY285dPh4zcOVL8V m4uTlUwsax66MZP8PC6uv/nre/3CXougAn1wHQxXAPzNjd75xiVv1QmaoJ46qtm5lrvr SeGobbSyFc60yGfi8pRoLNQslwEyBD90mPrko9rnU+XC1ptZ9+KALH0aeNE2GAcVz3p1 uvf4AzvCGTBWjPL2UqNfNoicmhxYUh+JbDNQDdrs+FHPVOqL8l/KONJIkxIfAUbE+ELV vovA== X-Gm-Message-State: AHYfb5gsYMEizJewWKXXcvlE0TEW+adtz7S4GvdBe2vwJnd+sWfPiaEM p182UGOK3XR8Yd6fULRSVLY2s2EgAUiXzA1+BnjbXA3+110+a3hnjiDjZM9aKim8UwUpsV69MNX pkYuSH3b4yKWKfw== X-Received: by 10.202.83.6 with SMTP id h6mr146299oib.138.1501794367634; Thu, 03 Aug 2017 14:06:07 -0700 (PDT) X-Received: by 10.202.83.6 with SMTP id h6mr146284oib.138.1501794367297; Thu, 03 Aug 2017 14:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 14:05:46 -0700 (PDT) In-Reply-To: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> From: Aanchal Malhotra Date: Thu, 3 Aug 2017 23:05:46 +0200 Message-ID: To: Michael StJohns Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a113d2e08c9f6340555dfbf9d" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 21:07:45 -0000 --001a113d2e08c9f6340555dfbf9d Content-Type: text/plain; charset="UTF-8" Hi Mike, On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns wrote: > On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: > > A DNSKEY RRset with pre-published KSK is signed by the old (now > compromised) KSK. When the resolver uses RFC 5011 for the trust anchor > update, the attacker can inject a new KSK (signed by the compromised KSK). > Which KSK is now the new T*rust Anchor *for the resolver? > > The resolver trust point trust anchor set contains both the old and > pre-published stand-by key. When the old KSK is compromised, you set the > revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked > KSK and the standby KSK. The stand by key does not trace its trust > through the old key except during the process of being added. The attempt > to inject the new KSK is foiled by revoking the old KSK and publishing the > revocation before the hold-down time expires for the resolver(s). > I understand and agree to what you say. And even RFC 5011 explicitly states that this approach works only if there is a backup/standby/pre-published (whatever name we like) and the assumption that both active and stand-by keys are not compromised at the same time. The point is again, as Warren mentioned, that one needs two trust anchors in this case. And the issues ensue.... Also, I am not sure if there is any implementations that are actually doing standby-keys (not that I am aware of). What I am trying to say is that we do not have a solution to this problem without a back-up key set? > > At some point - ideally quickly after the old KSK revocation - you publish > a new standby KSK long enough to inject it as a new trust anchor. > > Mike > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a113d2e08c9f6340555dfbf9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <ms= j@nthpermutation.com> wrote:
On 8/3/2017 3:01 P= M, Aanchal Malhotra wrote:
A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new Trust Anchor=C2=A0 = for the resolver?

The resolver trust point trust anchor set contains both the o= ld and pre-published stand-by key.=C2=A0=C2=A0 When the old KSK is compr= omised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK.=C2=A0=C2=A0 The stand = by key does not trace its trust through the old key except during the process of being added.=C2=A0=C2=A0 The attempt to inject the new KSK= is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s).


I understand and agree to what you say. And eve= n RFC 5011 explicitly states that this approach works only if there is a ba= ckup/standby/pre-published (whatever name we like) and the assumption that = both active and stand-by keys are not compromised at the same time. The poi= nt is again, as Warren mentioned, that one needs two trust anchors in this = case. And the issues ensue.... Also, I am not sure if there is any implemen= tations that are actually doing standby-keys (not that I am aware of).
=
What I am trying to say is that we do not have a solution to= this problem without a back-up key set?


At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor.

Mike



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


--001a113d2e08c9f6340555dfbf9d-- From nobody Thu Aug 3 14:49:43 2017 Return-Path: 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 ACB8F12EB2B for ; Thu, 3 Aug 2017 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com 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 tLrKYRlh6h6c for ; Thu, 3 Aug 2017 14:49:40 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E71131950 for ; Thu, 3 Aug 2017 14:49:39 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id 16so15545179qtz.4 for ; Thu, 03 Aug 2017 14:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=EPqvczlDVrhD3qPVyvBpzUeEhy3jmiJQWund1YdNs/E=; b=IWIZWDEYHT76K7tD7XG2cCDT+im78srFmEEI/Cl+1QvI/rijyyKm3p2ursRBMA34/a 6VJy9aXFUOBZDD6X+riJRRK4/ReAKXvQyDvcKgWrQ0r39monSG5BVmOR3Cimlx+P61iB VqbS2v6eeUwFHv60uC8b5z+gn4LUg8CXPjo9ZnYwDN2xoPmyhZl+VTLO7j+1lwOrxrXO UYD7UZRmEzx0OHM/GBIuRFRKQxFbhJDmjQPC7a5raDejVO79vOlFYEa4zdv3JG+5StSV ObztP0eGN7tt/4vAzl1qLypeu4+iEMfRiUG6xjiOFl+Cvv6j9KV5ig68/scOX9sc49mC 0yMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=EPqvczlDVrhD3qPVyvBpzUeEhy3jmiJQWund1YdNs/E=; b=X/ECRh+zCy4AWUULoVuvoXNjKyEfIzTSwAB5Fi7Yv4Ktn4KHmeXVL0a0Pvy0e+NXf7 wPcLNS1gEMaKYXGrWUBDcapi9YJ45o/JjjAruPLqQiatM/g0QDqzlXGdt8svTlK3aeOa 5Arf+6OKkWoMC9dDDFhpU42/mDNNyFOdUKLz4qpPBn9KQZX0gzoRiA+J8UhDSdpN0BFO yEz+y44Ol3o5fSHUpxfmxJVYmb1fqCnwRrb0Wy4zl/MytPnU5Ubhlhq5VK0lechzQpDb 30MoGJXVS9Gl9A9iepwJErqP/yv1n+JyfEmr7QUUqgMN0RfxSdcHjEZT4QBy7c5sIAxj mZPg== X-Gm-Message-State: AHYfb5i7VCZQSDpZ/2Mw2Nr6B6N07G5Zd/r9vaz3CbCzLZ8KXTq1UDC0 jBjRg4reY0xYH53e5GA= X-Received: by 10.237.32.172 with SMTP id 41mr400187qtb.260.1501796978816; Thu, 03 Aug 2017 14:49:38 -0700 (PDT) Received: from [192.168.1.117] (c-69-140-114-191.hsd1.md.comcast.net. [69.140.114.191]) by smtp.gmail.com with ESMTPSA id a126sm25841150qkf.25.2017.08.03.14.49.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Aug 2017 14:49:37 -0700 (PDT) To: Aanchal Malhotra Cc: dnsop@ietf.org References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> From: Michael StJohns Message-ID: <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> Date: Thu, 3 Aug 2017 17:49:35 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5E7CFA7EAE7FEC3043821E98" Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 21:49:41 -0000 This is a multi-part message in MIME format. --------------5E7CFA7EAE7FEC3043821E98 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I answered the question that you asked. Other people are weighing in on the root and stand by keys. Mike On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: > Hi Mike, > > On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns > > wrote: > > On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: >> A DNSKEY RRset with pre-published KSK is signed by the old (now >> compromised) KSK. When the resolver uses RFC 5011 for the trust >> anchor update, the attacker can inject a new KSK (signed by the >> compromised KSK). Which KSK is now the new T/rust Anchor /for the >> resolver? > > The resolver trust point trust anchor set contains both the old > and pre-published stand-by key. When the old KSK is compromised, > you set the revoke bit on the old KSK, and sign the DNSKEY RRSet > with both the revoked KSK and the standby KSK. The stand by key > does not trace its trust through the old key except during the > process of being added. The attempt to inject the new KSK is > foiled by revoking the old KSK and publishing the revocation > before the hold-down time expires for the resolver(s). > > > I understand and agree to what you say. And even RFC 5011 explicitly > states that this approach works only if there is a > backup/standby/pre-published (whatever name we like) and the > assumption that both active and stand-by keys are not compromised at > the same time. The point is again, as Warren mentioned, that one needs > two trust anchors in this case. And the issues ensue.... Also, I am > not sure if there is any implementations that are actually doing > standby-keys (not that I am aware of). > > What I am trying to say is that we do not have a solution to this > problem without a back-up key set? > > > At some point - ideally quickly after the old KSK revocation - you > publish a new standby KSK long enough to inject it as a new trust > anchor. > > Mike > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > > --------------5E7CFA7EAE7FEC3043821E98 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I answered the question that you asked.  Other people are weighing in on the root and stand by keys.

Mike



On 8/3/2017 5:05 PM, Aanchal Malhotra wrote:
Hi Mike,

On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new Trust Anchor  for the resolver?

The resolver trust point trust anchor set contains both the old and pre-published stand-by key.   When the old KSK is compromised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK.   The stand by key does not trace its trust through the old key except during the process of being added.   The attempt to inject the new KSK is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s).


I understand and agree to what you say. And even RFC 5011 explicitly states that this approach works only if there is a backup/standby/pre-published (whatever name we like) and the assumption that both active and stand-by keys are not compromised at the same time. The point is again, as Warren mentioned, that one needs two trust anchors in this case. And the issues ensue.... Also, I am not sure if there is any implementations that are actually doing standby-keys (not that I am aware of).

What I am trying to say is that we do not have a solution to this problem without a back-up key set?


At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor.

Mike



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



--------------5E7CFA7EAE7FEC3043821E98-- From nobody Thu Aug 3 15:12:27 2017 Return-Path: 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 3947912711E for ; Thu, 3 Aug 2017 15:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 Xh3e5396Uxbt for ; Thu, 3 Aug 2017 15:12:23 -0700 (PDT) Received: from relay60.bu.edu (relay60.bu.edu [128.197.228.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF127131C11 for ; Thu, 3 Aug 2017 15:12:22 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f70.google.com (mail-oi0-f70.google.com [209.85.218.70]) by relay60.bu.edu (8.14.3/8.14.3) with ESMTP id v73MBvam029638 for ; Thu, 3 Aug 2017 18:11:57 -0400 Received: by mail-oi0-f70.google.com with SMTP id f11so24113oih.7 for ; Thu, 03 Aug 2017 15:11:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=StBB+LbcA3mrogR7DmI00wUFOakvo08HVHlBxbilQ6Q=; b=pSqMys/VagrlNokQFzn6yIUWRagP2p9qGV7odCObuk6GwkaqT1vCxpc2zBa+THGD8Y zjUIRnW+YXbVjKZF8oIJPvxwPNUDdBliUOe6ABJbpVScnINl8D21Hc1s6zM4+EakDV09 JpbQOZBczeBBCT3AWYH3CaT9sXTg/zZy1zrd2UTeCy0+wA2+KUtSmMaWeFVEUSvIhd6B 4enyPXyfmIUpMA8fP96iyh95EcQuxCBV/y7cKgHP2+oVIR9wp2OSUJN83rULBDSxjASJ NrveyWHa8Mmtya/kV8DZZXTGwYEATP6sTfyaSrEPQqQR28jIyAF6Y/GLO0eXVEeph7fL 6AgA== X-Gm-Message-State: AHYfb5j66BHC+qouN31xSVJFqCasaXC+yJO/S1Noej4VYdH01Zcpa2IQ cHWJDsmKIBDRAxlmTQ6SIGRaiHYR2D1MjDQ//kh+M6qpmhO1l1eTV1WQz8j0tXucN/W6nnfCnEI jtGbDGsIeUooBZg== X-Received: by 10.202.227.5 with SMTP id a5mr265532oih.240.1501798316674; Thu, 03 Aug 2017 15:11:56 -0700 (PDT) X-Received: by 10.202.227.5 with SMTP id a5mr265525oih.240.1501798316364; Thu, 03 Aug 2017 15:11:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Thu, 3 Aug 2017 15:11:35 -0700 (PDT) In-Reply-To: <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> From: Aanchal Malhotra Date: Fri, 4 Aug 2017 00:11:35 +0200 Message-ID: To: Michael StJohns Cc: dnsop@ietf.org Content-Type: multipart/alternative; boundary="001a1141a5722bfb1a0555e0ab9f" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 22:12:25 -0000 --001a1141a5722bfb1a0555e0ab9f Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns wrote: > I answered the question that you asked. > Yes, thanks Mike. That answers my question about the attack. It was not clear that pre-published was synonymous with stand-by keys. > Other people are weighing in on the root and stand by keys. > > Mike > However, my question (not just for Mike.) "If we have a solution to this (subject of this thread) problem without a back-up key set? And do we even care about it?" still remains. Thx. > > > > > On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: > > Hi Mike, > > On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns > wrote: > >> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: >> >> A DNSKEY RRset with pre-published KSK is signed by the old (now >> compromised) KSK. When the resolver uses RFC 5011 for the trust anchor >> update, the attacker can inject a new KSK (signed by the compromised KSK). >> Which KSK is now the new T*rust Anchor *for the resolver? >> >> The resolver trust point trust anchor set contains both the old and >> pre-published stand-by key. When the old KSK is compromised, you set the >> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked >> KSK and the standby KSK. The stand by key does not trace its trust >> through the old key except during the process of being added. The attempt >> to inject the new KSK is foiled by revoking the old KSK and publishing the >> revocation before the hold-down time expires for the resolver(s). >> > > I understand and agree to what you say. And even RFC 5011 explicitly > states that this approach works only if there is a > backup/standby/pre-published (whatever name we like) and the assumption > that both active and stand-by keys are not compromised at the same time. > The point is again, as Warren mentioned, that one needs two trust anchors > in this case. And the issues ensue.... Also, I am not sure if there is any > implementations that are actually doing standby-keys (not that I am aware > of). > > What I am trying to say is that we do not have a solution to this problem > without a back-up key set? > >> >> At some point - ideally quickly after the old KSK revocation - you >> publish a new standby KSK long enough to inject it as a new trust anchor. >> >> Mike >> >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> >> > > --001a1141a5722bfb1a0555e0ab9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <= msj@nthpermutat= ion.com> wrote:
=20 =20 =20
I answered t= he question that you asked.=C2=A0

Yes, thanks= Mike. That answers my question about the attack. It was not clear that pre= -published was synonymous with stand-by keys.
=C2=A0
Other people are weighing = in on the root and stand by keys.

Mike

However, my question=C2=A0 (not= just for Mike.)
=C2=A0
"If we=C2=A0 have a solution to this (su= bject of this thread) problem without a back-up key set? And do we even car= e about it?" still remains.

Thx.




On 8/3/2017 5:05 PM, Aanchal Malhotra wrote:
Hi Mike,

On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <msj@nthpermutation.com> wrote:
On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
A DNSKEY RRset with pre-published KSK is signed by the old (now compromised) KSK. When the resolver uses RFC 5011 for the trust anchor update, the attacker can inject a new KSK (signed by the compromised KSK). Which KSK is now the new Trust Anchor=C2=A0 fo= r the resolver?

The resolver trust point trust anchor set contains both the old and pre-published stand-by key.=C2=A0=C2= =A0 When the old KSK is compromised, you set the revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked KSK and the standby KSK.=C2=A0=C2=A0 The st= and by key does not trace its trust through the old key except during the process of being added.=C2=A0=C2=A0 T= he attempt to inject the new KSK is foiled by revoking the old KSK and publishing the revocation before the hold-down time expires for the resolver(s).


I understand and agree to what you say. And even RFC 5011 explicitly states that this approach works only if there is a backup/standby/pre-published (whatever name we like) and the assumption that both active and stand-by keys are not compromised at the same time. The point is again, as Warren mentioned, that one needs two trust anchors in this case. And the issues ensue.... Also, I am not sure if there is any implementations that are actually doing standby-keys (not that I am aware of).

What I am trying to say is that we do not have a solution to this problem without a back-up key set?


At some point - ideally quickly after the old KSK revocation - you publish a new standby KSK long enough to inject it as a new trust anchor.

Mike



_______________________________________________
DNSOP mailing list
DNSOP@i= etf.org
https://www.ietf.org/mailman/listinf= o/dnsop




--001a1141a5722bfb1a0555e0ab9f-- From nobody Thu Aug 3 15:36:34 2017 Return-Path: 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 5869F131CF1 for ; Thu, 3 Aug 2017 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 eFtMyaMYQS8y for ; Thu, 3 Aug 2017 15:36:31 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 A9131131D21 for ; Thu, 3 Aug 2017 15:36:31 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v73Mavov023984 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 3 Aug 2017 15:36:57 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1501799817; bh=fnmOX2zimLcX2gDfTFjBOGICPXdKQjhXXLdyJt1RwSU=; h=From:Subject:Reply-To:To:References:Date:In-Reply-To:From; b=pe8Mo85cDZoEHVy186dmt4R++nOM3vTxnfT5ouahtMy+yKwv5EDl7fo66oUjFAXg9 r64o1IAucmci6EzyBwJrJ/Y8Md9YRGbjevea3VHugD8Fl5DnoxclA/tkatzNxVZX7k cZBkLLaE7DMZg9ti5PqvYa2NfAkkHzthm4MRGeB0= From: Dave Crocker Reply-To: dcrocker@bbiw.net To: dnsop References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> Organization: Brandenburg InternetWorking Message-ID: <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> Date: Thu, 3 Aug 2017 15:36:24 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Thu, 03 Aug 2017 22:36:33 -0000 Howdy. (I posted this on the ART list, yesterday, because Tim started a query about attrleaf there, but the note should probably also be posted at the attleaf hosting wg list. /d) I've been mulling over the challenges of this registration topic for more than a decade, constantly being hoisted on the petard of established practice... First, underscores can be used for multiple levels of node name. Trying to deal with that fully, in a single spec produced an especially confused draft, roughly 10 years ago. More recently it became clear that this is best handled by the described simplification the spec now declares -- essentially distinguishing between 'top-level' underscore names and separately deal with those below. But, as you note, this is not fully or adequately implemented in the latest versions of the draft. But I'll leave details about further fixes for that, for the moment, because... Second, and much worse, is that the original documentation of underscore use created an inherently-problematic arrangement: Attempting to synthesize some of the registration by incorporating entries in independent registration tables documented in SRV and URI specifications. The semantics therefore would mean there would be more than one 'authority' for name registration. This is a registration model designed to produce collisions. Efforts have been to retrofit an administrative model that accommodated this, where the idea of real-time conflict detection and resolution -- by infinitely diligent and perfectly perceptive -- IANA staff is one of the more recent suggestions. Unfortunately, there is an essential and practical difference between 'excellent' and 'perfect', where the latter is an inappropriate goal for human performance. I've come to the conclusion that "accommodating" the established registration practices is a fundamentally wrong path. The only way to solve a problem of multiple registration authorities is to create a single registration authority. That is, the right path is to create a simple and obvious registration model, and, separately, go back and fix the problematic documents. Therefore I propose to: 1. Have this document define the simple, sole, authoritative mechanism for registering "top-level" (global scope) underscore names. 2. Create a separate document that specifies modifications to the SRV and URI documents, rationalizing the use of underscore names, through the mechanism defined in -attrleaf-. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 4 04:01:56 2017 Return-Path: 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 7A71F132014 for ; Fri, 4 Aug 2017 04:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xIDZQ4-jpy_n for ; Fri, 4 Aug 2017 04:01:52 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 5504C131FF3 for ; Fri, 4 Aug 2017 04:01:51 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:41094) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1ddaMV-000CK8-el (Exim 4.89) (return-path ); Fri, 04 Aug 2017 12:01:47 +0100 Date: Fri, 4 Aug 2017 12:01:47 +0100 From: Tony Finch To: Aanchal Malhotra cc: Michael StJohns , dnsop@ietf.org In-Reply-To: Message-ID: References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 11:01:54 -0000 Aanchal Malhotra wrote: > > What I am trying to say is that we do not have a solution to this problem > without a back-up key set? ... isn't that true for all kinds of disaster recovery plans? Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Shannon, Rockall, Malin, Hebrides: West or northwest, 4 or 5, decreasing 3 at times. Moderate. Showers, thundery later in Shannon. Good occasionally poor later in Shannon. From nobody Fri Aug 4 07:12:27 2017 Return-Path: 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 5DBD8131EAD for ; Fri, 4 Aug 2017 07:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 OoW8pabdruVx for ; Fri, 4 Aug 2017 07:12:23 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9795131FED for ; Fri, 4 Aug 2017 07:12:22 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 80so7750375uas.0 for ; Fri, 04 Aug 2017 07:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hGOXYzmSS8HCunWdbzdlcteS4m9sWdZ4UJbXgHFgl1g=; b=TnmqdOscYaDKaI3fE1LiQDni4vZNiJ+hSVoPs1AG/XIr4kkmwffa+JP7erGJW/8T3n /RLOtdMQ0moDMHj5nLzC+rpn0km5dfZgEdL5vmr1m8FNWl/RttrJv2PT9H7CCIyUldyj CoXrIxsGPYRA3i+I76aFClKqsYRAqgBWvNNEw0fgKzeBtLIOyQWZU+EBS7uG08aCKBSr lBgqDf7sFJiG086pejb0eyadCK42cJhbrv7cgOeHVN3aHppDZeWMT1F5l0Iufat5RD7h Ep/wC0GM0Jl7/39DRVN0lnIdAsWjc3YSfVHgXdQ/Fd8lloQsFAXsP+xZwzmfhxi37bxp hyaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hGOXYzmSS8HCunWdbzdlcteS4m9sWdZ4UJbXgHFgl1g=; b=YhHpFVxMHjWrIrghFXdcWS/0fgwVS7R964fRAeI5QBYLWTa7uHT0IQYEBnq1sQac3I FyCmAgKbdkmNF0uINnsgq5ZOqDDposYb8KdfjPP4n9Tl6Dd2Az/NPB013lP94mATWtD/ nkp+BT/hsm2hV1TldZxpYy/jynBEYqvmysXO8LmYnBsR3AfaZ0p1SwLQdzUq3dsQn/br byZcRc9X+Y8oOE5Li9mM2eG575fC2No3O5a9S+F9C2YZ5TuQ/LGzySEeh9dZw+US8SdT LenB1UXAlpFnLIZxAXPP5b2oqDtp6Xd+CSCDgNFpkMvLetXd0gUq7frsJ+FmaQV+yJHT Gvnw== X-Gm-Message-State: AHYfb5jDYHsoWT9txKULrduFI6F/Q/BoO1eiWVb3l0TkNwz6JePeSB+0 m7K+Abbr2Iqp3RVLJaRxoTQkBEhO3MwK X-Received: by 10.176.95.27 with SMTP id p27mr1564380uah.2.1501855941771; Fri, 04 Aug 2017 07:12:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.9.231 with HTTP; Fri, 4 Aug 2017 07:11:41 -0700 (PDT) In-Reply-To: References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> From: Warren Kumari Date: Fri, 4 Aug 2017 10:11:41 -0400 Message-ID: To: Aanchal Malhotra Cc: Michael StJohns , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 14:12:25 -0000 On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra wrote: > > > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns > wrote: >> >> I answered the question that you asked. > > > Yes, thanks Mike. That answers my question about the attack. It was not > clear that pre-published was synonymous with stand-by keys. > >> >> Other people are weighing in on the root and stand by keys. >> >> Mike > > > However, my question (not just for Mike.) > > "If we have a solution to this (subject of this thread) problem without a > back-up key set? And do we even care about it?" still remains. > Well, we kinda do... The plan (which I haven't seen, but have been assured exists, is well fleshed out and documented, etc) is that, if the primary is suspected to be compromised (or lost), an "emergency key roll" will occur. This involves, from what I've been told, publishing new keys / hashes on the IANA site (https://www.iana.org/dnssec/files), and a "significant press event", publishing the new key on newspapers, blogs, etc. The attestations by the trusted community reps and signatures chaining back to CA certs is supposed to prove the validity of this new key, and the compromise of the old one. Unsurprisingly, it would be good if the emergency roll process never needs to be invoked; the key protections are supposed to be safe enough that this should be very unlikely. Much of this is very similar to the loss / compromise of a CA root cert... W > Thx. >> >> >> >> >> >> On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: >> >> Hi Mike, >> >> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns >> wrote: >>> >>> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: >>> >>> A DNSKEY RRset with pre-published KSK is signed by the old (now >>> compromised) KSK. When the resolver uses RFC 5011 for the trust anchor >>> update, the attacker can inject a new KSK (signed by the compromised KSK). >>> Which KSK is now the new Trust Anchor for the resolver? >>> >>> The resolver trust point trust anchor set contains both the old and >>> pre-published stand-by key. When the old KSK is compromised, you set the >>> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked >>> KSK and the standby KSK. The stand by key does not trace its trust through >>> the old key except during the process of being added. The attempt to >>> inject the new KSK is foiled by revoking the old KSK and publishing the >>> revocation before the hold-down time expires for the resolver(s). >> >> >> I understand and agree to what you say. And even RFC 5011 explicitly >> states that this approach works only if there is a >> backup/standby/pre-published (whatever name we like) and the assumption that >> both active and stand-by keys are not compromised at the same time. The >> point is again, as Warren mentioned, that one needs two trust anchors in >> this case. And the issues ensue.... Also, I am not sure if there is any >> implementations that are actually doing standby-keys (not that I am aware >> of). >> >> What I am trying to say is that we do not have a solution to this problem >> without a back-up key set? >>> >>> >>> At some point - ideally quickly after the old KSK revocation - you >>> publish a new standby KSK long enough to inject it as a new trust anchor. >>> >>> Mike >>> >>> >>> >>> _______________________________________________ >>> 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 > -- 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 nobody Fri Aug 4 07:44:41 2017 Return-Path: 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 4E9D01321AD for ; Fri, 4 Aug 2017 07:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] 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 Wm4uayFfWKBm for ; Fri, 4 Aug 2017 07:44:36 -0700 (PDT) Received: from relay52.bu.edu (relay52.bu.edu [128.197.228.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24EB81321B0 for ; Fri, 4 Aug 2017 07:44:35 -0700 (PDT) X-Envelope-From: aanchal4@bu.edu Received: from mail-oi0-f69.google.com (mail-oi0-f69.google.com [209.85.218.69]) by relay52.bu.edu (8.14.3/8.14.3) with ESMTP id v74EiKQt014152 for ; Fri, 4 Aug 2017 10:44:20 -0400 Received: by mail-oi0-f69.google.com with SMTP id p62so1416463oih.12 for ; Fri, 04 Aug 2017 07:44:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tm9ybzMz//bP29xzLuj/VcUdc5D8DsQ3gWwp9C35wio=; b=D6vKfFqKsPzt4J7PiqovZsm5Ty9tHs5qjBi0LUr4nlGmjarDt8U0d1rBkZH9kuivYU kpoZCu+/LnZuY5+W/G/Mfwysu0EaWpd6V3wFZ/oOS+vIHdq4tqEVPDQ1apwtv+Pqu4FY X2LBz/mWYUH+0/qj4QiBzTOfp4Ji7oeaITuQJJdH5fCLz7IfOfx/SluHdZO6OPcOAE4m cmDn39FVFHj/ies8m/T7fwfE6sOeak17CgznN4Qxe2T6UjIE7CZOt0SBTQnnixwRPOvQ TW6acHV15I0gZM6Q3y0STICxrDAFpIsm/n7nldXrafnuDQ54lEDPN7LA4YarmA+GWMnC l9wQ== X-Gm-Message-State: AHYfb5hLqAFD2KybKEeAY65j3YgFZ72YZhQIwyORDJ4GAKCy2bzPcVCo kdzyqG+aMaaRCzm8V3usRJUV2g88HliyvEKgpKZvhKxxfUkqkzcMQroyQfkNh6UlIqJYmm/dgfq IXjNBVfMQ4Ylf7g== X-Received: by 10.202.102.198 with SMTP id m67mr1746846oik.297.1501857860179; Fri, 04 Aug 2017 07:44:20 -0700 (PDT) X-Received: by 10.202.102.198 with SMTP id m67mr1746835oik.297.1501857859921; Fri, 04 Aug 2017 07:44:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.121.75 with HTTP; Fri, 4 Aug 2017 07:43:59 -0700 (PDT) In-Reply-To: References: <70641a7b-8fe1-265a-5eb0-6e484ff7c735@nthpermutation.com> <1214cb8a-54be-68d8-edda-9e1cd804996b@nthpermutation.com> From: Aanchal Malhotra Date: Fri, 4 Aug 2017 16:43:59 +0200 Message-ID: To: Warren Kumari Cc: dnsop , Michael StJohns Content-Type: multipart/alternative; boundary="001a1140a92c3e7e580555ee8851" Archived-At: Subject: Re: [DNSOP] Emergency KSK Rollover for locally secure zones. X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 14:44:39 -0000 --001a1140a92c3e7e580555ee8851 Content-Type: text/plain; charset="UTF-8" Thanks Warren. On Fri, Aug 4, 2017 at 4:11 PM, Warren Kumari wrote: > On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra wrote: > > > > > > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns > > > wrote: > >> > >> I answered the question that you asked. > > > > > > Yes, thanks Mike. That answers my question about the attack. It was not > > clear that pre-published was synonymous with stand-by keys. > > > >> > >> Other people are weighing in on the root and stand by keys. > >> > >> Mike > > > > > > However, my question (not just for Mike.) > > > > "If we have a solution to this (subject of this thread) problem without > a > > back-up key set? And do we even care about it?" still remains. > > > > Well, we kinda do... > > The plan (which I haven't seen, but have been assured exists, is well > fleshed out and documented, etc) is that, if the primary is suspected > to be compromised (or lost), an "emergency key roll" will occur. > Wouldn't it be good if this document is accessible to all? Is there a reason for this document not being public? > > This involves, from what I've been told, publishing new keys / hashes > on the IANA site (https://www.iana.org/dnssec/files), and a > "significant press event", publishing the new key on newspapers, > blogs, etc. > > The attestations by the trusted community reps and signatures chaining > back to CA certs is supposed to prove the validity of this new key, > and the compromise of the old one. > That sounds like a plan (with a "significant press event" being my fav part :)) > > Unsurprisingly, it would be good if the emergency roll process never > needs to be invoked; the key protections are supposed to be safe > enough that this should be very unlikely. Much of this is very similar > to the loss / compromise of a CA root cert... > Yes I agree. It will be a highly unlikely and unfortunate event for the root trust anchor to be compromised. But what about emergency key rollover for other islands of trust/security, if there exist any? And do we care about them? > > W > > > Thx. > >> > >> > >> > >> > >> > >> On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: > >> > >> Hi Mike, > >> > >> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns < > msj@nthpermutation.com> > >> wrote: > >>> > >>> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: > >>> > >>> A DNSKEY RRset with pre-published KSK is signed by the old (now > >>> compromised) KSK. When the resolver uses RFC 5011 for the trust anchor > >>> update, the attacker can inject a new KSK (signed by the compromised > KSK). > >>> Which KSK is now the new Trust Anchor for the resolver? > >>> > >>> The resolver trust point trust anchor set contains both the old and > >>> pre-published stand-by key. When the old KSK is compromised, you set > the > >>> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the > revoked > >>> KSK and the standby KSK. The stand by key does not trace its trust > through > >>> the old key except during the process of being added. The attempt to > >>> inject the new KSK is foiled by revoking the old KSK and publishing the > >>> revocation before the hold-down time expires for the resolver(s). > >> > >> > >> I understand and agree to what you say. And even RFC 5011 explicitly > >> states that this approach works only if there is a > >> backup/standby/pre-published (whatever name we like) and the assumption > that > >> both active and stand-by keys are not compromised at the same time. The > >> point is again, as Warren mentioned, that one needs two trust anchors in > >> this case. And the issues ensue.... Also, I am not sure if there is any > >> implementations that are actually doing standby-keys (not that I am > aware > >> of). > >> > >> What I am trying to say is that we do not have a solution to this > problem > >> without a back-up key set? > >>> > >>> > >>> At some point - ideally quickly after the old KSK revocation - you > >>> publish a new standby KSK long enough to inject it as a new trust > anchor. > >>> > >>> Mike > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > -- > 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 > --001a1140a92c3e7e580555ee8851 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Warren.

On Fri, Aug 4, 2017 at 4:11 PM, Warren Kumari <warren@= kumari.net> wrote:
On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra <aanchal4@bu.edu> wrote:
>
>
> On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <msj@nthpermutation.com>
> wrote:
>>
>> I answered the question that you asked.
>
>
> Yes, thanks Mike. That answers my question about the attack. It was no= t
> clear that pre-published was synonymous with stand-by keys.
>
>>
>> Other people are weighing in on the root and stand by keys.
>>
>> Mike
>
>
> However, my question=C2=A0 (not just for Mike.)
>
> "If we=C2=A0 have a solution to this (subject of this thread) pro= blem without a
> back-up key set? And do we even care about it?" still remains. >

Well, we kinda do...

The plan (which I haven't seen, but have been assured exists, is well fleshed out and documented, etc) is that, if the primary is suspected
to be compromised (or lost), an "emergency key roll" will occur.<= br>

Wouldn't it be good if this documen= t is accessible to all? Is there a reason for this document not being publi= c?

This involves, from what I've been told, publishing new keys / hashes on the IANA site (https://www.iana.org/dnssec/files), and = a
"significant press event", publishing the new key on newspapers,<= br> blogs, etc.

The attestations by the trusted community reps and signatures chaining
back to CA certs is supposed to prove the validity of this new key,
and the compromise of the old one.

That= sounds like a plan (with a "significant press event" being my fa= v part :))

Unsurprisingly, it would be good if the emergency roll process never
needs to be invoked; the key protections are supposed to be safe
enough that this should be very unlikely. Much of this is very similar
to the loss / compromise of a CA root cert...

Yes I agree. It will be a highly unlikely and unfortunate event for = the root trust anchor to be compromised.

But what about e= mergency key rollover for other islands of trust/security, if there exist a= ny? And do we care about them?

W

> Thx.
>>
>>
>>
>>
>>
>> On 8/3/2017 5:05 PM, Aanchal Malhotra wrote:
>>
>> Hi Mike,
>>
>> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <msj@nthpermutation.com>
>> wrote:
>>>
>>> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote:
>>>
>>> A DNSKEY RRset with pre-published KSK is signed by the old (no= w
>>> compromised) KSK. When the resolver uses RFC 5011 for the trus= t anchor
>>> update, the attacker can inject a new KSK (signed by the compr= omised KSK).
>>> Which KSK is now the new Trust Anchor=C2=A0 for the resolver?<= br> >>>
>>> The resolver trust point trust anchor set contains both the ol= d and
>>> pre-published stand-by key.=C2=A0 =C2=A0When the old KSK is co= mpromised, you set the
>>> revoke bit on the old KSK, and sign the DNSKEY RRSet with both= the revoked
>>> KSK and the standby KSK.=C2=A0 =C2=A0The stand by key does not= trace its trust through
>>> the old key except during the process of being added.=C2=A0 = =C2=A0The attempt to
>>> inject the new KSK is foiled by revoking the old KSK and publi= shing the
>>> revocation before the hold-down time expires for the resolver(= s).
>>
>>
>> I understand and agree to what you say. And even RFC 5011 explicit= ly
>> states that this approach works only if there is a
>> backup/standby/pre-published (whatever name we like) and the assum= ption that
>> both active and stand-by keys are not compromised at the same time= . The
>> point is again, as Warren mentioned, that one needs two trust anch= ors in
>> this case. And the issues ensue.... Also, I am not sure if there i= s any
>> implementations that are actually doing standby-keys (not that I a= m aware
>> of).
>>
>> What I am trying to say is that we do not have a solution to this = problem
>> without a back-up key set?
>>>
>>>
>>> At some point - ideally quickly after the old KSK revocation -= you
>>> publish a new standby KSK long enough to inject it as a new tr= ust anchor.
>>>
>>> Mike
>>>
>>>
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/d= nsop
>>>
>>
>>
>
>
> _______________________________________________
> 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.
=C2=A0 =C2=A0---maf

____________________________= ___________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a1140a92c3e7e580555ee8851-- From nobody Fri Aug 4 09:02:48 2017 Return-Path: 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 ADDAC13233D for ; Fri, 4 Aug 2017 09:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 sGhU-08ynZy3 for ; Fri, 4 Aug 2017 09:02:44 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246EA132332 for ; Fri, 4 Aug 2017 09:02:40 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q25so9119608uah.1 for ; Fri, 04 Aug 2017 09:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zQFeCMBQYCuQ9eQN+UgJg2nJwH7kkrwW0JDNlTe7HDw=; b=Vm6gRngc2tGUKSxiOYgmTqiAww8nO3Mf29tw1kLClFuWuk09Jo9Iwno1WACEHsZyxS CZSg3CVA9mWPEMDsbFBfyMRQtIiW4Oxaz1mhFuCPl9QPkICXE1mED/4ZuySWMYgolGYA FerFCyIY0gWhhdJ/ml6mZcIjWlWLdlvvr+lvTvUEMXMyq+D1tLvjTIqsIOLQNv9gVx9k oGl3USNyd+tQ6wEyYc/RFvNAmX2SMWZlo2RGLj233gxxZqrpfGvn+suKrqE4JkxVR/i7 3W2fhbK40EH8eViz0BTOQpRTBBQ2xArgpkhxyF1U1UkeTUdFwSH7/9KNhYBQ0DFZ2LfE gTCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zQFeCMBQYCuQ9eQN+UgJg2nJwH7kkrwW0JDNlTe7HDw=; b=VgM1Tq7AUpWMRrJKU0pHZUYiYcmA1YnhW59ne66Wy9c89WTXGlOT3QGXMmNktZS9b7 JlNrJX76JiTT7doiddwkMkFzAUAqhLT0k6hnhbC6UMEHrwoUqB+yaBdMGrw+zubdO8mn cIDCEW9bLL+Bh9YMPt9IavmtT/RaGsYgj7NJbpgFj4OX4ZeMqaiJMwzprPyLRGzT0Yj/ 5gPGjK3xJxQzylTpLuQGr46dZuXOrqjFBA0rymBpPPV51hTgPTQ4e8ipnW1D6/Cht21B OfTCFtCaf5Ki+A2TF6DsQpnKO6J519PH4rVZWPbO/GHU4AekDbyIRLpLtpbOM4yDVWC2 Ixkw== X-Gm-Message-State: AIVw112iDcW8m5BCbE/uC0XNk5hFrmhuh/3IT6VrRyUvfOBeyRP796qm titacv+qBItWcH4eIZyyyGT0vph/9gC85Rs= X-Received: by 10.176.18.231 with SMTP id o39mr2075933uac.58.1501862559797; Fri, 04 Aug 2017 09:02:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.74 with HTTP; Fri, 4 Aug 2017 09:02:39 -0700 (PDT) In-Reply-To: <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> From: Matthew Pounsett Date: Fri, 4 Aug 2017 12:02:39 -0400 Message-ID: To: dcrocker@bbiw.net Cc: dnsop Content-Type: multipart/alternative; boundary="f4030436146c6147490555efa0f0" Archived-At: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 16:02:48 -0000 --f4030436146c6147490555efa0f0 Content-Type: text/plain; charset="UTF-8" On 3 August 2017 at 18:36, Dave Crocker wrote: > > > Therefore I propose to: > > 1. Have this document define the simple, sole, authoritative mechanism > for registering "top-level" (global scope) underscore names. > > 2. Create a separate document that specifies modifications to the SRV > and URI documents, rationalizing the use of underscore names, through the > mechanism defined in -attrleaf-. > > Do I understand correctly that the intent is to obsolete existing underscore registries (whether they be actual IANA registries, or just code points listed in a draft) and move their data to a new, central registry? This seems sensible to me. --f4030436146c6147490555efa0f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 3 August 2017 at 18:36, Dave Crocker <dhc2@dcrocker.net> wrote:


Therefore I propose to:

=C2=A0 =C2=A01. Have this document define the simple, sole, authoritative m= echanism for registering "top-level" (global scope) underscore na= mes.

=C2=A0 =C2=A02. Create a separate document that specifies modifications to = the SRV and URI documents, rationalizing the use of underscore names, throu= gh the mechanism defined in -attrleaf-.

Do I under= stand correctly that the intent is to obsolete existing underscore registri= es (whether they be actual IANA registries, or just code points listed in a= draft) and move their data to a new, central registry? =C2=A0 This seems s= ensible to me.

=C2=A0

--f4030436146c6147490555efa0f0-- From nobody Fri Aug 4 09:52:54 2017 Return-Path: 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 9E8AA1323A3 for ; Fri, 4 Aug 2017 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net 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 jUQDNbalZjxw for ; Fri, 4 Aug 2017 09:52:51 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 99BE0132377 for ; Fri, 4 Aug 2017 09:52:51 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v74GrGKP017809 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 4 Aug 2017 09:53:17 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1501865597; bh=CpYQx0ebSvRy5u7mUcqKdo2mdDV33183rbUKEs89Es4=; h=Subject:To:Cc:References:Reply-To:From:Date:In-Reply-To:From; b=DgJZA3MDl3coyC7rM+Oven2au6u3gssolpGTykNwQhi23fKWspfAV+yxWVkh6cRD6 UraA3YPRww2cL2TRzSPwq7H3eJqVN02DjBatNCM+x1ok65ZfTQxzRe30j2X3+BH/H7 M7aWEVyheI87zm/Y4ABALMx4mT2/v0Uf1bSSaKAc= To: Matthew Pounsett Cc: dnsop References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> Reply-To: dcrocker@bbiw.net From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Fri, 4 Aug 2017 09:52:43 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 16:52:52 -0000 On 8/4/2017 9:02 AM, Matthew Pounsett wrote: > Do I understand correctly that the intent is to obsolete existing > underscore registries (whether they be actual IANA registries, or just > code points listed in a draft) and move their data to a new, central > registry? This seems sensible to me. Arguably, there aren't any underscore registries. There are some specs that allocate underscore names, but a 'registery' per se is not specified anywhere. That's the motivation for the current draft. SRV does registration-by-inheritance, but that overloads one registry semantic with another. So I'll take the liberty of rephrasing what you describe as: Obsolete the existing inheritance registrations and create explicit registrations for the currently-inherited names in use. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Fri Aug 4 09:53:35 2017 Return-Path: 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 730DF132353 for ; Fri, 4 Aug 2017 09:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 ykavl3akUJgP for ; Fri, 4 Aug 2017 09:53:30 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEEB132055 for ; Fri, 4 Aug 2017 09:53:30 -0700 (PDT) Received: from [46.227.151.81] (port=57605 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1ddfqo-0001Kj-FE (Exim 4.72) for dnsop@ietf.org (return-path ); Fri, 04 Aug 2017 17:53:26 +0100 To: dnsop@ietf.org References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> From: Ray Bellis Message-ID: <05b40bc8-7b7e-782f-12fd-db719460d7c1@bellis.me.uk> Date: Fri, 4 Aug 2017 17:53:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 16:53:33 -0000 On 04/08/2017 17:02, Matthew Pounsett wrote: > Do I understand correctly that the intent is to obsolete existing > underscore registries (whether they be actual IANA registries, or just > code points listed in a draft) and move their data to a new, central > registry? This seems sensible to me. I agree that it's sensible for those underscore labels that appear rightmost in a string of one or more such labels, e.g. the _udp label of an SRV record owner-name, but not the _proto that precedes it. Ray From nobody Fri Aug 4 10:26:20 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA6813235E; Fri, 4 Aug 2017 10:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnsop@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150186757812.18701.18018746262963813562@ietfa.amsl.com> Date: Fri, 04 Aug 2017 10:26:18 -0700 Archived-At: Subject: [DNSOP] I-D Action: draft-ietf-dnsop-sutld-ps-08.txt X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 17:26:18 -0000 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. Title : Special-Use Domain Names Problem Statement Authors : Ted Lemon Ralph Droms Warren Kumari Filename : draft-ietf-dnsop-sutld-ps-08.txt Pages : 29 Date : 2017-08-04 Abstract: The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-sutld-ps-08 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-sutld-ps-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-sutld-ps-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 4 12:55:15 2017 Return-Path: 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 9917E126BF3 for ; Fri, 4 Aug 2017 12:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 8h4s0zj7LEJ9 for ; Fri, 4 Aug 2017 12:55:11 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A065C131EB6 for ; Fri, 4 Aug 2017 12:55:11 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id w45so11461051uac.5 for ; Fri, 04 Aug 2017 12:55:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=HheDTDnrE02HLJUxRo85Sz9W2jw+K4UVuDFWGJsQijI=; b=XOyqVwRJoFhLx/z1LyrmsaXFZkAQR5SqLiV6s+UwxV9w7aZT24wWc3IJKVDwl/TfEd i1M0PiO90BRyDE7DE4aCm4MFLdCdtXUCb/ylYfxh0PUY1YzW6N38rBimH66R7k9116BX 6bzpVJyrwXpEapsYWHH2RmlgAItkbLV9fWhVdZdFILem/EvLwTQWwfvyZHMoBDPVQ2hD EzNbjXrg//Tn2EPOXaTwaBAbrNE3ajw7BJ5OYfiTdkhOx8tu7EBjQQ0+Echmr9iDyldW LcheQga6bKfO7hBsb/yFN5deJXtEDLes3s+Y0ZSUOMV4IFGF1QP+zlfz+E5gSoLmLuiW V3iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=HheDTDnrE02HLJUxRo85Sz9W2jw+K4UVuDFWGJsQijI=; b=Vpbbv3KqhFAA5bFho7vRXCW+DSbcxflneU3YwBXgIdOj9GMDYk7pRyUxfh37dwnhTW k06f6/mLL9Qmt7n+Z6o0Ne8O/f5Pz1fbiUQXtS70bVArBSdCanRB+8XIQWEkqc77Ccsi gToInp/KJxOxg1zxLnNlrrphMWs4kTumse5Ga/pwmJzQlq7SQoDdpvqsXPbj4eW4sQB+ S/aM3KBJB7imuMaqnoFc9PiyifNtIHTNx6KVUzimm5LFhCQu4gRmVMNQB3KbhOKj3LBd qpdULwRyqUm1Qembn70yLwEMIj1ZT15byx8PldWG1cEk8xqNjUY9DzqSi9eY6Zf4gAvl dFfw== X-Gm-Message-State: AHYfb5hseKbhrTxBb/1svWEsBV/KzLlEiRKgom4iLwU6RRpGxs40H/AJ fEMWzb9d1Dg856P9xhZuT+tlZ8ZSwEsM X-Received: by 10.176.18.71 with SMTP id s7mr2607871uac.127.1501876510627; Fri, 04 Aug 2017 12:55:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.9.231 with HTTP; Fri, 4 Aug 2017 12:54:30 -0700 (PDT) In-Reply-To: <6e0e2e92-6c06-38cf-16d9-a78ddfbaaed6@cesnet.cz> References: <20170623105434.22478B810AB@rfc-editor.org> <9284fde5-ea75-a25a-3aa1-2e521753dc3e@cesnet.cz> <519c2cb0-0239-e28f-e4e8-6dcb13459d3d@pletterpet.nl> <20170627145452.623CB7C84E77@rock.dv.isc.org> <20170628042127.863D87CA0CFF@rock.dv.isc.org> <6e0e2e92-6c06-38cf-16d9-a78ddfbaaed6@cesnet.cz> From: Warren Kumari Date: Fri, 4 Aug 2017 15:54:30 -0400 Message-ID: To: =?UTF-8?Q?Ond=C5=99ej_Caletka?= Cc: Mark Andrews , Dick Franks , tjw ietf , Matthijs Mekking , =?UTF-8?B?SmFuIFbEjWVsw6Fr?= , =?UTF-8?B?SmFyb23DrXIgVGFsw63FmQ==?= , IETF DNSOP WG , Suzanne Woolf , Paul Wouters , Benoit Claise , =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= , Olafur Gudmundsson , RFC Editor Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049) X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 19:55:14 -0000 Hi all, I gave this discussion some time to converge[0], and also asked for more comments during the (2nd) DNSOP session in Prague. Unless I hear strong objections by Wednesday I'll mark the errata as verified (with the minor clarification provided): Strictly speaking, the CDS record could be "CDS X 0 X X" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 00" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 AA=3D=3D"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. W [0]: Yeah, that sounds much better than "procrastinated" :-) On Wed, Jun 28, 2017 at 7:27 AM, Ond=C5=99ej Caletka wrote: > Hello, > >>Dick Franks: >>> What is needed now is methodical use-case analysis based on RFC8078 as = it >>> exists now and tested against a real implementation. The time to rewri= te >>> the RFC will come if/when we discover we are unable to live with it. We >>> have not reached that point yet. > Mark Andrews: >> I can't go from RFC8078 to a working implementation because the >> existing description is not clear enough to do it. I don't think >> anyone can do it. >> >> With the proposed errata fix I could write code. For CDS the RRset >> is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00. For CDNSKEY >> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00. > > I have a confirmation from the real implementation of RFC8078 in the .CZ > domain registry (cc jaromir.talir) that their understanding of CDNSKEY > DELETE operation is exactly the set of RDATA quoted by Mark Andrews, > which translates to the presentation form CDNSKEY 0 3 0 AA=3D=3D > > I don't think there is a big room to interpret RFC 8078 differently, > since it does not define any new presentation/wire format for > CDS/CDNSKEY record. Therefore, even future versions of software that > (de-)serializes RRs between wire and presentation format will have > issues if there are not all fields mandated by RFC 4034 present in the > rdata. > > -- > Ond=C5=99ej Caletka > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 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 nobody Fri Aug 4 15:08:32 2017 Return-Path: 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 112791276AF for ; Fri, 4 Aug 2017 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] 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 1PTEH5g8oTh1 for ; Fri, 4 Aug 2017 15:08:29 -0700 (PDT) Received: from mail.hardakers.net (unknown [168.150.236.43]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C29012708C for ; Fri, 4 Aug 2017 15:08:29 -0700 (PDT) Received: from localhost (50-1-20-198.dsl.static.fusionbroadband.com [50.1.20.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 0351A2778E; Fri, 4 Aug 2017 15:08:26 -0700 (PDT) From: Wes Hardaker To: Matthijs Mekking Cc: dnsop@ietf.org References: <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> Date: Fri, 04 Aug 2017 15:08:25 -0700 In-Reply-To: <7d425067-84ff-2471-d39a-0c3a20c0116c@pletterpet.nl> (Matthijs Mekking's message of "Thu, 20 Jul 2017 14:34:56 +0200") Message-ID: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] requesting WGLC for 5011-security-considerations X-BeenThere: dnsop@ietf.org 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: Fri, 04 Aug 2017 22:08:31 -0000 Matthijs Mekking writes: > It's been a while since I have had a look at this draft, my apologies. No worries; I'm due to publish the copy that is sitting on my disk with updates to the math. So *my* apologies in return. (and the update should be a bit easier to read too) I'll review your math proposal before publishing. I'm not sure we agree with your analysis yet, but will consider it carefully. > Furthermore, this document should also give guidance on the wait time > before a revoked DNSKEY can be removed from the zone: (which is also in the unpublished update) > This document should probably update RFC 7583 because it is giving a > better definition of Itrp and Irev. Probably true too. Thanks for pointing that out. I'll be honest, I've always had a hard time reading 7583 because the acronyms fly fast a furious and it's hard to remember which is which. -- Wes Hardaker USC/ISI From nobody Sat Aug 5 14:01:44 2017 Return-Path: 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 2C930131F1A for ; Sat, 5 Aug 2017 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 odxCeG2U4-sR for ; Sat, 5 Aug 2017 14:01:41 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06B38131F21 for ; Sat, 5 Aug 2017 14:01:40 -0700 (PDT) Received: (qmail 53395 invoked from network); 5 Aug 2017 21:01:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 5 Aug 2017 21:01:39 -0000 Date: 5 Aug 2017 21:01:17 -0000 Message-ID: <20170805210117.1123.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: matt@conundrum.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 05 Aug 2017 21:01:43 -0000 In article you write: >In the case where 'localhost' is being passed to DNS resolution software, a >validating stub (for example inside a web browser) needs a way to know that >the 'localhost' TLD should be treated as insecure. In that case, the only >way to accomplish that is ... ... by having the stub or cache treat localhost as a special case. I use unbound as my cache which as far as I know has always done that. Are there caches that don't? Are there validating stubs that don't? My reading of this draft is that if you don't treat localhost as a special case already, it's time to get with the program. R's, John > with an insecure delegation at the root. From nobody Sat Aug 5 17:34:15 2017 Return-Path: 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 02EB6124B18 for ; Sat, 5 Aug 2017 17:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 yJfYq0PwLg9t for ; Sat, 5 Aug 2017 17:34:11 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF6A1243F6 for ; Sat, 5 Aug 2017 17:34:11 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o9so16368340iod.1 for ; Sat, 05 Aug 2017 17:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vxtJn5y/YcnSzLsvfXUzzdGzHxNbvsbfY5elzEHb9HI=; b=JtvHtyYuY4T/Da11FbFHd8OWsKpue2L8CFwBnWaC3RHCPcp+QXp00otfFlh9aXPjTW cZPfAhQKTAzE4gY/yV2zH7t8dLIfIilUTbYHchU9/ccN8EMnaJrFSw/Tx6vXQMN4tlMq Cm8aMF1FabVrAONoBrLRydZJgBREoc65hEDTz1wI1LdGE8Ghb0+iM4V26QbhSgbWSh5U w7meDL/39wg0SwRaFythJfb5GFlHCUOGhkZo0suX+ne9cVRU/7e+C7Zsxh/2B88oO90j aB9b1mWiG0UHhvL1HTFkX184p84aoJXDwV9l7l+TP/5twtTkfzO0Qf6tyqT18Rv5daDg 0wGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vxtJn5y/YcnSzLsvfXUzzdGzHxNbvsbfY5elzEHb9HI=; b=WWr5htMzFwgW3PfO96kH8QG8NKbHYCJ65oTOK9HQ3ngVTbpUaCdfiVxsx9/kTj3JNB FsSskMxkW6vK3rjsRtfBDJAybVx4vSUmsgByc/8h5Y8iGda+lwE+sdg6drYM+YkM9dEX KNAY3uoMS6zUQK1IrQXzr3/ZcsaQNZ0frLAAsci+EWPVIu8OBy3YdG+0Ad2k5N2Dg5tr byS0yAnyeuK2f2jI22dyV6EA4+brADBv21EhLsv2QSLrA3xSjmFzKoTsN39NZo++VSwi DekVTgbTdP63/KzzywEiWuYPzxpPFRAuOhmldgfmERMPeBL0HRk5kU14NioBTgTy9xpd Q+fg== X-Gm-Message-State: AHYfb5gMM5WY/k4CsHtLWtffHnPJt2lNn6F4kDSp6GJTuw1dPq/oi/WR +y2N4j387PgMvlTi3/TfR8u/0DCXnA== X-Received: by 10.107.183.139 with SMTP id h133mr7246480iof.125.1501979650621; Sat, 05 Aug 2017 17:34:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.59.9 with HTTP; Sat, 5 Aug 2017 17:34:09 -0700 (PDT) In-Reply-To: References: <20170805210117.1123.qmail@ary.lan> From: william manning Date: Sat, 5 Aug 2017 17:34:09 -0700 Message-ID: To: dnsop Content-Type: multipart/alternative; boundary="94eb2c0ba18289056e05560ae314" Archived-At: Subject: [DNSOP] Fwd: Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sun, 06 Aug 2017 00:34:14 -0000 --94eb2c0ba18289056e05560ae314 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message ---------- From: william manning Date: Sat, Aug 5, 2017 at 5:33 PM Subject: Re: [DNSOP] Status of "let localhost be localhost"? To: John Levine i think the question hinges on zone completion logic and fully qualified domain names. when localhost appears as: localhost IN AAAA 3ffe:53::53 without the trailing dot, zone completion logic should ensure that it is NOT treated as a TLD. whereas if I code this: localhost. IN AAAA 3ffe:53::53 that is a clear indication that I am running my own root zone and defining my own view of the DNS namespace for class IN. Shouldn't apps depend on the DNS to serve trustworthy, correct, data? /Wm On Sat, Aug 5, 2017 at 2:01 PM, John Levine wrote: > In article gmail.com> you write: > >In the case where 'localhost' is being passed to DNS resolution software, > a > >validating stub (for example inside a web browser) needs a way to know > that > >the 'localhost' TLD should be treated as insecure. In that case, the only > >way to accomplish that is ... > > ... by having the stub or cache treat localhost as a special case. > > I use unbound as my cache which as far as I know has always done that. > Are there caches that don't? Are there validating stubs that don't? > > My reading of this draft is that if you don't treat localhost as a > special case already, it's time to get with the program. > > R's, > John > > > with an insecure delegation at the root. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c0ba18289056e05560ae314 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

---------- Forwarded messag= e ----------
From: william manning <chinese.apr= icot@gmail.com>
Date: Sat, Aug 5, 2017 at 5:33 PM
Subje= ct: Re: [DNSOP] Status of "let localhost be localhost"?
To: Jo= hn Levine <johnl@taugh.com>

i think the question hinges on zone completion lo= gic and fully qualified domain names.

when localhost app= ears as:

localhost =C2=A0 IN =C2=A0AAAA =C2=A0 3ff= e:53::53

without the trailing dot, zone completion= logic should ensure that it is NOT treated as a TLD.
whereas if = I code this:

localhost.=C2=A0 IN AAAA =C2=A03ffe:5= 3::53

that is a clear indication that I am running= my own root zone and defining my own view of the DNS namespace for class I= N. =C2=A0 Shouldn't apps depend on the DNS to serve trustworthy, correc= t, data?

/Wm
=

On Sat, Aug 5, 20= 17 at 2:01 PM, John Levine <johnl@taugh.com> wrote:
In article <CAAiTEH9=3DRNDrUmSOs8Rg2Ea4+as= 9pg=3Dj5jnU6Y=3Dnc8A4Z1aPog@mail.gmail.com> you write:
>In the case where 'localhost' is being passed to DNS resolution= software, a
>validating stub (for example inside a web browser) needs a way to know = that
>the 'localhost' TLD should be treated as insecure.=C2=A0 In tha= t case, the only
>way to accomplish that is ...

=C2=A0... by having the stub or cache treat localhost as a special case.
I use unbound as my cache which as far as I know has always done that.
Are there caches that don't?=C2=A0 Are there validating stubs that don&= #39;t?

My reading of this draft is that if you don't treat localhost as a
special case already, it's time to get with the program.

R's,
John

> with an insecure delegation at the root.

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


--94eb2c0ba18289056e05560ae314-- From nobody Mon Aug 7 00:55:15 2017 Return-Path: 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 E347E1288B8 for ; Mon, 7 Aug 2017 00:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 LY1fxRrJuF3P for ; Mon, 7 Aug 2017 00:55:11 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 A4219131EA2 for ; Mon, 7 Aug 2017 00:55:10 -0700 (PDT) Received: from [192.168.1.43] (unknown [77.236.194.38]) by mail.nic.cz (Postfix) with ESMTPSA id 8DC96623AB for ; Mon, 7 Aug 2017 09:55:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502092508; bh=L35/a+MgDP4rPNpz3WS2Ehm/2ZQtbmmTifEMEx4W8Sg=; h=To:From:Date; b=EZxohFNX6kcbw6Sd875FY1rU/zXrULwKsoN/k/Uj9YDi1hR23GU47kcUM9kToOUfP 9hFxkqBFc8Ee8gmmqwE9OQWf3pGTIAb2wP8pm3EJWBlA04XcR3SLyooFav19s7X2UB 4D53ucxVijFtxxg4ReaI9RrSjyMeeYmodd7zmOCw= To: dnsop@ietf.org References: <9002F172-4171-41EE-A0FF-61C7A5ACAD32@hopcount.ca> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <51680877-0843-c069-863a-85cf97990530@nic.cz> Date: Mon, 7 Aug 2017 09:55:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] =?utf-8?q?draft-ietf-dnsop-refuse-any=3A_points_from_Pet?= =?utf-8?b?ciDFoHBhxI1law==?= X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 07:55:14 -0000 On 26.7.2017 12:56, Tony Finch wrote: > Joe Abley wrote: >> >> If anybody else here has thoughts about specific text or violent >> objections to including QTYPE=RRSIG in general, please let me know (I >> looked in the mail archive but couldn't find any there). > > I think it's helpful to mention RRSIG explicitly since it isn't > immediately obvious that it's a stealth ANY query. (It becomes > apparent to implementers fairly rapidly tho!) > >> As we discuss (see Stephane's points) in the case of multiple >> transports, perhaps we can also recommend that implementors provide >> configuration options to allow administrators to deal with ANY, RRSIG, >> neither or both. That way we get flexibility that matches deployment, >> but we also get a reference for handling RRSIG in a predictable way. > > I think the draft should recommend a simple on/off switch and describe > sensible behaviour when it is on. Mainly because I think we know what > that sensible behaviour is, and I don't think it's a big enough feature > to deserve a lot of configuration and documentation complexity. I agree with Tony that we know what that sensible behaviour is so, with my implementor hat on, I would be perfectly happy with implementation-specific behavior with no knobs at all. If you don't like it, feel free to pick another implementation. Petr Špaček @ CZ.NIC > > Having said that, the initiator side (section 5) needs a bit of work. > Something like, > > ANY queries SHOULD be sent using the same choice of transport as other > queries (typically, try UDP first, and only use TCP if the response is > truncated). As an exception, debugging and diagnostics tools MAY have > a special case for ANY queries. > > (bleeding-edge versions of `dig` use TCP for ANY) > > Tony. From nobody Mon Aug 7 01:41:44 2017 Return-Path: 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 CEB5713218E for ; Mon, 7 Aug 2017 01:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 leSUZDIZo7V7 for ; Mon, 7 Aug 2017 01:41:40 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C7613218D for ; Mon, 7 Aug 2017 01:41:40 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x3so59939287oia.1 for ; Mon, 07 Aug 2017 01:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2GphdkdW/ftm7iXUrKrPoj38S/FowSwPpNfY+Yqqu24=; b=RNCn0lEKWA3ARszbhqlr9NtIBVNqli/XCnECnuKG3VZVvGU94T8GcFmkxd8WXDaTLk ac7lO+7lZAIRr+LXOjSkRkhj1ZkeIwhyH0Ye+oGU56S9u0Dc5XqxQ1N+t/NIR4bfQWVT graVqY1nqO3k99ORPkiPsSIfU9s1I/KOsmatfBv2ocLq2TB55k2CSMNN1yYLPpxbEFDf Xn0610GaAX+2IkwfbP9keIITNO57cBolzQOlCnl8a4pM+IGz6KF7V+XrLGL8klTHVp0o GpSFZfaxLl8aVLbggPSxB3t7Uz5OqsjVyR1QZCYcLebm+ijSnPEz2bhukN86gcWfXZWG DyMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2GphdkdW/ftm7iXUrKrPoj38S/FowSwPpNfY+Yqqu24=; b=hD74lsdWjhl/xyZRzpiqRU0z0iodkb7dAGrt91FiK1G8ge4Q1n7geiB0OUaA6tpsfy 5Penw7Zlpnc2I4aeqahw4HwV1+9rABmU9wi2Z+RHxU6PjpCa8ckecYSxJq/TaP5KLw8P bFPbM1Nht//iEbOpAzjMKWQJz4mGHTaf4CK/s4kKglaHsSRMYISFQPlbGlG81RamFZMf 0obAMhjTSWU32vuE9Fjb0x4OhuteNRE8Wpxgl1Y5NhZN4WREh43FlwRStRpfcjB2QC+0 30WSaMaz9XoKuvDwY8wc7ZLgJdF6mxJw6Sam6ThrvWW9zMOEbkEyWqOsByeqNqABgSZa LC9A== X-Gm-Message-State: AHYfb5gjX0ORNyS3BfWT53A0nN0cjUxyPi1P34m+7aGydfkc4p+wzVk0 eKcRc6e3esfhMLGb2eGs6ur/J2PHIeskv6w= X-Received: by 10.202.102.25 with SMTP id a25mr6146866oic.296.1502095299326; Mon, 07 Aug 2017 01:41:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.47.5 with HTTP; Mon, 7 Aug 2017 01:41:18 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> From: Mike West Date: Mon, 7 Aug 2017 10:41:18 +0200 Message-ID: To: dnsop WG Cc: Joe Abley , Jacob Hoffman-Andrews , Richard Barnes Content-Type: multipart/alternative; boundary="001a114091a8bcd0c8055625d0db" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 08:41:43 -0000 --001a114091a8bcd0c8055625d0db Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 3:44 PM, Mike West wrote: > On Wed, Aug 2, 2017 at 3:38 PM, Richard Barnes wrote: > >> It seems like the desired behavior for the DNS infrastructure here is the >> same as for .onion -- return NXDOMAIN. After all, these are queries that >> should never leave the end host, so anything not on the host should handle >> them as an error. >> >> cf. https://tools.ietf.org/html/rfc7686#section-2 >> > > I'm pretty sure this is what the draft we're discussing attempts to do. > See #2 under https://tools.ietf.org/html/draft-west-let-localhost-b > e-localhost-03#section-3. It could be more explicit about the response, > however... I can address that in a -04 if folks agree with the approach. > > (I also wonder whether it would be a better idea to reframe this draft as > something akin to the "onion" RFC: that is, defining the behavior as a > stand-alone document rather than monkey-patching RFC 6761.) > I poked at the draft a bit over the weekend, reworking it into a stand-alone document in https://tools.ietf.org/html/ draft-west-let-localhost-be-localhost-04. I think it ends up being clearer overall, and hopefully y'all agree. Regarding the outstanding question of DNSSEC and insecure delegations, this new draft takes the same approach as the ".onion" RFC, as Richard suggested. I'm willing to run with whatever the group agrees upon on this point, but this seems like a reasonable approach that's both simple to explain and consistent with existing recommendations. Feedback on that new draft would be very welcome indeed! -mike --001a114091a8bcd0c8055625d0db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 2, 2017 at 3:44 PM, Mike West <mkwst@google.com> wrot= e:
=

I'm pretty sure this is what the draft we= 9;re discussing attempts to do. See #2 under=C2=A0https://tools.ietf.org/html/draft-west-let-localhost-be-= localhost-03#section-3. It could be more explicit about the response, h= owever... I can address that in a -04 if folks agree with the approach.

(I also wonder whether it would be a better idea to r= eframe this draft as something akin to the "onion" RFC: that is, = defining the behavior as a stand-alone document rather than monkey-patching= RFC 6761.)

I poked= at the draft a bit over the weekend, reworking it into a stand-alone docum= ent in=C2=A0https://tools.ietf.org/html/draft-= west-let-localhost-be-localhost-04. I think it ends up being clear= er overall, and hopefully y'all agree.

Regardi= ng the outstanding question of DNSSEC and insecure delegations, this new dr= aft takes the same approach as the ".onion" RFC, as Richard sugge= sted. I'm willing to run with whatever the group agrees upon on this po= int, but this seems like a reasonable approach that's both simple to ex= plain and consistent with existing recommendations.

Feedback on that new draft would be very welcome indeed!

-mike
--001a114091a8bcd0c8055625d0db-- From nobody Mon Aug 7 03:52:25 2017 Return-Path: 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 B0A9A13219C for ; Mon, 7 Aug 2017 03:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 jfpN91cFXl93 for ; Mon, 7 Aug 2017 03:52:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 90A061320B5 for ; Mon, 7 Aug 2017 03:52:18 -0700 (PDT) Received: from [192.168.1.76] (unknown [77.236.194.38]) by mail.nic.cz (Postfix) with ESMTPSA id D4BCF622A7 for ; Mon, 7 Aug 2017 12:52:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502103136; bh=rIVldHMtyESKRSyUtsOfa4w5o3/VNCtYdNx3kI+coNE=; h=To:From:Date; b=WzWkZqaMMPqg27YZnea3M9BItuabAW090bgM2nANzBjQdEdISiprbbzJxvBgeeXUJ oc31co4hUVcfYGxSEGWvNlzvVeO4xvRRPMxvAeXBeRHyDhiJAztV6qtzjvW5Ysd74n ugyzPVQuBz9g0VDCkT8jM9LSXaJXcLDbenA28yuw= To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <52fe314c-7dfa-150c-a6aa-463776e9106d@nic.cz> Date: Mon, 7 Aug 2017 12:52:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 10:52:23 -0000 On 2.8.2017 16:56, Edward Lewis wrote: > On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" wrote: > >> ... >> I'm happy with error codes that are informational, but don't change client behavior. Yes, I realize that users may be tricked, but that's also the case today, right? > > If a receiver can't trust what it gets from the network, you can't run a protocol. Dead in the water. > > No matter what, what a receiver does next will depend on what it gets from the network (or doesn't get/timeout). That happens now, in an unmanaged way. IMHO, it would be good to address that (the reactions, as opposed to elaborating on the error). > > If you are worried about having trustable error codes, think of a way to secure the channel (like TSIG). If you are worried and can't secure the channel, then it doesn't matter whether RCODES are extended or not - you have nothing trustable to act upon. (See: dead in the water.) > > Once you have faith that there's usefulness in the error/response code you do receive, then you can design what the reaction is. (If you are worried, you need to do what is necessary to build the faith or this will not be solvable.) > > I sent a long message urging that the response indicate the next step, not so much indicating what went bad. I won't belabor that - my motivation comes from the observation that many folks are used to "debugging" DNS via query/resposnse as they are not the authorized operator of the answering system. Extending RCODEs should be about solving the protocol's needs, not about preserving the ability of remote debugging of servers, leave that to the authorized operator. I very much agree with Edward! To be more specific, I think we should aim for set of information which helps the user to to decide who to contact: a) contact local support / fix his local system (e.g. system time is likely off and validation fails for this reason) b) contact ISP support (e.g. local forwading cache is not able to contact recursor) c) contact domain owner, e.g. bank (e.g. all the NSes are timing out) -- Petr Špaček @ CZ.NIC From nobody Mon Aug 7 04:14:28 2017 Return-Path: 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 459C51321A0 for ; Mon, 7 Aug 2017 04:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 lS_sHanxvd40 for ; Mon, 7 Aug 2017 04:14:25 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 012B113219C for ; Mon, 7 Aug 2017 04:14:25 -0700 (PDT) Received: from [46.227.151.81] (port=54459 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1defzK-0004Sx-B0 (Exim 4.72) for dnsop@ietf.org (return-path ); Mon, 07 Aug 2017 12:14:22 +0100 To: dnsop From: Ray Bellis Message-ID: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> Date: Mon, 7 Aug 2017 12:14:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 11:14:27 -0000 Having looked at this a few months ago when one of our partners was (briefly) returning NOTIMP for ANY queries, I find myself wondering why this isn't discussed in the draft? The draft does talk about *new* RCODEs, but not existing ones. My reading of RFC 1035 is that it would be a perfectly appropriate response from a server that doesn't support ANY. Unfortunately the retry semantics of DNS are not well specified and therefore implementation differences may occur. If as a result NOTIMP is really not usable then IMHO this should also be documented. Ray From nobody Mon Aug 7 05:38:18 2017 Return-Path: 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 7D185129A92 for ; Mon, 7 Aug 2017 05:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 oMq2g9se48JG for ; Mon, 7 Aug 2017 05:38:15 -0700 (PDT) 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 3EC22127ABE for ; Mon, 7 Aug 2017 05:38:14 -0700 (PDT) Received: from [192.168.1.76] (unknown [77.236.194.38]) by mail.nic.cz (Postfix) with ESMTPSA id ECA566245E for ; Mon, 7 Aug 2017 14:38:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502109492; bh=eJz3FTsustWnWNbBqlSuMbKyYqKIJSW10t/Ed228cF8=; h=To:From:Date; b=Rmd/IvHR/D1TQHsABCNHHakx5s5RKRMAiSp0LILFvuSfneTbm40uAhakkvjlwnruK 7jXLrJXvAGZx9TJ2K2C+YMEqNtziTo9kCjFTYAUt0bF4VMadynrR+vRNp7v51qr6Uk Bri0BJdJmYRbCdASqZjzk7OJgvIkb/vbshmpPnaM= To: dnsop@ietf.org References: <150040947342.11401.6673996996138598307.idtracker@ietfa.amsl.com> <3E029203-62B9-43ED-992C-CBF4A33156EC@powerdns.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <76a859a5-b7b8-6609-7bc9-d1fe50fd7a58@nic.cz> Date: Mon, 7 Aug 2017 14:38:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] The DNSOP WG has placed draft-woodworth-bulk-rr in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 12:38:17 -0000 On 24.7.2017 15:43, Tony Finch wrote: > Peter van Dijk wrote: >> >> One could make $GENERATE more efficient without actually implementing >> the BULK RR, by taking your pattern matching logic and implementing it >> inside the name server. > > Andrew Sullivan was right to say that there is an advantage to having BULK > as an RR compared to the $GENERATE master file directive, because an RR > makes it easier to interoperate across multiple providers in a > multi-master DNS setup. > > I guess a BULK that is just a standardized version of $GENERATE (with > multi-master-only online signing when there's an unfeasible number of > generated records) isn't a completely terrible idea, though it's a lot > less complicated than the current draft. I agree that a BULK version simplified to bare bones (auth side only) might closer to acceptable. Still, it will not solve interoperability problem because we would need a mechanism to transfer signing keys along the BULK RR. > I'd still like to see lots more specific examples of how it could be used > other than for v6 reverse DNS. Yes please, use-cases would be very welcome. Right now it seems like *a lot* of complexity which is in my eyes not justified. Thank you for understanding. -- Petr Špaček @ CZ.NIC From nobody Mon Aug 7 08:44:22 2017 Return-Path: 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 9ADFE132443 for ; Mon, 7 Aug 2017 08:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com 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 s9Nye5hmMM-x for ; Mon, 7 Aug 2017 08:44:13 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8C1D132420 for ; Mon, 7 Aug 2017 08:44:12 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id p3so4919219qtg.2 for ; Mon, 07 Aug 2017 08:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QpGknPU0TwrsMWILduWUzD545VgfeZlOUD4ZyFKfV8U=; b=JpP2ljMpO1iaAsagwU8//eSduwQ1qEimYLiD0dEhFnzGP7Afn3TDaBVwgO9KgYEZvD AnVrinp2z2LNhr6taQzD4bYEFOvxOludFoiSLF1tuKEz07iy7RkLEFu9OYc3g8ZO9+60 BjtUctFRPToIiGJK3cxz3tPeHJACfBkN/ycvU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QpGknPU0TwrsMWILduWUzD545VgfeZlOUD4ZyFKfV8U=; b=S0SVXSuC46bl8tM8JSHQG8wyxV7xl/g9je3tLvTtDx2W9x8Jg+gAwWmpkL0UFedbQM 8dCex5s+H0/5E4Qny5jv/isiLLtWQOyqKVKW/hQ0ypGTTxidl7dL5+DctE7meF/w0Ybb bzHwbQmcdQkzli6RxCZIn3B/9ZqVPDI7oQ8jy6+InsPSMsEvBe8j0vquVD8g6mxrLzvS FZMIkWyRjV6oTfA1+rn325rtIeAOuvw4SLXvZ0hZ5uFrqelXe/M9pTkdspnEcLje5Gub LE32hFruFgBZZrAGzPzPCZzlQoF3uoGbXBUljvyINOKCuPOKGTi5s65LQh6FmJfURpjO 1NeQ== X-Gm-Message-State: AHYfb5iwxrmRm99l8RamkuHPZfdq2k/D9jjubYhk769OKMrChK13jyvx 8LHR6ItmWqFwa6Qg0Na8AoXuHIw9Ox5xBVg= X-Received: by 10.200.36.80 with SMTP id d16mr1447252qtd.281.1502120651781; Mon, 07 Aug 2017 08:44:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.88.228 with HTTP; Mon, 7 Aug 2017 08:44:11 -0700 (PDT) In-Reply-To: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> References: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Mon, 7 Aug 2017 11:44:11 -0400 Message-ID: To: Ray Bellis Cc: dnsop Content-Type: multipart/alternative; boundary="001a113c862edc0bec05562bb785" Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 15:44:15 -0000 --001a113c862edc0bec05562bb785 Content-Type: text/plain; charset="UTF-8" This was the original proposal, the drawback is that resolvers to not cache the answer, and to make things worse they ask ALL NS addresses for listed domain thus it acts as a DDoS against the domain in question. Olafur On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis wrote: > Having looked at this a few months ago when one of our partners was > (briefly) returning NOTIMP for ANY queries, I find myself wondering why > this isn't discussed in the draft? > > The draft does talk about *new* RCODEs, but not existing ones. > > My reading of RFC 1035 is that it would be a perfectly appropriate > response from a server that doesn't support ANY. > > Unfortunately the retry semantics of DNS are not well specified and > therefore implementation differences may occur. If as a result NOTIMP > is really not usable then IMHO this should also be documented. > > Ray > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a113c862edc0bec05562bb785 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

This was the original proposal,=C2=A0
t= he drawback is that resolvers to not cache the answer, and to make things w= orse they ask ALL NS addresses for listed domain=C2=A0
thus it ac= ts as a DDoS against the domain in question.=C2=A0

Olafur


On Mon, Aug 7, 2017 at 7:14 AM, Ray Bellis <ray@bellis.me.= uk> wrote:
Having looked at= this a few months ago when one of our partners was
(briefly) returning NOTIMP for ANY queries, I find myself wondering why
this isn't discussed in the draft?

The draft does talk about *new* RCODEs, but not existing ones.

My reading of RFC 1035 is that it would be a perfectly appropriate
response from a server that doesn't support ANY.

Unfortunately the retry semantics of DNS are not well specified and
therefore implementation differences may occur.=C2=A0 If as a result NOTIMP=
is really not usable then IMHO this should also be documented.

Ray

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

--001a113c862edc0bec05562bb785-- From nobody Mon Aug 7 08:45:53 2017 Return-Path: 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 A5BA9131D24 for ; Mon, 7 Aug 2017 08:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 0DRcGlK1lOmP for ; Mon, 7 Aug 2017 08:45:50 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 079C71324A0 for ; Mon, 7 Aug 2017 08:45:50 -0700 (PDT) Received: from [46.227.151.81] (port=61352 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dekDy-0002OV-9j (Exim 4.72) (return-path ); Mon, 07 Aug 2017 16:45:46 +0100 To: =?UTF-8?Q?=c3=93lafur_Gu=c3=b0mundsson?= Cc: dnsop References: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> From: Ray Bellis Message-ID: Date: Mon, 7 Aug 2017 16:45:48 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 15:45:52 -0000 On 07/08/2017 16:44, Ólafur Guðmundsson wrote: > This was the original proposal, > the drawback is that resolvers to not cache the answer, and to make > things worse they ask ALL NS addresses for listed domain > thus it acts as a DDoS against the domain in question. Indeed - I've since confirmed that BIND does this. I think my point still stands that this behaviour should be documented in the section that talks about a possible new RCODE and why that option was rejected. kind regards, Ray From nobody Mon Aug 7 09:14:17 2017 Return-Path: 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 706441321DE for ; Mon, 7 Aug 2017 09:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 LTXJ32HpEPUh for ; Mon, 7 Aug 2017 09:14:14 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AECB1323A0 for ; Mon, 7 Aug 2017 09:14:14 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 7 Aug 2017 09:14:11 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 7 Aug 2017 09:14:11 -0700 From: Edward Lewis To: Ray Bellis , =?utf-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= CC: dnsop Thread-Topic: [Ext] Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? Thread-Index: AQHTD5QVkEOHh8Kk70ulhqhinKYjfKJ5fqoA///E4IA= Date: Mon, 7 Aug 2017 16:14:11 +0000 Message-ID: <19BAB7E0-4132-448C-92C5-BEC0441EF08F@icann.org> References: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.24.1.170721 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.47.234] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3584952851_1294082972" MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] [Ext] Re: draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 16:14:16 -0000 --B_3584952851_1294082972 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 8/7/17, 11:45, "DNSOP on behalf of Ray Bellis" wrote: > On 07/08/2017 16:44, =C3=93lafur Gu=C3=B0mundsson wrote: > =20 > > This was the original proposal,=20 > > the drawback is that resolvers to not cache the answer, and to make > > things worse they ask ALL NS addresses for listed domain=20 > > thus it acts as a DDoS against the domain in question. =20 > =20 > Indeed - I've since confirmed that BIND does this. > =20 > I think my point still stands that this behaviour should be documented > in the section that talks about a possible new RCODE and why that opti= on > was rejected. This thread is why I'd like to return "what the querier should do next" ins= tead of "why I didn't answer". ;)=20 --B_3584952851_1294082972 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIR5gYJKoZIhvcNAQcCoIIR1zCCEdMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC D68wggWeMIIEhqADAgECAhAE64fxtFjS2DdV8JfouoFSMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQTAeFw0xNjA4MDkw MDAwMDBaFw0xOTA4MDkxMjAwMDBaMIG9MQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZv cm5pYTEUMBIGA1UEBxMLTG9zIEFuZ2VsZXMxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEeMBwGA1UEAxMVRWR3YXJkIExl d2lzIDkgQXVnIDE2MSUwIwYJKoZIhvcNAQkBFhZlZHdhcmQubGV3aXNAaWNhbm4ub3JnMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxGXAQjOhBCDPz1+sGOERDMvSCFWbOUws GUrXAHLGeEAGYTCpni8f7kYPH7RMalvbep2aVtkMSUn6HR1uY84b437ZZuHCviUn7Aw6itGE wrDyq7Pb7zTlqE/1kLVhKYrHA4sjhsQRHhBHevxWbb3SYU2IMNxJd4QFgRJIp4zDmAR7bzbH 1ZazFGfo/op0QRsfcpFYmBotbj/4SnldtFwZasr7zTK9wJRSXa9sspLXtQhBe9itxTHJRg0H BH66VcPX7iRra9XFzkM5JLXOT2nBDIxeqDsLKoTkRWiNoSWoDZylAqS3BfBppwq7eremR7zD LIaPN4Tbb8TCpORMCZuvswIDAQABo4IB7zCCAeswHwYDVR0jBBgwFoAU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHQYDVR0OBBYEFBiOkLRCGoHjShiTxeM3n94XHm+2MAwGA1UdEwEB/wQCMAAw IQYDVR0RBBowGIEWZWR3YXJkLmxld2lzQGljYW5uLm9yZzAOBgNVHQ8BAf8EBAMCBaAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9bAQBAjAq MCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8EgYAw fjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEA zhEJp9X6tm36lKKaxCdyjyETxL3oVPDmv2JHBD/T/xbqRH0vQfR34VkRnSO+5d8AqHGdhYTK 7yjB/vW52KjiQUiW9WnQFYdY5Q/Yv3cnVgi4zuuye9BPvyr87HbmJ0uafYjATnYziT71njO7 xKIQP6w0MFv8ugT/fXIZsV4NU2eGQEHhvPkR+WOt0KfFa5jEY1qXoj4iZmE21j+f0OhSTA9K EofM5chR6FCaOyomKPIYU1mcoQwcistCwfcdVhUCpmgazxn6fR89ZOOiKTXxhOHrILdO0pCI dlJ3xO6EBvFKBCOyRBkD2z7jcWm/U3GkkYBLyRMvH1Ki+q4vwKnFZjCCBk4wggU2oAMCAQIC EASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNV BAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMb RGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoXDTI4MTEwNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQ d3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENB MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kbLQWHohBDMd8O 1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+yTU7VvEffEJ+ JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo8Ymvzf9e /1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYhrTg8 E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAO BgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0 LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRp Z2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYB BQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwIC MIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBp AGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBl ACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBk ACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBu AHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQAeQAgAGEAbgBk ACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUAaQBuACAAYgB5 ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZP3Q5STI8inkw HwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQELBQADggEBAE7U iSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZpgeafBMn2+UC ooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxIEM4zaHvN k6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaBVUCO Zu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIICn6ADAgECAhAM 5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQK EwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0Rp Z2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTExMTAwMDAw MDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3 dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq 9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii 72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PW w25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqi uhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn 8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0 ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy 5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU 5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1bV+JAbZJW58B BZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/N3ypW2168RJG YIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHSoyahEHGdreLD +cOZUbcrBwjOLuZQsqf6CkUvovDyMYIB/zCCAfsCAQEweTBlMQswCQYDVQQGEwJVUzEVMBMG A1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQD ExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEATrh/G0WNLYN1Xwl+i6gVIwCQYFKw4D AhoFAKBdMCMGCSqGSIb3DQEJBDEWBBRK9pMczaimtwyE7zpcHV0oSElQsDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDcxNjE0MTFaMA0GCSqGSIb3 DQEBAQUABIIBAA6chAPFFGOdJ0lMlkYVU14802XOs6K+MIEBB+d6v+6SYniMy4cxSc2ACcWC nY2CHwOS/UmYoilx11TH8LcYuHASbPfLEef6KanHD7hVdDjB6ye+h4z5iwhuLKDoZz5qJI63 oQLTKRsDvVZ6nx2Fij79biiDj4LgWeZlkj1s2IcI0rTvqsCACXJPb+96o28E2Co+1pVSHyF7 2ISWP0hTzx38IubycUP8QmDoTgH8HftW9dBNHvK6zxZggVVkWecWvaV0DTTlbefjqwlF6MBZ OL/BR4iCRzgouGSALLEHJlK+8qC9OVrXhs1InFJdJTeMQ2GlA7wx6bGnayZsk6si6a8= --B_3584952851_1294082972-- From nobody Mon Aug 7 09:29:20 2017 Return-Path: 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 31B2513235A for ; Mon, 7 Aug 2017 09:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nXh0r8xaKyAw for ; Mon, 7 Aug 2017 09:29:17 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC8A131D69 for ; Mon, 7 Aug 2017 09:29:15 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id s6so5709984qtc.1 for ; Mon, 07 Aug 2017 09:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CmA2v54G1m/JgOx7SyR/j7TfUFKUamxBOBXP2xEOq7A=; b=Sn7KBNcn2m0xK9KZXIOanLYhSvJ31FbKktiKTZw4ZvbpeKC3BuJmUyar7XKtF6sHm9 U0YZYk7M7BKpZoVLkWGazzPWeM+K2A3QtHAoJTbPpHksftDSuckh9hwOizimpxIF+vRn FuvK/wY9kTxQKz44iJOAnSjp2LBrIRaONSysu23dFbq2EF7n/CS+ZiA8+19ODZ+6BkBe 3bQ+kOVzV1cTI3JARCDwpgrrLF9mAQ3cJt1MzOUvJ0yVDLNV0lW+cDYe8Buenlht+sCJ YnK2jvxXt/dtrVmllhgHBrpsw9+pSqiQJWnbP1+NL2xZk9rA6carLqdsiNV7+8dINsuw 3P2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CmA2v54G1m/JgOx7SyR/j7TfUFKUamxBOBXP2xEOq7A=; b=Z/GXGIQBFHiW0YkBQ5782QRNKKoN1BtX6apxlhVbbH5nrttoiXvA7Lhe17MCn5ZMK3 P61WiQODIt7zF3NaiV7rNwOV2N2xfv66XSMcbcrgRqQOI98X0eEjIklC7Qn5TWZMWhYq psn5DFFV9JYztq9+VF8l+EOYBRYaqgtLi6JMlBJ04GZRnxF3iiNbdnS1xy3zlAhewXza 5cBfG4aXUwae4dtlncBMNI1bFPcAhMl13kv56O4MVINmQMeSbp7zGhKdu9kOY5eFJFyT vXImlTO7wuvx/6TD3ITxh54VusixQymJh8qpIoS0BmA6I+1bDFoTXT7eoxukbQtsRKVQ W/SA== X-Gm-Message-State: AHYfb5hl0Yu/vusfn2cCoO2JnX6lW5nI9K0MZeYcmd5ZjGmN/cDWhhdu MbHtVa0nYSRPr+1weIAZcITi49oW8XF2 X-Received: by 10.237.63.131 with SMTP id s3mr1568333qth.90.1502123354775; Mon, 07 Aug 2017 09:29:14 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.12.169.15 with HTTP; Mon, 7 Aug 2017 09:29:14 -0700 (PDT) In-Reply-To: References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <7019539A-48B1-4FA2-801D-20A78D85B339@hopcount.ca> From: Erik Nygren Date: Mon, 7 Aug 2017 12:29:14 -0400 X-Google-Sender-Auth: dh-CU8F0fE0HpMVlwqFsbr2U_8A Message-ID: To: Mike West Cc: dnsop WG , Richard Barnes , Joe Abley , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="001a11434eb8f864f905562c589a" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 16:29:18 -0000 --001a11434eb8f864f905562c589a Content-Type: text/plain; charset="UTF-8" On Mon, Aug 7, 2017 at 4:41 AM, Mike West wrote: > > I poked at the draft a bit over the weekend, reworking it into a > stand-alone document in https://tools.ietf.org/ > html/draft-west-let-localhost-be-localhost-04. I think it ends up being > clearer overall, and hopefully y'all agree. > This is looking good. Thank you for driving this forward. I think it is crucial to make the "localhost" abstraction be usable without concerns (but with caveats and guide-rails as proposed in the doc). Otherwise we'll be stuck eternally with people using "http://127.0.0.1/" URLs and will need to special-case that when we want to retire IPv4 off of hosts. It might make sense to collect some statistics on how often "localhost" is looked up on various recursive resolvers to determine how big of a problem it will be for them to "NXDOMAIN". Erik --001a11434eb8f864f905562c589a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 7, 2017 at 4:41 AM, Mike West <mkwst@google.com> wrot= e:

I poked at the= draft a bit over the weekend, reworking it into a stand-alone document in= =C2=A0https://tools.ietf.org/html/draft-west-l= et-localhost-be-localhost-04. I think it ends up being clearer ove= rall, and hopefully y'all agree.


This is looking good.=C2=A0 Thank you for driving thi= s forward.

I think it is crucial to make the "local= host" abstraction be usable without concerns
(but with = caveats and guide-rails as proposed in the doc).=C2=A0 Otherwise we'll<= br>
be stuck eternally with people using "http://127.0.0.1/" URLs and will need
to= special-case that when we want to retire IPv4 off of hosts.

<= div>It might make sense to collect some statistics on how often "local= host"
is looked up on various recursive resolvers to det= ermine how big of a problem
it will be for them to "NXDO= MAIN".

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik
=


--001a11434eb8f864f905562c589a-- From nobody Mon Aug 7 10:26:15 2017 Return-Path: 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 02E641324F5 for ; Mon, 7 Aug 2017 10:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 IbSaRq2UNw6Q for ; Mon, 7 Aug 2017 10:26:11 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB31131EA2 for ; Mon, 7 Aug 2017 10:26:11 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:ed0a:9ec7:e266:79e4] (unknown [IPv6:2001:559:8000:c9:ed0a:9ec7:e266:79e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 3134561FF3; Mon, 7 Aug 2017 17:26:11 +0000 (UTC) Message-ID: <5988A2AD.3010507@redbarn.org> Date: Mon, 07 Aug 2017 10:26:05 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Ray Bellis CC: dnsop References: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> In-Reply-To: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 17:26:13 -0000 Ray Bellis wrote: > ... returning NOTIMP for ANY queries, ... > > ... > > My reading of RFC 1035 is that it would be a perfectly appropriate > response from a server that doesn't support ANY. the RFC was treated as a general guideline by most implementers, and once the code for some client or server appeared to work, it was shipped. it is that code which constraints our work now, not the RFC. > Unfortunately the retry semantics of DNS are not well specified and > therefore implementation differences may occur. If as a result NOTIMP > is really not usable then IMHO this should also be documented. i think you'll find that NOTIMP causes try-next-server for many clients, but without poisoning, so if all servers return NOTIMP, then all those same servers will be tried again, without delay. sometimes, withholding a response is the only way to keep the client out of this bombardment-mode. sometimes returning something poisonous like ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do something constructive, ideally constructive for both them and us. it doesn't have to be true, and it doesn't have to be documented in an older RFC. i agree that writing a new RFC whenever something like this is found to be necessary, and putting into that RFC more specific advice to client implementers so that the future might possibly improve, is a great idea. -- P Vixie From nobody Mon Aug 7 10:34:26 2017 Return-Path: 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 45B8A1328AD for ; Mon, 7 Aug 2017 10:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 y5xDvGsGM_1U for ; Mon, 7 Aug 2017 10:34:23 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F63F1326E6 for ; Mon, 7 Aug 2017 10:34:23 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:ed0a:9ec7:e266:79e4] (unknown [IPv6:2001:559:8000:c9:ed0a:9ec7:e266:79e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 12C8F61FF3; Mon, 7 Aug 2017 17:34:23 +0000 (UTC) Message-ID: <5988A49D.3070607@redbarn.org> Date: Mon, 07 Aug 2017 10:34:21 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Ray Bellis CC: dnsop References: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> In-Reply-To: <6c97191d-9591-d7de-6e8b-ed6e460c7707@bellis.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] draft-ietf-dnsop-refuse-any - why not NOTIMP? X-BeenThere: dnsop@ietf.org 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: Mon, 07 Aug 2017 17:34:24 -0000 Ray Bellis wrote: > ... returning NOTIMP for ANY queries, ... > > ... > > My reading of RFC 1035 is that it would be a perfectly appropriate > response from a server that doesn't support ANY. the RFC was treated as a general guideline by most implementers, and once the code for some client or server appeared to work, it was shipped. it is that code which constraints our work now, not the RFC. > Unfortunately the retry semantics of DNS are not well specified and > therefore implementation differences may occur. If as a result NOTIMP > is really not usable then IMHO this should also be documented. i think you'll find that NOTIMP causes try-next-server for many clients, but without poisoning, so if all servers return NOTIMP, then all those same servers will be tried again, without delay. sometimes, withholding a response is the only way to keep the client out of this bombardment-mode. sometimes returning something poisonous like ANCOUNT=0 is nec'y. again, our guide today is how to get clients to do something constructive, ideally constructive for both them and us. it doesn't have to be true, and it doesn't have to be documented in an older RFC. i agree that writing a new RFC whenever something like this is found to be necessary, and putting into that RFC more specific advice to client implementers so that the future might possibly improve, is a great idea. -- P Vixie From nobody Tue Aug 8 03:53:29 2017 Return-Path: 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 B47DE13218F for ; Tue, 8 Aug 2017 03:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rGiKddok1ODS for ; Tue, 8 Aug 2017 03:53:26 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A0F132193 for ; Tue, 8 Aug 2017 03:53:25 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d136so17411136qkg.3 for ; Tue, 08 Aug 2017 03:53:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=q+SOV1Sr5y2NzgMcPxd8/iz2lj8nAzJAU/IErHAXDHo=; b=ToawcsTHcN58VVQFz2cE1+37rcetpxBmsn4dW7dXl/NNncOtwL2v2CRD986C+cJPC+ XWN9i8vFrSNwVR3JBWnD9sfs/n+RNtmz42Ig7vE55ytXYkMAMIUThb8C7eRj3DeF/zTQ 08redDdAw7cSSwdK0zzn1gYl55FHQoqCxTR9uUqY4TjGFfiY+V8gNkGHEXdDGBQvLngp aR6Vly1dy2/BORvY1Pg/Bhe5VZ/TO78+0WTDuW+iCbKJcd1LwaKnnqWJ5QT8uYihjHVO yvsmQXcu4/UIDxakV2Jk7qolUa4UWYphe2TGkiWZovLoA9dmTLcanSmQaPwksRKdFP+H 5Kvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q+SOV1Sr5y2NzgMcPxd8/iz2lj8nAzJAU/IErHAXDHo=; b=fz7uCptSIJgU/cVrrocaqrSvrpyuUZuWASE3TMPOa+iOov9JjLrlRm5LSPqMTGfNG3 pMLuZ8/7Uuig6Rw0gKYTjQcn/nOjlryReBm4Sfw1AXP+RIZy1gpY+t+isA1L1vsWZxj6 LBwj9K4gibJ43nRieGnQXwqlMphE76UqfRs7ZxcK2NRASAuYFzPD8q7xURTamGICgmNz Pa6AZtf+vVg+DO041EMJaVYfP7XcmG4Y3M8qb8/L7lJ6+59rCCgS8hZYfTzqmvw50F/c dKoTEfvLhBRF/kRS2KKIlCe3W/rbjAZ5ZpgzouvxggF32krVNsGsKAQjU8rdtUHVQWAf 34zA== X-Gm-Message-State: AHYfb5hnDQ0vCBUilQeCBYAYoWgtrYXkCaUFx8M3oT7TMiKgYnZO0sT4 7LYR1zhsRbGpEBKo X-Received: by 10.55.18.87 with SMTP id c84mr5292296qkh.12.1502189604656; Tue, 08 Aug 2017 03:53:24 -0700 (PDT) Received: from twicinski-ltm1.internal.salesforce.com ([204.14.236.150]) by smtp.googlemail.com with ESMTPSA id y133sm507126qkb.71.2017.08.08.03.53.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 03:53:23 -0700 (PDT) From: Tim Wicinski To: dnsop References: Message-ID: Date: Tue, 8 Aug 2017 06:53:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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: Tue, 08 Aug 2017 10:53:28 -0000 All The Call for Adoption period has ended and there is some strong consensus to adopt this work, and move it forward. The authors will upload a new version with the right naming, and the real work can begin on gather consensus. thanks for all the comments for the chairs, tim On 7/25/17 12:04 PM, tjw ietf wrote: > This draft was the only one which seemed to have broad support in some > form during the meeting last week. > > This starts a Call for Adoption for draft-wkumari-dnsop-extended-error > > The draft is available here: > https://tools.ietf.org/html/draft-wkumari-dnsop-extended-error-02 > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 8 August 2017, 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > From nobody Tue Aug 8 06:24:03 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC310132387; Tue, 8 Aug 2017 06:23:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , draft-ietf-dnsop-sutld-ps@ietf.org, dnsop-chairs@ietf.org, dnsop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , bclaise@cisco.com, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150219863383.12399.16498119191156787341.idtracker@ietfa.amsl.com> Date: Tue, 08 Aug 2017 06:23:53 -0700 Archived-At: Subject: [DNSOP] Document Action: 'Special-Use Domain Names Problem Statement' to Informational RFC (draft-ietf-dnsop-sutld-ps-08.txt) X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 13:23:54 -0000 The IESG has approved the following document: - 'Special-Use Domain Names Problem Statement' (draft-ietf-dnsop-sutld-ps-08.txt) as Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are Warren Kumari and Benoit Claise. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ Technical Summary The Special-Use Domain Names IANA registry policy defined in RFC 6761 has been shown through experience to present unanticipated challenges. This memo presents a list, intended to be comprehensive, of the problems that have been identified. In addition it reviews the history of Domain Names and summarizes current IETF publications and some publications from other organizations relating to Special- Use Domain Names. Working Group Summary This document was the result of a decision in DNSOP to attempt to characterize the problems we actually face with special use names before attempting to analyze any of several proposals and contending beliefs about how to resolve them. The document has been a considerable time in the making but has WG consensus as a list of the relevant issues and challenges. As such, it can reasonably be the basis for future work in this area, whether it's within scope/charter for DNSOP or not. Document Quality The document summarizes many discussions and documents across DNSOP, the wider IETF, and other concerned communities to date. Personnel Shepherd: Suzanne Woolf Area Director: Benoit Claise From nobody Tue Aug 8 22:22:58 2017 Return-Path: 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 CBCA9131DB6 for ; Tue, 8 Aug 2017 22:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] 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 h9SRF3kqtkNV for ; Tue, 8 Aug 2017 22:22:54 -0700 (PDT) Received: from mail.hardakers.net (unknown [168.150.236.43]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD363120227 for ; Tue, 8 Aug 2017 22:22:54 -0700 (PDT) Received: from localhost (unknown [10.0.0.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 4225521AF0; Tue, 8 Aug 2017 22:22:54 -0700 (PDT) From: Wes Hardaker To: Edward Lewis Cc: dnsop , tjw ietf In-Reply-To: (Edward Lewis's message of "Wed, 26 Jul 2017 15:12:59 +0000") References: User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.2 (gnu/linux) Date: Tue, 08 Aug 2017 22:22:54 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [DNSOP] [Ext] Call for Adoption: draft-wkumari-dnsop-extended-error X-BeenThere: dnsop@ietf.org 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, 09 Aug 2017 05:22:56 -0000 Edward Lewis writes: > But the draft itself isn't exactly the way I'd go about solving the > problem. Does that mean it shouldn't be adopted? I suppose not, I > suppose the answer is to adopt it and change it mercilessly. And such is the IETF way; so to quote someone recently: > I mean, bring it on. -- Wes Hardaker USC/ISI From nobody Wed Aug 9 09:31:36 2017 Return-Path: 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 C3A4913240E for ; Wed, 9 Aug 2017 09:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Y8T_SUhrr7Jg for ; Wed, 9 Aug 2017 09:31:33 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 885C113240C for ; Wed, 9 Aug 2017 09:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502296293; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A/LG1IIsHxQ9vz7l9hIl5Zl4OVNTukgtwb3zOWmVgss=; b=S8OzzYj/czYrWA1L4ZDS9Lh0K4Om2EbEjVrbECgLk5uGSJQIYTmmaYaF+26ENwbJ U95Bf/LbGd1eUgM8+y3b3Q1VdON/v46VMthR+F5XhX0FYUPYbT3ebk74qjZ4oCAj d+AkHamybT3HJovQenDm9AFvQeMCM2ooya1ISs/NfRmn3ryuPlqptxW/KOMGRn7K 0vtFj7JAmy9X7+U9Dg9sDLNd4BMbcJSCKPQOhjd3gsAP3sV8CokCrHUyC+GZ3pTx nPRc2A7YnS1QIkz0sI7FyvzZeLouMB4FpS6Gu2HDDJ7CiudM7NOR3OdiBPM8FLcs haWJP3VPwtsbOQZeLDzUkA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id D7.76.06195.5E83B895; Wed, 9 Aug 2017 09:31:33 -0700 (PDT) X-AuditID: 11973e16-8b5f19c000001833-c6-598b38e5a0e0 Received: from jimbu.apple.com (jimbu.apple.com [17.151.62.37]) by relay5.apple.com (Apple SCV relay) with SMTP id D9.49.10385.5E83B895; Wed, 9 Aug 2017 09:31:33 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from da0602a-dhcp180.apple.com ([17.226.23.180]) by jimbu.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUF00B69F8K0600@jimbu.apple.com>; Wed, 09 Aug 2017 09:31:33 -0700 (PDT) Sender: cheshire@apple.com From: Stuart Cheshire In-reply-to: <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> Date: Wed, 09 Aug 2017 09:31:33 -0700 Cc: Robert Edmonds , Ted Lemon , Richard Barnes , Mike West , william manning , Jacob Hoffman-Andrews Content-transfer-encoding: quoted-printable Message-id: <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> To: dnsop X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUi2FAYofvUojvSoHeDkMXsHQ1sFnffXGax WL7+L7vFzCs/2SzerDnCZHF21Wdmi6l9tg7sHu8+PWf1aLqwjN1j56y77B4LNpV6LFnyk8lj 8sZZLB6Lbh1nDGCP4rJJSc3JLEst0rdL4Mo4dHszc8EK4Yo9P9waGD/ydzFyckgImEi8vTmT vYuRi0NIYDWTRNuJ78wwidnbOtlBbCGBDYwS7+8kgti8AoISPybfY+li5OBgFlCXmDIlF6K3 kUmiefsyVpAaYQEpiVcrPzND2DYSbd0XmUBsNgEtiRefr7CB2JwC5hIrX2wCq2ERUJX4dfU6 M8ggZoHrjBLf2zvAGpgFtCWevLvACrHYRmLevj4miG0PWSQ+XngN1i0CtO3ZrEcsEFfLStya fQlskoTAInaJv7/Xs01gFJ6F5PJZCJfPQrJjASPzKkah3MTMHN3MPHO9xIKCnFS95PzcTYyg 2JluJ7aD8eEqq0OMAhyMSjy8CaLdkUKsiWXFlbmHGKU5WJTEefuyuiKFBNITS1KzU1MLUovi i0pzUosPMTJxcEo1MLI67Y3Luss7eYOQ3GvfmilcR79xXKly4tPcKymzapvHKfuEQhGbVW+z tLYt6jGIDrU3mJK5S6pml+5djcBWobl653TufDjuyTr92R6VNbdDl54KecHO5RrxdDPTwQ2T W9Vvbs3JMBE8U/O2+9372ADfz8kT3YwPeqctZnDmPnF54YG2KNd7C5RYijMSDbWYi4oTAfTS b3d+AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUiON1OVfepRXekwdKzfBazdzSwWdx9c5nF Yvn6v+wWM6/8ZLN4s+YIk8XZVZ+ZLab22Tqwe7z79JzVo+nCMnaPnbPusnss2FTqsWTJTyaP yRtnsXgsunWcMYA9ytAmLb+oPLEoRaEouaDEVqk4IzElvzze0tjI1CGxoCAnVS85P1dJ384m JTUnsyy1SN8uwTDj0O3NzAUrhCv2/HBrYPzI38XIySEhYCIxe1snO4gtJLCBUeL9nUQQm1dA UOLH5HssXYwcHMwC6hJTpuR2MXIBlTQySTRvX8YKUiMsICXxauVnZgjbRqKt+yITiM0moCXx 4vMVNhCbU8BcYuWLTWA1LAKqEr+uXmcGGcQscJ1R4nt7B1gDs4C2xJN3F1ghFttIzNvXxwSx 7SGLxMcLr8G6RYC2PZv1iAXialmJW7MvMU9gFJiF5NhZCMfOQjJ2ASPzKkaBotScxEpTPXjg bGIERU5DYcQOxv/LrA4xCnAwKvHwcgh3RwqxJpYVV+YeYpTgYFYS4b1sBhTiTUmsrEotyo8v Ks1JLT7E6AP0zURmKdHkfGBU55XEGxpbGFuaWBgYmFiameAQVhLn3b+lI1JIID2xJDU7NbUg tQhmHBMHp1QD4xQ9lt/yG24vYPsyKTbvydfaQ3fL7Q5t2Xyyb+OppOaILy8Xm6W6R3yK+R1k +/+b9kLf3Q2NDR/iNidqB+7ddWfj6YlTfd2M3xw3cb4b4Chy1v7FClnbDRI/zPczzghSNr77 Z+6crTss/ia+zah4vffWhieZkWd0JzLwJ7wP/MiftbvosK/KI1slFmAyMtRiLipOBAD1rRQO yQIAAA== Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 09 Aug 2017 16:31:35 -0000 I=E2=80=99m puzzled by much of this discussion. We want a way for an application to indicate that it wants a loopback = connection to another port on the local host. People widely use =E2=80=9Clocalhost=E2=80=9D for this. But other people argue that a mere RFC can=E2=80=99t guarantee that a = host doesn=E2=80=99t violate the assumption that =E2=80=9Clocalhost=E2=80=9D= means =E2=80=9Clocal host=E2=80=9D. So, to indicate that it wants a loopback connection to another port on = the local host, an application needs to use =E2=80=9C127.0.0.1=E2=80=9D. = By, by the same logic, a mere RFC can=E2=80=99t guarantee that a host = doesn=E2=80=99t violate the assumption that =E2=80=9C127.0.0.1=E2=80=9D = means loopback. Who knows what a host OS will do with that address, if = it does not follow the relevant RFCs? [*] Forgive me, I forgot, =E2=80=9C127.0.0.1=E2=80=9D is obsolete. I should = have written, =E2=80=9C::1=E2=80=9D. I=E2=80=99ll try again: So, to indicate that it wants a loopback connection to another port on = the local host, an application needs to use =E2=80=9C::1=E2=80=9D. By, = by the same logic, a mere RFC can=E2=80=99t guarantee that a host = doesn=E2=80=99t violate the assumption that =E2=80=9C::1=E2=80=9D means = loopback. Who knows what a host OS will do with that address, if it does = not follow the relevant RFCs? So, =E2=80=9C127.0.0.1=E2=80=9D and =E2=80=9C::1=E2=80=9D are not = suitable, both because a host OS might choose not to follow the relevant = RFCs, and more importantly, they=E2=80=99re both = address-family-specific. What we really need is some symbolic way for an application to indicate = unambiguously that it wants a loopback connection to another port on the = local host. We should reserve a specific string and define that it has this meaning. = Some operating systems will follow the specification, and will work as = expected, and others will not, which is a bug. Don=E2=80=99t use those = products. A nice mnemonic string would be good. Something memorable, which conveys = the meaning, =E2=80=9Clocal host=E2=80=9D. I suggest =E2=80=9Clocalhost=E2=80=9D. Stuart Cheshire [*] If you think it=E2=80=99s stupid to suggest a host might not treat = =E2=80=9C127.0.0.1=E2=80=9D as meaning loopback, why is that any more = stupid than suggesting that a host might not treat =E2=80=9Clocalhost=E2=80= =9D as meaning loopback? Both are just as arbitrary.= From nobody Wed Aug 9 09:45:03 2017 Return-Path: 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 9B7CA132423 for ; Wed, 9 Aug 2017 09:45:01 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 HCbWX7sHLKV3 for ; Wed, 9 Aug 2017 09:44:59 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 825DE132424 for ; Wed, 9 Aug 2017 09:44:59 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id h68so30105058pfk.0 for ; Wed, 09 Aug 2017 09:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EwN0pabjg5y+hVmN3W7H63PJToMk1zS/W4vcY9Pcp5A=; b=xeSmiISEn99qn9B7eG+MC6Wxl9rLIDfHvi/6jxmwhFL59AWqzffDkU/EYKjHs8BnX1 X7ywKBUxLQeNOQaZgJfd3vo5ePi42tju03kK/uTSrnbkRKkSYqxvYQVWcJD4nzM5glpU xvC6pcfpnFRoE75AXV+ToeHfYarh5TOy9Rwlv982keS+Gz+d8w2NBtftVOGyK4GNoTDS vzZVXzHkSfQC+2rsgu3ehwKbjuCpEiZkHrMuSzlnqYQw+aTKKLQdaSa+IOj6loI6Kwt+ XXX8Hid23eLMuPBPtW4zkPQx1+IuiTg6SqYyt8Gv1yvgDkFoME0nD0W7DVsPQI9IWbRD XV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EwN0pabjg5y+hVmN3W7H63PJToMk1zS/W4vcY9Pcp5A=; b=qAO2Aws5HlP8grjjKYg1gGzbKYPgOy4PGMJBVnIRbdkC1OArDP2Zj+8Pa4KbCEhQvV z8LigGnCUyF+OB4psBWVApCRfhgkrrR3lGZ6GDtBva27K2LmLGioV6afY7i/qkbX+UpJ 7xG9D/3p27XadwGD0vtvQihKrJZf5UsduqQUgkIiUHi/PHLsLYBOqR2igG83gnWLm2NW 1becCQ3VMIfi188YOg8bXcI3boMPXqYBqtbCrpzLi5GK9IybrdB7Z8cn8rdc71p6J/1h StZeHxvRTyt4CSuuhVz3nb/xz34xvtHoJaylJKgy5MQH+Q5LtDFqkqHzvYSLQmKZUz52 Pyyw== X-Gm-Message-State: AHYfb5isW7FmcDBiXeZD5LrHM69k9WHx5tHfliCGt4Y5OTnsfaG8lgPv VIuEPZtxmmqDdZyYrLsevwzTDQWw2hJt X-Received: by 10.99.107.193 with SMTP id g184mr8148113pgc.167.1502297098892; Wed, 09 Aug 2017 09:44:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Wed, 9 Aug 2017 09:44:18 -0700 (PDT) In-Reply-To: <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> From: Ted Lemon Date: Wed, 9 Aug 2017 12:44:18 -0400 Message-ID: To: Stuart Cheshire Cc: dnsop , Robert Edmonds , Richard Barnes , Mike West , william manning , Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary="94eb2c14088aed4dd8055654cc52" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 09 Aug 2017 16:45:02 -0000 --94eb2c14088aed4dd8055654cc52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire wrote= : > [*] If you think it=E2=80=99s stupid to suggest a host might not treat = =E2=80=9C127.0.0.1=E2=80=9D > as meaning loopback, why is that any more stupid than suggesting that a > host might not treat =E2=80=9Clocalhost=E2=80=9D as meaning loopback? Bot= h are just as > arbitrary. The reason is that we understand the process by which names are resolved, and we understand the process by which addresses are configured. You likely have only one IP stack on your host. You may have dozens of stub resolvers. So the stub resolvers are a target-rich environment for failure, and they fail unsafe, not safe: by default, they go to the DNS protocol to resolve names. If the implementor assumes the DNS will return 127.0.0.1 or ::1, as indeed they tend to do, then they may not think to read the RFC that says "you need a special case for localhost." On the other hand, suppose that ::1 doesn't work on your host. What happens is that the network transaction fails. This is a much better outcome than connecting to an endpoint that is not on the local host, assuming that it is, and making safety assumptions on the basis that it is. Suppose ::1 is configured to connect to an external host. Well, a ton of stuff is going to break, and it's going to be really obvious that it's broken. You may still experience some negative consequences, but this is a much more detectable situation, because a lot more things will break. Of course, the real answer to this is that neither solution is desirable. I've heard several people here say that if localhost were "fixed" in an RFC, then the W3C could mark http connections to localhost as secure, rather than insecure. This is of course nonsense. The fact is that you should always validate the endpoint you are connecting to using some secure protocol. With a unix domain socket, you can pass credentials over the socket. With a TCP or UDP connection, you can't do that, so you need to use cryptography. This is a problem for connections to localhost, of course, since you can't get a cert for it, but that's probably okay. A better test for localhost for W3C is that if the page you are looking at came from localhost and refers to localhost, *AND* the software that's making the secure/not judgment is also doing name resolution, and it implements the RFC we are talking about here, then it can assume that resources addressed using http://localhost are both secure and confidential. Otherwise not (a web page referencing localhost that wasn't served by localhost should be treated as an attack, for example). --94eb2c14088aed4dd8055654cc52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire <cheshire@apple.com>= wrote:
[*] If you think it=E2=80= =99s stupid to suggest a host might not treat =E2=80=9C127.0.0.1=E2=80=9D a= s meaning loopback, why is that any more stupid than suggesting that a host= might not treat =E2=80=9Clocalhost=E2=80=9D as meaning loopback? Both are = just as arbitrary.

T= he reason is that we understand the process by which names are resolved, an= d we understand the process by which addresses are configured. =C2=A0 You l= ikely have only one IP stack on your host. =C2=A0 You may have dozens of st= ub resolvers. =C2=A0 So the stub resolvers are a target-rich environment fo= r failure, and they fail unsafe, not safe: by default, they go to the DNS p= rotocol to resolve names. =C2=A0 If the implementor assumes the DNS will re= turn 127.0.0.1 or ::1, as indeed they tend to do, then they may not think t= o read the RFC that says "you need a special case for localhost."=

On th= e other hand, suppose that ::1 doesn't work on your host. =C2=A0 What h= appens is that the network transaction fails. =C2=A0 This is a much better = outcome than connecting to an endpoint that is not on the local host, assum= ing that it is, and making safety assumptions on the basis that it is. =C2= =A0 Suppose ::1 is configured to connect to an external host. =C2=A0 Well, = a ton of stuff is going to break, and it's going to be really obvious t= hat it's broken. =C2=A0 You may still experience some negative conseque= nces, but this is a much more detectable situation, because a lot more thin= gs will break.

Of course, the real answer to this is that neither solution is des= irable. =C2=A0 I've heard several people here say that if localhost wer= e "fixed" in an RFC, then the W3C could mark http connections to = localhost as secure, rather than insecure. =C2=A0 This is of course nonsens= e. =C2=A0 The fact is that you should always validate the endpoint you are = connecting to using some secure protocol. =C2=A0 With a unix domain socket,= you can pass credentials over the socket. =C2=A0 With a TCP or UDP connect= ion, you can't do that, so you need to use cryptography. =C2=A0 This is= a problem for connections to localhost, of course, since you can't get= a cert for it, but that's probably okay. =C2=A0 A better test for loca= lhost for W3C is that if the page you are looking at came from localhost an= d refers to localhost, AND=C2=A0the software that's making the s= ecure/not judgment is also doing name resolution, and it implements the RFC= we are talking about here, then it can assume that resources addressed usi= ng http://localhost are both secure and co= nfidential. =C2=A0 Otherwise not (a web page referencing localhost that was= n't served by localhost should be treated as an attack, for example).
--94eb2c14088aed4dd8055654cc52-- From nobody Wed Aug 9 09:45:49 2017 Return-Path: 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 1DE99132424 for ; Wed, 9 Aug 2017 09:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 A9STWoEnVt-N for ; Wed, 9 Aug 2017 09:45:46 -0700 (PDT) Received: from mycre.ws (mycre.ws [45.33.102.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5209132423 for ; Wed, 9 Aug 2017 09:45:46 -0700 (PDT) Received: by chase.mycre.ws (Postfix, from userid 1000) id EAF9812C1833; Wed, 9 Aug 2017 12:45:45 -0400 (EDT) Date: Wed, 9 Aug 2017 12:45:45 -0400 From: Robert Edmonds To: Stuart Cheshire Cc: dnsop , Jacob Hoffman-Andrews , william manning , Richard Barnes , Ted Lemon , Mike West Message-ID: <20170809164545.we3lw43s6aswdg6f@mycre.ws> References: <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 09 Aug 2017 16:45:48 -0000 Stuart Cheshire wrote: > [*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” as meaning loopback, why is that any more stupid than suggesting that a host might not treat “localhost” as meaning loopback? Both are just as arbitrary. As far as I can tell, "let 127.0.0.1 be loopback" is more stupid because RFC 1122 states that addresses of the form 127.0.0.0/8 MUST be used for loopback traffic, while the considerations for "let localhost be loopback" in RFC 6761 §6.3 use non-mandatory language. -- Robert Edmonds From nobody Wed Aug 9 09:48:43 2017 Return-Path: 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 F0438132429 for ; Wed, 9 Aug 2017 09:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 wBvbW7mYALcw for ; Wed, 9 Aug 2017 09:48:41 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F4D132427 for ; Wed, 9 Aug 2017 09:48:41 -0700 (PDT) Received: from [46.227.151.81] (port=54524 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1dfU9t-0000aR-B3 (Exim 4.72) for dnsop@ietf.org (return-path ); Wed, 09 Aug 2017 17:48:37 +0100 To: dnsop@ietf.org References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> <820AEB88-C38C-4547-8F42-3C7C7E3D7ACC@apple.com> From: Ray Bellis Message-ID: <90eb5003-3629-e962-417c-8af37188ae51@bellis.me.uk> Date: Wed, 9 Aug 2017 17:48:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 09 Aug 2017 16:48:43 -0000 On 09/08/2017 17:44, Ted Lemon wrote: > Of course, the real answer to this is that neither solution is > desirable. I've heard several people here say that if localhost were > "fixed" in an RFC, then the W3C could mark http connections to localhost > as secure, rather than insecure. This is of course nonsense. The > fact is that you should always validate the endpoint you are connecting > to using some secure protocol. With a unix domain socket, you can pass > credentials over the socket. With a TCP or UDP connection, you can't > do that, so you need to use cryptography. Speaking of which, MySQL uses the word "localhost" as a switch to use a UNIX domain socket instead of IP for its connection. Just sayin' ;) Ray From nobody Wed Aug 9 22:25:17 2017 Return-Path: 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 416C413254F for ; Wed, 9 Aug 2017 22:25:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=ZFI2D2Ky; dkim=pass (1024-bit key) header.d=yitter.info header.b=URfXtXuW 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 7chcSRrI6XFR for ; Wed, 9 Aug 2017 22:25:15 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB3C13254E for ; Wed, 9 Aug 2017 22:25:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id D3254BF590 for ; Thu, 10 Aug 2017 05:24:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502342684; bh=eF2LaKx4xjQso+Tgg5T459YZxXs+arJ4ni2OkbPzow4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=ZFI2D2KyJI3miirk/8et6l7CThI2TpiuNNT7vcVu4cOBkCXh2WdfIHQWrpd0HC5Bd J29I0SNykR9CqBYQX3IM20T/6lS2VuWfGcvViah7SihWQwtg0IztRYcyzmt93bN23u 4dpJUjns+H5bHVLq2lv4TX7mHz3qwTuPfqNXnblo= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTA2Tjmy7d1e for ; Thu, 10 Aug 2017 05:24:43 +0000 (UTC) Date: Thu, 10 Aug 2017 01:24:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1502342683; bh=eF2LaKx4xjQso+Tgg5T459YZxXs+arJ4ni2OkbPzow4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=URfXtXuWFf8a70Yhj+/9oXtzoQzJSdppSe+82JzLp7zZbsaFa3CQxd31Rrvi4u0DX sFpU+DVYALe06yB0uWo1dmejuXHq0sSk5U1qzBBFxFAeI91RsXZoOjkg/6PQJg+DOU a8jcu7qXQORJyGr8s80scPpp13/5VuX7AYt5qU1c= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170810052443.ltfr4mjskwvwvg3q@mx4.yitter.info> References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> Archived-At: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 05:25:17 -0000 Hi, On Thu, Aug 03, 2017 at 03:36:24PM -0700, Dave Crocker wrote: > deal with that fully, in a single spec produced an especially confused > draft, roughly 10 years ago. I _think_ I may be one of the people who complained at the time, and if I recall correctly what Dave and I agreed about (maybe the only thing) was that this was all a terrible mess that needed repair. At the time, I was still too much in thrall to data-theoretic approaches to give in on Dave's pragmatic answer. And I now see that Dave has actually described better than I was ever able my objection: > I've come to the conclusion that "accommodating" the established > registration practices is a fundamentally wrong path. The only way to solve > a problem of multiple registration authorities is to create a single > registration authority. Yes. > 1. Have this document define the simple, sole, authoritative mechanism > for registering "top-level" (global scope) underscore names. > > 2. Create a separate document that specifies modifications to the SRV and > URI documents, rationalizing the use of underscore names, through the > mechanism defined in -attrleaf-. I like this approach. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Thu Aug 10 04:04:46 2017 Return-Path: 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 85F33132695 for ; Thu, 10 Aug 2017 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 47qxFTLqLrF7 for ; Thu, 10 Aug 2017 04:04:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C8C3C126C22 for ; Thu, 10 Aug 2017 04:04:41 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a] (unknown [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a]) by mail.nic.cz (Postfix) with ESMTPSA id 85C23624E7; Thu, 10 Aug 2017 13:04:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502363078; bh=nHALdF5FbyeZbTVB7aL9jirZ9ScEi7bxIwCm13mPSYU=; h=From:To:Date; b=kT71UEDxbZxmAach2p/floxrqLMfwQvQ9cuR8GtsMC3l4hnHTkqi2KHCGYD/Aksiv INDWJXbSSZOVxxmfvSF/KdlaDuUdbm4z9/dTha3Gkm8K9WJuAuoxZ5/p+B+OUiFdbF BBfGqm7lM2f3VBm7/9Cgs/OIUEbS+PNLuT7/moIg= From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= To: dnsop@ietf.org Cc: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> Organization: CZ.NIC Message-ID: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> Date: Thu, 10 Aug 2017 13:04:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 11:04:44 -0000 Hello, On 4.7.2017 05:54, Lanlan Pan wrote: > Hi Tony, > > We try to solve similar wildcard problem. > > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards > ) > : > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information. > - cached deduced wildcard: give the default wildcard RR. > > SWILD: > - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR. > > SWILD is applicable even when Authoritative Nameservers don't give > NSEC/NSEC3 RR. > SWILD is applicable on non-validating Forwarding Resolvers. If I understand it correctly: - the only information added by SWILD RR is an explicit information about the original (unexpanded) name of wildcard owner - the very same information can be obtained from RRSIG RR in a synthtetised answer (RRSIG labels < owner name labels) - SWILD will work only if there are no nodes below the wildcard Assuming this analysis is right, I'm against this proposal. We can get even better behavior from aggressive NSEC use. Here are advantages of aggressive NSEC use: - does not require changes to existing authoritatives or signed zones - less fragile (if we consider manual SWILD specification as an option) - supports wildcards with nodes below it Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that is okay: New features are provided only by the latest version of the protocol. Petr Špaček @ CZ.NIC > > Regards, > > Tony Finch >于2017年7月3日周一 下午 > 8:18写道： > > Lanlan Pan > wrote: > > > > This document specifies a new SWILD RR type for Intermediate > Nameservers to > > cache subdomain wildcard record, in order to reduce the cache size and > > optimize the wildcard domain cache miss. > > Isn't this functionality already provided by > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ? > > Tony. > -- > f.anthony.n.finch > > http://dotat.at/ - I xn--zr8h punycode > Fitzroy: Variable 4 for a time in north, otherwise northeasterly > becoming > cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, > occasionally > poor. > > -- > 致礼 Best Regards > > 潘蓝兰 Pan Lanlan From nobody Thu Aug 10 04:28:36 2017 Return-Path: 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 4AB05126E3A; Thu, 10 Aug 2017 04:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 Dy5VivbSTM0V; Thu, 10 Aug 2017 04:28:31 -0700 (PDT) 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 9A9791320BB; Thu, 10 Aug 2017 04:28:31 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a] (unknown [IPv6:2001:1488:fffe:6:f462:c2ff:fe89:fd7a]) by mail.nic.cz (Postfix) with ESMTPSA id CB4BB622C0; Thu, 10 Aug 2017 13:28:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502364510; bh=dla9eyO95IPRwlSSng230rBoFd2OvR7sVBFIvXPQ/28=; h=From:To:Date; b=mGONFtNXMzIAOubfuXz0l6WLMXh9oMxngjf5EzvSA2m4z7ODnaRnAvR0aiDU5QAIt mnXExok9q4+25ynr6VArgOIW93hnbTiSit1H90LUDeAR5TjPzSPVt0RdD+w+juL5j5 XnPHRudcmDPjZ/FqU4Bxz0DRKfxonBlU8i8dyBu8= From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= To: Ted Lemon , dnsop WG Cc: "dnsop-chairs@ietf.org" References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> Organization: CZ.NIC Message-ID: Date: Thu, 10 Aug 2017 13:28:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 11:28:34 -0000 Hello Ted and dnsop, and sorry for delayed answer (below). Your message forced me to think more about the draft, this time without focus on the wire format. Spoiler alert: I still do not like the proposal in its current form. Please see below. On 21.7.2017 10:22, Ted Lemon wrote: > I am hearing from a number of people that this is "a new protocol" and > hence requires careful thought and perhaps a new working group, along > with the associated delay. I do not _entirely_ disagree with this > position, although it would be really inconvenient from my perspective. > > However, I would like to point out that the objection "it is a new > protocol" is not a technical objection. Also, the same objection can > actually much more justly be raised against several other proposals that > were brought before the working group. For example, the multiple > RRtypes proposal, the multiple responses proposal, and the extended > error codes proposal. > > All of these define new protocol, in ways that are in, like session > signaling, backward-compatible with the existing protocol. The other > proposals are actually much more significant changes than session > signaling is, in terms of what they actually do, as opposed to what > their wire format is. Okay, I can see what you mean - there surely are various levels of complexity and protocol changes proposed in the last years for dnsop. However I disagree that adding session signalling to DNS is less significant change than e.g. multi-query/repose proposals. As you said, session signalling is a "control plane for DNS", which is a very new thing. Keeping (IMHO significant) wire format issues aside, adding a control plane to DNS is in my eyes a significant new development and should be treated as such. > And as for a new DNS wire format, which I also think would be a good > idea, this is pretty clearly /not /what session signaling is. How > would you do a DNS query with session signaling? In what way would it > be an improvement over the existing query format? It's possible that a > new wire format can be built on top of session signaling, but session > signaling doesn't build a new wire format, and if we choose to do > session signaling, that doesn't preclude doing a different wire format > for queries later. Maybe one of the problems is that the current draft mixes three things in a single document: - The new wire format, - DNS control plane, - Session signaling functionality over the control plane. This is probably making things way harder to explain to non-authors than necessary. These really are separate things. I can imagine that control plane and potentially its wire format can be together in one document (but I'm still not convinced that the a wire format is necessary), but session signaling functionality itself should be certainly separate from that. Let's keep discussion about the wire format for later, there is even more significant issue ahead of us: > Session signaling is just a control plane for DNS. It's useful. I > would like to see it done sooner rather than later. If we are not > going to do it sooner rather than later, I would like the reason to be > something more than vague unease about walking backwards into a new wire > format. The problem is that current proposal is creating some generic "control DNS plane" as by-product of session signaling functionality, as we were discussion during dnsop session. (References: "Totally flexible format" & "Concerned with embedding DNS messages in TLVs" in [2].) I believe that we really should not invent such generic mechanisms as by-products. If a WG agrees that a generic DNS control plane is needed, then it needs to be carefuly designed and described, including problem statement and analysis related to current and potential new transports. These are compleretely missing now. Moreover, the dnsop is specifically chartered to subset of possible changes [1] to the DNS protocol: 4. Publish documents to address operational issues with the DNS protocols by extending or performing protocol maintenance on them. Act as focal-point for operator discussion and provide advice to the Ops ADs and other WGs on EDNS0 options, new RRTYPEs, DNSSEC, record synthesis, or other mechanics of extending DNS to support other applications. 5. Serve as a home for drafts that document the problem space around existing or new DNS issues. The group, with the advice and consent of the responsible AD in coordination with other areas, will then decide whether these issues belong in DNSOP under the existing charter and, if not, will work with the authors and appropriate ADs to determine the proper place for the work to be carried out. For me, adding control plane is just stretching this definition too far. If session signaling is covered by this charter then we must admit that dnsop can do anything it wants to the DNS protocol. [1] http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ [2] https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop Again: If there is a need for a "DNS control plane" then it should be enginered as such and not invented as by-product of something else. Yes, it is a lot of work. And yes, it should start with problem statement for control plane (in general) and continue from there. I hope it explains why I still do not like the current proposal. Thank you for your attention. Petr Špaček @ CZ.NIC > > On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček > wrote: > > On 20.7.2017 19:09, Andrew Sullivan wrote: > > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > >>> But it's certainly another step along the way to DNSbis by accident. > >> > >> Would it be useful to make it not "by accident"? > > > > Yes. That was basically the point I was trying to make at the > > beginning of today's session, about overall analysis. > > > > > b) make this draft DNS-SD only, so it can fast forward... > >> > > > > I'm not keen on this. > > > > > >> c) use the changed paradigm to work on DNSbis without the accident part? > > Yes please! > > My main opposition comes from fact that current session signaling draft > "accidentaly" defines new protocol which is using the old DNS-RFC1035 as > "transport". > > I would welcome DNSbis effort with clear cut. Here please note that > clear cut does not mean that RR format and data, for example, has to be > incompatible! > > It is still possible to share big chunks of specifications (like RR > definitions, namespace, etc.) but define a DNSbis protocol which is > clearly distinguishable from the old DNS. > > Petr Špaček @ CZ.NIC > > > I'm starting to wonder whether a bof is needed. Maybe the IAB's > > workshop will produce some fruit? From nobody Thu Aug 10 04:45:54 2017 Return-Path: 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 61AF3132699 for ; Thu, 10 Aug 2017 04:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 oc9cBCPlrtzB for ; Thu, 10 Aug 2017 04:45:51 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6876812741D for ; Thu, 10 Aug 2017 04:45:51 -0700 (PDT) Received: from [10.242.2.31] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 75FF31C7D5; Thu, 10 Aug 2017 13:45:48 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Thu, 10 Aug 2017 13:45:47 +0200 Message-ID: <15B4EE8E-CE83-42F4-9FC5-2E6FB58C2AA9@powerdns.com> In-Reply-To: <20170802233921.BEDA280D9BB0@rock.dv.isc.org> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <20170802012345.2CE2680BCC5E@rock.dv.isc.org> <121adcc6-55c5-4f90-2797-999f3f1f1ef8@eff.org> <2ef550a8-3e55-7fa0-9e00-fdf07093b25e@eff.org> <20170802233921.BEDA280D9BB0@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 11:45:53 -0000 Hello Mark, On 3 Aug 2017, at 1:39, Mark Andrews wrote: > Most OS's don't treat localhost specially. It is just a entry in > /etc/hosts and/or a zone in the local recursive server and/or > localhost. in a zone on the search list. The last of these > is how localhost is actually resolved on my machine (MacOS 10.12.6) > as the resolver doesn't treat "localhost" as special. It's processed > the same way as any other single label name. localhost entries in zones are dangerous and should (MUST?) be removed. = Having them present allows exploits like = https://googleprojectzero.blogspot.nl/2015/06/owning-internet-printing-ca= se-study-in.html = to reach beyond the vulnerable software, into the context of your = domain. On a sidenote, my Mac does not send out queries for localhost. I=E2=80=99= m = unsure if this is due to /etc/hosts or due to special casing in the = stub. Kind regards, -- = Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Thu Aug 10 05:43:47 2017 Return-Path: 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 10248132192 for ; Thu, 10 Aug 2017 05:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 vM8LwX6FQzit for ; Thu, 10 Aug 2017 05:43:42 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 184001326A8 for ; Thu, 10 Aug 2017 05:43:42 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id u185so2581194pgb.1 for ; Thu, 10 Aug 2017 05:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k6wr3+epEhTIG4EDyqjDYChE6HAgrdTLnB6DACR++ro=; b=Nk/S3wU9JbvhCZE3yymHwHcjq5PhdfoC34n49c/XA9ZKJKUqSI0yC+9GzoZquqHh/n /Rt60JhJDJ8J0faRZ/KGzyvpi7khE3SBDA7d1EjOpXUrHcMgG+IL8ofuqhZ0UuLLnVad uc2hzc5o7cIO/npnb5uZ8d3R3kFmas9JqqezypVxHgPGK7mLuf4yIVIOGnN97lxnJtOr Tqg8BBBzFWbKN8rVk0ISxuJKhKEuRudJrjH8KudjfCYRLb0dKzzk+NWXvlZeErfunoNu efELmIDeKGw5lladwizJhUE6lnH7PXI2HKv44HX9GslFMwXBDDf/rKoAiWkwOcVCT1eF ehMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k6wr3+epEhTIG4EDyqjDYChE6HAgrdTLnB6DACR++ro=; b=Elg7+0LV8SII+CZ15zyatu61/HagPb8k+xJn7xtw4gdblVVuKHy6bQux+/U6bXS9h0 UtCXYjzLwyhU8JsQSby8b9u3pGHvBqOGWiSn/Uhzdc4i7Yl+YYmSUrsDDmQ59NBDyZsV SA6MSInAkln2my7O7qJj7deRW3L0W+9JyPkDvW7MLdQfVnuJCPbXX2xWY8KvrOM8YddW tB1sJC3mLb3BtlKZh6/RYiSV5rrpVcuyAlf0VuxMBTqzDrcMe1FD4I3RfZvf0p5QX3YN LEIArT/HYvGxrcp5DqKfuxmcXXDNFYCTwYvub9ih5JF5AUCtHIh1EJgvB/JZCF8RHZ01 z/YQ== X-Gm-Message-State: AHYfb5hRu3wEz8z4SWfbIugHbIuKNg66HRA+JRPF/0GY01GsEOse7Lyb 88UoN9L1ssmP0L6ybwMcM+bGHpnPOMGP X-Received: by 10.84.167.2 with SMTP id c2mr13336878plb.368.1502369021443; Thu, 10 Aug 2017 05:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Thu, 10 Aug 2017 05:43:00 -0700 (PDT) In-Reply-To: References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> From: Ted Lemon Date: Thu, 10 Aug 2017 08:43:00 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop WG , "dnsop-chairs@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c145baed854a00556658ba9" Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 12:43:46 -0000 --94eb2c145baed854a00556658ba9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Petr, forgive me for holding your feet to the fire on this, but you make several statements along the lines of "for me, ... is stretching the definition too far," "I disgree that this is less significant," et cetera, but you don't actually raise any technical objections=E2=80=94you just expr= essed uneasy feelings, with which I don't think the working group is competent to help you. Your claim that this is a new wire format is incorrect. What it would mean for this to be a new wire format is that it is incompatible with the existing wire format. Doing something like that is an interesting job that is potentially worth working on, but would have a very long deployment window, if it got deployed at all. What we are proposing here is not a new wire format. It is compatible with, and enhances, the existing wire format. As for whether the working group should in fact undertake some grand design process for such a format, I don't have a strong opinion, but the first question I would raise is simply this: do *you* want to undertake such an effort? If the answer is yes, can you give me a sense of what your goals are? The reason I ask is that IETF working groups are constrained to do work that participants are willing to do, and thus far we have seen no evidence that you are interested in working on this document, which has been a working group document for a year. As for whether this document is in charter, what we are proposing is certainly in scope for the working group=E2=80=94it's very clearly an opera= tional enhancement for DNS in streaming protocols. It doesn't change the way you do DNS queries=E2=80=94it just adds some new capabilities for new implement= ations. I think it's very clearly useful=E2=80=94we already have three use cases = for it. If we were to stop work on this document now, the work that now relies on it would revert to what had been proposed earlier, which was not as good=E2=80=94dnssd has been hanging fire waiting for this work to be done b= ecause the working group wanted to cooperate with dnsop in producing something more generally useful, rather than doing a one-off extension like Apple's DNS Long-Lived Queries, which was never standardized. So if there is something missing from the document, or something unclear, or you wish we'd thought of ???, or think that !!! is not quite right and have suggestions, I think that would be really helpful. And of course the working group chairs are free to agree with your vague feelings of unease and drop this as a working group document. But as for any sort of specific request that the authors or the working group could act on, I am not hearing anything of that sort in what you have said. Can you think about this in that context, and see if you can more clearly articulate what it is that you find lacking in this proposal, so that the working group can figure out how to fix it? Can you do it soon? Thanks! On Thu, Aug 10, 2017 at 7:28 AM, Petr =C5=A0pa=C4=8Dek = wrote: > Hello Ted and dnsop, > > and sorry for delayed answer (below). Your message forced me to think > more about the draft, this time without focus on the wire format. > > Spoiler alert: I still do not like the proposal in its current form. > Please see below. > > On 21.7.2017 10:22, Ted Lemon wrote: > > I am hearing from a number of people that this is "a new protocol" and > > hence requires careful thought and perhaps a new working group, along > > with the associated delay. I do not _entirely_ disagree with this > > position, although it would be really inconvenient from my perspective. > > > > However, I would like to point out that the objection "it is a new > > protocol" is not a technical objection. Also, the same objection can > > actually much more justly be raised against several other proposals tha= t > > were brought before the working group. For example, the multiple > > RRtypes proposal, the multiple responses proposal, and the extended > > error codes proposal. > > > > All of these define new protocol, in ways that are in, like session > > signaling, backward-compatible with the existing protocol. The other > > proposals are actually much more significant changes than session > > signaling is, in terms of what they actually do, as opposed to what > > their wire format is. > > Okay, I can see what you mean - there surely are various levels of > complexity and protocol changes proposed in the last years for dnsop. > > However I disagree that adding session signalling to DNS is less > significant change than e.g. multi-query/repose proposals. > > As you said, session signalling is a "control plane for DNS", which is a > very new thing. Keeping (IMHO significant) wire format issues aside, > adding a control plane to DNS is in my eyes a significant new > development and should be treated as such. > > > > And as for a new DNS wire format, which I also think would be a good > > idea, this is pretty clearly /not /what session signaling is. How > > would you do a DNS query with session signaling? In what way would it > > be an improvement over the existing query format? It's possible that = a > > new wire format can be built on top of session signaling, but session > > signaling doesn't build a new wire format, and if we choose to do > > session signaling, that doesn't preclude doing a different wire format > > for queries later. > > Maybe one of the problems is that the current draft mixes three > things in a single document: > - The new wire format, > - DNS control plane, > - Session signaling functionality over the control plane. > This is probably making things way harder to explain to non-authors than > necessary. > > These really are separate things. I can imagine that control plane > and potentially its wire format can be together in one document (but I'm > still not convinced that the a wire format is necessary), but session > signaling functionality itself should be certainly separate from that. > > > Let's keep discussion about the wire format for later, there is even > more significant issue ahead of us: > > > Session signaling is just a control plane for DNS. It's useful. I > > would like to see it done sooner rather than later. If we are not > > going to do it sooner rather than later, I would like the reason to be > > something more than vague unease about walking backwards into a new wir= e > > format. > > The problem is that current proposal is creating some generic "control > DNS plane" as by-product of session signaling functionality, as we were > discussion during dnsop session. > (References: "Totally flexible format" & "Concerned with embedding DNS > messages in TLVs" in [2].) > > I believe that we really should not invent such generic mechanisms as > by-products. > > If a WG agrees that a generic DNS control plane is needed, then it needs > to be carefuly designed and described, including problem statement and > analysis related to current and potential new transports. These are > compleretely missing now. > > > Moreover, the dnsop is specifically chartered to subset of possible > changes [1] to the DNS protocol: > > 4. Publish documents to address operational issues with the DNS > protocols by extending or performing protocol maintenance > on them. Act as focal-point for operator discussion and provide > advice to the Ops ADs and other WGs on EDNS0 options, new > RRTYPEs, DNSSEC, record synthesis, or other mechanics of > extending DNS to support other applications. > > 5. Serve as a home for drafts that document the problem space > around existing or new DNS issues. The group, with the advice > and consent of the responsible AD in coordination with other areas, > will then decide whether these issues belong in DNSOP under > the existing charter and, if not, will work with the authors and > appropriate ADs to determine the proper place for the work to be > carried out. > > For me, adding control plane is just stretching this definition too far. > If session signaling is covered by this charter then we must admit > that dnsop can do anything it wants to the DNS protocol. > > [1] http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xK= Q > > [2] https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop > > > Again: > If there is a need for a "DNS control plane" then it should be enginered > as such and not invented as by-product of something else. > > Yes, it is a lot of work. And yes, it should start with problem > statement for control plane (in general) and continue from there. > > > I hope it explains why I still do not like the current proposal. > Thank you for your attention. > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > > > > On Fri, Jul 21, 2017 at 10:02 AM, Petr =C5=A0pa=C4=8Dek > > wrote: > > > > On 20.7.2017 19:09, Andrew Sullivan wrote: > > > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ond=C5=99ej Sur=C3=BD w= rote: > > >>> But it's certainly another step along the way to DNSbis by > accident. > > >> > > >> Would it be useful to make it not "by accident"? > > > > > > Yes. That was basically the point I was trying to make at the > > > beginning of today's session, about overall analysis. > > > > > > > b) make this draft DNS-SD only, so it can fast forward... > > >> > > > > > > I'm not keen on this. > > > > > > > > >> c) use the changed paradigm to work on DNSbis without the > accident part? > > > > Yes please! > > > > My main opposition comes from fact that current session signaling > draft > > "accidentaly" defines new protocol which is using the old > DNS-RFC1035 as > > "transport". > > > > I would welcome DNSbis effort with clear cut. Here please note that > > clear cut does not mean that RR format and data, for example, has t= o > be > > incompatible! > > > > It is still possible to share big chunks of specifications (like RR > > definitions, namespace, etc.) but define a DNSbis protocol which is > > clearly distinguishable from the old DNS. > > > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > > > I'm starting to wonder whether a bof is needed. Maybe the IAB's > > > workshop will produce some fruit? > --94eb2c145baed854a00556658ba9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Petr, forgive me for holding your feet to the fire on this= , but you make several statements along the lines of "for me, ... is s= tretching the definition too far," "I disgree that this is less s= ignificant," et cetera, but you don't actually raise any technical= objections=E2=80=94you just expressed uneasy feelings, with which I don= 9;t think the working group is competent to help you.=C2=A0 Your claim that= this is a new wire format is incorrect. =C2=A0 What it would mean for this= to be a new wire format is that it is incompatible with the existing wire = format. =C2=A0 Doing something like that is an interesting job that is pote= ntially worth working on, but would have a very long deployment window, if = it got deployed at all.

What we are proposing here is no= t a new wire format.=C2=A0 It is compatible with, and enhances, the existin= g wire format.

As for whether the working group sh= ould in fact undertake some grand design process for such a format, I don&#= 39;t have a strong opinion, but the first question I would raise is simply = this: do you=C2=A0want to undertake such an effort? =C2=A0 If the an= swer is yes, can you give me a sense of what your goals are?=C2=A0 The reas= on I ask is that IETF working groups are constrained to do work that partic= ipants are willing to do, and thus far we have seen no evidence that you ar= e interested in working on this document, which has been a working group do= cument for a year.

As for whether this document is= in charter, what we are proposing is certainly in scope for the working gr= oup=E2=80=94it's very clearly an operational enhancement for DNS in str= eaming protocols. =C2=A0 It doesn't change the way you do DNS queries= =E2=80=94it just adds some new capabilities for new implementations. =C2=A0= I think it's very clearly useful=E2=80=94we already have three use cas= es for it. =C2=A0 If we were to stop work on this document now, the work th= at now relies on it would revert to what had been proposed earlier, which w= as not as good=E2=80=94dnssd has been hanging fire waiting for this work to= be done because the working group wanted to cooperate with dnsop in produc= ing something more generally useful, rather than doing a one-off extension = like Apple's DNS Long-Lived Queries, which was never standardized.

So if there is something missing from the document, or= something unclear, or you wish we'd thought of ???, or think that !!! = is not quite right and have suggestions, I think that would be really helpf= ul. =C2=A0 And of course the working group chairs are free to agree with yo= ur vague feelings of unease and drop this as a working group document.

But as for any sort of specific request that the autho= rs or the working group could act on, I am not hearing anything of that sor= t in what you have said. =C2=A0 Can you think about this in that context, a= nd see if you can more clearly articulate what it is that you find lacking = in this proposal, so that the working group can figure out how to fix it? = =C2=A0 Can you do it soon?

Thanks!

On Thu, Aug 10, 2017 = at 7:28 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrot= e:
Hello Ted and dnsop,

and sorry for delayed answer (below). Your message forced me to think
more about the draft, this time without focus on the wire format.

Spoiler alert: I still do not like the proposal in its current form.
Please see below.

On 21.7.2017 10:22, Ted Lemon wrote:
> I am hearing from a number of people that this is "a new protocol= " and
> hence requires careful thought and perhaps a new working group, along<= br> > with the associated delay.=C2=A0 =C2=A0I do not _entirely_ disagree wi= th this
> position, although it would be really inconvenient from my perspective= .
>
> However, I would like to point out that the objection "it is a ne= w
> protocol" is not a technical objection.=C2=A0 Also, the same obje= ction can
> actually much more justly be raised against several other proposals th= at
> were brought before the working group.=C2=A0 =C2=A0For example, the mu= ltiple
> RRtypes proposal, the multiple responses proposal, and the extended > error codes proposal.
>
> All of these define new protocol, in ways that are in, like session > signaling, backward-compatible with the existing protocol.=C2=A0 =C2= =A0The other
> proposals are actually much more significant changes than session
> signaling is, in terms of what they actually do, as opposed to what > their wire format is.

Okay, I can see what you mean - there surely are various levels of complexity and protocol changes proposed in the last years for dnsop.

However I disagree that adding session signalling to DNS is less
significant change than e.g. multi-query/repose proposals.

As you said, session signalling is a "control plane for DNS", whi= ch is a
very new thing. Keeping (IMHO significant) wire format issues aside,
adding a control plane to DNS is in my eyes a significant new
development and should be treated as such.


> And as for a new DNS wire format, which I also think would be a good > idea, this is pretty clearly /not /what session signaling is.= =C2=A0 =C2=A0How
> would you do a DNS query with session signaling?=C2= =A0 =C2=A0In what way would it
> be an improvement over the existing query format?=C2=A0 =C2=A0It's= possible that a
> new wire format can be built on top of session signaling, but session<= br> > signaling doesn't build a new wire format, and if we choose to do<= br> > session signaling, that doesn't preclude doing a different wire fo= rmat
> for queries later.

Maybe one of the problems is that the current draft mixes three
things in a single document:
- The new wire format,
- DNS control plane,
- Session signaling functionality over the control plane.
This is probably making things way harder to explain to non-authors than necessary.

These really are separate things. I can imagine that control plane
and potentially its wire format can be together in one document (but I'= m
still not convinced that the a wire format is necessary), but session
signaling functionality itself should be certainly separate from that.


Let's keep discussion about the wire format for later, there is even more significant issue ahead of us:

> Session signaling is just a control plane for DNS.=C2=A0 =C2=A0It'= s useful.=C2=A0 =C2=A0I
> would like to see it done sooner rather than later.=C2=A0 =C2=A0If we = are not
> going to do it sooner rather than later, I would like the reason to be=
> something more than vague unease about walking backwards into a new wi= re
> format.

The problem is that current proposal is creating some generic "= control
DNS plane" as by-product of session signaling functionality, as we wer= e
discussion during dnsop session.
(References: "Totally flexible format" & "Concerned with= embedding DNS
messages in TLVs" in [2].)

I believe that we really should not invent such generic mechanisms as
by-products.

If a WG agrees that a generic DNS control plane is needed, then it needs to be carefuly designed and described, including problem statement and
analysis related to current and potential new transports. These are
compleretely missing now.


Moreover, the dnsop is specifically chartered to subset of possible
changes [1] to the DNS protocol:

4. Publish documents=C2=A0 to address operational issues with the DNS
=C2=A0 =C2=A0 protocols by=C2=A0 extending or performing protocol maintenan= ce
=C2=A0 =C2=A0 on them.=C2=A0 Act as=C2=A0 focal-point for operator discussi= on and provide
=C2=A0 =C2=A0 advice to the Ops ADs and other WGs on EDNS0 options,=C2=A0 n= ew
=C2=A0 =C2=A0 RRTYPEs, DNSSEC,=C2=A0 record synthesis, or other mechanics o= f
=C2=A0 =C2=A0 extending DNS to support other applications.

5. Serve as a home for drafts that document the problem space
=C2=A0 =C2=A0around existing or new DNS issues.=C2=A0 The group, with the a= dvice
=C2=A0 =C2=A0and consent of the responsible AD in coordination with other a= reas,
=C2=A0 =C2=A0will then decide whether these=C2=A0 issues belong in DNSOP=C2= =A0 under
=C2=A0 =C2=A0the existing charter and, if not,=C2=A0 will work with the aut= hors and
=C2=A0 =C2=A0appropriate ADs to determine the proper place for the work to = be
=C2=A0 =C2=A0carried out.

For me, adding control plane is just stretching this definition too far. If session signaling is covered by this charter then we must admit
that dnsop can do anything it wants to the DNS protocol.

[1] http://mailarchive.ietf.or= g/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ

[2] https://datatracker.ietf.org/<= wbr>meeting/99/materials/minutes-99-dnsop


Again:
If there is a need for a "DNS control plane" then it should be en= ginered
as such and not invented as by-product of something else.

Yes, it is a lot of work. And yes, it should start with problem
statement for control plane (in general) and continue from there.


I hope it explains why I still do not like the current proposal.
Thank you for your attention.

Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC


>
> On Fri, Jul 21, 2017 at 10:02 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz
> <mailto:petr.spacek@nic.cz>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 20.7.2017 19:09, Andrew Sullivan wrote:
>=C2=A0 =C2=A0 =C2=A0> On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ond= =C5=99ej Sur=C3=BD wrote:
>=C2=A0 =C2=A0 =C2=A0>>> But it's certainly another step al= ong the way to DNSbis by accident.
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> Would it be useful to make it not "by= accident"?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Yes.=C2=A0 That was basically the point I was = trying to make at the
>=C2=A0 =C2=A0 =C2=A0> beginning of today's session, about overal= l analysis.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 > b) make this draft DNS-SD only, so = it can fast forward...
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I'm not keen on this.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>> c) use the changed paradigm to work on DNS= bis without the accident part?
>
>=C2=A0 =C2=A0 =C2=A0Yes please!
>
>=C2=A0 =C2=A0 =C2=A0My main opposition comes from fact that current ses= sion signaling draft
>=C2=A0 =C2=A0 =C2=A0"accidentaly" defines new protocol which = is using the old DNS-RFC1035 as
>=C2=A0 =C2=A0 =C2=A0"transport".
>
>=C2=A0 =C2=A0 =C2=A0I would welcome DNSbis effort with clear cut. Here = please note that
>=C2=A0 =C2=A0 =C2=A0clear cut does not mean that RR format and data, fo= r example, has to be
>=C2=A0 =C2=A0 =C2=A0incompatible!
>
>=C2=A0 =C2=A0 =C2=A0It is still possible to share big chunks of specifi= cations (like RR
>=C2=A0 =C2=A0 =C2=A0definitions, namespace, etc.) but define a DNSbis p= rotocol which is
>=C2=A0 =C2=A0 =C2=A0clearly distinguishable from the old DNS.
>
>=C2=A0 =C2=A0 =C2=A0Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC
>
>=C2=A0 =C2=A0 =C2=A0> I'm starting to wonder whether a bof is ne= eded.=C2=A0 Maybe the IAB's
>=C2=A0 =C2=A0 =C2=A0> workshop will produce some fruit?

--94eb2c145baed854a00556658ba9-- From nobody Thu Aug 10 06:31:04 2017 Return-Path: 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 587F9132153; Thu, 10 Aug 2017 06:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qDwx1993Gwzy; Thu, 10 Aug 2017 06:30:44 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EF81326B5; Thu, 10 Aug 2017 06:30:44 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B840FB81B5A; Thu, 10 Aug 2017 06:30:30 -0700 (PDT) To: Ondrej.Caletka@cesnet.cz, olafur+ietf@cloudflare.com, pwouters@redhat.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: warren@kumari.net, iesg@ietf.org, dnsop@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170810133030.B840FB81B5A@rfc-editor.org> Date: Thu, 10 Aug 2017 06:30:30 -0700 (PDT) Archived-At: Subject: [DNSOP] [Errata Verified] RFC8078 (5049) X-BeenThere: dnsop@ietf.org 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: Thu, 10 Aug 2017 13:30:50 -0000 The following errata report has been verified for RFC8078, "Managing DS Records from the Parent via CDS/CDNSKEY". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5049 -------------------------------------- Status: Verified Type: Technical Reported by: Ondřej Caletka Date Reported: 2017-06-23 Verified by: Warren Kumari (IESG) Section: 4 Original Text ------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 0 CDNSKEY 0 3 0 0 The keying material payload is represented by a single 0. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X 0" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 0" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 0"; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Corrected Text -------------- The contents of the CDS or CDNSKEY RRset MUST contain one RR and only contain the exact fields as shown below. CDS 0 0 0 00 CDNSKEY 0 3 0 AA== The keying material payload is represented by a single octet with the value 00. This record is signed in the same way as regular CDS/CDNSKEY RRsets are signed. Strictly speaking, the CDS record could be "CDS X 0 X X" as only the DNSKEY algorithm is what signals the DELETE operation, but for clarity, the "0 0 0 00" notation is mandated -- this is not a definition of DS digest algorithm 0. The same argument applies to "CDNSKEY 0 3 0 AA=="; the value 3 in the second field is mandated by [RFC4034], Section 2.1.2. Notes ----- RFC 7344 defines both CDS and CDNSKEY record wire and presentation format to be identical to DS and DNSKEY wire and presentation format defined in RFC 4034. In case of CDNSKEY record, RFC 4034 section 2.2 requires that: > The Public Key field MUST be represented as a Base64 encoding of the Public Key. As Base64 encoding encodes 6 bits into one character, one character alone can never be a valid Base64 sequence. The proper encoding of one-byte long sequence with binary value of 00 is AA==. In case of CDS record, RFC 4034 section 5.3 requires that: > The Digest MUST be represented as a sequence of case-insensitive hexadecimal digits Although the value of a single 0 fulfils this requirement per se, it's not properly parsable by many implementations since it is expected to be even number of hex digits to align with octet boundaries in the wire format. So proper form of CDS record should contain two zeroes in place of the digest. [ AD Note: Discussion on the DNSOP list: - https://www.ietf.org/mail-archive/web/dnsop/current/msg20267.html ] -------------------------------------- RFC8078 (draft-ietf-dnsop-maintain-ds-06) -------------------------------------- Title : Managing DS Records from the Parent via CDS/CDNSKEY Publication Date : March 2017 Author(s) : O. Gudmundsson, P. Wouters Category : PROPOSED STANDARD Source : Domain Name System Operations Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Thu Aug 10 22:02:35 2017 Return-Path: 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 256FD131CE8 for ; Thu, 10 Aug 2017 22:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 69AyKe6_gLMj for ; Thu, 10 Aug 2017 22:02:26 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC17132423 for ; Thu, 10 Aug 2017 22:02:26 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i66so38274295wmg.0 for ; Thu, 10 Aug 2017 22:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0VWUDImnK9woM8iPH3MUDfarr61QG95GU87ZS+RXFto=; b=JUpBjoQv/UwlgPVBoDmC+zAJgzXAIA1cFViSd7biui3b/5EckIrckfIT8KYKoBxy7c gDdCeUYGupYrJIxv0zvbAeBOnOzP6I2Pi+1yHISzmNHhVs9UohUAeb8eOL8F6AwgJz7z Zlza7FI6z8ePxa4NQYPKzXcpGy0OlnOpcIgvXAza+5yh9m1xF143t2AMtGeO14ma73kg iuJk3rKB/vOW1SXpFgsjkj0RprwKtoIBjtjmEcQKYNLvDVExtmZHegJLAH3Bc3kofHO7 JkFnS6wkKQcBxpR7v1WeNkhMyZT2Ky4gyEFtkdHzxoP26YlnNjV4PrYU2Sta0QBfOpiS m2pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0VWUDImnK9woM8iPH3MUDfarr61QG95GU87ZS+RXFto=; b=N6oqGU2YNDFIujkE92Qvb3MBAG/mYjrJKRBnklkPRb2OTAubsRbuBdrtPtLKGbHuSC kyT6Z5HQ+vHGv+BSRroClXZKBRSOTBQ0zqvPji/VMFOUFk3zER4rJdhTFrmksA2PDHFv 6VV94WSNMClAPZNuyITNfFQX0jVY92NC/z7AluOItb2gNi5Q+UzGNrpz9BglHE6kJ6w1 i6MzpJhmYtaOWZDHwsRkzF1FILZ//8+ANgGc4tT9lzWuHzfDMdAdeSdS4Dz9XWV6wOYg EL6qGC+txFOrIX29bn4IJTPjxLNawaHJB1mPFJKSjcwjnzSkZiuRlGv1aUv8Ohafooe3 dXYQ== X-Gm-Message-State: AHYfb5i6lKFY6ooq6ncvI/ZomzXtjEYj4cU+5nhGlRADC6BIkxRKcMBj mWXqsUUXrJtr957yY+CE5GeuBR8QOw== X-Received: by 10.80.146.5 with SMTP id i5mr13947956eda.48.1502427744761; Thu, 10 Aug 2017 22:02:24 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> In-Reply-To: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> From: Lanlan Pan Date: Fri, 11 Aug 2017 05:02:14 +0000 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= , dnsop Content-Type: multipart/alternative; boundary="f403045c0c4606fbb905567338f7" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 11 Aug 2017 05:02:29 -0000 --f403045c0c4606fbb905567338f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Petr, Thanks for your comments, :-) Petr =C5=A0pa=C4=8Dek =E4=BA=8E2017=E5=B9=B48=E6=9C=881= 0=E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8B=E5=8D=887:04=E5=86=99=E9=81=93=EF=BC= =9A > Hello, > > On 4.7.2017 05:54, Lanlan Pan wrote: > > Hi Tony, > > > > We try to solve similar wildcard problem. > > > > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards > > < > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6 > >) > > : > > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information. > > - cached deduced wildcard: give the default wildcard RR. > > > > SWILD: > > - Directly give "ALL SUBDOMAIN" information, and the default wildcard R= R. > > > > SWILD is applicable even when Authoritative Nameservers don't give > > NSEC/NSEC3 RR. > > SWILD is applicable on non-validating Forwarding Resolvers. > > If I understand it correctly: > - the only information added by SWILD RR is an explicit information > about the original (unexpanded) name of wildcard owner > - the very same information can be obtained from RRSIG RR in a > synthtetised answer (RRSIG labels < owner name labels) > - SWILD will work only if there are no nodes below the wildcard > Your analysis is totally right. Assuming this analysis is right, I'm against this proposal. > > We can get even better behavior from aggressive NSEC use. Here are > advantages of aggressive NSEC use: > - does not require changes to existing authoritatives or signed zones > - less fragile (if we consider manual SWILD specification as an option) > - supports wildcards with nodes below it > Yes, aggressive NSEC use has advantages if: 1) AUTH give NSEC RR. 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC aggressive use. > Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that > is okay: New features are provided only by the latest version of > the protocol. > But: 1) many wildcards occupy the Resolver cache, with no nodes below them. 2) many wildcards AUTH not give NSEC RR. 3) many resolvers not support DNSSEC validating, not to mention NSEC aggressive use. On the view of new feature, SWILD can be an alternative simpler choice to deploy. Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > > > > Regards, > > > > Tony Finch >=E4=BA=8E2017=E5=B9=B47= =E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=88 > > 8:18=E5=86=99=E9=81=93=EF=BC=9A > > > > Lanlan Pan > wrote: > > > > > > This document specifies a new SWILD RR type for Intermediate > > Nameservers to > > > cache subdomain wildcard record, in order to reduce the cache siz= e > and > > > optimize the wildcard domain cache miss. > > > > Isn't this functionality already provided by > > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ? > > > > Tony. > > -- > > f.anthony.n.finch > > > http://dotat.at/ - I xn--zr8h punycode > > Fitzroy: Variable 4 for a time in north, otherwise northeasterly > > becoming > > cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, > > occasionally > > poor. > > > > -- > > =E8=87=B4=E7=A4=BC Best Regards > > > > =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c0c4606fbb905567338f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Petr,

Thanks for your comments, :-)

Petr =C5=A0pa= =C4=8Dek <petr.spacek@nic.cz&g= t;=E4=BA=8E2017=E5=B9=B48=E6=9C=8810=E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8B= =E5=8D=887:04=E5=86=99=E9=81=93=EF=BC=9A
Hello,

On 4.7.2017 05:54, Lanlan Pan wrote:
> Hi Tony,
>
> We try to solve similar wildcard problem.
>
> NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> <https://tools.ietf= .org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6>)
> :
> - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> - cached deduced wildcard: give the default wildcard RR.
>
> SWILD:
> - Directly give "ALL SUBDOMAIN" information, and the default= wildcard RR.
>
> SWILD is applicable even when Authoritative Nameservers don't give=
> NSEC/NSEC3 RR.
> SWILD is applicable on non-validating Forwarding Resolvers.

If I understand it correctly:
- the only information added by SWILD RR is an explicit information
about the original (unexpanded) name of wildcard owner
- the very same information can be obtained from RRSIG RR in a
synthtetised answer (RRSIG labels < owner name labels)
- SWILD will work only if there are no nodes below the wildcard

Your analysis is totally right.

Assuming this analysis is right, I'm against this proposal.

We can get even better behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it
=C2=A0
=
Yes, aggressive NSEC use has advantages if:
1) AUTH give= NSEC RR.
2) Every Intermediate Resolver supports DNSSEC vali= dating and the NSEC aggressive use.

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that is okay: New features are provided only by the latest version of
the protocol.
But:
1) many wildcards occupy th= e Resolver cache, with no nodes below them.
2) many wildcards AUTH not g= ive NSEC RR.
3) many resolvers not support DNSSEC validating,= not to mention NSEC aggressive use.

On the view of new f= eature, SWILD can be an alternative simpler choice to deploy.

Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC


>
> Regards,
>
> Tony Finch <dot@d= otat.at <mailto:do= t@dotat.at>>=E4=BA=8E2017=E5=B9=B47=E6=9C=883=E6=97=A5=E5=91=A8= =E4=B8=80 =E4=B8=8B=E5=8D=88
> 8:18=E5=86=99=E9=81=93=EF=BC=9A
>
>=C2=A0 =C2=A0 =C2=A0Lanlan Pan <abbypan@gmail.com <mailto:abbypan@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This document specifies a new SWILD RR type fo= r Intermediate
>=C2=A0 =C2=A0 =C2=A0Nameservers to
>=C2=A0 =C2=A0 =C2=A0> cache subdomain wildcard record, in order to r= educe the cache size and
>=C2=A0 =C2=A0 =C2=A0> optimize the wildcard domain cache miss.
>
>=C2=A0 =C2=A0 =C2=A0Isn't this functionality already provided by >=C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
>
>=C2=A0 =C2=A0 =C2=A0Tony.
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0f.anthony.n.finch=C2=A0 <dot@dotat.at <mailto:dot@dotat.at>>
>=C2=A0 =C2=A0 =C2=A0http://dotat.at/=C2=A0 -=C2=A0 I xn--zr8h punycode
>=C2=A0 =C2=A0 =C2=A0Fitzroy: Variable 4 for a time in north, otherwise = northeasterly
>=C2=A0 =C2=A0 =C2=A0becoming
>=C2=A0 =C2=A0 =C2=A0cyclonic 5 to 7. Slight or moderate. Occasional rai= n. Moderate,
>=C2=A0 =C2=A0 =C2=A0occasionally
>=C2=A0 =C2=A0 =C2=A0poor.
>
> --
> =E8=87=B4=E7=A4=BC=C2=A0 Best Regards
>
> =E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
= =E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2= =A0 Pan Lanlan
--f403045c0c4606fbb905567338f7-- From nobody Fri Aug 11 07:39:56 2017 Return-Path: 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 60F9513239C for ; Fri, 11 Aug 2017 07:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 nCojDBE1uXw0 for ; Fri, 11 Aug 2017 07:39:53 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88EEA1324E6 for ; Fri, 11 Aug 2017 07:39:51 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id q25so15861447uah.1 for ; Fri, 11 Aug 2017 07:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=71zpqZyP6VmCrcplJiDWcjPf5KFJG7PXfaPsIL0EBPo=; b=QfvMWNFoErYbKSptjHebhk7SDOYt5vObGmm9PWGEC1nRcUJaNqiGIX5QFJQ+X92UXN kcBQNUhGLFMiMyY9gveJF4BRFSgM+xZxZp0Lz9SwPcFOVQu2EkJ5PbGdn1as7eUBrMGA 9TdlItqd+HherUoLAWA+OQwMeFW1y9I3N4/HYW8B9HhdXULQr0PqVQCehvjl6KsP66WD hGrhm+ktmL1lZF2NLFvA9tWadQ1Btis7ro8c8cNKZnt/ax6wCXKGsfE8gfrDeke44LMf ciXZxDJnQWSw0th9HrAMlHBR1h7Fm/mWVmvJrkUSsH84kc8uh6xcJuTrk4mbA5RoT3jY 3Y6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=71zpqZyP6VmCrcplJiDWcjPf5KFJG7PXfaPsIL0EBPo=; b=fHdy2BZxv/O2nFgexqlOmYHYdLjPBMkkQ6A5NcJwSoE6OMvh9qk0xU78K2uZJMDKyw ZZJrY+GOse+hh6uOjYYZhHLEm6RIyk8k7foOG+skbZNNdRyjLaFcAr/fdHFNK4tv8Y0I CgbPTACUNHiy69E5AAuy1nsAGwxRHuWQ/5MifxwrL5+ZQwhKL/ygun5gFt9VM/8888gm Rq4dy4TXGQzPlnstEXVt9G6wpu8Bdyh09io/7XUkhUDAGbOdmONPGhtU6Q4BtxoaRJeG IJGuzkIZHpcw4YeLzdB2n0TvtPpsOkn/1dzDToiuD4UlvGQZHk+bBzzq0OX4SOWDZ/w3 2p+g== X-Gm-Message-State: AHYfb5gdnn7Caq3SGCoGLbsXBENzWZsEFE41DbKOrQXOtQNqWszpBQcL +zGLo6EURv5w6Ossp5e70uUjblvBpsUA X-Received: by 10.176.81.137 with SMTP id g9mr11800864uaa.187.1502462390614; Fri, 11 Aug 2017 07:39:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.74 with HTTP; Fri, 11 Aug 2017 07:39:50 -0700 (PDT) In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> From: Matthew Pounsett Date: Fri, 11 Aug 2017 10:39:50 -0400 Message-ID: To: Lanlan Pan Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , dnsop , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="94eb2c1927aa15324205567b4946" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 11 Aug 2017 14:39:55 -0000 --94eb2c1927aa15324205567b4946 Content-Type: text/plain; charset="UTF-8" On 11 August 2017 at 01:02, Lanlan Pan wrote: > >> We can get even better behavior from aggressive NSEC use. Here are >> advantages of aggressive NSEC use: >> - does not require changes to existing authoritatives or signed zones >> - less fragile (if we consider manual SWILD specification as an option) >> - supports wildcards with nodes below it >> > > Yes, aggressive NSEC use has advantages if: > 1) AUTH give NSEC RR. > 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC > aggressive use. > It sounds like you're assuming that SWILD would be supported by caching servers that do not support DNSSEC or NSEC aggressive use. Why do you expect implementers would adopt SWILD before adopting these much older features? > > Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that >> is okay: New features are provided only by the latest version of >> the protocol. >> > But: > 1) many wildcards occupy the Resolver cache, with no nodes below them. > 2) many wildcards AUTH not give NSEC RR. > 3) many resolvers not support DNSSEC validating, not to mention NSEC > aggressive use. > > On the view of new feature, SWILD can be an alternative simpler choice to > deploy. > --94eb2c1927aa15324205567b4946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 11 August 2017 at 01:02, Lanlan Pan <abbypan@gmail.com> wrote:

We can get= even better behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it
=C2=A0
=
Yes, aggressive NSEC use has advantages if:
1) AU= TH give NSEC RR.
2) Every Intermediate Resolver supports DNSS= EC validating and the NSEC aggressive use.

It sounds like you're assuming that SWILD would b= e supported by caching servers that do not support DNSSEC or NSEC aggressiv= e use.=C2=A0 Why do you expect implementers would adopt SWILD before adopti= ng these much older features?
=C2=A0
=C2=A0
<= div>

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that is okay: New features are provided only by the latest version of
the protocol.
But:
1) many wildcards oc= cupy the Resolver cache, with no nodes below them.
2) many wildcards AUT= H not give NSEC RR.
3) many resolvers not support DNSSEC vali= dating, not to mention NSEC aggressive use.

On the view o= f new feature, SWILD can be an alternative simpler choice to deploy.
<= /div>
--94eb2c1927aa15324205567b4946-- From nobody Fri Aug 11 07:51:06 2017 Return-Path: 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 AD0D813268C for ; Fri, 11 Aug 2017 07:51:03 -0700 (PDT) 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 jBvEU-a7XaOv for ; Fri, 11 Aug 2017 07:51:02 -0700 (PDT) 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 6B98513268A for ; Fri, 11 Aug 2017 07:51:02 -0700 (PDT) Received: from [10.32.60.134] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7BEo4GD006103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Aug 2017 07:50:05 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.134] From: "Paul Hoffman" To: "Lanlan Pan" Cc: dnsop Date: Fri, 11 Aug 2017 07:51:02 -0700 Message-ID: In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 11 Aug 2017 14:51:04 -0000 On 11 Aug 2017, at 7:39, Matthew Pounsett wrote: > It sounds like you're assuming that SWILD would be supported by caching > servers that do not support DNSSEC or NSEC aggressive use. Why do you > expect implementers would adopt SWILD before adopting these much older > features? This is my top question on the document. --Paul HOffman From nobody Fri Aug 11 13:47:30 2017 Return-Path: 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 523BE132400 for ; Fri, 11 Aug 2017 13:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dyn.com 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 zF-HpRHubkVf for ; Fri, 11 Aug 2017 13:47:25 -0700 (PDT) Received: from mail-vk0-x245.google.com (mail-vk0-x245.google.com [IPv6:2607:f8b0:400c:c05::245]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04F8113231E for ; Fri, 11 Aug 2017 13:47:25 -0700 (PDT) Received: by mail-vk0-x245.google.com with SMTP id j7so17898285vki.6 for ; Fri, 11 Aug 2017 13:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QGsNB2ZsOif7W0JCoEK72rqKCRJX2TZSGCSPNcUQqCU=; b=koKN7iEHB3bPw6o3UHAOEmO9C9wiaVtXZSZGzFpGoOByZBzKUZ28k1M8FYuuPX7FzU Zy8e3gTbLzrS4UXNnmKDGEJ08gphSE9XSHBCU4yAZ0a51BYGEQRxacV09UJJion64HQw tijrE+QUzJpKcPv+qtpIjdzSCk2Pp9kBdX5xI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QGsNB2ZsOif7W0JCoEK72rqKCRJX2TZSGCSPNcUQqCU=; b=dZjDN7PmvlXMWkX5QEdcvmoj6hgkeAxbxJPTTKQmSXsd5j7CimkoPgelHZ7+UKo+c1 rZbdkxXkGpqbaMNrQeKYFizo5P7EEji4p3jIPYA2edOMwdK5iOPfyFbmg3NNXx8hDG+P jmP7v4MscNrA6tEgtlpvByJcem9dHsGaMrNV9GnO0ldDB1kASIrP/pPmK6L4vmyRGiQS 4haJRwOkITMlKmn3nidyXuKRr442BsRLomArbrVpUJiM0MDZq9fT6mTFwLOVoKBsWFbF D1LYZ4WxtjTV3xvZjUQQmfsvcqU7yxCYi9MdIo/IvMvTO9LYYPRCqVhT7T3S0Uv5J3O1 43Ug== X-Gm-Message-State: AHYfb5gdJSiEIZrR+6XIQ26Sr2S3//4bp/vt9g67v9X8FYwphr2ifmG9 cDb0b7ccjEX8vwEQtNPnrMxzpGqKY3XnAYjC/g== X-Received: by 10.31.5.18 with SMTP id 18mr9660744vkf.200.1502484444042; Fri, 11 Aug 2017 13:47:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.85.83 with HTTP; Fri, 11 Aug 2017 13:47:03 -0700 (PDT) In-Reply-To: <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> From: Richard Gibson Date: Fri, 11 Aug 2017 16:47:03 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="001a1143da04916bcd0556806bf0" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 11 Aug 2017 20:47:28 -0000 --001a1143da04916bcd0556806bf0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm assuming there's a very obvious answer to this question, but what would break if unsigned wildcard caching were covered by allowing DNSSEC-independent NSEC (and therefore https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )? $ cat zones/github.io ; apex records github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com= . 1 7200 900 1209600 86400 github.io. 900 IN NS ns-1339.awsdns-39.org. github.io. 900 IN NS ns-1622.awsdns-10.co.uk. github.io. 900 IN NS ns-393.awsdns-49.com. github.io. 900 IN NS ns-692.awsdns-22.net. github.io. 900 IN NS ns1.p16.dynect.net. github.io. 900 IN NS ns2.p16.dynect.net. github.io. 900 IN NS ns3.p16.dynect.net. github.io. 900 IN NS ns4.p16.dynect.net. github.io. 30 IN A 151.101.193.147 github.io. 30 IN A 151.101.129.147 github.io. 30 IN A 151.101.1.147 github.io. 30 IN A 151.101.65.147 github.io. 300 IN TXT "v=3Dspf1 a -all" ; wildcard answer records *.github.io. 3600 IN CNAME sni.github.map.fastly.net. ; aggressive-use signal covering LDH wildcard-synthesized names *.github.io. 3600 IN NSEC github.io. CNAME NSEC ; aggressive-use signal covering pre-* wildcard synthesized names (omitted to demonstrate selective application) ; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC $ dig @$resolver +noall +answer example.github.io. A ; positive answer with covering NSEC for aggressive use ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; ANSWER SECTION: example.github.io. 3600 IN CNAME sni.github.map.fastly.net. sni.github.map.fastly.net. 30 IN A 151.101.117.147 ;; AUTHORITY SECTION: *.github.io. 3600 IN NSEC github.io. CNAME NSEC $ dig @$resolver +noall +answer foo.github.io. A ; positive answer from cache ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; ANSWER SECTION: foo.github.io. 3590 IN CNAME sni.github.map.fastly.net. sni.github.map.fastly.net. 20 IN A 151.101.117.147 ;; AUTHORITY SECTION: *.github.io. 3590 IN NSEC github.io. CNAME NSEC $ dig @$resolver +noall +answer bar.github.io. AAAA ; negative answer from cache plus fresh SOA ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; AUTHORITY SECTION: github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com= . 1 7200 900 1209600 86400 *.github.io. 3579 IN NSEC github.io. CNAME NSEC $ dig @$resolver +noall +answer baz.github.io. AAAA ; negative answer from cache ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0 ;; AUTHORITY SECTION: github.io. 890 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com= . 1 7200 900 1209600 86400 *.github.io. 3569 IN NSEC github.io. CNAME NSEC $ dig @$resolver +noall +answer '\032.github.io.' A ; positive answer with non-covering NSEC (due to partial application; could be remedied by adding another NSEC to the zone) ;; ->>HEADER<<- opcode: QUERY, status: NOERROR ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0 ;; ANSWER SECTION: \032.github.io. 3600 IN CNAME sni.github.map.fastly.net. sni.github.map.fastly.net. 30 IN A 151.101.117.147 ;; AUTHORITY SECTION: *.github.io. 3600 IN NSEC github.io. CNAME NSEC On Thu, Aug 10, 2017 at 7:04 AM, Petr =C5=A0pa=C4=8Dek = wrote: > Hello, > > On 4.7.2017 05:54, Lanlan Pan wrote: > > Hi Tony, > > > > We try to solve similar wildcard problem. > > > > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards > > aggressiveuse-10#page-6>) > > : > > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information. > > - cached deduced wildcard: give the default wildcard RR. > > > > SWILD: > > - Directly give "ALL SUBDOMAIN" information, and the default wildcard R= R. > > > > SWILD is applicable even when Authoritative Nameservers don't give > > NSEC/NSEC3 RR. > > SWILD is applicable on non-validating Forwarding Resolvers. > > If I understand it correctly: > - the only information added by SWILD RR is an explicit information > about the original (unexpanded) name of wildcard owner > - the very same information can be obtained from RRSIG RR in a > synthtetised answer (RRSIG labels < owner name labels) > - SWILD will work only if there are no nodes below the wildcard > > Assuming this analysis is right, I'm against this proposal. > > We can get even better behavior from aggressive NSEC use. Here are > advantages of aggressive NSEC use: > - does not require changes to existing authoritatives or signed zones > - less fragile (if we consider manual SWILD specification as an option) > - supports wildcards with nodes below it > > Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that > is okay: New features are provided only by the latest version of > the protocol. > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > > > > Regards, > > > > Tony Finch >=E4=BA=8E2017=E5=B9=B47= =E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=88 > > 8:18=E5=86=99=E9=81=93=EF=BC=9A > > > > Lanlan Pan > wrote: > > > > > > This document specifies a new SWILD RR type for Intermediate > > Nameservers to > > > cache subdomain wildcard record, in order to reduce the cache siz= e > and > > > optimize the wildcard domain cache miss. > > > > Isn't this functionality already provided by > > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ? > > > > Tony. > > -- > > f.anthony.n.finch > > > http://dotat.at/ - I xn--zr8h punycode > > Fitzroy: Variable 4 for a time in north, otherwise northeasterly > > becoming > > cyclonic 5 to 7. Slight or moderate. Occasional rain. Moderate, > > occasionally > > poor. > > > > -- > > =E8=87=B4=E7=A4=BC Best Regards > > > > =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a1143da04916bcd0556806bf0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm assuming there's a very obvious answer to this= question, but what would break if unsigned wildcard caching were covered b= y allowing DNSSEC-independent NSEC (and therefore https://tools.ietf.org/h= tml/draft-ietf-dnsop-nsec-aggressiveuse )?

$ cat zon= es/github.io
; apex records
github.io. 900<= span style=3D"white-space:pre"> IN <= /span>NS ns1.p16.dynect.net.
github.io. 900 IN NS ns3.p16.dynect.net.
github.io. 30 IN A 151.101.193.147
github.io. 30 IN A 151.101.129.147=
github.io. 30 IN A 151.1= 01.1.147
github.io. 30 IN A 151.101.65.147
github.io. 300 IN TXT "v=3Dspf1 a -all"
; wildcard answer = records
; aggressive-use signal covering LDH wildcard-synthesi= zed names
*.github.io. 3600 I= N NSEC github.io. CNAME NSEC
; aggressive-use signal covering pre-* wildcard synthesized name= s (omitted to demonstrate selective application)
; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC

=
$ dig @$resolver +noall +answer e= xample.github.io. A =C2=A0 =C2=A0; positive answer with covering NSEC f= or aggressive use
;; ->>HEADER<<- opcode: QUERY, stat= us: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORIT= Y: 1, ADDITIONAL: 0
;; ANSWER SECTION:
<= div>sni.github.map.fastly.net<= /a>. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
<= /div>
*.github.io. 3600 IN NSEC = github.io. CNAME NSEC

$ dig=C2=A0@$resolver=C2=A0+noall +answer foo.github.io. A=C2=A0=C2=A0 =C2=A0; positive answer from= cache
;; ->>HEADER<<- opcode: QUERY, status: NO= ERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, = ADDITIONAL: 0
;; ANSWER SECTION:
sni.github.map.fastly.net. 20 IN<= span style=3D"white-space:pre"> A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. <= /span>3590 IN NSEC github.io. CNAME NSEC

$ dig=C2=A0@$resolver=C2=A0+noall +a= nswer bar.github.io. AAAA =C2=A0 =C2= =A0; negative answer from cache plus fresh SOA
;; ->>HEADER= <<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; = QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY= SECTION:
github.io. 900 = IN SOA ns-1622.awsdns-10.co.u= k. awsdns-hostmaster.am= azon.com. 1 7200 900 1209600 86400
*.github.io. 3579 IN N= SEC git= hub.io. CNAME NSEC


$ dig=C2=A0@$= resolver=C2=A0+noall +answer '\032.git= hub.io.' A =C2=A0 =C2=A0; positive answer with non-covering NSEC (d= ue to partial application; could be remedied by adding another NSEC to the = zone)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR<= br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITI= ONAL: 0
;; ANSWER SECTION:
sni.github.map.fastly.net. 30 IN A = 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

On Thu, Aug 10, 2017 at 7:04 AM, Petr =C5=A0pa=C4=8Dek <pet= r.spacek@nic.cz> wrote:
Hello,

On 4.7.2017 05:54, Lanlan Pan wrote:
> Hi Tony,
>
> We try to solve similar wildcard problem.
>
> NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> <https://too= ls.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#page-6>)
> :
> - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN= " information.
> - cached deduced wildcard: give the default wildcard RR.
>
> SWILD:
> - Directly give "ALL SUBDOMAIN" information, and the default= wildcard RR.
>
> SWILD is applicable even when Authoritative Nameservers don't give=
> NSEC/NSEC3 RR.
> SWILD is applicable on non-validating Forwarding Resolvers.

If I understand it correctly:
- the only information added by SWILD RR is an explicit information
about the original (unexpanded) name of wildcard owner
- the very same information can be obtained from RRSIG RR in a
synthtetised answer (RRSIG labels < owner name labels)
- SWILD will work only if there are no nodes below the wildcard

Assuming this analysis is right, I'm against this proposal.

We can get even better behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that is okay: New features are provided only by the latest version of
the protocol.

Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC


>
> Regards,
>
> Tony Finch <dot@dotat.at <ma= ilto:dot@dotat.at>>=E4=BA=8E= 2017=E5=B9=B47=E6=9C=883=E6=97=A5=E5=91=A8=E4=B8=80 =E4=B8=8B=E5=8D=88
> 8:18=E5=86=99=E9=81=93=EF=BC=9A
>
>=C2=A0 =C2=A0 =C2=A0Lanlan Pan <abbypan@gmail.com <mailto:abby= pan@gmail.com>> wrote:
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This document specifies a new SWILD RR type fo= r Intermediate
>=C2=A0 =C2=A0 =C2=A0Nameservers to
>=C2=A0 =C2=A0 =C2=A0> cache subdomain wildcard record, in order to r= educe the cache size and
>=C2=A0 =C2=A0 =C2=A0> optimize the wildcard domain cache miss.
>
>=C2=A0 =C2=A0 =C2=A0Isn't this functionality already provided by >=C2=A0 =C2=A0 =C2=A0https://tools= .ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse ?
>
>=C2=A0 =C2=A0 =C2=A0Tony.
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0f.anthony.n.finch=C2=A0 <dot@dotat.at <mailto:dot@dotat.at>>
>=C2=A0 =C2=A0 =C2=A0http://dotat.at/= =C2=A0 -=C2=A0 I xn--zr8h punycode
>=C2=A0 =C2=A0 =C2=A0Fitzroy: Variable 4 for a time in north, otherwise = northeasterly
>=C2=A0 =C2=A0 =C2=A0becoming
>=C2=A0 =C2=A0 =C2=A0cyclonic 5 to 7. Slight or moderate. Occasional rai= n. Moderate,
>=C2=A0 =C2=A0 =C2=A0occasionally
>=C2=A0 =C2=A0 =C2=A0poor.
>
> --
> =E8=87=B4=E7=A4=BC=C2=A0 Best Regards
>
> =E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan

________________= _______________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a1143da04916bcd0556806bf0-- From nobody Sat Aug 12 01:30:01 2017 Return-Path: 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 218C3132634 for ; Sat, 12 Aug 2017 01:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 j-3VpTZSlg6Z for ; Sat, 12 Aug 2017 01:29:57 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4E6132576 for ; Sat, 12 Aug 2017 01:29:57 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id i66so7770974wmg.0 for ; Sat, 12 Aug 2017 01:29:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fwdivLhDrZfFzFhwl30yCfAWtyZFnfBLJKxWynUIyIg=; b=aUoLom6n+cLtDpdH1suHJsVPgvp5xkpx+zg0tPAtF8pn0bxwIreaWkWecRrrgXyZIz KZhEj7qwkfwX96TI+ub7WMDbQ8Al6+lj5Hhw6yLgv5SlyEla8+zxVatlOELCyhvNbrRw G4JFXLgDk7jtMnDpRtBqR5t8mP4osijXRCyy0NIybXufLU5mdW5JN+uDm2tcmATEJjia cyup0rBv53jKuvPsbJtn7Gq8b+Nx/JHwVqCp2J2l6LaId7bfPQVYn30bYZeMrt+eJRRH WdoAvrMM9sJIEVFI+9ec6De0+nH3xh4AHILpKT/Ic0+PM+7wexH9KSPeC0pekUie3Nrp p9hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fwdivLhDrZfFzFhwl30yCfAWtyZFnfBLJKxWynUIyIg=; b=DRJuFylg34T8pBq0+gu9qLTbmTjpDlqHFjkBIWeMKSR/z3GG6C4SQQDDkAsLBfGwRx FYehCxSSHGjcJpKKnYnIJVo097gbWIoQII8tk+1T9FvskRRnpFdSZWSFA38Wqks3We5P MMDbNhzOsZX228hMajwKHOtaGO5Tcfk8RFY7REBYRiYniwo2mjmwFHxTukmRgaXz2774 Zaes8ijh1LuWfGYVr2skmNQDUDVpwzYXKjIW5F1BpebL4Va2eHBjqIWTu1A1Tkh/Dt2k J1J6+4gS9koZdIkA0Bw5Rq+X+1jiW3fq1D9DeoFiR7aRc175moVuA1z23Z7iKy1Gr6+V nC+w== X-Gm-Message-State: AHYfb5g71GJ5SDtMO8d4zj5dhZTJT6oVshy/RyM/g83tjitAccqnLo+f 55aQ/pNzTmC1renSbWy9sDfynL/6Ww== X-Received: by 10.80.215.7 with SMTP id t7mr17711616edi.19.1502526595892; Sat, 12 Aug 2017 01:29:55 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> In-Reply-To: From: Lanlan Pan Date: Sat, 12 Aug 2017 08:29:45 +0000 Message-ID: To: Matthew Pounsett , Paul Hoffman Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , dnsop , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="f403045dbe94038ccd05568a3cbf" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 08:30:00 -0000 --f403045dbe94038ccd05568a3cbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matthew =EF=BC=86 Paul, Good question, :-) SWILD is a feature just for recusive cache optimization, only dealing with the wildcard subdomain issue (with no nodes below). DNSSEC + NSEC aggressive is security feature, with cryptographic contents such as KSK/ZSK/NSEC/NSEC3/NSEC5/... My assumption is: *we can give recursive server an alternative solution for wildcard subdomain cache issue, not need to depend on DNSSEC.* Authoritative server just simply add one SWILD RR, not much deploy cost. Recursive server can add SWILD support if it has an interest in wildcard subdomain cache optimization, it is OPT-IN. *I don't expect implementers would adopt SWILD 100% before adopting DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can decide adopting or not, before or after, we won't pre-select for them.* Even if both Authoritative server and Recursive server support DNSSEC+NSEC aggressive, when will they configure default dns query with dnssec ? (for NSEC agreesive cached deduced wildcard) As old features, why DNSSEC + NSEC is not forthcoming global deployed ? (maybe an old question, tired of discussing) Both Authoritative server and Recursive server consider about the DNSSEC validation cost / DDoS. Authoritative's Zone Enumeration risk, NSEC -> NSEC3 -> NSEC5 -> ??? other reasons... For example, Google likes to support some optimized protocols/features, such as QUIC, SPDY, ... dig @ns1.google.com xxxxxxxx.google.com +dnssec , only return NXDOMAIN. Matthew Pounsett =E4=BA=8E2017=E5=B9=B48=E6=9C=8811=E6= =97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B=E5=8D=8810:39=E5=86=99=E9=81=93=EF=BC=9A > On 11 August 2017 at 01:02, Lanlan Pan wrote: > > >>> We can get even better behavior from aggressive NSEC use. Here are >>> advantages of aggressive NSEC use: >>> - does not require changes to existing authoritatives or signed zones >>> - less fragile (if we consider manual SWILD specification as an option) >>> - supports wildcards with nodes below it >>> >> >> Yes, aggressive NSEC use has advantages if: >> 1) AUTH give NSEC RR. >> 2) Every Intermediate Resolver supports DNSSEC validating and the NSEC >> aggressive use. >> > > It sounds like you're assuming that SWILD would be supported by caching > servers that do not support DNSSEC or NSEC aggressive use. Why do you > expect implementers would adopt SWILD before adopting these much older > features? > > > >> >> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that >>> is okay: New features are provided only by the latest version of >>> the protocol. >>> >> But: >> 1) many wildcards occupy the Resolver cache, with no nodes below them. >> 2) many wildcards AUTH not give NSEC RR. >> 3) many resolvers not support DNSSEC validating, not to mention NSEC >> aggressive use. >> >> On the view of new feature, SWILD can be an alternative simpler choice t= o >> deploy. >> > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045dbe94038ccd05568a3cbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matthew =EF=BC=86 Paul,
Good question, :-)

SWILD is a feature just for recusive cach= e optimization, only dealing with the wildcard subdomain issue (with no nod= es below).
DNSSEC + NSEC aggressive is security feature, with cryp= tographic contents such as KSK/ZSK/NSEC/NSEC3/NSEC5/...

<= /div>My assumption is: we can give recursive server an alternative solut= ion for wildcard subdomain cache issue, not need to depend on DNSSEC.
Authoritative server just simply add one SWILD RR, not much de= ploy cost.
Recursive server can add SWILD support if it has an interest = in wildcard subdomain cache optimization,=C2=A0 it is OPT-IN.

I d= on't expect implementers would adopt SWILD 100% before adopting = DNSSEC+NSEC aggressive. Just give an alternative choice, implementers ca= n decide adopting or not, before or after, we won't pre-select for = them.
Even if both Authoritative server and Recursive server support= =20 DNSSEC+NSEC aggressive, when will they configure default dns query with dns= sec ?=20 (for NSEC agreesive cached deduced wildcard)

As old features, why DNSSEC + NSEC is not forthcoming = global deployed ? (maybe an old question, tired of discussing)
Both Authoritative server and Recursive server consider about the DNSSEC = validation cost / DDoS.
Authoritative's Zone Enumeration = risk, NSEC -> NSEC3 -> NSEC5 -> ???
other reasons...=
For example, Google likes to support some optimized protocol= s/features, such as QUIC, SPDY, ...
dig @ns1.google.com xxxxxxxx.google.com +dnssec ,=C2=A0 on= ly return NXDOMAIN.

<= /div>
Matthew Pounsett <matt@conundrum.com= >=E4=BA=8E2017=E5=B9=B48=E6=9C=8811=E6=97=A5=E5=91=A8=E4=BA=94 =E4=B8=8B= =E5=8D=8810:39=E5=86=99=E9=81=93=EF=BC=9A
=
On 11 August 2017 at 01:0= 2, Lanlan Pan <abbypan@gmail.com> wrote:


We can get even bett= er behavior from aggressive NSEC use. Here are
advantages of aggressive NSEC use:
- does not require changes to existing authoritatives or signed zones
- less fragile (if we consider manual SWILD specification as an option)
- supports wildcards with nodes below it
=C2=A0
=
Yes, aggressive NSEC use has advantages if:
1) AU= TH give NSEC RR.
2) Every Intermediate Resolver supports DNSS= EC validating and the NSEC aggressive use.

It sounds like you'= re assuming that SWILD would be supported by caching servers that do not su= pport DNSSEC or NSEC aggressive use.=C2=A0 Why do you expect implementers w= ould adopt SWILD before adopting these much older features?
=C2=A0
=C2=A0

Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that is okay: New features are provided only by the latest version of
the protocol.
But:
1) many wildcards oc= cupy the Resolver cache, with no nodes below them.
2) many wildcards AUT= H not give NSEC RR.
3) many resolvers not support DNSSEC vali= dating, not to mention NSEC aggressive use.

On the view o= f new feature, SWILD can be an alternative simpler choice to deploy.
<= /div>
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5= =85=B0=C2=A0 Pan Lanlan
--f403045dbe94038ccd05568a3cbf-- From nobody Sat Aug 12 08:42:49 2017 Return-Path: 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 A75EA131D6B for ; Sat, 12 Aug 2017 08:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 6EY_RxYS5S0E for ; Sat, 12 Aug 2017 08:42:46 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F1412EC11 for ; Sat, 12 Aug 2017 08:42:46 -0700 (PDT) Received: from tums.local (dhcp-181.access.lah1.vix.su [24.104.150.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 86E6861FF3; Sat, 12 Aug 2017 15:42:44 +0000 (UTC) From: Paul Vixie To: dnsop@ietf.org Cc: Lanlan Pan , Matthew Pounsett , Paul Hoffman , Petr =?utf-8?B?xaBwYcSNZWs=?= , =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Date: Sat, 12 Aug 2017 15:42:42 +0000 Message-ID: <1659363.yAWSxLQAC2@tums.local> Organization: Vixie Freehold In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 15:42:48 -0000 On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote: > ... > > SWILD is a feature just for recusive cache optimization, only dealing with > the wildcard subdomain issue (with no nodes below). > DNSSEC + NSEC aggressive is security feature, with cryptographic contents > such as KSK/ZSK/NSEC/NSEC3/NSEC5/... > > My assumption is: *we can give recursive server an alternative solution for > wildcard subdomain cache issue, not need to depend on DNSSEC.* > Authoritative server just simply add one SWILD RR, not much deploy cost. > Recursive server can add SWILD support if it has an interest in wildcard > subdomain cache optimization, it is OPT-IN. > > *I don't expect implementers would adopt SWILD 100% before adopting > DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can > decide adopting or not, before or after, we won't pre-select for them.* we do, though, and we must. DNSSEC development began in 1996, and deployment is stalled due to lack of motivation. it is the IETF's position that DNSSEC is a public good in that it will enable a general world-wide security level that has always eluded the Internet. any DNSSEC feature that we decide to offer separately ("a la carte") is both a missed opportunity to increase the deployment of DNSSEC, and a self-inflicted wound that deliberately further stalls that deployment. noting that DNSSEC as a protocol is of atrociously low quality ("it's crap"), i am in no way defending the design itself. however, it does work, and we would be acting contrary to our own best interests ("folly") if we took up anything like SWILD, or allowed anything like SWILD on the individual track. failing that level of commitment, the IETF ought to kill DNSSEC altogether. this is very similar to the "shall we had IPv6's features to IPv4, since V6 is taking so long to deploy, and these features are badly needed?" debate. vixie From nobody Sat Aug 12 09:31:11 2017 Return-Path: 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 D1E1D13240D for ; Sat, 12 Aug 2017 09:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 0WLoX12XX1hT for ; Sat, 12 Aug 2017 09:31:07 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AEC1323AB for ; Sat, 12 Aug 2017 09:31:06 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id j189so21798683vka.0 for ; Sat, 12 Aug 2017 09:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6fFWV/b2iWcRSAOT32KpfuEw7EmL0Wk81vhuwg51AKY=; b=F11YhPYdZolFNQFm+dajMcLzg6c8hQ9aIkMgbECWiIhTpInsh9UtzPGT8Iwj2zGc+z VAfhrqYZ2INFCJeqAsJc2U6x/06irgf52xK/dwAclLoq196/ed6BDQ2qk80YpwXGRSHU e9QbKLt2C6KCIWA6aqKaFHC7iC/f/C4l8P3YjwdApTFIuFHCGQtiUj9ZAoD91tqFQrfS +XPM0yqNgBH2CvgboY3JL/EgttoNzEBqi7rhuqE3q71aSEwYKYDccjkREHRaN/YYCN+3 or/rtQbPFp7T8p/ZIkBXZdVlOASCbdvDKbAnufPLULrlXFc5FyKOG93IJoLva3HmfyBF VlWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6fFWV/b2iWcRSAOT32KpfuEw7EmL0Wk81vhuwg51AKY=; b=R54U1l4h5heDFlEW1R8FcXINenQ5aKLgGNhffeqrhktqPgztSv+5T8ZVXKZa8FSvk2 O56h4qYiAOyeCJMYb4KqB6eotxldW2axGOzEye6ZQpLVATE/GGnDFkm2/2kTuYH4asOa i+n8wKC/lFVVzg9RMmY3id1M3XDko65YU2wXaewHb8d41KwUjKaREv7vutTWZ7qfPOIc fQWgrGqd/Z78P/ZD51bO2WlnPSG2X6E+Kyp4nWHONbwr6bVdxi7ai5oSBpwhpGEIeu+3 Cb8DlDXAnJV9kpMXb//qRTSgRz9kLeNCDpLOnALES/ickiWiByFn7mpp+h5dCMVUamAL orgQ== X-Gm-Message-State: AHYfb5iVO2ITnlFLuDIHoKHKIgbD8kIRfa6VtBE0crpwy+YnQRSe049T RtvQgZAz9Im1tIEhnT22dw7905XNxLxY X-Received: by 10.31.65.151 with SMTP id o145mr11086750vka.208.1502555465172; Sat, 12 Aug 2017 09:31:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.74 with HTTP; Sat, 12 Aug 2017 09:31:04 -0700 (PDT) In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> From: Matthew Pounsett Date: Sat, 12 Aug 2017 12:31:04 -0400 Message-ID: To: Lanlan Pan Cc: Paul Hoffman , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , dnsop , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="001a114da76ac1ddde055690f4b5" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 16:31:10 -0000 --001a114da76ac1ddde055690f4b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 12 August 2017 at 04:29, Lanlan Pan wrote: > Hi Matthew =EF=BC=86 Paul, > > Good question, :-) > > SWILD is a feature just for recusive cache optimization, only dealing wit= h > the wildcard subdomain issue (with no nodes below). > DNSSEC + NSEC aggressive is security feature, with cryptographic contents > such as KSK/ZSK/NSEC/NSEC3/NSEC5/... > > My assumption is: *we can give recursive server an alternative solution > for wildcard subdomain cache issue, not need to depend on DNSSEC.* > Authoritative server just simply add one SWILD RR, not much deploy cost. > Recursive server can add SWILD support if it has an interest in wildcard > subdomain cache optimization, it is OPT-IN. > I confess it was a rhetorical question. All of the major implementations already support DNSSEC. 8198 doesn't have an implementation status section, but there's every reason to think the major implementations will have support within a version of two. A quick survey of a few issues databases shows that at least Knot is already working on it. That is a significant head start; SWILD support without DNSSEC support can't happen in any significant way, and SWILD support without support for 8198 doesn't seem likely. As for operator adoption, the incentives are all wrong for this to actually get used. Recursive operators already have a very low operational bar to turn on DNSSEC and get the same benefit to their cache. In both cases (SWILD and DNSSEC) they rely on the authoritative operator opting in before that benefit can be realized. Authoritative operators may choose to use DNSSEC because it will secure their zone, and if recursive operators also have 8198-capable name servers then the workload for both authoritative and recursive is reduced for all terminal names. With SWILD, there is no direct benefit to the authoritative operator, as far as I can see. Given that the only benefit to using SWILD is to the recursive operator, what is the motivation for the authoritative operator to add complexity to their deployment by adopting it? Traditional wildcards work fine for them. To make the adoption problem worse, it appears as if SWILD is more limited in its use than traditional wildcards. For example, I don't see how you could occlude an SWILD record with a more-specific domain name, as you can with traditional wildcards. Here's a common scenario based on the example from the draft: @ 86400 IN SWILD _ _ 3600 IN CNAME map.bar.net. * 600 IN CNAME _ dev 600 IN CNAME map.dev.bar.net. How does SWILD behave when a client queries for dev? According to the draft, the authoritative server would return the SWILD record at the apex. An SWILD-aware recursive server seems like it would ignore the CNAME returned for dev and instead use the CNAME for _, which is not what the operator intended. > > *I don't expect implementers would adopt SWILD 100% before adopting > DNSSEC+NSEC aggressive. Just give an alternative choice, implementers can > decide adopting or not, before or after, we won't pre-select for them.* > Even if both Authoritative server and Recursive server support DNSSEC+NSE= C > aggressive, when will they configure default dns query with dnssec ? (for > NSEC agreesive cached deduced wildcard) > We already know that a year ago 26% of all end users were behind some sort of validating resolver, a number which continues to climb as more ISPs turn on validation, and more users switch to things like Google Public DNS . This isn't an ideal deployment status so long after DNSSEC was standardized, but it's a long way ahead of SWILD. You'll need to have a very compelling argument for me to believe that SWILD is both more useful than DNSSEC and more likely to be deployed at any kind of scale that would make a difference. I just don't see it. Add to that Paul's point that we would very much like to encourage DNSSEC adoption, I don't see why we'd add support for an alternative technology that accomplishes a subset of its features. --001a114da76ac1ddde055690f4b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 August 2017 at 04:29, Lanlan Pan <abbypan@gmail.com> wrote:
Hi Matthew =EF=BC=86 Paul,

Good quest= ion, :-)

SWILD is a feature just for recusive cache optimizati= on, only dealing with the wildcard subdomain issue (with no nodes below).
DNSSEC + NSEC aggressive is security feature, with cryptographic co= ntents such as KSK/ZSK/NSEC/NSEC3/NSEC5/...

My assu= mption is: we can give recursive server an alternative solution for wild= card subdomain cache issue, not need to depend on DNSSEC.
Authoritative server just simply add one SWILD RR, not much deploy cost.Recursive server can add SWILD support if it has an interest in wildcard = subdomain cache optimization,=C2=A0 it is OPT-IN.

I confess it was a rhetorical question. All of= the major implementations already support DNSSEC. =C2=A08198 doesn't h= ave an implementation status section, but there's every reason to think= the major implementations will have support within a version of two.=C2=A0= A quick survey of a few issues databases shows that at least Knot is alrea= dy working on it.=C2=A0 That is a significant head start; SWILD support wit= hout DNSSEC support can't happen in any significant way, and SWILD supp= ort without support for 8198 doesn't seem likely.

<= div>As for operator adoption, the incentives are all wrong for this to actu= ally get used.

Recursive operators already have a = very low operational bar to turn on DNSSEC and get the same benefit to thei= r cache.=C2=A0 In both cases (SWILD and DNSSEC) they rely on the authoritat= ive operator opting in before that benefit can be realized.

<= /div>
Authoritative operators may choose to use DNSSEC =C2=A0because it= will secure their zone, and if recursive operators also have 8198-capable = name servers then the workload for both authoritative and recursive is redu= ced for all terminal names.

With SWILD, there is n= o direct benefit to the authoritative operator, as far as I can see.=C2=A0 = Given that the only benefit to using SWILD is to the recursive operator, wh= at is the motivation for the authoritative operator to add complexity to th= eir deployment by adopting it?=C2=A0 Traditional wildcards work fine for th= em.

To make the adoption problem worse, it appears= as if SWILD is more limited in its use than traditional wildcards.=C2=A0 F= or example, I don't see how you could occlude an SWILD record with a mo= re-specific domain name, as you can with traditional wildcards. =C2=A0
Here's a common scenario based on the example from the draft:
=C2=A0 =C2=A0@ =C2=A0 =C2= =A086400 =C2=A0IN =C2=A0 SWILD =C2=A0_
=C2=A0 =C2=A0_ =C2=A0 =C2=A0 3600 =C2=A0IN =C2=A0 CNAME = =C2=A0map.bar.net.
=C2=A0 =C2=A0* =C2=A0 =C2= =A0 =C2=A0600 =C2=A0IN =C2=A0 CNAME =C2=A0_
=C2=A0dev =C2=A0 =C2=A0 =C2=A0600 =C2=A0IN= =C2=A0 CNAME =C2=A0ma= p.dev.bar.net.

How does SWILD behave when a client queries for de= v?=C2=A0 According to the draft, the authoritative server would return the = SWILD record at the apex.=C2=A0 An SWILD-aware recursive server seems like = it would ignore the CNAME returned for dev and instead use the CNAME for _,= which is not what the operator intended.=C2=A0
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

I don't expect implementers would adopt SWILD 100% befor= e adopting DNSSEC+NSEC aggressive. Just give an alternative choice, impl= ementers can decide adopting or not, before or after, we won't pre-= select for them.
Even if both Authoritative server and Recursive ser= ver support=20 DNSSEC+NSEC aggressive, when will they configure default dns query with dns= sec ?=20 (for NSEC agreesive cached deduced wildcard)

We already know that a year ago 26% of all end user= s were behind some sort of validating resolver, a number which continues to= climb as more ISPs turn on validation, and more users switch to things lik= e Google Public DNS
<https://labs.apnic.ne= t/presentations/store/2016-06-27-dnssec.pdf>.=C2=A0 This i= sn't an ideal deployment status so long after DNSSEC was standardized, = but it's a long way ahead of SWILD.

You'll= need to have a very compelling argument for me to believe that SWILD is bo= th more useful than DNSSEC and more likely to be deployed at any kind of sc= ale that would make a difference.=C2=A0 I just don't see it.
=
Add to that Paul's point that we would very much like to= encourage DNSSEC adoption, I don't see why we'd add support for an= alternative technology that accomplishes a subset of its features.
--001a114da76ac1ddde055690f4b5-- From nobody Sat Aug 12 09:55:26 2017 Return-Path: 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 BC1D313244D for ; Sat, 12 Aug 2017 09:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=dcrocker.net 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 C6tk1mu1SLtF for ; Sat, 12 Aug 2017 09:55:21 -0700 (PDT) Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (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 6FD7613246D for ; Sat, 12 Aug 2017 09:55:21 -0700 (PDT) Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id v7CGtprf021318 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 12 Aug 2017 09:55:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1502556951; bh=xjavGqwWf+6vWM0aix/948XqRKV59YsgLhV80xty7kE=; h=Subject:To:Cc:References:From:Reply-To:Date:In-Reply-To:From; b=h7z+VJ2XROK3ZTZqX2S4fnSNPSWN/0krco4gwUDmMHXmXe/9zUOyZC4R2MXuyY36Z BZEzqid7+QE9699x33nALspihnEhkzQvcByCVHAZwFWe0yDiEF+jiTsyZFroLDwmk5 oXmXIPFYV/cMyeYS1cYhtgLpSs8Y55m0fSYvy1yk= To: Paul Vixie Cc: dnsop@ietf.org, Lanlan Pan , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , Paul Hoffman References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> From: Dave Crocker Organization: Brandenburg InternetWorking Reply-To: dcrocker@bbiw.net Message-ID: Date: Sat, 12 Aug 2017 09:55:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <1659363.yAWSxLQAC2@tums.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 16:55:23 -0000 On 8/12/2017 8:42 AM, Paul Vixie wrote: > we do, though, and we must. DNSSEC development began in 1996, Hmmm. As I recall, discussions on the topic began in 1990 and I thought I was cognizant AD, briefly, when the first working group was formed, after that. I had understood that the IETF effort went through two false-starts in design before landing on the current design, but don't have an adequate sense of the milestone dates for these phases. I note that the DNSSEC History Project should document this, in detail, but lacks dates(*) d/ (*) https://wiki.tools.isoc.org/DNSSEC_History_Project -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Sat Aug 12 10:10:25 2017 Return-Path: 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 0509D1321A3 for ; Sat, 12 Aug 2017 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 86uPh-_4C6wR for ; Sat, 12 Aug 2017 10:10:22 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3394132376 for ; Sat, 12 Aug 2017 10:10:21 -0700 (PDT) Received: (qmail 6693 invoked from network); 12 Aug 2017 17:10:20 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 12 Aug 2017 17:10:20 -0000 Date: 12 Aug 2017 17:09:58 -0000 Message-ID: <20170812170958.14197.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: mellon@fugue.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 17:10:24 -0000 In article you write: >On Wed, Aug 9, 2017 at 12:31 PM, Stuart Cheshire wrote: > >> [*] If you think it’s stupid to suggest a host might not treat “127.0.0.1” >> as meaning loopback, why is that any more stupid than suggesting that a >> host might not treat “localhost” as meaning loopback? Both are just as >> arbitrary. >The reason is that we understand the process by which names are resolved, >and we understand the process by which addresses are configured. You >likely have only one IP stack on your host. You may have dozens of stub >resolvers. So the stub resolvers are a target-rich environment for >failure, and they fail unsafe, not safe: by default, they go to the DNS >protocol to resolve names. Right. That's why it's long past time that we make it clear that non-broken resolvers at any level will treat localhost as a special case. As you may have heard, we are not the Network Police, but we do publish the occasional document telling people what to do if they want to interoperate with the rest of the Internet. R's, John From nobody Sat Aug 12 10:14:42 2017 Return-Path: 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 E9BAD13219F for ; Sat, 12 Aug 2017 10:14:40 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 XwIKvJZ8xY8Y for ; Sat, 12 Aug 2017 10:14:38 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3A813213D for ; Sat, 12 Aug 2017 10:14:38 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id s6so35385524qtc.1 for ; Sat, 12 Aug 2017 10:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=NKLW87FxGkrLZ1M4iuNEOmqYXFBr+Qiy1VBnHb+XNRI=; b=d0zWFxDKR5zxMiwTHtfsUO28N26KrYYx8VzJzxN2IYLLbJP84u0c+i17dgJX0S5Dhu aRG7UdeYY6lUdwZkWQTNodXSScUk9HOusb2+LqE4Rud0NibenZgXkNGZ3zC6SAPKyZXH iVefmRwwAfxDJCBUi5cVzbB4haehCoNlM1H+9Hs/XObtJrqU2MIdY5U5BhGWdudrx9Fh wsRi9DVJB9FmFePKiziFFqRzv6CPXJbFvG09L4FGbpAvnuEfO6JWq5mjQXPquzNRjgwx qQ2BcYjKEgknl95agPteI0MKEL/lCcqMDg1fTru11ZOwY/l5oOo/oFbPPKtfLH9CPgng FZXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=NKLW87FxGkrLZ1M4iuNEOmqYXFBr+Qiy1VBnHb+XNRI=; b=XaFTGDZVUwJkN9GvNmuhrZlU+r1YsxcUcjihd87gF+gqDxzZrtoZvLxcZZPPxCeZDm 9jo3h7FSlQVkUunmU64hCkluKi4KXmbql6f6xE+SXRzESjVQPA8bpFH/woJ3ZKVR8PTi nqbL1qqtDiSyy2Z1pEHrmQvptkup2GAagIfefDeW1fT0cikJjktCJqorddHuUN6nlkq2 aVxgN6LNBo/boEn7KcR4aufCnx9eQVR0JtgjESBcIncG2H9YjtN42dXnoaWr+O2+xP/F C7g7Yr0MF0boHsrgiC8zqsOZ8Vg/fpa6elusOMSK8tuWrU9lLjBU7CGrQVloyXoCEuIX M8gw== X-Gm-Message-State: AHYfb5heOpwSRMWHwMxaIFbGDx0QfDCCa9h8H02s7i8JM8L9yWnFXY7D vEmNtXf62k5EiA9bdDdK1g== X-Received: by 10.237.53.221 with SMTP id d29mr26724002qte.79.1502558077379; Sat, 12 Aug 2017 10:14:37 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id x17sm2489678qta.47.2017.08.12.10.14.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 10:14:36 -0700 (PDT) From: Ted Lemon Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 Aug 2017 13:14:35 -0400 References: <20170812170958.14197.qmail@ary.lan> To: dnsop In-Reply-To: <20170812170958.14197.qmail@ary.lan> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 17:14:41 -0000 El 12 ag 2017, a les 13:09, John Levine va escriure: > Right. That's why it's long past time that we make it clear that > non-broken resolvers at any level will treat localhost as a special > case. As you may have heard, we are not the Network Police, but we do > publish the occasional document telling people what to do if they want > to interoperate with the rest of the Internet. With respect, John, the issue I raised here isn't interop. It's = security. It may be that I'm wrong, but if indeed I am wrong about = this particular point, it is not for this particular reason. From nobody Sat Aug 12 11:36:19 2017 Return-Path: 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 D640613251B for ; Sat, 12 Aug 2017 11:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 sLvQG3p4BQSi for ; Sat, 12 Aug 2017 11:36:16 -0700 (PDT) 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 76EE81324C2 for ; Sat, 12 Aug 2017 11:36:16 -0700 (PDT) Received: from [10.32.60.65] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7CIZJpD096425 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 12 Aug 2017 11:35:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.65] From: "Paul Hoffman" To: dnsop Date: Sat, 12 Aug 2017 11:36:17 -0700 Message-ID: <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> In-Reply-To: References: <20170812170958.14197.qmail@ary.lan> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 18:36:18 -0000 On 12 Aug 2017, at 10:14, Ted Lemon wrote: > El 12 ag 2017, a les 13:09, John Levine va escriure: >> Right. That's why it's long past time that we make it clear that >> non-broken resolvers at any level will treat localhost as a special >> case. As you may have heard, we are not the Network Police, but we >> do >> publish the occasional document telling people what to do if they >> want >> to interoperate with the rest of the Internet. > > With respect, John, the issue I raised here isn't interop. It's > security. It's security through interop. It's causing systems that want to hope that "localhost" has a particular meaning that has security implications to have a better chance that their hope is fulfilled. --Paul Hoffman From nobody Sat Aug 12 11:45:01 2017 Return-Path: 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 E837C1324A3 for ; Sat, 12 Aug 2017 11:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 UJS_hYUDJhmH for ; Sat, 12 Aug 2017 11:44:59 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D12C6132476 for ; Sat, 12 Aug 2017 11:44:58 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f15so14798403wmg.1 for ; Sat, 12 Aug 2017 11:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xqYMUm3ZIQBn8IDon+RSKUVB2t1+SKKQxhRBb8NnGwo=; b=vQd8F6Mv0XYZADoyd7qkhbUscib51sMIAeAoTOxoKNsWD1pls5QgWk6ExoPt0uvNFw 5vIEmWUXlqn2NmXGJFcXEonWXFCi073HEPd5ip7woxx1o2iyERrmWmNV1eH8EiRkejx6 Eqel3wIDWGkSzPOsiZQcerFbryoOp64+HcBixJjmnBU8DiiWru2fQd3MyKZmQn9ydJSL A6UdoKEkRsBQCtfWQc6Ubm+kJ7gOMKJp30WuVu2pAxeL3P7AKKBTBOyQWgBV7LUOYNfa Izr4n91ER4TqELaboOH34v5q8USVzngJ6JtkSNrQWPqxEmr43p/xF1P9kJ615ZQV9xYo uXUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xqYMUm3ZIQBn8IDon+RSKUVB2t1+SKKQxhRBb8NnGwo=; b=d8oU6Dk0qCM/v9jwGsLaWOyKT3SHobE62XHEzTNl/iq2ugbGyjLuIx8scGCz4Wn7Mp wdXv+llqaQXxbnUjKaKBvSReyXCy11dME3kbPHp33N+f0fHzLuAmSlj8eX0N1tMU5zP/ 77YipVFXvFZcJ3bSkbL/F8uAT+d1KtEl4C+RAqo4atJRpm80/U8FjsVmfAGWv0K8NAqY 2hzkgG1vSllnW5VbAzsfENlMMasZHSk/ymLRnKtZ6flCi8tn8C7lDwpHetb5b44b6ifR El/6R8kvo/swbpoyCQtrNF7OFIR+Icg//gLG0DHw4p+URf5RI503ey+43QOD5Zq8heo7 uVcQ== X-Gm-Message-State: AHYfb5hVZlBlO1zSXwwb5R3wVRJWetX97OZmWZM38afIDMD7J9LPIDHN 83gInRujyJsbPVFLoyfQ+si33QkhPLmlkwc= X-Received: by 10.28.70.68 with SMTP id t65mr1574176wma.163.1502563497127; Sat, 12 Aug 2017 11:44:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Sat, 12 Aug 2017 11:44:56 -0700 (PDT) In-Reply-To: <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> From: Richard Barnes Date: Sat, 12 Aug 2017 14:44:56 -0400 Message-ID: To: Paul Hoffman Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c0d45fc7fc8e0055692d3db" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 18:45:01 -0000 --94eb2c0d45fc7fc8e0055692d3db Content-Type: text/plain; charset="UTF-8" On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman wrote: > On 12 Aug 2017, at 10:14, Ted Lemon wrote: > > El 12 ag 2017, a les 13:09, John Levine va escriure: >> >>> Right. That's why it's long past time that we make it clear that >>> non-broken resolvers at any level will treat localhost as a special >>> case. As you may have heard, we are not the Network Police, but we do >>> publish the occasional document telling people what to do if they want >>> to interoperate with the rest of the Internet. >>> >> >> With respect, John, the issue I raised here isn't interop. It's security. >> > > It's security through interop. It's causing systems that want to hope that > "localhost" has a particular meaning that has security implications to have > a better chance that their hope is fulfilled. And giving systems that want to ensure that they never mistake "localhost" for something other than loopback to have a better chance that they won't break things. --Richard --94eb2c0d45fc7fc8e0055692d3db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman <paul.hoffman@vpnc.o= rg> wrote:
On 12 Aug 2017, at 10:14, Ted Lemon wrote:

El 12 ag 2017, a les 13:09, John Levine <johnl@taugh.com> va escriure:
Right.=C2=A0 That's why it's long past time that we make it clear t= hat
non-broken resolvers at any level will treat localhost as a special
case.=C2=A0 As you may have heard, we are not the Network Police, but we do=
publish the occasional document telling people what to do if they want
to interoperate with the rest of the Internet.

With respect, John, the issue I raised here isn't interop.=C2=A0 It'= ;s security.

 It's security through interop. It's causing systems that want to ho= pe that "localhost" has a particular meaning that has security im= plications to have a better chance that their hope is fulfilled.

And giving systems that want to ensure that they neve= r mistake "localhost" for something other than loopback to have a= better chance that they won't break things.

-= -Richard
=C2=A0
--94eb2c0d45fc7fc8e0055692d3db-- From nobody Sat Aug 12 12:03:45 2017 Return-Path: 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 F042B1252BA for ; Sat, 12 Aug 2017 12:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 kP-2RxHCDyTZ for ; Sat, 12 Aug 2017 12:03:42 -0700 (PDT) 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 65E49120724 for ; Sat, 12 Aug 2017 12:03:42 -0700 (PDT) Received: from [10.32.60.65] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7CJ2jwx097502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 12 Aug 2017 12:02:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.65] From: "Paul Hoffman" To: "Richard Barnes" Cc: dnsop Date: Sat, 12 Aug 2017 12:03:44 -0700 Message-ID: <80042DA2-D9B1-4CFD-83F9-0F4900AC3138@vpnc.org> In-Reply-To: References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 19:03:44 -0000 On 12 Aug 2017, at 11:44, Richard Barnes wrote: > On Sat, Aug 12, 2017 at 2:36 PM, Paul Hoffman > wrote: > >> On 12 Aug 2017, at 10:14, Ted Lemon wrote: >> >> El 12 ag 2017, a les 13:09, John Levine va >> escriure: >>> >>>> Right. That's why it's long past time that we make it clear that >>>> non-broken resolvers at any level will treat localhost as a special >>>> case. As you may have heard, we are not the Network Police, but we >>>> do >>>> publish the occasional document telling people what to do if they >>>> want >>>> to interoperate with the rest of the Internet. >>>> >>> >>> With respect, John, the issue I raised here isn't interop. It's >>> security. >>> >> >> It's security through interop. It's causing systems that want to hope >> that >> "localhost" has a particular meaning that has security implications >> to have >> a better chance that their hope is fulfilled. > > > And giving systems that want to ensure that they never mistake > "localhost" > for something other than loopback to have a better chance that they > won't > break things. Sorry, yes: that too. It applies to hopefulness on both sides. --Paul Hoffman From nobody Sat Aug 12 12:35:24 2017 Return-Path: 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 C5E1A131D1E for ; Sat, 12 Aug 2017 12:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 gm9uVYza14Fc for ; Sat, 12 Aug 2017 12:35:21 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3DD412EAF7 for ; Sat, 12 Aug 2017 12:35:20 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x191so34904362qka.5 for ; Sat, 12 Aug 2017 12:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=H+fG91OML64LQl1yYLj7gh/lRX8aAS21HTIbCN2x09o=; b=cHf97cH2IB/Xi/cSq6RDNGogF0bnK29CTha1p2NeIbi25UxW5I2uEeP/nznYerRW87 5cHRkYZftvIiBuEQQWIjQ67CzV3QOrdH1y18ENAxXQkGByegXRFwk3ognruK13qhSlk5 SIx+gApIF+KYJ0EvUZ0R2golULRG21W5tmzrnhgI/YlsEpE59DmOAtDyPZOQsll41n7Y HyxJnu9BpYB0ODmYThVqchJg7vNBgzAApB3ALEppQm4x95jNTrJ9Q5on+Yqu/6XPud2H NSJ4AGw3TAbIfkF+/LaMIk/KJtj286Adwlz+GoQoyjSHSHmoIgVKNu2UVxIoyLlThke8 glkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=H+fG91OML64LQl1yYLj7gh/lRX8aAS21HTIbCN2x09o=; b=h9we+EUKdj4/SUR5s+U4nODmwE5pcbOZ4J5F0C+xrQxjk6jENjYJdbYISRf1a5wxEB DGg1yFWc0c6Bx56DC4PzZ6kw+hx0izcDk7EXNvY+lDUrP6+1ZSqWfVjfV2ntFDjUJ2qH 9ccmMywiBApiHxZjC1fIblJXujuV/VQjfeWL1RRhQdiMGftPnT/tmi6yogAPh2LB9y85 NQzVzlfhPHXXJNfbb496fa3eygWACdUvAw10usEP9SD7hWa2P5uOtTu6ph6DPPNuPlbt 4hcJnZ9JeUvw2SK0hfUpTSqfVgCtA5j2IwStdQzkRrBAymcGOtl9jTJiP9nPv2SP+b5E cAiw== X-Gm-Message-State: AHYfb5jfgVFCJ9e70fRnRZM4w1vE/OQDwMc9q1a6TXE6Im6DdrOnsS/i bd4XXU5PS0qlogltCgS99w== X-Received: by 10.55.81.139 with SMTP id f133mr24216733qkb.194.1502566519862; Sat, 12 Aug 2017 12:35:19 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id j81sm2485487qke.19.2017.08.12.12.35.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2017 12:35:19 -0700 (PDT) From: Ted Lemon Message-Id: <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5CDCA84F-6805-40E7-9431-60DA0E121813" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sat, 12 Aug 2017 15:35:17 -0400 In-Reply-To: <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> Cc: dnsop To: Paul Hoffman References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 19:35:23 -0000 --Apple-Mail=_5CDCA84F-6805-40E7-9431-60DA0E121813 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 12 ag 2017, a les 14:36, Paul Hoffman va = escriure: > It's security through interop. It's causing systems that want to hope = that "localhost" has a particular meaning that has security implications = to have a better chance that their hope is fulfilled. Yes, I get that, and I'm not sure that it's wrong, but you still haven't = addressed the point that I raised. That's fine=E2=80=94I don't know = that you really need to. But for some reason people keep replying to = my point with statements that don't contradict it, as if they think they = have contradicted it, which puzzles me. To recap, my point is that fixing localhost and then relying on it = doesn't fail safe, and there is reason not to be confident that = implementations will conform, because they will appear to work even if = they don't. If we think that localhost is the right identifier to use = to refer to the local host, then we ought to be taking steps to make it = not be the case that broken implementations will appear to work: we = should be systematically trying to ensure that as many environments in = which such applications might run as possible produce failure when a = broken resolver forwards a query for localhost to the local recursive = resolver. The document does the right thing on that front, as far as that goes, = but if this is to be effective I think that it shouldn't be an aside, = but should be the main point of the document. That is, the title of = the document should be "DNS servers should return NXDOMAIN for = localhost" and the abstract should say why, and then the bit about stub = resolvers translating "localhost" to a reachable identifier for the = localhost such as 127.1 or ::1 should be the thing that's mentioned as = an aside. And then we should be socializing this to operators and filing bugs = against it in the bug tracking systems of our favorite distros. And after doing that, it will still be the case that references to = "localhost" don't fail safe, but it will be more likely that they won't = happen, so maybe my point will have been adequately addressed. But I = still think that it would be better to recommend some identifier that = can't be looked up in the DNS. --Apple-Mail=_5CDCA84F-6805-40E7-9431-60DA0E121813 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 12 ag 2017, a les 14:36, Paul Hoffman <paul.hoffman@vpnc.org> va escriure:
It's security through interop. It's = causing systems that want to hope that "localhost" has a particular = meaning that has security implications to have a better chance that = their hope is fulfilled.

Yes, I get that, and I'm not sure that it's = wrong, but you still haven't addressed the point that I raised.   = That's fine=E2=80=94I don't know that you really need to.   But for = some reason people keep replying to my point with statements that don't = contradict it, as if they think they have contradicted it, which puzzles = me.

To recap, = my point is that fixing localhost and then relying on it doesn't fail = safe, and there is reason not to be confident that implementations will = conform, because they will appear to work even if they don't.   If = we think that localhost is the right identifier to use to refer to the = local host, then we ought to be taking steps to make it not be the case = that broken implementations will appear to work: we should be = systematically trying to ensure that as many environments in which such = applications might run as possible produce failure when a broken = resolver forwards a query for localhost to the local recursive = resolver.

The = document does the right thing on that front, as far as that goes, but if = this is to be effective I think that it shouldn't be an aside, but = should be the main point of the document.   That is, the title of = the document should be "DNS servers should return NXDOMAIN for = localhost" and the abstract should say why, and then the bit about stub = resolvers translating "localhost" to a reachable identifier for the = localhost such as 127.1 or ::1 should be the thing that's mentioned as = an aside.

And = then we should be socializing this to operators and filing bugs against = it in the bug tracking systems of our favorite distros.

And after doing that, it = will still be the case that references to "localhost" don't fail safe, = but it will be more likely that they won't happen, so maybe my point = will have been adequately addressed.   But I still think that it = would be better to recommend some identifier that can't be = looked up in the DNS.

= --Apple-Mail=_5CDCA84F-6805-40E7-9431-60DA0E121813-- From nobody Sat Aug 12 15:10:39 2017 Return-Path: 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 2D150132408 for ; Sat, 12 Aug 2017 15:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 jpEo6d10JA6A for ; Sat, 12 Aug 2017 15:10:36 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DF4132411 for ; Sat, 12 Aug 2017 15:10:36 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:6407:90ff:3eca:80da] (unknown [IPv6:2001:559:8000:c9:6407:90ff:3eca:80da]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 25DDA61FF3 for ; Sat, 12 Aug 2017 22:10:36 +0000 (UTC) Message-ID: <598F7CDB.1010804@redbarn.org> Date: Sat, 12 Aug 2017 15:10:35 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: dnsop References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> In-Reply-To: <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sat, 12 Aug 2017 22:10:38 -0000 Ted Lemon wrote: > ... > > To recap, my point is that fixing localhost and then relying on it > doesn't fail safe, and there is reason not to be confident that > implementations will conform, because they will appear to work even if > they don't. ... i'm only excerpting a small bit of ted's text, so that i can say: +1 and, please everybody go read the rest if you didn't already. -- P Vixie From nobody Sat Aug 12 17:05:57 2017 Return-Path: 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 40C1F1323B4 for ; Sat, 12 Aug 2017 17:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.001 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 PuAIJqHko4oS for ; Sat, 12 Aug 2017 17:05:54 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B051323AE for ; Sat, 12 Aug 2017 17:05:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=POClskIq500R02RIkdNu+CB6KMbjhqtMXgvU536ymD4=; b=QbDtPgyiCBZdPQv2yugiY4sc44b3zKrG5rv1jna4ID/obibEXr7K7Nyl81WAA3q24PnzcqNBe72C7Piy2mfRy6dSp6c1VUr1CXxHNa1Zrvbm4ijARFfBk68ghY25O/mpug2C5c28chmaAKvTSaWNlfAPHxCPt7B14lv5cY2R2Sk=; Received: ; Sat, 12 Aug 2017 17:05:51 -0700 To: Ted Lemon , Paul Hoffman Cc: dnsop References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> From: Jacob Hoffman-Andrews Message-ID: <82f31300-0cca-ed48-561e-332a26c3f91d@eff.org> Date: Sat, 12 Aug 2017 17:05:51 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 00:05:56 -0000 On 08/12/2017 12:35 PM, Ted Lemon wrote: > The document does the right thing on that front, as far as that goes, > but if this is to be effective I think that it shouldn't be an aside, > but should be the main point of the document. That is, the title of > the document should be "DNS servers should return NXDOMAIN for > localhost" and the abstract should say why, and then the bit about > stub resolvers translating "localhost" to a reachable identifier for > the localhost such as 127.1 or ::1 should be the thing that's > mentioned as an aside. I agree, this seems like a good addition to the doc. It makes explicit what we've discussed on-list, and it codifies what is already common practice in the wild, along with justification. From nobody Sun Aug 13 10:19:50 2017 Return-Path: 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 BC751132646 for ; Sun, 13 Aug 2017 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 RJNIHiPvuiBD for ; Sun, 13 Aug 2017 10:19:47 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767E11324E5 for ; Sun, 13 Aug 2017 10:19:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 91095210A4; Sun, 13 Aug 2017 13:19:46 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 13 Aug 2017 13:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=UuIpGj1IVoebWZ//m79rJbhChD+s6mJP50A4zbWDDWA=; b=GBO4sJwD q4WKJv2Es0Pf8m+FsBdkD9D8BZk183lVZk1RjJ8ikRkdhvWd2qymbpCZDYn5uQJF 9vcTcvCSrQjBSS4OzLLfmbOOhM/AFbGflGkP6VTEsLaHSFGQg/9iNki7h9KCGfNU hf+xfSf6bnqMGeaNltanDIbdZChQ84tM9q03ZuGraA00++0Bl2cLTmEqm62HS7Qz pqWT9S2xI1jKMlfLuNHD7EckfMp1OudjTRg2FnGGd6ekFJIal1ap0rb7VUVLb6xf HXU1nTCFkkMzfoHFoW0kgxQrLVm3DwsHI0EGh2g1MBvR45uow6nhDeCcfC/sD+2X dBvnQz7eT8W7AA== X-ME-Sender: X-Sasl-enc: pbhjXTtXEdtJ6kWGX6h0FQDYeSCXm1+F2H0TQn9mv3h4 1502644786 Received: from [10.37.0.155] (188.29.164.105.threembb.co.uk [188.29.164.105]) by mail.messagingengine.com (Postfix) with ESMTPA id 223F924697; Sun, 13 Aug 2017 13:19:46 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-16907341-FD7E-46F3-AFFA-43CB23B1EA77 Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14G60) In-Reply-To: <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> Date: Sun, 13 Aug 2017 20:19:40 +0300 Cc: Paul Hoffman , dnsop Content-Transfer-Encoding: 7bit Message-Id: References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 17:19:50 -0000 --Apple-Mail-16907341-FD7E-46F3-AFFA-43CB23B1EA77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On 12 Aug 2017, at 22:35, Ted Lemon wrote: >=20 > That is, the title of the document should be "DNS servers should return NX= DOMAIN for localhost" and the abstract should say why, and then the bit abou= t stub resolvers translating "localhost" to a reachable identifier for the l= ocalhost such as 127.1 or ::1 should be the thing that's mentioned as an asi= de. RFC 6761 requires recursive servers to return positive 127.0.0.1 and ::1 res= ponses, not NXDOMAIN. I can't see an explanation in the draft for the change= to NXDOMAIN. https://tools.ietf.org/html/rfc6761#section-6.3 Should there also be some text about the wisdom (or otherwise) of localhost e= ntries in public zones? E.g. localhost.cam.ac.uk - see also http://seclists.= org/bugtraq/2008/Jan/270 and the follow up messages from Florian Weimer and D= avid Malone. Tony. --=20 f.anthony.n.finch http://dotat.at --Apple-Mail-16907341-FD7E-46F3-AFFA-43CB23B1EA77 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 12 Aug 20= 17, at 22:35, Ted Lemon <mellon@fugue= .com> wrote:

T= hat is, the title of the document should be "DNS servers should return NXDOM= AIN for localhost" and the abstract should say why, and then the bit about s= tub resolvers translating "localhost" to a reachable identifier for the loca= lhost such as 127.1 or ::1 should be the thing that's mentioned as an aside.=

RFC 6761 requires recursive servers t= o return positive 127.0.0.1 and ::1 responses, not NXDOMAIN. I can't see an explanation i= n the draft for the change to NXDOMAIN.


Should there also be some text about the wisdom (or otherwise) of l= ocalhost entries in public zones? E.g. localhost.cam.ac.uk - see also http://seclists.org/bugtraq/2008/Jan/270&nb= sp;and the follow up messages from Florian Weimer and David Malone.
-- 
f.anthony.n.finch  <dot@= dotat.at>  http://dotat.at

= --Apple-Mail-16907341-FD7E-46F3-AFFA-43CB23B1EA77-- From nobody Sun Aug 13 11:09:09 2017 Return-Path: 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 CB15213268A for ; Sun, 13 Aug 2017 11:09:07 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 LgZ9uu5RF5Dk for ; Sun, 13 Aug 2017 11:09:06 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05F1E132664 for ; Sun, 13 Aug 2017 11:09:05 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id v29so42512936qtv.3 for ; Sun, 13 Aug 2017 11:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=MGBzTw6z67b+NvTE6NpqWmE/DozJlZnFOZZTKAEJbkE=; b=TkECJ29EBMlVw7295kQI9UQn/CqVDLVnfWUvTyV8rX1Y3RCgJlZcMzDDk58SI3zrjb 2/+NkbaYSu0RaDydkosPyJaYrcb0aridig8wbpo2vlu7qotNDZns4P/6s4n7aNUwOA1m 6+v8vm/kWECTxoE3TfaC+UEIdN7avUWrZAwo9aljzCl+hvUV+SJ8HMznTP4bplzIFEte EMdE4TLUkU3SXzXZhaWs1ADIF7bzaamagn8m7OCyzHPgkrpHQvdIiSNLjB8chxxeR2Pi QRZWZchWq6+7ZpKqe5qNTnAbSq2E+7kfPTcTmVssg/6lJSTF/lfHWP5THg2WNqByV6of 8dmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=MGBzTw6z67b+NvTE6NpqWmE/DozJlZnFOZZTKAEJbkE=; b=P73IPIO2YXhFVvTwgnj9YCT7i27zSpikhbmKxAk97XDaKiiyKieY6gC4lyh42zao6o fRMAmfjwM+Q+W+bmczAjHj8DLreoCASU431y9bp64TQGn2EjqJxjI0qKEww/kPynxEyS B+bDBIxJYORSlsJykNdX0aSqOhRVptHjoz0eKAr9R98EWxPB5//uh7NFgrL5T3ISJl0O hthr3AR5A+6VmBTkWmd7YR/mSkZit11VV12+iSswF3uMR1jzoruCBnGKou4yr+nC5K+4 TDpKaY7eyQheSAqaRyMbOEFThJkfdDNYZWPrulqdgoYpXEUcq6dVFP0ALMRKHSB68jbV UaPA== X-Gm-Message-State: AHYfb5hy79LSOnK9rOLrDO7J8yE+Lxl4D2kxYrFdAfydtm5d3ymhM0JA jttGuMPz9eraDDXX X-Received: by 10.200.43.213 with SMTP id n21mr28404301qtn.142.1502647745028; Sun, 13 Aug 2017 11:09:05 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id u22sm4115936qth.43.2017.08.13.11.09.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 13 Aug 2017 11:09:03 -0700 (PDT) From: Ted Lemon Message-Id: <642396E7-7473-4859-BCA7-94EC8E12AFDF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1C208C13-71D0-4A1A-B8A1-6FA6F4E450D2" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 13 Aug 2017 14:09:02 -0400 In-Reply-To: Cc: Paul Hoffman , dnsop To: Tony Finch References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 18:09:08 -0000 --Apple-Mail=_1C208C13-71D0-4A1A-B8A1-6FA6F4E450D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 13 ag 2017, a les 13:19, Tony Finch va escriure: > RFC 6761 requires recursive servers to return positive 127.0.0.1 and = ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for = the change to NXDOMAIN. The reason to return NXDOMAIN is that it causes stub resolvers that look = localhost up using DNS to fail, which is what should happen. It is = incorrect to look up localhost in the DNS. Failure is preferred in = this case. --Apple-Mail=_1C208C13-71D0-4A1A-B8A1-6FA6F4E450D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 13 ag 2017, a les 13:19, Tony Finch <dot@dotat.at> va = escriure:
RFC= 6761 requires recursive servers to return positive 127.0.0.1 and ::1 = responses, not NXDOMAIN. I can't see an explanation in the = draft for the change to NXDOMAIN.

The reason to return NXDOMAIN is that it causes = stub resolvers that look localhost up using DNS to fail, which is what = should happen.   It is incorrect to look up localhost in the DNS. =   Failure is preferred in this case.

= --Apple-Mail=_1C208C13-71D0-4A1A-B8A1-6FA6F4E450D2-- From nobody Sun Aug 13 13:51:29 2017 Return-Path: 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 F3A80132AE5 for ; Sun, 13 Aug 2017 13:51:27 -0700 (PDT) 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 zUa4RSgxdacW for ; Sun, 13 Aug 2017 13:51:26 -0700 (PDT) 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 BAD01132A7F for ; Sun, 13 Aug 2017 13:51:26 -0700 (PDT) Received: from [10.32.60.33] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7DKoTjA059486 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 13 Aug 2017 13:50:30 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.33] From: "Paul Hoffman" To: dnsop Date: Sun, 13 Aug 2017 13:51:24 -0700 Message-ID: In-Reply-To: References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 20:51:28 -0000 On 13 Aug 2017, at 10:19, Tony Finch wrote: >> On 12 Aug 2017, at 22:35, Ted Lemon wrote: >> >> That is, the title of the document should be "DNS servers should >> return NXDOMAIN for localhost" and the abstract should say why, and >> then the bit about stub resolvers translating "localhost" to a >> reachable identifier for the localhost such as 127.1 or ::1 should be >> the thing that's mentioned as an aside. > > RFC 6761 requires recursive servers to return positive 127.0.0.1 and > ::1 responses, not NXDOMAIN. I can't see an explanation in the draft > for the change to NXDOMAIN. And there should be. Proposed addition to the last paragraph of Section 1: A consequence of the requirement that the resolver APIs MUST resolve "localhost." and any names falling within ".localhost." to loopback addresses is that caching DNS servers and authoritative DNS servers MUST NOT resolve those names at all, and always return NXDOMAIN. --Paul Hoffman From nobody Sun Aug 13 15:14:24 2017 Return-Path: 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 5436913311A for ; Sun, 13 Aug 2017 15:14:22 -0700 (PDT) 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 Ymxde1F8HjAa for ; Sun, 13 Aug 2017 15:14:20 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75BF81332C8 for ; Sun, 13 Aug 2017 15:14:20 -0700 (PDT) Received: from [10.242.2.4] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 3A2E01BC81; Mon, 14 Aug 2017 00:14:16 +0200 (CEST) From: "Peter van Dijk" To: dnsop Date: Mon, 14 Aug 2017 00:14:26 +0200 Message-ID: In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 22:14:22 -0000 On 12 Aug 2017, at 18:31, Matthew Pounsett wrote: > 8198 doesn't have an implementation status section https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#section-10 is not in the published RFC 8198 because 7942 (sadly) mandates that this section is removed before publication. I suspect this removal is specifically hurting OPENPGPKEY deployment today. So, if you want to know about implementation status, please click through from https://tools.ietf.org/html/rfcXXXX to the relevant draft. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Sun Aug 13 15:25:02 2017 Return-Path: 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 E0BB51333CA for ; Sun, 13 Aug 2017 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 TAVGs_OPeK3Q for ; Sun, 13 Aug 2017 15:24:58 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 558911333C8 for ; Sun, 13 Aug 2017 15:24:57 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id w45so30974928uac.5 for ; Sun, 13 Aug 2017 15:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WcbOB6RUmNuxcGeCnz874cJqyVC9IrRrxcYf1Hv0nh4=; b=I1paNBit2aQxhfTJ+lRtc0OimLzUnZYaFWWcDwbwkQcpdvW2H/biCPt3b8Xuz45fsQ JzKimtSaCUyRuqukZdovIjLw4OdZCowadXiyFJvpOKvHyLvCxhg7iY3ZcaI4yiS0eUEf smpwxUi+Lqkv26TreEx3P9HUpOjvvtJnmk7l4iQ5XOj9Zr7lWbjDbEri3CHq8dZ1EskY fDuiIJwQa6fFZzuvPoW0g7xyatRoYVzHkSDMTCsMBLapXauv8KKYLogTptAI8xYmWd/W 55FtGTL6pJ9p0cCMYsftinWctgeVzwNwnS7A4CSxHXGCcTk4QFKOIuTd2l+e0H71t7HV kWig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WcbOB6RUmNuxcGeCnz874cJqyVC9IrRrxcYf1Hv0nh4=; b=Ev7j8XlL/qT9VZ7YJoVwA8rvWp1PhNyaO4vVV6H0GYFYpEl82WYaOHEjSjuRhTD5zF pjl1FpMOg4gWI0f6aWvSyelUtAEXmI9z/21powbF5RbfJahQx0H5lEgbj42ImOebeTfN 8Gt2HPNQFh8qeJTPar1X0ZtCyio8H9xU8D5AAnv0vR2pf24VFdX4GmLj+Gp8XEdaCsqJ x2u6Xt4WyAdBK4mz101HzDHVmL96NrFdAC/heeIcLBmebV/FBaT1zkylDALc+Qk01m5Y QxoJSbvx+PbYM+5xE9ysDKNgJQ1ILjHC3bHeyNcpn8KpvcJkLT5ZushiCA1/LiW+utiQ 1MJg== X-Gm-Message-State: AHYfb5hZeU9Biqpb4ei1H3GcNdboXCYubCvH1ckWObGdcGh7KmqXDVRh ADjaw8qZ8x18xX+UkQ6vXccYNRrQUXmjxNo= X-Received: by 10.159.49.78 with SMTP id n14mr16325652uab.194.1502663096891; Sun, 13 Aug 2017 15:24:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.84.74 with HTTP; Sun, 13 Aug 2017 15:24:56 -0700 (PDT) In-Reply-To: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> From: Matthew Pounsett Date: Sun, 13 Aug 2017 18:24:56 -0400 Message-ID: To: Peter van Dijk Cc: dnsop Content-Type: multipart/alternative; boundary="f403045e232c1be7870556aa0433" Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Sun, 13 Aug 2017 22:25:01 -0000 --f403045e232c1be7870556aa0433 Content-Type: text/plain; charset="UTF-8" On 13 August 2017 at 18:14, Peter van Dijk wrote: > > https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressive > use-10#section-10 is not in the published RFC 8198 because 7942 (sadly) > mandates that this section is removed before publication. I suspect this > removal is specifically hurting OPENPGPKEY deployment today. > > So, if you want to know about implementation status, please click through > from https://tools.ietf.org/html/rfcXXXX to the relevant draft. > > Ah, I did not realize that was mandated to be removed. Thanks for filling me in! --f403045e232c1be7870556aa0433 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 13 August 2017 at 18:14, Peter van Dijk <peter.van.dijk@p= owerdns.com> wrote:

https://tools.ie= tf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-10#section-10= is not in the published RFC 8198 because 7942 (sadly) mandates that this s= ection is removed before publication. I suspect this removal is specificall= y hurting OPENPGPKEY deployment today.

So, if you want to know about implementation status, please click through f= rom https://tools.ietf.org/html/rfcXXXX to the relevant = draft.

Ah, I did not realize that was mandated to = be removed.=C2=A0 Thanks for filling me in!=C2=A0

--f403045e232c1be7870556aa0433-- From nobody Sun Aug 13 17:36:57 2017 Return-Path: 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 C2B05134059 for ; Sun, 13 Aug 2017 17:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 s1oZB4RNNprM for ; Sun, 13 Aug 2017 17:36:54 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9029C133D46 for ; Sun, 13 Aug 2017 17:36:54 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id DD3C520B98; Sun, 13 Aug 2017 20:36:53 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sun, 13 Aug 2017 20:36:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=2Ureohg2KfSkLQcYMejuKvEprdbqNzY2hYLX4gCQnkU=; b=bOKCW5Lo +BuAdOR0WSv6ThNhGfrHlkhxs5tlZed/4ebLpxWYSIAVzV+SMKFMfcpiLgnbnFHd AfB6nHs+hSboHmoKXOc00xpLCI0T1oB1WXgXpWaj42wmi7aL35mSu1UNY19jeTvb fiE5IgBWP+gGOGEMO9ZqMUS6kvwv7FCGX2OfHbjes5QxK4a/POOiJoJVt/GiP2BL MDUBkUni4zpS/u1l+P9lBYavcX156VGHKZEnWheIG3E5S6ztE2e08CF35F+OUHMd HHZBlRSDP9Ey1VInpVQ+BGUJClNhCIsPRq6GjnAJ6sLTnhSDgnE3EJFtrpaHnGc5 70voSpShY4KBpQ== X-ME-Sender: X-Sasl-enc: iPTucelgEfiFdiBQIdUiJUssK4fnDbldc1dih1tbTCCR 1502671013 Received: from [10.162.137.93] (92.40.248.31.threembb.co.uk [92.40.248.31]) by mail.messagingengine.com (Postfix) with ESMTPA id 76C0A2418A; Sun, 13 Aug 2017 20:36:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Mon, 14 Aug 2017 03:36:49 +0300 Cc: dnsop Content-Transfer-Encoding: quoted-printable Message-Id: <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> To: Paul Hoffman Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 00:36:57 -0000 > On 13 Aug 2017, at 23:51, Paul Hoffman wrote: >=20 > On 13 Aug 2017, at 10:19, Tony Finch wrote: >>=20 >>=20 >> RFC 6761 requires recursive servers to return positive 127.0.0.1 and ::1 r= esponses, not NXDOMAIN. I can't see an explanation in the draft for the chan= ge to NXDOMAIN. >=20 > And there should be. Proposed addition to the last paragraph of Section 1:= >=20 > A consequence of the requirement that the resolver APIs MUST resolve "loca= lhost." and any names falling within ".localhost." to loopback addresses is t= hat caching DNS servers and authoritative DNS servers MUST NOT resolve those= names at all, and always return NXDOMAIN. Well, that isn't really the kind of text I wanted. You have written a paragraph that is obvious from the internal logic of the d= raft, but it doesn't say why "a consequence" has changed from RFC 6761. What we really need is an informed analysis of the consequences of different= ways of sinking localhost queries on recursive servers. The de facto way is= NXDOMAIN (same as what happens when there is no special case in the resolve= r, except without the recursion to the root servers). The RFC 6761 way is to= return locally authoritative positive responses. Either way, BIND (for instance) needs special configuration to be RFC 6761 c= ompliant or NXDOMAIN compliant, so some kind of code change is needed to mak= e the Right Thing the default, but which Thing's Rightness needs justificati= on. There are also missing security considerations. The whole draft is motivated= by web security edge cases, so I would like to see a summary and citation o= f the same site scripting problem, and whatever other issues there might be.= Does the change from positive responses to NXDOMAIN have some connection to t= he web security motivation? It isn't clear to me and it ought to be. There is also a weird compatibility awkwardness. RFC 6761 requires *.localho= st to resolve to localhost, in stub and recursive resolvers. You can't imple= ment this in traditional Unix libc resolvers. It's possible to implement thi= s in a recursive server like BIND, but I realised this week that I had not i= mplemented the wildcard in my config, so I bet proper RFC 6761 conformance i= s rare. The upshot of the draft's current text is that full system behaviour will va= ry depending on libc version, recursor version, recursor config, etc. I think it is still a good idea to tighten up the implementation requirement= s to MUST. That part of the draft is good, but trivial. The interesting part is not stated in the current text: it is that applicati= on software that makes security assumptions about localhost MUST internally r= esolve localhost without relying on the shifting historical and operational v= ariability of stub resolvers and recursive servers. Tony. --=20 f.anthony.n.finch http://dotat.at= From nobody Sun Aug 13 21:57:05 2017 Return-Path: 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 0C0221252BA for ; Sun, 13 Aug 2017 21:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8j5l4VQf-Z5C for ; Sun, 13 Aug 2017 21:57:02 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FB87124BE8 for ; Sun, 13 Aug 2017 21:57:01 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id i66so34527806wmg.0 for ; Sun, 13 Aug 2017 21:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qyML1dxA7cDov/JC1mlMaxTPN3QkLG9rDSPCX9yKPSU=; b=hKkQHTMGY3X1kbvyHHKfU4C07YzCOr+630+PNSsZT4uKi6RGGjds+3chuiJs3yVr+M OPqIIgA9tyVLPDuic9EhFkd0jmxqR07mC1VLq2P6kUgMG9up9qqhgoHH0QdRekd09/c5 97COS+iBDCaHtI3r6gR0ooBzj8+W7ae3xEElvoDaJ2F5L6h8MERjBXM6vH9bnR1xe5da z5GeDieEhLgtNpJf7fmptsxuRsDZxGgere3NnnlEjaE4QQ7YwVo+6Yn1GwqyZUgplQOM xQ0QBcjnxlAAW0UOM+Yy/0E4VTGa8Qm3wjrhMqC3gAKC4brPINkz879asF1fqeXI8cpo XtUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qyML1dxA7cDov/JC1mlMaxTPN3QkLG9rDSPCX9yKPSU=; b=KG5UQ39kz6eqrC0KsgpQ7TwhxWbqDESuwGOl3Ww85OdQUjhLZ8+Uh/S67yeuRm2Blu y09Mvue0Qc9+KqrDafCur6z3QHEE1Y+iuBrqI+OP1ezmi/wsnfiyvuAKkSPDvMUw4/hC F562V9abI/ad1LPQQH8gPfh5wQZNDaeauBGrNlOe+JYcvzLonWo7xmF7oth09JRWdP8K +dzs1nY9P+JlQOTwqvyr4mMyw2WM7WpFFK9XkYYdscZaY15nxJR7EhCpOPUcNXCcY/AV xJPmIh+72nGOaKQR/kD16O6xkokoSxku+Qxn3zQ+4SFbOXsekXe1fuSWp3LhJwEHvHDK uO9g== X-Gm-Message-State: AHYfb5iHlPeyE9Cwjhm7FqYOePC+IHXbBT8tjR/E+bJL66Rd+MDJusY/ j+WzGMK+mQBTRz+a8emsvrXjWMmYQhal X-Received: by 10.80.138.6 with SMTP id i6mr22722551edi.247.1502686620193; Sun, 13 Aug 2017 21:57:00 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> In-Reply-To: <1659363.yAWSxLQAC2@tums.local> From: Lanlan Pan Date: Mon, 14 Aug 2017 04:56:49 +0000 Message-ID: To: Paul Vixie Cc: Matthew Pounsett , Paul Hoffman , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= , dnsop Content-Type: multipart/alternative; boundary="94eb2c1957843499dc0556af7ed6" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 04:57:04 -0000 --94eb2c1957843499dc0556af7ed6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, Maybe it makes a mountain out of a molehill. "Give to the emperor the things that are the emperor's, and to God the things that are God's.=E2=80=9C, we can seperate security issue and subdoma= in wildcard cache issue. I think, SWILD has no influence on DNSSEC deployment : 1) If recursive wants to deploy DNSSEC, it is almost impossible because of NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest motivation behind DNSSEC depolyment.* 2) If recursive doesn't want to deploy DNSSEC, it is almost impossible because of SWILD. Imagine that, there is no SWILD to give precise subdomain wildcard information from authoritative, recursive can use random subdomain detect method to make cache optimization, which was described in DNS Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS Traffic . But the rate of "DNSSEC + NSEC + default dns query with DNSSEC=E2=80=9D has influnence on subdomain wildcard cache issue if we only accept unique solution depend on it. Paul Vixie =E4=BA=8E2017=E5=B9=B48=E6=9C=8812=E6=97=A5=E5= =91=A8=E5=85=AD =E4=B8=8B=E5=8D=8811:42=E5=86=99=E9=81=93=EF=BC=9A > On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote: > > ... > > > > SWILD is a feature just for recusive cache optimization, only dealing > with > > the wildcard subdomain issue (with no nodes below). > > DNSSEC + NSEC aggressive is security feature, with cryptographic conten= ts > > such as KSK/ZSK/NSEC/NSEC3/NSEC5/... > > > > My assumption is: *we can give recursive server an alternative solution > for > > wildcard subdomain cache issue, not need to depend on DNSSEC.* > > Authoritative server just simply add one SWILD RR, not much deploy cost= . > > Recursive server can add SWILD support if it has an interest in wildcar= d > > subdomain cache optimization, it is OPT-IN. > > > > *I don't expect implementers would adopt SWILD 100% before adopting > > DNSSEC+NSEC aggressive. Just give an alternative choice, implementers c= an > > decide adopting or not, before or after, we won't pre-select for them.* > > we do, though, and we must. DNSSEC development began in 1996, and > deployment > is stalled due to lack of motivation. it is the IETF's position that > DNSSEC is > a public good in that it will enable a general world-wide security level > that > has always eluded the Internet. > > any DNSSEC feature that we decide to offer separately ("a la carte") is > both a > missed opportunity to increase the deployment of DNSSEC, and a > self-inflicted > wound that deliberately further stalls that deployment. > > noting that DNSSEC as a protocol is of atrociously low quality ("it's > crap"), > i am in no way defending the design itself. however, it does work, and we > would be acting contrary to our own best interests ("folly") if we took u= p > anything like SWILD, or allowed anything like SWILD on the individual > track. > > failing that level of commitment, the IETF ought to kill DNSSEC altogethe= r. > > this is very similar to the "shall we had IPv6's features to IPv4, since > V6 is > taking so long to deploy, and these features are badly needed?" debate. > > vixie > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c1957843499dc0556af7ed6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Maybe it makes a mou= ntain out of a molehill.
"Give to the emperor the things that are t= he emperor's, and to God the things that are God's.=E2=80=9C, we ca= n seperate security issue and subdomain wildcard cache issue.

=
I think,=C2=A0 SWILD has no influence on DNSSEC deployment :
1) If recursive wants to deploy DNSSEC, it is almost impossible becau= se of NSEC/NSEC3 aggressiveuse Wildcards. Security need is the greatest = motivation behind DNSSEC depolyment.
2) If recursive doesn't want to deploy DNSSEC, it is almos= t impossible because of SWILD. Imagine that, there is no SWILD to give prec= ise subdomain wildcard information from authoritative, recursive can use ra= ndom subdomain detect method to make cache optimization, which was describe= d in DNS Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS = Traffic.

But the rat= e of "DNSSEC + NSEC + default dns query with DNSSEC=E2=80=9D has=20 influnence on subdomain wildcard cache issue if we only accept unique=20 solution depend on it.

P= aul Vixie <paul@redbarn.org>= =E4=BA=8E2017=E5=B9=B48=E6=9C=8812=E6=97=A5=E5=91=A8=E5=85=AD =E4=B8=8B=E5= =8D=8811:42=E5=86=99=E9=81=93=EF=BC=9A
On Saturday, August 12, 2017 8:29:45 AM GMT Lanlan Pan wrote:
> ...
>
> SWILD is a feature just for recusive cache optimization, only dealing = with
> the wildcard subdomain issue (with no nodes below).
> DNSSEC + NSEC aggressive is security feature, with cryptographic conte= nts
> such as KSK/ZSK/NSEC/NSEC3/NSEC5/...
>
> My assumption is: *we can give recursive server an alternative solutio= n for
> wildcard subdomain cache issue, not need to depend on DNSSEC.*
> Authoritative server just simply add one SWILD RR, not much deploy cos= t.
> Recursive server can add SWILD support if it has an interest in wildca= rd
> subdomain cache optimization,=C2=A0 it is OPT-IN.
>
> *I don't expect implementers would adopt SWILD 100% before adoptin= g
> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers = can
> decide adopting or not, before or after, we won't pre-select for t= hem.*

we do, though, and we must. DNSSEC development began in 1996, and deploymen= t
is stalled due to lack of motivation. it is the IETF's position that DN= SSEC is
a public good in that it will enable a general world-wide security level th= at
has always eluded the Internet.

any DNSSEC feature that we decide to offer separately ("a la carte&quo= t;) is both a
missed opportunity to increase the deployment of DNSSEC, and a self-inflict= ed
wound that deliberately further stalls that deployment.

noting that DNSSEC as a protocol is of atrociously low quality ("it= 9;s crap"),
i am in no way defending the design itself. however, it does work, and we would be acting contrary to our own best interests ("folly") if w= e took up
anything like SWILD, or allowed anything like SWILD on the individual track= .

failing that level of commitment, the IETF ought to kill DNSSEC altogether.=

this is very similar to the "shall we had IPv6's features to IPv4,= since V6 is
taking so long to deploy, and these features are badly needed?" debate= .

vixie
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD= =98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--94eb2c1957843499dc0556af7ed6-- From nobody Mon Aug 14 00:26:28 2017 Return-Path: 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 12B59131D27 for ; Mon, 14 Aug 2017 00:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Uq4xgR63V1oh for ; Mon, 14 Aug 2017 00:26:24 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FFF131D19 for ; Mon, 14 Aug 2017 00:26:24 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t138so15094826wmt.1 for ; Mon, 14 Aug 2017 00:26:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3MzqldQnWAAtmNU54WC+aCzUzlxbGLkHE7Ia2VCjeM0=; b=lbAkMr7WrJC/DyGt/5Hq2nbbtg+lmiBgQLmbIY1rcGgTjXOaJJTGY2M8zUpxJAbT09 XitaBrMzWIvtqAOXLX1Ke/NxZvKm/2lYt2Gbui2TtRyzJxkzIU8RQp7na3ffLpCOfvaP c7j1KLH7CHJZzBq71gi/LHYOyMmbUYksuJsXEDbu2dFhTsXPtw0MsLKROjateZBEZFIF 1XGZyZ4YHOwQeks4x3HbEmes6Z/0Q3eJt+FSHeuqfhGdzerwKW8L/GJIpwxRr1pu66Tp bULYe+ziCt+Sjlfk/GiU+zMuivw0tsZ38F29HJwApNsnLXpYLN/KKHD8sBn3F9JGECOG jYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3MzqldQnWAAtmNU54WC+aCzUzlxbGLkHE7Ia2VCjeM0=; b=VV0W9sQY50q5KhUeGsg4wk0byjsPGj5fFkh6sMqSy/moqt5+4WzFfRVoLkGj6wwaDP Av3jrAQnsMEz9GeSfJ7ebPYLORGZAgTqdP9tV4Td18LAsax4P/i1pdt6ikszSQmzr1Dm y3+KFzQC1lMPW0loijBUWF8rTLzhc9He/o1y+LerrjYsXgboYE/rKdYlJ0D/pn82PaxB /VBPUW831r29/eAqU8rN60Xm/tFmAUegi/V2pBZe/zZ+erI40nVYb1ER5tiPk8hzaY+m Y+jAd5NJXrmrB7liXVRhExYKTj2mSmi5uw2DFOpSJBQnAAjEo/3+PCG+IXal+tNa6pgt sbSQ== X-Gm-Message-State: AHYfb5hFFOGK249pPtLKSyvWlaK6ZE2F/hDtsOW2q+OpJVlEdoiHf0SF K6OGKu+XObhSE9J73/dxlTapMCmrSg== X-Received: by 10.80.146.5 with SMTP id i5mr22934429eda.48.1502695582515; Mon, 14 Aug 2017 00:26:22 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> In-Reply-To: From: Lanlan Pan Date: Mon, 14 Aug 2017 07:26:11 +0000 Message-ID: To: Matthew Pounsett Cc: Paul Hoffman , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , dnsop , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="f403045c0c4666c5e50556b19410" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 07:26:27 -0000 --f403045c0c4666c5e50556b19410 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Matthew, Thanks for your detailed reply, :-) Matthew Pounsett =E4=BA=8E2017=E5=B9=B48=E6=9C=8813=E6= =97=A5=E5=91=A8=E6=97=A5 =E4=B8=8A=E5=8D=8812:31=E5=86=99=E9=81=93=EF=BC=9A > On 12 August 2017 at 04:29, Lanlan Pan wrote: > >> Hi Matthew =EF=BC=86 Paul, >> >> Good question, :-) >> >> SWILD is a feature just for recusive cache optimization, only dealing >> with the wildcard subdomain issue (with no nodes below). >> DNSSEC + NSEC aggressive is security feature, with cryptographic content= s >> such as KSK/ZSK/NSEC/NSEC3/NSEC5/... >> >> My assumption is: *we can give recursive server an alternative solution >> for wildcard subdomain cache issue, not need to depend on DNSSEC.* >> Authoritative server just simply add one SWILD RR, not much deploy cost. >> Recursive server can add SWILD support if it has an interest in wildcard >> subdomain cache optimization, it is OPT-IN. >> > > I confess it was a rhetorical question. All of the major implementations > already support DNSSEC. 8198 doesn't have an implementation status > section, but there's every reason to think the major implementations will > have support within a version of two. A quick survey of a few issues > databases shows that at least Knot is already working on it. That is a > significant head start; SWILD support without DNSSEC support can't happen > in any significant way, and SWILD support without support for 8198 doesn'= t > seem likely. > We know that we will have a Swiss Army knife (DNSSEC) in the future, can we also put a Fruit knife (SWILD) in the kitchen now? > > As for operator adoption, the incentives are all wrong for this to > actually get used. > > Recursive operators already have a very low operational bar to turn on > DNSSEC and get the same benefit to their cache. In both cases (SWILD and > DNSSEC) they rely on the authoritative operator opting in before that > benefit can be realized. > > Authoritative operators may choose to use DNSSEC because it will secure > their zone, and if recursive operators also have 8198-capable name server= s > then the workload for both authoritative and recursive is reduced for all > terminal names. > > With SWILD, there is no direct benefit to the authoritative operator, as > far as I can see. Given that the only benefit to using SWILD is to the > recursive operator, what is the motivation for the authoritative operator > to add complexity to their deployment by adopting it? Traditional > wildcards work fine for them. > Authoritative will be directly benefit, save cost, reduce wildcard subdomain response laterncy. As methioned in the draft : "Intermediate Nameservers' cache hit rate will rise, avoid to query Authoritative Nameserver for the same wildcard domain configuration." Imagine that Recursive Resolver knows that SWILD RR of wildcard domain "*. foo.com". In TTL time, if Recursive Resolver receives " yyy.foo.com/zzz.foo.com/..." A RR query, it can directly return this subdomain wildcard response without send dns queries to Authoritative. Traditional wildcards work no so fine for them, it make recursive send many subdomain dns queries to Authoritative. Authoritative operators can choose DNSSEC because of security, they can also choose SWILD because of wildcard domain response optimization. Not contradictory. > To make the adoption problem worse, it appears as if SWILD is more limite= d > in its use than traditional wildcards. For example, I don't see how you > could occlude an SWILD record with a more-specific domain name, as you ca= n > with traditional wildcards. > Here's a common scenario based on the example from the draft: > @ 86400 IN SWILD _ > _ 3600 IN CNAME map.bar.net. > * 600 IN CNAME _ > dev 600 IN CNAME map.dev.bar.net. > > How does SWILD behave when a client queries for dev? According to the > draft, the authoritative server would return the SWILD record at the apex= . > An SWILD-aware recursive server seems like it would ignore the CNAME > returned for dev and instead use the CNAME for _, which is not what the > operator intended. > As I replied to Petr, "many wildcards occupy the Resolver cache, with no nodes below them." Most of the subdomain wildcards for CDN, P2P, advertise, anti-virus, DNSBLs service have not specific subdomain like "dev", SWILD is not for this condition. > >> >> *I don't expect implementers would adopt SWILD 100% before adopting >> DNSSEC+NSEC aggressive. Just give an alternative choice, implementers ca= n >> decide adopting or not, before or after, we won't pre-select for them.* >> Even if both Authoritative server and Recursive server support >> DNSSEC+NSEC aggressive, when will they configure default dns query with >> dnssec ? (for NSEC agreesive cached deduced wildcard) >> > > We already know that a year ago 26% of all end users were behind some sor= t > of validating resolver, a number which continues to climb as more ISPs tu= rn > on validation, and more users switch to things like Google Public DNS > . This > isn't an ideal deployment status so long after DNSSEC was standardized, b= ut > it's a long way ahead of SWILD. > Every protocol feature has a deployment progress, nobody thinks that will be a short time, the same with other features such as ANAME, DANE, ... > You'll need to have a very compelling argument for me to believe that > SWILD is both more useful than DNSSEC and more likely to be deployed at a= ny > kind of scale that would make a difference. I just don't see it. > > Add to that Paul's point that we would very much like to encourage DNSSEC > adoption, I don't see why we'd add support for an alternative technology > that accomplishes a subset of its features. > I don't think SWILD will be more useful than DNSSEC, everyone knows that they are different features, and it is impossible. I think SWILD has no influence on DNSSEC deployment, details in last mail replied to Paul. One question: is wildcard subdomain cache issue solution must bind with security feature ? --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c0c4666c5e50556b19410 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Matthew,

Thanks for your detailed re= ply, :-)

On 12 August 2017 at 04:29, Lanlan Pan <abbypan@gmail.com> wrote:
Hi Matthew =EF=BC=86 Paul,

Good q= uestion, :-)

SWILD is a feature just for recusive cache optimi= zation, only dealing with the wildcard subdomain issue (with no nodes below= ).
DNSSEC + NSEC aggressive is security feature, with cryptographi= c contents such as KSK/ZSK/NSEC/NSEC3/NSEC5/...

My = assumption is: we can give recursive server an alternative solution for = wildcard subdomain cache issue, not need to depend on DNSSEC.
=
Authoritative server just simply add one SWILD RR, not much deploy cos= t.
Recursive server can add SWILD support if it has an interest in wildc= ard subdomain cache optimization,=C2=A0 it is OPT-IN.
=

I confess it was a rhetori= cal question. All of the major implementations already support DNSSEC. =C2= =A08198 doesn't have an implementation status section, but there's = every reason to think the major implementations will have support within a = version of two.=C2=A0 A quick survey of a few issues databases shows that a= t least Knot is already working on it.=C2=A0 That is a significant head sta= rt; SWILD support without DNSSEC support can't happen in any significan= t way, and SWILD support without support for 8198 doesn't seem likely.<= /div>
=C2=A0
We know that we w= ill have a Swiss Army knife (DNSSEC) in the future, can we also put a Fruit= knife (SWILD) in the kitchen now?
=C2=A0

As for operator adoption, the incentives are all = wrong for this to actually get used.

Recursive ope= rators already have a very low operational bar to turn on DNSSEC and get th= e same benefit to their cache.=C2=A0 In both cases (SWILD and DNSSEC) they = rely on the authoritative operator opting in before that benefit can be rea= lized.

Authoritative operators may choose to use D= NSSEC =C2=A0because it will secure their zone, and if recursive operators a= lso have 8198-capable name servers then the workload for both authoritative= and recursive is reduced for all terminal names.

= With SWILD, there is no direct benefit to the authoritative operator, as fa= r as I can see.=C2=A0 Given that the only benefit to using SWILD is to the = recursive operator, what is the motivation for the authoritative operator t= o add complexity to their deployment by adopting it?=C2=A0 Traditional wild= cards work fine for them.

Auth= oritative will be directly benefit, save cost, reduce wildcard subdomain re= sponse laterncy.

As methioned in the draft : "Intermediate Name= servers' cache hit rate will rise, avoid to query Authoritative Nameser= ver for the same wildcard domain configuration."
Imagine that Recur= sive Resolver knows that SWILD RR of wildcard domain "*.foo.com". In TTL time, if Recursive Resolver receives= "yyy.foo.com/zzz.foo.co= m/..." A RR query, it can directly return this subdomain wildcard = response without send dns queries to Authoritative.

Traditional wild= cards work no so fine for them, it make recursive send many subdomain dns q= ueries to Authoritative.

Authoritative operators can choose DNSSEC b= ecause of security,=C2=A0 they can also choose SWILD because of wildcard do= main response optimization.=C2=A0 Not contradictory.


To make the adoption probl= em worse, it appears as if SWILD is more limited in its use than traditiona= l wildcards.=C2=A0 For example, I don't see how you could occlude an SW= ILD record with a more-specific domain name, as you can with traditional wi= ldcards. =C2=A0
Here's a common scenario based on the example= from the draft:
=C2=A0 = =C2=A0@ =C2=A0 =C2=A086400 =C2=A0IN =C2=A0 SWILD =C2=A0_
<= font face=3D"monospace, monospace">=C2=A0 =C2=A0_ =C2=A0 =C2=A0 3600 =C2=A0= IN =C2=A0 CNAME =C2=A0map.= bar.net.
=C2=A0 = =C2=A0* =C2=A0 =C2=A0 =C2=A0600 =C2=A0IN =C2=A0 CNAME =C2=A0_
<= /div>
=C2=A0dev =C2=A0 =C2=A0 = =C2=A0600 =C2=A0IN =C2=A0 CNAME =C2=A0map.dev.bar.net.

How does SWILD behave when a cli= ent queries for dev?=C2=A0 According to the draft, the authoritative server= would return the SWILD record at the apex.=C2=A0 An SWILD-aware recursive = server seems like it would ignore the CNAME returned for dev and instead us= e the CNAME for _, which is not what the operator intended.=C2=A0

As I replied to Petr, "= many wildcards occupy the Resolver cache, with no nodes below them."
Most of the subdomain wildcards for CDN, P2P, advertise, a= nti-virus, DNSBLs service have not specific subdomain like "dev",= =C2=A0 SWILD is not for this condition.

=C2=A0

I don't expect implement= ers would adopt SWILD 100% before adopting DNSSEC+NSEC aggressive. J= ust give an alternative choice, implementers can decide adopting or not,= before or after, we won't pre-select for them.
Even if both= Authoritative server and Recursive server support=20 DNSSEC+NSEC aggressive, when will they configure default dns query with dns= sec ?=20 (for NSEC agreesive cached deduced wildcard)

We already know that a year ago 26% o= f all end users were behind some sort of validating resolver, a number whic= h continues to climb as more ISPs turn on validation, and more users switch= to things like Google Public DNS
<https:/= /labs.apnic.net/presentations/store/2016-06-27-dnssec.pdf>.=C2=A0 Th= is isn't an ideal deployment status so long after DNSSEC was standardiz= ed, but it's a long way ahead of SWILD.

Every protocol feature has a deployment progress, nobody thin= ks that will be a short time, the same with other features such as ANAME, D= ANE, ...


You= 9;ll need to have a very compelling argument for me to believe that SWILD i= s both more useful than DNSSEC and more likely to be deployed at any kind o= f scale that would make a difference.=C2=A0 I just don't see it.
<= div>
Add to that Paul's point that we would very much lik= e to encourage DNSSEC adoption, I don't see why we'd add support fo= r an alternative technology that accomplishes a subset of its features.

I don't think SWILD will be m= ore useful than DNSSEC,=C2=A0 everyone knows that they are different featur= es, and it is impossible.

I think SWILD has no influence = on DNSSEC deployment,=C2=A0 details in last mail replied to Paul.

One question:=C2=A0 is wildcard subdomain cache issue = solution must bind with security feature ?

<= /div>
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Re= gards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--f403045c0c4666c5e50556b19410-- From nobody Mon Aug 14 04:30:28 2017 Return-Path: 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 BE03D1321A7 for ; Mon, 14 Aug 2017 04:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 aC3q7vD6p3hJ for ; Mon, 14 Aug 2017 04:30:23 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5247713219E for ; Mon, 14 Aug 2017 04:30:23 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id s6so49916962qtc.1 for ; Mon, 14 Aug 2017 04:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q/pu3pQE7J0qCOHmyFk5H4lCsjP9Yu4ShUEtYcOV3Ic=; b=TNg3EdvSKxRsnL7pyxQt/EKKFgZe+OlKrP6OV6xLIO/pyM2AaQ8RdTTR2WsmClcZm7 74V+CNVEDzYEdQd/jrfZtiFM6FvEyBkn6quiTISE8I2FHFMjpU7At7EtS5gaWx/mdEeW Zu4k2+5Qgh93mmbyV7u7WaBsJChOQ+jlJLC0zypgMlg8hpis8OxoKPrLklGWeeCt1hGc 2/8EVyCdwCIh+ideCUh0ow9HS8bshKarstdbFE6C2Hk8mSypRyyTGa2B4wQ5vwsmTklh 0XAA1HYdj0LkBXHVBgN3HCEOWaxXtmoxOiUuNS0nFFLrtEclq3DZoyrcHSz1RNAGYjis vzXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q/pu3pQE7J0qCOHmyFk5H4lCsjP9Yu4ShUEtYcOV3Ic=; b=tMrliQYGI68OfLp6JWdTU6q+U3n/LxSBFMoFHWE86ch1yBIohMuDe2ZxvfFKB+Ulzz Bcqq+UMzYgv7yBKsW2Lr13OWmw7lHODJOV5BBb+TnqKORD+T8nJPOHf8SjXD7wUWWgQM WaglEKjJohFwL+80z+UExpcNgNbr5jgTlEHIeJQyggSS9d5OUPaXg6XuWchFCjd+lDEi 0I1OVCgkLURM6qVQXbeZLEmcye36pLGD6kf/s5ZaQDpKh9rCIfv/h1FtrA8XhRM0I1Cy CyQGiRfQjtDvKzGhJ4mAlfvq50vW7PbUF05G2WOqE3ZFplJ3l13qTCLvFdN0ESCPP3GY MkWw== X-Gm-Message-State: AHYfb5jNYaeRpJHRZs8fWjkwBWpAISgvn1oUe+/WeXdIuWIHFcTq0mt0 l5rKGOjEsqBWpVMoMaUpKEA3E/J1JCVGiY/9iA== X-Received: by 10.200.40.204 with SMTP id j12mr30378502qtj.139.1502710222069; Mon, 14 Aug 2017 04:30:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.25.236 with HTTP; Mon, 14 Aug 2017 04:30:01 -0700 (PDT) In-Reply-To: <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> From: Mike West Date: Mon, 14 Aug 2017 13:30:01 +0200 Message-ID: To: dnsop Cc: Ted Lemon , Tony Finch , Mark Andrews Content-Type: multipart/alternative; boundary="001a114070dafd281d0556b4fc3b" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 11:30:26 -0000 --001a114070dafd281d0556b4fc3b Content-Type: text/plain; charset="UTF-8" I've uploaded an -05 draft (diff to -04 ) that addresses some of the feedback in this thread, Ted Lemon's in particular. It attempts to spell out the rationale for the NXDOMAIN change more clearly, boiling it down to Ted's suggestion that we ought to be recommending that stub resolvers fail closed when they forward requests for localhost names on to recursive resolvers. The draft also follows up on recommendations that Mark and others have made regarding DNSSEC by requesting an insecure delegation of `localhost.` in the root-zone (I found Warren's notes on the topic in https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4 quite useful, btw). Tony: I'd like to understand more clearly what justification you'd like the draft to present. Do the changes in -05 give the reader enough context, or does it need more work in that regard? Does shifting the application-level requirements into the main body of the draft, out of the implementation considerations section, make the requirements around security decisions for localhost names clear enough? -mike On Mon, Aug 14, 2017 at 2:36 AM, Tony Finch wrote: > > > On 13 Aug 2017, at 23:51, Paul Hoffman wrote: > > > > On 13 Aug 2017, at 10:19, Tony Finch wrote: > >> > >> > >> RFC 6761 requires recursive servers to return positive 127.0.0.1 and > ::1 responses, not NXDOMAIN. I can't see an explanation in the draft for > the change to NXDOMAIN. > > > > And there should be. Proposed addition to the last paragraph of Section > 1: > > > > A consequence of the requirement that the resolver APIs MUST resolve > "localhost." and any names falling within ".localhost." to loopback > addresses is that caching DNS servers and authoritative DNS servers MUST > NOT resolve those names at all, and always return NXDOMAIN. > > Well, that isn't really the kind of text I wanted. > > You have written a paragraph that is obvious from the internal logic of > the draft, but it doesn't say why "a consequence" has changed from RFC 6761. > > What we really need is an informed analysis of the consequences of > different ways of sinking localhost queries on recursive servers. The de > facto way is NXDOMAIN (same as what happens when there is no special case > in the resolver, except without the recursion to the root servers). The RFC > 6761 way is to return locally authoritative positive responses. > > Either way, BIND (for instance) needs special configuration to be RFC 6761 > compliant or NXDOMAIN compliant, so some kind of code change is needed to > make the Right Thing the default, but which Thing's Rightness needs > justification. > > There are also missing security considerations. The whole draft is > motivated by web security edge cases, so I would like to see a summary and > citation of the same site scripting problem, and whatever other issues > there might be. > > Does the change from positive responses to NXDOMAIN have some connection > to the web security motivation? It isn't clear to me and it ought to be. > > There is also a weird compatibility awkwardness. RFC 6761 requires > *.localhost to resolve to localhost, in stub and recursive resolvers. You > can't implement this in traditional Unix libc resolvers. It's possible to > implement this in a recursive server like BIND, but I realised this week > that I had not implemented the wildcard in my config, so I bet proper RFC > 6761 conformance is rare. > > The upshot of the draft's current text is that full system behaviour will > vary depending on libc version, recursor version, recursor config, etc. > > I think it is still a good idea to tighten up the implementation > requirements to MUST. That part of the draft is good, but trivial. > > The interesting part is not stated in the current text: it is that > application software that makes security assumptions about localhost MUST > internally resolve localhost without relying on the shifting historical and > operational variability of stub resolvers and recursive servers. > > Tony. > -- > f.anthony.n.finch http://dotat.at > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114070dafd281d0556b4fc3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've uploaded an -05 draft=C2=A0(diff to -04) that addresses some of the feedback in this threa= d, Ted Lemon's in particular. It attempts to spell out the rationale fo= r the NXDOMAIN change more clearly, boiling it down to Ted's suggestion= that we ought to be recommending that stub resolvers fail closed when they= forward requests for localhost names on to recursive resolvers.

The draft also follows up on recommendations that Mark and others = have made regarding DNSSEC by requesting an insecure delegation of `localho= st.` in the root-zone (I found Warren's notes on the topic in=C2=A0https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4 quite useful, btw).



On Mon, Aug 14, 2017 at 2:36 AM, Tony Finch = <dot= @dotat.at> wrote:

> On 13 Aug 2017, at 23:51, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
>
> On 13 Aug 2017, at 10:19, Tony Finch wrote:
>>
>>
>> RFC 6761 requires recursive servers = to return positive 127.0.0.1 and ::1 responses, not NXDOMAIN. I can't s= ee an explanation in the draft for the change to NXDOMAIN.
>
> And there should be. Proposed addition to the last paragraph of Sectio= n 1:
>
> A consequence of the requirement that the resolver APIs MUST resolve &= quot;localhost." and any names falling within ".localhost." = to loopback addresses is that caching DNS servers and authoritative DNS ser= vers MUST NOT resolve those names at all, and always return NXDOMAIN.

Well, that isn't really the kind of text I wanted.

You have written a paragraph that is obvious from the internal logic of the= draft, but it doesn't say why "a consequence" has changed fr= om RFC 6761.

What we really need is an informed analysis of the consequences of differen= t ways of sinking localhost queries on recursive servers. The de facto way = is NXDOMAIN (same as what happens when there is no special case in the reso= lver, except without the recursion to the root servers). The RFC 6761 way i= s to return locally authoritative positive responses.

Either way, BIND (for instance) needs special configuration to be RFC 6761 = compliant or NXDOMAIN compliant, so some kind of code change is needed to m= ake the Right Thing the default, but which Thing's Rightness needs just= ification.

There are also missing security considerations. The whole draft is motivate= d by web security edge cases, so I would like to see a summary and citation= of the same site scripting problem, and whatever other issues there might = be.

Does the change from positive responses to NXDOMAIN have some connection to= the web security motivation? It isn't clear to me and it ought to be.<= br>
There is also a weird compatibility awkwardness. RFC 6761 requires *.localh= ost to resolve to localhost, in stub and recursive resolvers. You can't= implement this in traditional Unix libc resolvers. It's possible to im= plement this in a recursive server like BIND, but I realised this week that= I had not implemented the wildcard in my config, so I bet proper RFC 6761 = conformance is rare.

The upshot of the draft's current text is that full system behaviour wi= ll vary depending on libc version, recursor version, recursor config, etc.<= br>
I think it is still a good idea to tighten up the implementation requiremen= ts to MUST. That part of the draft is good, but trivial.

The interesting part is not stated in the current text: it is that applicat= ion software that makes security assumptions about localhost MUST internall= y resolve localhost without relying on the shifting historical and operatio= nal variability of stub resolvers and recursive servers.

Tony.
--
f.anthony.n.finch=C2=A0 <dot@dotat.at>=C2=A0 http://dotat.at
________________= _______________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

--001a114070dafd281d0556b4fc3b-- From nobody Mon Aug 14 07:37:02 2017 Return-Path: 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 05E60132344 for ; Mon, 14 Aug 2017 07:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 S1f7vW8s-wKA for ; Mon, 14 Aug 2017 07:36:57 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D13713232C for ; Mon, 14 Aug 2017 07:36:57 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id a77so51214619qkb.0 for ; Mon, 14 Aug 2017 07:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MElMcZjrEyiFjpiSaqdd+qpFZE3kN5vqHu0DeTPVYFk=; b=ZlqEi1VSvEcUatzhUayjmd4rNkCGvlzUbhtCOJpeo+LfQdQSzcd9YnTEtSAFGMZTuK RkBEFw7iGj7SomLUZjsmOJIzbAiNAemDeidY4zavGqzAIj8hP3PqRrOFylTlSKjoet++ 70t5sxS11AKy8sBkpkNSCabDRqIAnOf1f+JT3QUXWSVHb2Qoez0Krc/0gvoqaG83y4t8 72yw4LkUYcF52F9B34kT+LLO43nu6Q1CSVAYNxzl5I50vN8ubEvvDjGqVBHUDQqrOJlD 1rzSWG+fqOhe2MZFlVwSkKWV+u0AqQH6/HboZK4DxIhgzRNWVA2ANgmyn55Uxh65hiQK T6VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MElMcZjrEyiFjpiSaqdd+qpFZE3kN5vqHu0DeTPVYFk=; b=MCjpiLue3tfc/4prmGGd4R4jAwQsqAJqvunLdRl0dHw2h3JsfmpXl8xUsUEtOg53Yj ZQGISttSQV+jjHS7ZQ4bRZsZQ9kRFUBnCqkoz22aKklZU3SjodJROpWI2eFrA6hIGp9R 7BdhfqwCS8bP3u6+z0CRREK/xz+lROrgVyZCnrjstwSKguGfU9H4pI91w3m4JLaSbKjz FYE4D+dwv20ijiebvU39AtbXK8ZFQTk1UP1tuBVwGaNLSePysQziwqU2mwJ8o+Pw0JrK FMcf/Mt/IOYaqi+hB/qz1H0D7aJ9azpao1qBKC3W3rq2P7pCKJHzs90VttvtOssiRaFc Whfw== X-Gm-Message-State: AHYfb5goYS9TGiNj0EcQx0GjOzzThImcDp49nGYkxtW1JVocc1RHzEkf 62MJiTv1E7hCL1aI X-Received: by 10.55.207.72 with SMTP id e69mr6143883qkj.34.1502721416499; Mon, 14 Aug 2017 07:36:56 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 22sm5370066qto.36.2017.08.14.07.36.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Aug 2017 07:36:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ted Lemon In-Reply-To: Date: Mon, 14 Aug 2017 10:36:54 -0400 Cc: dnsop , Tony Finch , Mark Andrews Content-Transfer-Encoding: quoted-printable Message-Id: <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com> References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> To: Mike West X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 14:37:00 -0000 El 14 ag 2017, a les 7:30, Mike West va escriure: > I've uploaded an -05 draft (diff to -04) that addresses some of the = feedback in this thread, Ted Lemon's in particular. It attempts to spell = out the rationale for the NXDOMAIN change more clearly, boiling it down = to Ted's suggestion that we ought to be recommending that stub resolvers = fail closed when they forward requests for localhost names on to = recursive resolvers. This doesn't actually address my concerns. Sorry to be a sticky = wicket. Here is what I think the text should say: OLD: This document updates RFC6761 with the goal of ensuring that "localhost" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS = servers are required to return "NXDOMAIN" when queried for localhost names, which will cause non-conformant stub resolvers to fail safely = closed. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. NEW: This document updates RFC6761 with the goal of ensuring that "localhost" can be safely relied upon as a name for the local host's loopback interface. To that end, stub resolvers are required to resolve localhost names to loopback addresses. Recursive DNS = servers are required to return "NXDOMAIN" when queried for localhost names, making non-conformant stub resolvers more likely to fail and produce problem reports that result in updates. Together, these requirements would allow applications and specifications to join regular users in drawing the common-sense conclusions that "localhost" means "localhost", and doesn't resolve to somewhere else on the network. OLD: This document hardens [RFC6761]'s recommendations regarding "localhost" by requiring that name resolution APIs and libraries themselves return a loopback address when queried for localhost names, bypassing lookup via recursive and authoritative DNS servers entirely. Further, recursive and authoritative DNS servers are required to return "NXDOMAIN" for such queries, ensuring that non- conformant stub resolvers will fail safely. NEW: This document updates [RFC6761]'s recommendations regarding "localhost" by requiring that name resolution APIs and libraries themselves return a loopback address when queried for localhost names, bypassing lookup via recursive and authoritative DNS servers entirely. In addition, recursive and authoritative DNS servers are required to return "NXDOMAIN" for such queries. This increases the likelihood that non-conformant stub resolvers will not go = undetected. Note that this does not have the result that such resolvers will fail safe=E2=80=94it just makes it more likely that they will be = detected and fixed, since they will fail in the presence of conforming name servers. These changes are not sufficient to ensure that "localhost" can be assumed to actually refer to an address on the local machine. This document therefore further requires that applications that wish to make that assumption handle the name "localhost" specially. OLD: If application software wishes to make security decisions based upon the assumption that localhost names resolve to loopback addresses (e.g. if it wishes to ensure that a context meets the requirements laid out in [SECURE-CONTEXTS]), then it SHOULD = avoid relying upon name resolution APIs, instead performing the resolution itself. If such software chooses to rely on name resolution APIs, it MUST verify that the resulting IP address is a loopback address before making a decision about its security properties. NEW: If application software wishes to make security decisions based upon the assumption that localhost names resolve to loopback addresses (e.g. if it wishes to ensure that a context meets the requirements laid out in [SECURE-CONTEXTS]), then it MUST directly translate the name "localhost" to an IP address that connects locally, and MUST NOT rely upon name resolution APIs. =20 The text about checking the address returned by the API doesn't make = sense=E2=80=94it's easier to just do the translation, and so an = application that doesn't do the translation isn't going to check. Keep = it simple. OLD: In any event, application software MUST NOT use a searchlist to resolve a localhost name. That is, even if DHCP's domain search option [RFC3397] is used to specify a searchlist of = "example.com" for a given network, the name "localhost" will not be resolved = as "localhost.example.com", and "subdomain.localhost" will not be resolved as "subdomain.localhost.example.com". NEW: Application software MUST NOT use a searchlist to resolve a localhost name. That is, even if DHCP's domain search option [RFC3397] is used to specify a searchlist of = "example.com" for a given network, the name "localhost" will not be resolved = as "localhost.example.com", and "subdomain.localhost" will not be resolved as "subdomain.localhost.example.com". (For consistency with previous change) On the topic of DNSSEC, the root currently returns a secure denial of = existence. This is exactly right=E2=80=94there's no reason to change = it. You need a security considerations section. I suggest the following: --- Some applications may consider it useful to treat a connection to an = endpoint on the same host as more trustworthy than a connection to other = endpoints. This assumption is not entirely safe=E2=80=94it is possible = for example that an application that is sandboxed could still listen for = connections from the local host, and thereby present a security = vulnerability to other applications that mistakenly assume that some = other service is listening for connections on that port. A similar risk = can be present for a sandboxed application connecting to localhost if = the local host is infected by malware that listens on a particular local = port. Such situations may be considered out of scope, however, in the = sense that if malware is running on the local host, it may have easier = opportunities for attack than listening for connections on a local port. = The sandbox example is mentioned because malware that successfully = attacks a sandboxed application may still be contained in the sandbox; = trusting localhost in this case could penetrate that protection. Applications that attempt to use the local resolver to query "localhost" = do not fail safe: if an attacker sets up a DNS server returning a = non-local answer for "localhost," such applications will connect to that = remote server assuming it is local. This is the reason for the = requirement that applications using "localhost" process it specially, = rather than relying on the local resolver. =20 There may be cases where the target runtime environment is such that it = can be safely assumed that the local resolver does the right thing; in = this case the requirement that the application do the translation on its = own may be safe to ignore, but only if all of the requirements under = point 2 of section 3 are known to be followed by the resolver that is = known to be present in the target runtime environment. --- The first paragraph is rather tendentious. My reason for presenting it = is not to claim that you should put that exact text in the security = considerations section, but rather to suggest that this is possibly = something that the working group should consider doing if the document = is adopted, as seems likely. My personal opinion is that trusting = localhost is a bad idea, but I realize that this may not be the = consensus.= From nobody Mon Aug 14 11:39:08 2017 Return-Path: X-Original-To: dnsop@ietf.org Delivered-To: dnsop@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BF21321F0; Mon, 14 Aug 2017 11:39:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: tjw.ietf@gmail.com, warren@kumari.net, dnsop@ietf.org, dnsop-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273594689.453.1709028569010475439.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:39:06 -0700 Archived-At: Subject: [DNSOP] dnsop - New Meeting Session Request for IETF 100 X-BeenThere: dnsop@ietf.org X-Mailman-Version: 2.1.22 List-Id: IETF DNSOP WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:39:07 -0000 A new meeting session request has just been submitted by Tim Wicinski, a Chair of the dnsop working group. --------------------------------------------------------- Working Group Name: Domain Name System Operations Area Name: Operations and Management Area Session Requester: Tim Wicinski Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 160 Conflicts to Avoid: First Priority: dprive dnssd homenet dhc Second Priority: v6ops intarea trans ideas Third Priority: 6man grow opsarea opsawg pcp saag sidr People who must be present: Suzanne Woolf Joel Jaeggli Warren Kumari Tim Wicinski Resources Requested: Special Requests: If either session is slotted for Friday, please make it the second 1 hour session. thanks --------------------------------------------------------- From nobody Mon Aug 14 14:32:14 2017 Return-Path: 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 E98B113243E for ; Mon, 14 Aug 2017 14:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 wPsTQ7G8603Z for ; Mon, 14 Aug 2017 14:32:10 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 247D013243A for ; Mon, 14 Aug 2017 14:32:10 -0700 (PDT) Received: from [10.1.7.203] (63-158-87-14.dia.static.qwest.net [63.158.87.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id CDCB861FF3; Mon, 14 Aug 2017 21:32:08 +0000 (UTC) Message-ID: <599216D2.8060608@redbarn.org> Date: Mon, 14 Aug 2017 14:32:02 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Lanlan Pan CC: dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 21:32:12 -0000 WG Chairs: i oppose adoption of this draft. Lanlan Pan wrote: > Hi Paul, > > ... tl;dr: this message marks the end of this thread from my side. > I think, SWILD has no influence on DNSSEC deployment : 1) If > recursive wants to deploy DNSSEC, it is almost impossible because of > NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest > motivation behind DNSSEC depolyment.* 2) If recursive doesn't want > to deploy DNSSEC, it is almost impossible because of SWILD. Imagine > that, there is no SWILD to give precise subdomain wildcard > information from authoritative, recursive can use random subdomain > detect method to make cache optimization, which was described in DNS > Noise: Measuring the Pervasiveness of Disposable Domains in Modern > DNS Traffic > . Mr. Pan, your words above are a striking example of absurd reduction, which through a series of difficult-to-assail false equivalencies, an outcome unacceptable to your correspondent may begin to "look good on paper". Proof of this can by found by trying to reason your way to the conclusion you are offering, by any other path. You'll find this difficult, since the likelihood of someone deploying DNSSEC if it has no compelling features is lower, and aggressive negative caching with or without a wildcard is a feature of both DNSSEC and SWILD. In any case I find that you are arguing in bad faith, starting from your desire and then finding ways to justify it, rather than starting from the facts and finding out where those lead to. I won't play along any further. For your possible use, see these words from the NY Times opinion pages, published a day or so ago: <> -- P Vixie From nobody Mon Aug 14 16:30:43 2017 Return-Path: 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 C08B3132452 for ; Mon, 14 Aug 2017 16:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 umEIbbSblRXp for ; Mon, 14 Aug 2017 16:30:40 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390FC132451 for ; Mon, 14 Aug 2017 16:30:40 -0700 (PDT) Received: from [10.1.7.203] (63-158-87-14.dia.static.qwest.net [63.158.87.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id C434861FF3 for ; Mon, 14 Aug 2017 23:30:38 +0000 (UTC) Message-ID: <5992329C.9050408@redbarn.org> Date: Mon, 14 Aug 2017 16:30:36 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: "dnsop@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] on engineering cost/benefits X-BeenThere: dnsop@ietf.org 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: Mon, 14 Aug 2017 23:30:42 -0000 I realize that for the Perl language, "there is always more than one way to do it". That was a design choice, and the results are now part of Perl's reputation as a "swiss-army chainsaw" perfectly suitable for the creation of unmaintainable programs. Generally, we do not provide more than one way to accomplish something, because it imposes costs on operators and implementers and especially on QA/test teams, who must support all such methods, for competitive or coverage reasons. Distributed system complexity is a function of message types and their options and permutations and combinations, and state variables and their options and permutations and combinations. More complexity is almost always going to add more cost than benefit, and every argument about adding new states, variables, or messages has to begin with the engineering economics: what are the costs & benefits? For example if it's possible to express the nonexistence of a wildcard in two ways, each publisher of DNS information will have to decide whether to support only one and if so which one, or both ways. Every implementer of a DNS client library or a DNS-aware application will also have to choose. If some choose method A and others choose method B than the functionality will not be effectively present. If everyone chooses to support both then there was no advantage to the second way. In terms of cost/benefit, someone who wanted to provide a new way to support signalling of non-wildcard should be comparing the effort of standardizing, implementing and deploying a second way, vs. pushing for broader deployment of the existing way. One could either come to the IETF, and to the authors of PowerDNS, BIND, NSD, Unbound, and companies like Nominum, Microsoft, and so on, asking "could you please support this second way to do something your systems already know how to do?", or one could approach one's own I.T. department and the I.T. departments of our customers, suppliers, and partners, and say, "could you please support this existing standard by changing your operational practice to include DNSSEC signing and validation?" In the first case, it's all new work, which adds complexity for all operators and all implementers, and may have the effect of reducing DNSSEC deployment if some number of operators cared only about this feature (which we'll call SWILD) and have no other reason to deploy DNSSEC. This concern is heightened because the DNSSEC specification is crap, and there's been unending concern as to whether its costs are greater than its benefits. DNSSEC rests on knife-edge, ready to fall. In the second case, it's mostly just turning stuff on that's already defined, already implemented, and is an option in virtually all current generation DNS software. We would not be adding new test cases for QA/test teams. And importantly, we would be adding new effort to the task of causing DNSSEC to be more ubiquitous. This kind of engineering economics tradeoff should be obvious. I apologize to anyone who is about to ask me why I appear to be trying to teach my grandmother how to chew cheese. Consider this a PSA for newcomers for whom shiny objects are an unalloyed good, and aren't seen in the context of costs and benefits and effects and side effects. -- P Vixie From nobody Mon Aug 14 21:45:34 2017 Return-Path: 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 8DFEC1324BB for ; Mon, 14 Aug 2017 21:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rwtxVWq45KtX for ; Mon, 14 Aug 2017 21:45:30 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3E1132397 for ; Mon, 14 Aug 2017 21:45:30 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id m85so1533346wma.0 for ; Mon, 14 Aug 2017 21:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dzBq9n3zT0kTS/v8ovhrEWVzNYSwNoOln7GRsnJqAiw=; b=iWGgH+xWbzsI75f3ESWcSD1wg/YOh6DWYMQXvR13XoFDi0bY82N8DDF2jk/Vnzr/no 7m0HhL2tQs7/Asic4ESDXTs3ac1QUx3B+QuN+ldRXUgxtY329oQyQFFyr6vRO8p1GSMs uTcSXsFQ/MeQcu7wRWbWQj7A9nQP7ehPESoBOaJd4xHP16jfuehMPV3P249mWg15Fh91 pkJCIuh5jQ1akdEFMi6+buYKkWZ1/uVLqbuVznlwT9tQIylyaaCt0oY1RGy3R61gs37N U59Si/kAvsysNvAmc7Wchv/LFpOBV7VNymB82SG5L39Rg5CxriRQ9nHSuvPHiliR8/y+ LJGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dzBq9n3zT0kTS/v8ovhrEWVzNYSwNoOln7GRsnJqAiw=; b=sMNAu1LMoq610bnUbyTSy/lBbe4UhfntOeKX01UX0k4b5NNpv78oO6kjR9B96cKWyZ PKlCcxArkSW+igPVj/T7xMlHf/cGUPVjq/0nN+2Go1nVXuDWQCLIxRbhXZ/0luLL+I59 254tl+y81oSIpRNYDLQ3NaFl3I+glutNXyBouYPP6rYp4tYrJPaF33THLAtFWQjoQBLm GLj2d4vqSZtqJPAsso4H2FA7nCOR7gF8X/F0JTBrkuvirxabERl4w9qq8bT67OGSb8bZ CYOklMw2NYmO2A+cZNhZRLfG1k312ETxWtIVqsd4cjQFYLLVANPBOecaNE1e6uSLJotp +4pw== X-Gm-Message-State: AHYfb5jQZSLd4aV2ibr4U4CvKltZBMTOlQlqyg/FHtA+pqhQX7j7P+lj H/5jGR+71dBNoWXGkhhkvJ2D/DVzcB7k X-Received: by 10.80.216.206 with SMTP id y14mr26019681edj.165.1502772328775; Mon, 14 Aug 2017 21:45:28 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> <599216D2.8060608@redbarn.org> In-Reply-To: <599216D2.8060608@redbarn.org> From: Lanlan Pan Date: Tue, 15 Aug 2017 04:45:17 +0000 Message-ID: To: Paul Vixie Cc: dnsop Content-Type: multipart/alternative; boundary="089e08222db4d5c4c20556c372ab" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 04:45:34 -0000 --089e08222db4d5c4c20556c372ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, Don't judy other's motivation with meaningless skeptics. The endless skeptics can also push on your RPZ to DNSSEC. As an network engineer, I think good faith is face to the realistic internet world, try my best to offer a better solution to technology problem. If we anticipated the subdomain wildcard scenario when designing wildcard years ago, *make Authoritative give more precise wildcard information to Recursive* (SWILD) is natually. SWILD is not starting from "desire", not to mention "reducing DNSSEC deployment". *1) I believe, reduce solution interdependence between different problem areas is comfortable.* Subdomain wildcard cache issue solution is not need to bind with security issue, in natural. *2) I believe, design an alternative solution to an existed problem is ordinary.* IPv4/IPv6 Migration can use Tunnel, NAT, ... Subdomain wildcard cache optimization can use NSEC aggressive wildcards, SWILD, ... You can oppose to SWILD, but wish you not oppose to the alternative solution designing. *3) I believe, network protocol / feature deployment progress is decided by the key function, not because of additional function.* IPv6 deployment will sharply rise mostly because of *IPv4 addresses exhaustion*, but almost impossible because of any improved IPv6 featue that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ..= . DNSSEC deployment will sharply rise if global nameservers desire *dns security*, but almost impossible because of an addtional wildcards feature. That is why I say "SWILD has no influnence on reducing DNSSEC deployment", going further, "NSEC aggressive wildcard has no influnence on rising DNSSEC deployment". Repeat the Google example, as far as I can see: - Google has expert on NSEC aggressive wildcard. - Google likes to support some optimized protocols/features, such as QUIC, SPDY, ... Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return NXDOMAIN. Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED in future, more probability than because of NSEC aggressive wildcards. Paul Vixie =E4=BA=8E2017=E5=B9=B48=E6=9C=8815=E6=97=A5=E5= =91=A8=E4=BA=8C =E4=B8=8A=E5=8D=885:32=E5=86=99=E9=81=93=EF=BC=9A > WG Chairs: i oppose adoption of this draft. > > Lanlan Pan wrote: > > Hi Paul, > > > > ... > > tl;dr: this message marks the end of this thread from my side. > > > I think, SWILD has no influence on DNSSEC deployment : 1) If > > recursive wants to deploy DNSSEC, it is almost impossible because of > > NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest > > motivation behind DNSSEC depolyment.* 2) If recursive doesn't want > > to deploy DNSSEC, it is almost impossible because of SWILD. Imagine > > that, there is no SWILD to give precise subdomain wildcard > > information from authoritative, recursive can use random subdomain > > detect method to make cache optimization, which was described in DNS > > Noise: Measuring the Pervasiveness of Disposable Domains in Modern > > DNS Traffic > > . > > Mr. Pan, your words above are a striking example of absurd reduction, > which through a series of difficult-to-assail false equivalencies, an > outcome unacceptable to your correspondent may begin to "look good on > paper". > > Proof of this can by found by trying to reason your way to the > conclusion you are offering, by any other path. You'll find this > difficult, since the likelihood of someone deploying DNSSEC if it has no > compelling features is lower, and aggressive negative caching with or > without a wildcard is a feature of both DNSSEC and SWILD. > > In any case I find that you are arguing in bad faith, starting from your > desire and then finding ways to justify it, rather than starting from > the facts and finding out where those lead to. I won't play along any > further. For your possible use, see these words from the NY Times > opinion pages, published a day or so ago: > > < that hardly any climate skeptics are in fact trying to get at the truth. > I=E2=80=99m not a climate scientist, but I do know what bogus arguments l= ook > like =E2=80=94 and I can=E2=80=99t think of a single prominent climate sk= eptic who isn=E2=80=99t > obviously arguing in bad faith. > > Take, for example, all the people who seized on the fact that 1998 was > an unusually warm year to claim that global warming stopped 20 years ago > =E2=80=94 as if one unseasonably hot day in May proves that summer is a m= yth. Or > all the people who cited out-of-context quotes from climate researchers > as evidence of a vast scientific conspiracy.>> > > -- > P Vixie > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --089e08222db4d5c4c20556c372ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Don't = judy other's motivation with meaningless skeptics. The endless skeptics= can also push on your RPZ to DNSSEC.

As= an network engineer, I think good faith is face to the realistic internet = world, try my best to offer a better solution to technology problem.

If we anticipated the subdomain wildcard scenario when de= signing wildcard years ago, make Authoritative give more precise wildcar= d information to Recursive (SWILD) is natually.
SWILD is not startin= g from "desire", not to mention "reducing DNSSEC deployment&= quot;.

1) I believe,= =C2=A0 reduce solution interdependence between different problem areas is c= omfortable.

Subdomain wildcard cache issue sol= ution is not need to bind with security issue,=C2=A0 in natural.
=
2) I believe,=C2=A0 design an alternative solution to an = existed problem is ordinary.

IPv4/IPv6 = Migration can use Tunnel, NAT, ...
Subdomain wildcard = cache optimization can use NSEC aggressive wildcards, SWILD, ...
<= /div>

You can oppose to SWILD,=C2=A0 but wish you not op= pose to the alternative solution designing.

<= b>3) I believe,=C2=A0 network protocol / feature deployment progress is dec= ided by the key function, not because of additional function.

IPv6 deployment=C2=A0 will sharply rise mostly becau= se of IPv4 addresses exhaustion,=C2=A0 but almost impossible because of any improved IPv6 featue that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ...
D= NSSEC deployment will sharply rise if global nameservers desire dns secu= rity, but almost impossible because of an addtional wildcards feature.<= /div>

That is why I say "SWILD has no influnence on= reducing DNSSEC deployment",=C2=A0 going further,=C2=A0 "NSEC ag= gressive wildcard has no influnence on rising DNSSEC deployment".
<= /div>

Repeat the Google example,=C2=A0 as far as I can see:- Google has expert on NSEC aggressive wildcard.
- Google likes t= o support some optimized protocols/features, such as QUIC, SPDY, ...

Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return NXDOMAIN.
Sum it up, I believe Google will deploy DNSSEC because of = DNS SECURITY NEED in future, more probability than because of NSEC aggressi= ve wildcards.

=

Paul Vixie <<= a href=3D"mailto:paul@redbarn.org">paul@redbarn.org>=E4=BA=8E2017=E5= =B9=B48=E6=9C=8815=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=885:32=E5=86= =99=E9=81=93=EF=BC=9A
WG Chairs: i = oppose adoption of this draft.

Lanlan Pan wrote:
> Hi Paul,
>
> ...

tl;dr: this message marks the end of this thread from my side.

> I think, SWILD has no influence on DNSSEC deployment : 1) If
> recursive wants to deploy DNSSEC, it is almost impossible because of > NSEC/NSEC3 aggressiveuse Wildcards. *Security need is the greatest
> motivation behind DNSSEC depolyment.* 2) If recursive doesn't want=
> to deploy DNSSEC, it is almost impossible because of SWILD. Imagine > that, there is no SWILD to give precise subdomain wildcard
> information from authoritative, recursive can use random subdomain
> detect method to make cache optimization, which was described in DNS > Noise: Measuring the Pervasiveness of Disposable Domains in Modern
> DNS Traffic
> <http://astrolavos.gatech.edu/arti= cles/dnsnoise-dsn2014.pdf>.

Mr. Pan, your words above are a striking example of absurd reduction,
which through a series of difficult-to-assail false equivalencies, an
outcome unacceptable to your correspondent may begin to "look good on<= br> paper".

Proof of this can by found by trying to reason your way to the
conclusion you are offering, by any other path. You'll find this
difficult, since the likelihood of someone deploying DNSSEC if it has no compelling features is lower, and aggressive negative caching with or
without a wildcard is a feature of both DNSSEC and SWILD.

In any case I find that you are arguing in bad faith, starting from your desire and then finding ways to justify it, rather than starting from
the facts and finding out where those lead to. I won't play along any further. For your possible use, see these words from the NY Times
opinion pages, published a day or so ago:

<<What becomes clear to anyone following the climate debate, however,= is
that hardly any climate skeptics are in fact trying to get at the truth. I=E2=80=99m not a climate scientist, but I do know what bogus arguments loo= k
like =E2=80=94 and I can=E2=80=99t think of a single prominent climate skep= tic who isn=E2=80=99t
obviously arguing in bad faith.

Take, for example, all the people who seized on the fact that 1998 was
an unusually warm year to claim that global warming stopped 20 years ago =E2=80=94 as if one unseasonably hot day in May proves that summer is a myt= h. Or
all the people who cited out-of-context quotes from climate researchers
as evidence of a vast scientific conspiracy.>>

--
P Vixie

--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

= =E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--089e08222db4d5c4c20556c372ab-- From nobody Mon Aug 14 22:14:33 2017 Return-Path: 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 AB0F11324C3 for ; Mon, 14 Aug 2017 22:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] 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 TTHdYADXxvzr for ; Mon, 14 Aug 2017 22:14:30 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8CA91324C1 for ; Mon, 14 Aug 2017 22:14:29 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id CCF8524AE2D; Tue, 15 Aug 2017 05:14:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9093C160045; Tue, 15 Aug 2017 05:14:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 7D2A8160067; Tue, 15 Aug 2017 05:14:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Q_uayAp3kCrT; Tue, 15 Aug 2017 05:14:24 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id EAA10160045; Tue, 15 Aug 2017 05:14:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 399518263A84; Tue, 15 Aug 2017 15:14:21 +1000 (AEST) To: Lanlan Pan Cc: Paul Vixie , dnsop From: Mark Andrews References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> <599216D2.8060608@redbarn.org> In-reply-to: Your message of "Tue, 15 Aug 2017 04:45:17 +0000." Date: Tue, 15 Aug 2017 15:14:21 +1000 Message-Id: <20170815051421.399518263A84@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 05:14:32 -0000 In message , Lanlan Pan writes: > > Hi Paul, > > Don't judy other's motivation with meaningless skeptics. The endless > skeptics can also push on your RPZ to DNSSEC. I can't see how you can say push your RPZ to DNSSEC as RPZ breaks DNSSEC. > As an network engineer, I think good faith is face to the realistic > internet world, try my best to offer a better solution to technology > problem. > > If we anticipated the subdomain wildcard scenario when designing wildcard > years ago, *make Authoritative give more precise wildcard information to > Recursive* (SWILD) is natually. > SWILD is not starting from "desire", not to mention "reducing DNSSEC > deployment". > > *1) I believe, reduce solution interdependence between different problem > areas is comfortable.* > > Subdomain wildcard cache issue solution is not need to bind with security > issue, in natural. Only if you believe spoofed responses can't be delivered. > *2) I believe, design an alternative solution to an existed problem is > ordinary.* > > IPv4/IPv6 Migration can use Tunnel, NAT, ... And that is a problem for router vendors and OS developers because they end up having to implement them all. Part of the reason there aren't lots of CPE Routers today that support IPv6 is that the vendors have to spend lots of $$$$$$ implemententing and testing all the different transition mechanisms. If they don't want to spend lot of $$$$$$ then there is no real guidance on what mechanisms to discard. > Subdomain wildcard cache optimization can use NSEC aggressive wildcards, > SWILD, ... > > You can oppose to SWILD, but wish you not oppose to the alternative > solution designing. > > *3) I believe, network protocol / feature deployment progress is decided > by the key function, not because of additional function.* > > IPv6 deployment will sharply rise mostly because of *IPv4 addresses > exhaustion*, but almost impossible because of any improved IPv6 featue > that IPv4 not have, such as MTU detect, auto addressing, built in IPsec, ... > DNSSEC deployment will sharply rise if global nameservers desire *dns > security*, but almost impossible because of an addtional wildcards feature. > > That is why I say "SWILD has no influnence on reducing DNSSEC deployment", > going further, "NSEC aggressive wildcard has no influnence on rising > DNSSEC deployment". > > Repeat the Google example, as far as I can see: > - Google has expert on NSEC aggressive wildcard. > - Google likes to support some optimized protocols/features, such as QUIC, > SPDY, ... > > Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return > NXDOMAIN. > Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY NEED > in future, more probability than because of NSEC aggressive wildcards. Google validates answers on its recursive servers so Google has already partially deployed DNSSEC. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Aug 14 23:21:15 2017 Return-Path: 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 7B2351323C4 for ; Mon, 14 Aug 2017 23:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_NOVOWEL=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 lRIaHLnYDpDr for ; Mon, 14 Aug 2017 23:21:11 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B52126B6E for ; Mon, 14 Aug 2017 23:21:11 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id t201so2436407wmt.1 for ; Mon, 14 Aug 2017 23:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yVW3KnVpYo+TBxprEcht2/bby92112dDgZNwxSifO7Y=; b=P7+VenOZ7eq7q71xtijANbPH7kYJsWZzy6cuD2AAFs4/9sJykcHdvfDAh9IDJ6liL2 QYUNFgG+4Qv6udpsZHi3KYyEs7/sILiByx+FCVwevpyu724g7ykuXl/RNuuBPhtGAFEN U5c+LfODWZLlFgU7UxM82uf51Rht6z7tac1RDtdbhR0A/FLyLwciaDTEPGXk1lvSEh2s pKIBs9KVGlRJ25rPYQhGNFY8kT5HP/s22MRCqidbqKEkYjTajdiB4IuUMCbckVU7m60y xAeLEcpZIJDFQpWooxKgMVhxDq3eUkhdR1oG4/A3w0db8/YS6YpcAmffnIGiKxpOFyuZ 79iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yVW3KnVpYo+TBxprEcht2/bby92112dDgZNwxSifO7Y=; b=kfLG9lVDdawkzTSTUpVMrehwth3KAxq5gstMj8VboMskHDR88Any+la0m+QzQq6B7p Cv6DoUHsiKU6QQi21p4FyvOSrGGYMhDYPTo//14RV9zxwAfKZHDOyPF3zDm9KdZC4rsy hqvSKRYMVAfPZLJcjwhKenop4bxiRj/DswfMYQKzO6AzNYmFMnfF3wkaNTfKo6H3UqMA CGzrUDTJZwqt6NTXQeTECP3ZjNdIJqDGuZcKO9k7zoLyLYo8qv79UQmaV/9zp9FMFZqx CLhLk61cFHn0rq2pkw0flDM/PR2TQT6Fm6Mmb0ZRiUR1yKy844Rm697pcUduJU8fUNrU iXgA== X-Gm-Message-State: AHYfb5i3df9POLCaYmon3zQEi0CQoH0FEB5nR7l2/hp/dWp804oE0/La YqZAX5zm5xgznPkVWYlc46irmymyN0P1nxA= X-Received: by 10.80.180.15 with SMTP id b15mr26340598edh.226.1502778069679; Mon, 14 Aug 2017 23:21:09 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> <599216D2.8060608@redbarn.org> <20170815051421.399518263A84@rock.dv.isc.org> In-Reply-To: <20170815051421.399518263A84@rock.dv.isc.org> From: Lanlan Pan Date: Tue, 15 Aug 2017 06:20:58 +0000 Message-ID: To: Mark Andrews Cc: Paul Vixie , dnsop Content-Type: multipart/alternative; boundary="94eb2c1b51c20505450556c4c9cf" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 06:21:14 -0000 --94eb2c1b51c20505450556c4c9cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mark Andrews =E4=BA=8E2017=E5=B9=B48=E6=9C=8815=E6=97=A5=E5= =91=A8=E4=BA=8C =E4=B8=8B=E5=8D=881:14=E5=86=99=E9=81=93=EF=BC=9A > > In message < > CANLjSvWyO0nbiSJGSqhRH33evbCUFLNzCjceAHJ-L89FA+En8g@mail.gmail.com> > , Lanlan Pan writes: > > > > Hi Paul, > > > > Don't judy other's motivation with meaningless skeptics. The endless > > skeptics can also push on your RPZ to DNSSEC. > > I can't see how you can say push your RPZ to DNSSEC as RPZ breaks > DNSSEC. > Just for compare example, I mean that I also can't see how Paul can say SWILD is to reduce DNSSEC deployment. Not depend on, is not equal to , reducing deployment. > > As an network engineer, I think good faith is face to the realistic > > internet world, try my best to offer a better solution to technology > > problem. > > > > If we anticipated the subdomain wildcard scenario when designing wildca= rd > > years ago, *make Authoritative give more precise wildcard information t= o > > Recursive* (SWILD) is natually. > > SWILD is not starting from "desire", not to mention "reducing DNSSEC > > deployment". > > > > *1) I believe, reduce solution interdependence between different probl= em > > areas is comfortable.* > > > > Subdomain wildcard cache issue solution is not need to bind with securi= ty > > issue, in natural. > > Only if you believe spoofed responses can't be delivered. > Everyone knows spoofed response can be delivered, that is why DNSSEC exists= . SWILD can work with DNSSEC validation, and save validation cost. DNSSEC-enabled Recursive only need validate SWILD RR one time, not need calculate/match NSEC3/NSEC5/... for yyy/zzz/.foo.com range. > > > *2) I believe, design an alternative solution to an existed problem is > > ordinary.* > > > > IPv4/IPv6 Migration can use Tunnel, NAT, ... > > And that is a problem for router vendors and OS developers because > they end up having to implement them all. Part of the reason there > aren't lots of CPE Routers today that support IPv6 is that the > vendors have to spend lots of $$$$$$ implemententing and testing > all the different transition mechanisms. If they don't want to > spend lot of $$$$$$ then there is no real guidance on what mechanisms > to discard. > > > Subdomain wildcard cache optimization can use NSEC aggressive wildcards= , > > SWILD, ... > > > > You can oppose to SWILD, but wish you not oppose to the alternative > > solution designing. > > > > *3) I believe, network protocol / feature deployment progress is decid= ed > > by the key function, not because of additional function.* > > > > IPv6 deployment will sharply rise mostly because of *IPv4 addresses > > exhaustion*, but almost impossible because of any improved IPv6 featue > > that IPv4 not have, such as MTU detect, auto addressing, built in IPsec= , > ... > > DNSSEC deployment will sharply rise if global nameservers desire *dns > > security*, but almost impossible because of an addtional wildcards > feature. > > > > That is why I say "SWILD has no influnence on reducing DNSSEC > deployment", > > going further, "NSEC aggressive wildcard has no influnence on rising > > DNSSEC deployment". > > > > Repeat the Google example, as far as I can see: > > - Google has expert on NSEC aggressive wildcard. > > - Google likes to support some optimized protocols/features, such as > QUIC, > > SPDY, ... > > > > Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only return > > NXDOMAIN. > > Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY > NEED > > in future, more probability than because of NSEC aggressive wildcards. > > Google validates answers on its recursive servers so Google has already > partially deployed DNSSEC. > My example is Google's Authoritative Server, ns1.google.com. > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 <+61%202%209871%204742> INTERNET: > marka@isc.org > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c1b51c20505450556c4c9cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Mark A= ndrews <marka@isc.org>=E4=BA=8E2= 017=E5=B9=B48=E6=9C=8815=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=881:14= =E5=86=99=E9=81=93=EF=BC=9A

In message <CANLjSvWyO0nbiSJGSqhRH33evbCU= FLNzCjceAHJ-L89FA+En8g@mail.gmail.com>
, Lanlan Pan writes:
>
> Hi Paul,
>
> Don't judy other's motivation with meaningless skeptics. The e= ndless
> skeptics can also push on your RPZ to DNSSEC.

I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
DNSSEC.

Just for compare example, I mea= n that I also can't see how Paul can say SWILD is to reduce DNSSEC depl= oyment.=C2=A0

Not depend on,=C2=A0 is not equ= al to , reducing deployment.


> As an network engineer, I think good faith is face to the realistic > internet world, try my best to offer a better solution to technology > problem.
>
> If we anticipated the subdomain wildcard scenario when designing wildc= ard
> years ago, *make Authoritative give more precise wildcard information = to
> Recursive* (SWILD) is natually.
> SWILD is not starting from "desire", not to mention "re= ducing DNSSEC
> deployment".
>
> *1) I believe,=C2=A0 reduce solution interdependence between different= problem
> areas is comfortable.*
>
> Subdomain wildcard cache issue solution is not need to bind with secur= ity
> issue, in natural.

Only if you believe spoofed responses can't be delivered.
Everyone knows spoofed response can be delivered, that is why DNSSE= C exists.
SWILD can work with DNSSEC validation, and save validat= ion cost. DNSSEC-enabled Recursive only need validate SWILD RR one time, no= t need calculate/match NSEC3/NSEC5/... for yyy/zzz/.foo.com range.

> *2) I believe,=C2=A0 design an alternative solution to an existed prob= lem is
> ordinary.*
>
> IPv4/IPv6 Migration can use Tunnel, NAT, ...

And that is a problem for router vendors and OS developers because
they end up having to implement them all.=C2=A0 Part of the reason there aren't lots of CPE Routers today that support IPv6 is that the
vendors have to spend lots of $$$$$$ implemententing and testing
all the different transition mechanisms.=C2=A0 If they don't want to spend lot of $$$$$$ then there is no real guidance on what mechanisms
to discard.

> Subdomain wildcard cache optimization can use NSEC aggressive wildcard= s,
> SWILD, ...
>
> You can oppose to SWILD,=C2=A0 but wish you not oppose to the alternat= ive
> solution designing.
>
> *3) I believe,=C2=A0 network protocol / feature deployment progress is= decided
> by the key function, not because of additional function.*
>
> IPv6 deployment=C2=A0 will sharply rise mostly because of *IPv4 addres= ses
> exhaustion*,=C2=A0 but almost impossible because of any improved IPv6 = featue
> that IPv4 not have, such as MTU detect, auto addressing, built in IPse= c, ...
> DNSSEC deployment will sharply rise if global nameservers desire *dns<= br> > security*, but almost impossible because of an addtional wildcards fea= ture.
>
> That is why I say "SWILD has no influnence on reducing DNSSEC dep= loyment",
> going further,=C2=A0 "NSEC aggressive wildcard has no influnence = on rising
> DNSSEC deployment".
>
> Repeat the Google example,=C2=A0 as far as I can see:
> - Google has expert on NSEC aggressive wildcard.
> - Google likes to support some optimized protocols/features, such as Q= UIC,
> SPDY, ...
>
> Nowadays: dig @ns1.google.com xxxxxxxx.google.com +dnssec, only r= eturn
> NXDOMAIN.
> Sum it up, I believe Google will deploy DNSSEC because of DNS SECURITY= NEED
> in future, more probability than because of NSEC aggressive wildcards.=

Google validates answers on its recursive servers so Google has already
partially deployed DNSSEC.
My example is Google's = Authoritative Server,=C2=A0 ns1.google.co= m.

Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0INTERNET: marka@isc.org
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--94eb2c1b51c20505450556c4c9cf-- From nobody Mon Aug 14 23:52:20 2017 Return-Path: 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 6D6B0124234 for ; Mon, 14 Aug 2017 23:52:18 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 2rSWfmevIu9k for ; Mon, 14 Aug 2017 23:52:16 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 C56AB1323C4 for ; Mon, 14 Aug 2017 23:52:15 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7F6ptZK005526 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Tue, 15 Aug 2017 06:51:56 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7F6ptN7005525 for dnsop@ietf.org; Tue, 15 Aug 2017 06:51:55 GMT Date: Tue, 15 Aug 2017 06:51:55 GMT From: Vernon Schryver Message-Id: <201708150651.v7F6ptN7005525@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 06:52:18 -0000 > From: Lanlan Pan > Don't judy other's motivation with meaningless skeptics. The endless > skeptics can also push on your RPZ to DNSSEC. A significant difference between RPZ and the SWILD is that RPZ does not depend on non-participants doing anything. For example, RPZ works fine on a single, isolated resolver. (Of course, the owners of the IETF printing presses would have to agree to publish anything, but publishing a description is neither implementing nor deploying.) The history of RPZ might suggest a temporary solution. Why not implement SWILD using a private rtype or perhaps even TXT? An implementation and a few 1000 installations might convince some skeptics and render many objections moot. > DNSSEC deployment will sharply rise if global nameservers desire *dns > security*, but almost impossible because of an addtional wildcards feature. I don't understand that. My zones have plenty of wildcards, but as far as I can tell, no new wildcard features will break my DNSSEC signatures. I don't understand "global nameservers [desiring] dns security". Are "global nameservers" resolvers or authorities? If they are resolvers, then there is absolutely no immediate prospect of many (any?) resolvers that might be called "global" dropping unsigned DNS data. If they are authorities, then I thought that the reasons why almost all com zones are unsigned are well understood, recently listed here, and have nothing to do with wildcards. What am I missing? http://scoreboard.verisignlabs.com/ http://scoreboard.verisignlabs.com/percent-trace.png ....................... ] From: Mark Andrews ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks ] DNSSEC. I describe the same facts as the opposite, as "either DNSSEC breaks RPZ or DNSSEC and RPZ work together perfectly well" (in either case, assuming a trusted path such as (trusted) localhost name or 127.0.0.1 address to a trusted resolver, where "trusted resolver" includes "trusted to rewrite." Of course, without a trusted path to a trusted resolver or a verifying stub, DNSSEC doesn't mean much.) As Mark Andrews understands but many people don't, the common RPZ implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast that RPZ invalidates and removes signatures and so verifying stubbs and verifying downstream resolvers will not accept rewritten answers." Also, in the two RPZ implementations I've written, the default BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ. Vernon Schryver vjs@rhyolite.com From nobody Tue Aug 15 00:08:02 2017 Return-Path: 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 D298E13250C for ; Tue, 15 Aug 2017 00:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 rvZOghNKJ8m2 for ; Tue, 15 Aug 2017 00:07:59 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 8715613250B for ; Tue, 15 Aug 2017 00:07:59 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 17CC734C21D; Tue, 15 Aug 2017 07:07:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 08146160067; Tue, 15 Aug 2017 07:07:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E99EE160070; Tue, 15 Aug 2017 07:07:56 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y1MQrxj43qL6; Tue, 15 Aug 2017 07:07:56 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A8E34160067; Tue, 15 Aug 2017 07:07:56 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id B1E1182668F1; Tue, 15 Aug 2017 17:07:54 +1000 (AEST) To: Vernon Schryver Cc: dnsop@ietf.org From: Mark Andrews References: <201708150651.v7F6ptN7005525@calcite.rhyolite.com> In-reply-to: Your message of "Tue, 15 Aug 2017 06:51:55 +0000." <201708150651.v7F6ptN7005525@calcite.rhyolite.com> Date: Tue, 15 Aug 2017 17:07:54 +1000 Message-Id: <20170815070754.B1E1182668F1@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 07:08:01 -0000 In message <201708150651.v7F6ptN7005525@calcite.rhyolite.com>, Vernon Schryver writes: > ] From: Mark Andrews > > ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks > ] DNSSEC. I should have been more precise RPZ breaks DNSSEC for down stream validators if it modifies responses from signed zones. RPZ implementations can be configured to do this. > I describe the same facts as the opposite, as "either DNSSEC breaks RPZ > or DNSSEC and RPZ work together perfectly well" (in either case, > assuming a trusted path such as (trusted) localhost name or 127.0.0.1 > address to a trusted resolver, where "trusted resolver" includes > "trusted to rewrite." Of course, without a trusted path to a trusted > resolver or a verifying stub, DNSSEC doesn't mean much.) > > As Mark Andrews understands but many people don't, the common RPZ > implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks > DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast > that RPZ invalidates and removes signatures and so verifying stubbs > and verifying downstream resolvers will not accept rewritten answers." > > Also, in the two RPZ implementations I've written, the default > BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ. > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > 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: marka@isc.org From nobody Tue Aug 15 00:26:01 2017 Return-Path: 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 D48C1132576 for ; Tue, 15 Aug 2017 00:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 OJwGldyBG5EH for ; Tue, 15 Aug 2017 00:25:58 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 E170F1200B9 for ; Tue, 15 Aug 2017 00:25:57 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 236B0AF; Tue, 15 Aug 2017 09:25:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502781955; bh=tTySGLJ00DfweznmDpm3dCj2QXZt1xJ8SzdGuicLqJA=; h=Date:From:To:Subject:From; b=ot98oT0gihv2g+bVleEloRg5PL+D0bsSp/mu8J5HHe7Vty5K3BKgKmeAyuqVIYw+8 EZl6Q4chDbFZ51GcPOxMo1x+EPscHkaqU2POZ8yZ5Fn6obUp7XK07IQW6oOxv5wr+q OKLpPl8gyiUYXBp+jFm2hRmIPFP32sBn/6sJlxnk= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 1F19784 for ; Tue, 15 Aug 2017 09:25:55 +0200 (CEST) Date: Tue, 15 Aug 2017 09:25:55 +0200 (CEST) From: Mikael Abrahamsson To: dnsop@ietf.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 07:26:00 -0000 Hi, we've had a discussion on V6OPS (https://www.ietf.org/mail-archive/web/v6ops/current/msg27337.html) where Mark Andrews has brought up the topic of caching DNS resolvers not being populated with A and AAAA information at the same time, or the TTL might expire at different points in time, thus causing the Happy Eyeballs algorithm to use IPv4 more than IPv6 because of the 50ms total timer of DNS lookup+TCP initation. I had a look into this, and there are some drafts regarding opportunistic refresh of information to try to avoid records expiring, and instead refreshing them before they expire. One I have found is https://tools.ietf.org/html/draft-muks-dnsop-dns-opportunistic-refresh-00 There was another opinion in the discussion (https://www.ietf.org/mail-archive/web/v6ops/current/msg27356.html) that caching resolvers should try to keep AAAA and A cached as long as one of them is being asked for. Currently I believe there is no such "coupling" between RR types? What is the opinion of this wg on that topic? I believe the best solution for the problem statement in Happy Eyeballs is a solution that needs to change behaviour both in the client (DNS lookups and TCP session initiation) but also in the resolver. If we can have a reasonable expectation that the caching resolver is always "hot" when it comes to frequently used A and AAAA records, that would mean we'd need less DNS lookup delay, waiting for both lookups to complete before deciding what to do regarding IPv6 and IPv4 TCP session initiation. Right now RFC6555bis proposes a 50ms head start for IPv6 (DNS lookup+TCP init), which IPv6 will lose if the DNS resolver AAAA is expired and the A is cached, and the authoritative DNS server is far away TTL-wise. However, introducing a really high head start for IPv6 in this setup is not desireable either, let's say 500ms head start to handle that the authoritative DNS server is 400ms RTT away. This would give a bad user experience in some other cases. Thoughts? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 01:16:48 2017 Return-Path: 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 ACE321323F7 for ; Tue, 15 Aug 2017 01:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oCQBz7IkLH90 for ; Tue, 15 Aug 2017 01:16:44 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29FF1200B9 for ; Tue, 15 Aug 2017 01:16:43 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id i66so4541927wmg.0 for ; Tue, 15 Aug 2017 01:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AJUYqyvn18KuIDCzd6x2V6wf1BGdm0Ib2jLXXK/9I7E=; b=iSTZ9Wi3l6Ky5PLUrbpbTplAkMxV4npxXIYYs76CO20/Z7H2K1bhsWY2H3odixCJn7 wlMEIP0e+1pRiUUnS1tVl+n8Z3O9nCm7TZEm5a4/lnfFLha02RgGhaLUPysA/3csQCNG zjEIhN5gst02+HSarbXmNVzuCjFDLJdgq4bl02Iqpq+MD3IwVGbeGYrwKSGZZ+ICAzAm rR1t0a4Qu6C8cw+20p/w6q0NNVUw4hKJ5TI6I7yqTHAM4MreEVbbfSHCyg1tIBtZsU29 Gv22g47+oal6iUOkiEpP4B7wyk9u+uHngir8pvT6ou0ghar4Dw4V3e70ScGW8TYZs1fb 8mng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AJUYqyvn18KuIDCzd6x2V6wf1BGdm0Ib2jLXXK/9I7E=; b=rHKJGXOqTVltp0Y9rL6/oBdzDqVgF+lApVgdO+BFRG2raZT/wnlB7zcomZ2E8WSDuc 1ZslN1wP1gphFnAguN0zDK6U04qkh+q8UA7VJPSue3yZA5tbhneDBVJsjWr9E4aRcMmG NuJ3FEnBAPrI1BYOtXl1C08v+ZBm7K8MIGzJ26hiIdrzn6S2ju8RlXVOwMqc8ct9PyqS teGh+zcNZiJeZDrS359DiCGuYmmSergnazhr2kqfdXjN1ElBHbQM4J2UJEiXFMwX+Y4/ 9ruI9KLE3l5ilIbRvU6rYHBkASf17b+a5CoPXf00GlKXrHIQgF4KYfTYqHTuCZdgZj2w Nkxw== X-Gm-Message-State: AHYfb5gHksz1q+0EX6HLjEpKC0iGtRNK4pyxaUXU1FeDftVeISsNQy4K 6CVG9E6hHdk1eMe1UZxgvi/Dt1m7bQ== X-Received: by 10.80.138.6 with SMTP id i6mr26540414edi.247.1502785002473; Tue, 15 Aug 2017 01:16:42 -0700 (PDT) MIME-Version: 1.0 References: <201708150651.v7F6ptN7005525@calcite.rhyolite.com> In-Reply-To: <201708150651.v7F6ptN7005525@calcite.rhyolite.com> From: Lanlan Pan Date: Tue, 15 Aug 2017 08:16:31 +0000 Message-ID: To: Vernon Schryver Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c1957843f0e510556c6665c" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 08:16:46 -0000 --94eb2c1957843f0e510556c6665c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Vernon, Thanks for your advice, :-) Vernon Schryver =E4=BA=8E2017=E5=B9=B48=E6=9C=8815=E6=97= =A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D=882:52=E5=86=99=E9=81=93=EF=BC=9A > > From: Lanlan Pan > > > Don't judy other's motivation with meaningless skeptics. The endless > > skeptics can also push on your RPZ to DNSSEC. > > A significant difference between RPZ and the SWILD is that RPZ does > not depend on non-participants doing anything. For example, RPZ works > fine on a single, isolated resolver. > (Of course, the owners of the IETF printing presses would have to > agree to publish anything, but publishing a description is neither > implementing nor deploying.) > > The history of RPZ might suggest a temporary solution. Why not implement > SWILD using a private rtype or perhaps even TXT? An implementation > and a few 1000 installations might convince some skeptics and render > many objections moot. > Yeah, TXT is my history plan: Recursive Resolvers that support wildcard detect method with TXT record > > > > DNSSEC deployment will sharply rise if global nameservers desire *dns > > security*, but almost impossible because of an addtional wildcards > feature. > > I don't understand that. My zones have plenty of wildcards, but as > far as I can tell, no new wildcard features will break my DNSSEC > signatures. > > I don't understand "global nameservers [desiring] dns security". > Are "global nameservers" resolvers or authorities? If they are resolvers, then there is absolutely no immediate prospect > of many (any?) resolvers that might be called "global" dropping > unsigned DNS data. > Both recursives and authoritatives. I mean more and more recursives and authoritatives enable DNSSEC for dns query by default configuration, sorry for my poor English. If they are authorities, then I thought that the reasons why almost > all com zones are unsigned are well understood, recently listed here, > and have nothing to do with wildcards. What am I missing? > http://scoreboard.verisignlabs.com/ > http://scoreboard.verisignlabs.com/percent-trace.png The deployment problem is on the Authoritative Nameservers of billions of second level domains, not on TLD. And Recursive must enable DNSSEC validation for dns query by default configuration. > > ....................... > > ] From: Mark Andrews > > ] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks > ] DNSSEC. > > I describe the same facts as the opposite, as "either DNSSEC breaks RPZ > or DNSSEC and RPZ work together perfectly well" (in either case, > assuming a trusted path such as (trusted) localhost name or 127.0.0.1 > address to a trusted resolver, where "trusted resolver" includes > "trusted to rewrite." Of course, without a trusted path to a trusted > resolver or a verifying stub, DNSSEC doesn't mean much.) > > As Mark Andrews understands but many people don't, the common RPZ > implementation parameter "BREAK-DNSSEC yes" does NOT mean "RPZ breaks > DNSSEC", but "RPZ should ignore DNSSEC request bits despite the fast > that RPZ invalidates and removes signatures and so verifying stubbs > and verifying downstream resolvers will not accept rewritten answers." > > Also, in the two RPZ implementations I've written, the default > BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RPZ. > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c1957843f0e510556c6665c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vernon,

Thanks for your advice, :-)<= br>

Vernon Sc= hryver <vjs@rhyolite.com>=E4= =BA=8E2017=E5=B9=B48=E6=9C=8815=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8B=E5=8D= =882:52=E5=86=99=E9=81=93=EF=BC=9A
= > From: Lanlan Pan <abbypan@gmail.com>

> Don't judy other's motivation with meaningless skeptics. The e= ndless
> skeptics can also push on your RPZ to DNSSEC.

A significant difference between RPZ and the SWILD is that RPZ does
not depend on non-participants doing anything.=C2=A0 For example, RPZ works=
fine on a single, isolated resolver.
(Of course, the owners of the IETF printing presses would have to
agree to publish anything, but publishing a description is neither
implementing nor deploying.)

The history of RPZ might suggest a temporary solution.=C2=A0 Why not implem= ent
SWILD using a private rtype or perhaps even TXT?=C2=A0 An implementation and a few 1000 installations might convince some skeptics and render
many objections moot.



> DNSSEC deployment will sharply rise if global nameservers desire *dns<= br> > security*, but almost impossible because of an addtional wildcards fea= ture.

I don't understand that.=C2=A0 My zones have plenty of wildcards, but a= s
far as I can tell, no new wildcard features will break my DNSSEC
signatures.

I don't understand "global nameservers [desiring] dns security&quo= t;.
Are "global nameservers" resolvers or authorities?
If they are resolvers, then there is absolutely no immediate prospect
of many (any?) resolvers that might be called "global" dropping unsigned DNS data.
=C2=A0
Both recursives an= d authoritatives.
I mean more and more recursives and authoritati= ves enable DNSSEC for dns query by default configuration, sorry for my poor= English.

If they are authorities, then I thought that the reasons why almost
all com zones are unsigned are well understood, recently listed here,
and have nothing to do with wildcards.=C2=A0 What am I missing?
http://scoreboard.verisignlabs.com/
http://scoreboard.verisignlabs.com/percent-trace= .png

The deployment problem is on the A= uthoritative Nameservers of billions of second level domains,=C2=A0 not on = TLD.
And Recursive must enable DNSSEC validation for d= ns query by default configuration.

=

=C2=A0 =C2=A0.......................

] From: Mark Andrews <marka@isc.org>

] I can't see how you can say push your RPZ to DNSSEC as RPZ breaks
] DNSSEC.

I describe the same facts as the opposite, as "either DNSSEC breaks RP= Z
or DNSSEC and RPZ work together perfectly well"=C2=A0 (in either case,=
assuming a trusted path such as (trusted) localhost name or 127.0.0.1
address to a trusted resolver, where "trusted resolver" includes<= br> "trusted to rewrite."=C2=A0 Of course, without a trusted path to = a trusted
resolver or a verifying stub, DNSSEC doesn't mean much.)

As Mark Andrews understands but many people don't, the common RPZ
implementation parameter "BREAK-DNSSEC yes" does NOT mean "R= PZ breaks
DNSSEC", but "RPZ should ignore DNSSEC request bits despite the f= ast
that RPZ invalidates and removes signatures and so verifying stubbs
and verifying downstream resolvers will not accept rewritten answers."=

Also, in the two RPZ implementations I've written, the default
BREAK-DNSSEC value is "no" so that requesting DNSSEC turns off RP= Z.


Vernon Schryver=C2=A0 =C2=A0 vjs@rhyolite.com

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--94eb2c1957843f0e510556c6665c-- From nobody Tue Aug 15 02:28:09 2017 Return-Path: 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 5C8561204DA for ; Tue, 15 Aug 2017 02:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hq_mqdG8KBCR for ; Tue, 15 Aug 2017 02:28:03 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110AE13203D for ; Tue, 15 Aug 2017 02:28:03 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id t201so5016487wmt.1 for ; Tue, 15 Aug 2017 02:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Nwvmpk7r3mMD7WT5mOJMhJ6F1YmIgQYaU5qL3lqrI8=; b=fgEeO7/jtPcLhZQn2XPea8Lt3uZS1otfVW+CLzOlOAA+i3DRJodlcnoqC+BK/BmWLI pYCxv0y9YG3CuDzp2RF/O3/SoCwy1YdDtDdYPPB+flk9ERQEwxT0uuQ5HVMXJrkaJof+ HNjjCUhj9Vcn8nzlHwPpTEZf8FKzGk+C5kZQ9MoSpT9Ll+lWuSbXullU405zWNGREEDe U6J/Z7digLpxd9zlgmMYULfdB9U8V7JyB8A+Tf0x2yHWxG/M7QEUEF87drxcjKP7WpKf COCiEGs8Y9U4qlsSQdQ8jbWixTwOzROmJFYgRq5VnK1MN7/Od7mPftEt6GogolUct3QJ TGJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Nwvmpk7r3mMD7WT5mOJMhJ6F1YmIgQYaU5qL3lqrI8=; b=Unf5EuGInVHwFzO+tpDmGxOxqd9CNsW7hpg5i/DAJMsdWXNV/Y9VUU+KM5Uuk4+Jx6 OBnWYg69Vy0mQqG+RV0Budi7EY7QnwJ5XxHJYtc0Kjglpwe0HiKUhVoq/s0Dcjktl2AB 8VayLbxAb030JE24PAIY4QKZV/Xc5JWhjim0qdWr7sdsUB1YrUj5ttjwvjrU0wYV6zF8 Tznwjx5buIYM5oqLZFpAJ/36hLN9MPkNAWKs7yBNfofDuS4yRRsVnfdqoV0F7t3BPuxh XNVsmk7ValAtW1K38A5i0IngeA30xcFVwQnDVuLUBbrDQ3ggSPVAItiitoc+p7YRUN46 nHHA== X-Gm-Message-State: AHYfb5gTdydNNMYjbwhHeqkc4J+vJAmbNoV0kLePxii8/8hHtkYgqn2b TVFwwe+M/bWhA1QFe86uQHrY1eTgVw6U X-Received: by 10.80.215.7 with SMTP id t7mr26354153edi.19.1502789281604; Tue, 15 Aug 2017 02:28:01 -0700 (PDT) MIME-Version: 1.0 References: <5992329C.9050408@redbarn.org> In-Reply-To: <5992329C.9050408@redbarn.org> From: Lanlan Pan Date: Tue, 15 Aug 2017 09:27:50 +0000 Message-ID: To: Paul Vixie Cc: dnsop Content-Type: multipart/alternative; boundary="f403045dbe944d69070556c765db" Archived-At: Subject: Re: [DNSOP] on engineering cost/benefits X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 09:28:07 -0000 --f403045dbe944d69070556c765db Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The complexity is the real world, No Silver Bullet. It is the fact, there is always more than one way to do it, not only for subdomain wildcard cache, or IPv4/IPv6 migration. Take virtual network tunneling for example, we have VN-Tag, VXLAN, NVGRE, ... Give the choice to operators, time is the best witness, like IP surpassed ATM. Actually, SWILD can work with DNSSEC, reduce validation cost by avoiding NSEC range calculation. Repeat my option: I believe that DNSSEC deployment is decided by rising the dns security need, not by an additional subdomain wildcard feature. If SWILD will reduce DNSSEC deployment as you say, what about RPZ break DNSSEC validation in the same measure principle ? RPZ seem not to cause DNSSEC to be more ubiquitous. Paul Vixie =E4=BA=8E2017=E5=B9=B48=E6=9C=8815=E6=97=A5=E5= =91=A8=E4=BA=8C =E4=B8=8A=E5=8D=887:30=E5=86=99=E9=81=93=EF=BC=9A > I realize that for the Perl language, "there is always more than one way > to do it". That was a design choice, and the results are now part of > Perl's reputation as a "swiss-army chainsaw" perfectly suitable for the > creation of unmaintainable programs. > > Generally, we do not provide more than one way to accomplish something, > because it imposes costs on operators and implementers and especially on > QA/test teams, who must support all such methods, for competitive or > coverage reasons. Distributed system complexity is a function of message > types and their options and permutations and combinations, and state > variables and their options and permutations and combinations. More > complexity is almost always going to add more cost than benefit, and > every argument about adding new states, variables, or messages has to > begin with the engineering economics: what are the costs & benefits? > > For example if it's possible to express the nonexistence of a wildcard > in two ways, each publisher of DNS information will have to decide > whether to support only one and if so which one, or both ways. Every > implementer of a DNS client library or a DNS-aware application will also > have to choose. If some choose method A and others choose method B than > the functionality will not be effectively present. If everyone chooses > to support both then there was no advantage to the second way. > > In terms of cost/benefit, someone who wanted to provide a new way to > support signalling of non-wildcard should be comparing the effort of > standardizing, implementing and deploying a second way, vs. pushing for > broader deployment of the existing way. One could either come to the > IETF, and to the authors of PowerDNS, BIND, NSD, Unbound, and companies > like Nominum, Microsoft, and so on, asking "could you please support > this second way to do something your systems already know how to do?", > or one could approach one's own I.T. department and the I.T. departments > of our customers, suppliers, and partners, and say, "could you please > support this existing standard by changing your operational practice to > include DNSSEC signing and validation?" > > In the first case, it's all new work, which adds complexity for all > operators and all implementers, and may have the effect of reducing > DNSSEC deployment if some number of operators cared only about this > feature (which we'll call SWILD) and have no other reason to deploy > DNSSEC. This concern is heightened because the DNSSEC specification is > crap, and there's been unending concern as to whether its costs are > greater than its benefits. DNSSEC rests on knife-edge, ready to fall. > > In the second case, it's mostly just turning stuff on that's already > defined, already implemented, and is an option in virtually all current > generation DNS software. We would not be adding new test cases for > QA/test teams. And importantly, we would be adding new effort to the > task of causing DNSSEC to be more ubiquitous. > > This kind of engineering economics tradeoff should be obvious. I > apologize to anyone who is about to ask me why I appear to be trying to > teach my grandmother how to chew cheese. Consider this a PSA for > newcomers for whom shiny objects are an unalloyed good, and aren't seen > in the context of costs and benefits and effects and side effects. > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045dbe944d69070556c765db Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The complexity is the real world, No Silver Bullet.

It is the fact, there is always mor= e than one way to do it, not only for subdomain wildcard cache, or IPv4/IPv= 6 migration.
Take virtual network tunneling for e= xample, we have VN-Tag, VXLAN, NVGRE, ...

Give the choice to operators, time = is the best witness, like IP surpassed ATM.

A= ctually, SWILD can work with DNSSEC, reduce validation cost by avoiding NSE= C range calculation.
Repeat my option:=C2=A0 I believe that DNSSEC deploymen= t is decided by rising the dns security need,=C2=A0 not by an additional subdomain wildcard feature.

If SWILD will reduce DNSSEC deployment as you say,=C2=A0 what a= bout RPZ break DNSSEC validation in the same measure principle ?=C2=A0 RPZ = seem not to cause DNSSEC to be more ubiquitous.
=

Paul Vixie <paul@redbarn.org>=E4=BA=8E2017=E5= =B9=B48=E6=9C=8815=E6=97=A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=887:30=E5=86= =99=E9=81=93=EF=BC=9A
I realize tha= t for the Perl language, "there is always more than one way
to do it". That was a design choice, and the results are now part of Perl's reputation as a "swiss-army chainsaw" perfectly suitab= le for the
creation of unmaintainable programs.

Generally, we do not provide more than one way to accomplish something,
because it imposes costs on operators and implementers and especially on QA/test teams, who must support all such methods, for competitive or
coverage reasons. Distributed system complexity is a function of message types and their options and permutations and combinations, and state
variables and their options and permutations and combinations. More
complexity is almost always going to add more cost than benefit, and
every argument about adding new states, variables, or messages has to
begin with the engineering economics: what are the costs & benefits?
For example if it's possible to express the nonexistence of a wildcard<= br> in two ways, each publisher of DNS information will have to decide
whether to support only one and if so which one, or both ways. Every
implementer of a DNS client library or a DNS-aware application will also have to choose. If some choose method A and others choose method B than
the functionality will not be effectively present. If everyone chooses
to support both then there was no advantage to the second way.

In terms of cost/benefit, someone who wanted to provide a new way to
support signalling of non-wildcard should be comparing the effort of
standardizing, implementing and deploying a second way, vs. pushing for
broader deployment of the existing way. One could either come to the
IETF, and to the authors of PowerDNS, BIND, NSD, Unbound, and companies
like Nominum, Microsoft, and so on, asking "could you please support this second way to do something your systems already know how to do?",=
or one could approach one's own I.T. department and the I.T. department= s
of our customers, suppliers, and partners, and say, "could you please<= br> support this existing standard by changing your operational practice to
include DNSSEC signing and validation?"

In the first case, it's all new work, which adds complexity for all
operators and all implementers, and may have the effect of reducing
DNSSEC deployment if some number of operators cared only about this
feature (which we'll call SWILD) and have no other reason to deploy
DNSSEC. This concern is heightened because the DNSSEC specification is
crap, and there's been unending concern as to whether its costs are
greater than its benefits. DNSSEC rests on knife-edge, ready to fall.

In the second case, it's mostly just turning stuff on that's alread= y
defined, already implemented, and is an option in virtually all current
generation DNS software. We would not be adding new test cases for
QA/test teams. And importantly, we would be adding new effort to the
task of causing DNSSEC to be more ubiquitous.

This kind of engineering economics tradeoff should be obvious. I
apologize to anyone who is about to ask me why I appear to be trying to
teach my grandmother how to chew cheese. Consider this a PSA for
newcomers for whom shiny objects are an unalloyed good, and aren't seen=
in the context of costs and benefits and effects and side effects.

--
P Vixie

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
-- =
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8= =93=9D=E5=85=B0=C2=A0 Pan Lanlan
--f403045dbe944d69070556c765db-- From nobody Tue Aug 15 04:27:32 2017 Return-Path: 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 A27DC132194 for ; Tue, 15 Aug 2017 04:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 maMv3nD_WcYl for ; Tue, 15 Aug 2017 04:27:29 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id DCED613218C for ; Tue, 15 Aug 2017 04:27:29 -0700 (PDT) Received: from [10.237.203.87] (c-69-136-137-7.hsd1.mi.comcast.net [69.136.137.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 72AE7540510; Tue, 15 Aug 2017 07:27:28 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jared Mauch X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Tue, 15 Aug 2017 07:27:27 -0400 Cc: dnsop@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> References: To: Mikael Abrahamsson Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 11:27:32 -0000 > On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: >=20 > What is the opinion of this wg on that topic? There has been much discussion about doing away with any/255 and I seem to r= ecall some discussion of a ANYA type which would return AAAA and A.=20 This is something I see value in being implemented.=20 - jared=20= From nobody Tue Aug 15 04:29:26 2017 Return-Path: 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 8487B132197 for ; Tue, 15 Aug 2017 04:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 7XW_L1hnt5dD for ; Tue, 15 Aug 2017 04:29:22 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FB413218C for ; Tue, 15 Aug 2017 04:29:22 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id t37so2694912qtg.5 for ; Tue, 15 Aug 2017 04:29:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rp+FxLqfazPVlz+Gyq0WEAu7g6eTUU+pDrFR43hYqeA=; b=HAn3EVz3dx13T7AR2EXTEEpE5/4U3vmtn8zlM5t3M5fZq3Uy6YCPvtCsvGIfT1wHMN Roywi6c6uU07d08nbW2ksVHZXPoU0i+gjLEbaGSGetR96ygx98t486ZeZNs52UaTt1+q t5e2oB+yOTWIH5wPHr7b7TeVcALj1SyvR3uj+Vb5sEbzyAdtG2yF1J5zlHk+08NeBoIJ BmCbwoWSKkGWuLFfNUdPqXEP8u86dE4YdWFk/Q9vZvQ3bGeW5qQ9iuNhXcCEfCrOgBri 1mIwxq/VLWmUg+c1GqTvnWPptGFbBwdJ+nS4OU1h2wcMPAo2rF2lDydJBd8UaS+gzzts 42Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rp+FxLqfazPVlz+Gyq0WEAu7g6eTUU+pDrFR43hYqeA=; b=ligm3SjoPYx9VTRv/zRWP0Gd5cA1YhNeWk/3xNA8aaSEmmth6byhhR0kCTjy1iRO4m vbu7MaXxticBxj1jcqO3UoXzFr1j3Mapo1K/EKQK9xA0/sDmQZDaxZNnCrkWvtLD97IO TZBuC9pm6zEA+agr3lZeQA5xoUni7j7OUH5iebN+lg1XdCY8OXKcIGECHEI3AfC0ghsR 7Z1Ijchg1lDkByluDx/XgQcbP7qmNnu28LNomZluvapLOhnnshtFEPMP8aQwSOOp1O3d 6xKL4EtuEZiB4AkJ1SRPxY/8/DDHCr/5G6xvC+ADRaxZpRBV+TVcPEy4PYEikI8wt7Kk +v2A== X-Gm-Message-State: AHYfb5gsyiC2J9uvKBCde7CrytFrq2otQxXGuyCSHBbxK3LkrPy63C17 p/SleDpIrPIr3Ete X-Received: by 10.237.53.172 with SMTP id c41mr38936305qte.33.1502796561704; Tue, 15 Aug 2017 04:29:21 -0700 (PDT) Received: from [10.0.30.153] (c-73-167-64-188.hsd1.ma.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id 8sm6191863qkm.76.2017.08.15.04.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Aug 2017 04:29:20 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_ABA98A4A-2B86-41B0-ABBB-67598BF4DBFF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 15 Aug 2017 07:29:18 -0400 In-Reply-To: Cc: dnsop@ietf.org To: Mikael Abrahamsson References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 11:29:24 -0000 --Apple-Mail=_ABA98A4A-2B86-41B0-ABBB-67598BF4DBFF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 15 ag 2017, a les 3:25, Mikael Abrahamsson va = escriure: > Right now RFC6555bis proposes a 50ms head start for IPv6 (DNS = lookup+TCP init), which IPv6 will lose if the DNS resolver AAAA is = expired and the A is cached, and the authoritative DNS server is far = away TTL-wise. If it's a commonly-used name, isn't this a one-time event, though? The = happy eyeballs client asks for A and AAAA, gets A because it was in the = cache, but AAAA also winds up in the cache, and then because it's a = commonly used name, neither record ever goes stale again. --Apple-Mail=_ABA98A4A-2B86-41B0-ABBB-67598BF4DBFF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 15 ag 2017, a les 3:25, Mikael Abrahamsson <swmike@swm.pp.se> va = escriure:
Right now = RFC6555bis proposes a 50ms head start for IPv6 (DNS lookup+TCP init), = which IPv6 will lose if the DNS resolver AAAA is expired and the A is = cached, and the authoritative DNS server is far away TTL-wise.

If = it's a commonly-used name, isn't this a one-time event, though?   = The happy eyeballs client asks for A and AAAA, gets A because it was in = the cache, but AAAA also winds up in the cache, and then because it's a = commonly used name, neither record ever goes stale again.

= --Apple-Mail=_ABA98A4A-2B86-41B0-ABBB-67598BF4DBFF-- From nobody Tue Aug 15 04:40:06 2017 Return-Path: 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 A10D413218F for ; Tue, 15 Aug 2017 04:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 D0hKBDi3GNE1 for ; Tue, 15 Aug 2017 04:40:03 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 ED86F13208E for ; Tue, 15 Aug 2017 04:40:02 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id BF02EAF; Tue, 15 Aug 2017 13:40:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502797200; bh=YpReYK7L56PzbZJ2PMoGbUKVoIDdXH7QyhnZwD1Mkic=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=u4PfTq+9WghFw4rFd9oHwGOucAIpev4Udd7dEL4ZmX2Mn7ajjFUiD3+LJ5kg022g+ K1D+7PwnnZN5tc9rqJsRz1zEl8ST6MfbC/aKzn+ahtUxXCtnkmWAF4krk5fqew2Ug8 nA09UCuXpiRwtA5x1OrQDa1jy/Maqh/RTbuG6kio= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id BC76784; Tue, 15 Aug 2017 13:40:00 +0200 (CEST) Date: Tue, 15 Aug 2017 13:40:00 +0200 (CEST) From: Mikael Abrahamsson To: Ted Lemon cc: dnsop@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 11:40:05 -0000 On Tue, 15 Aug 2017, Ted Lemon wrote: > If it's a commonly-used name, isn't this a one-time event, though? The > happy eyeballs client asks for A and AAAA, gets A because it was in the > cache, but AAAA also winds up in the cache, and then because it's a > commonly used name, neither record ever goes stale again. That was the assumtion by a lot of people who aren't DNS experts (including me). Mark Andrews brought up that this might be a more frequent issue that people think. Also there is the issue that as the TTL becomes 0 and the RR is now no longer in cache, next question will trigger a lookup and if the authoritative nameserver is 400ms RTT away, then during these 400ms a lot of clients might only use IPv4 with current RFC6555bis proposal. So there are two things here I see: 1. Opportunistically refresh RRs before they expire. I've been told some resolvers do this already. 2. Tie together A and AAAA so that if one is asked for, make sure there is an up-to-date of the second one as well, at least make sure it doesn't expire even if it's infrequently used. I guess this means take into account A questions when deciding whether to refresh that AAAA you might have? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 05:00:31 2017 Return-Path: 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 001331320DC for ; Tue, 15 Aug 2017 05:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fredan.se 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 b5gXt0Ca-7Kj for ; Tue, 15 Aug 2017 05:00:25 -0700 (PDT) Received: from postoffice46.doho.se (postoffice46.doho.se [IPv6:2a00:16d8:c::5b6a:c260]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAEA132143 for ; Tue, 15 Aug 2017 05:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=fredan.se; s=2014; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=RzDB9oo3e47q6u62TfDopVKrb8yCGbB0jDxkXcZoZzw=; b=gjVBxScum4G3n2WDftlCwmfH2zstZLOKrxfGhjg6bKk9WTDKOkMskbnkr2p9Qf3q4Bo3w4Lc3aVTx41+vfkeFnC2lAQo/mrKiooxw8vVz6RpE9ONwVKk8NmX6Vg3ZhTKPAJt83BtEWgzxc8gHo6MhX5SR37RTDKGXsFfd4wrEz2ls5Smxo7vcNqIv38hEQXVg/4Yr3MTL7N6X2s5zokmFAUn00TT/GDlvqyfopGL1Hujy+Fd9RciDBNfC/MXJuT9TAgJcEeeDw2gWqb2V4p4vi18H4e82QUX8qoFKRZIPCB2r7d3C//G1kKjxfJZF17xVBYavxtKUywSMgRQ56OwxQ==; Received: from [213.66.95.98] (port=56816 helo=[192.168.44.61]) by postoffice46.doho.se with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1dhaWF-00031e-9c for dnsop@ietf.org; Tue, 15 Aug 2017 14:00:23 +0200 To: dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> From: fredrik danerklint Message-ID: Date: Tue, 15 Aug 2017 14:00:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam_report: X-Spam_score: [] () Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 12:00:28 -0000 > >> What is the opinion of this wg on that topic? > There has been much discussion about doing away with any/255 and I seem to recall some discussion of a ANYA type which would return AAAA and A. > > This is something I see value in being implemented. > > Would it be easier in this case to implement this behavior instead of creating a new type? If a authority DNS server is getting a question type of A and it has both A and AAAA records, put both in the answer. The same for a question type of AAAA, if it has both A and AAAA records put those in the answer. If it got a question type of A and it doesn't have the A record but it has the AAAA record, what should the behavior be in this case? The same for other way around of course, question type AAAA but it does not have the AAAA record, only the A record. Should it add the known record or not at all? -- //fda From nobody Tue Aug 15 05:30:32 2017 Return-Path: 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 0734B1241FC for ; Tue, 15 Aug 2017 05:30:31 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details.\n \n Content previ[...] 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 xb4HoJbd_h99 for ; Tue, 15 Aug 2017 05:30:28 -0700 (PDT) Received: from relay.vweb.co.za (relay.vweb.co.za [IPv6:2001:43f8:790:61::200]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B9612008A for ; Tue, 15 Aug 2017 05:30:26 -0700 (PDT) Received: from [165.255.158.101] (port=49554 helo=mjelap.posix.co.za) by relay.vweb.co.za with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1dhazF-00071H-I8 for dnsop@ietf.org; Tue, 15 Aug 2017 14:30:22 +0200 Reply-To: mje@posix.co.za To: dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> From: Mark Elkins Organization: Posix Systems Message-ID: <22432372-9229-0092-6a28-f6bd75c3a3a3@posix.co.za> Date: Tue, 15 Aug 2017 14:29:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 12:30:31 -0000 The Query portion of the DNS protocol can probably ask more than one question at a time. (I think I've only ever seen "QUERY: 1" in all the digs I've ever done - but might be wrong). Of course - if one were to ask for both an A and AAAA at the same time - one gets the same problem - how does one sort out whether there is an AAAA if there is a valid answer to A, and visa versa. "dig machine.domain.com a machine.domain.com aaaa" - actually works but does this as two queries. I think the cleanest way would be a new pseudo record (ANYA) as the reply would have to be a single complete resource set of all the possible answers (A's and AAAA's), all with one covering signature if DNSSEC is involved. One would then programmatically know then what was available. On 15/08/2017 14:00, fredrik danerklint wrote: > >> >>> What is the opinion of this wg on that topic? >> There has been much discussion about doing away with any/255 and I >> seem to recall some discussion of a ANYA type which would return AAAA >> and A. >> >> This is something I see value in being implemented. >> >> > Would it be easier in this case to implement this behavior instead of > creating a new type? > > If a authority DNS server is getting a question type of A and it has > both A and AAAA records, put both in the answer. The same for a > question type of AAAA, if it has both A and AAAA records put those in > the answer. > > If it got a question type of A and it doesn't have the A record but it > has the AAAA record, what should the behavior be in this case? The > same for other way around of course, question type AAAA but it does > not have the AAAA record, only the A record. Should it add the known > record or not at all? > -- Mark James ELKINS - Posix Systems - (South) Africa mje@posix.co.za Tel: +27.128070590 Cell: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za From nobody Tue Aug 15 05:53:22 2017 Return-Path: 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 BB23D132422 for ; Tue, 15 Aug 2017 05:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 xFEkbwAj8N5W for ; Tue, 15 Aug 2017 05:53:17 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 76E8313241E for ; Tue, 15 Aug 2017 05:53:17 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1::3e0] (unknown [IPv6:2001:718:1a02:1::3e0]) by mail.nic.cz (Postfix) with ESMTPSA id D231B623B4 for ; Tue, 15 Aug 2017 14:53:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502801595; bh=+RQKzBrwJleV5U+eK+FUWGisZUuTewpfqCAp+DyK92c=; h=To:From:Date; b=CI79+Bw9FBMTRU1jPLYqsOVy63RuBKR79mrBYqLHq9KhqTTy62eEzSIaeyirTevLi h9Wnbiupsp80Yo2xX5kuLi7fYBuZ+SvmjNkwhwFjuy8LnM3NNJ/hWYA+En5RbREfJY VAssPbmriYyd4NpO+J8XMJjzlhTgj7f+84evF3bs= To: dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <22432372-9229-0092-6a28-f6bd75c3a3a3@posix.co.za> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Message-ID: <92c20e3f-fc47-44c0-ac3e-a2b6814f0649@nic.cz> Date: Tue, 15 Aug 2017 14:53:15 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <22432372-9229-0092-6a28-f6bd75c3a3a3@posix.co.za> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 12:53:20 -0000 Hello, I can't bear to watch this anymore. On 08/15/2017 02:29 PM, Mark Elkins wrote: > [...] > I think the cleanest way would be a new pseudo record (ANYA) as the > reply would have to be a single complete resource set of all the > possible answers (A's and AAAA's), all with one covering signature if > DNSSEC is involved. One would then programmatically know then what was > available. Such changes would *not* help, really. You can ask both A and AAAA in separate parallel queries easily. If something like ANYA was asked instead, you would run into the risk of the server not implementing it and introducing yet another round trip (in the better not-implemented cases). The main question on client side is how long to wait if one answer comes and the other doesn't, but that does seem better decided by the client (with separate queries) than by intermediate resolvers (with a single query). On resolver side, one could recommend some prefetching strategies, as mentioned, and I can imagine having some such recommendations in rfc6555bis (non-mandatory). --Vladimir From nobody Tue Aug 15 06:41:44 2017 Return-Path: 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 9827913261E for ; Tue, 15 Aug 2017 06:41:42 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 8KHMS9JPYNjk for ; Tue, 15 Aug 2017 06:41:41 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 117B91321BB for ; Tue, 15 Aug 2017 06:41:40 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7FDfNLo039482 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Tue, 15 Aug 2017 13:41:23 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7FDfNqR039481 for dnsop@ietf.org; Tue, 15 Aug 2017 13:41:23 GMT Date: Tue, 15 Aug 2017 13:41:23 GMT From: Vernon Schryver Message-Id: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 13:41:43 -0000 ] From: Lanlan Pan ] Give the choice to operators, time is the best witness, like IP surpassed ] ATM. That is backwards. IP did not surpass ATM, because IP came long before ATM. Instead, end-to-end ATM was the last gasp of the end-to-end circuit switching point of view. End-to-end ATM was supposed to replace IP, but instead the new virtual circuits of ATM came far too late and did not solve the problems that packet switching had already solved. ATM has not yet died and is still common for some uses. For example, ATM is used as x.25 was used under IP in the early days of IP; many DSL installations use AMT VCs. A better and more relevant history is that of the SPF RR. The SPF RR was supposed to replace the use of the TXT rtype for SPF. The SPF RR was widely available in deployed DNS authoritative servers (via BIND). I think it was in milter modules for sendmail and postfix. Nevertheless, it died because it came late, was only a modest improvement, and required operators to do something more than they were doing. Vernon Schryver vjs@rhyolite.com From nobody Tue Aug 15 09:33:38 2017 Return-Path: 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 7ECFA132356 for ; Tue, 15 Aug 2017 09:33:36 -0700 (PDT) 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 Uf9U-hnLGuyZ for ; Tue, 15 Aug 2017 09:33:35 -0700 (PDT) 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 51699126BF3 for ; Tue, 15 Aug 2017 09:33:35 -0700 (PDT) Received: from [10.32.60.72] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7FGWbaa097658 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 15 Aug 2017 09:32:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.72] From: "Paul Hoffman" To: dnsop@ietf.org Date: Tue, 15 Aug 2017 09:33:37 -0700 Message-ID: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 16:33:36 -0000 On 15 Aug 2017, at 4:29, Ted Lemon wrote: > If it's a commonly-used name, isn't this a one-time event, though? > The happy eyeballs client asks for A and AAAA, gets A because it was > in the cache, but AAAA also winds up in the cache, and then because > it's a commonly used name, neither record ever goes stale again. +1 to this question. Happy eyeballs might tend to v4 for the first lookup, but then hopefully not after that. This WG has already spent years trying to rearchitect the A/AAAA lookup. --Paul Hoffman From nobody Tue Aug 15 10:09:01 2017 Return-Path: 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 D24F2132394 for ; Tue, 15 Aug 2017 10:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8CMHO-HpMkE2 for ; Tue, 15 Aug 2017 10:08:59 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1AF31321CB for ; Tue, 15 Aug 2017 10:08:58 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 16so7677107qtz.4 for ; Tue, 15 Aug 2017 10:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XSbsHBe066vj1yB5rc+uw/6eAqzJZISx4PClf7edSk0=; b=JoyOma/xH5FR9xnViAbr1vOIkXPAvhdXJ3ShWcSc2lB10701Gxfu7bgZGGOUx0Xtrw 2B2nPHpiwcSTtHFUWtuB2yaUZrM2UcnGh+wMc7dOKKYFi98+6KjtwVaLeXR5nBGaT35c YWHtHu9CqKAqjps1tauSavejfqoo9UnNfmZ5czJag2M1y7jsdhP1fpY/8GiVCuSSzDOn J105Ntrg1s7gy7wDDsN9iCuP0TS1A9L0XXyoqdOGRLfmcIQRWFcSG7ntYWA1BuQAcTHx gpSFmC2QDlPITDIynkHhDS1jUP+KELYc5XALup9FZeu3vB/+5eKQ8o6pPD2KU6QQ2gcf N/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XSbsHBe066vj1yB5rc+uw/6eAqzJZISx4PClf7edSk0=; b=W6/8sSpToQqERMU/BNZ7B6K4NUHOjE8Ou/TxJD0/7RvPbozG80fGm1ExEMLx7HJkCL e91AR/yWcbmBlRAxelxULA+5dVKek4m0bMYrqhQY+CeaXzKaclQYXWasXqLFQoj86haO BVp6aOt9o+qAdd31b/o0MMfTxEf6lIeVlrQfhJkuDKBnNvtX1nOv77kQlBF3x+cSa31b KQZfiLRIXqbgiHutSMMDhl+5ZDfTPyyCQBXiCDgBfI2Eqh7oFI/VErRxxLRapSdyGMzF /vUWYIknJ6cnSyaPwoGXjqE0l+5YK9FFPC3ZSOFlA9KlD5CBeN5c3/6WMdIEo4GxfItD eL6g== X-Gm-Message-State: AHYfb5h3ap7fRotpOabOaf3/B96tbjbsVNAubWYw6jDTUOPoq3POzT6p 8tW+TZsWLhQg1JlQNtIHif4qY9J/jvV5JBs= X-Received: by 10.200.41.241 with SMTP id 46mr36636714qtt.339.1502816938029; Tue, 15 Aug 2017 10:08:58 -0700 (PDT) MIME-Version: 1.0 Sender: jinmei.tatuya@gmail.com Received: by 10.237.60.60 with HTTP; Tue, 15 Aug 2017 10:08:57 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?56We5piO6YGU5ZOJ?= Date: Tue, 15 Aug 2017 10:08:57 -0700 X-Google-Sender-Auth: itBfUvtSHjxkl7Enw1SQDNbu6-E Message-ID: To: Mikael Abrahamsson Cc: Ted Lemon , dnsop Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 17:09:01 -0000 At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), Mikael Abrahamsson wrote: > > If it's a commonly-used name, isn't this a one-time event, though? The > > happy eyeballs client asks for A and AAAA, gets A because it was in the > > cache, but AAAA also winds up in the cache, and then because it's a > > commonly used name, neither record ever goes stale again. > > That was the assumtion by a lot of people who aren't DNS experts > (including me). Mark Andrews brought up that this might be a more frequent > issue that people think. > > Also there is the issue that as the TTL becomes 0 and the RR is now no > longer in cache, next question will trigger a lookup and if the > authoritative nameserver is 400ms RTT away, then during these 400ms a lot > of clients might only use IPv4 with current RFC6555bis proposal. If it's a commonly-used name, I suspect the more straightforward "prefetching" should suffice in practice: https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ Several popular recursive servers already implement the feature. Some of them even enable it by default. My impression on the rfc6555bis thread is that Mark wanted to make it "safer" (in that both AAAA and A responses are provided before trying to establish a TCP connection) even in some near-worst cases, not just "working in most cases in practice". In that sense I suspect tricks at the resolver won't help much, whether it's existing prefetch, opportunistic refresh or bundled AAAA/A queries, since there are worst cases where those don't work. Whether we need this level of perfection for rfc6555bis is a different question, though. -- JINMEI, Tatuya From nobody Tue Aug 15 10:26:39 2017 Return-Path: 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 5EC50132380 for ; Tue, 15 Aug 2017 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 bYE5KaqSL50T for ; Tue, 15 Aug 2017 10:26:22 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286DD1323A1 for ; Tue, 15 Aug 2017 10:26:22 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:14c:5d3e:8d2a:c80c] (unknown [IPv6:2001:559:8000:c9:14c:5d3e:8d2a:c80c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 09E956209B; Tue, 15 Aug 2017 17:26:22 +0000 (UTC) Message-ID: <59932EBD.9030007@redbarn.org> Date: Tue, 15 Aug 2017 10:26:21 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Lanlan Pan CC: dnsop References: <5992329C.9050408@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] on engineering cost/benefits X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 17:26:23 -0000 Lanlan Pan wrote: > The complexity is the real world, No Silver Bullet. > >... the real world is organic: it is what it is, and our job is to discover it, and sometimes model it, and sometimes enhance it through automation. we are not talking about that. we are talking about artifice: what shall we build, with what choices, and what projected outcomes? your dismissal is noted. -- P Vixie From nobody Tue Aug 15 10:27:56 2017 Return-Path: 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 3903513219E for ; Tue, 15 Aug 2017 10:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 4uBO9UMYpAtA for ; Tue, 15 Aug 2017 10:27:53 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFACA132143 for ; Tue, 15 Aug 2017 10:27:52 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id i12so9458571pgr.3 for ; Tue, 15 Aug 2017 10:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=SrCpjYlZjzGO+F0Sva417azpHJnORPG/zl11r4zVPJ8=; b=BZeu+qe0xeyZtWE0jO5ODd01VhXO0btoJWCSPwKvbW1vREYwNZn9ONutkxO5j0WvT/ GruCvR3a2KzLVWxrkwUEgvU1RdifV7IkiqHzYtseT9SMatCIuCX5r7Vnyp2VfzdB7v9M 5OmH0O0T+QEOe0mXiKUMht/l6tWFya0238NNC4iyoJ5DlLagzSzX5BStM+Oun99u9Y0G Zodb6+XSZgEtYlRinTuVP6uG0d6R1kpzjwZlqRoMpUAZA9s4oo2wIjKL2sPzi0aNtNDn dBmaDXaIVDoE9I9RFzJMG9Qy4IDV5ZcaS2w6M52QCSsD5eJ4hBmiF6Z1nxtywLUscpHm 6a9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=SrCpjYlZjzGO+F0Sva417azpHJnORPG/zl11r4zVPJ8=; b=CDZwxixmJYATs1EOJJdQ4A24pM5zzkk6GkjkxDbG7wfxZktGMYc9cwHAA9ATKbwE+R OxK4MYtugtGR0iLm6YMta8GxxtPpK8Nz9gXAbqQaqrGnQX7UEOyGQrHeVZjj1XXhuhvo hJ7B+U9pNkO/HxY1Jusz4pXmaTUg1QVvlFA4XdEwn/lWm7FKN6S4dEW5/dFsg9v8msOG ToLECAbWlhVkp8ii6rTwfRPcYuLGiCgE9hxCpEOi+O3OkcNDs7VhCKOrkf06tcFkBNx/ VI6yuu+aqg/XErZxfR+F+tlYmQ0PtmKhu2FuGXLjT8Ba9qJFCwDlE7otN2XFbY/gjD4Z OkPw== X-Gm-Message-State: AHYfb5g6P4gZqp1x3el7rZ33ClghLRnrytluVTZDhoMenYhYdW1ojBSY U4CpIcNlPnKEmTrfahAA5/ol3/bTGcOZ X-Received: by 10.98.200.152 with SMTP id i24mr29567861pfk.33.1502818072144; Tue, 15 Aug 2017 10:27:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Tue, 15 Aug 2017 10:27:11 -0700 (PDT) In-Reply-To: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> From: Ted Lemon Date: Tue, 15 Aug 2017 13:27:11 -0400 Message-ID: Cc: dnsop WG Content-Type: multipart/alternative; boundary="94eb2c1113be5a458c0556ce19d0" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 17:27:55 -0000 --94eb2c1113be5a458c0556ce19d0 Content-Type: text/plain; charset="UTF-8" I tried to ignore this thread for a while, but became alarmed after reading some of the recent comments, so I went and read the document. As far as I can tell, this document gives no clear justification for why it is a good idea. We have not been told of the practical operational problems that motivate it. It appears to solve a problem we have already solved, in a way that creates new security vulnerabilities. We have not been told why the existing solution to the problem is not adequate. If the authors have a real problem that they feel has not already been solved, the first step in the process ought to be to present that information to the working group, rather than to present a solution to the working group with no clear statement about the problem it solves, and in particular no data about the seriousness of the problem. For what it's worth, which isn't much since the chairs haven't issued a call for adoption, I don't think the working group should work on this. On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver wrote: > ] From: Lanlan Pan > > ] Give the choice to operators, time is the best witness, like IP surpassed > ] ATM. > > That is backwards. IP did not surpass ATM, because IP came long before > ATM. Instead, end-to-end ATM was the last gasp of the end-to-end > circuit switching point of view. End-to-end ATM was supposed to replace > IP, but instead the new virtual circuits of ATM came far too late and > did not solve the problems that packet switching had already solved. > > ATM has not yet died and is still common for some uses. For example, > ATM is used as x.25 was used under IP in the early days of IP; many > DSL installations use AMT VCs. > > A better and more relevant history is that of the SPF RR. The SPF RR > was supposed to replace the use of the TXT rtype for SPF. The SPF RR > was widely available in deployed DNS authoritative servers (via BIND). > I think it was in milter modules for sendmail and postfix. Nevertheless, > it died because it came late, was only a modest improvement, and required > operators to do something more than they were doing. > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --94eb2c1113be5a458c0556ce19d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I tried to ignore this thread for a while, but became alar= med after reading some of the recent comments, so I went and read the docum= ent.

As far as I can tell, this document gives no clear = justification for why it is a good idea. =C2=A0 We have not been told of th= e practical operational problems that motivate it. =C2=A0 It appears to sol= ve a problem we have already solved, in a way that creates new security vul= nerabilities. =C2=A0 We have not been told why the existing solution to the= problem is not adequate.

If the authors have a re= al problem that they feel has not already been solved, the first step in th= e process ought to be to present that information to the working group, rat= her than to present a solution to the working group with no clear statement= about the problem it solves, and in particular no data about the seriousne= ss of the problem.

For what it's worth, which = isn't much since the chairs haven't issued a call for adoption, I d= on't think the working group should work on this.

On Tue, Aug 15, 2017 at 9:4= 1 AM, Vernon Schryver <vjs@rhyolite.com> wrote:
] From: Lanlan Pan <abbypan@gmail.com>

] Give the choice to operators, time is the best witness, like IP surpassed=
] ATM.

That is backwards.=C2=A0 IP did not surpass ATM, because IP came long befor= e
ATM.=C2=A0 Instead, end-to-end ATM was the last gasp of the end-to-end
circuit switching point of view.=C2=A0 End-to-end ATM was supposed to repla= ce
IP, but instead the new virtual circuits of ATM came far too late and
did not solve the problems that packet switching had already solved.

ATM has not yet died and is still common for some uses.=C2=A0 For example,<= br> ATM=C2=A0 is used as x.25 was used under IP in the early days of IP; many DSL installations use AMT VCs.

A better and more relevant history is that of the SPF RR.=C2=A0 The SPF RR<= br> was supposed to replace the use of the TXT rtype for SPF.=C2=A0 The SPF RR<= br> was widely available in deployed DNS authoritative servers (via BIND).
I think it was in milter modules for sendmail and postfix.=C2=A0 Neverthele= ss,
it died because it came late, was only a modest improvement, and required operators to do something more than they were doing.


Vernon Schryver=C2=A0 =C2=A0 vjs@rhyoli= te.com

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

--94eb2c1113be5a458c0556ce19d0-- From nobody Tue Aug 15 10:28:18 2017 Return-Path: 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 7C2A71323A1 for ; Tue, 15 Aug 2017 10:28:17 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 qKww4fDGJiMN for ; Tue, 15 Aug 2017 10:28:16 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DCDB1323A3 for ; Tue, 15 Aug 2017 10:28:16 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:14c:5d3e:8d2a:c80c] (unknown [IPv6:2001:559:8000:c9:14c:5d3e:8d2a:c80c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2601461FF3; Tue, 15 Aug 2017 17:28:16 +0000 (UTC) Message-ID: <59932F2F.9030504@redbarn.org> Date: Tue, 15 Aug 2017 10:28:15 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Jared Mauch CC: Mikael Abrahamsson , dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> In-Reply-To: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 17:28:17 -0000 Jared Mauch wrote: > >> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson >> wrote: >> >> What is the opinion of this wg on that topic? > > There has been much discussion about doing away with any/255 and I > seem to recall some discussion of a ANYA type which would return AAAA > and A. > > This is something I see value in being implemented. as i've said every few years when this proposal comes up, it's unnec'y. we can specify that AAAA be sent as additional data for QTYPE=A, and that A be sent as additional data when QTYPE=AAAA. given identical deployment curves along both the ANYA and additional-data timelines, we will get identical results. -- P Vixie From nobody Tue Aug 15 11:36:29 2017 Return-Path: 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 6894513239D for ; Tue, 15 Aug 2017 11:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 MM9ZUY5IYE5b for ; Tue, 15 Aug 2017 11:36:27 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A42132398 for ; Tue, 15 Aug 2017 11:36:27 -0700 (PDT) Received: from [172.16.101.226] (96-82-111-94-static.hfc.comcastbusiness.net [96.82.111.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1BE826209B; Tue, 15 Aug 2017 18:36:25 +0000 (UTC) Message-ID: <59933D59.3090407@redbarn.org> Date: Tue, 15 Aug 2017 11:28:41 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Paul Hoffman CC: dnsop@ietf.org References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> In-Reply-To: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 18:36:28 -0000 Paul Hoffman wrote: > ... > > This WG has already spent years trying to rearchitect the A/AAAA lookup. that goal has been sought since longer than this wg has existed. however, adding the other kind of address record to the additional data section is something anyone can do, it breaks nothing, it will only be used opportunistically. adding it to the answer section would be more problematic. but no rfc is needed to give permission, and since these records could be signed and can in any case be cached, the impact would be immediate. -- P Vixie From nobody Tue Aug 15 12:05:42 2017 Return-Path: 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 AC75D13234C for ; Tue, 15 Aug 2017 12:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com 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 TsboX3tAlGGl for ; Tue, 15 Aug 2017 12:05:38 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5791323B3 for ; Tue, 15 Aug 2017 12:05:38 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9775422992; Tue, 15 Aug 2017 15:05:37 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 15 Aug 2017 15:05:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=8ed06e6Oc/70b3WNGbMLBCZy852pvfDwgfasMtGthi4=; b=h6AS4rMR K99LvF5nkEAck3H6GB6CC5BMzjO8AOusRIKC5Tmgab1f94FK9NRmipvaPczLZLuD hd3DSlUhH1tHRCkuR7wi9SgKz+QGHMXvxyXqw2MPH3vtVeq9nDsublAJ/rG62w4m gBbsfh1MSug8RCmHqEyo6ZUHjlXb/OF/6r7GMiPZZCsIp+BbZt7jUwmQN5YL0l+D H/utH9/rwOX7P7OCW+qJb8E41DZUvyZiAdw1UKjLJ0R4wgflJ+jwg6KZ9xvXQHxL /0+M+Y4hMrnsdD1pwTF5u31UbT/0h0Xb5gL7vVdVGiaS3ynfuKXPKnxxEwAnwqVJ YmH2MM3fg7FLhQ== X-ME-Sender: X-Sasl-enc: 0pfiTypiCutptwVOF8IxLzkUECSI+mJwHjgEtxOSqjgS 1502823937 Received: from [192.168.0.19] (82-181-40-178.bb.dnainternet.fi [82.181.40.178]) by mail.messagingengine.com (Postfix) with ESMTPA id 405267E749; Tue, 15 Aug 2017 15:05:37 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Tony Finch X-Mailer: iPhone Mail (14G60) In-Reply-To: <59932F2F.9030504@redbarn.org> Date: Tue, 15 Aug 2017 22:05:35 +0300 Cc: Jared Mauch , dnsop@ietf.org, Mikael Abrahamsson Content-Transfer-Encoding: quoted-printable Message-Id: <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> To: Paul Vixie Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 19:05:41 -0000 > On 15 Aug 2017, at 20:28, Paul Vixie wrote: >=20 > we can specify that AAAA be sent as additional data for QTYPE=3DA, and tha= t A be sent as additional data when QTYPE=3DAAAA. It's awkward. =46rom the stub point of view, how does it know that the server will return a= dditional address records? How does it tell the difference between no suppor= t, no records, or an empty cache? To what extent do the additional records a= ctually help clients to avoid double queries? =46rom the recursive server point of view, should it delay answers so it can= fill in the additional section? What if a broken authority doesn't answer t= o AAAA queries? DNSSEC can help a bit because there would be a visible proof of nonexistence= to disambiguate some cases. > given identical deployment curves along both the ANYA and additional-data t= imelines, we will get identical results. ANYA has the advantage of clear signalling that the server supports it or no= t, though broken servers or middleboxes might make the negative answer rathe= r slow. But we would need some kind of modelling or experimental evidence to= see if it increases the query load by 50% (the worst case) rather than redu= cing by 50% (the goal). Tony. --=20 f.anthony.n.finch http://dotat.at= From nobody Tue Aug 15 12:41:23 2017 Return-Path: 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 EB314126BF3 for ; Tue, 15 Aug 2017 12:41:21 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 tXaAA2YeKgtM for ; Tue, 15 Aug 2017 12:41:20 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD121200F3 for ; Tue, 15 Aug 2017 12:41:20 -0700 (PDT) Received: from [172.16.101.226] (96-82-111-94-static.hfc.comcastbusiness.net [96.82.111.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 0378B61FF3; Tue, 15 Aug 2017 19:41:20 +0000 (UTC) Message-ID: <59934E5E.30409@redbarn.org> Date: Tue, 15 Aug 2017 12:41:18 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Tony Finch CC: dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> In-Reply-To: <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 19:41:22 -0000 Tony Finch wrote: >> On 15 Aug 2017, at 20:28, Paul Vixie wrote: >> >> we can specify that AAAA be sent as additional data for QTYPE=A, >> and that A be sent as additional data when QTYPE=AAAA. > > It's awkward. it seems so, but is not. > From the stub point of view, how does it know that the server will > return additional address records? How does it tell the difference > between no support, no records, or an empty cache? To what extent do > the additional records actually help clients to avoid double > queries? the stub resolver as of today will most likely not look in the additional data section. i think the happy eyeballs community has enough cohesion around their client-side features that apple, microsoft, google, the bigger linux distros like ubunto and debian and redhat and suse, and bsd, would all modify their gethostby*() logic if this idea took off. and the getdnsapi people of course, likewise. however, they would have to make a change to support ANYA, so that's not new work in the "a/aaaa as additional" timeline vs. the ANYA timeline. what matters, then is the authority-to-cache side. > From the recursive server point of view, should it delay answers so > it can fill in the additional section? no. it should answer with what it's got without fetching anything new, like all additional data other than the rare case of in-zone a/aaaa referenced by NS. > What if a broken authority > doesn't answer to AAAA queries? n/a. > DNSSEC can help a bit because there would be a visible proof of > nonexistence to disambiguate some cases. n/a. >> given identical deployment curves along both the ANYA and >> additional-data timelines, we will get identical results. > > ANYA has the advantage of clear signalling that the server supports > it or not, though broken servers or middleboxes might make the > negative answer rather slow. But we would need some kind of modelling > or experimental evidence to see if it increases the query load by 50% > (the worst case) rather than reducing by 50% (the goal). in the just-send-additional model, the recursive will more often have both A and AAAA rrsets in cache (because it will indeed cache the additional data section, using cache precedence and credibility rules, under which same-owner should be at the ANSWER credibility level even though that's not the section it was found in). this means the stub that makes two queries will get the second answer much faster. and that future stubs that make one query and get both answers and use both answers will not have to make a second query. -- P Vixie From nobody Tue Aug 15 12:45:26 2017 Return-Path: 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 545C7126BF3 for ; Tue, 15 Aug 2017 12:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 O8F7lgzY_Gkt for ; Tue, 15 Aug 2017 12:45:24 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by ietfa.amsl.com (Postfix) with ESMTP id EB1821200F3 for ; Tue, 15 Aug 2017 12:45:23 -0700 (PDT) Received: from [IPv6:2603:3015:3603:8e00:ecc2:5b5b:fd83:f90d] (unknown [IPv6:2603:3015:3603:8e00:ecc2:5b5b:fd83:f90d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id DC0B25404E6; Tue, 15 Aug 2017 15:45:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jared Mauch In-Reply-To: <59932F2F.9030504@redbarn.org> Date: Tue, 15 Aug 2017 15:45:20 -0400 Cc: Mikael Abrahamsson , dnsop@ietf.org Content-Transfer-Encoding: 7bit Message-Id: References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> To: paul vixie X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 19:45:25 -0000 > On Aug 15, 2017, at 1:28 PM, Paul Vixie wrote: > > > > Jared Mauch wrote: >> >>> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson >>> wrote: >>> >>> What is the opinion of this wg on that topic? >> >> There has been much discussion about doing away with any/255 and I >> seem to recall some discussion of a ANYA type which would return AAAA >> and A. >> >> This is something I see value in being implemented. > > as i've said every few years when this proposal comes up, it's unnec'y. > > we can specify that AAAA be sent as additional data for QTYPE=A, and > that A be sent as additional data when QTYPE=AAAA. > > given identical deployment curves along both the ANYA and > additional-data timelines, we will get identical results. As this is DNSOP, what implementations support this? - Jared From nobody Tue Aug 15 12:46:13 2017 Return-Path: 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 1620613233D for ; Tue, 15 Aug 2017 12:46:11 -0700 (PDT) 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 kCowyTLyF14S for ; Tue, 15 Aug 2017 12:46:09 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 439841200F3 for ; Tue, 15 Aug 2017 12:46:09 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B4CFE7A330A; Tue, 15 Aug 2017 19:46:07 +0000 (UTC) Date: Tue, 15 Aug 2017 19:46:07 +0000 From: Viktor Dukhovni To: dnsop@ietf.org Message-ID: <20170815194607.GY8146@mournblade.imrryr.org> Reply-To: dnsop@ietf.org References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59933D59.3090407@redbarn.org> <59932F2F.9030504@redbarn.org> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 19:46:11 -0000 On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: > > There has been much discussion about doing away with any/255 and I > > seem to recall some discussion of a ANYA type which would return AAAA > > and A. > > > > This is something I see value in being implemented. > > as i've said every few years when this proposal comes up, it's unnec'y. > > We can specify that AAAA be sent as additional data for QTYPE=A, and > that A be sent as additional data when QTYPE=AAAA. > > given identical deployment curves along both the ANYA and > additional-data timelines, we will get identical results. +1, by far simpler/cleaner than adding a new RR type. On Tue, Aug 15, 2017 at 11:28:41AM -0700, Paul Vixie wrote: > > This WG has already spent years trying to rearchitect the A/AAAA lookup. > > that goal has been sought since longer than this wg has existed. > > however, adding the other kind of address record to the additional data > section is something anyone can do, it breaks nothing, it will only be used > opportunistically. > > adding it to the answer section would be more problematic. > > but no rfc is needed to give permission, and since these records could be > signed and can in any case be cached, the impact would be immediate. With no need to change stub or caching resolvers. Just the authoritative servers can be upgraded incrementally. Though multi-stage caches might benefit from similar logic in the upstream cache. This has a clear advantage over introducing new query types. -- Viktor. From nobody Tue Aug 15 12:51:01 2017 Return-Path: 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 28EB81321F0 for ; Tue, 15 Aug 2017 12:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 JxS1zd8LB-RQ for ; Tue, 15 Aug 2017 12:50:58 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D380D1321EB for ; Tue, 15 Aug 2017 12:50:58 -0700 (PDT) Received: from [172.16.101.226] (96-82-111-94-static.hfc.comcastbusiness.net [96.82.111.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 99B6C61FF3; Tue, 15 Aug 2017 19:50:58 +0000 (UTC) Message-ID: <599350A1.2050209@redbarn.org> Date: Tue, 15 Aug 2017 12:50:57 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Jared Mauch CC: dnsop@ietf.org, Mikael Abrahamsson References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 19:51:00 -0000 Jared Mauch wrote: >> we can specify that AAAA be sent as additional data for QTYPE=A, and >> that A be sent as additional data when QTYPE=AAAA. >> >> given identical deployment curves along both the ANYA and >> additional-data timelines, we will get identical results. > > As this is DNSOP, what implementations support this? of authorities, none. of recursives as initiators, most. of recursives as responders, none. of stubs, some. there are two measurable lobes here. one is now, where any authority who adopts this behaviour is likely to pre-seed the recursive initiator's cache with "the other answer" (among A and AAAA), and any stub who makes two queries in series (AAAA then A) will get a faster answer to the second query. the other is the future, where stubs are taught to notice the additional data section and begin to avoid the second query, and where recursive responders both ensure that they do cache additional data whose owner is the same as the effective qname, and begin to send additional data to stubs. so, the benefit begins immediately, but gets better over time, and there is no new signalling required, and nothing ever breaks, and it is never necessary to try-then-fallback (causing additional round trips.) have no fear. every few years this topic comes up, and i say what i'm saying, and we don't do it, and then people ask for QDCOUNT>1 again. so we are right on track at this stage of the thread. had the response to "resimprove" been better, i would have written this up before now. -- P Vixie From nobody Tue Aug 15 14:25:39 2017 Return-Path: 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 DC2E3132428 for ; Tue, 15 Aug 2017 14:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 dFyuCY-9BBlJ for ; Tue, 15 Aug 2017 14:25:36 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C847F132420 for ; Tue, 15 Aug 2017 14:25:36 -0700 (PDT) Received: from [IPv6:2602:306:8074:1ac0:a19b:1b42:4133:7b0e] (unknown [IPv6:2602:306:8074:1ac0:a19b:1b42:4133:7b0e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 29D7961FF3 for ; Tue, 15 Aug 2017 21:25:35 +0000 (UTC) Message-ID: <599366CE.6040003@redbarn.org> Date: Tue, 15 Aug 2017 14:25:34 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: dnsop@ietf.org References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <20170815194607.GY8146@mournblade.imrryr.org> In-Reply-To: <20170815194607.GY8146@mournblade.imrryr.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 21:25:38 -0000 Viktor Dukhovni wrote: > On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: > ... >> >> We can specify that AAAA be sent as additional data for QTYPE=A, and >> that A be sent as additional data when QTYPE=AAAA. >> >> given identical deployment curves along both the ANYA and >> additional-data timelines, we will get identical results. > > +1, by far simpler/cleaner than adding a new RR type. viktor, if you write this up and submit it as an i-d, i agree to review it. -- P Vixie From nobody Tue Aug 15 15:58:03 2017 Return-Path: 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 84D1513243A for ; Tue, 15 Aug 2017 15:58:02 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 mieCZc9m4_ZP for ; Tue, 15 Aug 2017 15:58:01 -0700 (PDT) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (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 152D9132428 for ; Tue, 15 Aug 2017 15:58:01 -0700 (PDT) Received: from webmail.nominum.com (unknown [IPv6:2620:0:b60:fab4:38af:c9d6:18df:f5fe]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 7350F7400E3; Tue, 15 Aug 2017 22:57:30 +0000 (UTC) Received: from SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) by SJC1-EXCH02.WIN.NOMINUM.COM (64.89.235.69) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA) id 15.1.1034.26; Tue, 15 Aug 2017 15:57:27 -0700 Received: from SJC1-EXCH02.WIN.NOMINUM.COM ([fe80::38af:c9d6:18df:f5fe]) by SJC1-EXCH02.WIN.NOMINUM.COM ([fe80::38af:c9d6:18df:f5fe%11]) with mapi id 15.01.1034.026; Tue, 15 Aug 2017 15:57:27 -0700 From: Bob Halley To: Paul Vixie CC: "dnsop@ietf.org" Thread-Topic: [DNSOP] opportunistic refresh and Happy Eyeballs Thread-Index: AQHTFZfD5iFmUq5F50OBp+oh3htLcqKFvRuAgABkzoD//7E5NoAAkRYAgAAZroA= Date: Tue, 15 Aug 2017 22:57:27 +0000 Message-ID: <43BE41D4-40FA-49DA-8F8E-13651F9DFB5E@nominum.com> References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <20170815194607.GY8146@mournblade.imrryr.org> <599366CE.6040003@redbarn.org> In-Reply-To: <599366CE.6040003@redbarn.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.89.232.154] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 22:58:02 -0000 > On Aug 15, 2017, at 14:25, Paul Vixie wrote: >=20 > Viktor Dukhovni wrote: >> On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: >> ... >>>=20 >>> We can specify that AAAA be sent as additional data for QTYPE=3DA, and >>> that A be sent as additional data when QTYPE=3DAAAA. >>>=20 >>> given identical deployment curves along both the ANYA and >>> additional-data timelines, we will get identical results. >>=20 >> +1, by far simpler/cleaner than adding a new RR type. >=20 > viktor, if you write this up and submit it as an i-d, i agree to review i= t. I am also willing to review such a draft. /Bob From nobody Tue Aug 15 16:43:04 2017 Return-Path: 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 15801132667 for ; Tue, 15 Aug 2017 16:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 mCii7bKxe5Ck for ; Tue, 15 Aug 2017 16:43:00 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 6268A132668 for ; Tue, 15 Aug 2017 16:43:00 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B1692349C70; Tue, 15 Aug 2017 23:42:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9D05C160067; Tue, 15 Aug 2017 23:42:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 87D8F160070; Tue, 15 Aug 2017 23:42:57 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id KD0jVPqXBu4R; Tue, 15 Aug 2017 23:42:57 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 3C7E4160067; Tue, 15 Aug 2017 23:42:57 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 233248277939; Wed, 16 Aug 2017 09:42:54 +1000 (AEST) To: Bob Halley Cc: Paul Vixie , "dnsop@ietf.org" From: Mark Andrews References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <20170815194607.GY8146@mournblade.imrryr.org> <599366CE.6040003@redbarn.org> <43BE41D4-40FA-49DA-8F8E-13651F9DFB5E@nominum.com> In-reply-to: Your message of "Tue, 15 Aug 2017 22:57:27 +0000." <43BE41D4-40FA-49DA-8F8E-13651F9DFB5E@nominum.com> Date: Wed, 16 Aug 2017 09:42:54 +1000 Message-Id: <20170815234254.233248277939@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 23:43:02 -0000 Or we could just say that mapped IPv4 addresses MUST be published in AAAA records and that A records are no longer required to be published after January 1, 2028 (now + ~10 years). Additionally that master nameservers and signers MUST synthesis mapped AAAA record if there are A records at the name but no associated AAAA record. In message <43BE41D4-40FA-49DA-8F8E-13651F9DFB5E@nominum.com>, Bob Halley write s: > > > On Aug 15, 2017, at 14:25, Paul Vixie wrote: > > > > Viktor Dukhovni wrote: > >> On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: > >> ... > >>> > >>> We can specify that AAAA be sent as additional data for QTYPE=A, and > >>> that A be sent as additional data when QTYPE=AAAA. > >>> > >>> given identical deployment curves along both the ANYA and > >>> additional-data timelines, we will get identical results. > >> > >> +1, by far simpler/cleaner than adding a new RR type. > > > > viktor, if you write this up and submit it as an i-d, i agree to review it. > > I am also willing to review such a draft. > > /Bob > > _______________________________________________ > 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: marka@isc.org From nobody Tue Aug 15 17:00:39 2017 Return-Path: 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 9AFD71323AC for ; Tue, 15 Aug 2017 17:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 ryNt3JcHJdkf for ; Tue, 15 Aug 2017 17:00:36 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8174E13239E for ; Tue, 15 Aug 2017 17:00:36 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95] (unknown [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 31EA061FF3; Wed, 16 Aug 2017 00:00:36 +0000 (UTC) Message-ID: <59938B23.6040107@redbarn.org> Date: Tue, 15 Aug 2017 17:00:35 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Mark Andrews CC: Bob Halley , "dnsop@ietf.org" References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <20170815194607.GY8146@mournblade.imrryr.org> <599366CE.6040003@redbarn.org> <43BE41D4-40FA-49DA-8F8E-13651F9DFB5E@nominum.com> <20170815234254.233248277939@rock.dv.isc.org> In-Reply-To: <20170815234254.233248277939@rock.dv.isc.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 00:00:38 -0000 Mark Andrews wrote: > Or we could just say that mapped IPv4 addresses MUST be published > in AAAA records and that A records are no longer required to be > published after January 1, 2028 (now + ~10 years). Additionally > that master nameservers and signers MUST synthesis mapped AAAA record > if there are A records at the name but no associated AAAA record. that proposal is in a different echelon of both complexity and controversy, and should not be considered as an alternative. -- P Vixie From nobody Tue Aug 15 17:34:17 2017 Return-Path: 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 8A4C21320BD for ; Tue, 15 Aug 2017 17:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 mUH7nGFqJ9Ej for ; Tue, 15 Aug 2017 17:34:13 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F7B1323B0 for ; Tue, 15 Aug 2017 17:34:12 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id f15so21422825wmg.1 for ; Tue, 15 Aug 2017 17:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1prN7IzjZHi3EKjLXMAij5CJqHApp/LUJrl9uuZ88Pk=; b=07a77z9nEzrXC+x34wMTSwf3bl9x7yVXVmfwB1WkL2OzOYeKnNR1NFt3Ld0qc43mUQ dX6F6mZANdeoo658w3th+aIuKicZ8AX/2U4zWeElnYzXu6VB7v6nkWBqumWrlGYl6D+o uxZ+0ICz84dv0v7BVWqSBmcNC3f8QXKl2zxmygrOmT25p2ZeuwI02aLRiiuilCHbGuhA rRk8WHVP4NplLpcH+kdrxeS4LGHZtQry5to/4dc2/WNz/RiGaORgU95xL3Hed3GKkQCf L+12U0CGiA1pzVI8hV6zfhmBpy+d8mn9HeezSrNXNFhkhH3EcCnM2exl+wJcRb3+TRC1 RbUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1prN7IzjZHi3EKjLXMAij5CJqHApp/LUJrl9uuZ88Pk=; b=VSHEw8FekfxF0Cn0D3/6XaWrYVT2AD5mMaGGsF0RlBsXEi6F4hRXbLHDlN9WS47F+j WNqZdTWYvR84Qnmn9aj5Cg0L0tpo9wrt5NQsslMAmOqptMvlUqZn1aXLSy7ZKikeqGkm Ofju+r47rRQ4tVf83Y3AX0dYxqKq1u21vyv2gRCaiEfzkc+ZsJeWAu+L25MEzu4ewTIC e1C5VpKYgOZYtLqDC0cUAlJ8EuTVqjsEFI67p5IYymkldWYg+xAmoXSVnza851N+AvdY QPMKwsG9V+nYAmM8hpSRVSjUJY89GSy4OdwrBQ1f3YvzZPwrq8ZH4AFekQZhBoPwq7lO y+HA== X-Gm-Message-State: AHYfb5gAZvcwg1X+4Q9lQzm5QG4G8HGxg+6JuamA5n3/vPVPUmPomjrb C9+9RsmnZjDQv7R4RGZx6wDIQV6AHkiW79WFwA== X-Received: by 10.28.196.71 with SMTP id u68mr146665wmf.18.1502843651186; Tue, 15 Aug 2017 17:34:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 15 Aug 2017 17:33:30 -0700 (PDT) In-Reply-To: <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> From: Warren Kumari Date: Tue, 15 Aug 2017 20:33:30 -0400 Message-ID: To: Tony Finch Cc: Paul Vixie , dnsop , Mikael Abrahamsson , Jared Mauch Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 00:34:15 -0000 On Tue, Aug 15, 2017 at 3:05 PM, Tony Finch wrote: > >> On 15 Aug 2017, at 20:28, Paul Vixie wrote: >> >> we can specify that AAAA be sent as additional data for QTYPE=3DA, and t= hat A be sent as additional data when QTYPE=3DAAAA. > > It's awkward. > > From the stub point of view, how does it know that the server will return= additional address records? How does it tell the difference between no sup= port, no records, or an empty cache? To what extent do the additional recor= ds actually help clients to avoid double queries? > This is a subset of draft-wkumari-dnsop-multiple-responses-05 ("Returning extra answers in DNS responses."): "Other examples where this technique may be useful include SMTP (by including mail server addresses, SPF and DKIM records when serving the MX record), SRV (by providing the target information in addition to the SRV response) and TLSA (by providing any TLSA records associated with a name). This same technique can also be used to include both the IPv4 (A) and IPv6 (AAAA) addresses for any singular address query." The above document does require DNSSEC, and is clearly an optimization, but if the auth-> recursive or recursive -> stub includes an AAAA with an A (or the other way round), it means that you'll have it handy. > From the recursive server point of view, should it delay answers so it ca= n fill in the additional section? What if a broken authority doesn't answer= to AAAA queries? > > DNSSEC can help a bit because there would be a visible proof of nonexiste= nce to disambiguate some cases. > >> given identical deployment curves along both the ANYA and additional-dat= a timelines, we will get identical results. > > ANYA has the advantage of clear signalling that the server supports it or= not, though broken servers or middleboxes might make the negative answer r= ather slow. But we would need some kind of modelling or experimental eviden= ce to see if it increases the query load by 50% (the worst case) rather tha= n reducing by 50% (the goal). multiple-responses allows servers to opportunistically include this info. We still need to do some analysis to figure out just how much of an improvement this generates, but it doesn't require any additional requests. If the server (auth or recursive) knows that a client (recursive or stub) might be able to use this into, it just shovels it in. This leads to larger responses, but I think that we lost the "small packets" battle long ago -- attackers who want to find big responses for reflections can easily do so... > > Tony. > -- > f.anthony.n.finch http://dotat.at > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 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 nobody Tue Aug 15 17:45:35 2017 Return-Path: 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 A3F351323B0 for ; Tue, 15 Aug 2017 17:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 UMR3GV29gK3j for ; Tue, 15 Aug 2017 17:45:31 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D75313226B for ; Tue, 15 Aug 2017 17:45:31 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id t201so19472706wmt.1 for ; Tue, 15 Aug 2017 17:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=RWNkD9gO5BNrwreZHdVEfcs7I6xQ8HB2uWnFfNdZXwE=; b=Cg23yVXtrCH1DZ2NzErw1r3AzwVk8KYYUbhBtIQobic2g0K0xfKLxdghccoR/tt+O4 9l1ACu80it5S3N7rLdDJCGlv38ym6qQ3gwSfE0TXctqtXIce1QCZIqJrPFFytY+bnFRH um8/Ph8GFYU/g+lPYkqkqNhd+KubaVJpgaOd1VI59QqpVC28rFDK2RlMeENEMssrBmb4 eryKoWX9I6bTxZRSFd1w9AL9jboJXggj9B2pneF1zHHfyWDyE4nhcKD5YmfJGDlXfuXh x/kiGoWL/6joo8GE20fRew6KGWrrxjidQ1ePxzzQO8jyIx+/mnaLxIyQ7z6VAnE4ZtnX Z3/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RWNkD9gO5BNrwreZHdVEfcs7I6xQ8HB2uWnFfNdZXwE=; b=sH9DxC5Swi94cgmcmgSg8AYUV0BOjV77YeztCFBQEvWv7FRWrSEtI8/ZXKj40nuh6K MYbaauV4uctVV69Byd+PEgvy3zyJGdeLpOemBNkFeuexpaKRw21SK1IqJugf/Z6unCoe SDXx/PFHtJ3U5/rWHGbq7fKCnCQz/U/4/Ex8InakJVTuMvkDPgZ9guK/KnN/HqacMKe1 gHhV2Vy+RMufwylzfCYTGMXYfrLJUKe+kr7Gyzuif5njK0/arHP2iIAy+shdVu2gRx3H UOUyEywqRaogNh4A4qoRkGZtLYbh67JyG9Ao3Us4H+uIZosMsTqYU6uCZ8/M+HL9lz/X sUPg== X-Gm-Message-State: AHYfb5j1Pj0AoLFpAdra6hXuGdPx4zkWTTOzoNFkG9hGMLjQCFLOyaKe 1MmebGz50jl5Sqb7grRl0hXqm1bpFvO8 X-Received: by 10.28.12.201 with SMTP id 192mr158424wmm.45.1502844329677; Tue, 15 Aug 2017 17:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Tue, 15 Aug 2017 17:44:48 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Tue, 15 Aug 2017 20:44:48 -0400 Message-ID: To: =?UTF-8?B?56We5piO6YGU5ZOJ?= Cc: Mikael Abrahamsson , dnsop , Ted Lemon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 00:45:34 -0000 On Tue, Aug 15, 2017 at 1:08 PM, =E7=A5=9E=E6=98=8E=E9=81=94=E5=93=89 wrote: > At Tue, 15 Aug 2017 13:40:00 +0200 (CEST), > Mikael Abrahamsson wrote: > >> > If it's a commonly-used name, isn't this a one-time event, though? Th= e >> > happy eyeballs client asks for A and AAAA, gets A because it was in th= e >> > cache, but AAAA also winds up in the cache, and then because it's a >> > commonly used name, neither record ever goes stale again. >> >> That was the assumtion by a lot of people who aren't DNS experts >> (including me). Mark Andrews brought up that this might be a more freque= nt >> issue that people think. >> >> Also there is the issue that as the TTL becomes 0 and the RR is now no >> longer in cache, next question will trigger a lookup and if the >> authoritative nameserver is 400ms RTT away, then during these 400ms a lo= t >> of clients might only use IPv4 with current RFC6555bis proposal. > > If it's a commonly-used name, I suspect the more straightforward > "prefetching" should suffice in practice: > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ > Several popular recursive servers already implement the feature. > Some of them even enable it by default. > One of the main outstanding items on the "Stop! Hammer Time!" document that we need to clean up the implementation section (Appendix A), but it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND 9.10 implement this. Unbound's documentation says that the default for prefetch is disabled (https://www.unbound.net/documentation/unbound.conf.html), and, BIND enables it by default ( https://kb.isc.org/article/AA-01122/204/Early-refresh-of-cache-records-cach= e-prefetch-in-BIND-9.10.html ) W > My impression on the rfc6555bis thread is that Mark wanted to make it > "safer" (in that both AAAA and A responses are provided before trying > to establish a TCP connection) even in some near-worst cases, not just > "working in most cases in practice". In that sense I suspect tricks > at the resolver won't help much, whether it's existing prefetch, > opportunistic refresh or bundled AAAA/A queries, since there are worst > cases where those don't work. Whether we need this level of > perfection for rfc6555bis is a different question, though. > > -- > JINMEI, Tatuya > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 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 nobody Tue Aug 15 18:05:23 2017 Return-Path: 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 391E41321F0 for ; Tue, 15 Aug 2017 18:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 zluxMHsPsMao for ; Tue, 15 Aug 2017 18:05:21 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 019EE132076 for ; Tue, 15 Aug 2017 18:05:21 -0700 (PDT) Received: from jurassic (unknown [115.117.171.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id DA87F56A003F; Wed, 16 Aug 2017 01:05:17 +0000 (GMT) Date: Wed, 16 Aug 2017 06:35:14 +0530 From: Mukund Sivaraman To: Warren Kumari Cc: Tony Finch , dnsop , Jared Mauch , Paul Vixie , Mikael Abrahamsson Message-ID: <20170816010514.GA32767@jurassic> References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <294FA766-3C87-4C35-AF0F-E886A7ADEDE5@dotat.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 01:05:22 -0000 Hi Warren On Tue, Aug 15, 2017 at 08:33:30PM -0400, Warren Kumari wrote: > multiple-responses allows servers to opportunistically include this > info. We still need to do some analysis to figure out just how much of > an improvement this generates, but it doesn't require any additional > requests. If the server (auth or recursive) knows that a client > (recursive or stub) might be able to use this into, it just shovels it > in. This leads to larger responses, but I think that we lost the > "small packets" battle long ago -- attackers who want to find big > responses for reflections can easily do so... There's a cost attached to how much information is in a reply message. Lookup of data, rendering it to a DNS message, RR ordering, name compression, etc. all consume CPU and the query performance of a service is affected by how many RRsets it includes in a reply. This is significant and should not be ignored when thinking about these extensions. I favour the draft where the client requests for things it needs (including for TLSA as somebody pointed out) than the server adding what it thinks a client may need (a lot of which may end up being thrown away by the client). I don't oppose bundling A/AAAA though per this thread. Mukund From nobody Tue Aug 15 21:19:26 2017 Return-Path: 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 61748132361 for ; Tue, 15 Aug 2017 21:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6UiF6MAe_7MB for ; Tue, 15 Aug 2017 21:19:22 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E99F1321A5 for ; Tue, 15 Aug 2017 21:19:22 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so21532894wma.0 for ; Tue, 15 Aug 2017 21:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RVcpz8f6wQQ9+EFLUs/WfEmVlyuRUauwMjJcvHKt1/w=; b=HDZ19Zx5ZNQPVZQt/1ifw/yo2mdsd8gUFhepPofq3Uy7bsOmvO0/VmGhWBVQ9sstIk SmNE157asUJvBf3ZV++7S9bK7t6Q16rwB1YqlkIV/LXQDx0kqDjPZCpDQsut2SRm4gHN r6khFRnG69KtJWpk7GFlhC++2umZSCsyY/DphQCwVSL1pqjF4lxQEONpONhGjzN2Ew1X f2zG/VeydkKN+Z4KJN+R44TTSSnRVc/URtNz5SLZrSREKXv30dHUYrQEHijwkTHon8mr Fty22r3C2pNvMkXdx+FqqFXF5QxWANzf1OSUjuf7DwwkQOMKliv785ueYa52sKuN9wrW c3Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RVcpz8f6wQQ9+EFLUs/WfEmVlyuRUauwMjJcvHKt1/w=; b=VIITbcSUU9RqelchM9iH5cpygelTPrCvP3tOWcckgPKgd0un2oZ2baXUNNumjoukaI YrA4pZHkMjF6GqPwfWnzB9cYN9HakMa0PMJZVSAnlZzGAJGgPq1pBuvgwkfFfPPF5pX+ X1ngu4W2Opz2YNPsuR5tPdWAHYyp0ykJfNMRu2oWIG0bX+EVe9n05nsVVtCw15dLBxEc W5990aJ/+EYjUohsdj57ecmFI11AmpXdURrx/pwQ6pmrSUHwWtpC3XIB/Z14OgY47TuO WLoMBHbz6doTTIMZmCiOdomebZzXyJjTual6T2LuJA0bOtNtVOp7RgEE9wIWvOJb5N9F 9X7g== X-Gm-Message-State: AHYfb5hvHvApJgqFPXFzZ5LhNMJEr3HiFZJvFV/EN/IJxgoQqxt0NGjj D2xVVnXwq1a87qL6iIrgYra8S1GSodX9Y14= X-Received: by 10.80.146.5 with SMTP id i5mr708851eda.48.1502857160985; Tue, 15 Aug 2017 21:19:20 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> In-Reply-To: From: Lanlan Pan Date: Wed, 16 Aug 2017 04:19:10 +0000 Message-ID: To: Ted Lemon Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c0c463a8fbe0556d7336c" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 04:19:25 -0000 --f403045c0c463a8fbe0556d7336c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ted, Thanks for your relevant comments, :-) Ted Lemon =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8A=E5=8D=881:28=E5=86=99=E9=81=93=EF=BC=9A > I tried to ignore this thread for a while, but became alarmed after > reading some of the recent comments, so I went and read the document. > > As far as I can tell, this document gives no clear justification for why > it is a good idea. We have not been told of the practical operational > problems that motivate it. It appears to solve a problem we have alread= y > solved, in a way that creates new security vulnerabilities. We have not > been told why the existing solution to the problem is not adequate. > > If the authors have a real problem that they feel has not already been > solved, the first step in the process ought to be to present that > information to the working group, rather than to present a solution to th= e > working group with no clear statement about the problem it solves, and in > particular no data about the seriousness of the problem. > For what it's worth, which isn't much since the chairs haven't issued a > call for adoption, I don't think the working group should work on this. > We analyzed our recursive query log, about 18.6 billion queries from 12/01/2015 to 12/07/2015. We found about 4.7 Million temporary domains occupy the recursive's cache, which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, Cloudfront, Greencompute... Temporary Domain Names/ All Names: 41.7% Queries for Temporary Domain Names/ All Queries: 0.12% Details in: Dealing with temporary domain name issues in the DNS The operational problem is, subdomain wildcards waste recursive cache capacity. Existing solution to the problem is not adequate in recursive operating environment at present, because of low DNSSEC deployment. > > On Tue, Aug 15, 2017 at 9:41 AM, Vernon Schryver wrote= : > >> ] From: Lanlan Pan >> >> ] Give the choice to operators, time is the best witness, like IP >> surpassed >> ] ATM. >> >> That is backwards. IP did not surpass ATM, because IP came long before >> ATM. Instead, end-to-end ATM was the last gasp of the end-to-end >> circuit switching point of view. End-to-end ATM was supposed to replace >> IP, but instead the new virtual circuits of ATM came far too late and >> did not solve the problems that packet switching had already solved. >> >> ATM has not yet died and is still common for some uses. For example, >> ATM is used as x.25 was used under IP in the early days of IP; many >> DSL installations use AMT VCs. >> >> A better and more relevant history is that of the SPF RR. The SPF RR >> was supposed to replace the use of the TXT rtype for SPF. The SPF RR >> was widely available in deployed DNS authoritative servers (via BIND). >> I think it was in milter modules for sendmail and postfix. Nevertheless= , >> it died because it came late, was only a modest improvement, and require= d >> operators to do something more than they were doing. >> >> >> Vernon Schryver vjs@rhyolite.com >> >> _______________________________________________ >> 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 > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c0c463a8fbe0556d7336c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ted,

Thanks for your relevant comment= s, :-)

Te= d Lemon <mellon@fugue.com>=E4= =BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8A=E5=8D= =881:28=E5=86=99=E9=81=93=EF=BC=9A
=
I tried to ignore this thread for a while, but became alar= med after reading some of the recent comments, so I went and read the docum= ent.

As far as I can tell, this document gives no clear = justification for why it is a good idea. =C2=A0 We have not been told of th= e practical operational problems that motivate it. =C2=A0 It appears to sol= ve a problem we have already solved, in a way that creates new security vul= nerabilities. =C2=A0 We have not been told why the existing solution to the= problem is not adequate.

If the authors have a re= al problem that they feel has not already been solved, the first step in th= e process ought to be to present that information to the working group, rat= her than to present a solution to the working group with no clear statement= about the problem it solves, and in particular no data about the seriousne= ss of the problem.
<= div dir=3D"ltr">
For what it's worth, which isn't much since th= e chairs haven't issued a call for adoption, I don't think the work= ing group should work on this.
=C2=A0
We analyzed our recursive query log, about 18.6 billion queries from 12/01/2015 to 12/07/2015.
=09 =09

We found about 4.7= Million temporary domains occupy the recursive's cache, which are subd= omain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, Cloudfront, = Greencompute...

Temporary Domain Names/ All Names: 41.7%

Queries for Tem= porary Domain Names/ All Queries: 0.12%


The operational problem is, = subdomain wildcards waste recursive cache capacity. Existing solution to th= e problem is not adequate in recursive operating environment at present, be= cause of low DNSSEC deployment.
=C2=A0

On Tue, Aug = 15, 2017 at 9:41 AM, Vernon Schryver <vjs@rhyolite.com> wrote= :
] From: Lanlan Pan <abbypan@gmail.com>

] Give the choice to operators, time is the best witness, like IP surpassed=
] ATM.

That is backwards.=C2=A0 IP did not surpass ATM, because IP came long befor= e
ATM.=C2=A0 Instead, end-to-end ATM was the last gasp of the end-to-end
circuit switching point of view.=C2=A0 End-to-end ATM was supposed to repla= ce
IP, but instead the new virtual circuits of ATM came far too late and
did not solve the problems that packet switching had already solved.

ATM has not yet died and is still common for some uses.=C2=A0 For example,<= br> ATM=C2=A0 is used as x.25 was used under IP in the early days of IP; many DSL installations use AMT VCs.

A better and more relevant history is that of the SPF RR.=C2=A0 The SPF RR<= br> was supposed to replace the use of the TXT rtype for SPF.=C2=A0 The SPF RR<= br> was widely available in deployed DNS authoritative servers (via BIND).
I think it was in milter modules for sendmail and postfix.=C2=A0 Neverthele= ss,
it died because it came late, was only a modest improvement, and required operators to do something more than they were doing.


Vernon Schryver=C2=A0 =C2=A0 vjs@rhyolite.com

_______________________________________________
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
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--f403045c0c463a8fbe0556d7336c-- From nobody Tue Aug 15 22:45:48 2017 Return-Path: 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 9C065132415 for ; Tue, 15 Aug 2017 22:45:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 cY-KrFtBYC8q for ; Tue, 15 Aug 2017 22:45:45 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED241321A5 for ; Tue, 15 Aug 2017 22:45:45 -0700 (PDT) Received: from jurassic (unknown [115.117.171.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 6667356A014C; Wed, 16 Aug 2017 05:45:41 +0000 (GMT) Date: Wed, 16 Aug 2017 11:15:39 +0530 From: Mukund Sivaraman To: Matthew Pounsett Cc: Lanlan Pan , dnsop , Petr =?utf-8?B?xaBwYcSNZWs=?= , =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Message-ID: <20170816054539.GA12897@jurassic> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 05:45:46 -0000 On Fri, Aug 11, 2017 at 10:39:50AM -0400, Matthew Pounsett wrote: > It sounds like you're assuming that SWILD would be supported by caching > servers that do not support DNSSEC or NSEC aggressive use. Why do you > expect implementers would adopt SWILD before adopting these much older > features? (Without commenting about SWILD) It does not have to be due to implementation support alone. Many operators stick to unsigned zones. There are many reasons, some of which I'd mentioned in the unsigned NSEC thread. Resolvers have to deal with cache pollution and unnecessary upstream queries, but they have no control over whether the authoritative zones are signed. 2 mails up this thread, there is a comment about "New features are provided only by the latest version of the protocol." This seems to mix unrelated things together. The latest version of DNS (if there's such a thing) doesn't mandate operational use of DNSSEC. Use of unsigned zones is not obsolete and may well outlive us. Most zones today are unsigned and a carrot like NSEC agressive use is unlikely to change the level of adoption of DNSSEC significantly. Alexa Top domains and DNSSEC: 24 / 500 top domains (4.8%) 20548 / 1 million top domains (2.05%) (12 years after introduction of 403{3,4,5}) Mukund From nobody Tue Aug 15 23:21:43 2017 Return-Path: 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 73DAE1252BA for ; Tue, 15 Aug 2017 23:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 tBnYSNCXICe9 for ; Tue, 15 Aug 2017 23:21:40 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 AF970124217 for ; Tue, 15 Aug 2017 23:21:40 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 98FEEAF; Wed, 16 Aug 2017 08:21:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502864497; bh=NddMwPci93djrfc4vVEhSpJ7rS/5HIrc6NdYwd1EZeU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=wnvFi876kyybUvIuHapjG2S8FKDNgwhIoFh0rCGSxhjLNzIGqd1i5WAEjBYlHfAIW lbz8Mtq3d/8jQqVkddcdv8dWJ4hCt+gPvncg5E9p7GqAeDtLROOvmlzzlyXX67zKiV ZCySu6swotTsF3KQCvY1BtfwND/Ci2kuCqff8sSY= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 81B5584; Wed, 16 Aug 2017 08:21:37 +0200 (CEST) Date: Wed, 16 Aug 2017 08:21:37 +0200 (CEST) From: Mikael Abrahamsson To: Mukund Sivaraman cc: dnsop In-Reply-To: <20170816054539.GA12897@jurassic> Message-ID: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 06:21:42 -0000 On Wed, 16 Aug 2017, Mukund Sivaraman wrote: > 24 / 500 top domains (4.8%) > 20548 / 1 million top domains (2.05%) > > (12 years after introduction of 403{3,4,5}) https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1 20% of European users is behind a validating resolver, in some countries it's 70% plus. So this is now happening, albeit at a not high enough pace. But at least it's going in the right direction, and I do believe that there is enough people behind validating resolvers that people can't mess up signing their zone and push away blame on who needs to fix things. So at least there is benefit in signing your zone now, there wasn't as much before when nobody was validating. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Aug 15 23:29:59 2017 Return-Path: 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 009B2132043 for ; Tue, 15 Aug 2017 23:29:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 2CUVfXOR_Hf9 for ; Tue, 15 Aug 2017 23:29:57 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF6E126B71 for ; Tue, 15 Aug 2017 23:29:56 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95] (unknown [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BF83C61FF3; Wed, 16 Aug 2017 06:29:56 +0000 (UTC) Message-ID: <5993E664.2070107@redbarn.org> Date: Tue, 15 Aug 2017 23:29:56 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Mukund Sivaraman CC: dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> In-Reply-To: <20170816054539.GA12897@jurassic> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 06:29:58 -0000 Mukund Sivaraman wrote: ... > > Alexa Top domains and DNSSEC: > > 24 / 500 top domains (4.8%) > 20548 / 1 million top domains (2.05%) > > (12 years after introduction of 403{3,4,5}) we should give up. or we shouldn't. not a mixture. -- P Vixie From nobody Tue Aug 15 23:38:52 2017 Return-Path: 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 4C768132397 for ; Tue, 15 Aug 2017 23:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 z9Gbljzb2sYL for ; Tue, 15 Aug 2017 23:38:49 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2DCE9126B71 for ; Tue, 15 Aug 2017 23:38:49 -0700 (PDT) Received: from jurassic (unknown [115.117.171.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id E027E56A05A1; Wed, 16 Aug 2017 06:38:46 +0000 (GMT) Date: Wed, 16 Aug 2017 12:08:43 +0530 From: Mukund Sivaraman To: Paul Vixie Cc: dnsop Message-ID: <20170816063843.GA16977@jurassic> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <5993E664.2070107@redbarn.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5993E664.2070107@redbarn.org> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 06:38:50 -0000 On Tue, Aug 15, 2017 at 11:29:56PM -0700, Paul Vixie wrote: > > > Mukund Sivaraman wrote: > ... > > > > Alexa Top domains and DNSSEC: > > > > 24 / 500 top domains (4.8%) > > 20548 / 1 million top domains (2.05%) > > > > (12 years after introduction of 403{3,4,5}) > > we should give up. > > or we shouldn't. > > not a mixture. I'm not saying we should give up.. but it's going to be a while before we get to an utopia of maximal DNSSEC deployment. In the meantime, there are practical problems that need mitigation. Mukund From nobody Tue Aug 15 23:49:04 2017 Return-Path: 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 03D60124217 for ; Tue, 15 Aug 2017 23:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 YxqMPjiS7HIw for ; Tue, 15 Aug 2017 23:49:01 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 05663120713 for ; Tue, 15 Aug 2017 23:49:01 -0700 (PDT) Received: from jurassic (unknown [115.117.171.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 3DF6656A014C; Wed, 16 Aug 2017 06:48:58 +0000 (GMT) Date: Wed, 16 Aug 2017 12:18:55 +0530 From: Mukund Sivaraman To: Mikael Abrahamsson Cc: dnsop Message-ID: <20170816064855.GB16977@jurassic> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 06:49:03 -0000 On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote: > On Wed, 16 Aug 2017, Mukund Sivaraman wrote: > > > 24 / 500 top domains (4.8%) > > 20548 / 1 million top domains (2.05%) > > > > (12 years after introduction of 403{3,4,5}) > > https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1 > > 20% of European users is behind a validating resolver, in some countries > it's 70% plus. > > So this is now happening, albeit at a not high enough pace. But at least > it's going in the right direction, and I do believe that there is enough > people behind validating resolvers that people can't mess up signing their > zone and push away blame on who needs to fix things. > > So at least there is benefit in signing your zone now, there wasn't as much > before when nobody was validating. The validating resolver is half of the system. DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was designed for) that many businesses cannot afford to bank on if something were to go wrong. An administrative error or signer software bug on the authoritative side can take the whole zone down and every service with it (as DNS is at the head of network activity). Software is still not perfect, so I don't know how this can change - I see practical signer bugs still that take down the zone entirely. It's also still painfully inconvenient to update parent zones, that makes fixing mishaps difficult. The amount of damage that a break in DNSSEC validation chain could do is far greater than other implementations of crypto such as TLS where it is limited to a service. (Note that I'm not advocating against DNSSEC, as much as this email may sound so. The things I mention are practical issues that I see as an implementor.) A colleague says "If TLD’s allowed UPDATE messages to be processed most of the issues with DNSSEC would go away. At the moment we have a whole series of kludges because people are scared of signed update messages." Mukund From nobody Wed Aug 16 00:03:48 2017 Return-Path: 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 4CCDA132397 for ; Wed, 16 Aug 2017 00:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 Scp--uHwISHQ for ; Wed, 16 Aug 2017 00:03:44 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 08729120713 for ; Wed, 16 Aug 2017 00:03:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2D925B0; Wed, 16 Aug 2017 09:03:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502867021; bh=RdCRBNYmR6+X1WT64acT5LeiUorrOvpKukegPww30ZU=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=iVSaVF2BqDkbf78RlwYo5ChwzHOvIj29zlpIE1EokoNm1mOY33IUu26GdDvgnHXys tuO5U3iOToOLNGhfe3wtfzQVtUdgb0SPvAOT8PlKseJ4T2d/6sNdz4z5Nk0Lu+bY5h opvy/jXl/ESEIT9ax5W+QNZwCCRpfde0fOWjzTmQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2AEE0AF; Wed, 16 Aug 2017 09:03:41 +0200 (CEST) Date: Wed, 16 Aug 2017 09:03:41 +0200 (CEST) From: Mikael Abrahamsson To: Mukund Sivaraman cc: dnsop In-Reply-To: <20170816064855.GB16977@jurassic> Message-ID: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:03:46 -0000 On Wed, 16 Aug 2017, Mukund Sivaraman wrote: > > The validating resolver is half of the system. > > DNSSEC is brittle. Absolutely. But before we were in a situation where people signed zones, screwed it up, and then the (sometime single) ISP running a validating resolver got the run-around "must be wrong at your end, nobody else is complaining" and the zone signing was never fixed. Now I think we're past that. There are enough users behind validating resolvers nowadays that you can't get away with getting your signing wrong and blaming others. Yes, we need better APIs so applications can tell the user what went wrong, instead of just throwing a DNS failure. If there is need to update the DNS specs for this to be possible, then that should be done. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 00:04:54 2017 Return-Path: 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 18A4513240E for ; Wed, 16 Aug 2017 00:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 b2isp2FVoSO1 for ; Wed, 16 Aug 2017 00:04:52 -0700 (PDT) Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id B547713240F for ; Wed, 16 Aug 2017 00:04:49 -0700 (PDT) Received: from jurassic (unknown [115.117.171.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 3F78756A05A1; Wed, 16 Aug 2017 07:04:48 +0000 (GMT) Date: Wed, 16 Aug 2017 12:34:45 +0530 From: Mukund Sivaraman To: Mikael Abrahamsson Cc: dnsop Message-ID: <20170816070445.GA17023@jurassic> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170816064855.GB16977@jurassic> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:04:53 -0000 On Wed, Aug 16, 2017 at 12:18:55PM +0530, Mukund Sivaraman wrote: > difficult. The amount of damage that a break in DNSSEC validation chain > could do is far greater than other implementations of crypto such as TLS > where it is limited to a service. Caching can also exacerbate such problems making a bad situation worse, so a fix may not be instantaneously observed. This is unlike with other popular crypto protocols such as TLS. Mukund From nobody Wed Aug 16 00:05:36 2017 Return-Path: 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 BF084132397 for ; Wed, 16 Aug 2017 00:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 w52nQjMhrN7u for ; Wed, 16 Aug 2017 00:05:32 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C48C6120713 for ; Wed, 16 Aug 2017 00:05:32 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95] (unknown [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id AE08C61FF3; Wed, 16 Aug 2017 07:05:32 +0000 (UTC) Message-ID: <5993EEBC.9040908@redbarn.org> Date: Wed, 16 Aug 2017 00:05:32 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Mukund Sivaraman CC: dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <5993E664.2070107@redbarn.org> <20170816063843.GA16977@jurassic> In-Reply-To: <20170816063843.GA16977@jurassic> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:05:34 -0000 Mukund Sivaraman wrote: > On Tue, Aug 15, 2017 at 11:29:56PM -0700, Paul Vixie wrote: >> we should give up. >> >> or we shouldn't. >> >> not a mixture. > > I'm not saying we should give up.. but it's going to be a while before > we get to an utopia of maximal DNSSEC deployment. In the meantime, there > are practical problems that need mitigation. anybody who needs secure denial of existence, of wildcards or other data, should deploy dnssec. anybody who needs their networking partners to have this, should urge their partners to deploy dnssec. if we don't believe that this can be done, then we should give up on dnssec. there is no middle road here. -- P Vixie From nobody Wed Aug 16 00:06:14 2017 Return-Path: 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 EAE6A132414 for ; Wed, 16 Aug 2017 00:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CIKo5Nymr98Q for ; Wed, 16 Aug 2017 00:06:10 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A4BB120713 for ; Wed, 16 Aug 2017 00:06:10 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id t138so28224294wmt.1 for ; Wed, 16 Aug 2017 00:06:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zSmvbjP7XoNSMvlHeWcUOtocXTni7BlxcegOS0Uh1Mk=; b=S3z9z+QdVIrO/0qQWVRxty3Zxfh0HckeMzRrjG0AJnRQZVc5gb5FNgO9Q/NuIX8JLa YJaUEX4ZgiFGwA8ATD7bd8C9jv+Qt279ScPWIvogYJr8dinxP2+81OP9G8l/bC87EX5h SXfq7cJc/ncD63Zbda269R/Aw1OGHyaqfFPVEKotNHA7l4yH5JtMukRxhBKt2VbxqvyE pPByHo6OR6T48/mw6BgXPzJeAkJYERj30Dk1a/GBBFTP6k03V7iTIQqfCKu3emvlapPP AuocjAcho4PdayLHKm1N2BILEdi5uRu0Sw1Tkw2k0E8kexd7Yct+rDjilhcPSg3K0C9S FlvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zSmvbjP7XoNSMvlHeWcUOtocXTni7BlxcegOS0Uh1Mk=; b=leGf+rsgQXrXyl58e1po57i7dRISdeiGPB4zOv4u/DCN4pHDssrs0A5/X0x1yaM33v Ec7evzGZ9Lm5RD3qVeS/fhdZLSDj7CtG5c2kZZCfqdtnpNARYwe+BthChbRY0fAcUjPr MeFsJ4nsP5hfAHLV964oJ6pa3hSE8ObZ0eC4MYNWQ1puHCJr+7wDZrbcH45XkMVZcime byy3ZS8on/IzC574Ie7jZfhxu6eee98z5YFlMfhQvDU0x8uO7AJzfNaE9iqpeotIoO2f lRNC7PtVc3LVuryrGVF8k+vJP/HVZUkeVtcNZZqN/K/HHQxCgY6PvHyWJ7uVuDupTihI kAbA== X-Gm-Message-State: AHYfb5gdaFpzYbB+O0daW2d+7F+NjfeNW88VsX6zOuPocLAjCnhuitr9 pRLM+aTDNDWFPzOwDWgXqBEewe1ltSa4tyw= X-Received: by 10.80.241.66 with SMTP id z2mr1059908edl.21.1502867169191; Wed, 16 Aug 2017 00:06:09 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <5993E664.2070107@redbarn.org> In-Reply-To: <5993E664.2070107@redbarn.org> From: Lanlan Pan Date: Wed, 16 Aug 2017 07:05:58 +0000 Message-ID: To: Paul Vixie Cc: dnsop , Mukund Sivaraman Content-Type: multipart/alternative; boundary="089e08283f9cc3aa490556d98707" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:06:13 -0000 --089e08283f9cc3aa490556d98707 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (Without commenting about SWILD) Is your RPZ a mixture ? Doesn't RPZ rewrite DNS answer, break DNSSEC validation ? Should we give up , or we shouldn't ? Paul Vixie =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8B=E5=8D=882:30=E5=86=99=E9=81=93=EF=BC=9A > > > Mukund Sivaraman wrote: > ... > > > > Alexa Top domains and DNSSEC: > > > > 24 / 500 top domains (4.8%) > > 20548 / 1 million top domains (2.05%) > > > > (12 years after introduction of 403{3,4,5}) > > we should give up. > > or we shouldn't. > > not a mixture. > > -- > P Vixie > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --089e08283f9cc3aa490556d98707 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Without commenting about SWILD)

=
Is your RPZ a mixture ?

Doesn't RPZ rewri= te DNS answer, break DNSSEC validation ?

Shou= ld we give up , or we shouldn't ?

Paul Vixie <paul@redbarn.org>=E4=BA=8E2017=E5=B9=B48=E6=9C= =8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=882:30=E5=86=99=E9=81=93= =EF=BC=9A


Mukund Sivaraman wrote:
...
>
> Alexa Top domains and DNSSEC:
>
> 24 / 500 top domains (4.8%)
> 20548 / 1 million top domains (2.05%)
>
> (12 years after introduction of 403{3,4,5})

we should give up.

or we shouldn't.

not a mixture.

--
P Vixie

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85= =B0=C2=A0 Pan Lanlan
--089e08283f9cc3aa490556d98707-- From nobody Wed Aug 16 00:06:46 2017 Return-Path: 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 DBD9C132426 for ; Wed, 16 Aug 2017 00:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 LwRapd1iWryr for ; Wed, 16 Aug 2017 00:06:43 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC70132411 for ; Wed, 16 Aug 2017 00:06:43 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95] (unknown [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id A46E161FF3; Wed, 16 Aug 2017 07:06:43 +0000 (UTC) Message-ID: <5993EF03.3090005@redbarn.org> Date: Wed, 16 Aug 2017 00:06:43 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Mukund Sivaraman CC: Mikael Abrahamsson , dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> In-Reply-To: <20170816064855.GB16977@jurassic> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:06:45 -0000 Mukund Sivaraman wrote: > DNSSEC is brittle. then let's fix it. or give up on it. -- P Vixie From nobody Wed Aug 16 00:19:10 2017 Return-Path: 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 2F47D13263E for ; Wed, 16 Aug 2017 00:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 n9_PzjOwAB5l for ; Wed, 16 Aug 2017 00:19:07 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA7E913263F for ; Wed, 16 Aug 2017 00:19:07 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95] (unknown [IPv6:2001:559:8000:c9:fcd9:f67b:792b:7f95]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 7A26A61FF3; Wed, 16 Aug 2017 07:19:07 +0000 (UTC) Message-ID: <5993F1EA.2010305@redbarn.org> Date: Wed, 16 Aug 2017 00:19:06 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Lanlan Pan CC: dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <5993E664.2070107@redbarn.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:19:09 -0000 Lanlan Pan wrote: > (Without commenting about SWILD) > > Is your RPZ a mixture ? no. > Doesn't RPZ rewrite DNS answer, break DNSSEC validation ? the I-D advises against this. some implementations offer a switch to rewrite DNSSEC-signed results. i don't use this myself, and i recommend against its use. my reasoning is that if the initiator indicates a desire for dnssec meta data, and there is in fact dns metadata, then any lie will be transparently obvious, and you should not in that case tell that lie. some time before bad people get around to using dnssec to bypass rpz, the spec will have to evolve to allow new signalling ("i want to hear both the truth and the lie, and please sign the lie with our shared key so i'll know it's from you"). i figure we have a few years to get it done. it's one of the first things this WG will take up if an RFC is published on the current protocol, at which point vernon and i have agreed to surrender change control. thank you for giving me this platform to explain the dnssec dilemma faced by rpz, along with my position, and my expectations. RPZ is not meant to be a censorship tool and will not, and should not, work as one. DNS filtering must be seen as a value-add by its user community or else it should be, and will in fact be, nonfunctional. > Should we give up , or we shouldn't ? see #1, #4, especially #7, and #12 from . your lacks of respect and of professionalism is noted. -- P Vixie From nobody Wed Aug 16 00:19:39 2017 Return-Path: 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 18260132644 for ; Wed, 16 Aug 2017 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 8RiCML3LL1aS for ; Wed, 16 Aug 2017 00:19:32 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F65132648 for ; Wed, 16 Aug 2017 00:19:29 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 1EF9124AE36; Wed, 16 Aug 2017 07:19:18 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id E8A03160052; Wed, 16 Aug 2017 07:19:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id D041B160067; Wed, 16 Aug 2017 07:19:23 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wxnJWOoIwxsI; Wed, 16 Aug 2017 07:19:23 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 48EF9160052; Wed, 16 Aug 2017 07:19:23 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BA2C98287EA4; Wed, 16 Aug 2017 17:19:20 +1000 (AEST) To: Mukund Sivaraman Cc: Mikael Abrahamsson , dnsop From: Mark Andrews References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> In-reply-to: Your message of "Wed, 16 Aug 2017 12:18:55 +0530." <20170816064855.GB16977@jurassic> Date: Wed, 16 Aug 2017 17:19:20 +1000 Message-Id: <20170816071920.BA2C98287EA4@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 07:19:38 -0000 In message <20170816064855.GB16977@jurassic>, Mukund Sivaraman writes: > On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote: > > On Wed, 16 Aug 2017, Mukund Sivaraman wrote: > > > > > 24 / 500 top domains (4.8%) > > > 20548 / 1 million top domains (2.05%) > > > > > > (12 years after introduction of 403{3,4,5}) > > > > https://stats.labs.apnic.net/dnssec/XE?o=cXAw1x1g1r1 > > > > 20% of European users is behind a validating resolver, in some countries > > it's 70% plus. > > > > So this is now happening, albeit at a not high enough pace. But at least > > it's going in the right direction, and I do believe that there is enough > > people behind validating resolvers that people can't mess up signing > their > > zone and push away blame on who needs to fix things. > > > > So at least there is benefit in signing your zone now, there wasn't as > much > > before when nobody was validating. > > The validating resolver is half of the system. > > DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was > designed for) that many businesses cannot afford to bank on if something > were to go wrong. An administrative error or signer software bug on the > authoritative side can take the whole zone down and every service with > it (as DNS is at the head of network activity). Software is still not > perfect, so I don't know how this can change - I see practical signer > bugs still that take down the zone entirely. It's also still painfully > inconvenient to update parent zones, that makes fixing mishaps > difficult. The amount of damage that a break in DNSSEC validation chain > could do is far greater than other implementations of crypto such as TLS > where it is limited to a service. > > (Note that I'm not advocating against DNSSEC, as much as this email may > sound so. The things I mention are practical issues that I see as an > implementor.) > > A colleague says "If TLDs allowed UPDATE messages to be processed most > of the issues with DNSSEC would go away. At the moment we have a whole > series of kludges because people are scared of signed update messages." And there is even a IANA assign SRV prefix to allow UPDATE messages to be directed to directed to a server other than those that are answering the queries. Apple was good enough to get it registered several years ago. SIG(0) and TSIG UPDATE messages are forwardable so all the TLD operator needs to do is to redirect the messages to the appropriate registrar, based on the records being updated, for processing then return the reply. Named forwards both types of messages and returns the replies so this is all technically possible. > Mukund > > _______________________________________________ > 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: marka@isc.org From nobody Wed Aug 16 01:05:57 2017 Return-Path: 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 9DC2D1321A8 for ; Wed, 16 Aug 2017 01:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 zXHYOf4WvEPF for ; Wed, 16 Aug 2017 01:05:55 -0700 (PDT) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 37808124207 for ; Wed, 16 Aug 2017 01:05:55 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 400755F4004A; Wed, 16 Aug 2017 10:05:48 +0200 (CEST) Received: from [172.20.10.3] (tmo-100-232.customers.d1-online.com [80.187.100.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 6E3085F4004A; Wed, 16 Aug 2017 10:05:45 +0200 (CEST) From: "Ralf Weber" To: "Warren Kumari" Cc: "=?utf-8?b?56We5piO6YGU5ZOJ?=" , dnsop , "Ted Lemon" , "Mikael Abrahamsson" Date: Wed, 16 Aug 2017 10:05:50 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 08:05:56 -0000 Moin! On 16 Aug 2017, at 2:44, Warren Kumari wrote: >> If it's a commonly-used name, I suspect the more straightforward >> "prefetching" should suffice in practice: >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ >> Several popular recursive servers already implement the feature. >> Some of them even enable it by default. >> > > One of the main outstanding items on the "Stop! Hammer Time!" document > that we need to clean up the implementation section (Appendix A), but > it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND > 9.10 implement this. >From how I read the document and understand the implementations none of those implements the actual draft, but instead they have implementations that do some sort of prefetching. If that is the case you can add Nominum Cacheserve to the list, but I really think we should do some more general document describing prefetching as a concept and not just one way how to do it with a hammer ;-). So long -Ralf From nobody Wed Aug 16 01:18:19 2017 Return-Path: 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 2D499132641 for ; Wed, 16 Aug 2017 01:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 eMSmzBLGjKji for ; Wed, 16 Aug 2017 01:18:16 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83E713263F for ; Wed, 16 Aug 2017 01:18:15 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id t138so28613815wmt.1 for ; Wed, 16 Aug 2017 01:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HQwBA2Mis6buUM8zrxqtnP3PgX/qSIT6j5J/sOWkzt8=; b=p1+jRyHWHRccWlUhZiha+nK1shiuSf1KpJKTqfe6P8ksTLIoM4cMYCLUTS7BPd88fO d92ALgTrzk+MZNsV75Gmd+RDWizCs+LL7buJjoS/C4WOre1aAYxslDyN4U/+bBQX5vb7 FXWx/wX7toPz8qivQ12e2jV31wOOlqfzkEAuLo8PvHaxnbpbX+Uka98mOR7CJdEDyR5X w9d40RWEVeuCsCvU4NNZQeaNOPGBKql/6XGDiG4qi3tE/295Uymhf7M9dNL1b0AuWi5p sYxITxTD0amm31J+wMeDL3p9Yh/XaPuUWCGvpOj1eAt/K3l3mKrfHYFd2JMlMrXAwDyg mfGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HQwBA2Mis6buUM8zrxqtnP3PgX/qSIT6j5J/sOWkzt8=; b=i0+6q2tM/NATCrUHQm6edaanzvwYFk+CSQ/SiG4Nm/0jUIRjW9VOcPKyqzYvaX8IVE fni4dSWYVeCdiLWDGzCap+kp82dmUOsTAYvpWdQt1YbE0I6CYwo6w4q0aREu2A79qsrn Unzm4jCfeqS1OfB0Ath5/Vt8Daxbhx+PZYDmpQTbTmDTdS8Bu8E6EpSlThv97uRBih0p Xuj5/f66/ZJj/yDeKlBgxEqA3httLu3Melze4bV4Akf+pNPsb3FPIueDyU/2As/1MymC t04ihrIWxD+34feHCXH5Y4EisTB9Wd6bAr7WpI2ohAgEv1v37bHlWSGZR+gLcR14LVRM 3Tgg== X-Gm-Message-State: AHYfb5j2RDAbxbCdKUU2b8C/O7hijHyKo7ykWexwPWj56+2ZIhZOZ4/7 RKx4Apj6SxlnpyXa1W30e4LqfT7jAw== X-Received: by 10.80.216.206 with SMTP id y14mr1214077edj.165.1502871494389; Wed, 16 Aug 2017 01:18:14 -0700 (PDT) MIME-Version: 1.0 References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> In-Reply-To: <20170816054539.GA12897@jurassic> From: Lanlan Pan Date: Wed, 16 Aug 2017 08:18:03 +0000 Message-ID: To: Mukund Sivaraman , Matthew Pounsett Cc: dnsop , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Content-Type: multipart/alternative; boundary="089e08222db490f5e60556da89eb" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 08:18:18 -0000 --089e08222db490f5e60556da89eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mukund Sivaraman =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5= =E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=881:45=E5=86=99=E9=81=93=EF=BC=9A > On Fri, Aug 11, 2017 at 10:39:50AM -0400, Matthew Pounsett wrote: > > It sounds like you're assuming that SWILD would be supported by caching > > servers that do not support DNSSEC or NSEC aggressive use. Why do you > > expect implementers would adopt SWILD before adopting these much older > > features? > > (Without commenting about SWILD) > > It does not have to be due to implementation support alone. Many > operators stick to unsigned zones. There are many reasons, some of which > I'd mentioned in the unsigned NSEC thread. Resolvers have to deal with > cache pollution and unnecessary upstream queries, but they have no > control over whether the authoritative zones are signed. > > 2 mails up this thread, there is a comment about "New features are > provided only by the latest version of the protocol." This seems to mix > unrelated things together. The latest version of DNS (if there's such a > thing) doesn't mandate operational use of DNSSEC. Use of unsigned zones > is not obsolete and may well outlive us. Most zones today are unsigned > and a carrot like NSEC agressive use is unlikely to change the level of > adoption of DNSSEC significantly. > +1 DNS Poison Attack risk such as Brazilian Bank Targeted By Phishing Site And DNS Poisoning is the greatest motivation to deploy DNSSEC. > > Alexa Top domains and DNSSEC: > > 24 / 500 top domains (4.8%) > 20548 / 1 million top domains (2.05%) > > (12 years after introduction of 403{3,4,5}) > > Mukund > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --089e08222db490f5e60556da89eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Mukund= Sivaraman <muks@isc.org>=E4=BA= =8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=881= :45=E5=86=99=E9=81=93=EF=BC=9A
On F= ri, Aug 11, 2017 at 10:39:50AM -0400, Matthew Pounsett wrote:
> It sounds like you're assuming that SWILD would be supported by ca= ching
> servers that do not support DNSSEC or NSEC aggressive use.=C2=A0 Why d= o you
> expect implementers would adopt SWILD before adopting these much older=
> features?

(Without commenting about SWILD)

It does not have to be due to implementation support alone. Many
operators stick to unsigned zones. There are many reasons, some of which I'd mentioned in the unsigned NSEC thread. Resolvers have to deal with<= br> cache pollution and unnecessary upstream queries, but they have no
control over whether the authoritative zones are signed.

2 mails up this thread, there is a comment about "New features are
provided only by the latest version of the protocol." This seems to mi= x
unrelated things together. The latest version of DNS (if there's such a=
thing) doesn't mandate operational use of DNSSEC. Use of unsigned zones=
is not obsolete and may well outlive us. Most zones today are unsigned
and a carrot like NSEC agressive use is unlikely to change the level of
adoption of DNSSEC significantly.
+1
DNS Poison Attack risk such as Braz= ilian Bank Targeted By Phishing Site And DNS Poisoning=C2=A0 is the gre= atest motivation to deploy DNSSEC.

Alexa Top domains and DNSSEC:

24 / 500 top domains (4.8%)
20548 / 1 million top domains (2.05%)

(12 years after introduction of 403{3,4,5})

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--089e08222db490f5e60556da89eb-- From nobody Wed Aug 16 01:22:29 2017 Return-Path: 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 45C2513264C for ; Wed, 16 Aug 2017 01:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 ufu-oVQSnQOV for ; Wed, 16 Aug 2017 01:22:26 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 9D83B132641 for ; Wed, 16 Aug 2017 01:22:26 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 7FF195F4044C; Wed, 16 Aug 2017 10:22:19 +0200 (CEST) Received: from [172.20.10.3] (tmo-108-211.customers.d1-online.com [80.187.108.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 511D75F4004A; Wed, 16 Aug 2017 10:22:16 +0200 (CEST) From: "Ralf Weber" To: "Lanlan Pan" Cc: "Ted Lemon" , "dnsop WG" Date: Wed, 16 Aug 2017 10:22:20 +0200 Message-ID: <949DA2AE-6E76-4F70-84EA-9864D0D2687C@fl1ger.de> In-Reply-To: References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 08:22:28 -0000 Moin! On 16 Aug 2017, at 6:19, Lanlan Pan wrote: > We analyzed our recursive query log, about 18.6 billion queries from > 12/01/2015 to 12/07/2015. > > We found about 4.7 Million temporary domains occupy the recursive's = > cache, > which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, > 360safedns, Cloudfront, Greencompute... > > Temporary Domain Names/ All Names: 41.7% > Queries for Temporary Domain Names/ All Queries: 0.12% So you are designing a protocol change for 0.12% of your queries? IMHO = not a good use of engineering time. > Details in: Dealing with temporary domain name issues in the DNS > > > > The operational problem is, subdomain wildcards waste recursive cache > capacity. Existing solution to the problem is not adequate in = > recursive > operating environment at present, because of low DNSSEC deployment. Sorry can't read that, but from the abstract and your emails I think the = main flaw in your thinking is that you want to cache all the records, = regardless of how often they are queried. That is not how caching resolvers work. = Records that are not used frequently and most of these signalling queries are one = time queries just expire from the cache, either by LRU mechanism or TTL. So long -Ralf From nobody Wed Aug 16 01:44:20 2017 Return-Path: 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 9CA8E132641 for ; Wed, 16 Aug 2017 01:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FWa5UzYWMnYB for ; Wed, 16 Aug 2017 01:44:18 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0C3132671 for ; Wed, 16 Aug 2017 01:44:18 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id u133so10013610vke.3 for ; Wed, 16 Aug 2017 01:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4guTfzsTZOoh33TzykX0yiSkvmaYHQdDXP6hw88Ezik=; b=eGm+jOYNXqx/3O++UqdS+9kFywWBp+lnUW9ZG8C70HJm7YAvhPUTQSa65aYZwTGTWN l1VRtxi2DmTIFk6n5loAuSBUuZ84UvA1qhXu3ccfhQvhuXY99BbUypnuDB7T/WqpWLHA CQnkz/xwtqCHGXfveNGppCxvD1zzZsaVFmxtYiZalnGgHMnUCHRO4HetUW+VytHBcq3T Ucvm8FRiIn0qwYhLQhoGj2oU45p7PCs/N8jtPR86Je3LPSxj3oR0PxgzBhFQNKN10tys vK9SwjxIcuRoS6Q5C7fjUB3e/vK1XEKTFz4GCjGaWLyqDta9HoUbqkV9yLg+biRHfkHz xO+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4guTfzsTZOoh33TzykX0yiSkvmaYHQdDXP6hw88Ezik=; b=GAnKUWWUD4OomyHZED0/+HyaWIR8XuOPcFqW2IK6Sre6Kl6eUWamh5XcugZTfuPsPS ZPCdXZWJS3+ktZBIZKyZtVkhiwBEu8Ub8WpZRc4OucAViwLcwjBJaPGPQvNsmrJuJc65 9E5kdrni3ZtB7sMk6j1rQbud2Rk9xxPAsZx2zncplShVHZ0oJSJlr1yptLYDs4Yw31yW k0+LBATMoL+ZqA1n14CNQKWb06PgYvGe1+VPfhhaiodgVQmqdUY7bx2jipVzlu3K1dov z4JzuTZ7Qfyejm3RRJYr1nCLVW/yw9xGtQ8bGc1L21lp7x20H+r3VccUR/h8r5jAFIDg ZDpg== X-Gm-Message-State: AHYfb5h7N2NKUNcOZJmYob64G1mFF+D7FNeh+cUDVSfH3/CIzxHY9UbK SripQMUxpm9UyEp5skgyhjDQ+03v7Q== X-Received: by 10.31.94.207 with SMTP id s198mr622627vkb.64.1502873057263; Wed, 16 Aug 2017 01:44:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.76 with HTTP; Wed, 16 Aug 2017 01:44:16 -0700 (PDT) In-Reply-To: <1659363.yAWSxLQAC2@tums.local> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> From: Davey Song Date: Wed, 16 Aug 2017 16:44:16 +0800 Message-ID: To: Paul Vixie , Lanlan Pan Cc: dnsop Content-Type: multipart/alternative; boundary="001a114e5108b886c80556dae6bc" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 08:44:20 -0000 --001a114e5108b886c80556dae6bc Content-Type: text/plain; charset="UTF-8" On 12 August 2017 at 23:42, Paul Vixie wrote: > > > failing that level of commitment, the IETF ought to kill DNSSEC altogether. > > this is very similar to the "shall we had IPv6's features to IPv4, since > V6 is > taking so long to deploy, and these features are badly needed?" debate. > > +1. If any operator would like to implement SWILD without DNSSEC or NAT44 without IPv6, It's OK. It maybe a good solution in their network for their custormer. I do know many people and solutions walk around DNSSEC, IPv6 (due to IPsec) and TLS for surveillance issues. But IETF as a worldwide standard body has its position on the technical path towards a better Internet. Davey --001a114e5108b886c80556dae6bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 August 2017 at 23:42, Paul Vixie <paul@redbarn.org>= wrote:


failing that level of commitment, the IETF ought to kill DNSSEC altogether.=

this is very similar to the "shall we had IPv6's features to IPv4,= since V6 is
taking so long to deploy, and these features are badly needed?" debate= .


+1.=C2=A0=C2= =A0 =C2=A0 =C2=A0

If any operator would lik= e to implement=C2=A0SWILD without DNSSEC o= r NAT44 without IPv6, It's OK. It maybe a good solution in their networ= k for their custormer. I do know many people and solutions walk around=C2= =A0DNSSEC, IPv6 (due to IPsec) and TLS for surveillance=C2=A0issues. But=C2= =A0IETF as a worldwide standard bod= y has its position on the technical path towards a better Internet.<= /div>

Davey

--001a114e5108b886c80556dae6bc-- From nobody Wed Aug 16 01:54:24 2017 Return-Path: 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 A93C61323C8 for ; Wed, 16 Aug 2017 01:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 OHFy5dj_BC9p for ; Wed, 16 Aug 2017 01:54:20 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03EFB132670 for ; Wed, 16 Aug 2017 01:54:19 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id m85so25419298wma.0 for ; Wed, 16 Aug 2017 01:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3Sndjr6sgMK86FuhdPdWgxAX3UaAOzZqXzS3lkLUcps=; b=V5S7BrESIdAWx7k5ohkGfv1cZqJsE6Ym5LNhT0nlsbD8QWKpuUg1bwdItAnUU42idN QsEJ8hlUzkmahb6nvt4Vybn90XUSiYeCnx1G6YlYiIDsdCAK/VUnDpBp8Y7OBYUxWLBd F9PcUiIsui/FNSB4EkW54WAI1vrvNSDF+1XriEBmLHD8sytgMgTJxbngEe3YmnKYqopq FuL8k8Yfbe7/bXpuuRDAKgE/e8PoRM/2VaPbFTWzFEGIeQot2FMdh+tzzEpIXYQDZd5m Z5/6QJy2E88KmaWdiahRK+itBFqqmxn0rnqPp+YcaXkWOIcI4hFC0Kjt211eDoBgVrzj UDpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3Sndjr6sgMK86FuhdPdWgxAX3UaAOzZqXzS3lkLUcps=; b=EyvVoc32UVjmv2rrfhkyKphnWcqellMtgPCEyZ4XAD0Jk0j99/m6UPqwnfCAqk4PEV W1LxWIMWAXyH0ylMsAcb0ge0oVMbt5IDuC0t6QXh7OYMVQQLOD97liF2c5MA63HKTNZx oDqT+/v0MHAyPWJP3eo9TE5R14EbKgqq1QLNy8cmXpqneySMN/TZEY7LIAYDSSHs4n9i bnVRc/S7qPFBl+H47vdHKof6+BnoF+5aWYglD3r4DWMpxLoDyUHrVq14mfRo2pAWMpgm /wDOf8LU8+x7u0jzxN9DBp93t0lSq0DAznm0R8jG6oII02Z/5zEk9mcD3wi3VDlEQ/LD V0Tw== X-Gm-Message-State: AHYfb5hyLdiroXjndIVUnD/NiJzx+p9dUdqLT5OXk1rPot5IbaNgVUWB gwFTOvOefIupp6DZz+WtHWHN1Mx/pG8ktNM= X-Received: by 10.80.146.5 with SMTP id i5mr1335682eda.48.1502873658525; Wed, 16 Aug 2017 01:54:18 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <949DA2AE-6E76-4F70-84EA-9864D0D2687C@fl1ger.de> In-Reply-To: <949DA2AE-6E76-4F70-84EA-9864D0D2687C@fl1ger.de> From: Lanlan Pan Date: Wed, 16 Aug 2017 08:54:07 +0000 Message-ID: To: Ralf Weber Cc: Ted Lemon , dnsop WG Content-Type: multipart/alternative; boundary="f403045c0c468f12310556db0a72" Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 08:54:23 -0000 --f403045c0c468f12310556db0a72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ralf Weber =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91= =A8=E4=B8=89 =E4=B8=8B=E5=8D=884:22=E5=86=99=E9=81=93=EF=BC=9A > Moin! > > On 16 Aug 2017, at 6:19, Lanlan Pan wrote: > > > We analyzed our recursive query log, about 18.6 billion queries from > > 12/01/2015 to 12/07/2015. > > > > We found about 4.7 Million temporary domains occupy the recursive's > > cache, > > which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, > > 360safedns, Cloudfront, Greencompute... > > > > Temporary Domain Names/ All Names: 41.7% > > Queries for Temporary Domain Names/ All Queries: 0.12% > So you are designing a protocol change for 0.12% of your queries? IMHO > not a > good use of engineering time. > The temporary domain name's rate > 40%. Every xxx/yyy/zzz.foo.com query must be sent to Authoritative Nameserver for the subdomain wildcard same answer, we can try to reduce this cost, and shorten the response laterncy. > > Details in: Dealing with temporary domain name issues in the DNS > > < > https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.= html > > > > > > < > https://www.computer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.= html > > > > The operational problem is, subdomain wildcards waste recursive cache > > capacity. Existing solution to the problem is not adequate in > > recursive > > operating environment at present, because of low DNSSEC deployment. > Sorry can't read that, but from the abstract and your emails I think the > main > flaw in your thinking is that you want to cache all the records, > regardless of > how often they are queried. That is not how caching resolvers work. > Records that > are not used frequently and most of these signalling queries are one > time queries > just expire from the cache, either by LRU mechanism or TTL. > Yes, LRU and TTL can expire from the cache, which were also discussed in the paper. Recursives commonly cache "all queried domain in n days" for some SERVFAIL/TIMEOUT condition, which has been documented in https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01 The subdomain wildcards cache are needlessly, and we can make some optimization. > So long > -Ralf > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c0c468f12310556db0a72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Ralf W= eber <dns@fl1ger.de>=E4=BA=8E201= 7=E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=884:22=E5= =86=99=E9=81=93=EF=BC=9A
Moin!
On 16 Aug 2017, at 6:19, Lanlan Pan wrote:

> We analyzed our recursive query log, about 18.6 billion queries from > 12/01/2015 to 12/07/2015.
>
> We found about 4.7 Million temporary domains occupy the recursive'= s
> cache,
> which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft,
> 360safedns, Cloudfront, Greencompute...
>
> Temporary Domain Names/ All Names: 41.7%
> Queries for Temporary Domain Names/ All Queries: 0.12%
So you are designing a protocol change for 0.12% of your queries? IMHO
not a
good use of engineering time.

The tempo= rary domain name's rate > 40%.

Every x= xx/yyy/zzz.foo.com query must be sent to= Authoritative Nameserver for the subdomain wildcard same answer, we can tr= y to reduce this cost, and shorten the response laterncy.

> Details in: Dealing with temporary domain name issues in the DNS
> <https://www.co= mputer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>
>
> <https://www.co= mputer.org/csdl/proceedings/iscc/2016/0679/00/07543831-abs.html>
> The operational problem is, subdomain wildcards waste recursive cache<= br> > capacity. Existing solution to the problem is not adequate in
> recursive
> operating environment at present, because of low DNSSEC deployment. Sorry can't read that, but from the abstract and your emails I think th= e
main
flaw in your thinking is that you want to cache all the records,
regardless of
how often they are queried. That is not how caching resolvers work.
Records that
are not used frequently and most of these signalling queries are one
time queries
just expire from the cache, either by LRU mechanism or TTL.

Yes, LRU and TTL can expire from the cache, which were= also discussed in the paper.

Recursives commonly = cache "all queried domain in n days" for some SERVFAIL/TIMEOUT co= ndition, which has been documented in https://tools.ietf.org/html/draft-tale-d= nsop-serve-stale-01
The subdomain wildcards cache are needles= sly,=C2=A0 and we can make some optimization.


So long
-Ralf
--
=E8=87=B4=E7= =A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanl= an
--f403045c0c468f12310556db0a72-- From nobody Wed Aug 16 02:35:32 2017 Return-Path: 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 B77C4132025 for ; Wed, 16 Aug 2017 02:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 mqLovmbX-M3u for ; Wed, 16 Aug 2017 02:35:28 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55EAD1200B9 for ; Wed, 16 Aug 2017 02:35:28 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id d124so10378590vkf.2 for ; Wed, 16 Aug 2017 02:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xgQJyD4dsFpHYZI5Jl9J25PwLf8JpETLccejI0gRPfE=; b=DcU8RDbzwtvqvfnVRToGesalqoEh5ZDe2nE3dFh+JCFJF62p7y9pTdRKcjaZ6qPG1J AgnLRL8ead/hvJLOUvKvd8oTS5g0bO4u5omDvzCYULja2/Ha02aKKYvrfL0fh60jV6SJ KLa24WzjByRjMuxqn6JnYGoJkfGnzOEILLOUYJG7+J7Uyho+AjQfFZjh+E1SYfbQ2qWF xwx7k9x7xg7tNhwdmezdypp9BqLmG+vUzqieIOncqDHihjWoiwHhX5j2xtjsnCmnhHXl Ao7pd2jEtXMdEAJOOSCtvi1cw3sSfnf8eLRtAIo4bO/Ez9jxhMofuYkzR4cxnqPJrQKL JW4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xgQJyD4dsFpHYZI5Jl9J25PwLf8JpETLccejI0gRPfE=; b=fia+WwezQSfLL5QujAho5kksIAioBRfpjZjO9ChXZTCrFPLeI0HxvbCeKTqkoOse06 bQnsT7j6VgePGXD8pbKKrQDNt0/CqqkQF3DWJZnCmSHj5W5uVk5Lx7bJbDpArukoJtW4 lNpttEhJIwNJ/aIVCVyKC6Nhq31ECkZiNZwRPWvy3gh3BV4ADX1XmE92FXjFrBkHw8UT NWh0NBcrulI1ltztydMswAz5MOWsz3SsZ75SbUbANndP7o8xjKtRBE7kC9KmNEESzSer Wm2rPLUexaxDKkCjUapgi+7JZxvXxhIzq0CdLh+7W5PVy6L1zsqgKMKH2shBfm850YnJ PbGA== X-Gm-Message-State: AHYfb5jRuQZOiQYVDQd7rPMTB/H49/Owpxz6njW4+cdB+sHPo/Ijc6lr oxduvIcBMD9PO1v9yNJnh3UI8uHqLw== X-Received: by 10.31.226.1 with SMTP id z1mr666779vkg.65.1502876127470; Wed, 16 Aug 2017 02:35:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.28.76 with HTTP; Wed, 16 Aug 2017 02:35:26 -0700 (PDT) In-Reply-To: <20170816064855.GB16977@jurassic> References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> From: Davey Song Date: Wed, 16 Aug 2017 17:35:26 +0800 Message-ID: To: Mukund Sivaraman Cc: Mikael Abrahamsson , dnsop Content-Type: multipart/alternative; boundary="001a114e020cb82bb10556db9d3b" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 09:35:31 -0000 --001a114e020cb82bb10556db9d3b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Accroding to your description, I feel that IPv6 has better chance to win than its "brother" DNSSEC. LoL On 16 August 2017 at 14:48, Mukund Sivaraman wrote: > On Wed, Aug 16, 2017 at 08:21:37AM +0200, Mikael Abrahamsson wrote: > > On Wed, 16 Aug 2017, Mukund Sivaraman wrote: > > > > > 24 / 500 top domains (4.8%) > > > 20548 / 1 million top domains (2.05%) > > > > > > (12 years after introduction of 403{3,4,5}) > > > > https://stats.labs.apnic.net/dnssec/XE?o=3DcXAw1x1g1r1 > > > > 20% of European users is behind a validating resolver, in some countrie= s > > it's 70% plus. > > > > So this is now happening, albeit at a not high enough pace. But at leas= t > > it's going in the right direction, and I do believe that there is enoug= h > > people behind validating resolvers that people can't mess up signing > their > > zone and push away blame on who needs to fix things. > > > > So at least there is benefit in signing your zone now, there wasn't as > much > > before when nobody was validating. > > The validating resolver is half of the system. > > DNSSEC is brittle. It has an all-or-nothing behavior (that's what it was > designed for) that many businesses cannot afford to bank on if something > were to go wrong. An administrative error or signer software bug on the > authoritative side can take the whole zone down and every service with > it (as DNS is at the head of network activity). Software is still not > perfect, so I don't know how this can change - I see practical signer > bugs still that take down the zone entirely. It's also still painfully > inconvenient to update parent zones, that makes fixing mishaps > difficult. The amount of damage that a break in DNSSEC validation chain > could do is far greater than other implementations of crypto such as TLS > where it is limited to a service. > > (Note that I'm not advocating against DNSSEC, as much as this email may > sound so. The things I mention are practical issues that I see as an > implementor.) > > A colleague says "If TLD=E2=80=99s allowed UPDATE messages to be processe= d most > of the issues with DNSSEC would go away. At the moment we have a whole > series of kludges because people are scared of signed update messages." > > Mukund > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --001a114e020cb82bb10556db9d3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Accroding to your description, = I feel that IPv6 has better chance to win than its "brother" DNSS= EC. LoL

On 1= 6 August 2017 at 14:48, Mukund Sivaraman <muks@isc.org> wrote:
On Wed, Aug 16, 2017 at 08= :21:37AM +0200, Mikael Abrahamsson wrote:
> On Wed, 16 Aug 2017, Mukund Sivaraman wrote:
>
> > 24 / 500 top domains (4.8%)
> > 20548 / 1 million top domains (2.05%)
> >
> > (12 years after introduction of 403{3,4,5})
>
> https://stats.labs.apnic.net/dnssec/= XE?o=3DcXAw1x1g1r1
>
> 20% of European users is behind a validating resolver, in some countri= es
> it's 70% plus.
>
> So this is now happening, albeit at a not high enough pace. But at lea= st
> it's going in the right direction, and I do believe that there is = enough
> people behind validating resolvers that people can't mess up signi= ng their
> zone and push away blame on who needs to fix things.
>
> So at least there is benefit in signing your zone now, there wasn'= t as much
> before when nobody was validating.

The validating resolver is half of the system.

DNSSEC is brittle. It has an all-or-nothing behavior (that's what it wa= s
designed for) that many businesses cannot afford to bank on if something were to go wrong. An administrative error or signer software bug on the
authoritative side can take the whole zone down and every service with
it (as DNS is at the head of network activity). Software is still not
perfect, so I don't know how this can change - I see practical signer bugs still that take down the zone entirely. It's also still painfully<= br> inconvenient to update parent zones, that makes fixing mishaps
difficult. The amount of damage that a break in DNSSEC validation chain
could do is far greater than other implementations of crypto such as TLS where it is limited to a service.

(Note that I'm not advocating against DNSSEC, as much as this email may=
sound so. The things I mention are practical issues that I see as an
implementor.)

A colleague says "If TLD=E2=80=99s allowed UPDATE messages to be proce= ssed most
of the issues with DNSSEC would go away. At the moment we have a whole
series of kludges because people are scared of signed update messages."= ;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mukund

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

--001a114e020cb82bb10556db9d3b-- From nobody Wed Aug 16 03:01:13 2017 Return-Path: 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 1BF4A132076 for ; Wed, 16 Aug 2017 03:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 xNy_IPy3myp1 for ; Wed, 16 Aug 2017 03:01:09 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 8A14D13232C for ; Wed, 16 Aug 2017 03:01:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4BDEAAF; Wed, 16 Aug 2017 12:01:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1502877663; bh=2uUvPd9ix111sHgQ/3UastILYj+wCuvrPsem5+nXfk4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=tWPKr4LryuZhT6Qh6ql6I9LrphONLuCeWzSkeufh6L6gx+XR2d0Iilfk6ngtWvigy fVrI3EFt31zjDLOquxeIDa5VOr6DP0L8YAWNhdVu06k3GKIQvevsdZkL8PDPgQqyA4 1v94I2hR0r8sW19Tu71ghTbZ5vvQlxaDMOw+uykw= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3307F84; Wed, 16 Aug 2017 12:01:03 +0200 (CEST) Date: Wed, 16 Aug 2017 12:01:03 +0200 (CEST) From: Mikael Abrahamsson To: Davey Song cc: Mukund Sivaraman , dnsop In-Reply-To: Message-ID: References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1197245d-6b9a-3c3b-82a0-dc6a1cc3de58@nic.cz> <20170816054539.GA12897@jurassic> <20170816064855.GB16977@jurassic> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 10:01:12 -0000 On Wed, 16 Aug 2017, Davey Song wrote: > Accroding to your description, I feel that IPv6 has better chance to win > than its "brother" DNSSEC. LoL Currently they're both winning, and in kind of the same fashion. https://www.google.com/intl/en/ipv6/statistics.html Clients are sitting behind DNSSEC validating resolvers, but there are few zones to validate (apart from in a few markets, like .se and .cz). Clients are more and more getting IPv6 enabled, but the long tail content is not being enabled, and neither is the enterprise. So generally, enterprise is problematic in both spaces. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Aug 16 03:18:13 2017 Return-Path: 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 56170132076 for ; Wed, 16 Aug 2017 03:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 yDQxoV6q8tE3 for ; Wed, 16 Aug 2017 03:18:09 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBD013207A for ; Wed, 16 Aug 2017 03:18:08 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x191so17421724qka.5 for ; Wed, 16 Aug 2017 03:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NCOFrqmk5EelY3eCJgguUSsJ/V2Mqtz8F3aqn8votE0=; b=sVOEUaXT6py6mmWapAMFz1W7mqS/ywOQGUubgray9cv6n0/re8Txufj+ktRUHedzP8 hQkkuen1olF7KIMnUmsAY0XCmXrs+/74sZBKpZX1JGucXLO4XEX9s3qFpM0nzVu22Uu4 FwdUnC3WcvC5s57sW3e3+PeIhy8Z2jQ+bZRay8EpbK60kTvshcpg+KkUuOd1gt/MMoh3 +G7gPyenrJhyvlvxvLyYe10/ygQcaam0Wqv50de6H+OwNYg+DN9sAjteQatPrynh8BMs iYtYWWADIhAmloI/2X3mdWkL9f6tJK6dvw+39g0rhsf6+sZSplLXfe7WejcyVyIPGZVO tZtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NCOFrqmk5EelY3eCJgguUSsJ/V2Mqtz8F3aqn8votE0=; b=DKS3Btw+7pNY2Mpl4w68/73nuarxx8y6yWx4BDYyxyvnhev7VNf027D3wIeERZbJp6 MhT5XCnNaE/ot3RTLxSP4bAmvHUVgr7uUnEecXKCedyXmPsUBZ+gAgs9ReFF22bPL3IM 7v0KjHkhbI8wZ3ZZob0z/3p4rvW4nxwGuSI1yVSR/sgPJrhwOVSQhflI/BmbgVr48Psm w4DZVLOEj3IyXjQYWhxWU+tdl/IZzN5ue++zZYVDMNoyoRavccMaH9RjJJnBYpKBDNBo yaQArQ7cxcCFhkZ7bkdNLahF3AQg7HUDSeOHYX6+DUZ8NYf9fcIwRGNDoFenl/+Fa8ql fIzw== X-Gm-Message-State: AHYfb5iO/70IVvZLiMxg1L9QzePCfTxJtWtTPF5FuKotplOcQoSz4TE3 vAgyI8CUSMAUKCc2SJeWrm/yb+5XkKp9zQiBLg== X-Received: by 10.55.16.34 with SMTP id a34mr1464624qkh.124.1502878687655; Wed, 16 Aug 2017 03:18:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.25.236 with HTTP; Wed, 16 Aug 2017 03:17:46 -0700 (PDT) In-Reply-To: <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com> References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com> From: Mike West Date: Wed, 16 Aug 2017 12:17:46 +0200 Message-ID: To: Ted Lemon Cc: dnsop , Tony Finch , Mark Andrews Content-Type: multipart/alternative; boundary="001a11475f3851f0680556dc36fc" Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 10:18:12 -0000 --001a11475f3851f0680556dc36fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 14, 2017 at 4:36 PM, Ted Lemon wrote: > This doesn't actually address my concerns. Sorry to be a sticky wicket. > Here is what I think the text should say: > > [Snipping suggested diffs] > These suggestions seem pretty reasonable, thank you for spending the time writing them up. I've queued these up for an eventual -06 in https://github.com/mikewest/internetdrafts/commit/10274f38ef92edcc2c9f4083e= ad7e49ccc926508#diff-a9d272c9ebfa20da41c3000f869001a4 . > On the topic of DNSSEC, the root currently returns a secure denial of > existence. This is exactly right=E2=80=94there's no reason to change it= . > 1. I agree with you. 2. I know I don't have enough expertise in this area to make an informed decision, and smart folks on this thread and elsewhere have told me that an insecure delegation would be better than status-quo. I added https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05#sectio= n-4.2 to the document on that basis. I'm happy to accept the group consensus on this point, one way or the other. :) > You need a security considerations section. I suggest the following: > > --- > Some applications may consider it useful to treat a connection to an > endpoint on the same host as more trustworthy than a connection to other > endpoints. This assumption is not entirely safe=E2=80=94it is possible = for > example that an application that is sandboxed could still listen for > connections from the local host, and thereby present a security > vulnerability to other applications that mistakenly assume that some othe= r > service is listening for connections on that port. A similar risk can be > present for a sandboxed application connecting to localhost if the local > host is infected by malware that listens on a particular local port. Su= ch > situations may be considered out of scope, however, in the sense that if > malware is running on the local host, it may have easier opportunities fo= r > attack than listening for connections on a local port. The sandbox > example is mentioned because malware that successfully attacks a sandboxe= d > application may still be contained in the sandbox; trusting localhost in > this case could penetrate that protection. > > Applications that attempt to use the local resolver to query "localhost" > do not fail safe: if an attacker sets up a DNS server returning a non-loc= al > answer for "localhost," such applications will connect to that remote > server assuming it is local. This is the reason for the requirement tha= t > applications using "localhost" process it specially, rather than relying = on > the local resolver. > > There may be cases where the target runtime environment is such that it > can be safely assumed that the local resolver does the right thing; in th= is > case the requirement that the application do the translation on its own m= ay > be safe to ignore, but only if all of the requirements under point 2 of > section 3 are known to be followed by the resolver that is known to be > present in the target runtime environment. > --- > > The first paragraph is rather tendentious. My reason for presenting it > is not to claim that you should put that exact text in the security > considerations section, but rather to suggest that this is possibly > something that the working group should consider doing In the commit linked above, I've adopted the second and third paragraphs with minor wording changes. It's not really clear to me where the crux of the first paragraph lies. IMO, malware is pretty clearly out of scope for software's security decisions, as anything running on the local machine with privilege equal to (or exceeding!) your own is basically impossible to defeat. Are there scenarios in which you think that's not the case, at least insofar as this draft is concerned? if the document is adopted, as seems likely. Given the level of interest in the document, I do hope that the group would decide to adopt it. :) That said, it's not clear to me what the next steps might be here. My personal opinion is that trusting localhost is a bad idea, but I realize > that this may not be the consensus. Do you believe that trusting `127.0.0.1` is less risky? It seems to be less risky today, and part of the goal of this draft is to bring localhost names into line with the security properties that hard-coded loopback addresses provide. -mike --001a11475f3851f0680556dc36fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 14, 2017 at 4:36 PM, Ted Lemon <mellon@fugue.com> wro= te:
This doesn't a= ctually address my concerns.=C2=A0 =C2=A0Sorry to be a sticky wicket.=C2=A0= =C2=A0Here is what I think the text should say:

[Snipping suggested diffs]

These su= ggestions seem pretty reasonable, thank you for spending the time writing t= hem up. I've queued these up for an eventual -06 in=C2=A0https://github.com/mike= west/internetdrafts/commit/10274f38ef92edcc2c9f4083ead7e49ccc926508#diff-a9= d272c9ebfa20da41c3000f869001a4.
=C2=A0
On the topic of DNSSEC, the root currently= returns a secure denial of existence.=C2=A0 =C2=A0This is exactly right=E2= =80=94there's no reason to change it.

1.=C2=A0 I agree with you.

2.=C2=A0 I know I do= n't have enough expertise in this area to make an informed decision, an= d smart folks on this thread and elsewhere have told me that an insecure de= legation would be better than status-quo. I added=C2=A0ht= tps://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05#section-= 4.2 to the document on that basis.

I'm hap= py to accept the group consensus on this point, one way or the other. :)
=C2=A0
You n= eed a security considerations section.=C2=A0 =C2=A0I suggest the following:=

---
Some applications may consider it useful to treat a connection to an endpoi= nt on the same host as more trustworthy than a connection to other endpoint= s.=C2=A0 =C2=A0This assumption is not entirely safe=E2=80=94it is possible = for example that an application that is sandboxed could still listen for co= nnections from the local host, and thereby present a security vulnerability= to other applications that mistakenly assume that some other service is li= stening for connections on that port.=C2=A0 A similar risk can be present f= or a sandboxed application connecting to localhost if the local host is inf= ected by malware that listens on a particular local port.=C2=A0 =C2=A0Such = situations may be considered out of scope, however, in the sense that if ma= lware is running on the local host, it may have easier opportunities for at= tack than listening for connections on a local port.=C2=A0 =C2=A0The sandbo= x example is mentioned because malware that successfully attacks a sandboxe= d application may still be contained in the sandbox; trusting localhost in = this case could penetrate that protection.

Applications that attempt to use the local resolver to query "localhos= t" do not fail safe: if an attacker sets up a DNS server returning a n= on-local answer for "localhost," such applications will connect t= o that remote server assuming it is local.=C2=A0 =C2=A0This is the reason f= or the requirement that applications using "localhost" process it= specially, rather than relying on the local resolver.

There may be cases where the target runtime environment is such that it can= be safely assumed that the local resolver does the right thing; in this ca= se the requirement that the application do the translation on its own may b= e safe to ignore, but only if all of the requirements under point 2 of sect= ion 3 are known to be followed by the resolver that is known to be present = in the target runtime environment.
---

The first paragraph is rather tendentious.=C2=A0 =C2=A0My reason for presen= ting it is not to claim that you should put that exact text in the security= considerations section, but rather to suggest that this is possibly someth= ing that the working group should consider doing

In the commit linked above, I've adopted the second and third par= agraphs with minor wording changes. It's not really clear to me where t= he crux of the first paragraph lies. IMO, malware is pretty clearly out of = scope for software's security decisions, as anything running on the loc= al machine with privilege equal to (or exceeding!) your own is basically im= possible to defeat. Are there scenarios in which you think that's not t= he case, at least insofar as this draft is concerned?

if the document is ado= pted, as seems likely.
=C2=A0
Given the level of= interest in the document, I do hope that the group would decide to adopt i= t. :) That said, it's not clear to me what the next steps might be here= .

My = personal opinion is that trusting localhost is a bad idea, but I realize th= at this may not be the consensus.

Do you b= elieve that trusting `127.0.0.1` is less risky? It seems to be less risky t= oday, and part of the goal of this draft is to bring localhost names into l= ine with the security properties that hard-coded loopback addresses provide= .

-mik= e
--001a11475f3851f0680556dc36fc-- From nobody Wed Aug 16 05:54:35 2017 Return-Path: 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 777F813219C for ; Wed, 16 Aug 2017 05:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 WJxWdUEyso9M for ; Wed, 16 Aug 2017 05:54:31 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1161321A2 for ; Wed, 16 Aug 2017 05:54:31 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d145so19509406qkc.2 for ; Wed, 16 Aug 2017 05:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=TLOB2Fm0zWkNQr0h9V6gl2oqE+pWukkMU6JeWDjxU0I=; b=FtF06NaXtmhDC+jJ9YaOOf0ebQ3MjQggqMfMkIQ1OJzF9WiFi119kRBrO5dPLXJA8p LugzxEIfNmRjeAI+9ccfz5jB55JpmstlM9L+/mYv1EH/8HQd0QCnvrDFvltllSOWjYoj AsBOYugH82lvACBHPo4+mF7fT3iEtRweUbaIPEyElmZQWofZ7M7xSsJjbPDOlN27hYFk 734Cd78ZfLyZYNKtQPiMHFkpe4645K+S4GqSXpm0iY60WNWiBiOqbbgqts/mvZdiCjDM sKE4QPHqoPwTuLTpENpPePTQgfvZZr2w13bGuSw6sDDjo6KxOHlMNrgXW55TAaWEXu72 BYgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=TLOB2Fm0zWkNQr0h9V6gl2oqE+pWukkMU6JeWDjxU0I=; b=Bi8tKCDGdo058fznFxnsPdfJ0zCWjUyT2FA7VQpCEiEZ6BIQaCzuA88YNr+y7mN7Cv IuxkucQkHZ7atWzc0J4wpnkyGWL1ZH9v6aRadYVbdt9ebWkJUWCsEmAwAnhzsX2vDOuS KAXcx4//6gsfLJmpm8UrnT8hfLCT3gE2jOYxORCcSAtRwQ+KL7GjD5IAe6fS6HfIZ9Pp YatAXLeK/LJyYypMWJ0QKKQpRAcf/2bN7U2KIet19ts6ixsxEiPmI8WM4sQ/XWhuzKch 0YZ0cCt66+M7qSyyfM4UL52xiew6Ry/NKUm9clgb+fz8+UDT8XVvu5qaVVEya8EUanNS 2/sQ== X-Gm-Message-State: AHYfb5j3kt4o5lZVNB4+WQXFce/e/sQsx7ptLFzRgLp1NlWS+M847kn7 +OzRDl+ILqDzVbYNUUWGQg== X-Received: by 10.55.23.5 with SMTP id i5mr2060567qkh.116.1502888070378; Wed, 16 Aug 2017 05:54:30 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id s36sm486707qts.77.2017.08.16.05.54.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 05:54:29 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_DB62EF6C-C356-497B-B21D-F8AE76FE54EE" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 08:54:28 -0400 In-Reply-To: Cc: dnsop WG To: Lanlan Pan References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 12:54:33 -0000 --Apple-Mail=_DB62EF6C-C356-497B-B21D-F8AE76FE54EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 16 ag 2017, a les 0:19, Lanlan Pan va escriure: > We analyzed our recursive query log, about 18.6 billion queries from = 12/01/2015 to 12/07/2015. > We found about 4.7 Million temporary domains occupy the recursive's = cache, which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, = 360safedns, Cloudfront, Greencompute... >=20 > Temporary Domain Names/ All Names: 41.7% >=20 > Queries for Temporary Domain Names/ All Queries: 0.12% Okay. So it sounds like you have an algorithm for detecting temporary = domain names. It seems to me that a quicker solution to your problem = is to publish an operational document describing that algorithm and = proposing ways that recursive caches can use it to prune such domains = from the cache early. I'm curious if you studied the behavior of existing recursive caches in = the presence of these domains: do they in fact cache at the rate you = predict they will? The reason I ask is that I know that my own = company's cache, which is widely deployed in the exact scenario you are = describing, has a pretty sophisticated set of heuristics for deciding = what to cache. It would surprise me if it exhibited the behavior you = are concerned about. BTW, your paper is behind a paywall, so please don't cite it as a reason = to do anything in the IETF. If you want the IETF to take action based = on what is in the paper, you need to publish it openly. --Apple-Mail=_DB62EF6C-C356-497B-B21D-F8AE76FE54EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 16 ag 2017, a les 0:19, Lanlan Pan <abbypan@gmail.com> = va escriure:
We = analyzed our recursive query log, about 18.6 billion queries from 12/01/2015 to 12/07/2015.

We found about 4.7 = Million temporary domains occupy the recursive's cache, which are = subdomain wildcards from Skype, QQ, Mcafee, Microsoft, 360safedns, = Cloudfront, Greencompute...

Temporary Domain = Names/ All Names: 41.7%

Queries = for Temporary Domain Names/ All Queries: = 0.12%

Okay. =   So it sounds like you have an algorithm for detecting temporary = domain names.   It seems to me that a quicker solution to your = problem is to publish an operational document describing that algorithm = and proposing ways that recursive caches can use it to prune such = domains from the cache early.

I'm curious if you studied the behavior = of existing recursive caches in the presence of these domains: do they = in fact cache at the rate you predict they will?   The reason I ask = is that I know that my own company's cache, which is widely deployed in = the exact scenario you are describing, has a pretty sophisticated set of = heuristics for deciding what to cache.   It would surprise me if it = exhibited the behavior you are concerned about.

BTW, your paper is behind a paywall, so = please don't cite it as a reason to do anything in the IETF.   If = you want the IETF to take action based on what is in the paper, you need = to publish it openly.

= --Apple-Mail=_DB62EF6C-C356-497B-B21D-F8AE76FE54EE-- From nobody Wed Aug 16 05:58:57 2017 Return-Path: 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 8C1B113219C for ; Wed, 16 Aug 2017 05:58:55 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 16Yw2MSNr2La for ; Wed, 16 Aug 2017 05:58:54 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040991326B0 for ; Wed, 16 Aug 2017 05:58:53 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id 16so20123072qtz.4 for ; Wed, 16 Aug 2017 05:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=w5GZyebJPLftskvpd0cOcbEEAB1cNYdXGepHDRuvClg=; b=poDDCR1OU6BZaNZl13ydLJ11xnYy8aOdR5ctBt16p4KbyaZI0tJjNqYDy52i2K0XI3 BgOzpeCwEt8CFLi3BESPYnTy5m5c6Xw/+IuXiYsLDWcCqh9fWTi5KW7EAEiT67NqRT8R 0mJ42WNA7WNsVy7Ky80f/UjCjtHWWOy97wX1Oy1dpdXTpdFfLp+OloLF7LwpOmydtX63 p3DTrLts9lNepTVZ5/qrC5cQtl0fFHvkoUiMJoYx8I0gL2F1B5wc0SD/HHup+Ui5RG6V yaAB2Z8DvHYBE046f/gC+/6pI1096SxbgUp70brgK30H7qU6OpaQdckrPfS8A4Ijcc9l 2LKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=w5GZyebJPLftskvpd0cOcbEEAB1cNYdXGepHDRuvClg=; b=MZlB3pDisytQfYYRl2n38aXefcEgAeBiNtFFrW/n/AXkqdl1NS1vl68T3avlcp8GgA Boh6nq/Y33WuQZz4+rXx5NuhKBp7aUX4vba1Rcvpc2jf/34dAIgqLTaA7YdvblBzT3Nw 9xVbejTuRfgx7cvTaHhz9rd5/WuA6ZcvD/hlcVHE4wgSrdm+pUSCbeugR2Kr9PjfomG9 n201tVhipngukWvBLuG3G2GOaPgVi+UW3LaxyxYn+AhrPex3gtyQhNYhGmU2mmglDKZS RVwK46aGX9PFk/SiGODKRYbnA9OAR7e88dCGwZ0qnuoQIKRfNVEuXkGpq3M4YoOtCDmQ VG8w== X-Gm-Message-State: AHYfb5g71dKKfEFtGSiDUzBhvU8O8fd25YhUT87kEEuyTBAyOjxkd9su zz+6j/bQJ3l53FUa X-Received: by 10.200.51.133 with SMTP id c5mr2285478qtb.51.1502888333061; Wed, 16 Aug 2017 05:58:53 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k74sm506666qkh.41.2017.08.16.05.58.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 05:58:52 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6977D51C-00B6-4337-B95E-2AA71607E1B8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 16 Aug 2017 08:58:51 -0400 In-Reply-To: Cc: dnsop , Tony Finch , Mark Andrews To: Mike West References: <20170812170958.14197.qmail@ary.lan> <4544C6A8-5591-454F-9E94-F3CADD3CDD2D@vpnc.org> <42C048AD-E5BC-4D13-BE26-F9ED5D049FC9@fugue.com> <3617BEAA-8DCE-4BB5-9408-3AA78E986F27@dotat.at> <198D730F-F932-4220-8CDF-106D6BC77AFF@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 12:58:56 -0000 --Apple-Mail=_6977D51C-00B6-4337-B95E-2AA71607E1B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 16 ag 2017, a les 6:17, Mike West va escriure: > In the commit linked above, I've adopted the second and third = paragraphs with minor wording changes. It's not really clear to me where = the crux of the first paragraph lies. IMO, malware is pretty clearly out = of scope for software's security decisions, as anything running on the = local machine with privilege equal to (or exceeding!) your own is = basically impossible to defeat. Are there scenarios in which you think = that's not the case, at least insofar as this draft is concerned? That's why I mentioned sandboxing. A process running on the local = host, inside a sandbox, listening on a local port, could be reachable by = processes that aren't sandboxed, or are running in other sandboxes. So = trusting localhost provides a way for a sandboxed process to screw you, = basically. I don't know how serious a threat this is, but I think the = idea that the set of trust zones on a single host is flat is not valid, = and that's why I actually don't think that, even with this document = published and in wide use, "localhost" should be considered trustworthy. A slightly less vulnerable approach would be to allow reserved ports on = localhost to be trusted, but to not trust other ports, on the basis that = something that can get a reserved port has privileges. This is still = questionable, since a trusted sandboxed app could be compromised, but = it's at least a smaller attack surface. --Apple-Mail=_6977D51C-00B6-4337-B95E-2AA71607E1B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 16 ag 2017, a les 6:17, Mike West <mkwst@google.com> va = escriure:
In the commit linked above, I've = adopted the second and third paragraphs with minor wording changes. It's = not really clear to me where the crux of the first paragraph lies. IMO, = malware is pretty clearly out of scope for software's security = decisions, as anything running on the local machine with privilege equal = to (or exceeding!) your own is basically impossible to defeat. Are there = scenarios in which you think that's not the case, at least insofar as = this draft is concerned?

That's why I mentioned sandboxing.   A = process running on the local host, inside a sandbox, listening on a = local port, could be reachable by processes that aren't sandboxed, or = are running in other sandboxes.   So trusting localhost provides a = way for a sandboxed process to screw you, basically.   I don't know = how serious a threat this is, but I think the idea that the set of trust = zones on a single host is flat is not valid, and that's why I actually = don't think that, even with this document published and in wide use, = "localhost" should be considered trustworthy.

A slightly less vulnerable approach = would be to allow reserved ports on localhost to be trusted, but to not = trust other ports, on the basis that something that can get a reserved = port has privileges.   This is still questionable, since a trusted = sandboxed app could be compromised, but it's at least a smaller attack = surface.

= --Apple-Mail=_6977D51C-00B6-4337-B95E-2AA71607E1B8-- From nobody Wed Aug 16 10:33:54 2017 Return-Path: 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 643A713234E for ; Wed, 16 Aug 2017 10:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 QykZNG1z1JeN for ; Wed, 16 Aug 2017 10:33:50 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 9F2AA132344 for ; Wed, 16 Aug 2017 10:33:50 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7GHXXVY028295 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Wed, 16 Aug 2017 17:33:33 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7GHXWwr028294 for dnsop@ietf.org; Wed, 16 Aug 2017 17:33:32 GMT Date: Wed, 16 Aug 2017 17:33:32 GMT From: Vernon Schryver Message-Id: <201708161733.v7GHXWwr028294@calcite.rhyolite.com> To: dnsop@ietf.org X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 17:33:52 -0000 > From: Paul Vixie > some time before bad people get around to using dnssec to bypass rpz, > the spec will have to evolve to allow new signalling ("i want to hear > both the truth and the lie, and please sign the lie with our shared key > so i'll know it's from you"). I disagree. The last year has shown there there is limited appetite in the IETF for RPZ work A second issue concerns the use and purpose of the DNS. No applications that are not DNS debugging or forensic tools want both DNS truth and lies. All ordinary applications want an IP address and sometimes application protocol data such as in SRV, MX, TLSA, and TXT. They don't want and generally can't deal with multiple answers, as demonstrated by the very few applications that look past the first IP address from gethostbyname() (or modern replacements) even when the first IP address fails. Except for debugging or forensic tools, the application code itself should not and even if the IETF says it should, will not care about more than the first usable DNS result. Users of applications might want either truth or RPZ lies, but not both except for debugging and forensics. Those user preferences can vary depending on the application. A user of ssh might want the truth, because ssh has its own authentication system that is more secure than DNSSEC. The same user might choose RPZ filtering for smtp and http. To facilitate such user choices, it would be good if applications could tell stubs to use an alternate /etc/resolv.conf. On the other hand, there is already signaling that provides both DNS truth and lies. A UNIX shell command like `alias honest "dig @8.8.8.8"` implements kludge "signaling" to get the DNS truth, while straight `dig` gets the possible lie. (Note that a single system can host both honest and RPZ resolvers. BIND with views can distiguish requests for truth from requests for lies with TSIG keys and answer appropriately. You can include TSIG keys in dig commands.) That kludge, dual-dig "signalling" would work with future RPZ installations with real "give me both" signaling, old RPZ installations, and covert DNS liars. Even if a future version of RPZ has real "give me both" signaling, you will always need and will reach first for dual digs. The SOA added by RPZ to the additional section is perfectly sufficient to signal the honest presence of an RPZ lie. Vernon Schryver vjs@rhyolite.com From nobody Wed Aug 16 11:44:58 2017 Return-Path: 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 A7027126B6E for ; Wed, 16 Aug 2017 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 TFE3jv4OJRGP for ; Wed, 16 Aug 2017 11:44:54 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1C1113237B for ; Wed, 16 Aug 2017 11:44:54 -0700 (PDT) Received: from [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c] (unknown [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BDECD61FF3; Wed, 16 Aug 2017 18:44:53 +0000 (UTC) Message-ID: <599492A3.6010604@redbarn.org> Date: Wed, 16 Aug 2017 11:44:51 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Davey Song CC: dnsop References: <149908054910.760.8140876567010458934.idtracker@ietfa.amsl.com> <1659363.yAWSxLQAC2@tums.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 18:44:56 -0000 Davey Song wrote: > If any operator would like to implement SWILD without DNSSEC or NAT44 > without IPv6, It's OK. It maybe a good solution in their network for > their custormer. I do know many people and solutions walk around DNSSEC, > IPv6 (due to IPsec) and TLS for surveillance issues. But IETF as a > worldwide standard body has its position on the technical path towards a > better Internet. agreed. and, see also: https://mailarchive.ietf.org/arch/msg/ietf-announce/ObCNmWcsFPNTIdMX5fmbuJoKFR8 noting that DNSSEC isn't a form of confidentiality, the general spirit of the IAB's position as linked above, supports a co-goal of end-to-end authenticity. i see no reason to expend community development effort, or to add complexity costs, on alternatives in whole or in part to DNSSEC, unless it's a complete replacement protocol, or complete abandonment of the goal itself. -- P Vixie From nobody Wed Aug 16 13:13:27 2017 Return-Path: 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 3072C1326DB for ; Wed, 16 Aug 2017 13:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 byBspUgkbI9v for ; Wed, 16 Aug 2017 13:13:24 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC761326E1 for ; Wed, 16 Aug 2017 13:13:24 -0700 (PDT) Received: from [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c] (unknown [IPv6:2602:306:8074:1ac0:8c44:219f:380c:bf7c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 4F4C561FF3; Wed, 16 Aug 2017 20:13:23 +0000 (UTC) Message-ID: <5994A761.8080009@redbarn.org> Date: Wed, 16 Aug 2017 13:13:21 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Vernon Schryver CC: dnsop@ietf.org References: <201708161733.v7GHXWwr028294@calcite.rhyolite.com> In-Reply-To: <201708161733.v7GHXWwr028294@calcite.rhyolite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 20:13:26 -0000 Vernon Schryver wrote: >> From: Paul Vixie > >> some time before bad people get around to using dnssec to bypass rpz, >> the spec will have to evolve to allow new signalling ("i want to hear >> both the truth and the lie, and please sign the lie with our shared key >> so i'll know it's from you"). > > I disagree. The last year has shown there there is limited appetite > in the IETF for RPZ work i think we have to keep trying until and unless the co-chair say to stop. > A second issue concerns the use and purpose of the DNS. No applications > that are not DNS debugging or forensic tools want both DNS truth and > lies. All ordinary applications want an IP address and sometimes > application protocol data such as in SRV, MX, TLSA, and TXT. ... well, yes, but a directive in /etc/resolv.conf saying what lies to trust, or whether to trust all of them, or whether to trust none of them, would be a way for a system operator or owner to set response policy for all applications. the resolver is a dns-aware application. > Users of applications might want either truth or RPZ lies, but not both > except for debugging and forensics. Those user preferences can vary > depending on the application. if an application wants a different kind of lies than is the default in /etc/resolv.conf, it will need API hooks to say so. i predict that the getdnsapi team would offer such hooks if there were an underlying protocol with knobs like that. obviously "dig" will always just print both the truth and the lies, and let /dev/stdout sort out the meaning. > On the other hand, there is already signaling that provides both DNS > truth and lies. A UNIX shell command like `alias honest "dig @8.8.8.8"` > implements kludge "signaling" to get the DNS truth, while straight > `dig` gets the possible lie. alas, this is unreliable. i've been hooked up to networks with policy at the IP layer causing 8.8.8.8 requests to be rerouted to a local DNS server with advertising (NXDOMAIN substitution) support. considering that google's original motive for creating the 8.8.8.8 service in the first place was that various rDNS services were giving locally-faked responses to "www.google.com/A", i think this shows the slipperiness of the slope, in neon glowing detail. > The SOA added by RPZ to the additional section is perfectly sufficient > to signal the honest presence of an RPZ lie. well, yes. but it may be the law of the land in some countries that citizens accept DNS lies, whereas foreign visitors can accept DNS truth. so i'd like the protocol to carry both (lies and truth), with policy-level digital signatures on the lies, to be sure they are coming from the place we're expecting our lies to come from. -- P Vixie From nobody Wed Aug 16 14:42:47 2017 Return-Path: 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 26900132743 for ; Wed, 16 Aug 2017 14:42:46 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 tam3PvLo50AZ for ; Wed, 16 Aug 2017 14:42:44 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F75132744 for ; Wed, 16 Aug 2017 14:42:41 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id x43so27708601wrb.3 for ; Wed, 16 Aug 2017 14:42:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QL3NGVOB6+JZ3ukxMkukBF9jEY+KnmO5ms9/toR+m6I=; b=Nf1tw/1RkjBDQ3cqDpVNKtNlcCmT/5iWpcudokJwlcQmMTLrJZTWTpfmDIJE/AO0fp y4eZjs+D92SkdxRMcnGSroxhKPA+zZf72A4NNuLw+hmOyvLW6v+zzlGTvsoebLdf/peu ykdDf/j4JEx1JfC8B6ypfcvKSY30CW0IvSWcbCXm5b7rvQ8lr/TaOSTuJokcxEfIvgt4 iD7ZnGlp4NpyIi8tHAv0Qz1m98Ds3XzE1GsDMaExz39K2AoswxDVe3Nvbu9q9APnokDS OoZb7TWsWKvZBN/OVHOVZZurbQOCG+nrp7LyljFdY3Z1z+TyQlcaWJ8bnWK2UvyvPNri weqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QL3NGVOB6+JZ3ukxMkukBF9jEY+KnmO5ms9/toR+m6I=; b=ntwBlSTkLFEaRPH2K5diWjGtSeDn6ZIrdLZ/y6n2CvVlfPlvk+VWg1loaU0UmOaQa0 2XWjIi5Pa5dausOZ/fnHHWhHDEjiU92Zasy/OzFNeTh15TTx62ciEmhVaZv3iwK+tjyo Th+YjgB/lqqwKUmUWSvr/yfMa9IiTKzCCQnu82qYoFAoRNSIbOna5QTzlEZFqs/XIarN WJfwDd49YpAjcJ0nToPNBtsavRdyeKVwcPLIGVH4IvcZ05blHa5VettiENFxvO4ErBG2 0ncNAdcBonq99Br40pz9OFkK2TC0a6hFEsmhG9TEiRBk254BAEhW9ISSTh6ro7lL5qzJ s5bg== X-Gm-Message-State: AHYfb5hKWVFcvAPte89jqZdaiBPYvJnnDA+7auAvj5NLCCaBwh6nJ+UU ti8z6D13iBVQn+a5vKqyOryjE7WhehqB X-Received: by 10.223.176.5 with SMTP id f5mr1873356wra.194.1502919759468; Wed, 16 Aug 2017 14:42:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Wed, 16 Aug 2017 14:41:58 -0700 (PDT) In-Reply-To: <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> References: <05e469cf-1325-89fc-4a81-661f8647e869@eff.org> <1dbb47a4-c6e2-97d2-a1d7-ce6c65a4042a@eff.org> <6B25B24C-4C80-4A04-BF27-2306F4A77EF6@fugue.com> <20170802180221.n7ezh5yzr5cuxklz@mycre.ws> From: Warren Kumari Date: Wed, 16 Aug 2017 17:41:58 -0400 Message-ID: To: Robert Edmonds Cc: Ted Lemon , Richard Barnes , Mike West , william manning , dnsop , Jacob Hoffman-Andrews Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 21:42:46 -0000 On Wed, Aug 2, 2017 at 2:02 PM, Robert Edmonds wrote: > Ted Lemon wrote: >> But we are arguing that "localhost" should be treated specially by every= piece of software that looks at it, when its default meaning is "look up l= ocalhost in the DNS and connect to one of the addresses that you get in res= ponse." > > RFC 6761 =C2=A76.3 already says that "localhost" should be treated specia= lly > by pretty much every piece of software that looks at it. But especially: > > 2. Application software MAY recognize localhost names as special, or > MAY pass them to name resolution APIs as they would for other > domain names. > > 3. Name resolution APIs and libraries SHOULD recognize localhost > names as special and SHOULD always return the IP loopback address > for address queries and negative responses for all other query > types. Name resolution APIs SHOULD NOT send queries for > localhost names to their configured caching DNS server(s). > > (In practice, "localhost" already does get treated specially, especially > by operating systems that place a "Name Service Switch" or similar > component in front of the DNS stub resolver. Yup, you would think so -- unfortunately, this seems less true than we'd expect (or hope!) Around 0.3% of responses from Google Public DNS are for "localhost". As an honest DNSSEC-validating resolver, Google Public DNS returns NXDOMAIN for queries of localhost. (and all its subdomains). If you ask with DO set, it returns the root NSEC records proving there is no such domain (yes, this disagrees with the SHOULD in 6.3.4 of RFC6761). As with many things in the DNS, the real world is messier than we'd -- I would have hoped that most systems would be answering locally for queries for localhost, and never asking the DNS, but this turns out not to be as true as we would have liked. I think that this supports the case for the localhost document; this behavior should be firmed up. It also exposes the fact that an application naively resolving "localhost" and trusting the answer (for security purposes) is not currently safe. W > If you put > "http://localhost/" into your browser bar, you shouldn't see a DNS query > for "localhost" leave your machine.) > > Doesn't "Application software MAY recognize localhost names as special" > already give more than enough permission for browser developers to treat > "localhost" (and any subdomain of "localhost") specially, for instance > by hardcoding the names to a loopback address, or filtering the result > from the system's name resolver to verify that only a loopback address > is used? Or only allowing the "Secure Context" flag to be set when the > localhost name resolves to a loopback address. > > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 =C2=A76.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguing about whether > localhost "should" be treated specially, but whether it MUST be treated > specially, by all applications. Can the W3C not impose stricter > requirements on browser developers even if 6761 doesn't impose mandatory > treatment for "localhost"? > > Maybe a smaller addition to RFC 6761 =C2=A76.3 would be sufficient for th= e > W3C? Something like: > > Application software specifications MAY require that application > software recognize localhost names as special. > > But that seems weird because it's arguably just a specific case of > requirement #2. > > -- > Robert Edmonds > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 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 nobody Wed Aug 16 15:00:31 2017 Return-Path: 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 EEEE3132710 for ; Wed, 16 Aug 2017 15:00:29 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 UzB5VBziFD5o for ; Wed, 16 Aug 2017 15:00:28 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDFB813219E for ; Wed, 16 Aug 2017 15:00:27 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id 49so19226624wrw.2 for ; Wed, 16 Aug 2017 15:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JeE+F/1Ooz9BEabWWQXFEqKGtiLR346vOibfzRMmAO8=; b=uq/0CLO+ycxqXBAGIgrbHo9aEHftsavJ8VTS/GGpPYQB1bKdb44rSM4ycYJp62FilJ 8OP9lyC9oo916lyzRa/QUZIkIkoGcrC9sfS0jJufIoRgRWtxuh5IL+zEkyuTuSTFOLxI Y8smXd6AQEUoVeyZIqEqFDPGUZVt9zM61iTUQy0cFiz9eWoCvn2vQosQ6wKijVZJ/JnY cCcHvAH6BwSgTEntp2dBEYkc5cDgdtyCLXBp3yDp9yRFUiUoySU5Q58fNGLGOtT+Bik6 sGrr5CzdGX4ebUbzC0Fk7InNynoerLGnhZxmsv9PXnVhoi9J0YCq6e0quXLSmiJvtOju 6mVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JeE+F/1Ooz9BEabWWQXFEqKGtiLR346vOibfzRMmAO8=; b=DnKW8wAHqtoVLq03OpDiLD3eSkyCPyHnh+bLd8rG9Mi1G6oy4G+YXgTQUB16IdLuED xAhzP56NO5Tm7kZoPp+791VFj58udoiDpm4s9iumYICIrFGUO8vSQd5m46lyIznF5bGN QuDGCiqQS0tiZ6y00UIRXQraE5PYMMs/WUnsE7pGKKiTBZpYREmXo61SNbjZ4451H/Wl RgrrapZLEfJ8dzOp9DgF9k391ywkUZFvENml2GfF4S6BYzxhfx/gSIq0xQ1Zz4Z7yFLi NyjFAoLdnuGM8rOZ3zyymQb/o0XmPXYoiGAWgTaLTqiB6T+6M8hBYSItojPXt0yHGEAr iVWw== X-Gm-Message-State: AHYfb5in+H1wFj8hiK5AzdEzFKD8mavLY8bkLUDX8pjFOVvIpI8q0nJr 39nmXaxn2OdST57HsC5X4bg7TROR4bt5g/0= X-Received: by 10.28.99.11 with SMTP id x11mr189080wmb.164.1502920826228; Wed, 16 Aug 2017 15:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Wed, 16 Aug 2017 14:59:45 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Wed, 16 Aug 2017 17:59:45 -0400 Message-ID: To: Ralf Weber Cc: =?UTF-8?B?56We5piO6YGU5ZOJ?= , dnsop , Ted Lemon , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 22:00:30 -0000 On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber wrote: > Moin! > > On 16 Aug 2017, at 2:44, Warren Kumari wrote: >>> If it's a commonly-used name, I suspect the more straightforward >>> "prefetching" should suffice in practice: >>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ >>> Several popular recursive servers already implement the feature. >>> Some of them even enable it by default. >>> >> >> One of the main outstanding items on the "Stop! Hammer Time!" document >> that we need to clean up the implementation section (Appendix A), but >> it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND >> 9.10 implement this. > From how I read the document and understand the implementations none of > those implements the actual draft, but instead they have implementations > that do some sort of prefetching. If that is the case you can add Nominum > Cacheserve to the list, Awesome! > but I really think we should do some more general > document describing prefetching as a concept and not just one way how to > do it with a hammer ;-). Yeah, we keep meaning to go back and fix up the document. I think that it (and, even more so, the discussions) has already served it's primary purpose - it led to this being implemented. But, I think that it would be good if we now update it to explain what is now implemented, and how... I must admit that I some of my hesitance has been because I'm still entertained by the "joke", and know that I need to just get over this :-) W > > So long > -Ralf -- 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 nobody Wed Aug 16 15:51:16 2017 Return-Path: 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 16E8913235C for ; Wed, 16 Aug 2017 15:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 fwrREPxoYTWu for ; Wed, 16 Aug 2017 15:51:13 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 27187126DD9 for ; Wed, 16 Aug 2017 15:51:13 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7GMoxaY058528 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Wed, 16 Aug 2017 22:50:59 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7GMoxDU058527 for dnsop@ietf.org; Wed, 16 Aug 2017 22:50:59 GMT Date: Wed, 16 Aug 2017 22:50:59 GMT From: Vernon Schryver Message-Id: <201708162250.v7GMoxDU058527@calcite.rhyolite.com> To: dnsop@ietf.org In-Reply-To: <5994A761.8080009@redbarn.org> X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 22:51:15 -0000 > From: Paul Vixie > well, yes, but a directive in /etc/resolv.conf saying what lies to > trust, or whether to trust all of them, or whether to trust none of > them, would be a way for a system operator or owner to set response > policy for all applications. > if an application wants a different kind of lies than is the default in > /etc/resolv.conf, it will need API hooks to say so. That's what I meant. It could be done today with small, upward compatible changes to libresolv to allow the application to specify resolver IP addresses, port numbers, and TSIG keys. (and equivalently in Windows) (Note that TSIG keys in resolv.conf would help provide a trustworthy path to your trusted resolver for reasons unrelated to RPZ.) (well, getting libresolv to sign and check TSIG might not be that small.) > > On the other hand, there is already signaling that provides both DNS > > truth and lies. A UNIX shell command like `alias honest "dig @8.8.8.8"` > > implements kludge "signaling" to get the DNS truth, while straight > > `dig` gets the possible lie. > > alas, this is unreliable. A network that routes requests to 8.8.8.8 to inject DNS lies will also arrange to ignore or pervert any DNS-in-band tell-the-truth signaling. Without access to a trustworthy resolver, tell-the-truth signaling is useless because you can't trust it. If you have a trustworthy path to a trustworthy verifying resolver, then by definition you trust that resolver to do the things you want with RPZ and everything else, and so none of your applications need both answers. With a trustworthy resolver, you don't need in-band trugh signaling except for debugging, and all of the many people who have debugged RPZ installations have not needed more than log files and `dig` to different resolvers and resolver views so far. > > The SOA added by RPZ to the additional section is perfectly sufficient > > to signal the honest presence of an RPZ lie. > > well, yes. but it may be the law of the land in some countries that > citizens accept DNS lies, whereas foreign visitors can accept DNS truth. > so i'd like the protocol to carry both (lies and truth), with > policy-level digital signatures on the lies, to be sure they are coming > from the place we're expecting our lies to come from. No jurisdiction will allow foreign visitors to bypass local filters forever, because foreign visitors blab both the banned data and the banned tools. We've a very long history of this in print media. Recall that the Iron Curtain borders took an extremely dim view of smuggling subversive literature. And didn't Tailand recently sanction some foreigners for lese magesty in forgien on-line media? Isn't there talk about China blocking all tunnels including those of foreigners? Even with the acquiescence of regimes, there are insurmountable practical technical and non-technical issues in providing both RPZ filtered and raw DNS answers, configuring applications, and ensuring that citizens don't get foreign, uncensored versions of applications. It's one thing for a regime to allow foreigners to use foreign services (which I claim never lasts), and quite another thing for in-country operators to expect government censors to understand and believe that citizens can't use the truthful results in DNS responses. If you were a DNS operator in China, would you ever allow your resolver to give truthful answers about some domains in any form or in response to any signaling?--of course not! We're seeing something like this happen with the European demands that the "rights to be forgotten" apply accross borders. Vernon Schryver vjs@rhyolite.com From nobody Wed Aug 16 16:09:43 2017 Return-Path: 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 069AB1323BA for ; Wed, 16 Aug 2017 16:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 Q9lnkxUSBaVs for ; Wed, 16 Aug 2017 16:09:40 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7CA13235E for ; Wed, 16 Aug 2017 16:09:40 -0700 (PDT) Received: (qmail 35125 invoked from network); 16 Aug 2017 23:09:39 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 16 Aug 2017 23:09:39 -0000 Date: 16 Aug 2017 23:09:17 -0000 Message-ID: <20170816230917.4475.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org In-Reply-To: <20170816071920.BA2C98287EA4@rock.dv.isc.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 23:09:42 -0000 In article <20170816071920.BA2C98287EA4@rock.dv.isc.org> you write: >> A colleague says "If TLDs allowed UPDATE messages to be processed most >> of the issues with DNSSEC would go away. At the moment we have a whole >> series of kludges because people are scared of signed update messages." Someone is wildly overoptimistic. The problem I run into over and over again is that I run someone's DNS and other services, but I am not the registrant and I am not the registrar, I just run the DNS. Either I have to walk the registrant through the process of installing DNSSEC keys, or she has to give me her registrar account password, neither of which scales. Slightly more automatic processing of updates for which I do not have the credentials will not help. R's, John From nobody Wed Aug 16 16:50:37 2017 Return-Path: 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 70210132143 for ; Wed, 16 Aug 2017 16:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 kwEgqmZCKtGc for ; Wed, 16 Aug 2017 16:50:34 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1BB132256 for ; Wed, 16 Aug 2017 16:50:34 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4] (unknown [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2AB6E61FF3; Wed, 16 Aug 2017 23:50:33 +0000 (UTC) Message-ID: <5994DA47.7000409@redbarn.org> Date: Wed, 16 Aug 2017 16:50:31 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Vernon Schryver CC: dnsop@ietf.org References: <201708162250.v7GMoxDU058527@calcite.rhyolite.com> In-Reply-To: <201708162250.v7GMoxDU058527@calcite.rhyolite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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, 16 Aug 2017 23:50:36 -0000 Vernon Schryver wrote: > A network that routes requests to 8.8.8.8 to inject DNS lies will also > arrange to ignore or pervert any DNS-in-band tell-the-truth signaling. > Without access to a trustworthy resolver, tell-the-truth signaling is > useless because you can't trust it. i would like to be able to know that i can't trust it, rather than merely assuming that i can't trust it, as happens today. if neither the truth nor the lie is signed, i can make a red light blink, or even go offline, refusing the local edition of the social compact ("if you want to use the internet you have to accept dns answers w/o provenance.") > No jurisdiction will allow foreign visitors to bypass local filters > forever, because foreign visitors blab both the banned data and the > banned tools. as a frequent visitor to china, my verizon wireless roaming service is tunnelled back to the USA. i can read facebook, search google, and so on. verizon isn't a pirate -- they have a license to operate in china and they honor the terms of that license. but they don't sell this service inside china. i expect more, not less, arrangements of this kind going forward, now that other nation-states are making decisions about internet content filtering for their citizens. note that i blogged on this specific point, and mentioned rpz, recently: http://www.circleid.com/posts/20170718_nation_scale_internet_filtering_dos_and_donts/ > ... Isn't there > talk about China blocking all tunnels including those of foreigners? not that i've heard. china has a delicate balancing act, and they do not seem to want to completely discourage tourism, even if that means there are leaks in the great firewall as a result. on wifi or wired, they don't know who isn't a citizen. on LTE or GSM, they do. but the tunnel i use is slow, and expensive for both verizon and i. i'd like to offer china the opportunity to carry both dns truth and dns lies, in the same packet, with one of them a little harder to get at using older software, and with newer software having a switch, "do you trust policy having this key?" i expect that for android and iOS devices sold in china, this switch would be hardwired "on". this reflects my broader belief that neither the open source community, or the internet technology community, will ever be taken seriously by the chinese gov't if we tell them how they should run their country's internet or its connections to the rest of the world. if they want to be able to express policy data more reliably using DNS than will be possible in a ubiquitous-DNSSEC scenario, then we ought to provide that, and encourage engineers from within china to help define, model, test, develop, and deploy it. this would ease the complexity burden for companies selling internet devices and services inside china. it will not make anybody in the world less autonomous than they already aren't. > Even with the acquiescence of regimes, there are insurmountable practical > technical and non-technical issues in providing both RPZ filtered and > raw DNS answers, configuring applications, and ensuring that citizens > don't get foreign, uncensored versions of applications. It's one thing > for a regime to allow foreigners to use foreign services (which I claim > never lasts), and quite another thing for in-country operators to > expect government censors to understand and believe that citizens can't > use the truthful results in DNS responses. If you were a DNS operator > in China, would you ever allow your resolver to give truthful answers > about some domains in any form or in response to any signaling?--of course > not! as a provider i would, whether in china or elsewhere, follow the law. -- P Vixie From nobody Wed Aug 16 20:44:11 2017 Return-Path: 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 56BFE1241F5 for ; Wed, 16 Aug 2017 20:44:10 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 R5sy0P6plSnG for ; Wed, 16 Aug 2017 20:44:08 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 8BC0413208E for ; Wed, 16 Aug 2017 20:44:08 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7H3ht28051809 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Thu, 17 Aug 2017 03:43:55 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7H3htQn051808 for dnsop@ietf.org; Thu, 17 Aug 2017 03:43:55 GMT Date: Thu, 17 Aug 2017 03:43:55 GMT From: Vernon Schryver Message-Id: <201708170343.v7H3htQn051808@calcite.rhyolite.com> To: dnsop@ietf.org X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 03:44:10 -0000 > From: Paul Vixie > > A network that routes requests to 8.8.8.8 to inject DNS lies will also > > arrange to ignore or pervert any DNS-in-band tell-the-truth signaling. > > Without access to a trustworthy resolver, tell-the-truth signaling is > > useless because you can't trust it. > > i would like to be able to know that i can't trust it, rather than > merely assuming that i can't trust it, as happens today. if neither the > truth nor the lie is signed, i can make a red light blink, or even go > offline, refusing the local edition of the social compact ("if you want > to use the internet you have to accept dns answers w/o provenance.") By "signed" I guess you mean signed by the resolver itself with some sort of public key (perhaps DLV, double dnssec, one of the other secure DNS schemes, or something new) or with TSIG using a symmetric key previously shared with the resolver. (Having the stub verify DNSSEC to validate the truth and turn off the red light would make the stub a lot like a verifying resolver.) If so, I agree that works, but I still don't see how that is as good as two dig's with one to a resolver trusted to give the truth. Whenever that in-band DNS truth red light *might* blink, you'll want a trusted resolver available so that when the light does blink your application gets honest DNS truth or honest RPZ lies. But with that trusted verifying resolver you can use 2 digs and don't need the protocol or implementation costs of inband RPZ truth and you needn't to surmount principled IETF opposition to sanctioning RPZ. Principled objections to RPZ cannot be answered by RPZbis including truth with lies. That is because an application must consistently choose either truth or possible RPZ lies. Choosing RPZ lies for security and privacy defenses makes including the truth in RPZbis answers a sham and waste of bandwidth. On the other hand, an application choosing truth makes the RPZ lies a waste of bandwidth. Which gets back yet again to the only place I think RPZ belongs, which is in a verifying resolver that you trust to do only the RPZ lying that you want (and so where you don't need that red light except when debugging). All other uses of RPZ should be considered attacks on your security and privacy. (I think that's a short form of the agreed words that I'm waiting to be told to add to the draft.) Vernon Schryver vjs@rhyolite.com From nobody Wed Aug 16 20:47:58 2017 Return-Path: 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 C156F132661 for ; Wed, 16 Aug 2017 20:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 jr8rpiyetwW6 for ; Wed, 16 Aug 2017 20:47:52 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 13B47132485 for ; Wed, 16 Aug 2017 20:47:52 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id D0EC734B6DD; Thu, 17 Aug 2017 03:47:49 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A91D0160052; Thu, 17 Aug 2017 03:47:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8E39D160067; Thu, 17 Aug 2017 03:47:49 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Nz4baa-u0QaQ; Thu, 17 Aug 2017 03:47:49 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 42D07160052; Thu, 17 Aug 2017 03:47:49 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0F82D8298B68; Thu, 17 Aug 2017 13:47:47 +1000 (AEST) To: "John Levine" Cc: dnsop@ietf.org From: Mark Andrews References: <20170816230917.4475.qmail@ary.lan> In-reply-to: Your message of "16 Aug 2017 23:09:17 +0000." <20170816230917.4475.qmail@ary.lan> Date: Thu, 17 Aug 2017 13:47:47 +1000 Message-Id: <20170817034747.0F82D8298B68@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 03:47:54 -0000 In message <20170816230917.4475.qmail@ary.lan>, "John Levine" writes: > In article <20170816071920.BA2C98287EA4@rock.dv.isc.org> you write: > >> A colleague says "If TLDs allowed UPDATE messages to be processed most > >> of the issues with DNSSEC would go away. At the moment we have a whole > >> series of kludges because people are scared of signed update messages." > > Someone is wildly overoptimistic. > > The problem I run into over and over again is that I run someone's DNS > and other services, but I am not the registrant and I am not the > registrar, I just run the DNS. Either I have to walk the registrant > through the process of installing DNSSEC keys, or she has to give me > her registrar account password, neither of which scales. Slightly > more automatic processing of updates for which I do not have the > credentials will not help. Or you can have credentials to allow the hoster to update the DS records alone. UPDATE allows for fine grained credentials. Named has had fine grain update support for over a decade now. You can specify keys that can do everything and you can specify keys that can just update a single type. This isn't hard to do. The DNS hoster gives the registrant the public key they use to update DS records. This is passed to the registrar which uses it to verify UPDATE requests that change the DS records. You can do similar with TSIG but that is a shared secret between three parties. This is like using master keys and more specific keys. The only reason this isn't done today is that we aren't using UPDATE and are forcing all the transactions through a web interface. Mark > R's, > John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Aug 16 21:09:52 2017 Return-Path: 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 2503713247A for ; Wed, 16 Aug 2017 21:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bUt6HWfS924B for ; Wed, 16 Aug 2017 21:09:47 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D32F1320BE for ; Wed, 16 Aug 2017 21:09:47 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id 5so6420743wrz.5 for ; Wed, 16 Aug 2017 21:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8CibytmrpmypAPBrJ4sXM3ywuiAPj06hCJM8wPYSjpc=; b=JoUi2VuHUSrF9rBLfQt25UjGVkubcb8oqyigloWjVMyJMwcmMbw2M5/VZlR7kruDSI Xgl9PyGoK0TG7mRTAPSe9NTUkuT69mkbwpg7p9bpeMO1n6w97spBk2IYZiOL7fUS+6Yo HpUTl8VaLggksVagQ995N5rrtQlbcD5O2km0EDSC+gc7+2dCtQMCvRkU73iGhIQo3Vno LuBeGIDYWtTBnZIrY9YA7LxObYXL3QH8WhhVL/DSbORKiemp78zcyEBZfbRDhLUSMJeu UD4IFOaA69Qs8pqTF4aPwkwmuar4SmWwknG1pbAm+LeJVpbhu7Vf9wQ9A3uR4AKZte5z Ytxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8CibytmrpmypAPBrJ4sXM3ywuiAPj06hCJM8wPYSjpc=; b=njC+wm4GR/87YFVRZ71/yMsd4fcV4JGKB4Zhgy0bsFpzLcxwb3D54IZXiDRlmWHH4t Y+JnH/0MW3A+CGI+ok6oyu+R0KTEJt73/d3b0IAakKMRzbd81tUyQ1JpUGj/hU5rytm3 G1/3Wae2c5LbfgOd0pTVpuOD6AQN3oWtnYpNBw0SzfqTnEcVjTKCjcNuzQjWMYSMIvUp bDyCykca46vTSSEQbBv5GEIeuhDd3G75vmMJZ3csBOJZt6BDgjW1Yc3ztghcPZ3cXaf9 /HoYdrQNXiICPrJPE7osmd0ernb/K91gPXNexYW6t2cpAkMa5wQKMfpf7W5MiSB1aT34 /Ftg== X-Gm-Message-State: AHYfb5ifSfc/e8b8du56nVgFqqiVeW072jHhJRindjVaf6Esqb5vWdCF n9HFCYlPBzRc2bMLbN7aVxEiHc5cB9Ec5wM= X-Received: by 10.80.165.167 with SMTP id a36mr567698edc.286.1502942985742; Wed, 16 Aug 2017 21:09:45 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> In-Reply-To: From: Lanlan Pan Date: Thu, 17 Aug 2017 04:09:34 +0000 Message-ID: To: Ted Lemon Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c2548c870dd0556eb2ef1" Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 04:09:51 -0000 --f403045c2548c870dd0556eb2ef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU & TTL works fine. SWILD not save many online cache size, because of the queries rate. And Temporary Domain Names/ All Names: 41.7% for 7 days statistics, the rate can be about 10% for 1 day statistics. Because temporary domain names expire after TTL time. Ralf has similar curious. The problem is: 1) cache size Recursives commonly cache "all queried domain in n days" for some SERVFAIL/TIMEOUT condition, which has been documented in https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01 The subdomain wildcards cache are needlessly, we can use heuristics algorithm for deciding what to cache, or just use simple rule like "select domain which queies time > 5 in last n days". We can use SWILD to optimize it, not need to detecting, just remove items which SWILD marked, to save cost. 2) cache miss All of temporary subdomain wildcards will encounter cache miss. Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... We can use SWILD to optimize it, only query xxx.foo.com for the first time and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative server. 3) DDoS risk The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC unsigned. For example, [0-9]+.qzone.qq.com is a popular SNS website in China, like facebook. If botnets send "popular website wildcards" to recursive, the cache size of recursive will rise, recursive can not just simply remove them like some other random label attack. We prefer recursive directly return the IP of subdomain wildcards, and not rise recursive cach, not send repeat query to authoritative. Ted Lemon =E4=BA=8E2017=E5=B9=B48=E6=9C=8816=E6=97=A5=E5= =91=A8=E4=B8=89 =E4=B8=8B=E5=8D=888:54=E5=86=99=E9=81=93=EF=BC=9A > El 16 ag 2017, a les 0:19, Lanlan Pan va escriure: > > We analyzed our recursive query log, about 18.6 billion queries from > 12/01/2015 to 12/07/2015. > > We found about 4.7 Million temporary domains occupy the recursive's cache= , > which are subdomain wildcards from Skype, QQ, Mcafee, Microsoft, > 360safedns, Cloudfront, Greencompute... > > Temporary Domain Names/ All Names: 41.7% > Queries for Temporary Domain Names/ All Queries: 0.12% > > > Okay. So it sounds like you have an algorithm for detecting temporary > domain names. It seems to me that a quicker solution to your problem is > to publish an operational document describing that algorithm and proposin= g > ways that recursive caches can use it to prune such domains from the cach= e > early. > > I'm curious if you studied the behavior of existing recursive caches in > the presence of these domains: do they in fact cache at the rate you > predict they will? The reason I ask is that I know that my own company'= s > cache, which is widely deployed in the exact scenario you are describing, > has a pretty sophisticated set of heuristics for deciding what to cache. > It would surprise me if it exhibited the behavior you are concerned about= . > > BTW, your paper is behind a paywall, so please don't cite it as a reason > to do anything in the IETF. If you want the IETF to take action based o= n > what is in the paper, you need to publish it openly. > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c2548c870dd0556eb2ef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, I agree, in fact the online cache rate is small (0.12% queries), LRU & TTL works fine.
SWILD = not save many online cache size, because of the queries rate.
And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,=C2=A0 = the rate can be about 10% for 1 day statistics. Because temporary domain na= mes expire after TTL time.=C2=A0 Ralf has similar curious.
=

The problem is:

1)=C2=A0 cache size
<= div>Recursives commonly cache "all queried domain in n days" for = some SERVFAIL/TIMEOUT condition, which has been documented in https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01
The subdomain wildcards cache are needlessly,=C2=A0 we can use heuristics = algorithm for deciding what to cache, or just use simple rule like "se= lect domain which queies time > 5 in last n days".
We can= use SWILD to optimize it, not need to detecting, just remove items which S= WILD marked, to save cost.

2) cache miss
=
All of temporary subdomain wildcards will encounter cache miss.
<= div>Query xxx.foo.com,=C2=A0 then query = yyy.foo.com, zzz.foo.com, ...
We can use SWILD to optimize it,=C2=A0 o= nly query xxx.foo.com for the first time= and get SWILD, avoid to send yyy/zzz.foo.co= m queries to authoritative server.

3) DDoS risk
The botnet ddos risk and defense is like NSE= C aggressive wildcard, or NSEC unsigned.
For example,=C2=A0 [0-9]= +.qzone.qq.com is a popular SNS website= in China, like facebook. If botnets send "popular website wildcards&q= uot; to recursive,=C2=A0 the cache size of recursive will rise, recursive c= an not just simply remove them like some other random label attack.
We prefer recursive directly return the IP of subdomain wildcards, a= nd not rise recursive cach, not send repeat query to authoritative.
<= br>
Ted Lemon <= ;mellon@fugue.com>=E4=BA=8E2017= =E5=B9=B48=E6=9C=8816=E6=97=A5=E5=91=A8=E4=B8=89 =E4=B8=8B=E5=8D=888:54=E5= =86=99=E9=81=93=EF=BC=9A
El 16 ag 2017, a les 0:19, Lanlan Pan <abbypan@gmail.com>= va escriure:
We analyzed our recursive query log, about 18.6 billion que= ries=C2=A0from 12/01/2015 to 12/07/2015.

We found about 4.7 Million temporary domains occupy = the recursive's cache, which are subdomain wildcards from Skype, QQ, Mc= afee, Microsoft, 360safedns, Cloudfront, Greencompute...

Temporar= y Domain Names/ All Names: 41.7%

Queries for Temporary Domain Name= s/ All Queries: 0.12%

Okay. =C2=A0 So it sounds like you have an algo= rithm for detecting temporary domain names. =C2=A0 It seems to me that a qu= icker solution to your problem is to publish an operational document descri= bing that algorithm and proposing ways that recursive caches can use it to = prune such domains from the cache early.

I'm c= urious if you studied the behavior of existing recursive caches in the pres= ence of these domains: do they in fact cache at the rate you predict they w= ill? =C2=A0 The reason I ask is that I know that my own company's cache= , which is widely deployed in the exact scenario you are describing, has a = pretty sophisticated set of heuristics for deciding what to cache. =C2=A0 I= t would surprise me if it exhibited the behavior you are concerned about.

BTW, your paper is behind a paywall, so please don&= #39;t cite it as a reason to do anything in the IETF. =C2=A0 If you want th= e IETF to take action based on what is in the paper, you need to publish it= openly.

--
=E8=87=B4=E7=A4=BC=C2= =A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--f403045c2548c870dd0556eb2ef1-- From nobody Wed Aug 16 22:40:13 2017 Return-Path: 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 97017124E15 for ; Wed, 16 Aug 2017 22:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 KuCYTRJ7CIG9 for ; Wed, 16 Aug 2017 22:40:10 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6F3132666 for ; Wed, 16 Aug 2017 22:40:07 -0700 (PDT) Received: from [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4] (unknown [IPv6:2001:559:8000:c9:48ee:a207:919c:69c4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id B1B8261FF3; Thu, 17 Aug 2017 05:40:06 +0000 (UTC) Message-ID: <59952C34.1090100@redbarn.org> Date: Wed, 16 Aug 2017 22:40:04 -0700 From: Paul Vixie User-Agent: Postbox 5.0.16 (Windows/20170718) MIME-Version: 1.0 To: Vernon Schryver CC: dnsop@ietf.org References: <201708170343.v7H3htQn051808@calcite.rhyolite.com> In-Reply-To: <201708170343.v7H3htQn051808@calcite.rhyolite.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 05:40:12 -0000 Vernon Schryver wrote: > By "signed" I guess you mean signed by the resolver itself with some > sort of public key ... If so, I agree that works, yes. > but I still don't see how that is as good as two dig's with one to > a resolver trusted to give the truth. there will in my model be only one resolver, and while it may or may not be trusted to tell the truth, it may or may not also be trusted to tell a useful lie. that is, truth has value, and some lies also have value, for example an RPZ answer of NXDOMAIN when the qname is a DGA. but right now we have no authentication of the lies, while we do have it for the truth (if DNSSEC is used). so, i am conflating two issues in my stick-figure of the moment: authentication of lie source and content, and, the ability of an end-user via resolv.conf or API to tell her local applications what lie-source to believe, if any. > Whenever that in-band DNS truth red light *might* blink, you'll want > a trusted resolver available so that when the light does blink your > application gets honest DNS truth or honest RPZ lies. ... no, really. it's blink red first, and then either go offline or remain online, according to the user's risk tolerance. for me it's go offline. there is no other resolver present to ask-also or ask-instead or ask-after. rpz must become hop-by-hop authenticated, since there's no end-to-end for it. this may become the first valid use for dnscrypt. > Principled objections to RPZ cannot be answered by RPZbis including > truth with lies. That is because an application must consistently > choose either truth or possible RPZ lies. Choosing RPZ lies for > security and privacy defenses makes including the truth in RPZbis > answers a sham and waste of bandwidth. On the other hand, an application > choosing truth makes the RPZ lies a waste of bandwidth. i'm on a different trail entirely. we have to include the truth if it's dnssec signed, since the client will know we're lying if we do otherwise. but, in any valid RPZ deployment, the lies we tell are of value to the client, so we must include those. and, because those lies can otherwise be MITM'd, we must authenticate them hop-by-hop (that is, from the rDNS to the stub.) > Which gets back yet again to the only place I think RPZ belongs, which > is in a verifying resolver that you trust to do only the RPZ lying > that you want (and so where you don't need that red light except when > debugging). between arp spoofing and ip-source spoofing, a stub has no reason to trust its rDNS -- that's why DNSSEC has to be visible end-to-end for DNSSEC-aware applications. we need to authenticate the source of a lie, since otherwise it could be inserted by some on-LAN malicious actor. while we might be able to use SIG(0) and the KEY RR for this, and that would be a form of DNSSEC, the form would be degenerate, since it's not the same as end-to-end source authentication of the DNS data as having been created by the legitimate operator of the zone whose key signed it. RPZ is divorced entirely from the zone whose key normally signs data having the owner = qname. so we have to authenticate hop by hop. -- P Vixie From nobody Thu Aug 17 00:39:58 2017 Return-Path: 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 077181327FF for ; Thu, 17 Aug 2017 00:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 8m8qy--useTI for ; Thu, 17 Aug 2017 00:39:51 -0700 (PDT) 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 3F158132436 for ; Thu, 17 Aug 2017 00:39:51 -0700 (PDT) Received: from [192.168.3.102] (ip4-95-82-146-6.cust.nbox.cz [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 5E98962326 for ; Thu, 17 Aug 2017 09:39:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502955589; bh=eEvvFUjyNMeT7T8m1pif1mZ3u+P26/uSduUTtGIk828=; h=To:From:Date; b=x1lYEJyPYBij3KKVTmDx//XbUHaOM7bs/f0S1OzXCxvTMTKd3auZ//snxPyIWRRgD OB8gi2lATn7U/hKovyrxI/Jg07b0c9PqU+YE9aPwvC5GvYddIKqaXPbjFNBhNs+2Fn ri52N9HkLWAdnNzxHVpt2QyL2pg8MJLPOvpJxgCE= To: dnsop@ietf.org References: <20170816230917.4475.qmail@ary.lan> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <272dc071-c650-220c-3528-acb9467c706b@nic.cz> Date: Thu, 17 Aug 2017 09:39:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170816230917.4475.qmail@ary.lan> 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: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 07:39:56 -0000 On 17.8.2017 01:09, John Levine wrote: > In article <20170816071920.BA2C98287EA4@rock.dv.isc.org> you write: >>> A colleague says "If TLDs allowed UPDATE messages to be processed most >>> of the issues with DNSSEC would go away. At the moment we have a whole >>> series of kludges because people are scared of signed update messages." > > Someone is wildly overoptimistic. Or maybe not. CZ registry is now getting CDNSKEY from unsigned domains and use the obtained value to derive parent-side DS. This allows even third parties running DNS for the domain owner (e.g. Cloudflare) to DNSSEC-sign domains with no action required from the domain owner. Yes, someone might try to attack a domain using this. To lower probability of this kind of attack CZ.NIC is nagging the technical contact for one week before the DS gets installed into the CZ zone. For further details please see https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/ We will see how it goes. -- Petr Špaček @ CZ.NIC From nobody Thu Aug 17 04:33:12 2017 Return-Path: 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 2C05E13213D for ; Thu, 17 Aug 2017 04:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=conundrum-com.20150623.gappssmtp.com 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 N1-DO6PIRLz1 for ; Thu, 17 Aug 2017 04:33:08 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA04126DD9 for ; Thu, 17 Aug 2017 04:33:08 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id c74so21974322iod.4 for ; Thu, 17 Aug 2017 04:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p2u0HrWWcC4d+CpGKjQhu1BRfRtLDl6lvmaRWTZ/KUA=; b=FJxCJFmxPJBPlQXk5c2i6lc4jRBgvOIGZZjDNGDsiWNdWUa6UKvnLjSpq3n3PgehRS sTWqQ5usIlJf12O3XpSdAqJe+p6qhb07uSaQ362ZUJHr7BGLzxiagwrXlcwS0xw7D11W hmbhLjbS0dwf7SYwLuqX5oNL01woePMfvMGN2KJL4vPnspOFB0AXGiW9hvlMcHcrDI8X sCpASiOG8uViV/0CuPqV5sKImkQlINPo6Kkyx8ZEQb/yfg6dqnfUd/0c77x77/26n7QD LnpKBqPXqYCWrPhpVLlqDQw9hE57qPHf4W+b4wusyoa6EHvWYpJA2bWOCbGD0wPD5zob P+eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p2u0HrWWcC4d+CpGKjQhu1BRfRtLDl6lvmaRWTZ/KUA=; b=SVy93WluUJc3yjEJVbG8tZqcXYT7WmJOp/rI3vq0f3ZsojDIZUJOGYa9Nou8D3ZYeJ FKO+jjjqeyqFtmpq3+oOdahakwb9jYyHBZK6YfkNm53La3H7fJXVHH6UZJU43dRUXZa2 VgwQnmYxINtChpTCOWKcBLKLlg+SgkQicm0hoqGxkW7VrmN0b/tCOGmxIT463iBxEY8S NbXGGetX5R60dyVuVYZiwNrT4dEcr4ixBYNWxwLzDeOfUUGK7NmhTT9nrZjLPClJyNQw +Kn9R9FYsXGNOSKu2rJ9988luUpBVSeM281G6kh2r72otojnhyXiwxWlJwoDhti/uwKW IzJw== X-Gm-Message-State: AHYfb5ieL8iRci9fxTu/5l6GujAzFFu1pIAUAhxL9Y1iXTpTnCAzECo3 RrMfjryp22WdZbeWfDk/u/WOyuD4r9BF3XrAcA== X-Received: by 10.107.59.207 with SMTP id i198mr4830267ioa.198.1502969587645; Thu, 17 Aug 2017 04:33:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.8.215 with HTTP; Thu, 17 Aug 2017 04:33:07 -0700 (PDT) In-Reply-To: <20170816230917.4475.qmail@ary.lan> References: <20170816071920.BA2C98287EA4@rock.dv.isc.org> <20170816230917.4475.qmail@ary.lan> From: Matthew Pounsett Date: Thu, 17 Aug 2017 07:33:07 -0400 Message-ID: To: John Levine Cc: dnsop Content-Type: multipart/alternative; boundary="94eb2c06a4986161860556f160d9" Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 11:33:11 -0000 --94eb2c06a4986161860556f160d9 Content-Type: text/plain; charset="UTF-8" On 16 August 2017 at 19:09, John Levine wrote: > In article <20170816071920.BA2C98287EA4@rock.dv.isc.org> you write: > >> A colleague says "If TLDs allowed UPDATE messages to be processed most > >> of the issues with DNSSEC would go away. At the moment we have a whole > >> series of kludges because people are scared of signed update messages." > > Someone is wildly overoptimistic. > > The problem I run into over and over again is that I run someone's DNS > and other services, but I am not the registrant and I am not the > registrar, I just run the DNS. Either I have to walk the registrant > through the process of installing DNSSEC keys, or she has to give me > her registrar account password, neither of which scales. Slightly > more automatic processing of updates for which I do not have the > credentials will not help. > > Have a look at: < https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ > It allows a registrar (or a registry in some ccTLD environments) to do CDS/CDNSKEY without having to constantly scan their registrants' name servers, and provides some advice on how to safely bootstrap DNSSEC using CDS/CDNSKEY. There's currently a registrar implementation at Gandi, enabled for the TLDs for which they do DNSSEC (I believe it's beta, so you have to speak to their support to find the API URI), and registry implementations at CIRA (.ca) and APNIC (for their reverse zones). The CZ.NIC folks have also started building it into Fred, their open source registry software. There are a few more changes the draft will go through before it's ready for last call, but the API it describes should remain largely unchanged from this point onward. --94eb2c06a4986161860556f160d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 16 August 2017 at 19:09, John Levine <johnl@taugh.com> wrote:
In article &l= t;2017081607= 1920.BA2C98287EA4@rock.dv.isc.org> you write:
>> A colleague says "If TLDs allowed UPDATE messages to be proce= ssed most
>> of the issues with DNSSEC would go away. At the moment we have a w= hole
>> series of kludges because people are scared of signed update messa= ges."

Someone is wildly overoptimistic.

The problem I run into over and over again is that I run someone's DNS<= br> and other services, but I am not the registrant and I am not the
registrar, I just run the DNS.=C2=A0 Either I have to walk the registrant through the process of installing DNSSEC keys, or she has to give me
her registrar account password, neither of which scales.=C2=A0 Slightly
more automatic processing of updates for which I do not have the
credentials will not help.


Have a l= ook at:=C2=A0

It allows a registrar (or a registry in some ccTLD environments) to= do CDS/CDNSKEY without having to constantly scan their registrants' na= me servers, and provides some advice on how to safely bootstrap DNSSEC usin= g CDS/CDNSKEY. =C2=A0

There's currently a regi= strar implementation at Gandi, enabled for the TLDs for which they do DNSSE= C (I believe it's beta, so you have to speak to their support to find t= he API URI), and registry implementations at CIRA (.ca) and APNIC (for thei= r reverse zones).=C2=A0 The CZ.NIC folks have also started building it into= Fred, their open source registry software.

There = are a few more changes the draft will go through before it's ready for = last call, but the API it describes should remain largely unchanged from th= is point onward.
--94eb2c06a4986161860556f160d9-- From nobody Thu Aug 17 06:41:10 2017 Return-Path: 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 6670A132436 for ; Thu, 17 Aug 2017 06:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 8Yx5qIVmSPKD for ; Thu, 17 Aug 2017 06:41:06 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 9B033132431 for ; Thu, 17 Aug 2017 06:41:06 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:e86e:f483:12:b1ec] (unknown [IPv6:2001:67c:1220:80c:e86e:f483:12:b1ec]) by mail.nic.cz (Postfix) with ESMTPSA id DB3EB600D2 for ; Thu, 17 Aug 2017 15:41:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502977264; bh=FXSAb/J+ykYz9WuM0XFY26nw2H/QOyExuzPm8XI1eMY=; h=To:From:Date; b=XKirCwZCSoNX+3XjpFdACMdfDfsE+5JeCwK7uL3nq5xRDyQiyUcHslPXf9zERG476 mkaOhMppKDZ9ICgB2oL/Waar4f3o8xUoMXgvrDUp9MvRM4TUCcyThAKzIxM5mX/6m4 zDx8QpUIBtMJb2vN0gQGyfmJKaZmfyRjCiZJTomg= To: dnsop@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <4dcf23fc-f6f2-2288-36fd-67ed210aefe0@nic.cz> Date: Thu, 17 Aug 2017 15:41:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 13:41:09 -0000 On 16.8.2017 23:59, Warren Kumari wrote: > On Wed, Aug 16, 2017 at 4:05 AM, Ralf Weber wrote: >> Moin! >> >> On 16 Aug 2017, at 2:44, Warren Kumari wrote: >>>> If it's a commonly-used name, I suspect the more straightforward >>>> "prefetching" should suffice in practice: >>>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer/ >>>> Several popular recursive servers already implement the feature. >>>> Some of them even enable it by default. >>>> >>> >>> One of the main outstanding items on the "Stop! Hammer Time!" document >>> that we need to clean up the implementation section (Appendix A), but >>> it does note that at least Unbound (NLNet Labs), OpenDNS, and ISC BIND >>> 9.10 implement this. >> From how I read the document and understand the implementations none of >> those implements the actual draft, but instead they have implementations >> that do some sort of prefetching. If that is the case you can add Nominum >> Cacheserve to the list, BTW you can count Knot Resolver in as well. -- Petr Špaček @ CZ.NIC From nobody Thu Aug 17 06:54:58 2017 Return-Path: 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 A7F9F132192 for ; Thu, 17 Aug 2017 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=zhTJ63/L; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=QZ/z15+o 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 KjywxbDTXsBt for ; Thu, 17 Aug 2017 06:54:54 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57482132063 for ; Thu, 17 Aug 2017 06:54:54 -0700 (PDT) Received: (qmail 44215 invoked from network); 17 Aug 2017 13:54:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=acb5.5995a02d.k1707; bh=O9Kz05TzoEb2s3ZQiZRqUFafyrONfoL5E/2O8k7gZa8=; b=zhTJ63/LOC/42fmstBzjyvUk/VglQGfNORgAhD1F0LbSfnV8C3Rb///xfaO9rTKxinfqubqM7HPEZKQ/y0G+CVttkLRXZMnnTe5gYulVrqAc3iDGfuex9men0h6ludFiW+ttWBtCpXeXgRAz3CpUqvK7qv4UeSH/Ds6//FfTX8L9rZIj9MR8MMvP7QK3UwH8cd8/JZA8d7nJaf9AFtoy9ETx8EpzOF2Exf68ESo+BPoMxPajGipQPCm95jtehuRk DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=acb5.5995a02d.k1707; bh=O9Kz05TzoEb2s3ZQiZRqUFafyrONfoL5E/2O8k7gZa8=; b=QZ/z15+oTAZV+TIsOvK3u8NDiFUEDTQYpzElDMhvyU144318c2Rr05b93dWiKYOTm4X5EDVAnGujEVHXyWjh8BsPRP32aO+6ol1gugV0AEfy11Ax8L4ppNXTMI0xUymyF8lxQrry+DfCP1NruYugP37CKs9ABfI3mpz3Rieyz3n1Ax5vX+E1ipU5dl56TQjp+rLc3n7L1GXyqtFUwx/vOHRxwLjoCsUIoTXWkds6NG07uRRZExTuQvEA53wl2RSn Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 17 Aug 2017 13:54:52 -0000 Date: 17 Aug 2017 09:54:51 -0400 Message-ID: From: "John R Levine" To: "Matthew Pounsett" Cc: "dnsop" In-Reply-To: References: <20170816071920.BA2C98287EA4@rock.dv.isc.org> <20170816230917.4475.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 13:54:57 -0000 > Have a look at: > https://datatracker.ietf.org/doc/draft-ietf-regext-dnsoperator-to-rrr-protocol/ I've talked to Jacques about it, will try it when I have a chance. I only have two .CA domains so it's not a very high priority at this point. I agree that at this point it's the most promising approach if registries and registrars can solve the metaproblem of finding the update server. There's a dismaying amount of pushback on RDAP among the ICANN registries (policy issues, nothing technical) so I'm not holding my breath. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 17 06:56:30 2017 Return-Path: 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 DFACE132577 for ; Thu, 17 Aug 2017 06:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 OjqxdWoo9BfS for ; Thu, 17 Aug 2017 06:56:20 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AB3132499 for ; Thu, 17 Aug 2017 06:56:20 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id p3so37794693qtg.2 for ; Thu, 17 Aug 2017 06:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5IdYHIy+13xgnFu7WDLOVIUokAwAYh0SdN7LUEwcKiQ=; b=kyX2QJ1sSo69A/YkAhUYhSHsAnsyNt9AOJGQmWlCMAF6Gx9AFCyRENQ2UP2mWGuxrF +TsF9oFAA+B6UvYuNPogLolukZobTDhjYxITtG3hjizPSIUrd7vzopjtYQJvbdxferLL mXtYdhgs7roPJJjaXG1h4cTqX3M80SuKS0kA5pT5vI4Dw9RCQd5K4Xi1ihJmGdaJBcl3 NV0q7pVagAOSq4WK6Sj26y4HEMShm5xItak3AqkefGg45iMxKdLNLQI/3Mh59jT23Dl6 7JIDeTfm0VkwCPQC0bwTGAmoO8ygm2r5xrgoF7mt9HYc4WCa2REjZayGfafFhGFnJqDB Abcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5IdYHIy+13xgnFu7WDLOVIUokAwAYh0SdN7LUEwcKiQ=; b=VZCbazZq/A9pcgJridZqmFPy/IicuQ+k9ujBf5+m9PMtzwtFPveEB1xyG6Q+gnBDJH HcqXPVxNidRG4weRQAZ9f3WCYlIYEj2MTIKQjeBZ1TP2I5NtwnZ1qb2mbFX3fo/4DZ8b bgGMIxy7TLyLNC0pA/xDsESFmebQHzg3aFzDJaVcBsD5PXHoV6iWxC2yeT97/6C86jaU 5xj73RQU0M6AK9nBwqgS+cPbK+YPhLlSi888aLPgG2WMkwJlI0108Lb4YzsdPpYc9/yY dnLgofPHYQSTi6SiN3SJv+Ty5potcXZ5PGdL1BTeh6GEEFIM04tISskBX3CA6XHuSzqR fSpQ== X-Gm-Message-State: AHYfb5jthmAopcvCHkwLNVDM2RC5hFz8iS8rGG4sP753nwo7/4AuVwVw WP4ndU/zMbB/630q X-Received: by 10.200.55.129 with SMTP id d1mr7939500qtc.167.1502978179281; Thu, 17 Aug 2017 06:56:19 -0700 (PDT) Received: from cavall.ether.lede.home (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id k184sm674254qkf.40.2017.08.17.06.56.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 06:56:18 -0700 (PDT) From: Ted Lemon Message-Id: <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_268BB982-BE83-4769-A757-C28E208BAE50" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 09:56:17 -0400 In-Reply-To: Cc: dnsop WG To: Lanlan Pan References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 13:56:23 -0000 --Apple-Mail=_268BB982-BE83-4769-A757-C28E208BAE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 17 ag 2017, a les 0:09, Lanlan Pan va escriure: > We can use SWILD to optimize it, not need to detecting, just remove = items which SWILD marked, to save cost. So, can you talk about how your proposal saves cost over using a = heuristic? > 2) cache miss > All of temporary subdomain wildcards will encounter cache miss. > Query xxx.foo.com , then query yyy.foo.com = , zzz.foo.com , ... > We can use SWILD to optimize it, only query xxx.foo.com = for the first time and get SWILD, avoid to send = yyy/zzz.foo.com queries to authoritative server. Can you characterize why sending these queries to the authoritative = server is a problem? > 3) DDoS risk=20 > The botnet ddos risk and defense is like NSEC aggressive wildcard, or = NSEC unsigned. > For example, [0-9]+.qzone.qq.com is a popular = SNS website in China, like facebook. If botnets send "popular website = wildcards" to recursive, the cache size of recursive will rise, = recursive can not just simply remove them like some other random label = attack. > We prefer recursive directly return the IP of subdomain wildcards, and = not rise recursive cach, not send repeat query to authoritative. Why do you prefer this? Just saying "we prefer ..." is not a reason = for the IETF to standardize something. There are a bunch of problems with your proposal, as I'm sure others = have remarked before. It breaks DNSSEC validation for stub resolvers = that aren't aware of SWILD. In the absence of DNSSEC validation, it = creates a new and very effective spoofing attack (poison the cache with = bogus SWILD records). Etc. So you need to clearly explain why it is that you prefer this approach, = and not just say that it's something you like. Are you using it in = production? Do you have data on what it does? Do you have data on = the behavior of real-world caches that you can cite that shows that = SWILD would produce more of an improvement than just using a better = cache aging heuristic? --Apple-Mail=_268BB982-BE83-4769-A757-C28E208BAE50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 17 ag 2017, a les 0:09, Lanlan Pan <abbypan@gmail.com> = va escriure:
We = can use SWILD to optimize it, not need to detecting, just remove items = which SWILD marked, to save cost.

So, can you talk about how your proposal saves cost = over using a heuristic?

2) cache miss
All of = temporary subdomain wildcards will encounter cache miss.
Query xxx.foo.com,  then query yyy.foo.com, zzz.foo.com, ...
We can use SWILD to optimize it,  only query xxx.foo.com for the first = time and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative server.

Can = you characterize why sending these queries to the authoritative server = is a problem?

3) DDoS risk
The botnet ddos risk and defense is = like NSEC aggressive wildcard, or NSEC unsigned.
For = example,  [0-9]+.qzone.qq.com is a popular SNS website in China, like = facebook. If botnets send "popular website wildcards" to = recursive,  the cache size of recursive will rise, recursive can = not just simply remove them like some other random label attack.
We prefer recursive directly return the = IP of subdomain wildcards, and not rise recursive cach, not send repeat = query to authoritative. =

Why do you prefer this?   Just saying "we prefer ..." is = not a reason for the IETF to standardize something.

There are a bunch of = problems with your proposal, as I'm sure others have remarked before. =   It breaks DNSSEC validation for stub resolvers that aren't aware = of SWILD.  In the absence of DNSSEC validation, it creates a new = and very effective spoofing attack (poison the cache with bogus SWILD = records).   Etc.

So you need to clearly explain why it is that you prefer this = approach, and not just say that it's something you like.   Are you = using it in production?   Do you have data on what it does?   = Do you have data on the behavior of real-world caches that you can cite = that shows that SWILD would produce more of an improvement than just = using a better cache aging heuristic?

= --Apple-Mail=_268BB982-BE83-4769-A757-C28E208BAE50-- From nobody Thu Aug 17 07:14:01 2017 Return-Path: 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 ABDB813241F for ; Thu, 17 Aug 2017 07:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=aurxppVS; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=bWqAh5mD 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 luIsXHs6DUfV for ; Thu, 17 Aug 2017 07:13:57 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A77F413264C for ; Thu, 17 Aug 2017 07:13:55 -0700 (PDT) Received: (qmail 46143 invoked from network); 17 Aug 2017 14:13:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b43d.5995a4a2.k1707; bh=McndEuIAKOEDPee2PLgDiPJJ4tsEbFtQgMyxD7pIT2k=; b=aurxppVSzEXyjW+CzcHYuOTVq1oosvWio46ijepGAM4fHqGljCoasWA36A2nIhVe2f7GNo6u2iimppnDS0eHhb1P8x7dbgZHRahNzspLvZAwlKuv5Ib3qsO1Prix+9M5PI2J/Eh7t60Jb1iYRMPHlegONcrvtUyKBQqmrLw12n+9kJG9Ugpu7T4Eda4lGhtpmehZqbteA1QsCO3gGgjFaz4/RVsa/wNyy2YoI0n3yTG/fU0LWdrXr7J2GpbdXq9l DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=b43d.5995a4a2.k1707; bh=McndEuIAKOEDPee2PLgDiPJJ4tsEbFtQgMyxD7pIT2k=; b=bWqAh5mDEcnUQA2vdSrARYksOhfeur5NvDSTuk/0sd3b5xiGsLXHfg8rErPQOJrIF8u6P+I8VcmET2Zf+6N8ntdDhChG6UtvXTIjf7BRGey6qPUZIWcmjh1cPB1ALzJlrWb/2aMzM99VhUH8UFy+1Okk4mSwhkJWui1OXGDISrvw9oNZE95AKxMwaXlBpMflLsTbFSmZLgmNN4lQBLhe7KWGkz2rGKOX3Ep9ZuS0a4Ppuh1a7KpSGrhckimFJJs0 Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 17 Aug 2017 14:13:54 -0000 Date: 17 Aug 2017 10:13:54 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: dnsop@ietf.org In-Reply-To: <20170817034747.0F82D8298B68@rock.dv.isc.org> References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 14:13:58 -0000 On Thu, 17 Aug 2017, Mark Andrews wrote: > Or you can have credentials to allow the hoster to update the DS > records alone. Of course, but that's independent of how you present the updates to the registry or registrar. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 17 08:01:34 2017 Return-Path: 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 B11D4132153 for ; Thu, 17 Aug 2017 08:01:31 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 rgk9cK83Z8tQ for ; Thu, 17 Aug 2017 08:01:29 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBB51252BA for ; Thu, 17 Aug 2017 08:01:29 -0700 (PDT) Received: (qmail 50900 invoked from network); 17 Aug 2017 15:01:28 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 17 Aug 2017 15:01:28 -0000 Date: 17 Aug 2017 15:01:06 -0000 Message-ID: <20170817150106.5492.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: mkwst@google.com In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 15:01:32 -0000 In article you write: >2. I know I don't have enough expertise in this area to make an informed >decision, and smart folks on this thread and elsewhere have told me that an >insecure delegation would be better than status-quo. I added >https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05#section-4.2 >to the document on that basis. The problem with asking for an insecure root delegation is that the IETF has no process for putting anything in the root. In principle we could work something out with ICANN, but that process would take somewhere between a very very long time and forever. It is likely to be hijacked by other people who also want special treatment for their pet TLDs which is why my estimate would be closer to forever. So my inclination would be to say that localhost lookups that reach the root will get a secure NXDOMAIN, which one could take as a hint that it's time to update the stubs and caches that let the query leak. We don't have to work this out now, we can adopt the document and figure out what to fix later. R's, John PS: For anyone who was going to say what about .ARPA, it was in the root a long time before ICANN existed. From nobody Thu Aug 17 08:16:40 2017 Return-Path: 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 A3BFA1320D8 for ; Thu, 17 Aug 2017 08:16:38 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 EdiKRoIOKWcj for ; Thu, 17 Aug 2017 08:16:36 -0700 (PDT) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id E55641241FC for ; Thu, 17 Aug 2017 08:16:35 -0700 (PDT) Received: by nyx.guxx.net (Postfix, from userid 107) id 658A45F40045; Thu, 17 Aug 2017 17:16:27 +0200 (CEST) Received: from [172.27.7.23] (unknown [75.104.69.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 067335F40045; Thu, 17 Aug 2017 17:16:20 +0200 (CEST) From: "Ralf Weber" To: "Lanlan Pan" Cc: "Ted Lemon" , "dnsop WG" Date: Thu, 17 Aug 2017 11:16:20 -0400 Message-ID: <78BBBA80-9FAA-4F18-9EDC-F93A2790E226@fl1ger.de> In-Reply-To: References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 15:16:39 -0000 Moin! On 17 Aug 2017, at 0:09, Lanlan Pan wrote: > Yes, I agree, in fact the *online cache rate* is small (0.12% queries), LRU > & TTL works fine. > SWILD not save many online cache size, because of the queries rate. > And Temporary Domain Names/ All Names: 41.7% for 7 days statistics, the > rate can be about 10% for 1 day statistics. Because temporary domain names > expire after TTL time. Ralf has similar curious. As you mention me, with the data you supplied it is highly unlikely that a lot of records will still be active in the Cache because of the TTL and how least recently used (LRU) algorithms work. > The problem is: > > 1) cache size > Recursives commonly cache "all queried domain in n days" for some > SERVFAIL/TIMEOUT condition, which has been documented in > https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01 That is not what the draft suggest and is not what the current implementations of this or similar features do. They all rely on a cache with a fixed size and if the record that normally would be expired is still in the cache extend it's lifetime when queried. The records you mention are not queried and thus would be expired because other records that are queried more frequently would have overwritten them anyway. There also is nearly no harm if these queries fail in case the authoriative is not responding as most of those queries you describe are computer and not human generated. The draft above and similar techniques where done because of the twitter.com problem. Now I can assure you that twitter.com will always be hot (asked at least every couple of seconds) in a regular resolver at your ISP or a provider of DNS services, and thus the expired record will probably still be in the cache. > The subdomain wildcards cache are needlessly, we can use heuristics > algorithm for deciding what to cache, or just use simple rule like "select > domain which queies time > 5 in last n days". > We can use SWILD to optimize it, not need to detecting, just remove items > which SWILD marked, to save cost. The cost of sending a query now and then is very low resolvers do that all the time and the rate on which they have to do that is very low. However to actually save costs you would have to deploy your proposal on the authoritative server that have that behaviour and the resolvers. Good luck with that. I also assume some of the authorities are actually interested in the queries so they would not implement your proposal even if they could, making the theoretical improvement of 0.12% even smaller. > 2) cache miss > All of temporary subdomain wildcards will encounter cache miss. > Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... > We can use SWILD to optimize it, only query xxx.foo.com for the first time > and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative > server. See above. > 3) DDoS risk > The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSEC > unsigned. > For example, [0-9]+.qzone.qq.com is a popular SNS website in China, like > facebook. If botnets send "popular website wildcards" to recursive, the > cache size of recursive will rise, recursive can not just simply remove > them like some other random label attack. As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall attacks as others call them are usually asking every subdomain once (and these botnets take great care on doing this) the record would be removed by the least recently used (LRU) algorithm when other records that are used more are questioned. While these attacks on recursive resolvers can stress the recursive to authoritative part of the resolver there are techniques to limit the exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring Workshop in Amsterdam on that topic: https://indico.dns-oarc.net/event/21/contribution/29 and the summary of it is that all major vendors of recursive resolvers handle this, so again while your solution would be one once universally deployed there are already solutions to the problem out there, so why do another one? So long -Ralf From nobody Thu Aug 17 09:57:17 2017 Return-Path: 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 D3B8F132195 for ; Thu, 17 Aug 2017 09:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 sasIJ5SmeO2t for ; Thu, 17 Aug 2017 09:57:14 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C856A132190 for ; Thu, 17 Aug 2017 09:57:14 -0700 (PDT) Received: from cvpn-234.vpn.nominum.com (unknown [64.89.232.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 2630B1B8179; Thu, 17 Aug 2017 09:57:14 -0700 (PDT) From: Brian Wellington Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 09:57:14 -0700 References: <5A6662B6-1857-4A9B-ABF5-9EB01BD94608@vpnc.org> <59933D59.3090407@redbarn.org> <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> <59932F2F.9030504@redbarn.org> <20170815194607.GY8146@mournblade.imrryr.org> <599366CE.6040003@redbarn.org> To: dnsop@ietf.org, paul@redbarn.org In-Reply-To: <599366CE.6040003@redbarn.org> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 16:57:16 -0000 > On Aug 15, 2017, at 2:25 PM, Paul Vixie wrote: > > > > Viktor Dukhovni wrote: >> On Tue, Aug 15, 2017 at 10:28:15AM -0700, Paul Vixie wrote: >> ... >>> >>> We can specify that AAAA be sent as additional data for QTYPE=A, and >>> that A be sent as additional data when QTYPE=AAAA. >>> >>> given identical deployment curves along both the ANYA and >>> additional-data timelines, we will get identical results. >> >> +1, by far simpler/cleaner than adding a new RR type. > > viktor, if you write this up and submit it as an i-d, i agree to review it. I volunteer to review this, as well. Brian From vladimir.cunat@nic.cz Tue Aug 15 04:43:22 2017 Return-Path: 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 7EAD513208E for ; Tue, 15 Aug 2017 04:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 W1Y0gVtTbtpn for ; Tue, 15 Aug 2017 04:43:20 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 3B18012700F for ; Tue, 15 Aug 2017 04:43:20 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1::3e0] (unknown [IPv6:2001:718:1a02:1::3e0]) by mail.nic.cz (Postfix) with ESMTPSA id 36007623D2; Tue, 15 Aug 2017 13:43:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502797398; bh=RNDDPKPmsW0qw0SSwVN5ycmevsQx5lgujoCb9GKV9Oc=; h=To:From:Date; b=mj3UIKBz+XXR6qArd+UVeBrW3moTHBC5G5hZNCFUgujL5FGNHQFy5+JCiMJJ/iGKI SJowwYeFZFMmL0TBrL2mQ75kLQICwzhkRjb7JG8NNZ638h0g3R88AzBVQ0BX1swHcT 8oYejKYRB01KWynoqPmOpRPEaVJ59mkld2wuSoAg= To: Jared Mauch Cc: dnsop@ietf.org References: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Message-ID: <6dbedb89-2cb2-ae56-ebd8-8102b23c422c@nic.cz> Date: Tue, 15 Aug 2017 13:43:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <9EED4C56-8B35-4013-861D-0B86F66483E0@puck.nether.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Thu, 17 Aug 2017 13:57:13 -0700 Subject: Re: [DNSOP] opportunistic refresh and Happy Eyeballs X-BeenThere: dnsop@ietf.org 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: Tue, 15 Aug 2017 11:44:55 -0000 On 08/15/2017 01:27 PM, Jared Mauch wrote: >> On Aug 15, 2017, at 3:25 AM, Mikael Abrahamsson wrote: >> >> What is the opinion of this wg on that topic? > There has been much discussion about doing away with any/255 and I seem to recall some discussion of a ANYA type which would return AAAA and A. > > This is something I see value in being implemented. I can't see how that is relevant, really. Either you ask two separate queries or you might ask one for ANYA. --Vladimir From nobody Thu Aug 17 14:11:23 2017 Return-Path: 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 8E1E01321EF for ; Thu, 17 Aug 2017 14:11:22 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 NHVWhMV1-z1W for ; Thu, 17 Aug 2017 14:11:20 -0700 (PDT) Received: from calcite.rhyolite.com (calcite-v6.rhyolite.com [IPv6:2001:470:4b:581::3]) (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 4B49F1321BF for ; Thu, 17 Aug 2017 14:11:20 -0700 (PDT) Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.15.2/8.15.2) with ESMTPS id v7HLB3Ot078274 (CN=www.rhyolite.com version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for env-from ; Thu, 17 Aug 2017 21:11:04 GMT Received: (from vjs@localhost) by calcite.rhyolite.com (8.15.2/8.15.2/Submit) id v7HLB3kQ078273 for dnsop@ietf.org; Thu, 17 Aug 2017 21:11:03 GMT Date: Thu, 17 Aug 2017 21:11:03 GMT From: Vernon Schryver Message-Id: <201708172111.v7HLB3kQ078273@calcite.rhyolite.com> To: dnsop@ietf.org X-DCC-Rhyolite-Metrics: calcite.rhyolite.com; whitelist Archived-At: Subject: [DNSOP] dnsop@ietf.org X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 21:11:22 -0000 > From: Paul Vixie > there will in my model be only one resolver, and while it may or may not > be trusted to tell the truth, it may or may not also be trusted to tell > a useful lie. that is, truth has value, and some lies also have value, > for example an RPZ answer of NXDOMAIN when the qname is a DGA. but right > now we have no authentication of the lies, while we do have it for the > truth (if DNSSEC is used). so, i am conflating two issues in my > stick-figure of the moment: authentication of lie source and content, > and, the ability of an end-user via resolv.conf or API to tell her local > applications what lie-source to believe, if any. I separate those issues into 1. authenticating (signing) AD=1 in responses from resolvers to stubs. This is needed wherever the resolver is not reached by "localhost" and in some cases even where "localhost" is used. Most stubs do not reach their resolvers via localhost and either trust unsigned AD bits or ignore them. Either case makes DNSSEC almost a sham. This needs protocol work or the routine use of TSIG on requests and something for key distribution or public keys with TSIG or something else, new or old. This is not an RPZ issue. 2. applications that demand truth getting it instead of RPZ lies from resolvers that do RPZ filtering. > i'm on a different trail entirely. we have to include the truth if it's > dnssec signed, since the client will know we're lying if we do > otherwise. ... How does a stub know that the resolver gave an RPZ lie via DNSSEC? RPZ lies don't include RRSIGs. Would the stub interate to get NS, A, AAAA, and RRSIG rrsets starting with the root and then either fail to get RRSIGs somewhere in the chain and stop with "oh, never mind", or check that signature chain against the rrset it got a long time ago from the resolver? The stub probably needs a cache for all of those rrsets, including caching the absense of RRSIG rrsets. It must pay attention to authority sections and the right rrsets in additional sections. It would need to resolve CNAME (and DNAME?) chains. And so forth for a lot of what makes a recursive resolver. On the other hand, a stub could not worry about DNSSEC and watch for the special RPZ SOA in the additional sections of RPZ lies, and when it sees one, ask again for truth. On the third hand, a stub working for an application that wants truth could always ask for truth instead of RPZ filtering. As I keep saying only debugging applications want both truth and lies, and they don't need both at once (and couldn't receive both through current APIs). They could make two requests of the stub, one for truth and one for lies. I think the second hand is much better that the first and the third is best. Not only do they not force stubs to become resolvers, they give truth to applications that want it even when DNSSEC is not involved (as it won't be if ever in almost all of com and net). Applications that want truth instead of RPZ lies don't care whether DNSSEC was involved; they just want the resolver's best shot at the truth. They might separately want to tell the stub to discard anything from the resolver that lacks a (signed) AD=1. Note that RPZ lies are distinguished by the following and only the 3rd is dispositive: - no RRSIG rrsets - AD=0 - that bogus additional section SOA Vernon Schryver vjs@rhyolite.com From nobody Thu Aug 17 15:22:10 2017 Return-Path: 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 46F0D1323CA for ; Thu, 17 Aug 2017 15:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 neuJ3AExlyGa for ; Thu, 17 Aug 2017 15:22:07 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D80132356 for ; Thu, 17 Aug 2017 15:22:07 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 77so253740itj.1 for ; Thu, 17 Aug 2017 15:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=k+Jnm7KvQ0zzHqY9KajUrdZ1zNc4cAMJRFTFRLD/WUQ=; b=JsnU7ZC/3TUA2fMrCrrpRy8eiCKswXM9NF0C//BI1TE6BUPpp9Gmv6HZcyUFH+PKMf ac6N98fTRs2y4AplsijFhjxMPORuCfasy9nzUTzAtdrXHAZWnG5MjKDGS7QOi/O/edmG yAJ5QMxAKNHXGSheodKIIiwvpHfULvkZSOtSgl63fUApRXcfkmOlspmXdoCd0lkAy7ZW K5ED5cI2mlCWUbpfmy8azqt68ntOYq2BSoSz7BjJ90L6blr2wv2xN0KqEvwo1szjHPeP Yvtx1sEBs9AuKgwSWVJhDgLPtrYOYXK+By0fmciKjOWHerxC4cIEBtWUaioLs6sKA0aK jzGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k+Jnm7KvQ0zzHqY9KajUrdZ1zNc4cAMJRFTFRLD/WUQ=; b=JFO0fvtrsGT+ZXu3QVfoc9U9L0Oy9umeYdy6bB0PlFU+VPCSTU+B/tbjBbzBzVbj4b i021DYf0FmCGlb1wugvgvVRaBE1XwXlNP1kzpbN0/fePaTlEvnZc/hy68fQQlgRVV0BE 4gA2bXffO7vDz2OKYh0Jr/fZJseOSNHv0oIu9s1sLJYoo17MVNsyrOTaRNslGpaEmVH9 Ek1TLu3Va7K4lMUwSbYoLRXdTZyiarY4cdnQ73xR8TbeIu3dxCw50wzXlp6swC5rMUrD znLLuVy0k6Cy1+02xRu4ZyM/mtmN5CJ8TdtgNo0si7sDuN6Q4M0Ce7tjA2aojKFTfwiT /fiA== X-Gm-Message-State: AHYfb5iqfqosnww9kp4KQNrADqOTGuaBEThaKLzGEMl3c3854qfpi25h WBtpc4FGmVVZc9FzmDeGK3wBVzM/4g== X-Received: by 10.36.33.73 with SMTP id e70mr31220ita.136.1503008526429; Thu, 17 Aug 2017 15:22:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.107.71 with HTTP; Thu, 17 Aug 2017 15:22:05 -0700 (PDT) From: Brian Dickson Date: Thu, 17 Aug 2017 15:22:05 -0700 Message-ID: To: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1147c5be4ff3c00556fa71d8" Archived-At: Subject: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Thu, 17 Aug 2017 22:22:09 -0000 --001a1147c5be4ff3c00556fa71d8 Content-Type: text/plain; charset="UTF-8" The discussions about localhost (and 127.0.0.1 and ::1) have ben very enlightening. However, I wonder whether the desired use case -- reliably establishing a connection to a host, based on information in DNS -- might be more securely/reliably solved using other mechanisms? Using "localhost" is basically making unilateral assumptions (and using ::1 or 127.0.0.1 equally so). I think the reliability, and possibly the security, are better achieved with bilateral mechanisms. E.g. If the specific use case is a client trying to talk to a server, on a particular port and protocol, then a more robust method of determining that the server offers such a service, would be using SRV or URI records. When the client, resolver, authority server, and service-server may not be tightly coupled, it might require additional enhancements, such as client subnet (or similar), to ensure the appropriate answer is given. The specific value returned to the query might be 127.0.0.1, or might be some other address; the main thing is that the address is deliberately associated with a service that wants the client to use, and presumably the service knows that the client is on the same host. Sorry if this isn't as clear as I intended - basically, what I'm saying, is that the answer might not even be an IP, protocol and port, but might even be a "file:///" URI, for a named pipe, which avoids the whole IP stack. Hope this provides useful ideas which point away from localhost per se. Brian --001a1147c5be4ff3c00556fa71d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The discussions about localhost (and 127.0.0.1 and ::1) ha= ve ben very enlightening.

However, I wonder whether the = desired use case -- reliably establishing a connection to a host, based on = information in DNS -- might be more securely/reliably solved using other me= chanisms?

Using "localhost" is basically= making unilateral assumptions (and using ::1 or 127.0.0.1 equally so).

I think the reliability, and possibly the security, a= re better achieved with bilateral mechanisms.

E.g.= If the specific use case is a client trying to talk to a server, on a part= icular port and protocol, then a more robust method of determining that the= server offers such a service, would be using SRV or URI records.

When the client, resolver, authority server, and service-se= rver may not be tightly coupled, it might require additional enhancements, = such as client subnet (or similar), to ensure the appropriate answer is giv= en.

The specific value returned to the query might= be 127.0.0.1, or might be some other address; the main thing is that the a= ddress is deliberately associated with a service that wants the client to u= se, and presumably the service knows that the client is on the same host.

Sorry if this isn't as clear as I intended - ba= sically, what I'm saying, is that the answer might not even be an IP, p= rotocol and port, but might even be a "file:///" URI, for a named= pipe, which avoids the whole IP stack.

Hope this = provides useful ideas which point away from localhost per se.
Brian
--001a1147c5be4ff3c00556fa71d8-- From nobody Thu Aug 17 17:12:06 2017 Return-Path: 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 DB05213265F for ; Thu, 17 Aug 2017 17:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 FKyrWJMCAQeQ for ; Thu, 17 Aug 2017 17:12:03 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 1EF11132413 for ; Thu, 17 Aug 2017 17:12:03 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 28F5D34A619; Fri, 18 Aug 2017 00:11:56 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 15E66160042; Fri, 18 Aug 2017 00:11:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 037F4160070; Fri, 18 Aug 2017 00:11:56 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pS5rTXXkYZ0M; Fri, 18 Aug 2017 00:11:55 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id B3318160042; Fri, 18 Aug 2017 00:11:55 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 37E9082B0500; Fri, 18 Aug 2017 10:11:53 +1000 (AEST) To: "John R Levine" Cc: dnsop@ietf.org From: Mark Andrews References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> In-reply-to: Your message of "17 Aug 2017 10:13:54 -0400." Date: Fri, 18 Aug 2017 10:11:53 +1000 Message-Id: <20170818001153.37E9082B0500@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 00:12:05 -0000 In message , "John R Levine" wri tes: > On Thu, 17 Aug 2017, Mark Andrews wrote: > > Or you can have credentials to allow the hoster to update the DS > > records alone. > > Of course, but that's independent of how you present the updates to the > registry or registrar. Yet, you chose to attempt to shoot down the proposal based on the premise that you would be giving up full control. Fine grain control using UPDATE has existed in nameservers since 2000. I'm yet to here of anyone doing fine grain control via the web . Mark > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 17 17:37:01 2017 Return-Path: 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 400661323D4 for ; Thu, 17 Aug 2017 17:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 rLJ4HIEfq0bi for ; Thu, 17 Aug 2017 17:36:57 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 6CCE013269A for ; Thu, 17 Aug 2017 17:36:57 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 894AA349314; Fri, 18 Aug 2017 00:36:54 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 624E4160042; Fri, 18 Aug 2017 00:36:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 51803160070; Fri, 18 Aug 2017 00:36:54 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AhVCgLfZr-xW; Fri, 18 Aug 2017 00:36:54 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 05D14160042; Fri, 18 Aug 2017 00:36:54 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 07F2782B0AFE; Fri, 18 Aug 2017 10:36:52 +1000 (AEST) To: "John Levine" Cc: dnsop@ietf.org, mkwst@google.com From: Mark Andrews References: <20170817150106.5492.qmail@ary.lan> In-reply-to: Your message of "17 Aug 2017 15:01:06 +0000." <20170817150106.5492.qmail@ary.lan> Date: Fri, 18 Aug 2017 10:36:51 +1000 Message-Id: <20170818003652.07F2782B0AFE@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 00:36:59 -0000 In message <20170817150106.5492.qmail@ary.lan>, "John Levine" writes: > In article m> you write: > >2. I know I don't have enough expertise in this area to make an informed > >decision, and smart folks on this thread and elsewhere have told me that an > >insecure delegation would be better than status-quo. I added > >https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-05#section > -4.2 > >to the document on that basis. > > The problem with asking for an insecure root delegation is that the > IETF has no process for putting anything in the root. In principle we > could work something out with ICANN, but that process would take > somewhere between a very very long time and forever. It is likely to > be hijacked by other people who also want special treatment for their > pet TLDs which is why my estimate would be closer to forever. Well start now. 'localhost' was special before DNS, DNSSEC and ICANN came into existence. This is completing work that should have been done at the time the root zone was signed. > So my inclination would be to say that localhost lookups that reach > the root will get a secure NXDOMAIN, which one could take as a hint > that it's time to update the stubs and caches that let the query leak. Insecure NOERROR NODATA for A and AAAA are fine. Secure NOERROR NODATA for DS is what is needed. > We don't have to work this out now, we can adopt the document and > figure out what to fix later. > > R's, > John > > PS: For anyone who was going to say what about .ARPA, it was in the > root a long time before ICANN existed. > > _______________________________________________ > 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: marka@isc.org From nobody Thu Aug 17 18:13:51 2017 Return-Path: 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 D1E1F1326D7 for ; Thu, 17 Aug 2017 18:13:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=N7oSv9aw; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=ogV3IGMT 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 QweknxsC2BUA for ; Thu, 17 Aug 2017 18:13:48 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5366F132677 for ; Thu, 17 Aug 2017 18:13:48 -0700 (PDT) Received: (qmail 10233 invoked from network); 18 Aug 2017 01:13:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=27f7.59963f4a.k1707; bh=mtamhDemHpUL+6LjxGASGHtnIBDAnZsQU9dc8HhXXhg=; b=N7oSv9awrFnaFNqSm/NYtKD2i0OFxNN24tkD3Nxx/hnWGDMed7uolicm9soSvFRWRSFJAVmAGed3zjOJEShYaMasytHbmI36c51yrjQc4Rw3/QIl0a+lpo6o09DCUd03Amuv+sYrvYbiBHRl3AE0fXbajpixDEFtI4rr6pLszpzqcraoYomBK305sUpdrGRGo8vs3l9Fb3UB+qwCxnTDDkZZ/RHhF24+7f8KN1rtNrzTyohB7EHcQpOd3qsN1p1b DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=27f7.59963f4a.k1707; bh=mtamhDemHpUL+6LjxGASGHtnIBDAnZsQU9dc8HhXXhg=; b=ogV3IGMTJ+UlxRysuxBIptVr6lwGdRVxE6iUKFkcH+sc2V7c/jFXTxhXfrxctAOBS0/008SFCY4do3/dG0rmJn3swlFRE+YXAmHvTajKf6WZCbHfJXFvXowI1UaWF2EdN6jdfPeWyYoU1VOaG6AWs/8X5xeX1M9BGFGD8P3J0NNI5v/Bl87/bBBRABJFz+NzJ6JzCvlSqSkGMe3fqrRS5/3qbRVtVcbfFglERoBDhXo7dflOytplNIzTOoj4JH5p Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 18 Aug 2017 01:13:46 -0000 Date: 17 Aug 2017 21:13:45 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: dnsop@ietf.org In-Reply-To: <20170818001153.37E9082B0500@rock.dv.isc.org> References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> <20170818001153.37E9082B0500@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 01:13:50 -0000 On Fri, 18 Aug 2017, Mark Andrews wrote: >>> Or you can have credentials to allow the hoster to update the DS >>> records alone. >> >> Of course, but that's independent of how you present the updates to the >> registry or registrar. > > Yet, you chose to attempt to shoot down the proposal based on the > premise that you would be giving up full control. You appear to be responding to someone else. My point is that in practice, registries do not provide credentials for DNSSEC updates only, regardless of how they're presented. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 17 18:15:44 2017 Return-Path: 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 E62A0132707 for ; Thu, 17 Aug 2017 18:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=uRWZy+X4; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=Sn1Dyp5g 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 25fxpQmbFexC for ; Thu, 17 Aug 2017 18:15:31 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6D5132143 for ; Thu, 17 Aug 2017 18:15:31 -0700 (PDT) Received: (qmail 10569 invoked from network); 18 Aug 2017 01:15:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=2947.59963fb2.k1707; bh=A/R/jiFXU0nQB+mu8nvuYmG73qJJTNSHdD6Itb28Y64=; b=uRWZy+X4dh8NOHvMc7EJz8C+2mkeVAi9z4CsyD+tePIa/zvq3NNwkIyiMEdvgOAtDR+5xmiitK4PMrbr/goOPQtE2crgmuTxs5CzkeroWnW6jdBeQBtvE2SpYOwzfEnZgRNGL2zARVTtvnqBQ4Kj1D0l+LGN4Z0rITWvnWSC7ze0/vVYu7ToWxxc719xbYIDg+FX2JRamhWjPZWaX8YTAxToKbH2CkPr2sHLq8VUjrL/czUPdrgKR7WF1P0m7+29 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=2947.59963fb2.k1707; bh=A/R/jiFXU0nQB+mu8nvuYmG73qJJTNSHdD6Itb28Y64=; b=Sn1Dyp5g6B78yh0y/mUN6OLd/u4KuXPTSAESQx+/F1JeFZ/hLAL10mI12P9mAY8QtdOIFr5y7gCw+8k/GRwGaUIc8kBek4chNkUXgXhlvN6qci6Qg4nYYH9SRlOtFR8N70O4TjEWujGfXXy/yFkC/cA5BfodHnlcAdBk+XyPJtV0ASLO585M5Ni205cCFM6QBq30gS+EaUjwsO6JWxWkFLpbgPdgGXC07adaG5XOH0/j2yYk9tLFgJ8ifZbLghkG Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 18 Aug 2017 01:15:30 -0000 Date: 17 Aug 2017 21:15:29 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: dnsop@ietf.org, mkwst@google.com In-Reply-To: <20170818003652.07F2782B0AFE@rock.dv.isc.org> References: <20170817150106.5492.qmail@ary.lan> <20170818003652.07F2782B0AFE@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] Status of "let localhost be localhost"? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 01:15:33 -0000 On Fri, 18 Aug 2017, Mark Andrews wrote: > Insecure NOERROR NODATA for A and AAAA are fine. Secure NOERROR NODATA > for DS is what is needed. If you believe that's important (I don't) the stubs and caches can special case that, too, of course. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Thu Aug 17 18:28:48 2017 Return-Path: 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 6D143132723 for ; Thu, 17 Aug 2017 18:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 5R0zv98ofaCy for ; Thu, 17 Aug 2017 18:28:44 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727B91326E1 for ; Thu, 17 Aug 2017 18:28:44 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o124so37649035qke.3 for ; Thu, 17 Aug 2017 18:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pXIWFanqkqD36Ogf7OfnQODj4AttvJd+lLglxD8kAvc=; b=QEooV5fsfQc8ZKxLWlkwm/foiv1tZoUwHhBRmDhm5vZtriS/4UgMMNgyiKE3h4JTV8 jgusCA+zgBJJ6HfSGEJijY/teyRnWnaA2EhEEsI9RyG0nfcUgB890yBP+hmxIhg81r+w 2r+haa8V1iUeYY+NgaZbxtW5y1to4Cgv6bhkrtl72djvs8IiKpCbf7EN1EvpUWSOzeiy QAh4A+OmRm1Q5RvFTGZsSMy5gGrfr+Vc86f2VMZNNl3mhZTIEO0H74vqo4tZdNpxPRDZ eEOUDr/r0ySQsFT5ZQLi/UiTosmeahwZgv/npV0O2uzZB3MYdwWjMnzhi9p0DreZDx+C upTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pXIWFanqkqD36Ogf7OfnQODj4AttvJd+lLglxD8kAvc=; b=cX40aK5MVp1/eN/MXzlJPr2eEtbkYWAZuJAZiv9tQeIb0AUusudDGfKV7ydjxkCZwt XbaPnzJHpj6fYAq3VZMY2+U4AZj2Oug5Pd4ngfYdvIvSSQuibxCm9bx6VwWxJWbWiKO6 ib7ThMernjaimiPEUP1Jc2mOZsB0RurIFwE1kPfpWSQjjcWR82SXadZn4/ThcxRerH5o qRk1fMbhFEqzP9xbgUJyPXpaQrVSsAxZK7sTxBRhxO5tGhJ76ObmCXadDTrsOOnLUXHG KpVASjYX69dcUQnQCm14pJtDfsBTZPu+U+0CYsxpJxL7O92zYd7NBzBQyrlBFwpVWK58 renw== X-Gm-Message-State: AHYfb5jpi53xQ27rF62FCrShu+NgLVR3yjNwYbaGCMdlS9hymFilpfcn uy4Aesp9TYzagiBi X-Received: by 10.55.124.67 with SMTP id x64mr10008217qkc.98.1503019723627; Thu, 17 Aug 2017 18:28:43 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id c50sm3267900qte.55.2017.08.17.18.28.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 18:28:42 -0700 (PDT) From: Ted Lemon Message-Id: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_791FF05B-E70D-4C17-A2F6-E46DB9C3CD14" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 21:28:40 -0400 In-Reply-To: Cc: "dnsop@ietf.org WG" To: Brian Dickson References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 01:28:47 -0000 --Apple-Mail=_791FF05B-E70D-4C17-A2F6-E46DB9C3CD14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 17 ag 2017, a les 18:22, Brian Dickson = va escriure: > Sorry if this isn't as clear as I intended - basically, what I'm = saying, is that the answer might not even be an IP, protocol and port, = but might even be a "file:/// " URI, for a named pipe, which = avoids the whole IP stack. It's hard to see how this is going to help. What we are trying to do = here is bypass DNS; now you are asking us to go through DNS to get the = name of a local resource and contact it. So really you've just = increased the attack surface. --Apple-Mail=_791FF05B-E70D-4C17-A2F6-E46DB9C3CD14 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 17 ag 2017, a les 18:22, Brian Dickson <brian.peter.dickson@gmail.com> va = escriure:
Sorry if this isn't as clear as I intended - basically, what = I'm saying, is that the answer might not even be an IP, protocol and = port, but might even be a "file:///" = URI, for a named pipe, which avoids the whole IP = stack.

It's hard to = see how this is going to help.   What we are trying to do here is = bypass DNS; now you are asking us to go through DNS to get the name of a = local resource and contact it.   So really you've just increased = the attack surface.


= --Apple-Mail=_791FF05B-E70D-4C17-A2F6-E46DB9C3CD14-- From nobody Thu Aug 17 18:36:11 2017 Return-Path: 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 E6BC91326E1 for ; Thu, 17 Aug 2017 18:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 r4p46Oq1PIQY for ; Thu, 17 Aug 2017 18:36:09 -0700 (PDT) Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1003E132413 for ; Thu, 17 Aug 2017 18:36:09 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id F00CB24AE3D; Fri, 18 Aug 2017 01:35:57 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DECF6160042; Fri, 18 Aug 2017 01:36:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C5ED4160070; Fri, 18 Aug 2017 01:36:03 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NFR_hKcq6RyB; Fri, 18 Aug 2017 01:36:03 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6E923160042; Fri, 18 Aug 2017 01:36:03 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 473E582B17D6; Fri, 18 Aug 2017 11:36:01 +1000 (AEST) To: "John R Levine" Cc: dnsop@ietf.org From: Mark Andrews References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> <20170818001153.37E9082B0500@rock.dv.isc.org> In-reply-to: Your message of "17 Aug 2017 21:13:45 -0400." Date: Fri, 18 Aug 2017 11:36:01 +1000 Message-Id: <20170818013601.473E582B17D6@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 01:36:11 -0000 In message , "John R Levine" writes: > On Fri, 18 Aug 2017, Mark Andrews wrote: > >>> Or you can have credentials to allow the hoster to update the DS > >>> records alone. > >> > >> Of course, but that's independent of how you present the updates to the > >> registry or registrar. > > > > Yet, you chose to attempt to shoot down the proposal based on the > > premise that you would be giving up full control. > > You appear to be responding to someone else. My point is that in > practice, registries do not provide credentials for DNSSEC updates only, > regardless of how they're presented. And the proposal was for registrars to process them except in the case where the registry and registrar are the same entity. The only thing the registry needs to run is a forwarding agent which looks at the name of the zone to be updated (sanity checking and possible database selection for the next step) and the name of the first record to be updated in the update section to find which registrar to forward the update to. This is similar to how nsupdate works out which zone to update without being told explicitly. All validation (TSIG/SIG(0)), beyond is the UPDATE in scope, is done by the registrar which doesn't require the registry to handle any credentials. > Regards, > John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 17 18:54:11 2017 Return-Path: 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 0ACC313274F for ; Thu, 17 Aug 2017 18:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QbafuHcxM4YG for ; Thu, 17 Aug 2017 18:54:07 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0071132409 for ; Thu, 17 Aug 2017 18:54:07 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id 76so1722509ith.0 for ; Thu, 17 Aug 2017 18:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zmzYzZgLpjaSx8rlhFhfsqKLY149LPUEECGy7lbc2HU=; b=DCeUItxtYsrD1eBefWcvHDzSvS5jy3ZlKZHllmmBFjLHKZBWI3OdGCCoWIe8BGxr3k rdk2XwlpE6l2YuWLV4AMkN+PKQdxej0X219+EbqMQsLIWcu5+ZunfuXGxFkJSOkR1o7K HyZRi5yGE91m8zg8R2iKWcuR6xt1DOAEiMOVqHD/NTuvOYvyElZMmV49I6QOSXuL6ar0 rgAf5yuH9Vp3m/cikM1WQgmH3G7TpKtKaXFhSE5n6Ym5D/BOeBeFHz4HvCd5nl5BjER1 mfXOc3JuQYjTZUMYuBqN7lmHoqWkwMzKHknK7xc/+Ze5o5blsXOGsv6/ZrnOgjfHqM/s m6Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zmzYzZgLpjaSx8rlhFhfsqKLY149LPUEECGy7lbc2HU=; b=GTTcyPjKLLbY8zdfcn1ex6GrAAgA1QNai8K6EVyu0pwWHeUyM+TShNy8v6SR4+Laye mIwiPenDUhwXSFYXVezDhIpFE0hE4DRpcHymlVdyKPYchIiuKEwfTRgk0ugxWX44hZ6x 560xasYg2o08eCYna2qA+fnJq67SDuyBLjd6NXEwrRlMtL3Bm/YmZdMhU+okK0dF/fl9 ADdk/XIhAT//22YjAtlWWmjOYuRROUD6GBDdE+6B9qQ0qOXG67vemcXrQTpRrSJJGbkk 97i3z8HC8Iy3V5eT+mxRqR1X76mbrFFPxNKMRwMkQH942l998Eo5Xjvbwxb0JGZtbTEU XUhA== X-Gm-Message-State: AHYfb5joE0FCZiC264uEwPPuqux3mBu9o2vJsyxP/pq+aWeQwP/yZgJn 4JSF2TnFtId8T26dk2DJnUAYaAZhgQ== X-Received: by 10.36.116.3 with SMTP id o3mr411230itc.62.1503021245951; Thu, 17 Aug 2017 18:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.107.71 with HTTP; Thu, 17 Aug 2017 18:54:05 -0700 (PDT) In-Reply-To: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> References: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> From: Brian Dickson Date: Thu, 17 Aug 2017 18:54:05 -0700 Message-ID: To: Ted Lemon Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a114aa4687474ff0556fd6757" Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 01:54:10 -0000 --001a114aa4687474ff0556fd6757 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 17, 2017 at 6:28 PM, Ted Lemon wrote: > El 17 ag 2017, a les 18:22, Brian Dickson > va escriure: > > Sorry if this isn't as clear as I intended - basically, what I'm saying, > is that the answer might not even be an IP, protocol and port, but might > even be a "file:///" URI, for a named pipe, which avoids the whole IP > stack. > > > It's hard to see how this is going to help. What we are trying to do > here is bypass DNS; now you are asking us to go through DNS to get the name > of a local resource and contact it. So really you've just increased the > attack surface. > > If you're trying to use "localhost", that means you're using some kind of name resolution, whether it be DNS, /etc/hosts, NIS+, or anything else. I'm suggesting that by using DNS, you can take advantage of what DNS has to offer, which includes potentially DNSSEC. There is a bootstrap problem, in that the client might have to know something about its own name... In the use case, are you trying to bypass DNS because you don't trust it? That part isn't really clear. What are the assumptions that are being made, best case vs worst case, and which are known to be "guaranteed"? Is the server doing dynamic update to whoever its DNS authority is? Is DNSSEC an option (sometimes?) or not... etc. So, here's one model that might work. Put the "localhost" at the deepest part of the namespace, *below* the host name. I.e., if my name is fully.qualified.domain.name, then I "control" my own name and things below it, and do an update for " localhost.fully.qualified.domain.name". IFF that name exists, then the server is smart enough to be assumed to be listening on whatever IP address (v4 or v6) is registered, and the client can reasonably trust that. Using SRV at that point is maybe overkill, maybe not (depending on the trust model). Add DANE stuff if you really want to do some kind of validation, etc. Or use URI for getting off the IP stack, if "file:///" makes sense. I think someone should write up the problem statement, since it is possible that what you really want has nothing to do with localhost, and having the "let localhost" kind of presumes the solution before identifying the real problem... What are you actually trying to do, and why? Brian --001a114aa4687474ff0556fd6757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 17, 2017 at 6:28 PM, Ted Lemon <mellon@fugue.com> wrote:

It&= #39;s hard to see how this is going to help. =C2=A0 What we are trying to d= o here is bypass DNS; now you are asking us to go through DNS to get the na= me of a local resource and contact it. =C2=A0 So really you've just inc= reased the attack surface.


=
If you're trying to use "localhost", that means yo= u're using some kind of name resolution, whether it be DNS, /etc/hosts,= NIS+, or anything else.
I'm suggesting that by using DNS, yo= u can take advantage of what DNS has to offer, which includes potentially D= NSSEC.

There is a bootstrap problem, in that the c= lient might have to know something about its own name...

In the use case, are you trying to bypass DNS because you don't = trust it? That part isn't really clear.

What a= re the assumptions that are being made, best case vs worst case, and which = are known to be "guaranteed"?

Is the ser= ver doing dynamic update to whoever its DNS authority is? Is DNSSEC an opti= on (sometimes?) or not... etc.

So, here's one = model that might work.

Put the "localhost&quo= t; at the deepest part of the namespace, *below* the host name. I.e., if my= name is fully.qualified.dom= ain.name, then I "control" my own name and things below it, a= nd do an update for "localhost.fully.qualified.domain.name".

IFF that name exists, then the server is smart enough to be assumed = to be listening on whatever IP address (v4 or v6) is registered, and the cl= ient can reasonably trust that.

Using SRV at that = point is maybe overkill, maybe not (depending on the trust model).
Add DANE stuff if you really want to do some kind of validation, etc.
Or use URI for getting off the IP stack, if "file:///" mak= es sense.

I think someone should write up the prob= lem statement, since it is possible that what you really want has nothing t= o do with localhost, and having the "let localhost" kind of presu= mes the solution before identifying the real problem...

What are you actually trying to do, and why?

Brian=C2=A0

--001a114aa4687474ff0556fd6757-- From nobody Thu Aug 17 19:20:25 2017 Return-Path: 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 B5BF7132824 for ; Thu, 17 Aug 2017 19:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 Mbng9WelvuKH for ; Thu, 17 Aug 2017 19:20:22 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5385F132820 for ; Thu, 17 Aug 2017 19:20:22 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x77so2580270qka.5 for ; Thu, 17 Aug 2017 19:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pE4YPT9ZBET8EeHBnJb+hEKU+6YSKv2UaJi9JcZwPEc=; b=xksymi7BGd7k1SfvmMHuo7mifrCIUefZ+0N2Lii2c+N422b8E2tLxO8i4V43RmMhj5 aOkGeHDIMlWZGovD1ysWGptXu/stt82bI6Wi8HG18Kgfv1OP7bZl1QwcJKVU5eHMOchm /fIv6AlYeQl1UY+Za03kcgV76GZfVaGiKj2mySfw70WMFrIRSpR0oK6vfP5JJCpyUDiC J/jszs15TP5AtAyIv3VOWAb4JZDcXzsq2ZUweGcHF2NneT74vSUQdb+N7uTMmvYbMpDf F8OHplePAUuI4qDNv24EgiyYL42osqOLizJRB9BD3RfiztJcMso2dvWgM5Zi2FfDSzzr en+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pE4YPT9ZBET8EeHBnJb+hEKU+6YSKv2UaJi9JcZwPEc=; b=SbrQ/eiQYuIgQ3Ltpuqcqao7hN8v4Y7y6wsblGVcVErtWkkbneeiJhlPVO9oIiq/tl LttLvWr4JjHYlTZgtW0OdxaX/jzbGp+FA6XmplfxJmpqHT1WAxUICVjd9U4kpLeBB1R/ JOjUyEb6fpSbb6fXxFFwwlEhUnhi0UHTzsYc9eVE6Wsl08b6IoxMdl18wWdAeBTcDTma QnXD0FBi2L2y3wi8I656uaNheJLr5QZ5Latb03z0WBUIeTmF/aLcm1AtJdVt7QWc4+Ry PfzbOCmrWnMY2DxCQlP6X35HfaTNYLakaA8vDpSPgdgkjghELuk4lCcLMhR2ZjIjS9gS ibRQ== X-Gm-Message-State: AHYfb5idv0tCjfx1KHmAEBe2wHQzQfVSXuWTi9aVTDyXrjMzyY4qYNoV Cb73OIFbp8mFa4ru X-Received: by 10.55.42.132 with SMTP id q4mr10596808qkq.45.1503022821517; Thu, 17 Aug 2017 19:20:21 -0700 (PDT) Received: from [10.0.30.153] (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id n69sm3032364qke.52.2017.08.17.19.20.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 19:20:20 -0700 (PDT) From: Ted Lemon Message-Id: <69725356-F683-4FAF-A130-D08353D9169F@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_95344181-83BC-4AA9-911A-CADC452AA0B8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 17 Aug 2017 22:20:18 -0400 In-Reply-To: Cc: "dnsop@ietf.org WG" To: Brian Dickson References: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 02:20:23 -0000 --Apple-Mail=_95344181-83BC-4AA9-911A-CADC452AA0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 17 ag 2017, a les 21:54, Brian Dickson = va escriure: > If you're trying to use "localhost", that means you're using some kind = of name resolution, whether it be DNS, /etc/hosts, NIS+, or anything = else. > I'm suggesting that by using DNS, you can take advantage of what DNS = has to offer, which includes potentially DNSSEC. DNSSEC can't work, or even be used, if you are spoofing localhost. If = you used DNSSEC, the answer would fail validation. --Apple-Mail=_95344181-83BC-4AA9-911A-CADC452AA0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 17 ag 2017, a les 21:54, Brian Dickson <brian.peter.dickson@gmail.com> va = escriure:
If = you're trying to use "localhost", that means you're using some kind of = name resolution, whether it be DNS, /etc/hosts, NIS+, or anything = else.
I'm suggesting that by using = DNS, you can take advantage of what DNS has to offer, which includes = potentially DNSSEC.

DNSSEC can't work, or even be used, if you are = spoofing localhost.   If you used DNSSEC, the answer would fail = validation.

= --Apple-Mail=_95344181-83BC-4AA9-911A-CADC452AA0B8-- From nobody Thu Aug 17 19:39:37 2017 Return-Path: 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 EB49D1326E1 for ; Thu, 17 Aug 2017 19:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=pF6dctGO; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=St3yQMT2 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 Zfq9HB1CFmff for ; Thu, 17 Aug 2017 19:39:34 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB13613226B for ; Thu, 17 Aug 2017 19:39:33 -0700 (PDT) Received: (qmail 16680 invoked from network); 18 Aug 2017 02:39:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4126.59965364.k1707; bh=TVE5JcusYEMswIo+QfBegLNXXDBGfXMSTcNX70C1oUY=; b=pF6dctGOsTDc0hsLYFGrmpHr8m4uL/baHSXi3IbcG0zKa4EB7cc1Ld7G0NpbNkZeoHLz8UD/eFeEW3aExEHQcOr5zas1LpVg+H3lRgwPptAMN1GXhbz4y8nV98qWTwmBbFGkXtyM+CwwGHQzLNaf/cJ8vU81Ljnd3NmYM5oqlpPWWGsBsQxTCud5XHlOAthy3gNiVEGi8dWjaTCjBAIj4wSJZ8IyEaNj3XF/qNaQ+mV7Wo75Jv5w90fTq3/wksr/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4126.59965364.k1707; bh=TVE5JcusYEMswIo+QfBegLNXXDBGfXMSTcNX70C1oUY=; b=St3yQMT2E8KvVR53Ugu1cfiTg0ObfWIBj9hhEYc4diM8dEOqEH65e4lqEzHWIPOxYbvDvBXRAjuS67c0fVSdQycZIOWzPfDDJrn9hyOFyJGQHPssfdTuew85bjTHt1tnAOhvlz/kxiMEx+Jkwyazu8D1RGtXl71B64fYHls1KcRz9yYgGHR8ih75RxIfDdTBw6XRhISatDFFNvpF5bGiaPTCiJwIA1C/38ys2+tafk3v6C9KCG4JU+zDKMfwr87q Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 18 Aug 2017 02:39:32 -0000 Date: 17 Aug 2017 22:39:31 -0400 Message-ID: From: "John R Levine" To: "Mark Andrews" Cc: dnsop@ietf.org In-Reply-To: <20170818013601.473E582B17D6@rock.dv.isc.org> References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> <20170818001153.37E9082B0500@rock.dv.isc.org> <20170818013601.473E582B17D6@rock.dv.isc.org> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [DNSOP] updating fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 02:39:36 -0000 On Fri, 18 Aug 2017, Mark Andrews wrote: > And the proposal was for registrars to process them except in the > case where the registry and registrar are the same entity. The > only thing the registry needs to run is a forwarding agent which > looks at the name of the zone to be updated (sanity checking and > possible database selection for the next step) and the name of the > first record to be updated in the update section to find which > registrar to forward the update to. This is similar to how nsupdate > works out which zone to update without being told explicitly. I'm sorry, but once again I can't see how response is related to what you're responding to. It is a business issue whether the DNSSEC records (and the NS for that matter) are updated through the registry or the registrar. Some do it one way, some do it the other, and the registars and registries I've talked to feel very strongly about whichever way they do it. Either way, the problem is that almost none of them issue credentials that let you update a zone's DNSSEC separate from letting you update everything else about a registrant. As I've said a couple of times, where you present those non-existent credentials and whether you do it through TSIG or some web thing (web servers are really good at 3xx redirects) is an implementation nit. At this point Jacques' proposal that gives you a challenge token to stick in your zone to prove you're authorized is looking pretty good. R's, John From nobody Thu Aug 17 20:19:32 2017 Return-Path: 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 4597E132719 for ; Thu, 17 Aug 2017 20:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 1VzJ9ABUE_ni for ; Thu, 17 Aug 2017 20:19:29 -0700 (PDT) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82963132707 for ; Thu, 17 Aug 2017 20:19:29 -0700 (PDT) Received: by mail-pg0-x22d.google.com with SMTP id t3so27225455pgt.0 for ; Thu, 17 Aug 2017 20:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f6kRuyC6QNAwkh9SvX4lEtPjbDgEMyH9bJUmwFNDuZw=; b=H5GyAK4MclcTIM2f7ErUm5sm27Hv9rbWKlOPAsqb+8kjukd/rlUgjVT9h7OJ1Ifose Yhh9jqFt5vDLcpf+wnkdSti6An5kYjVP3dWoYDI65hUUWLft/OQFLrJ2aZ8Py8l1BwVu I3P52H6salo4yEY2mLTEo18WMaokL9tEQuK+3LnMK4CouXynOVbgUbHPqGpJhQUWiWod ajCB1gOKk6hFuDnuHTir0o7f14QRlkPrIWf6liaK424NrR8smJez2IeG+EpA9AR7q7GX 05BxT3SALVZYCrkDm9G/0XFw/3Vf05OMbGYCha6ONNLwdpUhVXXC0vwAuGdJnn3+BcVM sKzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=f6kRuyC6QNAwkh9SvX4lEtPjbDgEMyH9bJUmwFNDuZw=; b=eK17uLMFJBeysWQwJq6ZNGSe9vKqLI2v6FnWRwnhisiZYAecnCEIv2b6L2xRUVdy16 bAQykwtc8JfTKixJUregIZV47mPrOnQPeSVpuKjkofvMh4x+aDNxDJUSA4Y9BOSMTFPJ zDjuiHHk/MUY2H2tDWK5CyRPOqjXJhpyA/Ptf4DRaJkv4YKnR5uYsTBBvYiyIDKn4BO7 JXsHOhFCFFoFSVzlf4gKyylXXT5ReLoPuZ+0o7cE3Jn7r+oKAg4gczCjlCAkaNp4gz4j QI6SYtB3Qv0gtUJqvA7nVeR4j1hQXNQsB2j+LmTsolFMjNFErNRkggQ+rPLQQh5AMMU1 G4eg== X-Gm-Message-State: AHYfb5jlIaQ29xk2VEUm4gnHsJE0n6Xg+JfWk99pgvNJVRwFs21c8w5f TuQYWD9BW13Su02+Y1Y= X-Received: by 10.84.228.215 with SMTP id y23mr7934777pli.358.1503026368926; Thu, 17 Aug 2017 20:19:28 -0700 (PDT) Received: from [10.50.28.245] (mobile-166-177-250-16.mycingular.net. [166.177.250.16]) by smtp.gmail.com with ESMTPSA id z8sm8068819pgs.25.2017.08.17.20.19.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Aug 2017 20:19:27 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-89D1C8A3-3D03-4938-BC1F-FBD9597E50C4 Mime-Version: 1.0 (1.0) From: Brian Dickson X-Mailer: iPhone Mail (14G60) In-Reply-To: <69725356-F683-4FAF-A130-D08353D9169F@fugue.com> Date: Thu, 17 Aug 2017 20:19:25 -0700 Cc: "dnsop@ietf.org WG" Content-Transfer-Encoding: 7bit Message-Id: References: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> <69725356-F683-4FAF-A130-D08353D9169F@fugue.com> To: Ted Lemon Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 03:19:31 -0000 --Apple-Mail-89D1C8A3-3D03-4938-BC1F-FBD9597E50C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Aug 17, 2017, at 7:20 PM, Ted Lemon wrote: >=20 > El 17 ag 2017, a les 21:54, Brian Dickson v= a escriure: >> If you're trying to use "localhost", that means you're using some kind of= name resolution, whether it be DNS, /etc/hosts, NIS+, or anything else. >> I'm suggesting that by using DNS, you can take advantage of what DNS has t= o offer, which includes potentially DNSSEC. >=20 > DNSSEC can't work, or even be used, if you are spoofing localhost. If yo= u used DNSSEC, the answer would fail validation. >=20 Correct, so to clarify: Use DNSSEC, and use something other than "localhost." Does the host know its own name(s)? Brian= --Apple-Mail-89D1C8A3-3D03-4938-BC1F-FBD9597E50C4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Sent from my iPhone
=
On Aug 17, 2017, at 7:20 PM, Ted Lemon <mellon@fugue.com> wrote:

El 17 ag 2017, a les 21:54, Brian Dickson <brian.peter.dickson@gmail.com> va= escriure:
If you're trying to us= e "localhost", that means you're using some kind of name resolution, whether= it be DNS, /etc/hosts, NIS+, or anything else.
I'm suggesting that by using DNS, you= can take advantage of what DNS has to offer, which includes potentially DNS= SEC.

DNSSEC can't work, or= even be used, if you are spoofing localhost.   If you used DNSSEC, the= answer would fail validation.


Correct, so to clarify:
Use DNSSEC, and use somethin= g other than "localhost."

Does the host know its ow= n name(s)?

Brian
= --Apple-Mail-89D1C8A3-3D03-4938-BC1F-FBD9597E50C4-- From nobody Thu Aug 17 22:21:17 2017 Return-Path: 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 C72551320CF for ; Thu, 17 Aug 2017 22:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 zM8cV63Dfz-c for ; Thu, 17 Aug 2017 22:21:14 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2AA71200C5 for ; Thu, 17 Aug 2017 22:21:13 -0700 (PDT) Received: from [192.165.72.145] (unknown [192.165.72.145]) by mail.frobbit.se (Postfix) with ESMTPSA id 9B589204BC; Fri, 18 Aug 2017 07:21:10 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "John R Levine" Cc: "Mark Andrews" , dnsop@ietf.org Date: Fri, 18 Aug 2017 07:21:10 +0200 Message-ID: <8C160AEC-989A-4D29-A988-FC773440E4BB@frobbit.se> In-Reply-To: References: <20170816230917.4475.qmail@ary.lan> <20170817034747.0F82D8298B68@rock.dv.isc.org> <20170818001153.37E9082B0500@rock.dv.isc.org> <20170818013601.473E582B17D6@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_98F1D587-DF64-4E0A-B510-846CBE91EF7D_="; micalg=pgp-sha1; protocol="application/pgp-signature" X-Mailer: MailMate (2.0BETAr6090) Archived-At: Subject: Re: [DNSOP] updating fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 05:21:16 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_98F1D587-DF64-4E0A-B510-846CBE91EF7D_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 18 Aug 2017, at 4:39, John R Levine wrote: > Some do it one way, some do it the other, and the registars and registr= ies I've talked to feel very strongly about whichever way they do it. Correct, and that is why my only strong view is that both mechanisms can = be implemented by the solution IETF develops (including ability to say "N= O" to the not chosen option). Patrik --=_MailMate_98F1D587-DF64-4E0A-B510-846CBE91EF7D_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlmWeUYACgkQrMabGguI1824fwCfWHml1zDhshrRfwlXIQQFBNA8 9tcAn2prIDnDY5DQAW32Dq+3+pHje6fy =1tpK -----END PGP SIGNATURE----- --=_MailMate_98F1D587-DF64-4E0A-B510-846CBE91EF7D_=-- From nobody Fri Aug 18 07:46:01 2017 Return-Path: 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 531471323BA for ; Fri, 18 Aug 2017 07:46:00 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 NvRmmg9hclmq for ; Fri, 18 Aug 2017 07:45:58 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE162120721 for ; Fri, 18 Aug 2017 07:45:58 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id p3so54772206qtg.2 for ; Fri, 18 Aug 2017 07:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CIsL8iUls6zjbv0q0DiAUWj7M98Ic5nNZmsRLJ2B/ts=; b=xLR775DMnBtRYWHas/TleT9/3qht1ydtDftf5mLFDeBx10Ge9aU0P8ARe1HGjJTJZ/ XVsvfA4MNT87tuhKwEbywyfccH7HA/c0o8JFbJvaDf7jenz9+8Jj655y6HhuAkvOdZDX q8Qjo0ZUNLEhaGA51mpXB4piJK9Z1X62db60f7WtyuV5pUpc7KyKn0GSF1J1jm6K9atY bBGe/mpQWZJbY8notQphT4gvuI+pWGE39Ac8XHNB/j8FhlGmbSktBIegyaRF/l2eAugt k9Ilkl7Bes4KoJBNh2SduSz8dyM+Vfryok/btHwPz9Vppi19tm0DqyREZW0WBjg+g0zB DCMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CIsL8iUls6zjbv0q0DiAUWj7M98Ic5nNZmsRLJ2B/ts=; b=FqCXmhKWP16sPHZ6c8A4XOuBNBTCxl3srBd0Sdy1Kzv2dC3BgiDZ5MLa1cFKOZdIUi uVgsU4gWFvSyLuSrz3qmWgJCvWmGzDTrkFfHVXtq46qxjFowiXLIgQZwko53xHqBvfaL SZqCkiXQELdjtP+/Jghfk9RoPP4Crmd8onvumz5GfYh6ri6JMZprhqDNrWg9DEDofMu2 xQsGvMJ9iMl1fl0/REQhomhgN/X91MWZ61zZafQlDhv3Zc+mzSiHKSMO8rp2J4beH/ae DQhU5q6agyiEhm6du4zusT647nVXAbSnRH67iHlKUvCyBf/4Q2zjddtE5LvcTqXRzZ0l XZQA== X-Gm-Message-State: AHYfb5hZVT5264js9jkRTbOnF+owffzmUMmjCigwxaDzvJWMx/yprivH OEYAjP/0nw3NkVH9 X-Received: by 10.200.1.84 with SMTP id f20mr12064726qtg.6.1503067557819; Fri, 18 Aug 2017 07:45:57 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.ma.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id g37sm4366630qtb.20.2017.08.18.07.45.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 07:45:56 -0700 (PDT) From: Ted Lemon Message-Id: <3E884458-4BFD-4E88-8A60-482F18F275F3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_59835BBA-2BA9-4CCF-BB98-15D7EC5AB62D" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 Aug 2017 10:45:55 -0400 In-Reply-To: Cc: "dnsop@ietf.org WG" To: Brian Dickson References: <597FEBF7-7D11-4E50-9B79-63301914F75B@fugue.com> <69725356-F683-4FAF-A130-D08353D9169F@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 14:46:00 -0000 --Apple-Mail=_59835BBA-2BA9-4CCF-BB98-15D7EC5AB62D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 17 ag 2017, a les 23:19, Brian Dickson = va escriure: > Use DNSSEC, and use something other than "localhost." > Does the host know its own name(s)? Depending on the context, the host likely doesn't have a name. If it = does have a name, PKI works, so there's no need for some sort of ad-hoc = trust regime. You should assume that the only reason someone would use = localhost is that it's the best alternative, and propose solutions that = work in that situation. Localhost might get used in other situations, = but if you can't solve for that situation, you don't actually have a = solution. --Apple-Mail=_59835BBA-2BA9-4CCF-BB98-15D7EC5AB62D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 17 ag 2017, a les 23:19, Brian Dickson <brian.peter.dickson@gmail.com> va = escriure:
Use= DNSSEC, and use something other than "localhost."
Does the host know its own = name(s)?

Depending = on the context, the host likely doesn't have a name.   If it does = have a name, PKI works, so there's no need for some sort of ad-hoc trust = regime.   You should assume that the only reason someone would use = localhost is that it's the best alternative, and propose solutions that = work in that situation.   Localhost might get used in other = situations, but if you can't solve for that situation, you don't = actually have a solution.

= --Apple-Mail=_59835BBA-2BA9-4CCF-BB98-15D7EC5AB62D-- From nobody Fri Aug 18 08:13:04 2017 Return-Path: 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 DD3A61326E1 for ; Fri, 18 Aug 2017 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 IctTYljIBkyA for ; Fri, 18 Aug 2017 08:12:58 -0700 (PDT) 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 366C1132658 for ; Fri, 18 Aug 2017 08:12:58 -0700 (PDT) Received: from [192.168.3.237] (ip4-95-82-146-6.cust.nbox.cz [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 21CD2613CB; Fri, 18 Aug 2017 17:12:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503069176; bh=832HR0F2VH9Wckp/wcVPl2qSrj00VgMw849KbE+qW+g=; h=From:To:Date; b=BU6Q4vmMioOe5VSMYgMtPK1QVAsonQeelxa9a4D4GbH/mX3wAnzQegT1TcYVFG888 hpcRFJBIPp4WiMrQOszhFgqHMngVAA9B5A6iLi3igl898shd1MDkTSdju7nVoXUjw2 pBqt6VgpNnP5JiAlGfmIjAbFrGDGHdL7QiP6ybBE= From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= To: Ted Lemon Cc: dnsop WG References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> Organization: CZ.NIC Message-ID: <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> Date: Fri, 18 Aug 2017 17:12:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 15:13:03 -0000 Hello Ted and dnsop, I'm trying really hard to find out why we do not understand each other so I dug into to dnsop archives and draft-bellis-dnsop-session-signal-00 to see if my questions were already answered somewhere. Hopefully I have better understanding and will focus on technical questions. To be absolutely clear: There are parts of session signaling I *do like*, especially the idea to use a new OPCODE to separate "signaling" from "normal traffic". Also, I do not object to DNS-SD and other features built on top of session signaling! On 10.8.2017 14:43, Ted Lemon wrote: > Petr, forgive me for holding your feet to the fire on this, but you make > several statements along the lines of "for me, ... is stretching the > definition too far," "I disgree that this is less significant," et > cetera, but you don't actually raise any technical objections—you just > expressed uneasy feelings, with which I don't think the working group is > competent to help you. I will try my best to make the point even clearer, I promise! My objections are in the end about engineering costs, which was nicely summarized by Paul Vixie in another thread (about SWILD, but applicable to session signaling as well): https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8 For me the major portion of cost does not come from features (like session management etc.) but from the *framework* needed to build them. This cost increase IMHO stems from fact that the framework (SS aka DNS control plane as you named it) does not build on existing and widely available components. I believe that added complexity is one of serious technical parameters and I was objecting to it 4 months ago already: https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg > Your claim that this is a new wire format is > incorrect. What it would mean for this to be a new wire format is that > it is incompatible with the existing wire format. Doing something like > that is an interesting job that is potentially worth working on, but > would have a very long deployment window, if it got deployed at all. > > What we are proposing here is not a new wire format. It is compatible > with, and enhances, the existing wire format. Let's not focus on wording but on the meaning. We can certainly call TLVs "extension" but renaming it does not remove the fundamental problem: TLVs are largely incompatible with the code we already have widely implemented and deployed everywhere in all the DNS implementations and tools. As a consequence, it is increasing engineering cost for all involved parties. Please keep in mind that "involved parties" mean also all the people who are not interested in support for session signaling but happen to work on DNS monitoring, testing, etc. This will get worse if SS gets off is used as "DNS control plane" because at that point everyone will have to support it, with all its costs. > As for whether the working group should in fact undertake some grand > design process for such a format, I don't have a strong opinion, but the > first question I would raise is simply this: do /you/ want to undertake > such an effort? If the answer is yes, can you give me a sense of what > your goals are? The reason I ask is that IETF working groups are > constrained to do work that participants are willing to do, and thus far > we have seen no evidence that you are interested in working on this > document, which has been a working group document for a year. I apologize for taking so long before noticing the draft. To paraphrase: I tried to ignore this draft for a while, but became alarmed after reading about some of the recent development, so I went and read the document. :-) > As for whether this document is in charter, what we are proposing is > certainly in scope for the working group—it's very clearly an > operational enhancement for DNS in streaming protocols. It doesn't > change the way you do DNS queries—it just adds some new capabilities for > new implementations. I think it's very clearly useful—we already have > three use cases for it. If we were to stop work on this document now, > the work that now relies on it would revert to what had been proposed > earlier, which was not as good—dnssd has been hanging fire waiting for > this work to be done because the working group wanted to cooperate with > dnsop in producing something more generally useful, rather than doing a > one-off extension like Apple's DNS Long-Lived Queries, which was never > standardized. > > So if there is something missing from the document, or something > unclear, or you wish we'd thought of ???, or think that !!! is not quite > right and have suggestions, I think that would be really helpful. And > of course the working group chairs are free to agree with your vague > feelings of unease and drop this as a working group document. > > But as for any sort of specific request that the authors or the working > group could act on, I am not hearing anything of that sort in what you > have said. Can you think about this in that context, and see if you > can more clearly articulate what it is that you find lacking in this > proposal, so that the working group can figure out how to fix it? Can > you do it soon? Okay, please let me be even more specific. I believe that WG should seek answers to following questions and add explanatory text to the draft. Looking at version draft-ietf-dnsop-session-signal-03#section-1: In general, as far as I can tell, this document gives no clear justification why it is a good idea to do it this way. What I really want, on the highest level, is to see a justification why it is a good idea *to not reuse and extend existing framework* like EDNS. We have not been told of the practical problems that preclude solutions which are closer to existing code, e.g. EDNS, which would lower the engineering costs for the whole ecosystem. Let me make clear that when I talk about EDNS and other existing stuff, I still think about variant where e.g. EDNS is used in messages with new OPCODE, so the separation is still there. This is in no way proposal to mix SS and non-SS traffic. To avoid all doubts, here is my list of specific high-level problems paragraph-by-paragraph: The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is explicitly defined to only have "per-message" semantics. Whilst EDNS(0) has been used to signal at least one session related parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is less than optimal due to the restrictions imposed by the EDNS(0) semantics and the lack of server-initiated signalling. a) What are technical reasons not to use EDNS similarly to what RFC7828 have done? Specifically what is "less than optimal"? What problems of RFC7828 are we trying to avoid? b) What is the technical reason to invent a new thing instead of solving "lack of server-initiated signaling" in EDNS instead? Without justification it seems like we are not reusing code we have and thus increasing costs unnecessarily. This document defines a new Session Signaling OPCODE used to carry persistent "per-session" operations, expressed using type-length- value (TLV) syntax, and defines an initial set of TLVs used to manage session timeouts and termination. c) What were technical reasons to standardize TLV format over something else? What technical criteria were used to design the new format? Again, without justification it seems like we are not reusing code we have and thus increasing costs unnecessarily. With EDNS(0), multiple options may be packed into a single OPT pseudo-RR, and there is no generalized mechanism for a client to be able to tell whether a server has processed or otherwise acted upon each individual option within the combined OPT RR. The specifications for each individual option need to define how each different option is to be acknowledged, if necessary. d) Is it something which is not solved by EDNS capabilities (just an example)? I really need to see a justification why it is better to start from scratch instead of improving existing standards and code. With Session Signaling, in contrast, there is no compelling motivation to pack multiple operations into a single message for efficiency reasons. Each Session Signaling operation is communicated in its own separate DNS message, and the transport protocol can take care of packing separate DNS messages into a single IP packet if appropriate. For example, TCP can pack multiple small DNS messages into a single TCP segment. The RCODE in each response message indicates the success or failure of the operation in question. e) Technically packing multiple messages into one single TCP segment is not a property of session signaling but property of the transport. It would work the same way if we were sending DNS messages with OPT containing one EDNS option at a time. Current EDNS options define how server replies to client, so the client gets a reply according to particular standard. If the option is missing in the answer then it is not supported by server, i.e. the cost of detecting unsupported options is the very same as for session signaling with TLV (one round-trip). In other words, this paragraph does not justify costs for inventing a new thing because the EDNS already can do the same. 4.1.3. EDNS(0) and TSIG Since the ARCOUNT field MUST be zero, a Session Signaling message MUST NOT contain an EDNS(0) option in the additional records section. If functionality provided by current or future EDNS(0) options is desired for Session Signaling messages, a Session Signaling Operation TLV or Modifier TLV needs to be defined to carry the necessary information. For example, the EDNS(0) Padding Option [RFC7830] used for security purposes is not permitted in a Session Signaling message, so if message padding is desired for Session Signaling messages, a Session Signaling Modifier TLV needs to be defined to perform this function. Similarly, a Session Signaling message MUST NOT contain a TSIG record. A TSIG record in a conventional DNS message is added as the last record in the additional records section, and carries a signature computed over the preceding message content. Since Session Signaling data appears after the additional records section, it would not be included in the signature calculation. If use of signatures with Session Signaling messages becomes necessary in the future, an explicit Session Signaling Modifier TLV needs to be defined to perform this function. [snip] This specification explicitly prohibits use of the EDNS(0) TCP Keepalive Option [RFC7828] in _any_ messages sent on a Session Signaling session (because it duplicates the functionality provided by the Session Signaling Keepalive operation), but messages may contain other EDNS(0) options as appropriate. f) Section 4.1.3. shows the problem in full. Approach envisioned by the draft duplicates work and thus leads to unnecessary engineering costs again. Re-inventing things for two incompatible frameworks (EDNS and SS) will cost everyone a lot of effort. Are there technical reasons justifying these costs? The document does not answer this question, which is a significant problem. Can we work together and find answers to there questions? I will be happy to participate in the process. Petr Špaček @ CZ.NIC > > Thanks! > > On Thu, Aug 10, 2017 at 7:28 AM, Petr Špaček > wrote: > > Hello Ted and dnsop, > > and sorry for delayed answer (below). Your message forced me to think > more about the draft, this time without focus on the wire format. > > Spoiler alert: I still do not like the proposal in its current form. > Please see below. > > On 21.7.2017 10:22, Ted Lemon wrote: > > I am hearing from a number of people that this is "a new protocol" and > > hence requires careful thought and perhaps a new working group, along > > with the associated delay. I do not _entirely_ disagree with this > > position, although it would be really inconvenient from my perspective. > > > > However, I would like to point out that the objection "it is a new > > protocol" is not a technical objection. Also, the same objection can > > actually much more justly be raised against several other proposals that > > were brought before the working group. For example, the multiple > > RRtypes proposal, the multiple responses proposal, and the extended > > error codes proposal. > > > > All of these define new protocol, in ways that are in, like session > > signaling, backward-compatible with the existing protocol. The other > > proposals are actually much more significant changes than session > > signaling is, in terms of what they actually do, as opposed to what > > their wire format is. > > Okay, I can see what you mean - there surely are various levels of > complexity and protocol changes proposed in the last years for dnsop. > > However I disagree that adding session signalling to DNS is less > significant change than e.g. multi-query/repose proposals. > > As you said, session signalling is a "control plane for DNS", which is a > very new thing. Keeping (IMHO significant) wire format issues aside, > adding a control plane to DNS is in my eyes a significant new > development and should be treated as such. > > > > And as for a new DNS wire format, which I also think would be a good > > idea, this is pretty clearly /not /what session signaling is. How > > would you do a DNS query with session signaling? In what way would it > > be an improvement over the existing query format? It's possible that a > > new wire format can be built on top of session signaling, but session > > signaling doesn't build a new wire format, and if we choose to do > > session signaling, that doesn't preclude doing a different wire format > > for queries later. > > Maybe one of the problems is that the current draft mixes three > things in a single document: > - The new wire format, > - DNS control plane, > - Session signaling functionality over the control plane. > This is probably making things way harder to explain to non-authors than > necessary. > > These really are separate things. I can imagine that control plane > and potentially its wire format can be together in one document (but I'm > still not convinced that the a wire format is necessary), but session > signaling functionality itself should be certainly separate from that. > > > Let's keep discussion about the wire format for later, there is even > more significant issue ahead of us: > > > Session signaling is just a control plane for DNS. It's useful. I > > would like to see it done sooner rather than later. If we are not > > going to do it sooner rather than later, I would like the reason to be > > something more than vague unease about walking backwards into a new wire > > format. > > The problem is that current proposal is creating some generic "control > DNS plane" as by-product of session signaling functionality, as we were > discussion during dnsop session. > (References: "Totally flexible format" & "Concerned with embedding DNS > messages in TLVs" in [2].) > > I believe that we really should not invent such generic mechanisms as > by-products. > > If a WG agrees that a generic DNS control plane is needed, then it needs > to be carefuly designed and described, including problem statement and > analysis related to current and potential new transports. These are > compleretely missing now. > > > Moreover, the dnsop is specifically chartered to subset of possible > changes [1] to the DNS protocol: > > 4. Publish documents to address operational issues with the DNS > protocols by extending or performing protocol maintenance > on them. Act as focal-point for operator discussion and provide > advice to the Ops ADs and other WGs on EDNS0 options, new > RRTYPEs, DNSSEC, record synthesis, or other mechanics of > extending DNS to support other applications. > > 5. Serve as a home for drafts that document the problem space > around existing or new DNS issues. The group, with the advice > and consent of the responsible AD in coordination with other areas, > will then decide whether these issues belong in DNSOP under > the existing charter and, if not, will work with the authors and > appropriate ADs to determine the proper place for the work to be > carried out. > > For me, adding control plane is just stretching this definition too far. > If session signaling is covered by this charter then we must admit > that dnsop can do anything it wants to the DNS protocol. > > [1] > http://mailarchive.ietf.org/arch/msg/dnsop/MOFBFQAaZ2iZUDje3zWNBRn9xKQ > > > [2] > https://datatracker.ietf.org/meeting/99/materials/minutes-99-dnsop > > > > Again: > If there is a need for a "DNS control plane" then it should be enginered > as such and not invented as by-product of something else. > > Yes, it is a lot of work. And yes, it should start with problem > statement for control plane (in general) and continue from there. > > > I hope it explains why I still do not like the current proposal. > Thank you for your attention. > > Petr Špaček @ CZ.NIC > > > > > > On Fri, Jul 21, 2017 at 10:02 AM, Petr Špaček > > >> wrote: > > > > On 20.7.2017 19:09, Andrew Sullivan wrote: > > > On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote: > > >>> But it's certainly another step along the way to DNSbis by > accident. > > >> > > >> Would it be useful to make it not "by accident"? > > > > > > Yes. That was basically the point I was trying to make at the > > > beginning of today's session, about overall analysis. > > > > > > > b) make this draft DNS-SD only, so it can fast forward... > > >> > > > > > > I'm not keen on this. > > > > > > > > >> c) use the changed paradigm to work on DNSbis without the > accident part? > > > > Yes please! > > > > My main opposition comes from fact that current session > signaling draft > > "accidentaly" defines new protocol which is using the old > DNS-RFC1035 as > > "transport". > > > > I would welcome DNSbis effort with clear cut. Here please note > that > > clear cut does not mean that RR format and data, for example, > has to be > > incompatible! > > > > It is still possible to share big chunks of specifications > (like RR > > definitions, namespace, etc.) but define a DNSbis protocol > which is > > clearly distinguishable from the old DNS. > > > > Petr Špaček @ CZ.NIC > > > > > I'm starting to wonder whether a bof is needed. Maybe the IAB's > > > workshop will produce some fruit? From nobody Fri Aug 18 08:33:24 2017 Return-Path: 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 87AF0132964 for ; Fri, 18 Aug 2017 08:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QNRYYapsS7oN for ; Fri, 18 Aug 2017 08:33:20 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1B8132977 for ; Fri, 18 Aug 2017 08:33:19 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id c14so735283wmh.1 for ; Fri, 18 Aug 2017 08:33:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fQlSfAejAEYnVGhVT6rBBJjhW8kjiWYPIsBumqsTTq4=; b=ui9MATyv8Qajx3xvH+1/Vm1f+b1Aa9C8DU5PPe0pzSc5Mem92qnPUMncemNUkhBGQ/ YKVLEpP9Ywr/VjWPjiLHFvtJPUNp7nG2Q4mhtL/sfB3l1DGhxAHcgpolpGwcWrRWke1l p65jO4E5lBDAR7tHj7YZTYIeEkbPM9rJHPQXKJBV4zjlbCzD/OX/jhcMvXok1eAukcSZ HcF+wf/TH0CS1yqlxSrVZf/lsQyZ2rN/eUPFDSxEreX43zruH8j1YtlE0EbyAuh0TYBf n+5qe/9HA1F68jeAPqdnTpeQLj7xYtVRtNQQUd766HNhVxVjJYyG0+yxZfq9Q7/S9dI9 D3ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fQlSfAejAEYnVGhVT6rBBJjhW8kjiWYPIsBumqsTTq4=; b=O6UYYsYcHjo/lSffmsTsMoUmyKMxP6zsBJrlEVgl+83t9oQn7sfvENI48Aw1nFBnQ+ 7tZEDRF/5zFPmNR0ckz8QI+oqNSV6a5rVYgEhtBjQLug1INzD3oLJtresaaFtFStLih+ Fg17sZFhbJeQVY4KzWuBMvf/g4FzE0v+fKzJvntXmNkaO3DWi2qmn3Npz2JYZAdU6VsQ uN2szAfspPIC8OVI/+PxLKy0WN5vh09Bx7B46TtK8tdlzDkGbNFAI0VV1jz+oO2UvE0I rBDMRfT3ZLInFme9y5Yxjwq789lHxVhcov5CyGfbI2ET0ppLGKi0et4HdXx5y3L0RRnZ 7Z4g== X-Gm-Message-State: AHYfb5jewZTAMnjPo4CDb/tR7RWB8UOg8Te+gCxffik39NLyf82bQ4fG WTVoOXbjBc0q2PcJteTxy2IkIl/U3xnW X-Received: by 10.80.174.218 with SMTP id f26mr2264132edd.286.1503070398061; Fri, 18 Aug 2017 08:33:18 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> In-Reply-To: <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> From: Lanlan Pan Date: Fri, 18 Aug 2017 15:33:06 +0000 Message-ID: To: Ted Lemon Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c4eea261eeb055708d940" Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 15:33:22 -0000 --f403045c4eea261eeb055708d940 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot for your pertinent comments, :-) Ted Lemon =E4=BA=8E2017=E5=B9=B48=E6=9C=8817=E6=97=A5=E5= =91=A8=E5=9B=9B =E4=B8=8B=E5=8D=889:56=E5=86=99=E9=81=93=EF=BC=9A > El 17 ag 2017, a les 0:09, Lanlan Pan va escriure: > > We can use SWILD to optimize it, not need to detecting, just remove items > which SWILD marked, to save cost. > > > So, can you talk about how your proposal saves cost over using a heuristi= c? > It can be used with cache aging heuristic. Heuristic read in aaa/bbb/ccc.foo.com, expire and move out; then read in xxx/yyy/zzz.foo.com, expire and move out; loop... =3D> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read, i= t will reduce the load of move in/out. > > 2) cache miss > All of temporary subdomain wildcards will encounter cache miss. > Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... > We can use SWILD to optimize it, only query xxx.foo.com for the first > time and get SWILD, avoid to send yyy/zzz.foo.com queries to > authoritative server. > > > Can you characterize why sending these queries to the authoritative serve= r > is a problem? > Ok, Similar to RFC8198 section 6 Benefit but not problem, directly return from cache, avoid send queries to authoritative, and wait for response, reduce laterncy. > 3) DDoS risk > The botnet ddos risk and defense is like NSEC aggressive wildcard, or NSE= C > unsigned. > For example, [0-9]+.qzone.qq.com is a popular SNS website in China, like > facebook. If botnets send "popular website wildcards" to recursive, the > cache size of recursive will rise, recursive can not just simply remove > them like some other random label attack. > We prefer recursive directly return the IP of subdomain wildcards, and no= t > rise recursive cach, not send repeat query to authoritative. > > > Why do you prefer this? Just saying "we prefer ..." is not a reason for > the IETF to standardize something. > Sorry, my expression is fault. More details: 1) All of the attack botnets were customers of ISP, sent queries to ISP recursive with low rate, so all of the client's IP addresses were "legitimate", could not simply use ACL. 2) Normal users also visit [0-9]+.qzone.qq.com, all the the random queries domain seems to "legitimate". =3D> The client ip addresses and the random subdomains are all in the whitelist, not in blacklist. 3) ISP didn't have any DNS firewall equipment ( very sad situation, but it was true ) to take over the response of "*.qzone.qq.com". In this weaker scenario, it will be better if give recursive more information to directly answer queries from cache, and make recursive not to send/cache many subdomains query/response. Of course, we can defense the attack with professional operation, solve the problem very well. But there are also many more weaker recursive only run bind software, without any protection... > There are a bunch of problems with your proposal, as I'm sure others have > remarked before. It breaks DNSSEC validation for stub resolvers that > aren't aware of SWILD. In the absence of DNSSEC validation, it creates a > new and very effective spoofing attack (poison the cache with bogus SWILD > records). Etc. > > So you need to clearly explain why it is that you prefer this approach, > and not just say that it's something you like. Are you using it in > production? Do you have data on what it does? Do you have data on the > behavior of real-world caches that you can cite that shows that SWILD wou= ld > produce more of an improvement than just using a better cache aging > heuristic? > I will reconsider these problems of the proposal, make the improvement analysis on real-world caches before next step. --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c4eea261eeb055708d940 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for your pertinent comments, :-)

Ted Lemon <mellon@fugue.com>=E4=BA=8E2017=E5=B9=B48=E6= =9C=8817=E6=97=A5=E5=91=A8=E5=9B=9B =E4=B8=8B=E5=8D=889:56=E5=86=99=E9=81= =93=EF=BC=9A
El 17 ag 2017, a les 0:09, Lanlan Pan <abbypan@gmail.com> va escriure:<= br>
We can use SWILD to optimize it, not need to detecting, just remove items = which SWILD marked, to save cost.

So, can you talk about how your = proposal saves cost over using a heuristic?
It= can be used with cache aging heuristic.
Heuristic read in aa= a/bbb/ccc.foo.com, expire and move out;= =C2=A0 then read in xxx/yyy/zzz.foo.com,= =C2=A0 expire and move out;=C2=A0 loop...
=3D> Map aaa/bbb/ccc= /xxx/yy/zzz.foo.com to *.foo.com when heuristic read, it will reduce the load of mov= e in/out.

2) cache miss
= All of temporary subdomain wildcards will encounter cache miss.
Q= uery xxx.foo.com,=C2= =A0 then query yyy.foo.co= m, zzz.foo.com, .= ..
We can use SWILD to optimize it,=C2=A0 only query xxx.foo.com for the first time an= d get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative server.

Can you characterize why sending these queries to the authoritative = server is a problem?

Ok, Similar to RFC8198 secti= on 6
Benefit but not p= roblem,=C2=A0 directly return from cache, avoid send queries to authoritati= ve, and wait for response, reduce laterncy.
=
3) DDoS risk
The botnet ddos= risk and defense is like NSEC aggressive wildcard, or NSEC unsigned.
=
For example,=C2=A0 [0-9]+.qzone.qq.com is a popular SNS website in China, like facebook. I= f botnets send "popular website wildcards" to recursive,=C2=A0 th= e cache size of recursive will rise, recursive can not just simply remove t= hem like some other random label attack.
We prefer recursive = directly return the IP of subdomain wildcards, and not rise recursive cach,= not send repeat query to authoritative.

Why do yo= u prefer this? =C2=A0 Just saying "we prefer ..." is not a reason= for the IETF to standardize something.
<= br>
Sorry, my expression is fault.

More detai= ls:
1) All of the attack botnets were customers of ISP, sent quer= ies to ISP recursive with low rate, so all of the client's IP addresses= were "legitimate", could not simply use ACL.
2) No= rmal users also visit [0-9]+.qzone.qq.com, all the the random queries domain seems to "legitimate".
<= /div>
=3D> The client ip addresses and the random subdomains are all= in the whitelist, not in blacklist.

In this weaker scenario,=C2=A0 it will be bet= ter if give recursive more information to directly answer queries from cach= e, and make recursive not to send/cache many subdomains query/response.
Of course, we can defense the attack with professional op= eration, solve the problem very well. But there are also many more weaker r= ecursive only run bind software, without any protection...
<= br>

There are a bunch of problems with your proposal, as I= 'm sure others have remarked before. =C2=A0 It breaks DNSSEC validation= for stub resolvers that aren't aware of SWILD.=C2=A0 In the absence of= DNSSEC validation, it creates a new and very effective spoofing attack (po= ison the cache with bogus SWILD records). =C2=A0 Etc.
=C2=A0
So you need to clearly explain why it is that you pre= fer this approach, and not just say that it's something you like. =C2= =A0 Are you using it in production? =C2=A0 Do you have data on what it does= ? =C2=A0 Do you have data on the behavior of real-world caches that you can= cite that shows that SWILD would produce more of an improvement than just = using a better cache aging heuristic?

I will reconsider these problems of the proposal, make the= improvement analysis on real-world caches before next step.
--
=E8=87=B4=E7=A4=BC=C2= =A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--f403045c4eea261eeb055708d940-- From nobody Fri Aug 18 09:37:36 2017 Return-Path: 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 03A3B1329FF for ; Fri, 18 Aug 2017 09:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 htxsIOiXpZBX for ; Fri, 18 Aug 2017 09:37:32 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA6E81329F8 for ; Fri, 18 Aug 2017 09:37:31 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id t201so3963738wmt.1 for ; Fri, 18 Aug 2017 09:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wnnOc/yaN2kEhBt202fOwih6v9T92cKqWxVyrCdDbSY=; b=mrm8WKXI3jr44aOMx8JlfxpsEEgeuDN+AEvBFPjuINuny0yqlJ+ErueCS/bflN5q0e biNURTB3CoCqyHJtfB6JmT/xjkiK2lIR8+GD5oKwcdBRNzoHQHsZvI9c+H9R10D3eUe/ Iuh5VkXUCbFhZxqtHdkzrKJJlBH2FBTccvNc20DAUpr4BcQU1t20WcguVFbfNl7AMYfP mKSr8s9RVoTdrLiZ/YXXboj/9w1rl6Ej8ESh1AkwkesV1X/LXiYcICLF2QYImEtjYaqU K1aMShx8WmygTV3Dv7YVKLtMJQ0GGcuioknADRu98qzjmek8hXjiNO6ccpbHt98B0vBD PRwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wnnOc/yaN2kEhBt202fOwih6v9T92cKqWxVyrCdDbSY=; b=YdbHQXkIW95O1mvDF+FwzpQW0pEqwpl7U6zIq7O1ZY3FRVMdDtcStTghVOcEQeyi01 PB6NX8lbYQaGGH9WTofGSfHv90qnQoeaMEG8yK4muT1omTCk8WiV6EBsj44Sod9FP9oy IpwqDi6ZLbsyzZ9qIH7PnxPtC29xruqhFT+ZZVlxLVEPU81fqGp21iiKC2CJnP4MepaT TZZz1HnB1nYV+7ggLAZCSCFt2Ml9LfMDubzgQiX2a+mBVvezXCHnVRcRrUtrwv7ew5Nm ELx61vMD0cuxon5jvawE9MofY44/AFRx1JNHQhhwvG+Rt0sTxUw0Jie6HQ90XurPSkiR eVig== X-Gm-Message-State: AHYfb5idPRfLdnLgmK9ijr34gUJpRJ1zJ662ZviHI+G18sXJbg7T/ow6 AKjGlENpnGGBOjRxE5OYtT2fdGo5l2Ts X-Received: by 10.80.182.44 with SMTP id b41mr5324535ede.115.1503074250241; Fri, 18 Aug 2017 09:37:30 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <78BBBA80-9FAA-4F18-9EDC-F93A2790E226@fl1ger.de> In-Reply-To: <78BBBA80-9FAA-4F18-9EDC-F93A2790E226@fl1ger.de> From: Lanlan Pan Date: Fri, 18 Aug 2017 16:37:18 +0000 Message-ID: To: Ralf Weber Cc: Ted Lemon , dnsop WG Content-Type: multipart/alternative; boundary="94eb2c0dd4e4c1ba5e055709bee6" Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 16:37:35 -0000 --94eb2c0dd4e4c1ba5e055709bee6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks a lot for your detail analysis, :-) Ralf Weber =E4=BA=8E2017=E5=B9=B48=E6=9C=8817=E6=97=A5=E5=91= =A8=E5=9B=9B =E4=B8=8B=E5=8D=8811:16=E5=86=99=E9=81=93=EF=BC=9A > Moin! > > On 17 Aug 2017, at 0:09, Lanlan Pan wrote: > > Yes, I agree, in fact the *online cache rate* is small (0.12% queries), > LRU > > & TTL works fine. > > SWILD not save many online cache size, because of the queries rate. > > And Temporary Domain Names/ All Names: 41.7% for 7 days statistics, th= e > > rate can be about 10% for 1 day statistics. Because temporary domain > names > > expire after TTL time. Ralf has similar curious. > As you mention me, with the data you supplied it is highly unlikely that = a > lot of records will still be active in the Cache because of the TTL and > how least recently used (LRU) algorithms work. > > > The problem is: > > > > 1) cache size > > Recursives commonly cache "all queried domain in n days" for some > > SERVFAIL/TIMEOUT condition, which has been documented in > > https://tools.ietf.org/html/draft-tale-dnsop-serve-stale-01 > That is not what the draft suggest and is not what the current > implementations of this or similar features do. They all rely on a cache > with a fixed size and if the record that normally would be expired is > still in the cache extend it's lifetime when queried. The records you > mention are not queried and thus would be expired because other records > that are queried more frequently would have overwritten them anyway. > > There also is nearly no harm if these queries fail in case the > authoriative is not responding as most of those queries you describe > are computer and not human generated. The draft above and similar > techniques where done because of the twitter.com problem. Now I can > assure you that twitter.com will always be hot (asked at least every > couple of seconds) in a regular resolver at your ISP or a provider > of DNS services, and thus the expired record will probably still be > in the cache. > You are totally right. I admit the online cache size is not a problem on fixed size LRU/TTL refresh. > > > The subdomain wildcards cache are needlessly, we can use heuristics > > algorithm for deciding what to cache, or just use simple rule like > "select > > domain which queies time > 5 in last n days". > > We can use SWILD to optimize it, not need to detecting, just remove ite= ms > > which SWILD marked, to save cost. > The cost of sending a query now and then is very low resolvers do that al= l > the time and the rate on which they have to do that is very low. However = to > actually save costs you would have to deploy your proposal on the > authoritative server that have that behaviour and the resolvers. Good luc= k > with that. I also assume some of the authorities are actually interested = in > the queries so they would not implement your proposal even if they could, > making the theoretical improvement of 0.12% even smaller. > 0.12% is the rate of recursive queries times. authorities's improvement rate is not 0.12%, it depends on the query distribution of subdomain wildcards on the whole zone, and the number of recursives that enable SWILD. > > > 2) cache miss > > All of temporary subdomain wildcards will encounter cache miss. > > Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... > > We can use SWILD to optimize it, only query xxx.foo.com for the first > time > > and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative > > server. > See above. > same as above, and the above reply to Ted, :-) > > > 3) DDoS risk > > The botnet ddos risk and defense is like NSEC aggressive wildcard, or > NSEC > > unsigned. > > For example, [0-9]+.qzone.qq.com is a popular SNS website in China, > like > > facebook. If botnets send "popular website wildcards" to recursive, th= e > > cache size of recursive will rise, recursive can not just simply remove > > them like some other random label attack. > As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall > attacks > as others call them are usually asking every subdomain once (and these > botnets > take great care on doing this) the record would be removed by the least > recently used (LRU) algorithm when other records that are used more are > questioned. > > While these attacks on recursive resolvers can stress the recursive to > authoritative part of the resolver there are techniques to limit the > exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring > Workshop in Amsterdam on that topic: > https://indico.dns-oarc.net/event/21/contribution/29 > and the summary of it is that all major vendors of recursive resolvers > handle this, so again while your solution would be one once universally > deployed there are already solutions to the problem out there, so why do > another one? > See also the above reply to Ted. All major vendors of recursive resolvers can deal "legitimate subdomain wildcards" problem with some feature like Response Rate Limiting. The difference of my solution is directly reply IP to all "legitimate" clients' low rate queries, not move in/out the subdomain wildcard records with LRU. So long > -Ralf > > > -- =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --94eb2c0dd4e4c1ba5e055709bee6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot for your detail analysis, :-)

Ralf Weber <dns@fl1ger.de>=E4=BA=8E2017=E5=B9=B48=E6=9C=8817=E6=97= =A5=E5=91=A8=E5=9B=9B =E4=B8=8B=E5=8D=8811:16=E5=86=99=E9=81=93=EF=BC=9A
Moin!

On 17 Aug 2017, at 0:09, Lanlan Pan wrote:
> Yes, I agree, in fact the *online cache rate* is small (0.12% queries)= , LRU
> & TTL works fine.
> SWILD not save many online cache size, because of the queries rate. > And Temporary Domain Names/ All Names: 41.7% for 7 days statistics,=C2= =A0 the
> rate can be about 10% for 1 day statistics. Because temporary domain n= ames
> expire after TTL time.=C2=A0 Ralf has similar curious.
As you mention me, with the data you supplied it is highly unlikely that a<= br> lot of records will still be active in the Cache because of the TTL and
how least recently used (LRU) algorithms work.

> The problem is:
>
> 1)=C2=A0 cache size
> Recursives commonly cache "all queried domain in n days" for= some
> SERVFAIL/TIMEOUT condition, which has been documented in
> https://tools.ietf.org/html/draft-ta= le-dnsop-serve-stale-01
That is not what the draft suggest and is not what the current
implementations of this or similar features do. They all rely on a cache with a fixed size and if the record that normally would be expired is
still in the cache extend it's lifetime when queried. The records you mention are not queried and thus would be expired because other records
that are queried more frequently would have overwritten them anyway.

There also is nearly no harm if these queries fail in case the
authoriative is not responding as most of those queries you describe
are computer and not human generated. The draft above and similar
techniques where done because of the twitter.com problem. Now I can
assure you that twitter.com will always be hot (asked at least every
couple of seconds) in a regular resolver at your ISP or a provider
of DNS services, and thus the expired record will probably still be
in the cache.
You are totally right.
I admit= the online cache size is not a problem on fixed size LRU/TTL refresh.
<= /div>

> The subdomain wildcards cache are needlessly,=C2=A0 we can use heurist= ics
> algorithm for deciding what to cache, or just use simple rule like &qu= ot;select
> domain which queies time > 5 in last n days".
> We can use SWILD to optimize it, not need to detecting, just remove it= ems
> which SWILD marked, to save cost.
The cost of sending a query now and then is very low resolvers do that all<= br> the time and the rate on which they have to do that is very low. However to=
actually save costs you would have to deploy your proposal on the
authoritative server that have that behaviour and the resolvers. Good luck<= br> with that. I also assume some of the authorities are actually interested in=
the queries so they would not implement your proposal even if they could, making the theoretical improvement of 0.12% even smaller.
<= div>0.12% is the rate of recursive queries times.
authoritie= s's improvement rate is not 0.12%, it depends on the query distribution= of subdomain wildcards on the whole zone, and the number of recursives tha= t enable SWILD.

> 2) cache miss
> All of temporary subdomain wildcards will encounter cache miss.
> Query xxx.foo.com,=C2=A0 then query yyy.foo.com, zzz.foo.com, ...
> We can use SWILD to optimize it,=C2=A0 only query xxx.foo.com for the fir= st time
> and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritative
> server.
See above.
same as above, and the above reply to Ted, = :-)

> 3) DDoS risk
> The botnet ddos risk and defense is like NSEC aggressive wildcard, or = NSEC
> unsigned.
> For example,=C2=A0 [0-9]+.qzone.qq.com is a popular SNS website in China= , like
> facebook. If botnets send "popular website wildcards" to rec= ursive,=C2=A0 the
> cache size of recursive will rise, recursive can not just simply remov= e
> them like some other random label attack.
As PRSD (Pseudo Random Subdomain) attacks as I call them or waterfall attac= ks
as others call them are usually asking every subdomain once (and these botn= ets
take great care on doing this) the record would be removed by the least
recently used (LRU) algorithm when other records that are used more are
questioned.

While these attacks on recursive resolvers can stress the recursive to
authoritative part of the resolver there are techniques to limit the
exposure to clients. I did gave a talk on that at DNS-OARC 2015 Spring
Workshop in Amsterdam on that topic:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://indico.dns-o= arc.net/event/21/contribution/29
and the summary of it is that all major vendors of recursive resolvers
handle this, so again while your solution would be one once universally
deployed there are already solutions to the problem out there, so why do another one?
See also the above reply to Ted.
All major vendors of recursive resolvers can deal "legitimate=20 subdomain wildcards" problem with some feature like Response Rate=20 Limiting.
The difference of my solution is directly reply IP to a= ll "legitimate" clients' low rate queries, not move in/out th= e subdomain wildcard records with LRU.

So long
-Ralf


--
=E8=87= =B4=E7=A4=BC=C2=A0 Best Regards

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pa= n Lanlan
--94eb2c0dd4e4c1ba5e055709bee6-- From nobody Fri Aug 18 10:05:18 2017 Return-Path: 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 78C9613219A for ; Fri, 18 Aug 2017 10:05:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 nXAp8y6h5VNU for ; Fri, 18 Aug 2017 10:05:14 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C960713231E for ; Fri, 18 Aug 2017 10:05:13 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id t37so56777236qtg.5 for ; Fri, 18 Aug 2017 10:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1Cb4VrPVtYREz1pYjV1SYrnCKPORNf/9ycRWJnF3RRU=; b=rshX1JUPXyR/Sq9SoWmQbdrBr2OZZXrTVN8WD4TvlSu4wJVB/4a88JWWgAl6go9Ps3 fRRS/n2ObWNFcNyaivfc8V7XLPKLf4yEhBG3Qyx2JGt+bDVpKeDDHq5GOq3VQS6PwgXg RF8r3mbREjXsgTYyZ1Xyg42VqW1m9/R3Hp8WLELUec4HBgzoKk3T31FSK/3arXHW+7c3 x6MuDmAvkko1QpejLl3hGze6qajE7hR1sXzWPMinoJ0Ti/0v+pzd9kN9ku2qOvDp34br 0YEI8O/X2nGZp7hnpgdgtXcrTTbDX6wtcR+n4X9M0+gqPIrMyT/naj228Uag95o/ZQ41 6D4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1Cb4VrPVtYREz1pYjV1SYrnCKPORNf/9ycRWJnF3RRU=; b=Tn5mneGqG+p9wOdk+Yd/dSUaqawkEJyAi97Nnp8JSfxRP1NEnO7fQY/RXblCRNlSYl a44IdyBrginhYwfOkDljJ/oO21ajUBqm+BL5Ra1LcPisFub+04KujLpmnThB16Nnm/UM 2yDIifIErGmOnGnuxyxu0017h+1Av3DXng57hl7VesXoKERsyOIq15cnWDXyf1WChNH6 YZwDvLHClm9AzI12NAXHeZVuEvLUUNtXPQVE8cYrdATnzOR1hN8RJG3GD4a9Rl3w3V+K 55fPo/ojG9MthGKuhZMreGyw5tcORFcfxuz9jx3zQmEGF7y+rF8mPn6/O2p0QItGhAp/ 0gtA== X-Gm-Message-State: AHYfb5hX6A6BLGBZL6O5kjN8chkxmvBR1cvVEUMgLUcWDm2/tlI39q2A OmoBC+xjHvpQL3a7 X-Received: by 10.200.51.129 with SMTP id c1mr14001040qtb.71.1503075912910; Fri, 18 Aug 2017 10:05:12 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id f184sm3809113qkd.57.2017.08.18.10.05.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:05:12 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_08822224-AC60-4708-8BD2-24763F9696F8" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 Aug 2017 13:05:10 -0400 In-Reply-To: Cc: dnsop WG To: Lanlan Pan References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 17:05:17 -0000 --Apple-Mail=_08822224-AC60-4708-8BD2-24763F9696F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii El 18 ag 2017, a les 11:33, Lanlan Pan va escriure: > So, can you talk about how your proposal saves cost over using a = heuristic? > It can be used with cache aging heuristic. > Heuristic read in aaa/bbb/ccc.foo.com , expire = and move out; then read in xxx/yyy/zzz.foo.com , = expire and move out; loop... > =3D> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to = *.foo.com when heuristic read, it will reduce the load = of move in/out. By "move out" you mean "remove," right? Move out implies that you are = moving it somewhere. You haven't actually answered my question. You = say that SWILD will remove the load, but you don't give any evidence of = this. >=20 >> 2) cache miss >> All of temporary subdomain wildcards will encounter cache miss. >> Query xxx.foo.com , then query yyy.foo.com = , zzz.foo.com , ... >> We can use SWILD to optimize it, only query xxx.foo.com = for the first time and get SWILD, avoid to send = yyy/zzz.foo.com queries to authoritative server. >=20 > Can you characterize why sending these queries to the authoritative = server is a problem? >=20 > Ok, Similar to RFC8198 section 6 = > Benefit but not problem, directly return from cache, avoid send = queries to authoritative, and wait for response, reduce laterncy. Okay, but this isn't a reason to prefer this to existing, standardized = technology. >> 3) DDoS risk=20 >> The botnet ddos risk and defense is like NSEC aggressive wildcard, or = NSEC unsigned. >> For example, [0-9]+.qzone.qq.com is a popular = SNS website in China, like facebook. If botnets send "popular website = wildcards" to recursive, the cache size of recursive will rise, = recursive can not just simply remove them like some other random label = attack. >> We prefer recursive directly return the IP of subdomain wildcards, = and not rise recursive cach, not send repeat query to authoritative. >=20 > Why do you prefer this? Just saying "we prefer ..." is not a reason = for the IETF to standardize something. >=20 > Sorry, my expression is fault. >=20 > More details: > 1) All of the attack botnets were customers of ISP, sent queries to = ISP recursive with low rate, so all of the client's IP addresses were = "legitimate", could not simply use ACL. > 2) Normal users also visit [0-9]+.qzone.qq.com , = all the the random queries domain seems to "legitimate". > =3D> The client ip addresses and the random subdomains are all in the = whitelist, not in blacklist. > 3) ISP didn't have any DNS firewall equipment ( very sad situation, = but it was true ) to take over the response of "*.qzone.qq.com = ". >=20 > In this weaker scenario, it will be better if give recursive more = information to directly answer queries from cache, and make recursive = not to send/cache many subdomains query/response. > Of course, we can defense the attack with professional operation, = solve the problem very well. But there are also many more weaker = recursive only run bind software, without any protection... Maybe they should upgrade. > I will reconsider these problems of the proposal, make the improvement = analysis on real-world caches before next step. Thanks! However, I would really encourage you to step back from your = proposal and see if there's a way to accomplish what you want without = adding this resource record. I think you can get the same results you = want without SWILD, and the result will be a lot better for the DNS as a = whole. --Apple-Mail=_08822224-AC60-4708-8BD2-24763F9696F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii El 18 ag 2017, a les 11:33, Lanlan Pan <abbypan@gmail.com> = va escriure:
So, = can you talk about how your proposal saves cost over using a = heuristic?
It can be used with cache aging = heuristic.
Heuristic read in = aaa/bbb/ccc.foo.com, = expire and move out;  then read in xxx/yyy/zzz.foo.com,  expire = and move out;  loop...
=3D> Map = aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read, it will reduce the load of = move in/out.

By "move out" you mean "remove," right?   Move out = implies that you are moving it somewhere.   You haven't actually = answered my question.  You say that SWILD will remove the load, but = you don't give any evidence of this.


2) cache miss
All of temporary subdomain wildcards = will encounter cache miss.
Query xxx.foo.com,  then query yyy.foo.com,= zzz.foo.com, ...
We can use SWILD to = optimize it,  only query xxx.foo.com for the first time and get = SWILD, avoid to send yyy/zzz.foo.com queries to authoritative server.

Can you characterize why sending these = queries to the authoritative server is a = problem?

Ok, = Similar to RFC8198 section 6
Benefit but not problem,  directly return = from cache, avoid send queries to authoritative, and wait for response, = reduce laterncy.

Okay, but this isn't a reason to prefer this to = existing, standardized technology.

3) DDoS risk
The botnet ddos risk and defense is = like NSEC aggressive wildcard, or NSEC unsigned.
For = example,  [0-9]+.qzone.qq.com is a popular SNS website in China, like = facebook. If botnets send "popular website wildcards" to = recursive,  the cache size of recursive will rise, recursive can = not just simply remove them like some other random label attack.
We prefer recursive directly return the = IP of subdomain wildcards, and not rise recursive cach, not send repeat = query to authoritative. =

Why do you = prefer this?   Just saying "we prefer ..." is not a reason for the = IETF to standardize something.

Sorry, = my expression is fault.

More = details:
1) All of the attack botnets were = customers of ISP, sent queries to ISP recursive with low rate, so all of = the client's IP addresses were "legitimate", could not simply use = ACL.
2) Normal users also visit = [0-9]+.qzone.qq.com, all = the the random queries domain seems to "legitimate".
=3D> The client ip addresses and the = random subdomains are all in the whitelist, not in blacklist.
3) ISP didn't have any DNS firewall equipment ( very sad = situation, but it was true ) to take over the response of "*.qzone.qq.com".

In this weaker = scenario,  it will be better if give recursive more information to = directly answer queries from cache, and make recursive not to send/cache = many subdomains query/response.
Of course, we can defense the attack with professional = operation, solve the problem very well. But there are also many more = weaker recursive only run bind software, without any protection...

Maybe they should upgrade.

I will reconsider = these problems of the proposal, make the improvement analysis on = real-world caches before next = step.

Thanks! =   However, I would really encourage you to step back from your = proposal and see if there's a way to accomplish what you want without = adding this resource record.   I think you can get the same results = you want without SWILD, and the result will be a lot better for the DNS = as a whole.

= --Apple-Mail=_08822224-AC60-4708-8BD2-24763F9696F8-- From nobody Fri Aug 18 10:38:16 2017 Return-Path: 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 ED3BD126B71 for ; Fri, 18 Aug 2017 10:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 awl0YJlST3Hg for ; Fri, 18 Aug 2017 10:38:11 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D86B120721 for ; Fri, 18 Aug 2017 10:38:11 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id 49so63748176wrw.2 for ; Fri, 18 Aug 2017 10:38:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FvYJ63Z3YzBdr2k+kcAFRSUMId2ZVl7wDbPvfYkeOi4=; b=sM9z/ZW0fCD2oPfn0AQMI07R8qIkC8Qz+9H0oHttMGJ1EWHIuvJDhP6POb33RStQpU gWYd9LX6Wgq5DoezBcqi5v9loTFifbltVHcuDZtgPFZly4HJfygjHoclBlPfxYiWkLjy YUMUx0Q0d4CT4v+oICLFWYXE7WP//aTEIIdMhibJ+nlqcpKsundG7JdGa2v3wLLuAjk2 fC5UDSfR4A+neQ9cs/gYei+iVCvINCmyewLiRViHeER5qppcft+lNHyYlMmVOI+pUfI6 hFUMWeR+ByhR3KP7cQg6Vs6KomHRE6fX/A/GdoHfjx5YLyTolwqRHPcfMLXQctknk6n9 xpRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FvYJ63Z3YzBdr2k+kcAFRSUMId2ZVl7wDbPvfYkeOi4=; b=SoZpq8UbJjDoAWAk3vnhUJmmlq5N+b6L7LCGrsY/Fwv5pwiFjDPohVsMJ4B9pJU9vt 3V9AyYIDUjtgoG9nBWU36XbG+oY1CSpjL9t3CJQZ8/J7a8MDRv01XTBOUNmNoYZDP8b4 bTL5HhwiK1q5cC2/3WwJ0u/YnuJYtVqjLrlEQyvuzEpTZCrV3is9K0yAIfBgHeuIv72r tq4fIHjz4c5L7geS7MCI3s1kqKBsupR69MfDhySqfvaRZXvIZilfgetGVPFbMDV0TrXn N+ldWWYtPq7DtQsOqIvhptF1t9YD+9s7eI/8MbtzjVU4XmfBTEUWdQJINKE8/lFp9i4e WUHw== X-Gm-Message-State: AHYfb5g+hn21SToNVsFSMVU0VEON1TlorXhzb+B9M04C02sBKDoKHSAM LDjaShcxxSwOibk30fNSB+sXPZRPBsHn X-Received: by 10.223.134.180 with SMTP id 49mr5736605wrx.157.1503077889584; Fri, 18 Aug 2017 10:38:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.225.5 with HTTP; Fri, 18 Aug 2017 10:38:09 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Fri, 18 Aug 2017 13:38:09 -0400 Message-ID: To: Brian Dickson Cc: "dnsop@ietf.org WG" Content-Type: multipart/alternative; boundary="001a1146b06cadf39705570a97e0" Archived-At: Subject: Re: [DNSOP] Localhost - more reliable options? X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 17:38:14 -0000 --001a1146b06cadf39705570a97e0 Content-Type: text/plain; charset="UTF-8" Sorry, but point of order: We have a solution that entails a minimal change from the current state of the art and minimal incremental security risk. Let's not re-open fundamental questions, please. On Thu, Aug 17, 2017 at 6:22 PM, Brian Dickson < brian.peter.dickson@gmail.com> wrote: > The discussions about localhost (and 127.0.0.1 and ::1) have ben very > enlightening. > > However, I wonder whether the desired use case -- reliably establishing a > connection to a host, based on information in DNS -- might be more > securely/reliably solved using other mechanisms? > > Using "localhost" is basically making unilateral assumptions (and using > ::1 or 127.0.0.1 equally so). > > I think the reliability, and possibly the security, are better achieved > with bilateral mechanisms. > > E.g. If the specific use case is a client trying to talk to a server, on a > particular port and protocol, then a more robust method of determining that > the server offers such a service, would be using SRV or URI records. > > When the client, resolver, authority server, and service-server may not be > tightly coupled, it might require additional enhancements, such as client > subnet (or similar), to ensure the appropriate answer is given. > > The specific value returned to the query might be 127.0.0.1, or might be > some other address; the main thing is that the address is deliberately > associated with a service that wants the client to use, and presumably the > service knows that the client is on the same host. > > Sorry if this isn't as clear as I intended - basically, what I'm saying, > is that the answer might not even be an IP, protocol and port, but might > even be a "file:///" URI, for a named pipe, which avoids the whole IP stack. > > Hope this provides useful ideas which point away from localhost per se. > > Brian > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > --001a1146b06cadf39705570a97e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry, but point of order: We have a solution that entails= a minimal change from the current state of the art and minimal incremental= security risk.=C2=A0 Let's not re-open fundamental questions, please.<= br>

On Thu, = Aug 17, 2017 at 6:22 PM, Brian Dickson <brian.peter.dickson@gm= ail.com> wrote:
The discussions about localhost (and 127.0.0.1 and ::1) have ben very= enlightening.

However, I wonder whether the desired use= case -- reliably establishing a connection to a host, based on information= in DNS -- might be more securely/reliably solved using other mechanisms?

Using "localhost" is basically making uni= lateral assumptions (and using ::1 or 127.0.0.1 equally so).

=
I think the reliability, and possibly the security, are better a= chieved with bilateral mechanisms.

E.g. If the spe= cific use case is a client trying to talk to a server, on a particular port= and protocol, then a more robust method of determining that the server off= ers such a service, would be using SRV or URI records.

=
When the client, resolver, authority server, and service-server may no= t be tightly coupled, it might require additional enhancements, such as cli= ent subnet (or similar), to ensure the appropriate answer is given.

The specific value returned to the query might be 127.0.0= .1, or might be some other address; the main thing is that the address is d= eliberately associated with a service that wants the client to use, and pre= sumably the service knows that the client is on the same host.
Sorry if this isn't as clear as I intended - basically, wh= at I'm saying, is that the answer might not even be an IP, protocol and= port, but might even be a "file:///" URI, for a named pipe, whic= h avoids the whole IP stack.

Hope this provides us= eful ideas which point away from localhost per se.

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


--001a1146b06cadf39705570a97e0-- From nobody Fri Aug 18 10:39:43 2017 Return-Path: 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 90EB2132195 for ; Fri, 18 Aug 2017 10:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 CggyQqE7DNoI for ; Fri, 18 Aug 2017 10:39:38 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A4E132063 for ; Fri, 18 Aug 2017 10:39:38 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id z18so56608350qka.4 for ; Fri, 18 Aug 2017 10:39:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=LF2y7h1gfQaGwvxv0uIKCKaeuiGFIJ4qwoUJiTEf5U4=; b=kUA5MLR8C6cE4bDkVlyxFXiy/r/P1oeNDBBvCLUZECKlh8umkdKMG/Go6MCYXNbkgL ufNfbbazqQv1NBpCMrlr2EmqvvKtpGgFoN+ks+AQF+WbU1GUFtkRt2FxQaKz/n3Hbmcg s7PUCMPDS0bpVzAfavJDkqAVGUap/Jj5eNW4m+fhgcn/VLBLFryH+Ae6uyLfLOKEgw7m XaLI+S6s18hYQ15WSJ011FsXfYyZyNvqiDyWgzlkRvOF3efGzjl6oj1Sux9gz1F0/Kfc Umt088dIRG3jZkTa6ix1+BJr+Bo3GEBIKC6F2+BkYxdSNtqFegMA3B1q4rjZXFqAAvkQ k39A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=LF2y7h1gfQaGwvxv0uIKCKaeuiGFIJ4qwoUJiTEf5U4=; b=IXZ52dmBxHkAhwgwHg/jtAj+hc3+NKdsWVOw62KdFDPxkW1zAtkZXCvhRv0afkJ7cn pmyy+9p021wWaxtQ9MtYHxoVSVPZ/D19uJ2acSdBQGQ0CFFm5Pkpgn5dEUr0X5CQpuft zPZkfnTSHfS2M5AR9n/QV1Tt/YCBRKv85fKb/8FiNo/5Nu6lq6uz67iX4Z0ie+7k4b4C q9eIg0ATqJ8JRPgXZqS8lYjl8lp6gB/XlnxItl+ypRID0Rd/Bt2V/72Sx3hLYHxnnTKq sHdPUle8EshMR5aOuh8CFlFb1z9pe7GFD0JDhnDwL1uZYQlTkhm8USzwxutrLh4bn/ZS jdZg== X-Gm-Message-State: AHYfb5gdnAaq5Iga75TAQr2I2EjKB9EiA8Igin0A2ilSfieKaZ7q37rI KDgPb+hG91utd/Audzk4kw== X-Received: by 10.55.97.3 with SMTP id v3mr13119780qkb.1.1503077977687; Fri, 18 Aug 2017 10:39:37 -0700 (PDT) Received: from cavall.ether.lede.home (c-24-60-163-103.hsd1.nh.comcast.net. [24.60.163.103]) by smtp.gmail.com with ESMTPSA id 5sm3963339qkf.12.2017.08.18.10.39.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 10:39:36 -0700 (PDT) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_31DCA852-B690-4160-A688-62941E614212" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 Aug 2017 13:39:35 -0400 In-Reply-To: <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> Cc: dnsop WG To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 17:39:42 -0000 --Apple-Mail=_31DCA852-B690-4160-A688-62941E614212 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 El 18 ag 2017, a les 11:12, Petr =C5=A0pa=C4=8Dek = va escriure: > My objections are in the end about engineering costs, which was nicely > summarized by Paul Vixie in another thread (about SWILD, but = applicable > to session signaling as well): > = https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8 = Paul's arguments aren't at all applicable here. He's talking about = having two different resource records that require detailed special = handling; adding a new resource record that accomplishes what is = accomplished by existing code in a different way produces a substantial = increase in complexity not in the transport part of the DNS protocol, = but in the semantics engine of your DNS cache. > For me the major portion of cost does not come from features (like > session management etc.) but from the *framework* needed to build = them. > This cost increase IMHO stems from fact that the framework (SS aka DNS > control plane as you named it) does not build on existing and widely > available components. It's true, TLVs are quite innovative, and have never been used = elsewhere. ;-) > I believe that added complexity is one of serious technical parameters > and I was objecting to it 4 months ago already: > = https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg = The problem is that you didn't say then, and you don't say now, why this = supposed complexity is an important technical consideration. And it's = hard for me to see what the issue is. Nobody has to support this; if = you support it, it's because you want the features. If you want the = features, the complexity isn't really in the wire format serialization = and deserialization=E2=80=94this are trivial. The complexity is in, = for example, implementing DNS Push through a DNS cache if you want to = support it in that context. I admit that this is complex, and I = suspect that there will be little enthusiasm for doing it. That's = okay=E2=80=94it's actually not required that any cache implement DNS = push in order for us to get the benefit of it. But this complexity has = nothing to do with the wire format. The wire format itself is dead trivial. If in fact you need to = implement it, for example in wireshark, there is already code in = wireshark for unpacking TLVs, so it's a very small update. In = comparison, adding some new EDNS0-style OPT RR actually require special = custom code in wireshark, because the fields in the RR are given = different meanings just for that one RR. Of course, wireshark already = (I assume) understands EDNS0, but we can't use EDNS0; if we add a new = SSIG RR that looks like an OPT RR, we would be creating more work for = wireshark hackers than if we just did what the current spec says to do. > In general, as far as I can tell, this document gives no clear > justification why it is a good idea to do it this way. What I really > want, on the highest level, is to see a justification why it is a good > idea *to not reuse and extend existing framework* like EDNS. We have = not > been told of the practical problems that preclude solutions which are > closer to existing code, e.g. EDNS, which would lower the engineering > costs for the whole ecosystem. The most obvious practical problem is that, as I said above, adding = another EDNS0-style option is more complex than using TLVs. In = addition, it consumes more packet space. The actual format of the = packet is less sensible. The decode/encode logic is more complicated. = I don't know if you've written an EDNS0 decoder/encoder; I have. It's = not pretty. Of course you already have one, and so do I; maybe we could reuse the = code. Doing so would also add complexity. And the fact remains that = it's a needlessly arcane data format. The DNSIND (I think) working = group settled on EDNS0 because they thought, as you did, that using = something that looked like a DNS RR would make it more likely that = things would work, but that turned out to be true=E2=80=94we had endless = nightmares with middleboxes being confused by EDNS0. The point being, EDNS0 was a design compromise based on assumptions that = turned out not to be true. I think if the working group had it to do = over again and could see the future, they would have done something like = session signaling, rather than adding the OPT RR. Of course, that's = just my opinion, but the reasoning is as valid now as it would have been = then. The rest of your comments appear to be rehashes of the same basic point, = which boils down to "this is harder than that," with no actual technical = basis for making such an assertion. What I meant when I said "do you have any technical objections" was not = "could you repeat for me in more detail the points you already made = earlier about how if you were designing the enhancement, you would have = done it differently." That's basically what you've done here. You = would have done it differently. That's fine, we're all reasonable = people here, but we won't always agree on matters of taste. But there's no technical objection here. You've asked us to justify = design decisions we've made (I use "we" loosely here, since I'm an end = user of the document, not an author), but not provided any technical = objection to those design decisions. It's not good enough to say "I = think that EDNS0 would be more right." You need to actually say why = TLVs are wrong (or, I suppose, why EDNS0 is more right). You haven't = done that. --Apple-Mail=_31DCA852-B690-4160-A688-62941E614212 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 El 18 ag 2017, a les 11:12, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> = va escriure:
My objections are in the end about engineering = costs, which was nicely
summarized by Paul = Vixie in another thread (about SWILD, but applicable
to session signaling as well):
https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0= UwH354b8

Paul's= arguments aren't at all applicable here.   He's talking about = having two different resource records that require detailed special = handling; adding a new resource record that accomplishes what is = accomplished by existing code in a different way produces a substantial = increase in complexity not in the transport part of the DNS protocol, = but in the semantics engine of your DNS cache.

For me = the major portion of cost does not come from features (like
session management = etc.) but from the *framework* needed to build them.
This cost increase IMHO = stems from fact that the framework (SS aka DNS
control plane as you = named it) does not build on existing and widely
available = components.

It's = true, TLVs are quite innovative, and have never been used elsewhere. =   ;-)

I believe that added = complexity is one of serious technical parameters
and I was objecting to = it 4 months ago already:
https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBr= r5afKBEg

The = problem is that you didn't say then, and you don't say now, why this = supposed complexity is an important technical consideration.   And = it's hard for me to see what the issue is.   Nobody has to support = this; if you support it, it's because you want the features.   If = you want the features, the complexity isn't really in the wire format = serialization and deserialization=E2=80=94this are trivial.   The = complexity is in, for example, implementing DNS Push through a DNS cache = if you want to support it in that context.   I admit that this is = complex, and I suspect that there will be little enthusiasm for doing = it.   That's okay=E2=80=94it's actually not required that any cache = implement DNS push in order for us to get the benefit of it.   But = this complexity has nothing to do with the wire format.

The wire format itself = is dead trivial.   If in fact you need to implement it, for example = in wireshark, there is already code in wireshark for unpacking TLVs, so = it's a very small update.   In comparison, adding some new = EDNS0-style OPT RR actually require special custom code in wireshark, = because the fields in the RR are given different meanings just for that = one RR.   Of course, wireshark already (I assume) understands = EDNS0, but we can't use EDNS0; if we add a new SSIG RR that looks like = an OPT RR, we would be creating more work for wireshark hackers than if = we just did what the current spec says to do.

In = general, as far as I can tell, this document gives no clear
justification why it is = a good idea to do it this way. What I really
want, on the highest = level, is to see a justification why it is a good
idea *to not reuse and = extend existing framework* like EDNS. We have not
been told of the = practical problems that preclude solutions which are
closer to existing = code, e.g. EDNS, which would lower the engineering
costs for the whole = ecosystem.

The = most obvious practical problem is that, as I said above, adding another = EDNS0-style option is more complex than using TLVs.   In addition, = it consumes more packet space.   The actual format of the packet is = less sensible.   The decode/encode logic is more complicated. =   I don't know if you've written an EDNS0 decoder/encoder; I have. =   It's not pretty.

Of course you already have one, and so do I; maybe we could = reuse the code.   Doing so would also add complexity.   And = the fact remains that it's a needlessly arcane data format.   The = DNSIND (I think) working group settled on EDNS0 because they thought, as = you did, that using something that looked like a DNS RR would make it = more likely that things would work, but that turned out to be true=E2=80=94= we had endless nightmares with middleboxes being confused by = EDNS0.

The = point being, EDNS0 was a design compromise based on assumptions that = turned out not to be true.   I think if the working group had it to = do over again and could see the future, they would have done something = like session signaling, rather than adding the OPT RR.   Of course, = that's just my opinion, but the reasoning is as valid now as it would = have been then.

The rest of your comments appear to be rehashes of the same = basic point, which boils down to "this is harder than that," with no = actual technical basis for making such an assertion.

What I meant when I said = "do you have any technical objections" was not "could you repeat for me = in more detail the points you already made earlier about how if you were = designing the enhancement, you would have done it differently."   = That's basically what you've done here.   You would have done it = differently.  That's fine, we're all reasonable people here, but we = won't always agree on matters of taste.

But there's no technical objection = here.   You've asked us to justify design decisions we've made (I = use "we" loosely here, since I'm an end user of the document, not an = author), but not provided any technical objection to those design = decisions.   It's not good enough to say "I think that EDNS0 would = be more right."  You need to actually say why TLVs are wrong (or, I = suppose, why EDNS0 is more right).   You = haven't done that.

= --Apple-Mail=_31DCA852-B690-4160-A688-62941E614212-- From nobody Fri Aug 18 13:46:54 2017 Return-Path: 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 A9C5213234E for ; Fri, 18 Aug 2017 13:46:52 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 qjEO-XhPDXlR for ; Fri, 18 Aug 2017 13:46:50 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97DC6132332 for ; Fri, 18 Aug 2017 13:46:50 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.249.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 396C925B83; Fri, 18 Aug 2017 16:41:21 -0400 (EDT) From: Tom Pusateri Message-Id: <041D0F94-7FBC-4F7E-B200-6A5EECB8776F@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_258E14C8-0ADE-442D-B6FB-46E9CA056A1E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 18 Aug 2017 16:46:48 -0400 In-Reply-To: <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> Cc: Ted Lemon , dnsop WG To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Fri, 18 Aug 2017 20:46:53 -0000 --Apple-Mail=_258E14C8-0ADE-442D-B6FB-46E9CA056A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 18, 2017, at 11:12 AM, Petr =C5=A0pa=C4=8Dek = wrote: >=20 > We can certainly call TLVs "extension" but renaming it does not remove > the fundamental problem: > TLVs are largely incompatible with the code we already have widely > implemented and deployed everywhere in all the DNS implementations and > tools. As a consequence, it is increasing engineering cost for all > involved parties. >=20 There were two main reasons we chose to use TLVs instead of the EDNS(0) = RR format for Session Signaling (soon to be called DNS Stateful = Operations) and it was quite intentional: 1. Given the fact that we were using a new Opcode, we had the = opportunity to change the packet format for the better (at the = suggestion of Mark Andrews). There has been a lot of people in DNSOP = saying EDNS(0) OPT RRs were a mistake. To be fair, some people like it = or are agnostic but we=E2=80=99ve heard more complaints than support. = Using a new Opcode created an unusual and infrequent opportunity to = switch to TLVs without a backlash since all the code would be doing new = things. 2. Since EDNS(0) is per packet and not per session, and Session = Signaling is defined per session over a reliable, ordered transport, we = think it will be less confusing and simpler for implementors to have = separate code to deal with session semantics over the existing per = packet datagram semantics that don=E2=80=99t mean the same thing. * When I say we, I am saying what I understand to be the consensus of = the authors. I don=E2=80=99t mean to speak directly for the other = authors and I will let them correct me if there is disagreement that I = am not aware of. Thanks, Tom --Apple-Mail=_258E14C8-0ADE-442D-B6FB-46E9CA056A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 18, 2017, at 11:12 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> = wrote:

We can certainly call TLVs "extension" = but renaming it does not remove
the fundamental = problem:
TLVs are largely incompatible with the = code we already have widely
implemented and deployed = everywhere in all the DNS implementations and
tools. As a consequence, it is increasing = engineering cost for all
involved parties.

There were two = main reasons we chose to use TLVs instead of the EDNS(0) RR format for = Session Signaling (soon to be called DNS Stateful Operations) and it was = quite intentional:

1. Given the fact = that we were using a new Opcode, we had the opportunity to change the = packet format for the better (at the suggestion of Mark Andrews). There = has been a lot of people in DNSOP saying EDNS(0) OPT RRs were a mistake. = To be fair, some people like it or are agnostic but we=E2=80=99ve heard = more complaints than support. Using a new Opcode created an unusual and = infrequent opportunity to switch to TLVs without a backlash since all = the code would be doing new things.

2.= Since EDNS(0) is per packet and not per session, and Session Signaling = is defined per session over a reliable, ordered transport, we think it = will be less confusing and simpler for implementors to have separate = code to deal with session semantics over the existing per packet = datagram semantics that don=E2=80=99t mean the same thing.

* When I say we, I am saying what I understand to = be the consensus of the authors. I don=E2=80=99t mean to speak directly = for the other authors and I will let them correct me if there is = disagreement that I am not aware of.

Thanks,
Tom


= --Apple-Mail=_258E14C8-0ADE-442D-B6FB-46E9CA056A1E-- From nobody Sat Aug 19 08:47:54 2017 Return-Path: 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 CDF9613294B for ; Sat, 19 Aug 2017 08:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br 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 YXd9IYTly5gN for ; Sat, 19 Aug 2017 08:47:51 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 A9846132941 for ; Sat, 19 Aug 2017 08:47:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id C25AC21565A for ; Sat, 19 Aug 2017 12:47:46 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7OAfEJQb0Ks for ; Sat, 19 Aug 2017 12:47:44 -0300 (BRT) Received: from [192.168.1.81] (unknown [152.254.218.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id AE453215659 for ; Sat, 19 Aug 2017 12:47:44 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1503157664; bh=jiVDbrH9twVcqFZcQRZjLZmvqEWubcQtaMFQj9k7DIw=; h=From:Subject:Date:To:From; b=XnSSR5AIaEaNqBX1BIAWfSsAXQpgg6XhoTkiRVVGN5Mc+8Gg7Ju3PrTTo1gSythCa 1VzjuqCgshDwk7byT83EuGaa1XDLs2suMmZTzyZ8gf8jZj4JqVG4VT7b565W4SnbTl v5Rdry88qD7XdtPwYfLWZQ56Wvn9zlvUj2gMNeWU= From: Rubens Kuhl X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_73023A38-B83C-4739-B8F4-641B29C23DA0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sat, 19 Aug 2017 12:47:43 -0300 Message-Id: <61AE518D-10D7-42BF-89BE-15FB5DC1EE75@nic.br> To: dnsop Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br AE453215659 Archived-At: Subject: [DNSOP] ICANN Name collision framework X-BeenThere: dnsop@ietf.org 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: Sat, 19 Aug 2017 15:47:54 -0000 --Apple-Mail=_73023A38-B83C-4739-B8F4-641B29C23DA0 Content-Type: multipart/alternative; boundary="Apple-Mail=_DF6B7D8E-3034-4A79-A7F5-413650C37E6F" --Apple-Mail=_DF6B7D8E-3034-4A79-A7F5-413650C37E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (Sorry if you have received more than 1 copy of this e-mail, since this = is being sent to technical mailing lists focusing on DNS) There is ongoing policy development effort within ICANN towards = subsequent procedures of new gTLDs releases; during the last round in = 2012, one of the last pieces of the program to be defined was the name = collision framework, detailed at = https://www.icann.org/resources/pages/name-collision-2013-12-06-en = . The current thinking is to keep most of the framework as it was in that = round, with minor changes for low risk strings and some more detail for = other strings. The base principle is to use research-accessible trusted = databases such as DITL and ORDINAL to make decisions. In chronological order, the process would be like this: 1) Pre-application procedure ICANN Org would provide a "do not apply" list containing strings like = localhost and an "exercise care" list containing strings such as the = ones hitting root servers with large number of invalid queries, where = it's expected that a non-standard mitigation framework would be = required. 2) Application time Applicants would need to file a mitigation framework for "exercise care" = strings but could file one for other strings as well. 3) Evaluation time Each applied-for unique string would be evaluated and divided into 3 = buckets of strings: high-risk strings would have their applications = terminated, aggravated risk ones would require non-standard mitigation = framework and low-risk strings would use the standard framework. Note = that "exercise care" strings might turn out to be low-risk, or strings = not listed in any list might turn out to be high or aggravated risk. 4) Controlled interruption As soon as a decision is made regarding risk assessment, ICANN Org = itself would perform 90 days or more of wildcard 127.0.53.53 controlled = interruption for all low-risk strings. This would be different from the = 2012-round as this was done by registry operators after they got IANA = delegation. IANA delegation of those will be actually a redelegation to = registry operators. ICANN Org would have the option to decide answer NXDOMAIN instead of = 127.0.53.53 for specific labels that caused disruption, with the = understanding that those labels would still require 90 days of = controlled interruption to be later used. 5) Aggravated risk strings Each framework will be evaluated using registry services technical = evaluation procedures and carried out by registry operator, with ICANN = monitoring its compliance. Some of the questions still to be answered by the WG include: - Guidelines, lists and/or procedures for creating "do no apply" and = "exercise care" lists - Guidelines and/or procedures for applied strings risk assessment - Whether 2-year readiness for collisions with potential harm to human = life should still exist since none was detected in the 2012-round, and = only 37 collisions were reported to ICANN. - Whether 2012-round TLDs that already completed their 2-year readiness = cycles should still have some kind of operational readiness thru the = lifecycle of the TLD. So, the reasons for outreaching to this technical group include: - Whether someone has feedback for the current thinking of the process. = Nothing is final until they are final. - Whether someone has feedback on the unanswered questions so progress = can be made in those areas. Thanks! Rubens K=C3=BChl --Apple-Mail=_DF6B7D8E-3034-4A79-A7F5-413650C37E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
(Sorry if you have received more than 1 copy of this e-mail, = since this is being sent to technical mailing lists focusing on = DNS)

There is ongoing policy development = effort within ICANN towards subsequent procedures of new gTLDs releases; = during the last round in 2012, one of the last pieces of the program to = be defined was the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06= -en . 

The current thinking is to keep = most of the framework as it was in that round, with minor changes for = low risk strings and some more detail for other strings. The base = principle is to use research-accessible trusted databases such as DITL = and ORDINAL to make decisions. 

In chronological order, the process would be like = this:

1) Pre-application procedure
ICANN Org would = provide a "do not apply" list containing strings like localhost and an = "exercise care" list containing strings such as the ones hitting root = servers with large number of invalid queries, where it's expected that a = non-standard mitigation framework would be required. 

2) Application time
Applicants would need to file a = mitigation framework for "exercise care" strings but could file one for = other strings as well. 

3) Evaluation time
Each applied-for unique string would be = evaluated and divided into 3 buckets of strings: high-risk strings would = have their applications terminated, aggravated risk ones would require = non-standard mitigation framework and low-risk strings would use the = standard framework. Note that "exercise care" strings might turn out to = be low-risk, or strings not listed in any list might turn out to be high = or aggravated risk. 

4) Controlled = interruption
As soon as a decision is made regarding risk assessment, = ICANN Org itself would perform 90 days or more of wildcard 127.0.53.53 = controlled interruption for all low-risk strings. This would be = different from the 2012-round as this was done by registry operators = after they got IANA delegation. IANA delegation of those will be = actually a redelegation to registry operators. 
ICANN Org would = have the option to decide answer NXDOMAIN instead of 127.0.53.53 for = specific labels that caused disruption, with the understanding that = those labels would still require 90 days of controlled interruption to = be later used. 

5) Aggravated = risk strings
Each framework will be evaluated using registry services = technical evaluation procedures and carried out by registry operator, = with ICANN monitoring its compliance. 

Some of the questions still to be answered by the WG = include:
- Guidelines, lists and/or procedures for creating "do no = apply" and "exercise care" lists
- Guidelines and/or procedures for = applied strings risk assessment
- Whether 2-year readiness for = collisions with potential harm to human life should still exist since = none was detected in the 2012-round, and only 37 collisions were = reported to ICANN. 
- Whether 2012-round TLDs that already completed = their 2-year readiness cycles should still have some kind of operational = readiness thru the lifecycle of the TLD.


So, the reasons for outreaching to = this technical group include:
- Whether someone has feedback for the = current thinking of the process. Nothing is final until they are = final. 
- Whether someone has feedback on the unanswered questions so = progress can be made in those areas. 


Thanks!
Rubens K=C3=BChl
= --Apple-Mail=_DF6B7D8E-3034-4A79-A7F5-413650C37E6F-- --Apple-Mail=_73023A38-B83C-4739-B8F4-641B29C23DA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZmF2gAAoJEDaZBOfElOiNosIH/iu99wt55kSSXtt6evYKZVid LkXLPMoByyhV8F3TeuWESSo6kPAdTH9PSHEN9yYS3T/pCKPbkvmwBQ2ERjRZHvuE 74ABMb1qUxjn6N89T4eP5IBqS6vZs8QJrEOTneHQDeCtJQHDvRSsGx8PubT5QfEA 7dhcr9eeOtLqvVMQZA9UQisUbLg92bDJZyA+uCSqPD8jsDLCgTBbitcT/44dKyHq jHC45HHkUH7TDCEI+xWnVtXA/UzjucSsJXFWtGFwsq/niIkB5Q/7manhCT1pHoiY DcrnSHC3437/rrewDlnD6fuQOlkiarwDanZo5imxchCBHkkzLopOElrk5BTOMkw= =OpYm -----END PGP SIGNATURE----- --Apple-Mail=_73023A38-B83C-4739-B8F4-641B29C23DA0-- From nobody Sat Aug 19 18:49:17 2017 Return-Path: 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 E41791321ED for ; Sat, 19 Aug 2017 18:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] 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 uBZstEbZJCZ1 for ; Sat, 19 Aug 2017 18:49:13 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB0F1321A1 for ; Sat, 19 Aug 2017 18:49:12 -0700 (PDT) Received: (qmail 17181 invoked from network); 20 Aug 2017 01:49:12 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 20 Aug 2017 01:49:12 -0000 Date: 20 Aug 2017 01:48:50 -0000 Message-ID: <20170820014850.1072.qmail@ary.lan> From: "John Levine" To: dnsop@ietf.org Cc: petr.spacek@nic.cz In-Reply-To: <272dc071-c650-220c-3528-acb9467c706b@nic.cz> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Sun, 20 Aug 2017 01:49:15 -0000 In article <272dc071-c650-220c-3528-acb9467c706b@nic.cz> you write: >Yes, someone might try to attack a domain using this. To lower >probability of this kind of attack CZ.NIC is nagging the technical >contact for one week before the DS gets installed into the CZ zone. > >For further details please see >https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/ > >We will see how it goes. That's certainly one of the approaches that Olafur suggested, and it would definitely be easy to implement. Please let us know what you learn. R's, John From nobody Sat Aug 19 20:03:48 2017 Return-Path: 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 785FE132441 for ; Sat, 19 Aug 2017 20:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ITNii9BkH7KE for ; Sat, 19 Aug 2017 20:03:45 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5737D132436 for ; Sat, 19 Aug 2017 20:03:45 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x77so25600908qka.5 for ; Sat, 19 Aug 2017 20:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=8Z6padfKVmGgfNQuIF9hKW+uZ7+lODQ1E9GD4mz7EjI=; b=Hh+yKoiJvMM7szNUzhLUPOB1adWYUgbq1il5jRrXvoBiFoLSPQ/q884yhQPFSzkAnI ToJZHKwida8ZyK1yyjBl4zldVtX0A01QE2LOWL8k/G3JLZ/IezqDtfThd7zdmSmRNl9j bTWbFU4TI43anK2KlqoOotKm25+Rr+MRY26B5fvAC5gywZZYO3WLXLLztbw3bCSWtMXM ZX/JEw/P5KcVmVklNkCJTYR2JVgW9MsAghEBvwUm9Vb07qLdef6eABgoBZkMtu11YKUp QzRuPyHCNSNPFgs3qU5uXl03cdGQrWDvxwyaBs2SAqxdDuuBtoqJatvnVeOfebHKLu42 9QEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=8Z6padfKVmGgfNQuIF9hKW+uZ7+lODQ1E9GD4mz7EjI=; b=EhFtkZlMa+uR39u/z/bmU0gY+n5zBtaUal5N1IBwIjSGlSViXvOT+SL/I1g2qPkN4n yn5PeIFBtPsa//ZkkKtc4dDOOaHL4pa4LSdZ/sPfPJAAog93MBsIMIUNY6vAAasBM0qa ai1/LmzrRZCYvivcE4z7BbH/iOqyzIAnKxkDw8MfQuDH3U4dTA+PE4ZQr/mlR+rziAw3 3J78US/AW+oee1rV3UrGkJfkEj+y9DmGSjGcThD52zibFuP8aIwh3AiCyjRvvmmeP6T/ STjX2RIalAg3sYCF18kf0yYaie5UXiBERZwTaG9E/IF18jOb/27bfI8/Wron8fN+aMLZ aNFQ== X-Gm-Message-State: AHYfb5gRN42G9ivkSO6n7Rz7fSdJiGZFAAcyLF5+KkiqSONDy1u72gyb HT6hJ4nS8oRGiXvX X-Received: by 10.55.12.1 with SMTP id 1mr18071197qkm.319.1503198224530; Sat, 19 Aug 2017 20:03:44 -0700 (PDT) Received: from [10.0.0.22] (c-24-63-89-87.hsd1.ma.comcast.net. [24.63.89.87]) by smtp.gmail.com with ESMTPSA id a12sm4803245qta.66.2017.08.19.20.03.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 19 Aug 2017 20:03:43 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0BD357D-E30E-43E4-B8D1-79E0066AE0B0" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Suzanne Woolf In-Reply-To: <61AE518D-10D7-42BF-89BE-15FB5DC1EE75@nic.br> Date: Sat, 19 Aug 2017 23:03:41 -0400 Cc: dnsop Message-Id: References: <61AE518D-10D7-42BF-89BE-15FB5DC1EE75@nic.br> To: Rubens Kuhl X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [DNSOP] ICANN Name collision framework X-BeenThere: dnsop@ietf.org 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: Sun, 20 Aug 2017 03:03:47 -0000 --Apple-Mail=_C0BD357D-E30E-43E4-B8D1-79E0066AE0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On Aug 19, 2017, at 11:47 AM, Rubens Kuhl wrote: > (Sorry if you have received more than 1 copy of this e-mail, since = this is being sent to technical mailing lists focusing on DNS) >=20 > There is ongoing policy development effort within ICANN towards = subsequent procedures of new gTLDs releases; during the last round in = 2012, one of the last pieces of the program to be defined was the name = collision framework, detailed at = https://www.icann.org/resources/pages/name-collision-2013-12-06-en .=20 >=20 > The current thinking is to keep most of the framework as it was in = that round, with minor changes for low risk strings and some more detail = for other strings. The base principle is to use research-accessible = trusted databases such as DITL and ORDINAL to make decisions.=20 It's very good to see this outreach regarding the ICANN gTLD policy = process, and this specific topic may well be of interest to DNSOP = participants. However, it's also not a core topic for this group, and is likely to be = of interest to others as well. Is there a dedicated mailing list, wiki, = or other venue for people to offer their comments or continue the = discussion? There is a reference in the text to "the WG" ("Some of the questions = still to be answered by the WG include=85") Could you expand the = reference? Where can an interested DNSOP participant go to find out more = about this WG and its work to date? thanks, Suzanne --Apple-Mail=_C0BD357D-E30E-43E4-B8D1-79E0066AE0B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 rubensk@nic.br> = wrote:

(Sorry if you = have received more than 1 copy of this e-mail, since this is being sent = to technical mailing lists focusing on DNS)

There is ongoing policy development effort within ICANN = towards subsequent procedures of new gTLDs releases; during the last = round in 2012, one of the last pieces of the program to be defined was = the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06= -en . 

The current thinking is to keep = most of the framework as it was in that round, with minor changes for = low risk strings and some more detail for other strings. The base = principle is to use research-accessible trusted databases such as DITL = and ORDINAL to make = decisions. 

It's very = good to see this outreach regarding the ICANN gTLD policy process, and = this specific topic may well be of interest to DNSOP = participants.

However, it's also not a core = topic for this group, and is likely to be of interest to others as well. =  Is there a dedicated mailing list, wiki, or other venue for people = to offer their comments or continue the = discussion?

There is a reference in the text to = "the WG" ("Some of the questions still to be answered by the WG = include=85") Could you expand the reference? Where can an interested = DNSOP participant go to find out more about this WG and its work to = date?


thanks,
Suzanne


= --Apple-Mail=_C0BD357D-E30E-43E4-B8D1-79E0066AE0B0-- From nobody Sun Aug 20 04:28:45 2017 Return-Path: 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 283F61323AD for ; Sun, 20 Aug 2017 04:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br 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 P_oinqjw5zK6 for ; Sun, 20 Aug 2017 04:28:41 -0700 (PDT) Received: from mail.nic.br (mail.nic.br [200.160.4.5]) (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 8F167132397 for ; Sun, 20 Aug 2017 04:28:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.nic.br (Postfix) with ESMTP id 562D32152A3; Sun, 20 Aug 2017 08:28:38 -0300 (BRT) X-Virus-Scanned: Debian amavisd-new at mail.nic.br Authentication-Results: mail.nic.br (amavisd-new); dkim=pass (1024-bit key) header.d=nic.br Received: from mail.nic.br ([127.0.0.1]) by localhost (mail.nic.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOQIaHwjm5BH; Sun, 20 Aug 2017 08:28:35 -0300 (BRT) Received: from [192.168.1.81] (unknown [152.254.218.200]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rubensk@nic.br) by mail.nic.br (Postfix) with ESMTPSA id 67CF920CA82; Sun, 20 Aug 2017 08:28:35 -0300 (BRT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.br; s=dkim; t=1503228515; bh=3vtZFJRczqpBciPLmM5SpXl8WK4pU40MMB5NDDTs/NM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=tJ3qrcezcY4FfslSb8NAD/sMLfbNug5JgsXGnpUxPu07k5EK7Q5+htg7wf/KnIF7L ErUyzIx1h6MKXuNOEUbtSiAm3ZtVqo6we7Ju2hCMyzAGXBr7wcFjV/j1VMr7GhZYu8 yN3/W50W+F2DAOU18Y31SRhpctLwo6TvkECE768Y= Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E0FB9DC1-9D46-45AD-A146-326072AB0109"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Rubens Kuhl In-Reply-To: Date: Sun, 20 Aug 2017 08:28:30 -0300 Cc: dnsop Message-Id: <74346199-9D3F-4BBC-8055-DB00EB5C81F4@nic.br> References: <61AE518D-10D7-42BF-89BE-15FB5DC1EE75@nic.br> To: Suzanne Woolf X-Mailer: Apple Mail (2.3124) DMARC-Filter: OpenDMARC Filter v1.3.1 mail.nic.br 67CF920CA82 Archived-At: Subject: Re: [DNSOP] ICANN Name collision framework X-BeenThere: dnsop@ietf.org 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: Sun, 20 Aug 2017 11:28:44 -0000 --Apple-Mail=_E0FB9DC1-9D46-45AD-A146-326072AB0109 Content-Type: multipart/alternative; boundary="Apple-Mail=_1512665B-2680-42E8-915D-14732A92D3AF" --Apple-Mail=_1512665B-2680-42E8-915D-14732A92D3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Aug 20, 2017, at 12:03 AM, Suzanne Woolf = wrote: >=20 > Hi, >=20 >=20 > On Aug 19, 2017, at 11:47 AM, Rubens Kuhl > wrote: >=20 >> (Sorry if you have received more than 1 copy of this e-mail, since = this is being sent to technical mailing lists focusing on DNS) >>=20 >> There is ongoing policy development effort within ICANN towards = subsequent procedures of new gTLDs releases; during the last round in = 2012, one of the last pieces of the program to be defined was the name = collision framework, detailed at = https://www.icann.org/resources/pages/name-collision-2013-12-06-en = . >>=20 >> The current thinking is to keep most of the framework as it was in = that round, with minor changes for low risk strings and some more detail = for other strings. The base principle is to use research-accessible = trusted databases such as DITL and ORDINAL to make decisions. >=20 > It's very good to see this outreach regarding the ICANN gTLD policy = process, and this specific topic may well be of interest to DNSOP = participants. >=20 > However, it's also not a core topic for this group, and is likely to = be of interest to others as well. Is there a dedicated mailing list, = wiki, or other venue for people to offer their comments or continue the = discussion? The Subsequent Procedures PDP WG is currently operating with a full WG = and 4 WT (work-tracks); one of the WTs is the one discussing IDNs, = evaluation questions and name collisions. So although there is not one = specific to DNS topics, and WT4 also discusses things like financial = evaluation of applications, universal acceptance etc., WT4 would be the = closest one. And is within WT4 that the framework I mentioned was = discussed. All GNSO PDP WGs have one requirement to participate: publish an SOI at = https://community.icann.org/pages/viewpage.action?pageId=3D14713457 = . WT4 mailing list is available at = https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 = ; WT4 wiki = space is located at = https://community.icann.org/pages/viewpage.action?pageId=3D60490781 = . >=20 > There is a reference in the text to "the WG" ("Some of the questions = still to be answered by the WG include=85") Could you expand the = reference? Where can an interested DNSOP participant go to find out more = about this WG and its work to date? >=20 The main wiki space for the full WG is available at = https://community.icann.org/display/NGSPP/New+gTLD+Subsequent+Procedures+P= DP+Home = . Starting last March the group started releasing a monthly = newsletter which can be a good way to get up-to-speed on the different = work tracks. They are linked from = https://community.icann.org/pages/viewpage.action?pageId=3D58001970 = . Rubens --Apple-Mail=_1512665B-2680-42E8-915D-14732A92D3AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 20, 2017, at 12:03 AM, Suzanne Woolf <suzworldwide@gmail.com> wrote:

Hi,


On Aug 19, 2017, at 11:47 AM, Rubens Kuhl = <rubensk@nic.br> = wrote:

(Sorry if you have received more than 1 copy of this = e-mail, since this is being sent to technical mailing lists focusing on = DNS)

There is ongoing policy development = effort within ICANN towards subsequent procedures of new gTLDs releases; = during the last round in 2012, one of the last pieces of the program to = be defined was the name collision framework, detailed at https://www.icann.org/resources/pages/name-collision-2013-12-06= -en . 

The current thinking is to keep = most of the framework as it was in that round, with minor changes for = low risk strings and some more detail for other strings. The base = principle is to use research-accessible trusted databases such as DITL = and ORDINAL to make decisions. 

It's very good to see this outreach = regarding the ICANN gTLD policy process, and this specific topic may = well be of interest to DNSOP participants.

However, it's also not a core topic for = this group, and is likely to be of interest to others as well.  Is = there a dedicated mailing list, wiki, or other venue for people to offer = their comments or continue the = discussion?

The = Subsequent Procedures PDP WG is currently operating with a full WG and 4 = WT (work-tracks); one of the WTs is the one discussing IDNs, evaluation = questions and name collisions. So although there is not one specific to = DNS topics, and WT4 also discusses things like financial evaluation of = applications, universal acceptance etc., WT4 would be the closest one. = And is within WT4 that the framework I mentioned was = discussed. 

All GNSO PDP WGs = have one requirement to participate: publish an SOI at https://community.icann.org/pages/viewpage.action?pageId=3D1471= 3457 .





There is = a reference in the text to "the WG" ("Some of the questions still to be = answered by the WG include=85") Could you expand the reference? Where = can an interested DNSOP participant go to find out more about this WG = and its work to date?


The = main wiki space for the full WG is available at https://community.icann.org/display/NGSPP/New+gTLD+Subsequent+P= rocedures+PDP+Home . Starting last March the group started = releasing a monthly newsletter which can be a good way to get = up-to-speed on the different work tracks. They are linked from https://community.icann.org/pages/viewpage.action?pageId=3D5800= 1970 . 



Rubens



= --Apple-Mail=_1512665B-2680-42E8-915D-14732A92D3AF-- --Apple-Mail=_E0FB9DC1-9D46-45AD-A146-326072AB0109 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJZmXJiAAoJEDaZBOfElOiNWRwIAIt9t010xGJodLw3DnjU3F00 yue5JScMqh4rkAgCiswNYBt6a/q/JlEMOx/OBsY1smnTivXVVyEGnjeJhMXhWjyU 7YEVttDFvYHcLhXlknDYXzEPLPqzY1mftoNoixwaeDQhA0BxokB3taTTjZARlP09 JhtZ2AetQeKqXgFcgQnHTfNhgbWr8ZAZqbGcAuKstmb73eT6C93ZdbolhM/JtsXv JxebQH40gbLJWFMaz9TBGlJVG+AQiiFj1WuWrCwoO00Igd3hbnebhwA1DdXlgRWY yXvVGKB/bUvmJp8lp6RJymFGWmMO+EM+51KdoxluTUIo6J6f9nxEPMhfkWcBjPg= =IK0M -----END PGP SIGNATURE----- --Apple-Mail=_E0FB9DC1-9D46-45AD-A146-326072AB0109-- From nobody Sun Aug 20 23:20:19 2017 Return-Path: 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 DD5E41320BE for ; Sun, 20 Aug 2017 23:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 QMIuRraPWRQj for ; Sun, 20 Aug 2017 23:20:16 -0700 (PDT) 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 61529126B71 for ; Sun, 20 Aug 2017 23:20:15 -0700 (PDT) Received: from [192.168.3.212] (ip4-95-82-146-6.cust.nbox.cz [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 7399661144 for ; Mon, 21 Aug 2017 08:20:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503296412; bh=XDB/kdhOPsz52kmTRpQbiDqJ5Q2mdz7Cxq2qcR8jbkY=; h=To:From:Date; b=wIZFstG4GdUOR6kmzcMMypSdIiItxVRO4mt2FtOZN75jYa4rCb28V5NPfgde759MU xEWw1iW1YsN2d6heQADaNTHRHcC/fMJ+6q4blCWQhbz2AmLZMwT4X0v1EWl7pem2Pv bqoQgTP7k8aO+WBgWT5hVwo76sFWWTICGvsxnj2A= To: dnsop@ietf.org References: <150143619012.17703.6263456348626337808.idtracker@ietfa.amsl.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <328a6505-58ac-cb19-625d-34fa8af9c92f@nic.cz> Date: Mon, 21 Aug 2017 08:20:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150143619012.17703.6263456348626337808.idtracker@ietfa.amsl.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: Subject: Re: [DNSOP] The DNSOP WG has placed draft-tale-dnsop-serve-stale in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org 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: Mon, 21 Aug 2017 06:20:19 -0000 On 30.7.2017 19:36, IETF Secretariat wrote: > The DNSOP WG has placed draft-tale-dnsop-serve-stale in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ I support adoption, will review. -- Petr Špaček @ CZ.NIC From nobody Sun Aug 20 23:24:07 2017 Return-Path: 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 6EF2B1320BE for ; Sun, 20 Aug 2017 23:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 dCoAkGL1fGaL for ; Sun, 20 Aug 2017 23:24:04 -0700 (PDT) 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 0964F126B71 for ; Sun, 20 Aug 2017 23:24:04 -0700 (PDT) Received: from [192.168.3.212] (ip4-95-82-146-6.cust.nbox.cz [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id A568461144 for ; Mon, 21 Aug 2017 08:24:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503296642; bh=L0rTQb0LVOTsJfBzZBaCnPdh3hyv+ymaFz8DXtTXdNI=; h=To:From:Date; b=ag5dDEi/NXm1w6vAlHwDncrKRCr7VaEOpjm5NVDhrBTrdci5He/qA/uDNBqdDbqJ+ C9ah0Gx2KolXcjJbPMJXga3LVSla7+i+UX/1YcuWkivTRxYP+EAvbsXCUCZRMnbW2i d/zp9aC3F/xUGxXTjeKocy9LmJDMKFjA+Tj9RnsI= To: dnsop@ietf.org References: <9fc7ff7d-9f5a-ce2b-9fb1-e9b1c9eb0108@nostrum.com> <94641677-d072-3462-1c72-ab203c553eef@dcrocker.net> <20170810052443.ltfr4mjskwvwvg3q@mx4.yitter.info> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Mon, 21 Aug 2017 08:24:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170810052443.ltfr4mjskwvwvg3q@mx4.yitter.info> 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: Subject: Re: [DNSOP] [art] draft-ietf-dnsop-attrleaf X-BeenThere: dnsop@ietf.org 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: Mon, 21 Aug 2017 06:24:05 -0000 On 10.8.2017 07:24, Andrew Sullivan wrote: > Hi, > > On Thu, Aug 03, 2017 at 03:36:24PM -0700, Dave Crocker wrote: > >> deal with that fully, in a single spec produced an especially confused >> draft, roughly 10 years ago. > > I _think_ I may be one of the people who complained at the time, and > if I recall correctly what Dave and I agreed about (maybe the only > thing) was that this was all a terrible mess that needed repair. At > the time, I was still too much in thrall to data-theoretic approaches > to give in on Dave's pragmatic answer. And I now see that Dave has > actually described better than I was ever able my objection: > >> I've come to the conclusion that "accommodating" the established >> registration practices is a fundamentally wrong path. The only way to solve >> a problem of multiple registration authorities is to create a single >> registration authority. > > Yes. > >> 1. Have this document define the simple, sole, authoritative mechanism >> for registering "top-level" (global scope) underscore names. >> >> 2. Create a separate document that specifies modifications to the SRV and >> URI documents, rationalizing the use of underscore names, through the >> mechanism defined in -attrleaf-. > > I like this approach. Definitelly! -- Petr Špaček @ CZ.NIC From nobody Mon Aug 21 11:46:19 2017 Return-Path: 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 13E7C132A9A for ; Mon, 21 Aug 2017 11:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.778 X-Spam-Level: X-Spam-Status: No, score=-0.778 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com 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 y1fNeYo4IjLw for ; Mon, 21 Aug 2017 11:46:14 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BD58132AB2 for ; Mon, 21 Aug 2017 11:45:13 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id z91so104834452wrc.4 for ; Mon, 21 Aug 2017 11:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cKvSe3TJd3jHpROUghrS7Z4FPrF7Z+fU+PefKWQuyZg=; b=G7k2wvh0n4mSTTEay3DFhQ8MMquRmSdWGFj2upAtp8WAau/0gWS4G7LLiA1iX/uTIf SE61V3jR3iy0Bt2zjXw35E5CVYLSvfYAblSqeYX6FcUXQNyAbK31O7fws+6aza02nEp/ lkOtfqEDkWIor1tP8LOITXt4CWYmw0WEHhqJITk0zG04dMrCnscFZI9+QERdB6Wm/EDM dwg92Rm4Cyn41XPrg4nkMaJ/6kWJ3GjLe1dcnpJTRKUqWneTnnzQt+shiTofz2dzi9HM PJC800bQFT/G8L42se9mop44YBYvY/Ec+JpN7V9lokG3VmGSFd7rfo8jJB3hB5HUkd1a hl6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cKvSe3TJd3jHpROUghrS7Z4FPrF7Z+fU+PefKWQuyZg=; b=CiHPy4ssQr7fQVBqKesGCGQYLJY50GU9qSi8CqXqLVSiNvlrZsj/GfQhIVgQFyIuS5 iFapnK5mY3y/nibuByi3lwQOx1FwgtiiBWcv1Z1M9Mxo+jx4EOhUx+QILjiiXqANk/7G auJ6dNzTG0EBos5hKPbkva6Ly8FOt4hFwF/abMp9Rkl5hJCDrme06xQhBwtbKwtC+g77 3P43w55BGDfBc2ccn28FPpTYiWfNdnkUc9e9iYpq/GhCOLFhXkbo6xH9HY4Kt1fM3lFK urCEFxA77H/ZcjGDnC8vsSK7F/jdOCubAUTTGvDaOkzop1GC7+iYy1Nhd39s1RzAV4kI TCVg== X-Gm-Message-State: AHYfb5jdb/oSOnuhznYZQtE50Qu8SGdEmiPOHrf3ZXXmtrH9rIYp5w9S 75c8pKdWSB6NxJzqpfHF9iABgZWuZQRG X-Received: by 10.223.152.19 with SMTP id v19mr12028231wrb.60.1503341111372; Mon, 21 Aug 2017 11:45:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.135 with HTTP; Mon, 21 Aug 2017 11:44:30 -0700 (PDT) In-Reply-To: References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> From: Warren Kumari Date: Mon, 21 Aug 2017 14:44:30 -0400 Message-ID: To: Ted Lemon Cc: Lanlan Pan , dnsop WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Mon, 21 Aug 2017 18:46:17 -0000 I was really trying to stay out of this thread... On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon wrote: > El 18 ag 2017, a les 11:33, Lanlan Pan va escriure: > > So, can you talk about how your proposal saves cost over using a heuristi= c? > It can be used with cache aging heuristic. > Heuristic read in aaa/bbb/ccc.foo.com, expire and move out; then read in > xxx/yyy/zzz.foo.com, expire and move out; loop... > =3D> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read,= it > will reduce the load of move in/out. > > > By "move out" you mean "remove," right? Move out implies that you are > moving it somewhere. You haven't actually answered my question. You sa= y > that SWILD will remove the load, but you don't give any evidence of this. Yup. Earlier in the thread, one of justifications for this work was "DNS Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS Traffic." (posted by Lanlan Pan). In the abstract of the same is: "Disposable domains are likely generated automatically, characterized by a =E2=80=9Cone-time use=E2=80=9D = pattern, and appear to be used as a way of =E2=80=9Csignaling=E2=80=9D via DNS queri= es." The document contains some examples of these "disposable domains", includin= g: 0.0.0.0.1.0.0.4e.135jg5e1pd7s4735ftrqweufm5.avqs.mcafee.com McAfee's site says: "GTI File Reputation looks for suspicious programs, Portable Document Format (PDF) files, and Android Application Package (.APK) files that are active on endpoints running McAfee products, including Endpoint Security (ENS), VirusScan Enterprise (VSE), and SaaS Endpoint Protection (formerly known as Total Protection Service). If any suspicious files are found that do not trigger existing signature DAT files, GTI sends a DNS request to a central database server hosted by McAfee Labs." Basically, the way that this works is to generate a hash (or similar) of an object and query that hash in the DNS -- information is returned encoded in the address. It is quite clear that McAfee could not (and would not) want to publish a record saying that this is a wildcard -- if they did, they would either mark all objects as safe, or as malicious. Another example is: load-0-p-01.up-1852280.mem-251379712-24440832-0-p-50.swap-236691456-2979430= 40-0-p-44.3302068.1222092134.device.trans.manage.esoft.com Fascinating, but device.trans.manage.esoft.com has no incentive to publish a wildcard marker -- the whole purpose of this query appears to get data back to manage.esoft.com -- having this get answered from an intermediate cache would defeat this. The third example is: p2.a22a43lt5rwfg.ihg5ki5i6q3cfn3n.191742.s1.v4.ipv6-exp.l.google.com Lorenzo Colitti, Steinar, Erik Kline, Tiziana Refice have a good writeup of the purpose of these here: "Evaluating IPv6 Adoption in the Internet" - https://static.googleusercontent.com/media/research.google.com/= en//pubs/archive/36240.pdf Again, these queries are being made for a reason -- it isn't that the senders figured "I know, let's make a DNS query for fun!!!" - they wanted to query for some data, or send some data -- like the abstract says: "=E2=80=9Csignaling=E2=80=9D via DNS queries." In all of the above, publishing a "this is a wildcard" completely breaks the purpose of the queries, and so there is no incentive for these entities to publish such a record... >> >> 2) cache miss >> All of temporary subdomain wildcards will encounter cache miss. >> Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... >> We can use SWILD to optimize it, only query xxx.foo.com for the first >> time and get SWILD, avoid to send yyy/zzz.foo.com queries to authoritati= ve >> server. >> >> >> Can you characterize why sending these queries to the authoritative serv= er >> is a problem? > For the examples used in the paper justifying this, it's not a problem, it's the purpose :-) > > Ok, Similar to RFC8198 section 6 > Benefit but not problem, directly return from cache, avoid send queries = to > authoritative, and wait for response, reduce laterncy. > > > Okay, but this isn't a reason to prefer this to existing, standardized > technology. > >> 3) DDoS risk >> The botnet ddos risk and defense is like NSEC aggressive wildcard, or NS= EC >> unsigned. >> For example, [0-9]+.qzone.qq.com is a popular SNS website in China, lik= e >> facebook. If botnets send "popular website wildcards" to recursive, the >> cache size of recursive will rise, recursive can not just simply remove = them >> like some other random label attack. >> We prefer recursive directly return the IP of subdomain wildcards, and n= ot >> rise recursive cach, not send repeat query to authoritative. >> >> >> Why do you prefer this? Just saying "we prefer ..." is not a reason fo= r >> the IETF to standardize something. > > > Sorry, my expression is fault. > > More details: > 1) All of the attack botnets were customers of ISP, sent queries to ISP > recursive with low rate, so all of the client's IP addresses were > "legitimate", could not simply use ACL. > 2) Normal users also visit [0-9]+.qzone.qq.com, all the the random querie= s > domain seems to "legitimate". > =3D> The client ip addresses and the random subdomains are all in the > whitelist, not in blacklist. > 3) ISP didn't have any DNS firewall equipment ( very sad situation, but i= t > was true ) to take over the response of "*.qzone.qq.com". > > In this weaker scenario, it will be better if give recursive more > information to directly answer queries from cache, and make recursive not= to > send/cache many subdomains query/response. > Of course, we can defense the attack with professional operation, solve t= he > problem very well. But there are also many more weaker recursive only run > bind software, without any protection... > > > Maybe they should upgrade. > > I will reconsider these problems of the proposal, make the improvement > analysis on real-world caches before next step. > > > Thanks! However, I would really encourage you to step back from your > proposal and see if there's a way to accomplish what you want without add= ing > this resource record. I think you can get the same results you want > without SWILD, and the result will be a lot better for the DNS as a whole= . > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 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 nobody Tue Aug 22 00:52:56 2017 Return-Path: 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 326CE1321B7 for ; Tue, 22 Aug 2017 00:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iq0-fJeXsvDp for ; Tue, 22 Aug 2017 00:52:52 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D94F126B71 for ; Tue, 22 Aug 2017 00:52:51 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k46so43066930wre.2 for ; Tue, 22 Aug 2017 00:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XMPotzlvbD7hNoLw32A3GxKDOGhmnrpEGTxWWvidfzo=; b=QZPVcPbu/r4orm1fEafOzDyKC7EAZajLAzi6Tanh8cZwQvkSk7S3K0IcnXbygLQf7E TGu7QeWixl1g/e0p5K3KAsHZA+jSUfD4SeXLPuv4h7mxwEz2oVuRBJvndzIteMM9FNsm M7je3oQKVVvJ5Xhiu979C5w2+xN0/V/99D8mkZlIUN8XpcXeFIki7BgSxBOMiSaAXmT/ SGl99Z2fYDolL2L8b7SIizsoYSZDfOYihnjavy9dNJnet0lpKAcGlQlCRFHuCKWFTOBp sC1hYHShursIoSBvAap3Js7wWI8qi/MHvFBFEAfrwejj3d+dW1dJ+54Mq+taOC1AFcIH ww2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XMPotzlvbD7hNoLw32A3GxKDOGhmnrpEGTxWWvidfzo=; b=L/vLeyytv2LIaVwgagAgbFolFz0hcvsxXJK/Fzrck4+dUFuy2u/0WojXtUR3GlRpcm 9zs6eh5Zbj611AjScA3gsGNgWhPnWE2dJMHRN0927U0hn6X1lDGuNEwNsWUf34dypVDC L5NrZt+S0/hbeQsTYi58udYjty8/My7LMZ4w92wnH848qkA+P9uXxaM8pkNRWp2l3tMK 1YbjJyL7T4d6wEK+huwX0JBgRA7lwz1Cs4KyTvsCpyWwGUbMuqfcbA7gPE5ERXv3RcBk XBVUSaKj5uJhzigShp2tCmG3Z4Vh5agBmZar5x/2qXwPWClwrT/dyZ/REvNtO3sMKjwr pnqQ== X-Gm-Message-State: AHYfb5iVJMIK2t3ntHF0e2jr19gfWgogvnYWCgMsiD3TXkwehl0j5Hsg xrwQjuv4MC3kV7XrpJ2CWyqV5BJ2YzZF X-Received: by 10.80.174.218 with SMTP id f26mr11887377edd.286.1503388369932; Tue, 22 Aug 2017 00:52:49 -0700 (PDT) MIME-Version: 1.0 References: <201708151341.v7FDfNqR039481@calcite.rhyolite.com> <3337C704-0398-439E-8C9A-8A4BA9FB7413@fugue.com> In-Reply-To: From: Lanlan Pan Date: Tue, 22 Aug 2017 07:52:38 +0000 Message-ID: To: Warren Kumari , Ted Lemon Cc: dnsop WG Content-Type: multipart/alternative; boundary="f403045c4eeabfd667055752e1dc" Archived-At: Subject: Re: [DNSOP] New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt X-BeenThere: dnsop@ietf.org 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: Tue, 22 Aug 2017 07:52:55 -0000 --f403045c4eeabfd667055752e1dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Warren, Thanks for your work, :-) I totally agree: Not all Disposable Domains are wildcards like xxx.github.io / xxx.blogspot.com / xxx.qzone.qq.com. So, wildcard solution can not cover all example Disposable/Temporary Domains in the paper, as your analysis. The question is how to avoid unnecessary caches and queries, give recursive more power to defense with wildcard issue. As Ted's advice, for a better justification, I will do more analysis on recursive cache, which kind of temporary domain is "particular", wildcard domains or "domains has no incentive to publish a wildcard marker". Warren Kumari =E4=BA=8E2017=E5=B9=B48=E6=9C=8822=E6=97= =A5=E5=91=A8=E4=BA=8C =E4=B8=8A=E5=8D=882:45=E5=86=99=E9=81=93=EF=BC=9A > I was really trying to stay out of this thread... > > > On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon wrote: > > El 18 ag 2017, a les 11:33, Lanlan Pan va escriure: > > > > So, can you talk about how your proposal saves cost over using a > heuristic? > > It can be used with cache aging heuristic. > > Heuristic read in aaa/bbb/ccc.foo.com, expire and move out; then read > in > > xxx/yyy/zzz.foo.com, expire and move out; loop... > > =3D> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic rea= d, > it > > will reduce the load of move in/out. > > > > > > By "move out" you mean "remove," right? Move out implies that you are > > moving it somewhere. You haven't actually answered my question. You > say > > that SWILD will remove the load, but you don't give any evidence of thi= s. > > Yup. > > Earlier in the thread, one of justifications for this work was "DNS > Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS > Traffic." (posted by Lanlan Pan). > In the abstract of the same is: "Disposable domains are likely > generated automatically, characterized by a =E2=80=9Cone-time use=E2=80= =9D pattern, > and appear to be used as a way of =E2=80=9Csignaling=E2=80=9D via DNS que= ries." > > The document contains some examples of these "disposable domains", > including: > 0.0.0.0.1.0.0.4e.135jg5e1pd7s4735ftrqweufm5.avqs.mcafee.com > > McAfee's site says: "GTI File Reputation looks for suspicious > programs, Portable Document Format (PDF) files, and Android > Application Package (.APK) files that are active on endpoints running > McAfee products, including Endpoint Security (ENS), VirusScan > Enterprise (VSE), and SaaS Endpoint Protection (formerly known as > Total Protection Service). If any suspicious files are found that do > not trigger existing signature DAT files, GTI sends a DNS request to a > central database server hosted by McAfee Labs." > > Basically, the way that this works is to generate a hash (or similar) > of an object and query that hash in the DNS -- information is returned > encoded in the address. > It is quite clear that McAfee could not (and would not) want to > publish a record saying that this is a wildcard -- if they did, they > would either mark all objects as safe, or as malicious. > > > Another example is: > > load-0-p-01.up-1852280.mem-251379712-24440832-0-p-50.swap-236691456-29794= 3040-0-p-44.3302068.1222092134.device.trans.manage.esoft.com > Fascinating, but device.trans.manage.esoft.com has no incentive to > publish a wildcard marker -- the whole purpose of this query appears > to get data back to manage.esoft.com -- having this get answered from > an intermediate cache would defeat this. > > The third example is: > p2.a22a43lt5rwfg.ihg5ki5i6q3cfn3n.191742.s1.v4.ipv6-exp.l.google.com > Lorenzo Colitti, Steinar, Erik Kline, Tiziana Refice have a good > writeup of the purpose of these here: "Evaluating IPv6 Adoption in the > Internet" - > https://static.googleusercontent.com/media/research.google.com/en//pubs/a= rchive/36240.pdf > Again, these queries are being made for a reason -- it isn't that the > senders figured "I know, let's make a DNS query for fun!!!" - they > wanted to query for some data, or send some data -- like the abstract > says: "=E2=80=9Csignaling=E2=80=9D via DNS queries." > > In all of the above, publishing a "this is a wildcard" completely > breaks the purpose of the queries, and so there is no incentive for > these entities to publish such a record... > > > > >> > >> 2) cache miss > >> All of temporary subdomain wildcards will encounter cache miss. > >> Query xxx.foo.com, then query yyy.foo.com, zzz.foo.com, ... > >> We can use SWILD to optimize it, only query xxx.foo.com for the first > >> time and get SWILD, avoid to send yyy/zzz.foo.com queries to > authoritative > >> server. > >> > >> > >> Can you characterize why sending these queries to the authoritative > server > >> is a problem? > > > > For the examples used in the paper justifying this, it's not a > problem, it's the purpose :-) > > > > > Ok, Similar to RFC8198 section 6 > > Benefit but not problem, directly return from cache, avoid send querie= s > to > > authoritative, and wait for response, reduce laterncy. > > > > > > Okay, but this isn't a reason to prefer this to existing, standardized > > technology. > > > >> 3) DDoS risk > >> The botnet ddos risk and defense is like NSEC aggressive wildcard, or > NSEC > >> unsigned. > >> For example, [0-9]+.qzone.qq.com is a popular SNS website in China, > like > >> facebook. If botnets send "popular website wildcards" to recursive, t= he > >> cache size of recursive will rise, recursive can not just simply remov= e > them > >> like some other random label attack. > >> We prefer recursive directly return the IP of subdomain wildcards, and > not > >> rise recursive cach, not send repeat query to authoritative. > >> > >> > >> Why do you prefer this? Just saying "we prefer ..." is not a reason > for > >> the IETF to standardize something. > > > > > > Sorry, my expression is fault. > > > > More details: > > 1) All of the attack botnets were customers of ISP, sent queries to ISP > > recursive with low rate, so all of the client's IP addresses were > > "legitimate", could not simply use ACL. > > 2) Normal users also visit [0-9]+.qzone.qq.com, all the the random > queries > > domain seems to "legitimate". > > =3D> The client ip addresses and the random subdomains are all in the > > whitelist, not in blacklist. > > 3) ISP didn't have any DNS firewall equipment ( very sad situation, but > it > > was true ) to take over the response of "*.qzone.qq.com". > > > > In this weaker scenario, it will be better if give recursive more > > information to directly answer queries from cache, and make recursive > not to > > send/cache many subdomains query/response. > > Of course, we can defense the attack with professional operation, solve > the > > problem very well. But there are also many more weaker recursive only r= un > > bind software, without any protection... > > > > > > Maybe they should upgrade. > > > > I will reconsider these problems of the proposal, make the improvement > > analysis on real-world caches before next step. > > > > > > Thanks! However, I would really encourage you to step back from your > > proposal and see if there's a way to accomplish what you want without > adding > > this resource record. I think you can get the same results you want > > without SWILD, and the result will be a lot better for the DNS as a > whole. > > > > > > _______________________________________________ > > 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 > --=20 =E8=87=B4=E7=A4=BC Best Regards =E6=BD=98=E8=93=9D=E5=85=B0 Pan Lanlan --f403045c4eeabfd667055752e1dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Warren,

Thanks for you= r work, :-)

I totally agree:=C2=A0 Not all Disposable Domains = are wildcards like xxx.github.io / xxx.blogspot.com / xxx.qzone.qq.com. So, wildcard solution can not cover = all example Disposable/Temporary Domains in the paper, as your analysis.

The question is how to avoid unnecess= ary caches and queries, give recursive more power to defense with wildcard = issue.

As Ted's advice, for a= better justification, I will do more analysis on recursive cache, which ki= nd of temporary domain is "particular", wildcard domains or "= ;domains has no incentive to publish a wildcard marker".

Warren Kumari <= warren@kumari.net>=E4=BA=8E2017=E5=B9=B48=E6=9C=8822=E6=97=A5=E5=91= =A8=E4=BA=8C =E4=B8=8A=E5=8D=882:45=E5=86=99=E9=81=93=EF=BC=9A
I was really trying to stay out of this thread.= ..


On Fri, Aug 18, 2017 at 1:05 PM, Ted Lemon <mellon@fugue.com> wrote:
> El 18 ag 2017, a les 11:33, Lanlan Pan <abbypan@gmail.com> va escriure:
>
> So, can you talk about how your proposal saves cost over using a heuri= stic?
> It can be used with cache aging heuristic.
> Heuristic read in aaa/bbb/ccc.foo.com, expire and move out;=C2=A0 then re= ad in
> xxx/yyy/zzz.foo.com,=C2=A0 expire and move out;=C2=A0 loop...
> =3D> Map aaa/bbb/ccc/xxx/yy/zzz.foo.com to *.foo.com when heuristic read, it<= br> > will reduce the load of move in/out.
>
>
> By "move out" you mean "remove," right?=C2=A0 =C2= =A0Move out implies that you are
> moving it somewhere.=C2=A0 =C2=A0You haven't actually answered my = question.=C2=A0 You say
> that SWILD will remove the load, but you don't give any evidence o= f this.

Yup.

Earlier in the thread, one of justifications for this work was "DNS Noise: Measuring the Pervasiveness ofDisposable Domains in Modern DNS
Traffic." (posted by Lanlan Pan).
In the abstract of the same is: "Disposable domains are likely
generated automatically, characterized by a =E2=80=9Cone-time use=E2=80=9D = pattern,
and appear to be used as a way of =E2=80=9Csignaling=E2=80=9D via DNS queri= es."

The document contains some examples of these "disposable domains"= , including:
0.0.0.0.1.0.0.4e.135jg5e1pd7s4735f= trqweufm5.avqs.mcafee.com

McAfee's site says: "GTI File Reputation looks for suspicious
programs, Portable Document Format (PDF) files, and Android
Application Package (.APK) files that are active on endpoints running
McAfee products, including Endpoint Security (ENS), VirusScan
Enterprise (VSE), and SaaS Endpoint Protection (formerly known as
Total Protection Service). If any suspicious files are found that do
not trigger existing signature DAT files, GTI sends a DNS request to a
central database server hosted by McAfee Labs."

Basically, the way that this works is to generate a hash (or similar)
of an object and query that hash in the DNS -- information is returned
encoded in the address.
It is quite clear that McAfee could not (and would not) want to
publish a record saying that this is a wildcard -- if they did, they
would either mark all objects as safe, or as malicious.


Another example is:
load-0-p-01.up-1852280.mem-25137971= 2-24440832-0-p-50.swap-236691456-297943040-0-p-44.3302068.1222092134.device= .trans.manage.esoft.com
Fascinating, but device.trans.manage.esoft.com has no incent= ive to
publish a wildcard marker -- the whole purpose of this query appears
to get data back to manage.esoft.com -- having this get answered from
an intermediate cache would defeat this.

The third example is:
p2.a22a43lt5rwfg.ihg5ki5i= 6q3cfn3n.191742.s1.v4.ipv6-exp.l.google.com
Lorenzo Colitti, Steinar, Erik Kline, Tiziana Refice have a good
writeup of the purpose of these here: "Evaluating IPv6 Adoption in the=
Internet" - https://static.googleusercontent.com/media/research.google.com/en//pu= bs/archive/36240.pdf
Again, these queries are being made for a reason -- it isn't that the senders figured "I know, let's make a DNS query for fun!!!" -= they
wanted to query for some data, or send some data -- like the abstract
says: "=E2=80=9Csignaling=E2=80=9D via DNS queries."

In all of the above, publishing a "this is a wildcard" completely=
breaks the purpose of the queries, and so there is no incentive for
these entities to publish such a record...



>>
>> 2) cache miss
>> All of temporary subdomain wildcards will encounter cache miss. >> Query xxx.foo.com,=C2=A0 then query yyy.foo.com, zzz.foo.com, ...
>> We can use SWILD to optimize it,=C2=A0 only query xxx.foo.com for the= first
>> time and get SWILD, avoid to send yyy/zzz.foo.com queries to authorit= ative
>> server.
>>
>>
>> Can you characterize why sending these queries to the authoritativ= e server
>> is a problem?
>

For the examples used in the paper justifying this, it's not a
problem, it's the purpose :-)

>
> Ok, Similar to RFC8198 section 6
> Benefit but not problem,=C2=A0 directly return from cache, avoid send = queries to
> authoritative, and wait for response, reduce laterncy.
>
>
> Okay, but this isn't a reason to prefer this to existing, standard= ized
> technology.
>
>> 3) DDoS risk
>> The botnet ddos risk and defense is like NSEC aggressive wildcard,= or NSEC
>> unsigned.
>> For example,=C2=A0 [0-9]+.qzone.qq.com is a popular SNS website in C= hina, like
>> facebook. If botnets send "popular website wildcards" to= recursive,=C2=A0 the
>> cache size of recursive will rise, recursive can not just simply r= emove them
>> like some other random label attack.
>> We prefer recursive directly return the IP of subdomain wildcards,= and not
>> rise recursive cach, not send repeat query to authoritative.
>>
>>
>> Why do you prefer this?=C2=A0 =C2=A0Just saying "we prefer ..= ." is not a reason for
>> the IETF to standardize something.
>
>
> Sorry, my expression is fault.
>
> More details:
> 1) All of the attack botnets were customers of ISP, sent queries to IS= P
> recursive with low rate, so all of the client's IP addresses were<= br> > "legitimate", could not simply use ACL.
> 2) Normal users also visit [0-9]+.qzone.qq.com, all the the random quer= ies
> domain seems to "legitimate".
> =3D> The client ip addresses and the random subdomains are all in t= he
> whitelist, not in blacklist.
> 3) ISP didn't have any DNS firewall equipment ( very sad situation= , but it
> was true ) to take over the response of "*.qzone.qq.com".
>
> In this weaker scenario,=C2=A0 it will be better if give recursive mor= e
> information to directly answer queries from cache, and make recursive = not to
> send/cache many subdomains query/response.
> Of course, we can defense the attack with professional operation, solv= e the
> problem very well. But there are also many more weaker recursive only = run
> bind software, without any protection...
>
>
> Maybe they should upgrade.
>
> I will reconsider these problems of the proposal, make the improvement=
> analysis on real-world caches before next step.
>
>
> Thanks!=C2=A0 =C2=A0However, I would really encourage you to step back= from your
> proposal and see if there's a way to accomplish what you want with= out adding
> this resource record.=C2=A0 =C2=A0I think you can get the same results= you want
> without SWILD, and the result will be a lot better for the DNS as a wh= ole.
>
>
> _______________________________________________
> 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.
=C2=A0 =C2=A0---maf
--
=E8=87=B4=E7=A4=BC=C2=A0 Best Regards=

=E6=BD=98=E8=93=9D=E5=85=B0=C2=A0 Pan Lanlan
--f403045c4eeabfd667055752e1dc-- From nobody Tue Aug 22 07:17:46 2017 Return-Path: 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 4EC581200F3 for ; Tue, 22 Aug 2017 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.999 X-Spam-Level: X-Spam-Status: No, score=-6.999 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, URIBL_BLOCKED=0.001] 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 oQKazIFR6f01 for ; Tue, 22 Aug 2017 07:17:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C41B31329BB for ; Tue, 22 Aug 2017 07:17:41 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:9019:83ff:fe58:6a74] (unknown [IPv6:2001:1488:fffe:6:9019:83ff:fe58:6a74]) by mail.nic.cz (Postfix) with ESMTPSA id DD85D6089B; Tue, 22 Aug 2017 16:17:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503411460; bh=n0tXIPcyJddZFojmh1fu5W/kztOh6ilFE6BURCRCrm8=; h=To:From:Date; b=P5phTLIChid/hMSw0ieFmNSM3BP7dHtvKtXEyKMv6pc4KrJL0lIEX7N0XUT+6ujyq wMW9dzLtWY4yCYYZUvNi7GqNvWj+Ph6urgPkPJuYG9s37G+/I/Jf6gEEPBk21C+CVS ymIhbNy8DzaA8875FWu47diywhHhB7Ccvna08tDk= To: John Levine , dnsop@ietf.org References: <20170820014850.1072.qmail@ary.lan> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <54f2e262-ed8c-67dd-21b0-83f50992e619@nic.cz> Date: Tue, 22 Aug 2017 16:17:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170820014850.1072.qmail@ary.lan> 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: Subject: Re: [DNSOP] fragile dnssec, was Fwd: New Version X-BeenThere: dnsop@ietf.org 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: Tue, 22 Aug 2017 14:17:44 -0000 On 20.8.2017 03:48, John Levine wrote: > In article <272dc071-c650-220c-3528-acb9467c706b@nic.cz> you write: >> Yes, someone might try to attack a domain using this. To lower >> probability of this kind of attack CZ.NIC is nagging the technical >> contact for one week before the DS gets installed into the CZ zone. >> >> For further details please see >> https://en.blog.nic.cz/2017/06/21/lets-make-dns-great-again/ >> >> We will see how it goes. > > That's certainly one of the approaches that Olafur suggested, and it > would definitely be easy to implement. > > Please let us know what you learn. Few people asked me privately about more details so I'm going to post our IEPG presentation here as well: http://iepg.org/2017-07-16-ietf99/Fully%20automatic%20DNSSEC%20-%20final.pdf Feel free to play with it, we very much welcome feedback! Please direct further questions to Jaromír Talíř . Have fun! -- Petr Špaček @ CZ.NIC From nobody Thu Aug 24 07:21:53 2017 Return-Path: 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 52E15132351 for ; Thu, 24 Aug 2017 07:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 r7olcKCn9GDn for ; Thu, 24 Aug 2017 07:21:49 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (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 10257132962 for ; Thu, 24 Aug 2017 07:21:49 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id 44A4E2805CB for ; Thu, 24 Aug 2017 16:21:47 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id 3FB0D2805FC; Thu, 24 Aug 2017 16:21:47 +0200 (CEST) Received: from relay01.prive.nic.fr (unknown [10.1.50.11]) by mx4.nic.fr (Postfix) with ESMTP id 38FDF2805CB for ; Thu, 24 Aug 2017 16:21:47 +0200 (CEST) Received: from b12.nic.fr (b12.users.prive.nic.fr [10.10.86.133]) by relay01.prive.nic.fr (Postfix) with ESMTP id 3585E6023DF3 for ; Thu, 24 Aug 2017 16:21:47 +0200 (CEST) Received: by b12.nic.fr (Postfix, from userid 1000) id 2D1BD406FD; Thu, 24 Aug 2017 16:21:47 +0200 (CEST) Date: Thu, 24 Aug 2017 16:21:47 +0200 From: Stephane Bortzmeyer To: dnsop@ietf.org Message-ID: <20170824142147.lshdlmjv62nojd32@nic.fr> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <149894524329.526.18431408698564464455@ietfa.amsl.com> X-Operating-System: Debian GNU/Linux 9.1 X-Kernel: Linux 4.9.0-3-amd64 x86_64 X-Charlie: Je suis Charlie Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: NeoMutt/20170113 (1.7.2) X-Bogosity: No, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2017.8.24.141515 Archived-At: Subject: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 14:21:51 -0000 On Sat, Jul 01, 2017 at 02:40:43PM -0700, internet-drafts@ietf.org wrote a message of 45 lines which said: > Title : DNS Terminology > Authors : Paul Hoffman > Andrew Sullivan > Kazunori Fujiwara > Filename : draft-ietf-dnsop-terminology-bis-06.txt One of the issues I would like to discuss for terminology-bis is the definition of QNAME. I filed this erratum against RFC 2308 : https://www.rfc-editor.org/errata_search.php?rfc=2308&eid=4983 Five months later, it has not been accepted or rejected. So, it is time to poke the WG: do you think we should mark the RFC 2308 as wrong, and keep only the definition of RFC 1034? From nobody Thu Aug 24 08:38:14 2017 Return-Path: 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 50F46132644 for ; Thu, 24 Aug 2017 08:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 rB4lCjA8tJUA for ; Thu, 24 Aug 2017 08:38:09 -0700 (PDT) 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 1A3CA13237B for ; Thu, 24 Aug 2017 08:38:09 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:e077:c603:af89:3d6e] (unknown [IPv6:2001:67c:1220:80c:e077:c603:af89:3d6e]) by mail.nic.cz (Postfix) with ESMTPSA id DC9D5617E5; Thu, 24 Aug 2017 17:38:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503589087; bh=UzPwGYPFVU/01Pq529+4Lx370FaNTnKGiidJ/ds1N70=; h=To:From:Date; b=Um8qb2LSETlC5O0eItyuhnUHOUeUsQRcXnn9SP/SB13htRGUc93NLm/vJcaZnIYMx lG2UzmRC1tdCF8Ma/xX5DOidxq33AF2PMZJz1rt0a5ARktzbJDWxkWT7wcEWfyvMWR 228CtNskJ4czEGB/Wb+OPfigOr/G2aoI24DL5rno= To: dnsop@ietf.org, Tom Pusateri References: <148944868965.20421.13262969145873649331@ietfa.amsl.com> <235049030.6432.1500569125325.JavaMail.zimbra@nic.cz> <20170720165043.g5e7jprg2hmoanf2@mx4.yitter.info> <697159393.6506.1500569982281.JavaMail.zimbra@nic.cz> <20170720170907.gksdgic47juhbn7e@mx4.yitter.info> <54eea882-7c45-67e8-b50d-8a0558ad8236@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: <688ce522-3571-dcfc-42a6-b8526ce0dfba@nic.cz> Date: Thu, 24 Aug 2017 17:38:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: 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: Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-session-signal-02.txt X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 15:38:12 -0000 Hello Ted and Tom, I'm going to reply to both of you at once. First of all, I'm not going to push for wire format change any longer. Your replies show that there is a lot of thoughts behind the document *but* these are not captured in the document itself nor dnsop mailing list. (Maybe I'm just incompetent when it comes to searching archives.) I believe that our disagreement partially comes from misunderstanding each other, partially from missing information, and of course there is some true disagreement, but that is a matter of taste :-) Here I propose explanatory version of Introduction chapter for your draft. Goal of the proposal is to document why SS deviates from rest of DNS protocol so we have something to reference when new proposal for OPCODE=666 comes up (and thus do not need to go though this again). The text is based on my understanding to Ted and Tom's comments and might be wrong, feel free to modify it as needed. ------------------ 1. Introduction | The use of transports for DNS other than UDP is being increasingly | specified, for example, DNS over TCP [RFC1035][RFC7766] and DNS over | TLS [RFC7858]. Such transports can offer persistent, long-lived | sessions and therefore when using them for transporting DNS messages | it is of benefit to have a mechanism that can establish parameters | associated with those sessions, such as timeouts. In such situations | it is also advantageous to support server initiated messages. | | The existing EDNS(0) Extension Mechanism for DNS [RFC6891] is | explicitly defined to only have "per-message" semantics. Whilst | EDNS(0) has been used to signal at least one session related | parameter (the EDNS(0) TCP Keepalive option [RFC7828]) the result is | less than optimal due to the restrictions imposed by the EDNS(0) | semantics and the lack of server-initiated signalling. Extending EDNS(0) with "per-session" semantics is not worth the effort for several reasons: Most importantly EDNS(0) design is based on assumption that format similar to ordinary RR would make it more likely that things would work. Past experience shown us that this assumption is incorrect and in reality it is causing nightmares with middleboxes being confused by EDNS(0). Secondly, re-using EDNS(0) for "per-session" operation would be confusing because current code handling per-message semantics would have to be extended to deal with session semantics. Thirdly, adding another EDNS0-style option is deemed to be more complex than using the new proposed format, it would consume more packet space, and the actual format of the packet would be less sensible, resulting in more complex decode/encode logic. To avoid problems related to EDNS(0) usage, this document defines a new extension mechanism for the original DNS protocol. The new extension is based on a new Session Signaling OPCODE used to carry persistent "per-session" operations, expressed using type-length-value (TLV) syntax. The new Opcode allows us to change the packet format for the better. | It should be noted that the message format for Session Signaling | operations (see Section 4.1) differs from the traditional DNS packet | format used for standard queries and responses. The standard twelve- | octet header is used, but the four count fields (QDCOUNT, ANCOUNT, | NSCOUNT, ARCOUNT) are set to zero and the corresponding sections are | not present. The actual data pertaining to Session Signaling | operations is appended to the end of the DNS message header. When | displayed using today's packet analyser tools that have not been | updated to recognize the DNS Session Signaling format, this will | result in the Session Signaling data being displayed as unknown | additional data after the end of the DNS message. In contrast with EDNS(0), this new extension mechanism has no compelling motivation to pack multiple operations into a single message for | efficiency reasons. Each Session Signaling operation is communicated | in its own separate DNS message, and the transport protocol can take | care of packing separate DNS messages into a single IP packet if | appropriate. For example, TCP can pack multiple small DNS messages | into a single TCP segment. The RCODE in each response message | indicates the success or failure of the operation in question. On top of this new extension mechanism, this document defines an initial set of TLVs used to manage session timeouts and termination. ------------------ End of Introduction ------------------ Can we get something explanatory like this into the document, please? Thank you! On 18.8.2017 19:39, Ted Lemon wrote: > El 18 ag 2017, a les 11:12, Petr Špaček > va escriure: >> My objections are in the end about engineering costs, which was nicely >> summarized by Paul Vixie in another thread (about SWILD, but applicable >> to session signaling as well): >> https://mailarchive.ietf.org/arch/msg/dnsop/xMvOuQqWCWZtql1gqD0UwH354b8 > > Paul's arguments aren't at all applicable here. He's talking about > having two different resource records that require detailed special > handling; adding a new resource record that accomplishes what is > accomplished by existing code in a different way produces a substantial > increase in complexity not in the transport part of the DNS protocol, > but in the semantics engine of your DNS cache. > >> For me the major portion of cost does not come from features (like >> session management etc.) but from the *framework* needed to build them. >> This cost increase IMHO stems from fact that the framework (SS aka DNS >> control plane as you named it) does not build on existing and widely >> available components. > > It's true, TLVs are quite innovative, and have never been used > elsewhere. ;-) > >> I believe that added complexity is one of serious technical parameters >> and I was objecting to it 4 months ago already: >> https://mailarchive.ietf.org/arch/msg/dnsop/XjbQlz5dPblzfGr0OBrr5afKBEg > > The problem is that you didn't say then, and you don't say now, why this > supposed complexity is an important technical consideration. And it's I'm confused. Do you really claim "complexity is not an important technical consideration" ? Is https://tools.ietf.org/html/rfc3439 applicable only to IP? (Feel free to interpret this as rhetorical question.) > hard for me to see what the issue is. Nobody has to support this; i> you support it, it's because you want the features. If you want the > features, the complexity isn't really in the wire format serialization > and deserialization—this are trivial. The complexity is in, for > example, implementing DNS Push through a DNS cache if you want to > support it in that context. I admit that this is complex, and I > suspect that there will be little enthusiasm for doing it. That's > okay—it's actually not required that any cache implement DNS push in > order for us to get the benefit of it. But this complexity has nothing > to do with the wire format. Of course, if you want features you have to code them, agreed. The thing is that this proposal pushes complexity to places which do not want any features at all. We need to consider existence of DNS software which cares only about DNS wire format and nothing else. Many of these tools do not actively participate in DNS query-response protocol, they just observe and analyze what is going on wire. Another category are test tools etc. Nevermind. It will be good enough if we (we as in dnsop) at least document why SS is deemend to be the right way to extend DNS. -- Petr Špaček @ CZ.NIC From nobody Thu Aug 24 08:47:09 2017 Return-Path: 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 ED8F71321C7 for ; Thu, 24 Aug 2017 08:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=C4hFaMN1; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=zqRsz7Cs 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 xUAW5P-4DbuL for ; Thu, 24 Aug 2017 08:47:06 -0700 (PDT) Received: from catinthebox.net (groups.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 39E56124E15 for ; Thu, 24 Aug 2017 08:47:03 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1205; t=1503589618; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VS0OFVISArvb38PNxuAV4roJ0SU=; b=C4hFaMN1lp9fAuOG+QRCxtPN8v8rcuoiFwS5PtC/b2mFE0VDl8I/vElZj6Wvm+ dS3pjQb8kL0rCtc4AP/mcIWohkaLeZqXlf3zT1lfUDblBULAZW4ykTWlQJ425cwu eISxcXPHs1GWKmmZj5cx53IGZ4/vV+3Hh7Y6UElHoqrjQ= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Thu, 24 Aug 2017 11:46:58 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3653465672.75665.580; Thu, 24 Aug 2017 11:46:56 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1205; t=1503589565; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=VCt5S7D xE7Y3p6lf/igccOOJgEjSYIQ10wlX2TU3RTg=; b=zqRsz7Csw5QXB5MGoCHnu4w UTksKrA5VCAHpAsOyEEx2mR+NH1C+9aPXZ1qBO6zDqI0xVMVVhBEfe8ibjI6H4SE nbA2yAoU9uX8HfDSbCrG1FjugkgpmixthK8b8G8Oz/zK+5Xe/PS5NnM48Z3RGr2B B9XHC6jqOKJFfTHtkhmw= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Thu, 24 Aug 2017 11:46:04 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 537445140.9.16468; Thu, 24 Aug 2017 11:46:04 -0400 Message-ID: <599EF4F2.6070509@isdg.net> Date: Thu, 24 Aug 2017 11:46:58 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: "dnsop@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 15:47:08 -0000 I have a question related to RFC2317 "Classless IN-ADDR.ARPA delegation." Earlier this year, I switched from a class C bank of 256 addresses to a reduced set of 32 ips (/27). To get PTR queries to work, RFC2317 was referred by my ISP to prepare the delegation. Having implemented RFC2317, I noticed with PTR lookups directly against my own DNS server, it returns the proper host names, no cnames. When the query is done against other DNS servers, it returns the CNAME which points to the expected host name(s). This I understand is the expected RFC2317 method setup by the ISP. Not expecting this in my DNS resolver code, I modified the resolver to take the CNAMEs into account and return the host names instead. Was this the correct thing to do, thus providing the same results regardless of the query location? Reading RFC2317, section 5.1 and section 5.3, it sounds what I did was ok.' I have various PTR lookup scripts that did not expect the CNAME in the PTR query as RFC2317 indicates may happen, thus possibly failing a PTR requirement, i.e. SMTP receiver connection, etc. Before I release my updates, I wonder if this was the right thing to do. Thanks -- HLS From nobody Thu Aug 24 08:48:35 2017 Return-Path: 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 4571A124E15 for ; Thu, 24 Aug 2017 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 dRcmxovU65ev for ; Thu, 24 Aug 2017 08:48:32 -0700 (PDT) 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 A3E2A13237B for ; Thu, 24 Aug 2017 08:48:32 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:e077:c603:af89:3d6e] (unknown [IPv6:2001:67c:1220:80c:e077:c603:af89:3d6e]) by mail.nic.cz (Postfix) with ESMTPSA id 46CEF60733 for ; Thu, 24 Aug 2017 17:48:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503589711; bh=LIdRke1VXh2plOcnEF2sF3Rjm+aJd5PT7KdQ0gt60nk=; h=To:From:Date; b=BetyTqtBQxIV8Hf7rZ8SCol3YAR/gVejAhZsUNJgtLS8Cpcl3qBXKY6uHwhMjYxFC ZDWHN/JUrwG/4SXayfY62drNrhF7ct0nCszSqVu12/ShO1cmh/M4zPzfvMfviw8cGy UxNtUV/qGSAkf7qXCe7n406FjfgqRORd9WGAPLfQ= To: dnsop@ietf.org References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Thu, 24 Aug 2017 17:48:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170824142147.lshdlmjv62nojd32@nic.fr> 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: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 15:48:34 -0000 On 24.8.2017 16:21, Stephane Bortzmeyer wrote: > On Sat, Jul 01, 2017 at 02:40:43PM -0700, > internet-drafts@ietf.org wrote > a message of 45 lines which said: > >> Title : DNS Terminology >> Authors : Paul Hoffman >> Andrew Sullivan >> Kazunori Fujiwara >> Filename : draft-ietf-dnsop-terminology-bis-06.txt > > One of the issues I would like to discuss for terminology-bis is the > definition of QNAME. I filed this erratum against RFC 2308 : > > https://www.rfc-editor.org/errata_search.php?rfc=2308&eid=4983 > > Five months later, it has not been accepted or rejected. So, it is > time to poke the WG: do you think we should mark the RFC 2308 as > wrong, and keep only the definition of RFC 1034? I vote for keeping RFC 1034 definition and declaring RFC 2308 wrong. -- Petr Špaček @ CZ.NIC From nobody Thu Aug 24 09:06:30 2017 Return-Path: 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 1DD431320BD for ; Thu, 24 Aug 2017 09:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 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] 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 x5tAQ_psWJgo for ; Thu, 24 Aug 2017 09:06:26 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 6163C1201F8 for ; Thu, 24 Aug 2017 09:06:26 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:c478:5fff:feb6:ca15] (unknown [IPv6:2001:1488:fffe:6:c478:5fff:feb6:ca15]) by mail.nic.cz (Postfix) with ESMTPSA id 8AB5F608A1 for ; Thu, 24 Aug 2017 18:06:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503590784; bh=sezo7eiPKchD16RSaEbjOvMNzFaISybYTWnfYFsmaAA=; h=To:From:Date; b=prX4D3zAZZ1p1/HeWs53nXctufkCDS5xepkdQeFqa9fvp36uhmFGt2HHSxao0lv73 ULWCI1IxhTKfu95F9x696Qib5eccyvAiw2BiWOJW5IIlKp+uAJVHDJYsVbXqDwekqH 7bOD7GbsNpH9ys4ucPVn8hT18sBLqjTsDn5q4mJA= To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> From: =?UTF-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= Message-ID: <3d0a3708-f5ed-151e-816f-c88662400d8b@nic.cz> Date: Thu, 24 Aug 2017 18:06:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <599EF4F2.6070509@isdg.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 16:06:28 -0000 Hello. On 08/24/2017 05:46 PM, Hector Santos wrote: > [...] Not expecting this in my DNS resolver code, I modified the > resolver to take the CNAMEs into account and return the host names > instead. Was this the correct thing to do, thus providing the same > results regardless of the query location? [...] I can't see any hint in RFC2317 that resolvers should/could change the data they obtain from upstream, even if just "expand CNAMEs" (and it's only BCP RFC anyway). In particular, if the particular zone is covered by DNSSEC, you may trigger validation errors by that. --Vladimir From nobody Thu Aug 24 10:07:27 2017 Return-Path: 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 CB2E413234B for ; Thu, 24 Aug 2017 10:07:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 WL6u59unX34U for ; Thu, 24 Aug 2017 10:07:23 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348A61321C9 for ; Thu, 24 Aug 2017 10:07:23 -0700 (PDT) Received: from [IPv6:2600:100e:b140:3a6d:deb4:f2b4:97d9:ea8b] (unknown [IPv6:2600:100e:b140:3a6d:deb4:f2b4:97d9:ea8b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 1722861FF3; Thu, 24 Aug 2017 17:07:20 +0000 (UTC) Date: Thu, 24 Aug 2017 17:07:18 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <599EF4F2.6070509@isdg.net> References: <599EF4F2.6070509@isdg.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org, Hector Santos , "dnsop@ietf.org" From: P Vix Message-ID: <151DA7A7-47A7-4353-8A0A-A3EAB9B3EA46@redbarn.org> Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 17:07:26 -0000 ------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is why rfc 2308 definition of qname is correct=2E On August 24, 2017 9:46:58 AM MDT, Hector Santos wrot= e: >I have a question related to RFC2317 "Classless IN-ADDR=2EARPA >delegation=2E" > >Earlier this year, I switched from a class C bank of 256 addresses to=20 >a reduced set of 32 ips (/27)=2E To get PTR queries to work, RFC2317=20 >was referred by my ISP to prepare the delegation=2E > >Having implemented RFC2317, I noticed with PTR lookups directly=20 >against my own DNS server, it returns the proper host names, no=20 >cnames=2E When the query is done against other DNS servers, it returns= =20 >the CNAME which points to the expected host name(s)=2E This I=20 >understand is the expected RFC2317 method setup by the ISP=2E > >Not expecting this in my DNS resolver code, I modified the resolver to=20 >take the CNAMEs into account and return the host names instead=2E Was=20 >this the correct thing to do, thus providing the same results=20 >regardless of the query location? > >Reading RFC2317, section 5=2E1 and section 5=2E3, it sounds what I did wa= s=20 >ok=2E' > >I have various PTR lookup scripts that did not expect the CNAME in the=20 >PTR query as RFC2317 indicates may happen, thus possibly failing a PTR=20 >requirement, i=2Ee=2E SMTP receiver connection, etc=2E > >Before I release my updates, I wonder if this was the right thing to >do=2E > >Thanks > >--=20 >HLS > > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is why rfc 2308 definition of qname is correc= t=2E

On August 24, 2017 9:46:58 AM MDT, H= ector Santos <hsantos@isdg=2Enet> wrote:
I have a question related to RFC2317 "Classless=
 IN-ADDR=2EARPA delegation=2E"

Earlier this year, I switche=
d from a class C bank of 256 addresses to 
a reduced  set of 32 ips (/=
27)=2E  To get PTR queries to work, RFC2317 
was referred by my ISP to=
 prepare the delegation=2E

Having implemented RFC2317, I noticed=
 with PTR lookups directly 
against my own DNS server, it returns the =
proper host names, no 
cnames=2E   When the query is done against othe=
r DNS servers, it returns 
the CNAME which points to the expected host=
 name(s)=2E  This I 
understand is the expected RFC2317 method setup b=
y the ISP=2E

Not expecting this in my DNS resolver code, I modif=
ied the resolver to 
take the CNAMEs into account and return the host =
names instead=2E  Was 
this the correct thing to do, thus providing th=
e same results 
regardless of the query location?

Reading R=
FC2317, section 5=2E1 and section 5=2E3, it sounds what I did was 
ok=
=2E'

I have various PTR lookup scripts that did not expect the C=
NAME in the 
PTR query as RFC2317 indicates may happen, thus possibly =
failing a PTR 
requirement, i=2Ee=2E SMTP receiver connection, etc=2E<=
br />
Before I release my updates, I wonder if this was the right thin=
g to do=2E

Thanks

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------F5MZ9ICR9XWF3QWMTKTQRMIEDF9BLW-- From nobody Thu Aug 24 10:31:12 2017 Return-Path: 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 E227E132418 for ; Thu, 24 Aug 2017 10:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 XCePwViaripd for ; Thu, 24 Aug 2017 10:31:08 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 5D30413202D for ; Thu, 24 Aug 2017 10:31:08 -0700 (PDT) Received: from hal9000.thn.corp.google.com ([IPv6:2620:0:102a:11:887e:3068:91e8:1e9d]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v7OHVCe4003292 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 24 Aug 2017 12:31:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1503595874; bh=+P4KWC31EHFnrghykaYwn6lXOyPqXbpa1RoUxxzc5ro=; h=Subject:To:References:From:Date:In-Reply-To:From; b=osB8ZqYpm0YCN/O9rVa75xgpJkHTM+ngg4AFo3IU1Vi2XUHie7evAsfgmzgd5Ymnh BnTaJMTB10sCMVNtNUW2QI7EHqn33jqsTaqAfKPneXu03qYUt6FNHX7y9pKiVR17cO sMJWKLJthySdxlL4etPwXa8IEhhKbje+4NE5rM1g= To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> From: Grant Taylor Message-ID: <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net> Date: Thu, 24 Aug 2017 11:31:06 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <599EF4F2.6070509@isdg.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020302080308020207050309" Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 17:31:11 -0000 This is a cryptographically signed message in MIME format. --------------ms020302080308020207050309 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/24/2017 09:46 AM, Hector Santos wrote: > Not expecting this in my DNS resolver code, I modified the resolver to = > take the CNAMEs into account and return the host names instead. Was=20 > this the correct thing to do, thus providing the same results regardles= s=20 > of the query location? This is one of the gotchas for classless in-addr.arpa delegation. > Before I release my updates, I wonder if this was the right thing to do= =2E I prefer to use a different method to do classless in-addr.arpa delegatio= n. Specifically, I ask ISPs to put an NS record for the IP(s) in question=20 pointing to my own DNS server. Then I configure zone(s) that match the=20 full in-addr.arpa name with the PTR in the zone apex. You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP=20 (a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.)=20 with individual PTR records, much like the ISP normally does. If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd=20 recommend that you have NS records for the other 224 IPs that point to=20 your ISP's name server that is authoritative for the zone. In effect, you are actually delegating the IPs an additional level. I got bit by SORBS not understanding classless in-addr.arpa delegation=20 (since been fixed) more than a decade ago and have never had any similar = problems. --=20 Grant. . . . unix || die --------------ms020302080308020207050309 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CgIwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVLMIIEM6ADAgECAhBWFNl+TpTaXY4YBuKunuW7MA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYxMTIyMDAwMDAwWhcNMTcxMTIyMjM1OTU5WjArMSkwJwYJKoZIhvcNAQkB FhpndGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALQOeB9QxYwFjGM8smbnZihDiEsKsBBX0H1M9WC/HjeHf+AO26QH4mdiN+XpFMVy yVyZqEbgheL49o7qcRPf2PPVck+E67zn8b/kef1LbWde++QDMg56zZvAU4CbF7/v98WnHpzY LP+3AWK0z/7IfBwujQE8xW6E0vTZznq8GGP5z6pGSap4gKh/a8erEVcoYdK2IuWYa4sNxOvo FICiOoCMJhvU1F92yuuXCRZcZwFyav7P3+M36jHdViH2fuZuOhZBWb419mmhtUWS8r6aVdfk Vq+Pz3NdvLdo6AsUZpf7dZr/LeLW6gr2VoDQ5+j1JtI24wzl42RAVTsANoH/OusCAwEAAaOC AfgwggH0MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSxNT5f 50Ax2YRcuiCuDfxHUlkuGjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUE GTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/ MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9k by5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NP TU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAG CCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZ3RheWxv ckB0bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBACCtfMI0hVAiQKvOx9Br ffT4YUPJRlXcs6yoDHfg0bnVw/ucEJ1neOi/aIUdA6EypUMNrshmgJTNaj6CsRH8c0yXOeGd nO5tNrPMYAhVvCQo/gpliYhIs2RAKXgFNtkUufwTqOQOLZva4LLVxSuSYncAgxdaj6TcORsd 9NEKPUC03F8yW0hk2M6WqvOpyIG4CWAP8Tmrxs0OKZuQeAoI3bs103EuMiMBTFIeEm8Obvx+ svg+UhK0CaMjEH92AwZ4blouFxqGTlgE/wclDCe+tZr/FvBP4Vflm/o82IkvyiNff8Qwz/BS z1hTRwSc7JexXVTms1cS7rMBRFwcvU2Le6kxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBWFNl+TpTaXY4YBuKunuW7 MA0GCWCGSAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjQxNzMxMDZaMC8GCSqGSIb3DQEJBDEiBCAiLfnD9beQ2o6Gu65HxH4o e8/TA9bjMkwSTKMz+5MW9DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzCB wwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzANBgkqhkiG9w0BAQEFAASCAQCl yEMlmXNly/nI/enF11QtnBX1rUMo2jnEW8L1SHrvGV3BVWmxFr1CRZDXBF9Ax3X4HTBR9Bi2 6SP+hoOWhK2wyi2CVhTipCFt85/km7iaC2eju+GwOozDHr9+zrKaXwyLZ5ffQSX2nHtdzfX0 jHZodN+3Erny3+T5UsaIVWv/cVAI4Y1OcFCuO/fYNPX/pxu12U1jPhhEVKqgJpLjEX0H5eJ/ TnCPXew2W3B7wJ2+fxtsNLWp/QYEXJfIWv6gnOlq8y3HI8El+Tm955UktFcTemsNuSGdBD9e yI6fnkkRV3TtFyWQOJ8IPbGiDYdfjxtXBBJqlZar7uQ863oU2976AAAAAAAA --------------ms020302080308020207050309-- From nobody Thu Aug 24 15:27:34 2017 Return-Path: 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 A17B213271F for ; Thu, 24 Aug 2017 15:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 gIHSR_z1Jzg0 for ; Thu, 24 Aug 2017 15:27:31 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 374A41326FE for ; Thu, 24 Aug 2017 15:27:31 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 5191434A499; Thu, 24 Aug 2017 22:27:29 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3E8B8160052; Thu, 24 Aug 2017 22:27:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 289B216007F; Thu, 24 Aug 2017 22:27:29 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6GcW0MtNb8XC; Thu, 24 Aug 2017 22:27:29 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id CDDDE160052; Thu, 24 Aug 2017 22:27:28 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id C786E831AA5D; Fri, 25 Aug 2017 08:27:34 +1000 (AEST) To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: dnsop@ietf.org From: Mark Andrews References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> In-reply-to: Your message of "Thu, 24 Aug 2017 17:48:31 +0200." Date: Fri, 25 Aug 2017 08:27:34 +1000 Message-Id: <20170824222734.C786E831AA5D@rock.dv.isc.org> Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 22:27:33 -0000 RFC 2308 is consistent with RFC 1034. Go read *all* of RFC 1034. QNAME is used to refer to *both* the original *and* updated value after following a CNAME. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Thu Aug 24 15:40:28 2017 Return-Path: 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 2A9EA132710 for ; Thu, 24 Aug 2017 15:40:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Hb9AX4bTcj3d for ; Thu, 24 Aug 2017 15:40:25 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B209313219C for ; Thu, 24 Aug 2017 15:40:25 -0700 (PDT) Received: from [IPv6:2600:100f:b02b:7c6e:704:24f7:e921:11a2] (unknown [IPv6:2600:100f:b02b:7c6e:704:24f7:e921:11a2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id A037B61FF3; Thu, 24 Aug 2017 22:40:22 +0000 (UTC) Date: Thu, 24 Aug 2017 22:40:12 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <20170824222734.C786E831AA5D@rock.dv.isc.org> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----ZAKYQXRVUV6FHOEI3669ATCF9YL6ZX" Content-Transfer-Encoding: 7bit To: dnsop@ietf.org, Mark Andrews , =?UTF-8?Q?Petr_=C5=A0pa=C4=8Dek?= From: P Vix Message-ID: <47C8FA15-74BD-4C64-A962-226841BBC29A@redbarn.org> Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Thu, 24 Aug 2017 22:40:27 -0000 ------ZAKYQXRVUV6FHOEI3669ATCF9YL6ZX Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We might want to invent a new term here like effective qname, but basically= I agree with Mark=2E 2308 was written after bind itself learned the distin= ction=2E On August 24, 2017 3:27:34 PM PDT, Mark Andrews wrote: > >RFC 2308 is consistent with RFC 1034=2E > >Go read *all* of RFC 1034=2E QNAME is used to refer to *both* the >original >*and* updated value after following a CNAME=2E > >Mark >--=20 >Mark Andrews, ISC >1 Seymour St=2E, Dundas Valley, NSW 2117, Australia >PHONE: +61 2 9871 4742 INTERNET: marka@isc=2Eorg > >_______________________________________________ >DNSOP mailing list >DNSOP@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/dnsop --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------ZAKYQXRVUV6FHOEI3669ATCF9YL6ZX Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable We might want to invent a new term here like effec= tive qname, but basically I agree with Mark=2E 2308 was written after bind = itself learned the distinction=2E

On Augu= st 24, 2017 3:27:34 PM PDT, Mark Andrews <marka@isc=2Eorg> wrote: 

RFC 2308 is consistent with RFC 1034=2E
<=
br />Go read *all* of RFC 1034=2E  QNAME is used to refer to *both* the ori=
ginal
*and* updated value after following a CNAME=2E

Mark

--
Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------ZAKYQXRVUV6FHOEI3669ATCF9YL6ZX-- From nobody Thu Aug 24 17:00:23 2017 Return-Path: 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 73AA813265E for ; Thu, 24 Aug 2017 17:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 OE4TVT2fwO6u for ; Thu, 24 Aug 2017 17:00:19 -0700 (PDT) Received: from odbmap07.extra.chrysler.com (odbmap07.out.extra.chrysler.com [129.9.107.37]) (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 4C4B71323B9 for ; Thu, 24 Aug 2017 17:00:19 -0700 (PDT) Received: from shbmap09.shdc.chrysler.com (Unknown_Domain [151.171.73.109]) by (Symantec Messaging Gateway) with SMTP id AB.FC.09157.8886F995; Thu, 24 Aug 2017 20:00:11 -0400 (EDT) X-AuditID: 81096b23-a9bff700000023c5-0d-599f6888f661 Received: from mxph1chrw.fgremc.it (Unknown_Domain [151.171.20.45]) by (Symantec Messaging Gateway) with SMTP id B5.FB.04970.CB66F995; Thu, 24 Aug 2017 19:52:28 -0400 (EDT) Received: from mxph4chrw.fgremc.it (151.171.20.48) by mxph1chrw.fgremc.it (151.171.20.45) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 24 Aug 2017 20:00:14 -0400 Received: from mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701]) by mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1236.000; Thu, 24 Aug 2017 20:00:13 -0400 From: "Darcy Kevin (FCA)" To: "dnsop@ietf.org" Thread-Topic: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt Thread-Index: AQHTHORnHuETSd4O0EiRIffADErT/qKT6iSAgAAsejiAAAX28A== Date: Fri, 25 Aug 2017 00:00:13 +0000 Message-ID: <30735661ffd84430b8d9ab8ff2be0f06@mxph4chrw.fgremc.it> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> In-Reply-To: <20170824222734.C786E831AA5D@rock.dv.isc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [151.171.20.216] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyfbVnrm53xvxIg1nLJSzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujIsvHzIV9AtWfLj2jaWB8TlvFyMnh4SAicSNzr2MXYxcHEIC 2xkljv1ezwKT2HziDDuILSSwnlGi+5U8RNE6Rollb76zQjg7GSXmHrgPVsUG1LHwyl1mEFtE QFXiwr/vTCC2sECKxL6fG9kh4qkSkw7NYYGwnSS6/p1hA7FZgOpPnnkCVs8LFF/7fwkzxOaz jBLzpguC2JwCVhK7JuwD62UUEJP4fmoNWD2zgLjErSfzmSCuFpBYsuc8M4QtKvHy8T9WCNtA YuvSfVCfKUm82zMbqldP4tmpWSwQtrbEsoWvmSFuEJQ4OfMJC8iTEgK32CVWL1/JPIFRchaS fbOQ9M9C0j8LSf8CRpZVjNL5KUm5iQUG5nqpFSVFiXrJGUWVxTmpRXrJ+bmbGIFR2MiZrbyD ccpcy0OMAhyMSjy8hanzI4VYE8uKK3MPMUpwMCuJ8KaaAoV4UxIrq1KL8uOLSnNSiw8xSnOw KInzdpfNjRQSSE8sSc1OTS1ILYLJMnFwSjUwziwL/if9RMTs/8TwXKFf3x5ovG3sWvxDU9Fh 1SXNggkSPJvPm17MedmW2LYpq/n5uqb5YVWB53/H6v/6WOTaGvK2myMvrkNstcjimI+ZW6Rd nXdNP/Mv6tNtzv/LkjqlTeMOLeC8vFu/NN+MawlTxp5GN+kPMgHf5a4pzZ6zmWtqcK3p3qSZ SizFGYmGWsxFxYkAMPwkob4CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUyfbWIru6etPmRBi8m21jcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGRdfPmQq6Bes+HDtG0sD43PeLkZODgkBE4nNJ86wg9hCAusZ JbpfyXcxcgHZ6xgllr35zgrh7GSUmHvgPlgVG1DHwit3mUFsEQFViQv/vjOB2MICKRL7fm5k h4inSkw6NIcFwnaS6Pp3hg3EZgGqP3nmCVg9L1B87f8lzBCbzzJKzJsuCGJzClhJ7JqwD6yX UUBM4vupNWD1zALiEreezGeCuFpAYsme88wQtqjEy8f/WCFsA4mtSyF6JQSUJN7tmQ3Vqyfx 7NQsFghbW2LZwtfMEDcISpyc+YRlAqPYLCQrZiFpmYWkZRaSlgWMLKsYpYozknITCwws9Yoz UpL1kjOKKotzUov0kvNzNzGC48YzZwfj/4WWhxgFOBiVeHh/J82PFGJNLCuuzD3EKMnBpCTK uzwaKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEN9UUKMebklhZlVqUD5OS5mBREudVKXAIFBJI TyxJzU5NLUgtgsnKcHAoSfCuCwRqFCxKTU+tSMvMKUFIM3FwggznARouHwcyvLggMbc4Mx0i f4pRUkqcdybIRQIgiYzSPLjeV4ziQC8I8x4BeYEHmALhul4BDWQCGjjpxByQgSWJCCmpBkaV 2CzFd7qM75O+c0goRe7ZOZH9lpfUK+W6Fd0Pj9dM23B/6tdX/a+/V1Y8zHPZtjJI7iDnG46T PHf+BeWlWit/vbZg/sf7RrcMTi96s23PieBA9vX/P3i1NvasulOvwPuoQKvW/G725s0Nu9h2 uDQ5+rx1cTgWpcQh5ZV19F3rpJ08MeqRsw4rsRRnJBpqMRcVJwIABLz+xj4DAAA= Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Fri, 25 Aug 2017 00:00:21 -0000 Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change QN= AME to the canonical name in the CNAME RR, and go back to step 1" is just t= reating the string "QNAME" as a variable in a loop. One will note that the = analogous portion of the *resolver* algorithm (5.3.3) says "change the SNAM= E to the canonical name in the CNAME RR and go to step 1." So "QNAME" subst= itutes for a variable name in one version of the algorithm, and "SNAME" sub= stitutes in the other version. There's nothing "magical" about the referenc= e to "QNAME", therefore, and one shouldn't assume this was an attempt to (r= e)define protocol terminology, _per_se_. RFC 2308, on the other hand, defines "QNAME" as encompassing both the "pure= " and the CNAME-chain sense, in its "Terminology" section, and thus broaden= s the scope of the term in ways that IMO can lead to ambiguity, if read as = applying beyond that particular RFC. The challenge, however, with saying, that "QNAME" can puristically *only* r= efer to what was originally requested in the query packet, is that we need = to then come up with another term to describe the end of the CNAME-chain, i= f any, which has been followed. One suggestion was "effective QNAME", but I= 'd prefer to leave "QNAME" out of the term completely, to avoid confusion. = "Terminal name" or "terminating name", perhaps? "End name"? "Resultant name= "? - Kevin -----Original Message----- From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Mark Andrews Sent: Thursday, August 24, 2017 6:28 PM To: Petr =A9pa=E8ek Cc: dnsop@ietf.org Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop= -terminology-bis-06.txt RFC 2308 is consistent with RFC 1034. Go read *all* of RFC 1034. QNAME is used to refer to *both* the original *and* updated value after following a CNAME. Mark --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop From nobody Thu Aug 24 19:46:50 2017 Return-Path: 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 28982132A08 for ; Thu, 24 Aug 2017 19:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ic5Dg1NYurlP for ; Thu, 24 Aug 2017 19:46:46 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58F311329F7 for ; Thu, 24 Aug 2017 19:46:46 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id s199so3905493vke.1 for ; Thu, 24 Aug 2017 19:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hvcqg8LU+WudQGrPBaeJ/42nlkfmZ8f/LjdaCEqkvEY=; b=IgoeHOgjnyoOvoAjpVxgd/HDkB2xuYj6Jj4QcSpOgtmK2njmoJl1WKdnEMGOwSVwsI 1dndn1VDFFOmaJ2FV6uw81zVZhd832DA9A6psXDFeKualqEzFvWKzfEfgZRfHgQ/5Sna s3fDEpyNkk39OCm3bwlFCfJw+qli38qoUbh8QlAjTIn9JVSvf76oXNTUCI5lyVCcMeEp sVjDP7R8gh0kJ8miwts8GMbCv/HCSQb+tqXv2ay0qhmI8biJkKaFw4bjP3BYvsAJp1TU YVtGa+TVxKufXXt3P8qO4aWWyI6Zm2lrPyqS4FZHVHX7drz+QKf6WTlEY6RamjMxs04A l5NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hvcqg8LU+WudQGrPBaeJ/42nlkfmZ8f/LjdaCEqkvEY=; b=AfkcquCnRkdY81LsyJ1x6v2l4BRyckBQvRKsZTDV47Jc1mybbh5By4wYgwYe89GR5r 5fZyd3kXtoDvScA9ikBQYLq7Zlpxbo5oVgaDW0iwrhSFevsWfdgF4a0FXGHnbZHkby/z Wbga0MpmBw6wT+ks719DOR+KjQHFryWROyjfTCGQQPJlOYCZNRQXb7GUbViOhBWrSdMa ZAEAQO4pfHDWZcNb36Yktl8LNGzBSBGGCy7VwVWx39y383/yI0L3thsgnyZfinw+l/7M jx7+IEWDj4fBLGNVx4SwkRFdK64KcWYTfIb7Qzd4n3Zs/VFfu15hRjj0Qo+qvaTqVb9Q t0Fg== X-Gm-Message-State: AHYfb5jp8hvbZYGLoOpXnOuFopTap5xNBkgkrrIVrL/o/S54JqLWQflZ 6gUdDK/pxJI8g0rhoQPij/omu+4QDA== X-Received: by 10.31.174.149 with SMTP id x143mr4571448vke.175.1503629205380; Thu, 24 Aug 2017 19:46:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.9 with HTTP; Thu, 24 Aug 2017 19:46:44 -0700 (PDT) In-Reply-To: <30735661ffd84430b8d9ab8ff2be0f06@mxph4chrw.fgremc.it> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <30735661ffd84430b8d9ab8ff2be0f06@mxph4chrw.fgremc.it> From: Shumon Huque Date: Thu, 24 Aug 2017 22:46:44 -0400 Message-ID: To: "Darcy Kevin (FCA)" Cc: "dnsop@ietf.org" Content-Type: multipart/alternative; boundary="001a11438f9aa9251c05578af428" Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Fri, 25 Aug 2017 02:46:48 -0000 --001a11438f9aa9251c05578af428 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) wrote: > Honestly, I think the part of RFC 1034 (Section 4.3.2) that says "change > QNAME to the canonical name in the CNAME RR, and go back to step 1" is just > treating the string "QNAME" as a variable in a loop. One will note that the > analogous portion of the *resolver* algorithm (5.3.3) says "change the > SNAME to the canonical name in the CNAME RR and go to step 1." So "QNAME" > substitutes for a variable name in one version of the algorithm, and > "SNAME" substitutes in the other version. There's nothing "magical" about > the reference to "QNAME", therefore, and one shouldn't assume this was an > attempt to (re)define protocol terminology, _per_se_. > Yes, I agree with your characterization. > RFC 2308, on the other hand, defines "QNAME" as encompassing both the > "pure" and the CNAME-chain sense, in its "Terminology" section, and thus > broadens the scope of the term in ways that IMO can lead to ambiguity, if > read as applying beyond that particular RFC. > Yes. > The challenge, however, with saying, that "QNAME" can puristically *only* > refer to what was originally requested in the query packet, is that we need > to then come up with another term to describe the end of the CNAME-chain, > if any, which has been followed. One suggestion was "effective QNAME", but > I'd prefer to leave "QNAME" out of the term completely, to avoid confusion. > "Terminal name" or "terminating name", perhaps? "End name"? "Resultant > name"? > A while back I had suggested "Resolved qname" or "Canonicalized qname" .. Shumon. --001a11438f9aa9251c05578af428 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 24, 2017 at 8:00 PM, Darcy Kevin (FCA) <kevin.darcy@fcagrou= p.com> wrote:
Honestly, I t= hink the part of RFC 1034 (Section 4.3.2) that says "change QNAME to t= he canonical name in the CNAME RR, and go back to step 1" is just trea= ting the string "QNAME" as a variable in a loop. One will note th= at the analogous portion of the *resolver* algorithm (5.3.3) says "cha= nge the SNAME to the canonical name in the CNAME RR and go to step 1."= So "QNAME" substitutes for a variable name in one version of the= algorithm, and "SNAME" substitutes in the other version. There&#= 39;s nothing "magical" about the reference to "QNAME", = therefore, and one shouldn't assume this was an attempt to (re)define p= rotocol terminology, _per_se_.

Yes, I a= gree with your characterization.
=C2=A0
RFC 2308, on the other hand, defines "QNAME" as encompassing both= the "pure" and the CNAME-chain sense, in its "Terminology&q= uot; section, and thus broadens the scope of the term in ways that IMO can = lead to ambiguity, if read as applying beyond that particular RFC.

Yes.
=C2=A0
The challenge, however, with saying, that "QNAME" can puristicall= y *only* refer to what was originally requested in the query packet, is tha= t we need to then come up with another term to describe the end of the CNAM= E-chain, if any, which has been followed. One suggestion was "effectiv= e QNAME", but I'd prefer to leave "QNAME" out of the ter= m completely, to avoid confusion. "Terminal name" or "termin= ating name", perhaps? "End name"? "Resultant name"= ?

A while back I had suggested "Re= solved qname" or "Canonicalized qname" ..

Shumon.

--001a11438f9aa9251c05578af428-- From nobody Sat Aug 26 11:23:13 2017 Return-Path: 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 9DD581321F1 for ; Sat, 26 Aug 2017 11:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=hDRaPj6B; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=cOJy9Jyh 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 ZulDeN5WCO4R for ; Sat, 26 Aug 2017 11:23:08 -0700 (PDT) Received: from listserv.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id E73FB1329B8 for ; Sat, 26 Aug 2017 11:23:06 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=1443; t=1503771782; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=VCLaJywTm2ROx2mWZJG2H7Q4AzA=; b=hDRaPj6BHCBriEWLZdO0Ke4IV/dvZpa2iAYK95mUWf4N5qOYEZHZiGfpAbAY0Q WbEBJC3icL/ZivGZ3dWRX2AMNITLmFQ4Sfrb2SH+yxCqMosxKSSHJe7nqcVfro8o QH6MVG9hnq079/rE3krKGwRxvDg4PBPmHSslLVjmGCSP0= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:23:02 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3835628071.75665.1700; Sat, 26 Aug 2017 14:23:01 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=1443; t=1503771726; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=KBc/CPK HyazLvzsKTof+c6M8qpNr+rSC0Igjs41UjZU=; b=cOJy9Jyh0HPVV+IIENwZE7M QCZCKhCXeuwY/M2lvSf8jGcEGJtw7ao1TYqGkjHCmUXWtGYVrBFVziAYwQ/r7ZYu nuGzwaquCzYVuYnvO5ny3Oi508DkjU89xfzYA78s2HlVctwaThCWTiVRw3zhGnqa xs89lxxun+aX2UcxZ6Kg= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:22:06 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 719606296.9.22788; Sat, 26 Aug 2017 14:22:05 -0400 Message-ID: <59A1BC8A.3050204@isdg.net> Date: Sat, 26 Aug 2017 14:23:06 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net> In-Reply-To: <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Sat, 26 Aug 2017 18:23:11 -0000 On 8/24/2017 1:31 PM, Grant Taylor wrote: >> Before I release my updates, I wonder if this was the right thing to >> do. > > I prefer to use a different method to do classless in-addr.arpa > delegation. > > Specifically, I ask ISPs to put an NS record for the IP(s) in question > pointing to my own DNS server. Then I configure zone(s) that match > the full in-addr.arpa name with the PTR in the zone apex. > > You can have a separate zone (d.c.b.a.in-addr.arpa.) for each IP > (a.b.c.d) -or- you can have a single parent zone (c.b.a.in-addr.arpa.) > with individual PTR records, much like the ISP normally does. > > If you do the second method (parent c.b.a.in-addr.arpa. zone) I'd > recommend that you have NS records for the other 224 IPs that point to > your ISP's name server that is authoritative for the zone. > > In effect, you are actually delegating the IPs an additional level. This was done, at least the first part of providing the ISP the two NS servers required. They used RFC2317 to setup the cname delegation. On my servers, I had done what you suggestion with the second method using a parent c.b.a.in-addr.arpa zone. It all seems to work, except for the unexpected cname+ptr records with non-authoritive results. Still studying the impact. I was trying to prevent some consistency in the results in the resolver. In the same way, that its done for A->CNAME->A results. Thanks -- HLS From nobody Sat Aug 26 11:23:21 2017 Return-Path: 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 A8356132BD4 for ; Sat, 26 Aug 2017 11:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=Cc+IJKC3; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=fy6cNdM7 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 xcjW_nDQ-hU7 for ; Sat, 26 Aug 2017 11:23:18 -0700 (PDT) Received: from listserv.winserver.com (winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B2132BD7 for ; Sat, 26 Aug 2017 11:23:16 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=2286; t=1503771787; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=vTXhOGdRwNpZST6L8Q+jzEWE2Pk=; b=Cc+IJKC3xTpqTkjdaRgM7SgBfTgDwUsHMPjZaYc7F4YEUAqzo/U4DNnCkd3TJF 47wYW4nTN9S154S2UX0U60i8OtjitMndKBmN1ATIW/sSlzOL2tg2NoBtN2ztTHf2 fkAp4UsH1B1Fmz+Rob9gJNTwfHuoc03ZiC+VuBpuvLoXE= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:23:07 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 3835633000.75665.5044; Sat, 26 Aug 2017 14:23:06 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2286; t=1503771731; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=2qtN/LL jJR//YLd6luMJRCqdKoCuWpOl6AEd56zKhLY=; b=fy6cNdM7M4FTaQp0Tt4tQAD rQvqFW9ALhKHQUM3G55YtfWBogQvnSEGMFc/OREW+x5F0H2JdJN9xyfqoDr4hrTt 9IdzQGcDj7yt7AKMssAs3puKFQBTMb+7V45LAEJ13mHXPWVGnC7lSA+EFG6ehSJZ ULTL8/N0gUR5fhjAa7Vc= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Sat, 26 Aug 2017 14:22:11 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 719611328.9.22800; Sat, 26 Aug 2017 14:22:10 -0400 Message-ID: <59A1BC8F.4040006@isdg.net> Date: Sat, 26 Aug 2017 14:23:11 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> <3d0a3708-f5ed-151e-816f-c88662400d8b@nic.cz> In-Reply-To: <3d0a3708-f5ed-151e-816f-c88662400d8b@nic.cz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Sat, 26 Aug 2017 18:23:20 -0000 On 8/24/2017 12:06 PM, Vladimír Čunát wrote: > Hello. > > On 08/24/2017 05:46 PM, Hector Santos wrote: >> [...] Not expecting this in my DNS resolver code, I modified the >> resolver to take the CNAMEs into account and return the host names >> instead. Was this the correct thing to do, thus providing the same >> results regardless of the query location? [...] > > I can't see any hint in RFC2317 that resolvers should/could change the > data they obtain from upstream, even if just "expand CNAMEs" (and it's > only BCP RFC anyway). In particular, if the particular zone is covered > by DNSSEC, you may trigger validation errors by that. You're right. But I believe it does allude to potential problems and confusion. As I study this more, the issue is this old RFC promoted unexpected cname for the qname in PTR results. My ISP is using it for delegating our new /27 segment of ips. The direct DNS server authoritive response is: qname qtype data d.c.b.a.in-addr.arpa PTR host1 d.c.b.a.in-addr.arpa PTR host2 .. d.c.b.a.in-addr.arpa PTR hostN The non-authoritive response is: qname qtype data d.c.b.a.in-addr.arpa CNAME d.X.c.b.a.in-addr.arpa d.X.c.b.a.in-addr.arpa PTR host1 d.X.c.b.a.in-addr.arpa PTR host2 .. d.X.c.b.a.in-addr.arpa PTR hostN Where X is the the first IP in the delegated IP range. Although my resolver will only return the requested PTR records, the record.name field will contain the cname. I am still studying the impact. The exploratory change in the resolver was to basically compare the name field with the qname, and set it to the qname if different. That way the clients will get the same expected results. I don't think its any different when A->CNAME->A operations is done and cached. It does not seem its going to be a impact on my SMTP clients/senders that could be setup to dynamically obtain the EHLO/HELO hostname by extracting the first record in a PTR lookup. But it could be an impact on incoming SMTP filter scripts that could be setting a PTR requirement. Not sure. It does seem safe, for our system compatibility, to make it consistent. In my opinion, the delegation CNAME is meta-data and it should be passive in the query results. Thanks for the heads up. -- HLS From nobody Sat Aug 26 13:01:24 2017 Return-Path: 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 57F20132BF0 for ; Sat, 26 Aug 2017 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001, URI_TRY_3LD=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tnetconsulting.net 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 sIUIpyDAK-qc for ; Sat, 26 Aug 2017 13:01:21 -0700 (PDT) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [IPv6:2600:3c00::f03c:91ff:fe26:8849]) (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 80A7613293B for ; Sat, 26 Aug 2017 13:01:21 -0700 (PDT) Received: from [198.18.18.251] ([8.44.145.194]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id v7QK1LR5028214 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 26 Aug 2017 15:01:23 -0500 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at tncsrv06 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1503777683; bh=4mYZUBMMaM/6jrbCrxLTXGev9PTXhlpPLcJlfG9AHQg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=F/6IR+HsgxZOYdOS07gGQW4IAn6ANJ59EIovei3iA9MpOskKMuLF0dm1X4g2zNxZE 7hMJFAdfM52Qb4+02bCC8QpOcVOj8iDjCdl+lF4yHApTfHX0HnrJQRjUEAr9bzBjGM vEvozd8+CqkBgv8FOeB1i5wjetyunBkezWy+a7AQ= To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> <79b5be5d-1cb0-44ac-a2c8-ebacf7ac2960@tnetconsulting.net> <59A1BC8A.3050204@isdg.net> From: Grant Taylor Message-ID: Date: Sat, 26 Aug 2017 14:01:28 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <59A1BC8A.3050204@isdg.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020108050409010903060200" Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Sat, 26 Aug 2017 20:01:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020108050409010903060200 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/26/2017 12:23 PM, Hector Santos wrote: > This was done, at least the first part of providing the ISP the two NS > servers required. They used RFC2317 to setup the cname delegation. On > my servers, I had done what you suggestion with the second method using= > a parent c.b.a.in-addr.arpa zone. It all seems to work, except for th= e > unexpected cname+ptr records with non-authoritive results. If CNAME is still involved, you didn't do what I'm recommending. Suppose that this is the ISP's reverse DNS zone: $ORIGIN . $TTL 3600 2.0.192.in-addr.arpa IN SOA ispdnsserver.example.com. hostmaster.example.com. ( 1234567890 ; serial 3600 ; refresh 1800 ; retry 604800 ; expire ) IN NS ispdnsserver.example.com. $GENERATE 1-122 $ PTR somehost.example.com. 123 IN NS mydnsserver.example.net. $GENERATE 124-255 $ PTR somehost.example.com. This would be your reverse DNS zone: $ORIGIN . $TTL 3600 2.0.192.in-addr.arpa IN SOA mydnsserver.example.net. hostmaster.example.com. ( 1234567890 ; serial 3600 ; refresh 1800 ; retry 604800 ; expire ) IN NS mydnsserver.example.net. $GENERATE 1-122 $ NS ispdnsserver.example.com. 123 IN PTR myserver.example.net $GENERATE 124-255 $ NS ispdnsserver.example.com. Notice how the ISP is using an NS record instead of a PTR or a CNAME reco= rd. The ISP is quite literally delegating DNS responsibility to you, the exact same way that the upstream parent, 0.192.in-addr.arpa., delegated 2.0.192.in-addr.arpa. to the ISP. That is the catch. You are re-using THE EXACT SAME METHOD that is already used, NS delegation. Do NOT use CNAMEs in the parent zone. > Still studying the impact. I was trying to prevent some consistency in= > the results in the resolver. In the same way, that its done for > A->CNAME->A results. CNAMEs in reverse DNS have been problematic for me. (See previous email.= ) > Thanks You're welcome. --=20 Grant. . . . unix || die --------------ms020108050409010903060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CgIwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggVLMIIEM6ADAgECAhBWFNl+TpTaXY4YBuKunuW7MA0GCSqG SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0EwHhcNMTYxMTIyMDAwMDAwWhcNMTcxMTIyMjM1OTU5WjArMSkwJwYJKoZIhvcNAQkB FhpndGF5bG9yQHRuZXRjb25zdWx0aW5nLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALQOeB9QxYwFjGM8smbnZihDiEsKsBBX0H1M9WC/HjeHf+AO26QH4mdiN+XpFMVy yVyZqEbgheL49o7qcRPf2PPVck+E67zn8b/kef1LbWde++QDMg56zZvAU4CbF7/v98WnHpzY LP+3AWK0z/7IfBwujQE8xW6E0vTZznq8GGP5z6pGSap4gKh/a8erEVcoYdK2IuWYa4sNxOvo FICiOoCMJhvU1F92yuuXCRZcZwFyav7P3+M36jHdViH2fuZuOhZBWb419mmhtUWS8r6aVdfk Vq+Pz3NdvLdo6AsUZpf7dZr/LeLW6gr2VoDQ5+j1JtI24wzl42RAVTsANoH/OusCAwEAAaOC AfgwggH0MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSxNT5f 50Ax2YRcuiCuDfxHUlkuGjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUE GTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/ MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9k by5uZXQvQ1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NP TU9ET1NIQTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAG CCsGAQUFBwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9D T01PRE9TSEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZ3RheWxv ckB0bmV0Y29uc3VsdGluZy5uZXQwDQYJKoZIhvcNAQELBQADggEBACCtfMI0hVAiQKvOx9Br ffT4YUPJRlXcs6yoDHfg0bnVw/ucEJ1neOi/aIUdA6EypUMNrshmgJTNaj6CsRH8c0yXOeGd nO5tNrPMYAhVvCQo/gpliYhIs2RAKXgFNtkUufwTqOQOLZva4LLVxSuSYncAgxdaj6TcORsd 9NEKPUC03F8yW0hk2M6WqvOpyIG4CWAP8Tmrxs0OKZuQeAoI3bs103EuMiMBTFIeEm8Obvx+ svg+UhK0CaMjEH92AwZ4blouFxqGTlgE/wclDCe+tZr/FvBP4Vflm/o82IkvyiNff8Qwz/BS z1hTRwSc7JexXVTms1cS7rMBRFwcvU2Le6kxggRBMIIEPQIBATCBsDCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgG A1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBWFNl+TpTaXY4YBuKunuW7 MA0GCWCGSAFlAwQCAQUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xNzA4MjYyMDAxMjhaMC8GCSqGSIb3DQEJBDEiBCD87DVznhot1W3DbK+6WQO6 Xj3/w4Jgb14sQ7wC0MmDjDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgB ZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMIHBBgkrBgEEAYI3EAQxgbMwgbAwgZsxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzCB wwYLKoZIhvcNAQkQAgsxgbOggbAwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRpb24gYW5k IFNlY3VyZSBFbWFpbCBDQQIQVhTZfk6U2l2OGAbirp7luzANBgkqhkiG9w0BAQEFAASCAQAT E3ziJuYz6EB3xFpCyXwFE8EhQDl84gpoy8d2tdLNJ7CzDFycwo8vRyGHl17yzRn+S6Tp2rD0 ZZ0xbsxisjnYIiPvWj6RDoHBbWC7H8jOVxgHJjO1hQv/nbVd/4+YrmcHJRGg7ELI/gByc/XH EZ3Zh31fd4Jfezod9X3k3GTmCrpuNUic7DofzFSmTp6SFlb8ke3Um5UScB4NwpNlYKX/p3sT 4jJmRfY/C5Vu9d70WhPtK+GFIee+vOQRDmlqSiPis82pVJuBN/PE51myo2Jrd907X0rqEP9P XnTNsqOtTimzq/haDWxfEtkAgkKvP0JKydbVaWSJ2iJFIuFwvUeOAAAAAAAA --------------ms020108050409010903060200-- From nobody Mon Aug 28 06:51:59 2017 Return-Path: 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 4DB17132A05 for ; Mon, 28 Aug 2017 06:51:58 -0700 (PDT) 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 vJvl-G2Gishu for ; Mon, 28 Aug 2017 06:51:56 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [IPv6:2a01:1b0:202:40::1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53A96132936 for ; Mon, 28 Aug 2017 06:51:56 -0700 (PDT) Received: from [172.24.17.49] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id E142B1BB64; Mon, 28 Aug 2017 15:51:53 +0200 (CEST) From: "Peter van Dijk" To: dnsop@ietf.org Date: Mon, 28 Aug 2017 15:51:52 +0200 Message-ID: <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> In-Reply-To: <20170824222734.C786E831AA5D@rock.dv.isc.org> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> MIME-Version: 1.0 X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Mon, 28 Aug 2017 13:51:58 -0000 On 25 Aug 2017, at 0:27, Mark Andrews wrote: > RFC 2308 is consistent with RFC 1034. > > Go read *all* of RFC 1034. QNAME is used to refer to *both* the original > *and* updated value after following a CNAME. +1 Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Mon Aug 28 15:20:23 2017 Return-Path: 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 B57AB1326BB for ; Mon, 28 Aug 2017 15:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 OlKB9u9Mb-G6 for ; Mon, 28 Aug 2017 15:20:18 -0700 (PDT) Received: from shbmap08.extra.chrysler.com (shbmap08.out.extra.chrysler.com [129.9.75.106]) (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 AFA8013208E for ; Mon, 28 Aug 2017 15:20:18 -0700 (PDT) Received: from odbmap09.oddc.chrysler.com (Unknown_Domain [151.171.137.34]) by (Symantec Messaging Gateway) with SMTP id 4C.FB.07972.D1794A95; Mon, 28 Aug 2017 18:20:13 -0400 (EDT) X-AuditID: 81094b68-ebc6498000001f24-91-59a4971df7cf Received: from mxph1chrw.fgremc.it (Unknown_Domain [151.171.20.45]) by (Symantec Messaging Gateway) with SMTP id B8.7C.17921.D1794A95; Mon, 28 Aug 2017 18:20:15 -0400 (EDT) Received: from mxph4chrw.fgremc.it (151.171.20.48) by mxph1chrw.fgremc.it (151.171.20.45) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 28 Aug 2017 18:20:15 -0400 Received: from mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701]) by mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1236.000; Mon, 28 Aug 2017 18:20:14 -0400 From: "Darcy Kevin (FCA)" To: "dnsop@ietf.org" Thread-Topic: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt Thread-Index: AQHTHORnHuETSd4O0EiRIffADErT/qKT6iSAgAAsejiABfxBAP//5pnQ Date: Mon, 28 Aug 2017 22:20:14 +0000 Message-ID: <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> In-Reply-To: <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [151.171.20.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyfXWnkq7s9CWRBlOPmVvcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXsf72crOMJX8XSSfwPjA+4uRk4OCQETifV9k1m6GLk4hAS2 M0psX7CBHSaxddUNJhBbSGA9o8T7y7wQResYJS5++MEO4exklFh8bxVYBxtQx8Ird5lBbBEB VYkL/76DdQsLpEjs+7mRHSKeKjHp0BwWCNtN4t/3KawgNgtQ/fwz78HqeQWcJDa8XMoIsaCZ SWLqgSlgQzkFHCS2zH7PBmIzCohJfD+1BqyBWUBc4taT+UwQZwtILNlznhnCFpV4+fgfK4Rt ILF16T4WCFtJYuebDSwQvToSC3Z/YoOwtSWWLXzNDHGEoMTJmU+g6u+xS3TMYZ7AKDkLybpZ SNpnIWmfhaR9ASPLKkbp4oyk3MQCAwu91IqSokS95IyiyuKc1CK95PzcTYzAGGzk9M7YwThn q+UhRgEORiUeXt2pSyKFWBPLiitzDzFKcDArifD+nQwU4k1JrKxKLcqPLyrNSS0+xCjNwaIk zmtUBJQSSE8sSc1OTS1ILYLJMnFwSjUwmt12SBcIVtzYWzhHbUmM1rd3V2SY9mlvf+PG7+JR eynz2PclAuIeHz7Y/J4i8GHeWQ+95AsPFPyK7yveKf2ZnG99nbWucuu+nfbdHYaXZ8oVBnnP TV2rzrCg7ZGBeWCukV+Qqtk0fimZcEN2wf+fT6d8TXzp/+qLHWt2vQ3DNsnNbTbd9huUWIoz Eg21mIuKEwF93/hTvQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUyfbWIrq789CWRBo9PSVrcfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGXsf72crOMJX8XSSfwPjA+4uRk4OCQETia2rbjCB2EIC6xkl 3l/m7WLkArLXMUpc/PCDHcLZySix+N4qdpAqNqCOhVfuMoPYIgKqEhf+fQfrFhZIkdj3cyM7 RDxVYtKhOSwQtpvEv+9TWEFsFqD6+Wfeg9XzCjhJbHi5lBFiQTOTxNQDU8CGcgo4SGyZ/Z4N xGYUEJP4fmoNWAOzgLjErSfzmSDOFpBYsuc8M4QtKvHy8T9WCNtAYuvSfSwQtpLEzjcbWCB6 dSQW7P7EBmFrSyxb+JoZ4ghBiZMzn7BMYBSbhWTFLCQts5C0zELSsoCRZRWjVH5KUm5igYGl Xn5KSrJeckZRZXFOapFecn7uJkZw3HQq7mBsXGR5iFGAg1GJh3fdlCWRQqyJZcWVuYcYJTmY lER5d1YsjhTiS8pPqcxILM6ILyrNSS0+xCjBwawkwvt3MlA5b0piZVVqUT5MSpqDRUmcV6XA IVBIID2xJDU7NbUgtQgmK8PBoSTB+3YqUKNgUWp6akVaZk4JQpqJgxNkOA/QcKlpIMOLCxJz izPTIfKnGCWlxHlZQRICIImM0jy43leM4kAvCPPuARnNA0yBcF2vgAYyAQ1UFFwIMrAkESEl 1cDovO9bw9xP+hKlu1WnHW7kb5zVcs7QXeBozkvVLYcaJfVurm5Rjvy3b24CU43ow82arQsU /s/yZl11pvyW88ebb87+e5iVwslrtLLeoTFMOoZXfLrZjsWyfae3nSz9+2D7V8WPqS/q1Jzi xCSMNUr9p1RvM53hNFc45Yv7t9jHf/YpmUbf/uCtxFKckWioxVxUnAgACkSqjT4DAAA= Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Mon, 28 Aug 2017 22:20:21 -0000 Please understand that I don't have a strong opinion on the DNS terminology= discussion, _per_se_, but I do have them with regard to semantics, logic a= nd proper citation, which was kind of my prior life, before I even got into= DNS, or even Information Technology (at various times an English major, Ph= ilosophy major, a professional proofreader, etc.) The erratum-to-the-erratum is that RFC 1034 didn't *define* QNAME. But RFC = 1035 did: Section 4.1.2, QNAME is one of the fields of the Query Section, w= hich, it is stated, constitute " the parameters that define what is being a= sked". Thus, deductively, QNAME is defined in that document as "the name th= at was asked [by the client, assumed]". RFC 2308 includes in its definition of "QNAME", end-of-CNAME-chain (where a= pplicable). This was not covered by the RFC 1035 definition, since the clie= nt didn't ask for it. We can talk about "references" all we want, but the erratum, despite an off= -by-one error in RFC citation, is about *definitions*, and the one in RFC 2= 308 differs from the earlier one from the RFC 1034/1035 matched set. - Kevin -----Original Message----- From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Peter van Dijk Sent: Monday, August 28, 2017 9:52 AM To: dnsop@ietf.org Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop= -terminology-bis-06.txt On 25 Aug 2017, at 0:27, Mark Andrews wrote: > RFC 2308 is consistent with RFC 1034. > > Go read *all* of RFC 1034. QNAME is used to refer to *both* the original > *and* updated value after following a CNAME. +1 Kind regards, --=20 Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop From nobody Tue Aug 29 01:08:58 2017 Return-Path: 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 44ADA132197 for ; Tue, 29 Aug 2017 01:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] 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 yiJHnQPNlQd7 for ; Tue, 29 Aug 2017 01:08:55 -0700 (PDT) Received: from shannon.7bits.nl (shannon.7bits.nl [89.188.0.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530FC132620 for ; Tue, 29 Aug 2017 01:08:55 -0700 (PDT) Received: from [172.24.17.49] (095-096-086-198.static.chello.nl [95.96.86.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: peter) by shannon.7bits.nl (Postfix) with ESMTPSA id 13E671BDA0; Tue, 29 Aug 2017 10:08:52 +0200 (CEST) From: "Peter van Dijk" To: "dnsop@ietf.org" Date: Tue, 29 Aug 2017 10:08:51 +0200 Message-ID: In-Reply-To: <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Tue, 29 Aug 2017 08:08:57 -0000 On 29 Aug 2017, at 0:20, Darcy Kevin (FCA) wrote: > Please understand that I don't have a strong opinion on the DNS > terminology discussion, _per_se_, but I do have them with regard to > semantics, logic and proper citation, which was kind of my prior life, > before I even got into DNS, or even Information Technology (at various > times an English major, Philosophy major, a professional proofreader, > etc.) > > The erratum-to-the-erratum is that RFC 1034 didn't *define* QNAME. But > RFC 1035 did: Section 4.1.2, QNAME is one of the fields of the Query > Section, which, it is stated, constitute " the parameters that define > what is being asked". Thus, deductively, QNAME is defined in that > document as "the name that was asked [by the client, assumed]". But it only defines it as such in the context of the query. > RFC 2308 includes in its definition of "QNAME", end-of-CNAME-chain > (where applicable). This was not covered by the RFC 1035 definition, > since the client didn't ask for it. Right, but end-of-CNAME-chain is implied in 1034 4.3.2. > We can talk about "references" all we want, but the erratum, despite > an off-by-one error in RFC citation, is about *definitions*, and the > one in RFC 2308 differs from the earlier one from the RFC 1034/1035 > matched set. Then what we need is an erratum for 1034 and/or 1035 to make explicit what is implicit in 1034 4.3.2: that the QNAME follows the CNAME chain. Once that erratum is submitted and accepted, all is consistent again between 1034, 1035, 2308. Then, RFCs like 5155 which rely on the 2308 definition remain correct in their usage of QNAME. Kind regards, -- Peter van Dijk PowerDNS.COM BV - https://www.powerdns.com/ From nobody Tue Aug 29 15:17:49 2017 Return-Path: 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 107DE13295E for ; Tue, 29 Aug 2017 15:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 KcunGN47tCXR for ; Tue, 29 Aug 2017 15:17:46 -0700 (PDT) Received: from shbmap07.extra.chrysler.com (shbmap07.out.extra.chrysler.com [129.9.75.105]) (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 691C2132697 for ; Tue, 29 Aug 2017 15:17:46 -0700 (PDT) Received: from odbmap09.oddc.chrysler.com (Unknown_Domain [151.171.137.34]) by (Symantec Messaging Gateway) with SMTP id B4.CF.15564.808E5A95; Tue, 29 Aug 2017 18:17:44 -0400 (EDT) X-AuditID: 81094b67-b882b98000003ccc-08-59a5e808ffcc Received: from mxph4chrw.fgremc.it (Unknown_Domain [151.171.20.48]) by (Symantec Messaging Gateway) with SMTP id 0D.26.17921.408E5A95; Tue, 29 Aug 2017 18:17:42 -0400 (EDT) Received: from mxph4chrw.fgremc.it (151.171.20.48) by mxph4chrw.fgremc.it (151.171.20.48) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Tue, 29 Aug 2017 18:17:41 -0400 Received: from mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701]) by mxph4chrw.fgremc.it ([fe80::cc0c:cb4f:1b3f:2701%18]) with mapi id 15.00.1236.000; Tue, 29 Aug 2017 18:17:41 -0400 From: "Darcy Kevin (FCA)" To: "dnsop@ietf.org" Thread-Topic: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt Thread-Index: AQHTHORnHuETSd4O0EiRIffADErT/qKT6iSAgAAsejiABfxBAP//5pnQgAFL5oCAAElCoA== Date: Tue, 29 Aug 2017 22:17:40 +0000 Message-ID: <2185536740e34a04977989f5dd5dec51@mxph4chrw.fgremc.it> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [151.171.20.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDIsWRmVeSWpSXmKPExsUyfXWnki7Hi6WRBtumsVncfXOZxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGTea57EUnJKqeNQxi7mBcZ9oFyMnh4SAicSdpc+Yuhi5OIQE tjNKdP1uYodJnP27CcwWEljPKPGmuRCiaB2jxL4T/SwQzk5GiZ9bp7GCVLEBdSy8cpcZxBYR UJW48O87E4gtLJAise/nRnaIeKrEpENzWCDsMIkVOy6C2SxA9UvWrAGbwyvgJDGv9xwbxIJP TBLffrQzgiQ4BRwket68ZAOxGQXEJL6fWgO2gFlAXOLWk/lMEGcLSCzZc54ZwhaVePn4HyuE bSCxdek+FghbSeLbqzVsEL06Egt2f4KytSWWLXzNDHGEoMTJmU/AvpQQuMYusfDHe+YJjJKz kOybhaR/FpL+WUj6FzCyrGKULs5Iyk0sMDDXS60oKUrUS84oqizOSS3SS87P3cQIjMNGTu/0 HYxXFloeYhTgYFTi4T1/dWmkEGtiWXFl7iFGCQ5mJRHe5mdAId6UxMqq1KL8+KLSnNTiQ4zS HCxK4rwfi4FSAumJJanZqakFqUUwWSYOTqkGxuMFV1z/60tlC0t/afoj67r6mcTqiLda5jw/ 7AoD4sTmOJd8y/jOGdpxP+2h9XIWngIbcTP3GXPrrwvrmpVWW258XLNk6epZ9ftCjh4KuOc+ 98ZPjZ7Cew3qWxys3XR+fy7mOhk1TTywP3Llqe8HbHnW/M5/8/Z2NIv9nxliE1IPTsxdU/Ri lxJLcUaioRZzUXEiAKzVkT2/AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUyfbWIgS7bi6WRBp1XmSzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujBvN81gKTklVPOqYxdzAuE+0i5GTQ0LAROLs303sILaQwHpG iTfNhV2MXED2OkaJfSf6WSCcnYwSP7dOYwWpYgPqWHjlLjOILSKgKnHh33cmEFtYIEVi38+N 7BDxVIlJh+awQNhhEit2XASzWYDql6xZAzaHV8BJYl7vOTaIBZ+YJL79aGcESXAKOEj0vHnJ BmIzCohJfD+1BmwBs4C4xK0n85kgzhaQWLLnPDOELSrx8vE/VgjbQGLr0n0sELaSxLdXa9gg enUkFuz+BGVrSyxb+JoZ4ghBiZMzn7BMYBSbhWTFLCQts5C0zELSsoCRZRWjVH5KUm5igYGl Xn5KSrJeckZRZXFOapFecn7uJkZw5HQq7mBsXGR5iFGAg1GJh9fi2tJIIdbEsuLK3EOMkhxM SqK8ss+AQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4m0FyvCmJlVWpRfkwKWkOFiVxXpUCh0Ah gfTEktTs1NSC1CKYrAwHh5IEbzhIo2BRanpqRVpmTglCmomDE2Q4D9BwR7DhxQWJucWZ6RD5 U4ySUuK8hU+BEgIgiYzSPLjeV4ziQC8I8+4AaeMBJkG4rldAA5mABsZ6gQ0sSURISTUwTtv/ ZM1m92X3tp9znWGatnr5bdkeqb+q9zQP6u/jbq1s1tThXbl2cR3nq2uta957ThHiy71pk7Vt y5N3hUc/dzbw/3pyiUfmuHRYGiNfgkp5YPXuh13JLp+6FN3Eou6nc/fYGJTX7bB4q51hFRas wH/25LUZ81WnxPyQWv6o4+/2L7t3Lzo1VYmlOCPRUIu5qDgRAAU8lAE/AwAA Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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: Tue, 29 Aug 2017 22:17:48 -0000 -----Original Message----- From: DNSOP [mailto:dnsop-bounces@ietf.org] On Behalf Of Peter van Dijk Sent: Tuesday, August 29, 2017 4:09 AM To: dnsop@ietf.org Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop= -terminology-bis-06.txt On 29 Aug 2017, at 0:20, Darcy Kevin (FCA) wrote: >> Please understand that I don't have a strong opinion on the DNS=20 >> terminology discussion, _per_se_, but I do have them with regard to=20 >> semantics, logic and proper citation, which was kind of my prior life,=20 >> before I even got into DNS, or even Information Technology (at various=20 >> times an English major, Philosophy major, a professional proofreader, >> etc.) >> >> The erratum-to-the-erratum is that RFC 1034 didn't *define* QNAME. But=20 >> RFC 1035 did: Section 4.1.2, QNAME is one of the fields of the Query=20 >> Section, which, it is stated, constitute " the parameters that define=20 >> what is being asked". Thus, deductively, QNAME is defined in that=20 >> document as "the name that was asked [by the client, assumed]". > > But it only defines it as such in the context of the query. So, as the sole definition in the foundational RFCs, perhaps that's the *on= ly* context in which the term "QNAME" should have meaning. Which is why I s= uggested coming up with a different term to be used in other contexts, e.g.= the resolver algorithm, the auth-server algorithm, negative caching and so= forth. That other term could encompass more than just the name which was o= riginally presented by the client as the QNAME; it could include end-of-CNA= ME-chain. >> RFC 2308 includes in its definition of "QNAME", end-of-CNAME-chain=20 >> (where applicable). This was not covered by the RFC 1035 definition,=20 >> since the client didn't ask for it. > > Right, but end-of-CNAME-chain is implied in 1034 4.3.2. It's *used* that way, but there is no *definition* in RFC 1034. That's my m= ain point. We have only 2 competing definitions of "QNAME" -- RFC 1035 (wit= h a limited context, as you point out) versus RFC 2308. Thus, we have a cho= ice: to either reconcile the competing definitions via errata (where one "w= ins" and the other "loses"), or we can bifurcate into different terms. Pers= onally, I prefer the 2-state solution, but it's not a strong preference. BTW, I looked through a big long list of DNS RFCs -- anything that came up = on a search of "DNS" on www.rfc-editor.org, that was on standards track, an= d non-obsoleted. Offhand, I couldn't find any other RFCs where "QNAME" was = defined. Of those that reference "QNAME" at all, most use it to refer to th= e name in the original query, although things get murky in the DNSSEC-relat= ed RFCs, especially when it comes to authenticated denial of existence (NSE= C for end-of-CNAME-chain? I'm not familiar enough with DNSSEC arcana to dis= cern, with any confidence). RFC 6672 borrows the algorithm from RFC 2672, w= hich in turn borrows it from RFC 1034, wherein the value of "QNAME" is supp= osedly "changed" to whatever is considered the end of the CNAME chain. But = this is, to repeat myself, not a (re)definition of "QNAME"; it started out = as merely a convenient way of pressing a string into service as a variable = within an algorithmic loop, and the text has just been copied&pasted from R= FC to RFC. - Kevin From nobody Tue Aug 29 20:08:55 2017 Return-Path: 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 9D58E13208E for ; Tue, 29 Aug 2017 20:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yitter.info header.b=fSoWVsdf; dkim=pass (1024-bit key) header.d=yitter.info header.b=HjWsQ7ug 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 dIlrNagIwZtn for ; Tue, 29 Aug 2017 20:08:52 -0700 (PDT) Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3034612422F for ; Tue, 29 Aug 2017 20:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 7D03EBEA1E for ; Wed, 30 Aug 2017 03:08:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1504062501; bh=/z045W5EjpDO7oxAOMBTd3jNraAzm3I0Cv1yenihvGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=fSoWVsdfrN3qZq1u5BAKrvWwwfJdvEMhTUoHA4jmsNBMtLeUcJLc47VbdUgkUvh5j yvqSB0Wk8Psu1zI8JxLaIKGcd/Ho6Es9O1IBHKHydNhcge+WCJJi8IBgh1ItJ+KHEM wcXlyvTjN6mVka70N4Zw+TetrDvPZXbZNded0sks= X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSr55G3TdWxy for ; Wed, 30 Aug 2017 03:08:19 +0000 (UTC) Date: Tue, 29 Aug 2017 23:08:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1504062499; bh=/z045W5EjpDO7oxAOMBTd3jNraAzm3I0Cv1yenihvGU=; h=Date:From:To:Subject:References:In-Reply-To:From; b=HjWsQ7ugeSEHZajWw1eHCAosQi34+4LCRgVBEiUPakbWH8FMn0AWu+eKQVt8WosVP yVArIMS7G8rljnbALiF8RSqrYqfZvsSvmWuv6aet3y+5fuIilXus8hqbhemGiW+4It BzdbvXVJYtEMVSOGWSg5nQJ3EOit4RmL11Ei2r5M= From: Andrew Sullivan To: dnsop@ietf.org Message-ID: <20170830030818.luqglgowaj5xgrv3@mx4.yitter.info> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> <2185536740e34a04977989f5dd5dec51@mxph4chrw.fgremc.it> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2185536740e34a04977989f5dd5dec51@mxph4chrw.fgremc.it> Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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, 30 Aug 2017 03:08:53 -0000 Hi, On Tue, Aug 29, 2017 at 10:17:40PM +0000, Darcy Kevin (FCA) wrote: > > So, as the sole definition in the foundational RFCs, perhaps that's the *only* context in which the term "QNAME" should have meaning. Which is why I suggested coming up with a different term to be used in other contexts, e.g. the resolver algorithm, the auth-server algorithm, negative caching and so forth. That other term could encompass more than just the name which was originally presented by the client as the QNAME; it could include end-of-CNAME-chain. > […] > It's *used* that way, but there is no *definition* in RFC 1034. That's my main point. We have only 2 competing definitions of "QNAME" -- RFC 1035 (with a limited context, as you point out) versus RFC 2308. Thus, we have a choice: to either reconcile the competing definitions via errata (where one "wins" and the other "loses"), or we can bifurcate into different terms. Personally, I prefer the 2-state solution, but it's not a strong preference. > Speaking as one of the presumed editors of post-7719 -- one who is, so-presumed, supposed to sort this problem out -- I hope it's ok to state _very strongly_ that I appreciate the extensive discussion of this issue. I think this is very much one of the kinds of knotty terminological problems that has created enormous difficulty for people approaching the DNS for the first time. Not only are terms hard to understand; but when you come across them, they seem to be slippery. At the same time, and taking off my editor hat for the moment, I am quite uncomfortable having a terminology document (which is what this thread is about) make the term not-slippery. It _is_ slippery in the reference documents. I don't think it helps us to try to settle those disputes. I think 7719-bis can do two things: 1. Document, as clearly as possible, the nature of the ambiguity. This thread has helped, but I bet (I haven't checked with my co-editors) that a ¶ well-worked-out on the list (not necessarily the WG please note) would be welcome. 2. Define, as clearly as possible and using new terms, the distinctions in question and provide names for them. These could be, of course, names not previously known. I emphasise again that clarity of definitions is, at least for me, quite important, so ambiguous examples are super valuable. Thanks! A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Wed Aug 30 06:32:55 2017 Return-Path: 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 4D0BD133298 for ; Wed, 30 Aug 2017 06:32:54 -0700 (PDT) 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 RmYgZLHuAo3M for ; Wed, 30 Aug 2017 06:32:52 -0700 (PDT) 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 E1B8E133296 for ; Wed, 30 Aug 2017 06:32:51 -0700 (PDT) Received: from [10.32.60.111] (50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v7UDVmoZ014356 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 30 Aug 2017 06:31:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-98-42.dsl.dynamic.fusionbroadband.com [50.1.98.42] claimed to be [10.32.60.111] From: "Paul Hoffman" To: dnsop@ietf.org Date: Wed, 30 Aug 2017 06:32:53 -0700 Message-ID: In-Reply-To: <20170830030818.luqglgowaj5xgrv3@mx4.yitter.info> References: <149894524329.526.18431408698564464455@ietfa.amsl.com> <20170824142147.lshdlmjv62nojd32@nic.fr> <20170824222734.C786E831AA5D@rock.dv.isc.org> <4DC2EF4E-8922-4531-958C-FC4BEF75EAFA@powerdns.com> <06a96a6e59d14d378098013966f6641b@mxph4chrw.fgremc.it> <2185536740e34a04977989f5dd5dec51@mxph4chrw.fgremc.it> <20170830030818.luqglgowaj5xgrv3@mx4.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [DNSOP] Definition of QNAME (Was: I-D Action: draft-ietf-dnsop-terminology-bis-06.txt X-BeenThere: dnsop@ietf.org 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, 30 Aug 2017 13:32:54 -0000 On 29 Aug 2017, at 20:08, Andrew Sullivan wrote: > Speaking as one of the presumed editors of post-7719 -- one who is, > so-presumed, supposed to sort this problem out -- I hope it's ok to > state _very strongly_ that I appreciate the extensive discussion of > this issue. I think this is very much one of the kinds of knotty > terminological problems that has created enormous difficulty for > people approaching the DNS for the first time. Not only are terms > hard to understand; but when you come across them, they seem to be > slippery. > > At the same time, and taking off my editor hat for the moment, I am > quite uncomfortable having a terminology document (which is what this > thread is about) make the term not-slippery. It _is_ slippery in the > reference documents. I don't think it helps us to try to settle those > disputes. I think 7719-bis can do two things: > > 1. Document, as clearly as possible, the nature of the ambiguity. > This thread has helped, but I bet (I haven't checked with my > co-editors) that a ¶ well-worked-out on the list (not necessarily > the WG please note) would be welcome. > > 2. Define, as clearly as possible and using new terms, the > distinctions in question and provide names for them. These could > be, of course, names not previously known. > > I emphasise again that clarity of definitions is, at least for me, > quite important, so ambiguous examples are super valuable. Thanks! As another co-editor of 7719-bis, I strongly concur with Andrew. I have been flagging all the messages in this thread and waiting for it to peter out before suggesting wording. If someone who is invested in this thread can propose text for 1 and 2, that would help because then others who are invested in the thread can comment and we can get good wording before the editors try. --Paul Hoffman From nobody Wed Aug 30 12:17:21 2017 Return-Path: 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 72C651326EA for ; Wed, 30 Aug 2017 12:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 0wuuWxdpZcJk for ; Wed, 30 Aug 2017 12:17:17 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C010F1321DC for ; Wed, 30 Aug 2017 12:17:17 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s187so35853782ywf.2 for ; Wed, 30 Aug 2017 12:17:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b0uOhSROvpaWXNxq2wXoitZQCMB6XoES7Hg+Iq2Gmz8=; b=LEfDuuqoTiPqAZhvk7tJN40SAsY9MLlodf1Mx+FFAbuN9hOlw2SXXkxDiVXTtf68KR y/jL3uWqlePgfqI1AUZC7QqWU//F59K1AfHHnOnj3fkCdURmh73PE1IqFaHyTwhnVE++ aUbh+95LOCZyN01R2zA+PdVHOvLs9Wp0lhZRoDCPUWIhvqTPOZxBvLUhh6xSd0HaMtO0 jGIqUzkLJEiiX8bS2p+uo1+Q6qPFC/0nn9Y0ZpQ14VCdHoofXbdWJfkVs1xTY+Ee4D+K SdPzxyDXDRxvZMNWboUpmDZgo4QotCThuIfd4t49hEnv+BgwxsghpxUrVdX50UKmRHks BqrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b0uOhSROvpaWXNxq2wXoitZQCMB6XoES7Hg+Iq2Gmz8=; b=G+jp3Hlqi3FPe7ahtzhf3/Nx97RBuaI2dUwMr3ZPIHRCGpvfay9U1ucbskprk+XvGZ BPnE4nQWa/9Et/3iK/nBej9fyrbXYC+Vk8n64Du/Mk3SHqX9S9j4LJUIrFxQZF43Jfo+ qxkpxEPofg6XfTzNSTBUClUYXJXhaXkg380cbZ2+zYG4Un54qqG0Nfi3AZEq0Ie1xhnx zV4mL+K3i20AJ9v9wW1KYF3J5Zd0lEEPD8Zwz6c2w6X0YmtOqQ+3XjmVxnkcyslOo3TU smbXoaVCSdP4PqdJ7FmDQmXzw8kOncfoECixgzSHwss/rN84miMs8dE/uhyw7Dej2RH5 2v7A== X-Gm-Message-State: AHYfb5iJ8yPAAnsHzBtlRB5Lr5lR6fWEO5OpXX1RqWQdjIcV85DmUwMD UuabeOJMHcv7+pCts/ad7J/XNhE01B1L X-Received: by 10.37.176.163 with SMTP id f35mr2388366ybj.138.1504120636724; Wed, 30 Aug 2017 12:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.69.24 with HTTP; Wed, 30 Aug 2017 12:17:16 -0700 (PDT) In-Reply-To: <328a6505-58ac-cb19-625d-34fa8af9c92f@nic.cz> References: <150143619012.17703.6263456348626337808.idtracker@ietfa.amsl.com> <328a6505-58ac-cb19-625d-34fa8af9c92f@nic.cz> From: Bob Harold Date: Wed, 30 Aug 2017 15:17:16 -0400 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: IETF DNSOP WG Content-Type: multipart/alternative; boundary="f403045f0d42406c540557fd60bd" Archived-At: Subject: Re: [DNSOP] The DNSOP WG has placed draft-tale-dnsop-serve-stale in state "Candidate for WG Adoption" X-BeenThere: dnsop@ietf.org 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, 30 Aug 2017 19:17:20 -0000 --f403045f0d42406c540557fd60bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 21, 2017 at 2:20 AM, Petr =C5=A0pa=C4=8Dek = wrote: > On 30.7.2017 19:36, IETF Secretariat wrote: > > The DNSOP WG has placed draft-tale-dnsop-serve-stale in state > > Candidate for WG Adoption (entered by Tim Wicinski) > > > > The document is available at > > https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/ > > I support adoption, will review. > > -- > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > Likewise. --=20 Bob Harold --f403045f0d42406c540557fd60bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Mon, Aug 21, 2017 at 2:20 AM, Petr =C5=A0pa=C4=8Dek &l= t;petr.spacek@nic.c= z> wrote:
= On 30.7.2017 19:36, IETF Secretariat wrote:
> The DNSOP WG has placed draft-tale-dnsop-serve-stale in state
> Candidate for WG Adoption (entered by Tim Wicinski)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-tale-dnsop-serve-stale/

I support adoption, will review.

--
Petr =C5=A0pa=C4=8Dek=C2=A0 @=C2=A0 CZ.NIC


Likewise.

--=C2=A0
Bob Harold
=C2=A0
--f403045f0d42406c540557fd60bd-- From nobody Wed Aug 30 12:53:10 2017 Return-Path: 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 BDB0B13292A for ; Wed, 30 Aug 2017 12:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 O0oiBHYYc4QX for ; Wed, 30 Aug 2017 12:53:06 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (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 0A0F5132A05 for ; Wed, 30 Aug 2017 12:53:06 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:55401) by ppsw-32.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dn92r-000byr-2B (Exim 4.89) (return-path ); Wed, 30 Aug 2017 20:53:01 +0100 Date: Wed, 30 Aug 2017 20:53:01 +0100 From: Tony Finch To: Hector Santos cc: "dnsop@ietf.org" In-Reply-To: <599EF4F2.6070509@isdg.net> Message-ID: References: <599EF4F2.6070509@isdg.net> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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, 30 Aug 2017 19:53:09 -0000 Hector Santos wrote: > > Not expecting this in my DNS resolver code, I modified the resolver to take > the CNAMEs into account and return the host names instead. Was this the > correct thing to do, thus providing the same results regardless of the query > location? Yes. You should also make sure your response parser isn't tripped up by DNAME records (you can safely skip them). See also https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis which sadly ran out of steam and stalled... Tony. -- f.anthony.n.finch http://dotat.at/ - I xn--zr8h punycode Southeast Iceland: Variable 3 or 4, becoming westerly 5 to 7. Moderate or rough. Mainly fair, occasional drizzle later. Moderate or good. From nobody Thu Aug 31 05:56:34 2017 Return-Path: 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 BA8DF132D90 for ; Thu, 31 Aug 2017 05:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isdg.net header.b=ExIn3Hen; dkim=pass (1024-bit key) header.d=beta.winserver.com header.b=0J8RvyX2 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 B6LKcSEQ3sFh for ; Thu, 31 Aug 2017 05:56:30 -0700 (PDT) Received: from secure.winserver.com (secure.winserver.com [76.245.57.69]) by ietfa.amsl.com (Postfix) with ESMTP id 6A311132D87 for ; Thu, 31 Aug 2017 05:56:30 -0700 (PDT) DKIM-Signature: v=1; d=isdg.net; s=tms1; a=rsa-sha1; c=simple/relaxed; l=703; t=1504184181; atps=ietf.org; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=M5iMCUAbHNY/1sn6hEnlIDxWpUY=; b=ExIn3HenO1L00tI2BxPffsQqE9POtMjW3etxg1ZD6WBUgDDE+HqSNK6eHC1KL3 Ux3YJYaimJLqCpwgMR8ZCcBDBBRsGRqlZqyZQuwiFV+xHnVqYHOi3iTCnRxgF65R IiZ5Bo+oc/DXjgT45TYFY+GuieH/ddf0X+DyaXN+pNGr8= Received: by winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Thu, 31 Aug 2017 08:56:21 -0400 Authentication-Results: dkim.winserver.com; dkim=pass header.d=beta.winserver.com header.s=tms1 header.i=beta.winserver.com; adsp=pass policy=all author.d=isdg.net asl.d=beta.winserver.com; Received: from beta.winserver.com ([76.245.57.74]) by winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 4248023375.75665.5616; Thu, 31 Aug 2017 08:56:21 -0400 DKIM-Signature: v=1; d=beta.winserver.com; s=tms1; a=rsa-sha256; c=simple/relaxed; l=703; t=1504184181; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=A3sZGP3 TRsRhhMFCUgxujGVH2gdj3kXUHPJtqUVoWOY=; b=0J8RvyX2Mspc3GLiOSrsWb/ vDwaU9j/o8csfztDzNJIPe6aml16BR/xGMN/z+9mVKm3bXSkOnEbSlgxYNaAiWRV zhZ1fEZgucmmKHdpQemCWsgt3+1Mpitkcc//pbKMiaAe3Vb9gECxxf6XHXYSPIfk Vmf3XfPQiaj/5AFIAuyA= Received: by beta.winserver.com (Wildcat! SMTP Router v7.0.454.6) for dnsop@ietf.org; Thu, 31 Aug 2017 08:56:21 -0400 Received: from [192.168.1.68] ([99.121.5.8]) by beta.winserver.com (Wildcat! SMTP v7.0.454.6) with ESMTP id 1131998750.9.31496; Thu, 31 Aug 2017 08:56:20 -0400 Message-ID: <59A80778.3020508@isdg.net> Date: Thu, 31 Aug 2017 08:56:24 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1 MIME-Version: 1.0 To: dnsop@ietf.org References: <599EF4F2.6070509@isdg.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [DNSOP] RFC2317 Question: Resolving cname delegation X-BeenThere: dnsop@ietf.org 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: Thu, 31 Aug 2017 12:56:33 -0000 On 8/30/2017 3:53 PM, Tony Finch wrote: > Hector Santos wrote: >> >> Not expecting this in my DNS resolver code, I modified the resolver to take >> the CNAMEs into account and return the host names instead. Was this the >> correct thing to do, thus providing the same results regardless of the query >> location? > > Yes. > > You should also make sure your response parser isn't tripped up by DNAME > records (you can safely skip them). Ok, I'm going to explore DNAME types (at least it to my resolver). > See also https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis which > sadly ran out of steam and stalled... Interesting. Thanks for the note. -- HLS