Exchange 2003, Google DNS, and IMF Connection Filtering RBL Failures
|
From: ObiWan [MVP] on 29 Dec 2009 05:12 > One more thing to add to this discussion is that you can configure the > Exchange Virtual SMTP Server to use a different DNS than the rest of > the system uses. if you'll be using an external "public" resolver like OpenDNS, Google or whatever else, you may face the same issues I described elsewhere in this thread, that is, long cache retention causing false positives *and* rate limiting causing NXDOMAIN answers bottom line... do NOT use forwarders; it makes NO sense when you have your own DNS; it's like having a car, keeping it with the engine on but then hitchhicking instead of using your own car (which will be still parked there with the engine working) :P
From: Ace Fekay [MCT] on 29 Dec 2009 07:38 "Chucko" <chucko(a)myrealbox.com> wrote in message news:%23Y2RcREiKHA.3792(a)TK2MSFTNGP02.phx.gbl... > One more thing to add to this discussion is that you can configure the > Exchange Virtual SMTP Server to use a different DNS than the rest of the > system uses. > > You can find that configuration tab under default SMTP Virtual Server > Properties, Delivery, Advanced, Configure. > > That way you can use DNS servers that provide the proper NXDOMAIN response > for the SMTP mail traffic and something like Open DNS for the Server and > Workstations. That is how I normally set it up. I was trying out and > testing the Google DNS servers for SMTP traffic and that is how I found > out about the initial problem. > As I have mentioned in the post above.:-) Ace
From: Ace Fekay [MCT] on 29 Dec 2009 07:40 "ObiWan [MVP]" <obiwan(a)mvps.org> wrote in message news:O%23vR$9GiKHA.5020(a)TK2MSFTNGP02.phx.gbl... >> One more thing to add to this discussion is that you can configure the >> Exchange Virtual SMTP Server to use a different DNS than the rest of >> the system uses. > > if you'll be using an external "public" resolver like OpenDNS, Google > or whatever else, you may face the same issues I described elsewhere > in this thread, that is, long cache retention causing false positives > *and* > rate limiting causing NXDOMAIN answers > > bottom line... do NOT use forwarders; it makes NO sense when you > have your own DNS; it's like having a car, keeping it with the engine > on but then hitchhicking instead of using your own car (which will be > still parked there with the engine working) :P > > > Some of the only reasons I would see using a forwarder, which I configure my customers for, is to offload the recursion process, or to bypass a firewall that doesn't support EDNS0 or that an admin is unaware of how to update the firewall to allow that type of traffic. Ace
From: Ace Fekay [MCT] on 29 Dec 2009 07:43 "ObiWan [MVP]" <obiwan(a)mvps.org> wrote in message news:%23RPzd7GiKHA.4220(a)TK2MSFTNGP05.phx.gbl... > >> We block all DNS queries from all nodes except the DNS server - >> that would be the SBS box itself. > > good setup, ensure to do the same for SMTP too :) > >> Interesting question - SBS and a separate Terminal Server using Open >> DNS for web site filtering. > > uhm... let me understand, you have two servers, one is running sbs > and has its own DNS server w/o any forwarder, another one is used > as a TS and its network settings are configured so that the DNS IPs > point to OpenDNS ? That's totally crazy imHo :( it would badly screw > the AD > >> Since the forwarders have to use ODNS's DNS servers, how would >> you have SBS not be seen as originating from ODNS when doing >> RBL checks while still using ODNS for web blocking? > > you have TWO solutions > > the first one (which I prefer) is to setup a DNS server on the TS, > ensure the TS DNS has a copy of the local AD zones and then > configure it to use ODNS forwarder, next setup the TS machine > to use its own IP as the DNS; this way the SBS box won't be > using OpenDNS while the TS will > > the second one is... pointing both SBS and TS to the SBS DNS > then configuring conditional forwarding on the SBS DNS so that > queries directed to the DNSBL in use will go straight to the auth > servers for those domains while all other queries will be forwarded > to the OpenDNS servers > > in spamhaus case, the DNS can be obtained by running > > nslookup -type=NS spamhaus.org > > the same goes for the DNS for all the other DNSBL zones you > are using in IMF but, again, I'd prefer the first solution since this > one would force you to keep your DNS up-to-date whenever > you'll change the DNSBLs you use > I was thinking on how to respond to this one yesterday. I think your option #1 is the better solution. IMHO, I wouldn't use ODNS and simply use the IMF for Exchange, and use a firewall that supports Websense or use ISA. Ace
From: Ace Fekay [MCT] on 29 Dec 2009 07:47
"ObiWan [MVP]" <obiwan(a)mvps.org> wrote in message news:eLf1y1GiKHA.2132(a)TK2MSFTNGP05.phx.gbl... >> In summary, the link indicates the service is free unless (quoted): >> >> 1. Your use of the Spamhaus DNSBLs is non-commercial*, and >> 2. Your email traffic is less than 100,000 SMTP connections per day, > and >> 3. Your DNSBL query volume is less than 300,000 queries per day. > > exactly, now, since the spamhaus DNS servers only see the IP of > the querying box, in case your DNS is using the OpenDNS servers > as forwarders, the spamhaus DNS will see the IPs of the OpenDNS > servers since the query "chain" will be > > exchange IMF <-> your DNS <-> OpenDNS <-> spamhaus DNS > > now, the above means that anyone using the same config will be > seen by the spamhaus DNS with the SAME IP, so even a bunch > of low traffic email servers may quickly go above the allowed > spamhaus query rate (as seen above) and this in turn would > result in NXDOMAIN answers being returned by the spamhaus > DNS servers and btw the same (rate limit) issue is also true for > most/all other DNSBLs not just for spamhaus No kidding. I didn't think of this scenario. So the rate limit could be quickly reached and everyone is blaming ODNS for it. Well, it is ODNS fault, only because all of the queries are eminating from ODNS. > > bottom line, if one has a DNS server, better using it and not > some external forwarder (set aside the exceptions I listed > into another post in this same thread) since such a setup > will avoid a lot of troubles ... and since with such a setup > YOU will be back in control of YOUR DNS resolution :) True, eliminating the single point query scenario of ODNS to the DNSBLs. Ace |