Re: Multiple DNS implementations vulnerable to cache poisoning
As the advisory says, IronPort is not vulnerable to this problem.
However if you are using an upstream DNS server (rather than using the "root servers") and that upstream server (or it's upstream, etc) is vulnerable to this problem then it's still possible for your IronPort receive invalid data.
So please, if you're using an upstream DNS server please check with your ISP or whoever provides it to make sure that they are taking the relevant precautions to make sure they are not are vulnerable to this problem.
You can do a basic test to check if your upstream servers are vulnerable by running the following from your IronPort : myironport> nslookup porttest.dns-oarc.net txt
TXT="126.96.36.199 is GOOD: 26 queries in 155.3 seconds from 26 ports with std dev 14911.47" TTL=30m
If you get a POOR or FAIR then it means you've got a problem. If you get a GOOD it means that the last DNS server in the chain is OK, but any in the middle could still be vulnerable.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...