Posted
by
ScuttleMonkey
on Wednesday December 07, 2005 @02:21PM
from the underdeveloped-ideas dept.

ebresie writes "Computer Business Review Online has an interesting article about the lack of acceptance for Secure DNS." From the article: "Speaking during a workshop on the technology, Keith Schwalm of Good Harbor Consulting, a former US Secret Service agent, said that even the financial sector, traditional security early-adopters, are not rushing DNSsec."

I disagree. What you are talking about is the research part of a good or determined attacker. In this instance, the zone transfer is just more information on what to attack. This definitely is not a big risk.

However, there is much more associated with DNS that you can do.

If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?

A good example is a piece of malware that changes the local DNS cache to point ebay to another server that does a man-in-the-middle attack? To the end user, it's completely invisible.

It's fairly easy to do on a LAN by using one of the mitm tools. What you are doing is setting up a rogue DHCP server and DNS server, then you give the target computer a lease with a machine you control as the DNS server. If you control DNS, you can tell them to go anywhere you want, including sniffing their traffic, altering the content of the traffic enroute, basically whatever you want.

If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?

Secure protocols like ssl already solve the problem at a different level. DNS spoofing might get you connected to the wrong server, but when they fail the key-based challenge you'll know anyways. Even with secure DNS, those higher-level protocols would *still* have to carry out the checks they do now, since even after looking up the correct IP address, your IP packets could be misrouted. So what does secure DNS really buy you?

I'm not saying the authentication protocols already available (say in ssl) are entirely satisfactory, but duplicating them in DNS won't make them any better.

Most people can't tell if they are connected using SSL or not. One of the nice things about secure DNS is that if the DNS response is spoofed, it just doesn't come back. So if you have someone spoofing a zone, you don't see answers to the zone, rather than seeing and accepting the wrong answers. This leads to trying to figure out why "the internet isn't working," which leads to the revelation that someone is spoofing DNS, which leads to the problem being corrected.To spoof you without secure DNS, all

Those are beyond salvation and I don't think that secure DNS was developed with them in mind.

I mean, someone which will accept following an hyperlink coming on a html e-mail from somebody unknown to him that says "your.bank.of.confidence" while obviously opening a browser pointing to "your.hacker.of.the.day" won't benefit any more from using secure DNS.

