Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)

Joe Abley <jabley@hopcount.ca> Wed, 28 November 2018 20:14 UTC

Return-Path: <jabley@hopcount.ca>
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 657AC130FEA for <dnsop@ietfa.amsl.com>; Wed, 28 Nov 2018 12:14:03 -0800 (PST)
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, 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 oBSxlUbJ99mb for <dnsop@ietfa.amsl.com>; Wed, 28 Nov 2018 12:14:01 -0800 (PST)
Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 58BC5130FC7 for <DNSOP@ietf.org>; Wed, 28 Nov 2018 12:14:01 -0800 (PST)
Received: by mail-yw1-xc29.google.com with SMTP id g75so11288919ywb.1 for <DNSOP@ietf.org>; Wed, 28 Nov 2018 12:14:01 -0800 (PST)
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=WdWq948jXJ48w+Zu16DNI4cAHRS04Du/z6y0DiwqSxc=; b=nQ1NNKHTxk2P/x64VoHzPbWVBruAEKncwmHw66nzNp30aGf66dsqM6AhOp4racNbRI zxxxWWQvlm0A1c/TZ4jdq/3zzSejs7k+YR6soRvGT0VGKR6U9TVrEg19BwLhY8ThbZou 6l28BC8/lTCFT/prJv23L9KAzj7jOa6mXVLSQ=
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=WdWq948jXJ48w+Zu16DNI4cAHRS04Du/z6y0DiwqSxc=; b=q9n/EcqHLFX0KhdM7n3Ec2wO6qPHStXV5APbjS78ZAfLf1McI4jdJjGtlQFKGdOyYy ui3s7ahfcDFLHKfcamK7NMBnF3+7IJBFthYAhSYuu6bhDyMfmXWjKFBzhpPu8UtDyLen YZ2BPGKfpibnFbwnAwOvtCPtJGQKAdItyGZwYwZYSTRV3xX0t56XQtXWtSBU8RoqH68h s98eibFRvXHHaI0clx9M3+HfKKsHBNIWI5o0hu/PapmitZW8obnJ/sFmCVBG5yGdX3dr dDyZJZjTmFVbpa95SCv+Z4XbOhgy2WILWZCTawHiZ6Lfn7b+nPDNR2DcGNVvyXRIRSZ0 84fg==
X-Gm-Message-State: AA+aEWZBIIa7g02x4qoX5jn+3zdwichpf7Dh/Dk36yo7DShAa80pxEg8 JiA1Ri9FyvbBuzsElwzXgPBRiQ==
X-Google-Smtp-Source: AFSGD/Vi0YP1B/1VDpzZJVD4imi0aYiFfrDZXbNbocUFEQ3VJlBUZxIws8minHFQ19DhcFACNGteRg==
X-Received: by 2002:a81:98d0:: with SMTP id p199mr19879364ywg.279.1543436040363; Wed, 28 Nov 2018 12:14:00 -0800 (PST)
Received: from node-131dv5jso8madhh0sp.ipv6.teksavvy.com ([2607:f2c0:101:3:b1b9:4e7c:e412:4349]) by smtp.gmail.com with ESMTPSA id j134sm6508834ywb.91.2018.11.28.12.13.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Nov 2018 12:13:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <bc0ac914-9f47-f18b-359b-ed81d1a07c1f@sidn.nl>
Date: Wed, 28 Nov 2018 15:13:57 -0500
Cc: "DNSOP@ietf.org" <DNSOP@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C0AE711-440C-4885-88CD-A00A001056C1@hopcount.ca>
References: <bc0ac914-9f47-f18b-359b-ed81d1a07c1f@sidn.nl>
To: Giovane Moura <giovane.moura@sidn.nl>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FzT70SyyPOBo3EibxY6RtYmv86s>
Subject: Re: [DNSOP] Request for Adoption (draft-moura-dnsop-authoritative-recommendations)
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: Wed, 28 Nov 2018 20:14:03 -0000

Hey Giovane,

On 28 Nov 2018, at 04:55, Giovane Moura <giovane.moura@sidn.nl>; wrote:

> We have a new draft and we'd like to ask the WG to adopt it:
> 
> https://datatracker.ietf.org/doc/draft-moura-dnsop-authoritative-recommendations/
> 
> This is an informational draft that presents recommendations for
> authoritative DNS operators, based on research works we have been
> conducting over the last few years.

I have read this document. This is not a detailed review, just a more general reaction to the adoption question.

This document reads a bit like it wants to give operational advice but in fact it seems much more like a literature review that has been culturally adapted to an IETF audience. This is not intended to be a negative comment; I think the references and the context are useful and I think it's a great idea to find a way to push pointers to operational research into the RFC series, but I think it would be as well to make it clear that the operational advice contained within is not comprehensive and in many cases is quite superficial. I can give examples if you want more detail.

I also think that the document is not clear on what problem it is solving; in particular, it doesn't define "performance". It's inferred that the performance metric that matters is round-trip query latency for some nominal client at an average distance; what if the operator's priority is availability? That makes R1 potentially bad advice; no doubt there are other motivations that would also not fit the recommendations convincingly.

Much of the document is specifically concerned with the implementation of anycast strategies for DNS, not with authoritative DNS in particular. The advice would hold for any stateless (or short-duration transaction, where short is relative to routing stability). One direction the authors might consider taking this is to update the advice in RFC 4786 with reference to the repeatable experiments that you cite. Ironically 4786 was criticised for being a document about DNS that was pretending to be more general; perhaps when welded to your document the result would be more pleasantly neutral :-)


Joe