[DNSOP] draft idea : rfc_bcp_no-mail-loss-during-ns-changes.txt

vivil@laposte.net Wed, 08 May 2019 20:57 UTC

Return-Path: <willemijns.sebastien@laposte.net>
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 C88F312014F for <dnsop@ietfa.amsl.com>; Wed, 8 May 2019 13:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=laposte.net
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 eSEYrmu9qOzZ for <dnsop@ietfa.amsl.com>; Wed, 8 May 2019 13:57:08 -0700 (PDT)
Received: from smtp.laposte.net (smtpoutz13.laposte.net [194.117.213.172]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CD81200EC for <dnsop@ietf.org>; Wed, 8 May 2019 13:57:08 -0700 (PDT)
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout001 (Postfix) with ESMTP id 8B8014E86A70 for <dnsop@ietf.org>; Wed, 8 May 2019 22:57:06 +0200 (CEST)
Received: from smtp.laposte.net (localhost [127.0.0.1]) by lpn-prd-vrout001 (Postfix) with ESMTP id 6F3854E86A72 for <dnsop@ietf.org>; Wed, 8 May 2019 22:57:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=laposte.net; s=mail0; t=1557349026; bh=CkQAS0mEsON9h2jCWCPofY8VWkA89kuC8LUEMQS7snU=; h=Date:From:Reply-To:To:In-Reply-To:Subject; b=XVKGhFM6/NyUup8SBiKdAXTQzaiDBCA9sDhiLdT7T2tDSpJ1to7edKRGy1ih7jrde /mexNt25m27FgRg3Q7tqWxza25fxKULNseJgfxbgyNfjGbTNs9Z93WKElxNDpqMtEl EcT/rm79UDzWVOIG5koLMxm8k7/9SyJjVcj2J7sM32WIZDKbOPOFVOVoVbTDs/ZgF1 v/THhxBbfVRnWsjV6ReKGN9u6XIZKLVXd6E7Je8TCuzeVkBLQeHKQlQ3yJ+HIAZt0T nq1b2ugPZu3AU3/6U9dZ7H/HqEVU2C/zsSkk9O75FUfRF5+34UiF3vRxe2yhw7GWbF Rj7PJLNJsvwdA==
Received: from lpn-prd-mstr021.laposte (lpn-prd-mstr021 [10.128.59.22]) by lpn-prd-vrout001 (Postfix) with ESMTP id 541374E86A70 for <dnsop@ietf.org>; Wed, 8 May 2019 22:57:06 +0200 (CEST)
Date: Wed, 08 May 2019 22:57:06 +0200
From: vivil@laposte.net
Reply-To: vivil@laposte.net
To: dnsop@ietf.org
Message-ID: <1943718379.11243461.1557349026256.JavaMail.zimbra@laposte.net>
In-Reply-To: <300723765.11241870.1557349010294.JavaMail.zimbra@laposte.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_11243460_1468803928.1557349026255"
X-Originating-IP: [176.179.153.110]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF66 (Linux)/La Poste)
Thread-Topic: draft idea : rfc_bcp_no-mail-loss-during-ns-changes.txt
Thread-Index: pIf0lhgPRekklrweaWmcELeY7Xz2yw==
X-VR-FullState: 0
X-VR-Score: 0
X-VR-Cause-1: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgdduheeiucetufdoteggodetrfdotffvucfrrhho
X-VR-Cause-2: fhhilhgvmecunfetrffquffvgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpeffhfhrvffk
X-VR-Cause-3: jgfugggtihfothesrgdttggsredtjeenucfhrhhomhepvhhivhhilheslhgrphhoshhtvgdrnhgvthen
X-VR-Cause-4: ucffohhmrghinhepmhgrnhgrghgvrhdrtghomhdpvhhivhhilhhprhhojhgvtghtrdgtohhmpdhprhho
X-VR-Cause-5: vhhiuggvrhdrtghomhenucfkphepuddtrdduvdekrdehledrvddvpddujeeirddujeelrdduheefrddu
X-VR-Cause-6: uddtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhhtpdhinhgvthepuddtrdduvdekrdehledrvddv
X-VR-Cause-7: pdhhvghloheplhhpnhdqphhrugdqmhhsthhrtddvuddrlhgrphhoshhtvgdpmhgrihhlfhhrohhmpeif
X-VR-Cause-8: ihhllhgvmhhijhhnshdrshgvsggrshhtihgvnheslhgrphhoshhtvgdrnhgvthdprhgtphhtthhopegu
X-VR-Cause-9: nhhsohhpsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt
X-VR-AvState: No
X-VR-State: 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_PztceXU4-Yzh3hvrYog6NhAYD0>
Subject: [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 20:57:11 -0000

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.