Re: [dnsext] RETRY and EXPIRE clarification

Edward Lewis <Ed.Lewis@neustar.biz> Wed, 05 October 2011 12:42 UTC

Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923C921F8BEB for <dnsext@ietfa.amsl.com>; Wed, 5 Oct 2011 05:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.129
X-Spam-Level:
X-Spam-Status: No, score=-105.129 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaoWDlaw5UoJ for <dnsext@ietfa.amsl.com>; Wed, 5 Oct 2011 05:42:32 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfa.amsl.com (Postfix) with ESMTP id CD1BC21F8BE8 for <dnsext@ietf.org>; Wed, 5 Oct 2011 05:42:31 -0700 (PDT)
Received: from Work-Laptop-2.local (nyttbox.md.ogud.com [10.20.30.4]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p95CjVO4050189; Wed, 5 Oct 2011 08:45:38 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.203.207] by Work-Laptop-2.local (PGP Universal service); Wed, 05 Oct 2011 08:45:40 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Wed, 05 Oct 2011 08:45:40 -0400
Mime-Version: 1.0
Message-Id: <a06240804cab200031f9c@[10.31.203.207]>
In-Reply-To: <4E8C12CC.3090701@nic.cz>
References: <4E8C12CC.3090701@nic.cz>
Date: Wed, 05 Oct 2011 08:45:30 -0400
To: Lubos Slovak <lubos.slovak@nic.cz>
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.72 on 10.20.30.4
Cc: dnsext@ietf.org
Subject: Re: [dnsext] RETRY and EXPIRE clarification
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Oct 2011 12:42:32 -0000

At 10:18 +0200 10/5/11, Lubos Slovak wrote:
>Hi,
>
>I find the definition of RETRY and EXPIRE intervals in RFC 1035 
>quite vague and did not find any other RFC clarifying it.

First lesson in reading RFC 1034/1035 - don't take them that 
literally.  They were descriptions of the system, not specifications. 
This was explained to me by one of the folks involved in writing them.

>1) Should the RETRY interval start when the REFRESH event occurred (this
>is a bit more deterministic) or when it is clear that the transfer failed,
>i.e. on timeout or error during transfer (this is maybe closer to the
>definition of RETRY in RFC 1035, part 3.3.13)?

Doesn't really matter, I mean, how long does it take to fail a 
transfer?  Let's say it's 90 seconds - if the retry is 43200 (12 
hours), whether you try 1/2 a day later or 1/2 day plus 90 seconds 
later isn't going to change things.  It looks cooler in the logs if 
the retries happen at the stroke of 1/2 day intervals, but it doesn't 
matter in the long run.

>2) What should happen if the EXPIRE interval elapses before the transfer is
>finished (assume large zone, transfer lasts for several minutes and EXPIRE is
>set too low - i.e. 1 minute)? Should the server cease to serve the zone? If
>yes, should it serve the zone again after the transfer is finished?

Could and yeah.  I suspect that while you are transferring the zone 
you can suspend checking the timer if you want and no one would 
complain.

EXPIRE shouldn't be that low though.  DNS wasn't built to be real 
time, when you have a server-cache-client architecture you can expect 
it to be that fast.

(There's nothing wrong in trying to make DNS be real time.  But 
you'll have to realize it takes some work as that wasn't the design 
goal.  Kind of like trying to drag race pickup trucks.  You can do 
it, but it isn't as easy or efficient as drag racing speedsters.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Vote for the word of the day:
"Papa"razzi - father that constantly takes photos of the baby
Corpureaucracy - The institution of corporate "red tape"