Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

Warren Kumari <warren@kumari.net> Fri, 27 July 2018 20:44 UTC

Return-Path: <warren@kumari.net>
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 9B1BD130E45 for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 13:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] 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 226KJ-b27PXV for <dnsop@ietfa.amsl.com>; Fri, 27 Jul 2018 13:44:22 -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 5B718129385 for <dnsop@ietf.org>; Fri, 27 Jul 2018 13:44:22 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id s14-v6so6860677wmc.1 for <dnsop@ietf.org>; Fri, 27 Jul 2018 13:44:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=5MqySMaE7aKq9OnXhmAefzp8PEWCb16H+MKGyvpl2ZQ=; b=PVNnByeVNKvUUJqRhMt4dn8fmEH+KuSM3UtNHZA54AWZIKu7Xs0h7+j0cm4hvLwult 9HSzEPv8VipL6p0j10HAkY8As69e2+moo6F/82/Igi7fJ+KWby/HKRsQGPJjvIWs1cm3 C3M5B5nqnQb8elR6VY8Y7AGHDSbtp5Oy6z5W8L7BH70wFfXygLrGeOwfXtPA2oTOUyvt TV2z/Yd392L7U+hMiF3nE74rGpf/2GrgrLgsqswTs4Fc5wkGdMWGcL3aiCuGTBxXK1a/ MWiWdpEfG6mHE5vieuUmbKhfjBJpO7jHSj6MWKmknbpWca1NSMDC8kePUNEmIbrHu/1i w6PQ==
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:content-transfer-encoding; bh=5MqySMaE7aKq9OnXhmAefzp8PEWCb16H+MKGyvpl2ZQ=; b=l6NYRpFxMroflY0mzBB97/2/y8yeYI2yYXV6tt6MXnpo2RoZ2wEXxSibhjxLED7nBu w+CRiB2PovmSSK+FBJUMPVHuwWEQyUnW8pPK9JzJ7ueOg/9qlkSnXsBNBDNoUAArBcf6 XjVq8kgWvmZuHT/QeLVS9lpVBdoadE5u69AePck8kvEnxfw535P4dW8H12IYuX/pPQQA LIpPJQFJdHMD6LyVWbhV6ZYr/hqAibUOUdDOf1Cil3qFcTU6gAHxtAgO/LsfmcQfodQz IGofG/bcGRmLYFqanrPcmvh85eg8NBPjJFlVp+XeL4MLJ4cJ1phtJR3gbvrnHAj8ETxM YqeA==
X-Gm-Message-State: AOUpUlGRzZRdKf0KBuMDQW2P9uPGZXiKY99T8pGJFdnqnbHc+Fe+hbDs lw056+zxG4D0kfkdYUM8Kv4nssm9THWpFzNvepnKAw==
X-Google-Smtp-Source: AAOMgpfGngOFbE2fRCzA4fcxZ0eLJXRsoO/aDTyca3YmQ7+24vFSmJU2jP6VE8mJcVV9vC4njUHKCO5k4WE0DVvc7OU=
X-Received: by 2002:a1c:c60a:: with SMTP id w10-v6mr5590310wmf.26.1532724260463; Fri, 27 Jul 2018 13:44:20 -0700 (PDT)
MIME-Version: 1.0
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <CAAObRXL2LoB3f=296ZPE1Pp1nHkG---pRPAmyO1trTROxneHDQ@mail.gmail.com> <FF0A0A24-705F-46E3-BF31-314078636EE2@isc.org> <CAAObRXLjnOeaGZyHhvxH3xPwGBp=zxx6AjLSSm=CXR33NM-LjA@mail.gmail.com> <CAJE_bqetth7KLPsFaQD_S9w-LQYLaAz+7c9F9iG7TLX7zfzaOQ@mail.gmail.com>
In-Reply-To: <CAJE_bqetth7KLPsFaQD_S9w-LQYLaAz+7c9F9iG7TLX7zfzaOQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 27 Jul 2018 16:43:44 -0400
Message-ID: <CAHw9_iKcxzpuS7sdxoET1gmF5jbE9udFS7Dzg-TSj+pYiQ27NA@mail.gmail.com>
To: 神明達哉 <jinmei@wide.ad.jp>
Cc: Davey Song <songlinjian@gmail.com>, dnsop <dnsop@ietf.org>, mweinberg=40verisign.com@dmarc.ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vfA5SOJ9MgZu_gn1pbAVZW-4l04>
Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jul 2018 20:44:26 -0000

On Fri, Jul 27, 2018 at 3:02 PM 神明達哉 <jinmei@wide.ad.jp> wrote:
>
> At Fri, 27 Jul 2018 10:59:53 +0800,
> Davey Song <songlinjian@gmail.com> wrote:
>
> > > The problem is that when you have every recursive server in the world with
> > > a copy of the root zone from “random places” you want to reduce the
> > > possible error spaces into manageable chunks when things go wrong which
> > > they will.  Being able to verify the contents of the root zone you have are
> > > not modified helps.
> >
> > Generaly speaking it is ture for any file replication. But it is not
> > relevent with DNS context.
>
> Right, so I think one main question is why the root DNS zone case is
> so special that a protocol extension is justified.  Personally, I'm
> not yet fully convinced about it through the discussion so far.  As
> several other people seem to be persuaded, however, maybe I'm too wary
> just because of my hat of handling eventual "named triggers an
> assertion failure after zone transfer for some bogus zone digest"
> CVEs.  But at the same time, if my sense of the wg's take on the "DNS
> camel" discussion is correct, I think we (WG) should require a higher
> level of justification for new protocol features.

This can, but does not have, to be built into the nameserver itself.

As examples, Shane Kerr has created
https://github.com/shane-kerr/ZoneDigestHackathon
and Duane has created https://github.com/verisign/ldns-zone-digest
Both of these can be used as external utilities to validate a zone file.

I'd be perfectly happy doing something like:
'dig AXFR . @b.root-servers.net > root.zone (or wget
https://www.internic.net/domain/root.zone )
ldns-zone-digest -v . root.zone
if [ $? -eq 0 ]
  then
    `rndc reload .`
  else
    send_alert_critical.sh "Local root zone issue" "Panic\! Unable to
load new root zone"
fi'

(obviously with more error checking :-))

I'm also somewhat more paranoid than most - I'd personally also like
to be able to do something like:
for file in *
  do
    ldns-zone-digest -v $file $file.zone
      if [ $? -ne 0 ]
        then
          echo "${file} has been corrupted. Aborting..."
          exit 1
        fi
   done

in my init scripts.

I also used to host a zone for a friend who doesn't run his own
nameserver. He would email the the zonefile whenever he made changes,
and I would copy and paste it into a file[0] - it sure would have been
nice to be able to run something like 'named-checkzone foo foo' and
make sure I'd copied and pasted the whole thing correctly...

W
[0]: He wasn't really the sort of person I wanted to give a shell on
my machine to :-)

> Again, personally,
> I don't yet think draft-wessels-dns-zone-digest has passed this test.
>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> 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