Re: [DNSOP] draft idea : rfc_bcp_no-mail-loss-during-ns-changes.txt
Joe Abley <jabley@hopcount.ca> Wed, 08 May 2019 21:45 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 CCFB8120179 for <dnsop@ietfa.amsl.com>; Wed, 8 May 2019 14:45:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, 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 a-743BMFZ7hb for <dnsop@ietfa.amsl.com>; Wed, 8 May 2019 14:44:59 -0700 (PDT)
Received: from mail-lf1-x142.google.com (mail-lf1-x142.google.com [IPv6:2a00:1450:4864:20::142]) (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 0D1A61200E0 for <dnsop@ietf.org>; Wed, 8 May 2019 14:44:59 -0700 (PDT)
Received: by mail-lf1-x142.google.com with SMTP id n134so13809622lfn.11 for <dnsop@ietf.org>; Wed, 08 May 2019 14:44:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=CgL/0oiGdSbe5x6Mhxkmq6tkS/OtaBlyPwVwDFnNVoY=; b=RwyfspqzDJpclURUGRWMSgRksUPdQUwTTbbcAe13ioS1D08MiW50AcTYTP9B4bkYGb bzvgJmSAcXWHVVt69RlosRNweO7MnaayQcOZSCsTOgkgS+vhQ+ycyUByqjSPqRCrXwqk +dcvwfEZ/45wBV/cuOWREqXNJcEniYNHWk0hA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=CgL/0oiGdSbe5x6Mhxkmq6tkS/OtaBlyPwVwDFnNVoY=; b=jTtewaQZefUKal/Ep4NWunfAbnfsIOSPyycqkDCTeaSAFol+y1pgiDQdt5vNaCLLeT k3jFSxhalVRcIDKck8/tFYcR9wAhpHwsreCxC2uYZPK8C13NUOvIpNwZYP6ubguG7MfZ 7jQQA3QxUwyaVq8phFm6QFXWW/RvSRGskaLkfpIrE91VzQgCMdO8T64eUCk9zp2/ir/5 AbuBfk70Voc/Km+GAMLeHKcA1yUoZ2BgvcslpPCCDpLpLmM22IzJPG6V3xE0H/ZFzMgo YiD4RtyZQUCS0I5+E6QxlB9k1AWFWAlsyaKtj5wdBeIzMRrkvhR9PUgkWZG4CwGbwumw o3OQ==
X-Gm-Message-State: APjAAAU1/P5dv89FNV4EAVvfCFEc2U3PGbfFn1ta6UeGEKcvNO8/PRkw OXyY0R0LF+Kkq4vynk1Oz8Mxirf8zHBc3szGHbHwsA==
X-Google-Smtp-Source: APXvYqwu8tRqaITIA712zuzb2kxD8aLTH8G0NS8s4btC9Nx4btyr0I+3Pm5UfEHh0EpIFuDrpLmoKh+upJJ4V0pUu7E=
X-Received: by 2002:a19:e002:: with SMTP id x2mr254574lfg.16.1557351896132; Wed, 08 May 2019 14:44:56 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Wed, 8 May 2019 14:44:54 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
References: <1943718379.11243461.1557349026256.JavaMail.zimbra@laposte.net>
In-Reply-To: <1943718379.11243461.1557349026256.JavaMail.zimbra@laposte.net>
Date: Wed, 08 May 2019 14:44:54 -0700
Message-ID: <CAJhMdTOpTgKA-hQZF3agrcVkdjpkoAyAFpgN4RxFWdkwwa=RWw@mail.gmail.com>
To: vivil@laposte.net
Cc: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="0000000000008f464e0588673ed9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/d0lBOVGeaApolVyfX2mOD7V-iig>
Subject: Re: [DNSOP] draft idea : rfc_bcp_no-mail-loss-during-ns-changes.txt
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, 08 May 2019 21:45:02 -0000
Hi there, To avoid the problem I think you are describing you just need to serve appropriate responses from both the losing and winning authoritative name server sets simultaneously for a period starting just before the change of the delegation NS set. That period should continue after the delegation set change for not less than the TTL of any NS set cached by any client resolver. For safety that TTL is the maximum of the outgoing delegation and apex NS set TTLs, since that's an area where you can't always rely upon uniform resolver behaviour. Unless you have unusual requirements to minimise the length of that period you might multiply that number by some factor to accommodate resolvers who for local policy reasons might cache the outgoing NS set for longer. MX RRSets don't have special requirements, in this regard. No other signalling is necessary. More generally, proposals for new conventions that require changes in both requestor and respondent in the DNS are difficult to imagine ever being deployed. Proposals to make DNS implementations more complicated are also undesirable since the DNS is already complicated enough. In this case your idea doesn't actually provide additional functionality, however, unless I have misunderstood some fundamental aspect of what you are suggesting. For guidance on how to produce correctly-formatted internet-draft documents (and the tools available to reduce or maximise the pain in doing so, depending on your preferred level of irony) see < https://www.ietf.org/standards/ids/>. Joe On May 9, 2019, at 03:57, vivil=40laposte.net@dmarc.ietf.org wrote: Hello, This a new idea/draft to avoid loss mails during an NS change Sorry for the ugly write :-X RFC BCP draft purposal *Avoid loss mail during a name server (NS) provider move.* When we want to choose a new NS server/service for our domain name, we can have a tiny delay of several seconds just after typing the new NS on your main DNS hoster interface and the real service activation at the new NS manager hoster. Enough to have possible mail losses. It is often the case when your new commercial NS provider manages tons of NS (and need to know, thanks to your NS changes, than you are the real owner). I purpose than a TXT filed on the former NS root could be created with any of the future desired NS changes "ns1_future:ns1.my_future_ns_provider.com" "ns2_future:ns2.my_future_ns_provider.com" Example: I actually use "ns1.former_ns_manager.com" and "ns2.former_ns_manager.com" on my DNS hoster "ns1.new_ns_manager.com" and "ns2.new_ns_manager.com" changes made can be only detected by the new NS manager alsmost several seconds after the real change and can occurs loss messages during this time :-( By using these 2 TXT fields created on my former NS manager .... seb@seb:~$ dig TXT vivilproject.com ; <<>> DiG 9.11.3-1ubuntu1.7-Ubuntu <<>> TXT vivilproject.com (...) ;; ANSWER SECTION:vivilproject.com. 3600 IN TXT "ns2_future:ns2.future_ns_provider.com"vivilproject.com. 3600 IN TXT "ns1_future:ns1.future_ns_provider.com" ...... "future_ns_provider.com" can easily read the TXT field and he will knows for sure i want to shortly use his service and, with this information, he can temporary activate my account and authorize mail routing during a definited time of X hours or Y days. So i have the time to calmly change these two NS on my DNS hoster. Two steps but 0 loss. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop