IETF Logo Mail Archive

Re: [DNSOP] proposal: Covert in-band zone data

Matthew Pounsett <matt@conundrum.com> Tue, 23 July 2019 13:18 UTC

Return-Path: <matt@conundrum.com>
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 67C90120073 for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 06:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 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_HELO_NONE=0.001, SPF_NONE=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=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 axFzxGonrd0T for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 06:18:03 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 2583412006D for <dnsop@ietf.org>; Tue, 23 Jul 2019 06:18:03 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id e20so51336193iob.9 for <dnsop@ietf.org>; Tue, 23 Jul 2019 06:18:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=conundrum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zMl64RXu3mNJ0okvlhTKDqD/lh3w4Sto3sS+cLDjKvA=; b=rR0MDxg87UU/zJ89TXWRI/5lW3mzV3dEAf87dkAQnlgqT1mOeoQKfemxZXqOuTJz0W x6ojmXhpV6Z23ARo6NYDUc2WM1B+V8tW4o8ogoeKqwXkPsmbycHX39vAXKbysbQ8uJIy sKgN2rbJSY10CwY63+5rRiTnkOVQcIzaqVrlr1VM6QFW7S5JCAaHuYuaovmB160uyZhR gM2Z2Z3UY6NSByyc48MPcx6rvG/ZlHHHbrm9pa/lwsQ5ky8RUavFErrrWRMVrKd2FkGp +2abCOpvokn5WYy5cItovK5w0McXoULP2MiuBVn5NPj35z3VoPbl56fS/APoquBd6rpv yUlA==
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=zMl64RXu3mNJ0okvlhTKDqD/lh3w4Sto3sS+cLDjKvA=; b=SgXjO1QMtNBeKdldhNsn4KV6vsMgmOSsuAdGQxPoz1iR1CzuWGEE20R2Td+8h8fQjN ZCvNMWCzMalLNYUWAYRmyjmNT1jzl/lkusTxbrI2IwF8YnI5BNtroZzmX3VWZv0kaEPj FDrozyjp5kdks/Kb3TBygL5lPUBkUjBvQAQHZWiSxcGRC2xV4ltbx/RhrUDkrcwatw0A /qdweL/nbY0tChTK6FrURbv6W4MphG6L3yZaOk0Uq+peFTCwfBaf/RNLKZ+2WGrjuVh0 C9m67KfhPQoZX5EkUCY8zg4txlrq3zR/DNPXgHleyIHlJoaF201hd3DySKKGZ1Zfi++C dnjA==
X-Gm-Message-State: APjAAAX2OvfQV7/1UrtPmrMRofYkkPy0VIuwLTOO9v98c74meVeMp90/ m2fpjMo80XkvihGJF/JMWUmcvAeDk4OOAYKBO64zljQo
X-Google-Smtp-Source: APXvYqyzmmkpp7bnpGz82lbt+qixtJpshjs2SvNtKFSQvdLwNYuvjnzkXtr4iLaWBRVrPmNgNByBrsdhxxP7IdZqFCQ=
X-Received: by 2002:a5e:8704:: with SMTP id y4mr20975709ioj.135.1563887882397; Tue, 23 Jul 2019 06:18:02 -0700 (PDT)
MIME-Version: 1.0
References: <20190706213024.GA56650@isc.org> <alpine.BSF.2.21.9999.1907221704030.7062@bikeshed.isc.org>
In-Reply-To: <alpine.BSF.2.21.9999.1907221704030.7062@bikeshed.isc.org>
From: Matthew Pounsett <matt@conundrum.com>
Date: Tue, 23 Jul 2019 09:17:49 -0400
Message-ID: <CAAiTEH-fBQL6NXYKmjzuit8_uu44pfMw71tnEZrtNN-B+N+UWA@mail.gmail.com>
To: Dan Mahoney <dmahoney@isc.org>
Cc: Evan Hunt <each@isc.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b3017b058e5905b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fV2P2hbQ1vHR2s24pa9pr3cyGbY>
Subject: Re: [DNSOP] proposal: Covert in-band zone data
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Jul 2019 13:18:04 -0000

On Mon, 22 Jul 2019 at 14:00, Dan Mahoney <dmahoney@isc.org> wrote:

> On NOTE:
>
> Moving to the DNS-vendor standard answers of "just use DDNS" or "put it in
> an IPAM" add additional complexity, and additional attack surfaces.  DNS
> servers have a tenuous relationship with database backends, and I spend
> enough time patching my DNS servers without having to patch an IPAM.
>

"Just use DDNS" is actually harmful advice in many situations, for exactly
the reasons you've raised.  Maintaining versioning and "blame" (who made
what change when) is overly complex when trying to use DDNS-based zone
maintenance.  Not to mention I can put together a fairly decent zone change
management process using version control and zone files with off-the-shelf
software that any small enterprise can make use of ... there just aren't
any good OSS zone editors based on DDNS that I'm aware of, and small
enterprises can't afford to do a ton of in-house software development to
make something purpose built.

v2.23.0 | Report a Bug | By Email