The way I look at it is like PKI (remember when it was the silver bullet to everybody's security concerns? It always make me cringe when people started talking PKI for a company with 15 employees). It works great if you are a huge organization like the government, but if most people will not see any benefit of it at all. But then again, most government agencies have their own Certificate Authority, which makes DNSSec and PKI easier to tie into.And, to be honest, I like SSL better than DNSSec because ther

If you have a malware that poisoned your DNS cache, it might as well install a new trusted key in your browser. The malware site can then have another key that is signed with the key that the malware have already installed and you will have a secured connection.

But starting with a corrupted computer to begin with is a bad example anyway. The malware could simply substitute the ie.exe program for a new one that show what he want.

SSL does not solve DNS issues. Nothing prevents determined hackers from installing an SSL certificate on their phishing website to look like the real thing - most users don't know the difference anyway.

SSL does nothing to prove you're connecting to the right site if the attacker gets a cert from a CA. Most of the CAs now have "instant" SSL certs which have zero identity checking and a lower price. Very few users pay attention to the SSL icon, but even fewer open up the certificate properties and verify that the organization name on the cert is from who they think it is.

Sure, but DNS as it stands is much better in terms of scalability and redundancy. If you add a lot of authentication and double checking, the whole system becomes less efficient.Your scenario is plausible, but if someone is in a position to execute a Man in the Middle attack, then they can just snoop your traffic by redirecting it through a proxy under their control...Why bother with a DNS redirect? Cache poisoning exploits have been around forever, but they're not all that common either.

A good example is a piece of malware that changes the local DNS cache to point ebay to another server that does a man-in-the-middle attack? To the end user, it's completely invisible.

That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate. Again, if you as a user are so completely braindead that you ignore the warning then it's your own damn fault for getting your information compr

"...That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate...."If I am truely in the middle, i can rewrite URL, present other certificates etc, ( spoof the certificate authority too even ), all this software technology exists Load balancers content switches ssl concentrators all have to legitmately do this now.

All that being said, this is currently not the biggest threat, although pull

SecDNS doens't address poor set-up. It attemtps to assert zone authority through record signing. Right now, you don't know if DNS is resolving the correct address or not which makes poisoning such a nasty threat.

RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole.com zone before they begin to expire. Anyone know any different?

Rumor is false, with hardware accelerator.com can be signed inabout 1 hour on a fast AMD system.The distribution of the zone is a bigger issue, but most of the time only fragments of the zone would be signed at the same time.

RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole.com zone before they begin to expire. Anyone know any different?

That's not true... They have indeed signed the whole.com zone in practice on some fairly decent machines and it was on the order of hours (if I recall; I think 6), not months which is the more likely signature life time they'd pick

These are a serious problem. It would be relatively trivial for someone to poison DNS by spoofing a server that is pointed to by other DNS servers. The poison will then run downstream, affecting all servers that (ultimately) derive information from what should have been the master server. Because many corporations use SSL only after a person has entered login data, it would be possible for someone to use this to masquerade as a legit bank, with the bank's actual human-readable name but pointed to their own

Enough of my customers don't understand REGULAR DNS, nevermind secure DNS. The only way that this is likely to be adopted is to have the top level name servers eventually require the secure extensions. I doubt, however, that that will happen.

As it is now, I have my users going to their registrars and "deleting the 'A' records because: "There is no A on my website."

I run my own DNS server at home because I have a bigger fear that my ISP's DNS may be hijacked rather than my bank. It seems like that would be the easiest hole to crack for hackers.

I would hope that if my bank's DNS servers were hijacked that they would work with me to get any money I lost back. However, if my ISP's DNS servers were hijacked, I don't know that the bank would be as cooperative.

That oughtn't be a great problem, however, since your bank (hopefully?) uses a SSL certificate to ensure you that you are on the right web site. If you click past the SSL warning that says that the certificate doesn't match the domain name when you go to do some on-line banking, you really shouldn't be all too surprised to find all your money gone the next day.

But if your ISPs DNS has been poisoned, then the attacker can resolve any host to the IP address of thier choice. If I control your ISP DNS server and I tell it that www.amazon.com resolves to 192.168.10.1 which is a web server I control, then I can send you a certificate claiming to be from www.amazon.com, and the DNS name will match the FQDN in the certificate. That wouldn't be a problem.

You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place. But that is a different problem altogether.

You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place.

Yes, well, that was exactly what I was referring to. One shouldn't even begin to suspect that a bank would have a web server certificate that wasn't signed by one of the big CAs.

Yeah, and that is especially a concern with all the DNS registrars. Can they be trusted to really identify that some one is who they say they are beyond taking the information off of a credit card statement?

This is a valid point, especially when you look at the number of small fish in the pond. You have small registrars, you have small CAs (do you really trust Unizeto? I don't even know what it is, and yet by default Mozilla gives it the same trust as it gives Verisign.) Even so, I posit that it really doesn't matter how much trust I can place in the CAs and the registrars, because the (unfortunate) end result is that most users, when presented with a certificate error, simply click OK. We train users to do this. Many corporate and educational entities set up their own CAs, and then when users see a message in their browser about an untrusted CA, the tech staff just tells them to 'click ok'. As such, the user is now conditioned to click 'OK'. What have we done? Totally diminished the usefulness of the trust aspect of SSL.

Quite a bit actually. I quote Godaddy.com's Wildcard High Assurance 256bit SSL Cert "The Validation Process verifies: domain name and domain control; identity and authority of requesting person or company". I think some of the personal verification steps include credit reports and the like. Funny that I was JUST thinking of this last night.

" How much hard checking do these CA's really do?"Thawte just wanted a fax of our phone bill. Ours even had the wrong company name. I told them to look up our newly filed "doing business as" statement, but I don't know if they did.

I would believe that browser developers don't put CAs in the root CA set without very good reason. I haven't been requesting any certificates myself (I run my own CA instead for home use), but I believe that all the CAs in the standard browsers' root CA lists do very stringent control of the applicants.

After all, if they didn't, they wouldn't remain in the browsers' root CA list for very long.

www.spoofedbank.com that looks like Bank of America can get a certificate on their own and the end user wouldn't even know. How many non-slashdotters never or even know how to read a certificate? They just clicky through.

Of course there would be somewhat of a trail if the cert is signed by a CA and that's the only way they won't get a popup.

I guess I am really clueless, but don't banks use a security certificate so that a user like myself won't be misled into thinking that a spoofed site is really the bank? For example, I am a customer of bankX.com and I let my browser verify the site, if it's the right site I get the right response, if it's the wrong site I don't get the proper response.I do this with my machine at work too, I use ssh with a public/private key set-up. If someone highjacks my machine I will be informed when I log on --- actual

Wait. So your solution to the insecurity of DNS is to run a another DNS server? That sounds a bit insane to me. What if someone hacked the root DNS servers? It's been done before.

Seems like a more sane solution would be to add your banks IP address to your/etc/hosts file(s) and then set the/etc/nsswitch.conf hosts entry to 'files dns'. Then, if the bank's IP address changes, confirm it with the bank's IT department.

If the roots get signed, they'll certainly going to be using off-line signing so the private half of the signing key won't be kept on the servers themselves. Thus, an attacker couldn't modify the data without people that were already aware of the public key wouldn't detect (and if they tried to change the key validating resolvers with the root keys installed as trust anchors would notice the difference and ignore the answers; end result a

How about performance issues? I found that running my own DNS server actually increased my internet speeds. The computer was spending less time trying to find the websites and was actually getting to them. Then again, the internet providers in South Eastern Idaho are pretty brain dead. So it was no suprise. At the time that I put up the DNS server, I was living with room mates, and they actually connected to the server, and within about a month I had an entire building connecting to my FreeBSD 4.6 box. The

"Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more."

So you have domain, secure domain, and when that gets compromised, you will then have super secure domains, ultra secure domains, and supermax domains?

The goal of all this is to prevent phishing and other exploits? I think SPF will make a much bigger difference in cutting down on internet "crap". SPF seems much more likely to make a difference, and good luck getting secure DNS implemented in a significant number of domains.

SPF is for email, not *general* DNS operations like web browsing, ftp, etc. so it would have zero usage in DNS hijacking and actually might make it easier in some regards to send spam through a hijacked DNS server.

We already have authentication systems. Why should DNS, which every website uses, be doing something which only a tiny fraction of websites need?

Besides -- technology can't stop phishing. A combination of education, authentication and client software that can with 100% reliability inform the user whether authentication has happened is the answer. Authentication is by far the easiest problem of the three. Education is more or less impossible, and reliably informing users is next to impossible. (In a web browser, anyway. If you let websites display images and run active content, how do you stop them fooling a user, even a well educated one? How do you guarantee it's impossible to do so?)

Many phishing sites do offer authentication, just not to the place you thought. I've seen a couple that operate in MIM mode and they're growing in complexity as they try to avoid many of the new software applications that are out to catch them.Changing the way authentication happens from 2-factor to 3-factor is the only viable means for defeating most of the current phishing sites, but a slight expansion to some of the new MIM sites will be able to manage that as well. Then what? DNS is definitely not th

What it might take to bring about adoption would be a.sec TLD that only operates with DNSsec, and any other major security improvements. Banks and others might prefer to be associated with a domain that is secure from the beginning, spurring its adoption. This way the market place would decide since it would have a real choice.

What it might take to bring about adoption would be a.sec TLD that only operates with DNSsec

The thing is that this isn't really feasable, because you have to replace all the client software to make it work - and at that point you might as well mandate IPV6 with IPSEC.

Think about it: DNS is only as secure as its weakest link, and that link is the desktop. If your suggestion is implemented without making every desktop aware of the.sec TLD's requirement to use DNSsec, all an attacker has to do is convince

I know this is a rather stupid thing to be hung up on, but the referenced link (DNSsec.org [dnssec.org]) was so visually cluttered and ugly that I couldn't muster the desire to spend much time there.

Security is always harder to sell than most products, because you are usually trying to convince a customer to spend more time and money for something without out a tangiable return. (If my DNS hasn't been spoofed yet, why pay money? And even if they do secure it, they don't have an easy way to say: "this saved us X dollars this year, and thus was worth the investment")

Add in an "official" website which is hard to read, and painful on the eyes, and you've got a hard sell indeed. As petty as it sounds, a better web presence might help ease acceptance.

It's not an official site, though, just a compilation of DNSSEC information. It actually seems to be very comprehensive, obviously the compiler put a lot of effort into it. Maybe a bit crowded layout on the home page, yes, but lots of info. But here's the direct link to RFC 4033 [ietf.org] if that helps.

Bwahahahahahaha!I find Dan highly amusing, and would find a world without him a sadder place, but that's an opinion piece, without an iota of basis for any of the assertions he makes.

The one factoid he presents is the Microsoft ActiveX key spoof, which is indeed interesting. It also isn't addressed by his proposal, so I'm not sure what good it is. As for querying multiple servers to validate a lookup, that's a fun idea, but you still haven't cryptographically authenticated the information, and all it wo

I'm sure Dan is a nice guy, but his work (Qmail) has made me pull my long hair out by the handful. I prefer, that when I install stuff onto a UNIX machine, that the package I am installing doesn't EAT MY COMPUTER. Every time I've succombed to people's opinions about Qmail, and how great it is, and want to give it a try, I am again reminded that sendmail already works, is already installed, and already configured, and that I've just fucked up everything by installing Qmail. As an added bonus, qmail generates

"Not connected to the internet", then? BIND is notorious for remote root exploits. This by you is "okay"?

Do you mean BIND 8 or BIND 9? Looking at your google query, I see about four different hits that actually have to do with BIND, and they're all about BIND 8, and they are all the same root exploit, not four different root exploits. Along with them is a root exploit for tcpdump - are you proposing that we stop using tcpdump as well?

Seriously, if you want an open source name server, BIND 9 is an amazin

Bind 9 isn't crap, so there would be no reason for us to say it was. It's a fine product. Its target market is different than ours, that's all.Boo-hoo all you want about automated builds and patch distributions. I'm a big fan of keeping things simple. With BIND, I just install the.deb and I'm done. It takes about ten seconds, and it's exactly the same process as the other hundred or so packages I need on my server. A package that requires a special compile and a manual install had better be *hug

Unfortunately, he doesn't get things right very often, either. His programs are generally thought to be somewhat secure (only "somewhat" because he likes to blame found vulnerabilities on the underlying OS, which does jack all to actually fix the problem), but they tend to earn that reputation by only implementing small subsets of their respective protocols. A DNS server that won't sync to another isn't very useful to most people, but Da

Yeah, I used to be a lurker on comp.protocols.ntp, and it was a nice little traditional Usenet group. Everyone polite, informative, etc. Then, one day, this total asshole barges in and starts flaming the regulars. I mean, using profanity and everything. Of course, in ntpd, everything is done for a reason, and it's not perfect, but it's pretty damn good. He started railing on about some leap second issue, and wouldn't stop. Any post that pointed out his shortcomings was typically answered with a stream

From Computer Business Review: Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more.

So in the end, economics will drive SecDNS more than anything else. It seems like a good idea though for some institutions to go to a more secure DNS format. Let's face it: Fred's House of Flowers probably doesn't need as secure a domain as Citicorp or the CIA. The Internet ends up becoming a two-level affair, with the majority of sites being regular DNS sites and corporations and such using the more secure DNS setup.

If Fred's House of Flowers has your credit card info, and it's not secure, then it's the weak link in the chain, and it's the place where the attack will happen. I don't mean to say that in order for secure DNS to be useful, everyone has to use it, but certainly if it comes into widespread use and its use makes it a lot harder to spoof secured sites, then the sites that aren't secured are the ones that are going to get spoofed.

Fred's House of Flowers wouldn't be doing the credit card processing though. That would be done through a bank or e-commerce firm, and they would supposedly be using the more secure domain. If not, I doubt anybody would do business with them. Social and business pressure would start to force unwilling companies to switch to the more secure format.

The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.
The article says:

It's possible that a web surfer could think they are visiting their bank or an auction site and hand over their sensitive data, and it would be impossible to tell they were at a malicious site.

I disagree: there is a good way to tell if that is your bank you are talking to; check that they have the proper SSL certificate for their domain. Or better yet, just look at the color of the address bar in Firefox. If your bank isn't using SSL already, there are reasons far beyond DNS that they should be!
Also, even with SecDNS in place, physical man-in-the-middle or route poisoning attacks could intercept the communication at the IP level, making SecDNS marginally useful at best. In my opinion, the proper solution would be to encourage more widespread adoption of the existing SSL cert solution for services other than HTTPS. (e.g. SMTP, POP, FTP) Also, it would be good for the industry to have some additional certificate authorities with lower certification prices added to the major browsers' default trust list.

The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.

Once you've got a DNSSEC-enabled zone, you can put interesting things into it, like CERT RRs with SSH keys. The advantage is clear: you only pay for the delegation (the domain registration fee), and not for each server certificate individually.

Apart from the threat to existing CA business models, there are also some unsolved techn

SSL is helpful for some protocols, but not others. PKI via X.509 is also hard to deploy, and more complicated, and requires distribution of root certs in clients. And the user interface issueswith SSL in todays browsers is a whole 'nother topic....DNSSEC helps secure all DNS-based protocols, even those that couldn't adopt SSL/TLS.DKIM (DomainKeys Identified Mail) is the lastest case in point, and if adopted will help drive DNSSEC deployment since it relies on DNS to help stop spam etc.

Ah, but don't most Universities with wifi force you to VPN before you can access anything? You'd have to be a student to do it and you'd be logged anyway. At least my University is this way.On the other hand, there are various places around said University where you can plug in your cat5 and get to the Internet without VPN. Not the places where it's marked as OK to do so, mind you, mostly extra jacks in computer labs. I have a laptop but no wifi, and though I have no intention of doing anything illegal

The main problem with "secure DNS" is that you can't get it. This is because some of the problems remain unsolved - the problem of key rollover is currently generating a huge debate on the namedroppers mailing list, not the least because one of the proposals being advanced is patented.

On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g.,.com) isn't in a signed zone.

On top of that, many TLD providers seem to want signed zones to be a value-added option rather than basic functionality. So as with RSA, lo those many years ago, adoption will be slow because people want to monetize it, rather than seeing it as basic functionality that has to be there.

So it's no surprise that the end user isn't interested in it yet - they can't get it even if they are interested.

Yeah, I know, it's very cool, but all my domains are in the US. So I could register in.se, but it would look weird to my users. And it still requires installing the zone key for.se in any resolver that's going to securely resolve DNS entries in my zone, so it's actually not that useful yet. But it is a nice start - I hope more TLDs follow suit.

On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g.,.com) isn't in a signed zone.

