Jeff, There are firewalls out there that consider traffic in and out of the *same* interface to be illegal and they deny it. Depending on your perspective and requirements, this is a good thing.
Also some firewalls require the traffic to pass-through to be NAT'd. If you don't have the same-interface issue above, you may have your traffic not pass through the NAT tables because it turns around and goes out the same interface before it hits the NAT tables. This is really getting in to Firewall design specifics. You'll need to dig deep with the doco for your firewall(s) and maybe even log a support case to get your answer. Good luck. Rob :-) _________________________________________________ It might look like I'm doing nothing, but on a cellular level, I'm quite busy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Buehler Sent: Sunday, February 24, 2008 4:02 AM To: xmail@xmailserver.org Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?) Hi Rob - That is more or less what is happening, but I'm not clear about the specifics. I'm finding it a bit of a mystery - the firewall does NAT, but the external DNS server trying to contact the internal server does so in the case of many other domains, so the firewall is properly configured for external queries - also, a dig dns1.buehlertech.net +trace works properly from the server (as does dns2.buehlertech.net which is on another public IP and behind a different router running PFSense) so dns1.buehlertech.com (and dns2.buehlertech.com) must be visible without difficulty to the external dns server. The server shouldn't really be trying to communicate with it's own public IP (itself), but rather the external dns server which then should simply return the public IP of the server doing the query, or so I would think, but I guess dig +trace has to literally dig all the way back to itself? Even then, why is the secondary dns, which works and is on an entirely separate network, not stepping in? Also, if I do a "dig trikorausa.com +trace" from my secondary server (dns2.buehlertech.net) it works fine. Perhaps the PFSense router is handling the query and NAT properly and the m0n0wall router is not? At this point to me it is some sort of voodoo dns issue (and here I am without any animal sacrifice to offer it), but it isn't causing me any real headaches since SmartDns works. I will look more closely at NAT, though, as I suspect you are right that it is at the center of the issue somehow - it simply redirect inbound requests to port 53 of the server in question, nothing complex. I still need to look at the other external cases, but I have a feeling that there will be some misconfigured DNS or other problems in those cases. It also does not sound like an XMail issue anymore either, so my apologies for continuing on here. I will post a final time if I find out what is going on simply for the sake of posterity! Thanks, Jeff Rob Arends wrote: > This will be a fault where the world uses you public IP to access your zone > hosted on your server, but when your server tries to resolve > dns1.buehlertech.net it is not contactable (probably because of NAT on a > firewall) and so tries dns2.buehlertech.net, but it is also not contactable. > Then it goes back to the root to try again, but of course there is no way > you can talk to yourself via a public IP. > > I may have got a little bit of the process wrong, but in essence it is > correct. > If anyone can talk to you, but you can't talk to you, then it will be NAT. > > Try BIND views, or hosting on a different server, or allowing dns resolution > from 127.0.0.1, then pointing resolv.conf to 127.0.0.1 > > > Rob :-) > > _________________________________________________ > It might look like I'm doing nothing, but on a cellular level, I'm quite > busy. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Jeff Buehler > Sent: Saturday, February 23, 2008 11:36 AM > To: xmail@xmailserver.org > Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report ed > earlier?) > > Hi Davide - > > Sorry about the delay on this - I was in away yesterday and today... > > Here is a sample of the dig + trace - I copied only the last two entries > - basically this pattern is repeated until the "too many lookups" > result. The other domains this server is authoritative for produce the > same result except for buehlertech.net and buehlertech.com which work > fine. The only differences I can think of is the reverse points to > buehlertech.net and the domain is buehlertech.net in resolv.conf and in > the hosts file (but why would buehlertech.com work?). > > ;; Received 117 bytes from 192.5.6.30#53(a.gtld-servers.net) in 126 ms > > com. 21365 IN NS e.gtld-servers.net. > com. 21365 IN NS f.gtld-servers.net. > com. 21365 IN NS g.gtld-servers.net. > com. 21365 IN NS h.gtld-servers.net. > com. 21365 IN NS i.gtld-servers.net. > com. 21365 IN NS j.gtld-servers.net. > com. 21365 IN NS k.gtld-servers.net. > com. 21365 IN NS l.gtld-servers.net. > com. 21365 IN NS m.gtld-servers.net. > com. 21365 IN NS a.gtld-servers.net. > com. 21365 IN NS b.gtld-servers.net. > com. 21365 IN NS c.gtld-servers.net. > com. 21365 IN NS d.gtld-servers.net. > ;; Received 504 bytes from 67.102.108.82#53(dns1.buehlertech.net) in 68 ms > > trikorausa.com. 172800 IN NS dns1.buehlertech.net. > trikorausa.com. 172800 IN NS dns2.buehlertech.net. > ;; Received 117 bytes from 192.12.94.30#53(e.gtld-servers.net) in 93 ms > > com. 21365 IN NS c.gtld-servers.net. > com. 21365 IN NS d.gtld-servers.net. > com. 21365 IN NS e.gtld-servers.net. > com. 21365 IN NS f.gtld-servers.net. > com. 21365 IN NS g.gtld-servers.net. > com. 21365 IN NS h.gtld-servers.net. > com. 21365 IN NS i.gtld-servers.net. > com. 21365 IN NS j.gtld-servers.net. > com. 21365 IN NS k.gtld-servers.net. > com. 21365 IN NS l.gtld-servers.net. > com. 21365 IN NS m.gtld-servers.net. > com. 21365 IN NS a.gtld-servers.net. > com. 21365 IN NS b.gtld-servers.net. > ;; Received 504 bytes from 67.102.108.82#53(dns1.buehlertech.net) in 54 ms > > trikorausa.com. 172800 IN NS dns1.buehlertech.net. > trikorausa.com. 172800 IN NS dns2.buehlertech.net. > dig: too many lookups > > > Jeff > > Davide Libenzi wrote: > >> On Thu, 21 Feb 2008, Jeff Buehler wrote: >> >> >> >>> By the way, the trace does, and always has, produced the correct name >>> servers (dns1.buehlertech.net and dns2.buehlertech.net), it just >>> continues to trace after that result. >>> >>> >> Do they set the correct AUTHORITY bit in the answer? >> >> >> >> - Davide >> >> >> - >> To unsubscribe from this list: send the line "unsubscribe xmail" in >> the body of a message to [EMAIL PROTECTED] >> For general help: send the line "help" in the body of a message to >> [EMAIL PROTECTED] >> >> >> > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] > > - > To unsubscribe from this list: send the line "unsubscribe xmail" in > the body of a message to [EMAIL PROTECTED] > For general help: send the line "help" in the body of a message to > [EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
