Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?)

Mark Andrews <marka@isc.org> Wed, 09 August 2017 23:29 UTC

Return-Path: <marka@isc.org>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211D31270AC for <homenet@ietfa.amsl.com>; Wed, 9 Aug 2017 16:29: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 JLKHk-2Bo-pU for <homenet@ietfa.amsl.com>; Wed, 9 Aug 2017 16:29: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 4A62B126B71 for <homenet@ietf.org>; Wed, 9 Aug 2017 16:29:30 -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 9A1CA24AE12; Wed, 9 Aug 2017 23:27:59 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id EEB9F1600A4; Wed, 9 Aug 2017 23:28:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DC9671600A3; Wed, 9 Aug 2017 23:28:04 +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 19UCWkY1MhRX; Wed, 9 Aug 2017 23:28:04 +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 630FA160041; Wed, 9 Aug 2017 23:28:04 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id DA30381E1E05; Thu, 10 Aug 2017 09:28:01 +1000 (AEST)
To: Ted Lemon <mellon@fugue.com>
Cc: HOMENET <homenet@ietf.org>, Warren Kumari <warren@kumari.net>
From: Mark Andrews <marka@isc.org>
References: <150223150804.3668.14190745110025046639@ietfa.amsl.com> <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com> <20170809031722.28F8F81C6FC7@rock.dv.isc.org> <CAPt1N1mkOheWcQAispL7zpK=Whcjm=7ibjJcv9-DuNJKFyBiXw@mail.gmail.com>
In-reply-to: Your message of "Wed, 09 Aug 2017 11:53:42 -0400." <CAPt1N1mkOheWcQAispL7zpK=Whcjm=7ibjJcv9-DuNJKFyBiXw@mail.gmail.com>
Date: Thu, 10 Aug 2017 09:28:01 +1000
Message-Id: <20170809232801.DA30381E1E05@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/SwvKFxV_rW1uU0SgeBq26ENSFaE>
Subject: Re: [homenet] I-D Action: draft-ietf-homenet-dot-11.txt (FINAL?)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 23:29:32 -0000

In message <CAPt1N1mkOheWcQAispL7zpK=Whcjm=7ibjJcv9-DuNJKFyBiXw@mail.gmail.com>, Ted Lemon writes:
> 
> What does forwarding DS lookups for home.arpa out of the homenet do?   That
> is, suppose I implement a cache that doesn't do this: what bad thing
> happens?   It's going to return NXDOMAIN, right?   Isn't it the NSEC
> lookups that have to succeed, and the NS record lookup?   And doesn't the
> NS record have to be forged?

It will return a signed NOERROR nodata responses saying that there
isn't a DS record for home.arpa but there is a delegation assuming
DO=1 is set in the query and IANA has competed setting up the
insecure delegation.  If DO=0, or there isn't a OPT record, you
still get a NOERROR nodata response but that isn't useful for
downstream validating clients.

Note for DNSSEC to work reliably all resolvers that are forwarding
queries need to be DNSSEC aware (set DO=1) and validate responses.
If they don't validate responses they will cache bad answers which
will prevent down stream validators getting good answers.  Validating
allow the forwarding resolver to reject bad answers and to try
alternate sources.

It they don't validate DNSSEC will work most of the time because
most answers you get back are actually correct and complete.

Writing a recursive server these days that doesn't support DNSSEC
should be a hanging offence. :-)

> I think this actually means that it does have to be an unsigned delegation.
>   Argh.
> 
> Hm, thinking farther, no, it doesn't, because it's okay to return the right
> answer for the delegation as long as the stub resolver is willing to rely
> on the cache, which we've already specified it must do.   So what's the
> failure mode that this new text prevents?  Oh, you have to look up the DS
> record to get the NSEC that validates it?

Yes (proves its non existence).
 
> (I'm leaving in all of the stuff I typed while I was thinking this through
> because I'm not sure I got it right, and you can point out what I got
> wrong.)
> 
> On Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews <marka@isc.org> wrote:
> 
> >
> > In message <79597E4D-DEC0-4622-A410-003B45EB5E6A@fugue.com>, Ted Lemon
> > writes:
> > > I updated homenet-dot with the change that Mark requested regarding
> > > signed, unsigned and insecure delegations.   I believe the text is
> > > correct now, but would appreciate a sanity check.   Otherwise, I think
> > > it's up to the chairs to make the next move.
> >
> > I would explictly list DS home.arpa as a exception.  (I had to file
> > a bug report against recursive server that failed to have this
> > exception this week for AS112 zones.  The bug has been fixed.)  Also
> > I wouldn't be using '.home.arpa.' as we also want to stop queries
> > for 'home.arpa' leaving the home.  There are a couple of references
> > to '.home.arpa'.
> >
> > e.g.
> >
> > Old:
> >    DNS queries for names ending with '.home.arpa.' are resolved using
> >    local resolvers on the homenet.  Such queries MUST NOT be recursively
> >    forwarded to servers outside the logical boundaries of the homenet.
> >
> > New:
> >    DNS queries for names ending with 'home.arpa.' are resolved using
> >    local resolvers on the homenet.  Such queries MUST NOT be recursively
> >    forwarded to servers outside the logical boundaries of the homenet with
> >    the exception of DS lookups for 'home.arpa.'.
> >
> > Mark
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org