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

From: [email-masked]
Date: Wed, 8 May 2019 22:57:06 +0200 (CEST)

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.

---

From: Joe Abley <[email-masked]>
Date: Wed, 8 May 2019 14:44:54 -0700

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=[email-masked] wrote:

Hello,

RFC BCP draft purposal

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.

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 :-(

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.

Two steps but 0 loss.

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 8 May 2019 22:44:24 -0400

In article <CAJhMdTOpTgKA-hQZF3agrcVkdjpkoAyAFpgN4RxFWdkwwa=[email-masked]> you write:
>deployed. ...

Agreed.  Also anything that expects to make a flash cut from one set
of DNS data to another is doomed to disappointment due to caches,
network delays, and lost packets.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: [email-masked]
Date: Thu, 9 May 2019 11:56:36 +0200 (CEST)

Hello, 

GOOGLE uses a equivalent method to manage his business accounts ^^ see the "text screenshot" of my advanced DNS section from my BOOKMYNAME registrar: 

Example Google confirm domain ownership 

googlefffggghhh12345 (your uniq confirm string) CNAME google.com. 
@ TXT "google-site-verification=(your uniq confirm string)" 

=> The second line also exists for "activate by anticipation the google business account" no ? ^^ I do not say "if google gave the idea, it is the method we will propose" but the lack exists. 

De: "John Levine" < [email-masked] > 
À: [email-masked] 
Cc: [email-masked] 
Envoyé: Jeudi 9 Mai 2019 04:44:24 
Objet: Re: [DNSOP] draft idea : rfc_bcp_no-mail-loss-during-ns-changes.txt