FYI, there is at least some work being done on getting things signed by something other than your DNS parent. Look for the internet-drafts on "DLV" and the "lookaside" support in bind. It's unclear if this sort of work will a

Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed. It is really odd that so few people seem to care. It is kind of like putting a hundred dollar deadbolt on a screen door.

The only solution is either get secure DNS, or find a way to securly exchange keys out of band (rendering the point of x509 kind of moot)

Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed

Please explain.

SSL is designed to ensure that DNS spoofing will cause SSL authentication failure. An attacker needs to hijack the domain name and get a matching (signed, trusted) certificate for that domain name in order t

But it ultimately pretty much comes down to DNS. If I can receive email from a domain, I can generally get a cert for that domain. Pehaps not from your better certificate authorities, but have you looked at the number of CAs in your browsers CA cache? Have you tried getting certs from them? Some are much easier than others, but ALL are trusted equally and completely.As you say it is a problem of key management, but the way CAs do key management (distribution) today depends on DNS not being compromised.

All the browser does is make sure the strong cryptographically signed and verified cert's DN matches the totally insecure DNS lookup result.

Incorrect. The browser checks the certificate domain against the intended domain. The result of a DNS lookup is not part of the trust equation. This is the great thing about end-to-end security, everything else in the path doesn't even matter.

