Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]

Tony Finch <> Wed, 07 June 2017 11:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81F3E129B41; Wed, 7 Jun 2017 04:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UBea0G1Qmosu; Wed, 7 Jun 2017 04:48:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4C9D1127011; Wed, 7 Jun 2017 04:48:06 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:44467) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1dIZRT-000jxW-ez (Exim 4.89) (return-path <>); Wed, 07 Jun 2017 12:48:03 +0100
Date: Wed, 7 Jun 2017 12:48:03 +0100
From: Tony Finch <>
To: Stephane Bortzmeyer <>
In-Reply-To: <>
Message-ID: <>
References: <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Archived-At: <>
Subject: Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2017 11:48:08 -0000

Stephane Bortzmeyer <> wrote:
> > The DNS model of master and slave servers, with the latter
> > initiating updates based on TTL values,
> The slaves don't use the TTL values, don't they?

That section is a bit weird.

                                                     Efforts to use very
   short (or zero) TTLs to simulate nearly-simultaneous updating may
   work up to a point but appear to impose very heavy loads on servers
   and distribution mechanisms that were not designed to accommodate
   that style of working.  Similar observations can be made about
   attempts to use dynamic, "server-push", updating rather than the
   traditional DNS mechanisms.  While those might work better than
   ordinary short TTLs and update mechanisms as specified in RFC 1034
   and 1035, they imply that a "master" server must know the identities
   of (and have real time access to all of) its slaves, defeating many
   of the advantages of caching, particularly those associated with
   reduction of query traffic across the Internet.

It doesn't mention the venerable and widely-deployed NOTIFY, and seems to
muddle up replication to authoritative servers and cacheing in resolvers.
If it is supposed to be talking about somthing of current relevance, it
should refer explicitly to draft-ietf-dnssd-push or whatever other
developments the author has in mind.

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Trafalgar: Northerly 5 or 6, becoming cyclonic 5 to 7, perhaps gale 8 later in
southeast. Moderate or rough. Fair. Good.