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

Warren Kumari <warren@kumari.net> Thu, 12 July 2018 17:56 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 75C19130E58 for <dnsop@ietfa.amsl.com>; Thu, 12 Jul 2018 10:56:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.41
X-Spam-Level:
X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 zF0sdeWH8fz3 for <dnsop@ietfa.amsl.com>; Thu, 12 Jul 2018 10:56:13 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 40BD112F295 for <dnsop@ietf.org>; Thu, 12 Jul 2018 10:56:13 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id e7-v6so3017696wrs.9 for <dnsop@ietf.org>; Thu, 12 Jul 2018 10:56:13 -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=3oVmN78TCeV8DR1K1SX/IzYtxCCryeYvCKeMs68ppwU=; b=rOoBmREcXFoM+g7rK3UmEnZsA7jg9z31DRY/fpz94KDMHlckIER+HhtWxD3G1eqDXX 6XjY9YSVwlGjlIk/Ng0coaHIl4mjnp57ABU/QE+bplbHOuEojVzH4tAUv0V7BLTQkas4 uVDGrZVzi3AS2sSu6mQu2Ib/XNwG0v7v+WD/31V+dhRGG1gjaI0qbg6ObBAWN3Sm6sm6 9CMJeHeen84wjJGtQsxBDadBFvFQgHR6LnWIw9WZY7xnX07jS8Bfa3LgVyfx6ng+qlib WqFjyECRnYNwXOh0UcuXgJ+RDEtOXIk2wAQerS/Fwer13lPBXL2uxUKX522xts86p1Nk BAdw==
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=3oVmN78TCeV8DR1K1SX/IzYtxCCryeYvCKeMs68ppwU=; b=d/h/+Q0YWojy/chhQ/Xq4MYXw4M/ArILz6hnjCsP0di0YGkwjS46N/4+LN2feKtjsk 14RUEb/hEBuD6KCVYu/A+s5ZvXWNr1WaqUAbM3pDeEoZSfGtRYVpi5MnQUaianvX210P W9gmOk4ImQAqyEIE4knipYcbmH3qx3wXin3Uojg3LgXLZp6qYtcUbvZBxCiIeSOho6V/ d4N/mM6959HV446M916mgYWsngrI5jynJQH0csraIvW4KuWVOypiRZRU3Uo0X6DhBAzr B+llmm61N5GrMMWJhz4pRccqKVzFIKifYwTXHx3GsYORymsIejdCCFttrmhJBGgbUbb1 Mp/g==
X-Gm-Message-State: AOUpUlGXU5m9zB/U8s/AMwkDE3qUdEMBNPL9IhzVMItpLM+GJqxexaKL fbgWcTkAjJ/bFdkXSMHs0vCZGl8/niH7qj89oLS2gA==
X-Google-Smtp-Source: AAOMgpcnQqO29FkF8aK45XiqwswTNMhAIuxzxdTgzhA/Rqtn8JXCBiDIeTQOW3ca2bYbTttDn5zk/rrDU/P+F/SG208=
X-Received: by 2002:a5d:574d:: with SMTP id q13-v6mr2456815wrw.24.1531418171539; Thu, 12 Jul 2018 10:56:11 -0700 (PDT)
MIME-Version: 1.0
References: <4DCC5A51-1AB0-47B6-92B5-79B6894F9A9C@verisign.com> <CAJE_bqcELQbQeHPvvEBHOxpRyWYL76BmT_-G4jW4pTnUUXFMUw@mail.gmail.com> <27C44216-581A-4991-A739-ECE8B7F8AA35@verisign.com> <884c2d11-9db0-7668-59c9-baa8574a03f7@time-travellers.org> <37873808-8354-b26b-34f4-880ea7a5f0da@nic.cz> <e9f99fce-c240-7f23-c580-1fb8bd0a0687@time-travellers.org> <20180621203116.a7kv4ysotfe7kw5k@nic.cl>
In-Reply-To: <20180621203116.a7kv4ysotfe7kw5k@nic.cl>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 12 Jul 2018 13:55:35 -0400
Message-ID: <CAHw9_iKN7N+poGYqCVvRDwqXx9WjbZmF5ZMKDd3XkfsLifm=Ng@mail.gmail.com>
To: hsalgado@nic.cl
Cc: Shane Kerr <shane@time-travellers.org>, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v_MM9HzRShuYl60j_4rC-D6xf00>
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: Thu, 12 Jul 2018 17:56:16 -0000

On Thu, Jun 21, 2018 at 4:31 PM Hugo Salgado-Hernández <hsalgado@nic.cl> wrote:
>
> On 22:09 21/06, Shane Kerr wrote:
> > > Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
> > >
> > > Hmm, can you share some details about your experience?
> > > Did you find out when the data corruption took place?
> > > a) network transfer
> > > b) implementation bugs (e.g. incorrectly received IXFR)
> > > c) on disk
> > > d) some other option?
> >
> > I don't know. I have seen incorrectly transferred zone files both in
> > BIND
> > and NSD slaves. IIRC our solution was to include sentinel records in
> > the
> > zone files to spot problems, take the node out of service, and force a
> > re-transfer. This of course won't work if you are slaving zones that
> > you do
> > not control, and it doesn't prevent a small window of time when the
> > servers
> > are operating with broken zones. TSIG was being used.
>
> We have also seen broken transfers between secondaries. Our solution
> is to dump the zone after transfer, calculate a hash and compare. We
> would benefit from having a ZONEMD record inside the zone.

i *seem* to remember something happening with .de a few years back --
IIRC, slaves did a zone transfer, ran out of disk and truncated the
file, and so only had a partial zone file to serve - something like
2/3ds of the .de zone "disappeared". A zone checksum would allow the
nameserver to know that they do not have a full zone file.

My memory is hazy, because I would have expected the AXFR to fail and
the nameserver to just continue using the old zone. Perhaps there was
some other transfer mechanism and it involves restaring the
nameserver? I'm sure someone must remember more detail on this event.

W

>
> Hugo
>
> _______________________________________________
> 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