I agree that the way domains and certificates are purchased is ridiculous. For God's sake why are we still proving email addr

My mistake, that is actually how I intended to word it, and point out that we are only comparing against the intended domain, not the actual IP address we are connecting to. The lack of secure DNS means we get no assurance that the intended domain name is actually getting to the IP it is supposed to.

DNSSEC is just one piece in an overall risk management process. There are other pressing issues on the same list. As was posted already, until there is an attack that makes securing DNS an immediate issue for an organization or a country there will not be as much action toward it. It is common for risk management to focus on the threats of today and attacks of yesterday. We are wrapped up in the past and not looking at threats and attacks of tomorrow. This appears to be where we are with securing DNS.H

... even at very well managed sites. This recent paper [cornell.edu] from Cornell lays out some of the problem, showing how even the www.fbi.gov name can be hijacked by hacking in to seemingly completely unrelated servers, such as one of the name servers at telemail.net.

So for example, to hijack www.hsbc.com, you don't have to worry just about hsbc's name servers, com's name servers, and the root name servers. You also have to worry about the other servers that hsbc and com have deligated to, and the servers that they have deligated to, and on and on.

DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.

I'm not sure you've read the specs...

It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.

Like all security, you need a trust-anchor root. This is the same way that your browser has a list of trusted root CA certificates. DNSsec requires something similar: a list of keys for roots that you trust. It a can se

