Quoting Andrew McGlashan (andrew.mcglashan@affinityvision.com.au):
Many would say that about not having a backup MX, but anyway, guess we beg to differ on this one.
I've never known any third authoritative nameserver to be directly usable by spammers to cause a domain to DoS itself (which you may recall my saying is exactly what often happens with a backup MX). Also, if SMTP becomes undeliverable for less than four days (the customary 45x delivery timeout for most MTAs; suggested somewhere in RFC 5321) before restoration of service, no mail loss occurs, as it will all get delivered during subsequent retries. (Worst that happens is that senders will get some tempfail DSNs during your downtime.) And, hey, if you cannot figure out how to receive 25/tcp traffic again somewhere in the world within 4 days, I don't think you should call yourself a sysadmin. ;-> By contrast, if all of a domains auth nameservers go on holiday, the moment cached data reaches TTL at any recursive nameserver or host DNS cache, the domain's totally offline from there, all services broken and hardfailed. IMO, that's rather a bit more urgent and severe a breakdown than if incoming SMTP deliveries are merely stuck in a 4-day holding pattern pending your standing up a new MTA host.
I do have a DNS problem that is bugging me.....
Android phone, mobile data off, local WiFi on. Sometimes the mobile gets DNS answers for public DNS instead of the private one... running bind9.
Using views, I guess?
A laptop continuously testing from the same local network as per the Android phone never, ever gets the public answer :confused:
Yeah, don't know offhand. Maybe closely check the BIND9 logs for clues about why some queries are being handed the wrong view data? Double-check the Android 'phone about what network it's on when this happens. (I'm handwaving, there, out of lack of knowledge about what to check on such a smartphone.)
Any ideas on this one?
Wish I did. It's peculiar, all right.