Email migration and MX records
We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Hi Bruce, This is something I'm presently battling with as well. My current previously tested plan is: 1. Create all user accounts (with NEW email addresses) on the new email system 2. Setup a temporary forwarder on an existing *temporary* email server (we use hMail) which forwards all email sent to the *current* address to the *new temporary* address 4. Pre-stage the DNS zone file with the new DNS provider (we use Google Cloud DNS which allows this) 5. Transfer the domain name by *purchasing* a transfer/renewal with Google DNS - this allows us to immediately specify the Google Cloud DNS zone file thus preventing downtime 6. At a later date: migrate the destination domain to the new tenant This allows you to transfer the domain to a new tenant whilst still forwarding interim emails whilst you jump through the domain validation hoops. I am, of course, welcome to any recommended improvements to this process. Otherwise, good luck! Best, Richard. -Original Message- From: bind-users On Behalf Of Bruce Johnson via bind-users Sent: 03 January 2023 9:32 pm To: bind-users@lists.isc.org Subject: Email migration and MX records We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Email migration and MX records
Hi Bruce, It would be better to have an SMTP server return 421 "4.3.0" or 421 "4.7.0" while the migration is under way instead of bouncing the connection. 421 will tell all SMTP servers everywhere to "try again later". The 421 error is a proven greylisting configuration. Not knowing what is all involved with the actual migration, another option might be something as simple as putting the prod Barracuda server(s) into "maintenance mode". If that will prevent the migration from happening perhaps Barracuda can spin up an SMTP server that only answers with 421. Or, if you all are able, you could roll your own SMTP server to answer 421. Obviously standard do-not-test-in-prod, don’t wing it and hope for the best .. have a step-by-step playbook disclaimers apply and there is nothing wrong with a lower TTL of 60 seconds or less to facilitate reverting. John -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Bruce Johnson via bind-users Sent: Tuesday, January 3, 2023 3:32 PM To: bind-users@lists.isc.org Subject: Email migration and MX records We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Bruce Johnson University of Arizona College of Pharmacy Information Technology Group Institutions do not have opinions, merely customs -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Views vs Separate Authoritative & Recursive DNS
New to BIND and just starting to read the 5th edition from O'Reilly after watching some videos online while it made its way to me. I am trying to understand why the view statement appears to be included by default in most Linux distributions if best practice says you should have separate servers for each? Based on the comments in the named.conf sample file I am inclined to remove all of the view statements so it operates in "default view" on new servers I am setting up to replace old ones. Is the view statement just there for those who need to ignore best practices or am I missing something? -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