Wrong. You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be), not if you want to prove authority (that the resource is being generated by the correct host) or integrity (that the resource data hasn't been altered). Go read ISBN 0471117099 for practical algorithms if you like.

You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be)

true

not if you want to prove authority (that the resource is being generated by the correct host)

The resource can't be signed by an incorrect host (holder of a key; not a host) unless the key has been stolen or broken. Obviously, if you don't have a trust anchor then an attacker can generate any key it wants if you'll believe it. With a trust anchor, however, you won't believe it.

As you said, it should be no longer than the TTL. But in the real world there are some truely evil DNS implementations out there (Microsoft comes to mind) who choose not to follow standards, including not paying attention to TTL.

My own attitiude to people who accept and run such systems is simply "screw 'em". But you might want to be a little more caring than that...

What you can do is add your new MX records and leave the old ones in place, with a lower priority. Then just monitor the traffic to the ol

I saw an extreme example when I switched my MX record and months later received an email on my old mail server, which was still running but not pointed to by any public MX records. The email came from someone I knew at MetLife, and was sent via Lotus Notes. I kind of imagined Notes might be at fault, but I don't know what DNS servers MetLife uses.

I changed the IP address on a server and left the old one on for the changeover... checking the logs I found that people were still hitting the site *months* afterwards, usually the same ISPs. They might still be trying today.. the server is gone now.

It seems some ISPs not only ignore TTL, they aggressively cache so the first version of a domain they see is the one they always use, until someone complains.

The way I do it:- Configure a temp mailserver that forwards your companies email to the current MX- Change the MX records to point to this server- As the TTL expires and changed propogate you start seeing hits on your server. It still just forwards it to the old MX..- Verify the headers of the email you receive, you can see if it's delivered via your MX or not- When it seems all mail comes through your temp MX you either reconfigure it the way you want it or drop in a new one with the desired configThen you

The major stumbling block to adoption is that the current specification of DNSSEC requires NXT records

Unfortunately true, though you could delete all those records and be subject to name injection. The NXT records (actually called "NSEC" by the way not NXT) just protect against proof of non existence. There is a new version called NSEC3 which uses hashed names to get around the data leak.