At 2/28/04 1:18 PM, Dave Warren wrote: >How are you supposed to gracefully migrate a live domain? I'm not >especially familiar with their mail server product (I should get more >familiar I suppose -- It's the one area I will not ever outsource though, >unfortunately for Tucows) but still, in every successful migration of any >sort that I've ever done, the only reliable method has been to keep both >the old and new services running simultaneously for a brief period, at >least 24 hours above your TTL (to accommodate ISPs that don't grasp how >TTLs work)
You should keep the old mail server running during the propagation overlap period, but you shouldn't have it in the DNS. Having both in the DNS simultaneously would defeat the purpose of waiting for the TTL to expire. For example, if the old MX record pointed at mail.example.com and had a 24 hour TTL, you should ensure that the server at mail.example.com still accepts and handles mail for the domain in question for at least 24 hours after you have completely removed the mail.example.com MX record, because other servers may keep sending to it for that long afterwards (and as you say, erring on the side of caution and keeping it running even longer is smart). In other words, you want both the old and new mail servers accepting mail during the overlap period to compensate for the fact that a sending mail server will act as though both MX records are present in the DNS during the TTL period (i.e., it could send to either the old or the new server), even though you've completely removed the old record. But literally putting both MX records in the DNS for some period doesn't buy you anything; it just lengthens the period during which mail will arrive at either server. So it doesn't really make sense to add a new MX record and also leave the old MX record in the DNS for 24 hours, as you seem to be implying. It just delays the propagation. However, as a completely separate issue (although perhaps I misunderstood and this is the problem you were mentioning), it sounds like Tucows's mail product will actually refuse mail for the domain until it determines that it's the only MX server listed, and it only checks whether that's true once per hour. That would mean it's impossible to switch an existing domain to use Tucows mail without risking bounces. For example, if I update a domain's MX records to point to Tucows server at 10:45 AM, and Tucows refuses to accept mail for it until the next time it checks to see if the DNS has been correctly updated at 11:40 AM, that's 55 minutes during which mail could bounce (and having both the old and new servers in the DNS wouldn't help, even if you could do that -- sending mail servers don't retry other MXs if the first listed MX bounces it). I hope nobody who understands how mail and DNS work would design a system that works this way. But if someone did, that's a complaint about the mail server being misconfigured to reject mail it should accept, and not really a DNS issue.... -- Robert L Mathews, Tiger Technologies "A professional in an ape mask is still a professional." -Marge Simpson
