[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
In order to solve the problem of internal network machines reaching other internal machines using their external address on linux firewalls that I have installed that use IPTables I've had to create a NAT rule that remaps the source address to that of the firewall's internal address. The command is: iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -d 192.168.0.0/255.255.255.0 -p tcp -m tcp -m multiport --dports smtp,http,pop3,https -j SNAT --to-source 192.168.0.1 Which says if the traffic source is the internal network and the destination is the internal network and the destination ports are smtp,http,pop3 or https then make the source address the firewalls internal address. This is in the postrouting chain because the prerouting chain has already changed the packets external destination into an internal address when it first hit the firewall rules. So what happens is that the packet is then passed off to the internal server you are trying to reach, the response goes back to the firewall because of the source address translation and then the firewall redirects the packet back to the original source. I didn't figure this out myself, years ago I googled until I found the answer and have been using it ever since. Maybe you can find the equivalent rule for m0n0wall. Packet flow diagram time: internal server sends to external address (of destination internal server) firewall rules applied that change destination to internal address packet becomes internal server address to internal address of destination internal server if you stopped here the destination server would try and respond back to the source directly, not who it was trying to talk to, so: Firewall remaps source of packet to itself and remembers who the real source is firewall internal address sends to internal address of destination internal server Internal server responds to firewall internal address firewall remaps packet destination address back to the original source and passes it on and everyone is happy! Hope this helps. Bill >-- >From: Rob Arends[SMTP:[EMAIL PROTECTED] >Sent: Sunday, February 24, 2008 4:59 AM >To:xmail@xmailserver.org >Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report >ed >earlier?) > >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
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
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?). > > ;; Rece
[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#
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
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]
[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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
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. Jeff Jeff Buehler wrote: > Hi Clement - > > Yes - that is the setup, and the m0n0wall provides NAT to the servers > services. > > dig @localhost (or serving LAN ip) triokorausa.com +trace produces the > same "dig: too many lookups" error as does the dig @external-dns > trikorausa.com +trace. Which also seems odd to me, but I have a strange > feeling that it is the correct (to be expected) behavior, even if it is > undesirable in this case. Or perhaps a recent update to FreeBSD is > causing a problem? > > Jeff > > CLEMENT Francis wrote: > >> Hey Jeff >> >> Seams I did not understood all of your dns server setup. >> I thinked you dns only returned a list of NS for the domains it is >> autoritive. >> Sorry :) >> >> Another possibility :) : >> Just in case there is a problem with natted loop-back at monowall = >> router >> >> I suppose you have this physical hardware setup (correct if wrong) : >> >> Internet <-> MonoWall <-> 'autoritive only' dns server ;) / xmail = >> server >> >> Is it this ? >> >> Does the interface between Monowall and dns/xmail server do NAT ? >> >> If NATTED servers : >> >> What does a dig from the dns/xmail server to itself using its internal = >> ip >> address ? >> dig @internal-dns-server-ip-address trikorausa.com +trace >> >> And a dig from the xmail server using the External ip address of the = >> dns >> server (so the Monowall external ip) ? >> dig @monowall-external-internet-ip trikorausa.com +trace >> >> Francis >> >> >> >> >> -Message d'origine- >> De : [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] la part de Jeff Buehler >> Envoy=E9 : jeudi 21 f=E9vrier 2008 17:12 >> =C0 : xmail@xmailserver.org >> Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = >> ed >> earlier?) >> >> >> I should also clarify, as you mention users, that none of this has=20 >> anything to do with users on a LAN. This is a hosting server providing = >> >> web services and email, along with some other functionality. The issue = >> >> at question is how this particular server sees domains that are = >> external=20 >> to it. It has no way of knowing about yahoo.com or hotmail.com without = >> >> a name server that provides recursive lookups, so I have assigned it a=20 >> name server that does. It just so happens that in the case of this one = >> >> domain (trikorausa.com) this server provides the authoritative DNS (A=20 >> records, MX records, etc.). There is no way (that I know about) for me = >> >> to have it query itself just for domains it knows about, then query=20 >> external dns for everything else. >> >> Thanks again, >> Jeff >> >> Jeff Buehler wrote: >> >> >>> Hi Clement - >>> >>> Perhaps I am using the wrong semantics, or perhaps I am not = >>> >>> >> completely=20 >> >> >>> understanding you, or possibly I am doing something wrong (even = >>> >>> >> thought=20 >> >> >>> I have been doing it this way more or less for about 10 years!). = >>> >>> >> This=20 >> >> >>> server provides (what I understand to be) true authoritative name=20 >>> resolution for about 60 domains and ONLY those 60 domains, but = >>> >>> >> provides=20 >> >> >>> no recursive lookups nor any caching - no systems on the LAN query = >>> >>> >> it,=20 >> >> >>> or any other server I provide locally, for DNS resolution. It is = >>> >>> >> simply=20 >> >> >>> queried by external caching DNS servers on the net for name = >>> >>> >> resolution=20 >> >> >>> of a small number of domains. I do provide complete zone content for = >>> >>> >> >> >>> these domains, but not for other domains such as yahoo.com = >>> >>> >> (obviously)=20 >> >> >>> which need to be queried elsewhere as no caching is being done
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
Hi Clement - Yes - that is the setup, and the m0n0wall provides NAT to the servers services. dig @localhost (or serving LAN ip) triokorausa.com +trace produces the same "dig: too many lookups" error as does the dig @external-dns trikorausa.com +trace. Which also seems odd to me, but I have a strange feeling that it is the correct (to be expected) behavior, even if it is undesirable in this case. Or perhaps a recent update to FreeBSD is causing a problem? Jeff CLEMENT Francis wrote: > Hey Jeff > > Seams I did not understood all of your dns server setup. > I thinked you dns only returned a list of NS for the domains it is > autoritive. > Sorry :) > > Another possibility :) : > Just in case there is a problem with natted loop-back at monowall = > router > > I suppose you have this physical hardware setup (correct if wrong) : > > Internet <-> MonoWall <-> 'autoritive only' dns server ;) / xmail = > server > > Is it this ? > > Does the interface between Monowall and dns/xmail server do NAT ? > > If NATTED servers : > > What does a dig from the dns/xmail server to itself using its internal = > ip > address ? > dig @internal-dns-server-ip-address trikorausa.com +trace > > And a dig from the xmail server using the External ip address of the = > dns > server (so the Monowall external ip) ? > dig @monowall-external-internet-ip trikorausa.com +trace > > Francis > > > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la part de Jeff Buehler > Envoy=E9 : jeudi 21 f=E9vrier 2008 17:12 > =C0 : xmail@xmailserver.org > Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = > ed > earlier?) > > > I should also clarify, as you mention users, that none of this has=20 > anything to do with users on a LAN. This is a hosting server providing = > > web services and email, along with some other functionality. The issue = > > at question is how this particular server sees domains that are = > external=20 > to it. It has no way of knowing about yahoo.com or hotmail.com without = > > a name server that provides recursive lookups, so I have assigned it a=20 > name server that does. It just so happens that in the case of this one = > > domain (trikorausa.com) this server provides the authoritative DNS (A=20 > records, MX records, etc.). There is no way (that I know about) for me = > > to have it query itself just for domains it knows about, then query=20 > external dns for everything else. > > Thanks again, > Jeff > > Jeff Buehler wrote: > >> Hi Clement - >> >> Perhaps I am using the wrong semantics, or perhaps I am not = >> > completely=20 > >> understanding you, or possibly I am doing something wrong (even = >> > thought=20 > >> I have been doing it this way more or less for about 10 years!). = >> > This=20 > >> server provides (what I understand to be) true authoritative name=20 >> resolution for about 60 domains and ONLY those 60 domains, but = >> > provides=20 > >> no recursive lookups nor any caching - no systems on the LAN query = >> > it,=20 > >> or any other server I provide locally, for DNS resolution. It is = >> > simply=20 > >> queried by external caching DNS servers on the net for name = >> > resolution=20 > >> of a small number of domains. I do provide complete zone content for = >> > > >> these domains, but not for other domains such as yahoo.com = >> > (obviously)=20 > >> which need to be queried elsewhere as no caching is being done. >> >> My understanding is that a DNS server generally should not provide=20 >> recursive lookups and caching while also providing authoritative=20 >> resolution of domains for security reasons. This at least is a=20 >> recommendation made by Dan Bernstein (author of Tiny DNS) and makes=20 >> sense to me - Bind and MS systems allow it, but it is probably not a=20 >> good idea. >> >> Am I missing something? Thanks for your input ... >> >> Jeff >> >> > - > 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
Hey Jeff Seams I did not understood all of your dns server setup. I thinked you dns only returned a list of NS for the domains it is autoritive. Sorry :) Another possibility :) : Just in case there is a problem with natted loop-back at monowall = router I suppose you have this physical hardware setup (correct if wrong) : Internet <-> MonoWall <-> 'autoritive only' dns server ;) / xmail = server Is it this ? Does the interface between Monowall and dns/xmail server do NAT ? If NATTED servers : What does a dig from the dns/xmail server to itself using its internal = ip address ? dig @internal-dns-server-ip-address trikorausa.com +trace And a dig from the xmail server using the External ip address of the = dns server (so the Monowall external ip) ? dig @monowall-external-internet-ip trikorausa.com +trace Francis -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Jeff Buehler Envoy=E9 : jeudi 21 f=E9vrier 2008 17:12 =C0 : xmail@xmailserver.org Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = ed earlier?) I should also clarify, as you mention users, that none of this has=20 anything to do with users on a LAN. This is a hosting server providing = web services and email, along with some other functionality. The issue = at question is how this particular server sees domains that are = external=20 to it. It has no way of knowing about yahoo.com or hotmail.com without = a name server that provides recursive lookups, so I have assigned it a=20 name server that does. It just so happens that in the case of this one = domain (trikorausa.com) this server provides the authoritative DNS (A=20 records, MX records, etc.). There is no way (that I know about) for me = to have it query itself just for domains it knows about, then query=20 external dns for everything else. Thanks again, Jeff Jeff Buehler wrote: > Hi Clement - > > Perhaps I am using the wrong semantics, or perhaps I am not = completely=20 > understanding you, or possibly I am doing something wrong (even = thought=20 > I have been doing it this way more or less for about 10 years!). = This=20 > server provides (what I understand to be) true authoritative name=20 > resolution for about 60 domains and ONLY those 60 domains, but = provides=20 > no recursive lookups nor any caching - no systems on the LAN query = it,=20 > or any other server I provide locally, for DNS resolution. It is = simply=20 > queried by external caching DNS servers on the net for name = resolution=20 > of a small number of domains. I do provide complete zone content for = > these domains, but not for other domains such as yahoo.com = (obviously)=20 > which need to be queried elsewhere as no caching is being done. > > My understanding is that a DNS server generally should not provide=20 > recursive lookups and caching while also providing authoritative=20 > resolution of domains for security reasons. This at least is a=20 > recommendation made by Dan Bernstein (author of Tiny DNS) and makes=20 > sense to me - Bind and MS systems allow it, but it is probably not a=20 > good idea. > > Am I missing something? Thanks for your input ... > > Jeff > - 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
I should also clarify, as you mention users, that none of this has anything to do with users on a LAN. This is a hosting server providing web services and email, along with some other functionality. The issue at question is how this particular server sees domains that are external to it. It has no way of knowing about yahoo.com or hotmail.com without a name server that provides recursive lookups, so I have assigned it a name server that does. It just so happens that in the case of this one domain (trikorausa.com) this server provides the authoritative DNS (A records, MX records, etc.). There is no way (that I know about) for me to have it query itself just for domains it knows about, then query external dns for everything else. Thanks again, Jeff Jeff Buehler wrote: > Hi Clement - > > Perhaps I am using the wrong semantics, or perhaps I am not completely > understanding you, or possibly I am doing something wrong (even thought > I have been doing it this way more or less for about 10 years!). This > server provides (what I understand to be) true authoritative name > resolution for about 60 domains and ONLY those 60 domains, but provides > no recursive lookups nor any caching - no systems on the LAN query it, > or any other server I provide locally, for DNS resolution. It is simply > queried by external caching DNS servers on the net for name resolution > of a small number of domains. I do provide complete zone content for > these domains, but not for other domains such as yahoo.com (obviously) > which need to be queried elsewhere as no caching is being done. > > My understanding is that a DNS server generally should not provide > recursive lookups and caching while also providing authoritative > resolution of domains for security reasons. This at least is a > recommendation made by Dan Bernstein (author of Tiny DNS) and makes > sense to me - Bind and MS systems allow it, but it is probably not a > good idea. > > Am I missing something? Thanks for your input ... > > Jeff > > CLEMENT Francis wrote: > >> As an autoritive dns, why do you want your internal network to go to = >> the >> 'external' dns servers >> An autoritive dns server for a zone is ONLY one of the NS listed, and = >> theses >> NS roles suppose they have a full copy of the zone content. >> As many election algorythms will sort the ns entries to place the = >> 'locals' >> (network point of vue) as the preferred to ask first, your 'internal >> autoritive' that does not have all of the zone will surely be elected ! >> >> Then, the local computer electing to use you 'false autoritive server', = >> that >> is online and response to dns queries even if not the desirable good >> responses from user point of vue, but a 'good' response at dns protocol >> point of vue, why do you want them to 'change' and switch to the = >> 'external >> true autoritive servers' ? >> A tcpdump for dns traffic on your local network could show that for DOM >> domain almost all the queries are send to you 'false autoritive = >> server'. >> >> Best way to resolve this issue : >> - Don't use any 'internal dns server' for this zone at all >> or >> - Give your internal dns server the complete zone content to become a = >> true >> autoritive dns server for the zone :) >> (Notice that doing so if your local dns is behind a nat server, you = >> could >> face a commom 'nat firewall' loopback issue. I can explain if you want) >> >> Francis >> >> >> -Message d'origine- >> De : [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] la part de Jeff Buehler >> Envoy=E9 : mercredi 20 f=E9vrier 2008 20:35 >> =C0 : xmail@xmailserver.org >> Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = >> ed >> earlier?) >> >> >> Hi Davide - >> >> Yes, it works from an external line, but not from the server itself. I = >> >> am trying to figure out why providing the authoritative DNS for that=20 >> domain (pointing to another server on the net which provides everything = >> >> else for the domain) causes the failure - it seems to be looping, which = >> >> might be expected behavior, but I'm not certain. At this point since = >> it=20 >> works with SmartDNS it is mostly curiosity. >> >> Jeff >> >> - >> 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
Hi Clement - Perhaps I am using the wrong semantics, or perhaps I am not completely understanding you, or possibly I am doing something wrong (even thought I have been doing it this way more or less for about 10 years!). This server provides (what I understand to be) true authoritative name resolution for about 60 domains and ONLY those 60 domains, but provides no recursive lookups nor any caching - no systems on the LAN query it, or any other server I provide locally, for DNS resolution. It is simply queried by external caching DNS servers on the net for name resolution of a small number of domains. I do provide complete zone content for these domains, but not for other domains such as yahoo.com (obviously) which need to be queried elsewhere as no caching is being done. My understanding is that a DNS server generally should not provide recursive lookups and caching while also providing authoritative resolution of domains for security reasons. This at least is a recommendation made by Dan Bernstein (author of Tiny DNS) and makes sense to me - Bind and MS systems allow it, but it is probably not a good idea. Am I missing something? Thanks for your input ... Jeff CLEMENT Francis wrote: > As an autoritive dns, why do you want your internal network to go to = > the > 'external' dns servers > An autoritive dns server for a zone is ONLY one of the NS listed, and = > theses > NS roles suppose they have a full copy of the zone content. > As many election algorythms will sort the ns entries to place the = > 'locals' > (network point of vue) as the preferred to ask first, your 'internal > autoritive' that does not have all of the zone will surely be elected ! > > Then, the local computer electing to use you 'false autoritive server', = > that > is online and response to dns queries even if not the desirable good > responses from user point of vue, but a 'good' response at dns protocol > point of vue, why do you want them to 'change' and switch to the = > 'external > true autoritive servers' ? > A tcpdump for dns traffic on your local network could show that for DOM > domain almost all the queries are send to you 'false autoritive = > server'. > > Best way to resolve this issue : > - Don't use any 'internal dns server' for this zone at all > or > - Give your internal dns server the complete zone content to become a = > true > autoritive dns server for the zone :) > (Notice that doing so if your local dns is behind a nat server, you = > could > face a commom 'nat firewall' loopback issue. I can explain if you want) > > Francis > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la part de Jeff Buehler > Envoy=E9 : mercredi 20 f=E9vrier 2008 20:35 > =C0 : xmail@xmailserver.org > Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = > ed > earlier?) > > > Hi Davide - > > Yes, it works from an external line, but not from the server itself. I = > > am trying to figure out why providing the authoritative DNS for that=20 > domain (pointing to another server on the net which provides everything = > > else for the domain) causes the failure - it seems to be looping, which = > > might be expected behavior, but I'm not certain. At this point since = > it=20 > works with SmartDNS it is mostly curiosity. > > Jeff > > - > 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
As an autoritive dns, why do you want your internal network to go to = the 'external' dns servers An autoritive dns server for a zone is ONLY one of the NS listed, and = theses NS roles suppose they have a full copy of the zone content. As many election algorythms will sort the ns entries to place the = 'locals' (network point of vue) as the preferred to ask first, your 'internal autoritive' that does not have all of the zone will surely be elected ! Then, the local computer electing to use you 'false autoritive server', = that is online and response to dns queries even if not the desirable good responses from user point of vue, but a 'good' response at dns protocol point of vue, why do you want them to 'change' and switch to the = 'external true autoritive servers' ? A tcpdump for dns traffic on your local network could show that for DOM domain almost all the queries are send to you 'false autoritive = server'. Best way to resolve this issue : - Don't use any 'internal dns server' for this zone at all or - Give your internal dns server the complete zone content to become a = true autoritive dns server for the zone :) (Notice that doing so if your local dns is behind a nat server, you = could face a commom 'nat firewall' loopback issue. I can explain if you want) Francis -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Jeff Buehler Envoy=E9 : mercredi 20 f=E9vrier 2008 20:35 =C0 : xmail@xmailserver.org Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem report = ed earlier?) Hi Davide - Yes, it works from an external line, but not from the server itself. I = am trying to figure out why providing the authoritative DNS for that=20 domain (pointing to another server on the net which provides everything = else for the domain) causes the failure - it seems to be looping, which = might be expected behavior, but I'm not certain. At this point since = it=20 works with SmartDNS it is mostly curiosity. Jeff - 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
Hi Davide - Yes, it works from an external line, but not from the server itself. I am trying to figure out why providing the authoritative DNS for that domain (pointing to another server on the net which provides everything else for the domain) causes the failure - it seems to be looping, which might be expected behavior, but I'm not certain. At this point since it works with SmartDNS it is mostly curiosity. Jeff Davide Libenzi wrote: > On Wed, 20 Feb 2008, Jeff Buehler wrote: > > >> OK, just to add to my confusion, here is part of what is going on - this >> server also provides the authoritative DNS for trikorausa.com (but not >> local DNS queries or caching!). It does not provide any other services >> for trikorausa.com (no email etc.) - the records point to an outside >> address. If I do a "dig @an-external-dns-server trikorausa.com +trace" >> I still get a "dig: Too many lookups" error. Does that make sense - is >> it looping? It seems like it should work - the external primary DNS >> knows the server doing the dig provides the authoritative DNS, shouldn't >> it simply trace back to it and stop? Essentially the server is simply >> doing a trace from an external DNS server back to itself. If I do a dig >> using ANY dns server from the server that provides the authoritative DNS >> for this domain I get the same result. As Davide reported if I do a dig >> to trikorausa.com from an outside line the trace is fine and does not fail. >> >> Also I don't know what the story is with the other domains - I only have >> client reports at this point about unexpected failures. Also, three >> weeks ago I was able to send email to trikorausa.com without the >> "nxdomain" error. >> > > From here it works just fine: > > > [EMAIL PROTECTED]:~$ dig trikorausa.com mx +trace > > ; <<>> DiG 9.4.2 <<>> trikorausa.com mx +trace > ;; global options: printcmd > ... 324708 IN NS J.ROOT-SERVERS.NET. > ... 324708 IN NS K.ROOT-SERVERS.NET. > ... 324708 IN NS L.ROOT-SERVERS.NET. > ... 324708 IN NS M.ROOT-SERVERS.NET. > ... 324708 IN NS A.ROOT-SERVERS.NET. > ... 324708 IN NS B.ROOT-SERVERS.NET. > ... 324708 IN NS C.ROOT-SERVERS.NET. > ... 324708 IN NS D.ROOT-SERVERS.NET. > ... 324708 IN NS E.ROOT-SERVERS.NET. > ... 324708 IN NS F.ROOT-SERVERS.NET. > ... 324708 IN NS G.ROOT-SERVERS.NET. > ... 324708 IN NS H.ROOT-SERVERS.NET. > ... 324708 IN NS I.ROOT-SERVERS.NET. > ;; Received 428 bytes from 10.107.17.218#53(10.107.17.218) in 0 ms > > com.172800 IN NS D.GTLD-SERVERS.NET. > com.172800 IN NS F.GTLD-SERVERS.NET. > com.172800 IN NS B.GTLD-SERVERS.NET. > com.172800 IN NS E.GTLD-SERVERS.NET. > com.172800 IN NS H.GTLD-SERVERS.NET. > com.172800 IN NS M.GTLD-SERVERS.NET. > com.172800 IN NS K.GTLD-SERVERS.NET. > com.172800 IN NS C.GTLD-SERVERS.NET. > com.172800 IN NS I.GTLD-SERVERS.NET. > com.172800 IN NS J.GTLD-SERVERS.NET. > com.172800 IN NS L.GTLD-SERVERS.NET. > com.172800 IN NS A.GTLD-SERVERS.NET. > com.172800 IN NS G.GTLD-SERVERS.NET. > ;; Received 492 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 127 ms > > trikorausa.com. 172800 IN NS dns1.buehlertech.net. > trikorausa.com. 172800 IN NS dns2.buehlertech.net. > ;; Received 117 bytes from 192.43.172.30#53(I.GTLD-SERVERS.NET) in 197 ms > > trikorausa.com. 43200 IN MX 10 mail.trikorausa.com. > trikorausa.com. 43200 IN NS dns1.buehlertech.net. > trikorausa.com. 43200 IN NS dns2.buehlertech.net. > ;; Received 154 bytes from 69.12.155.168#53(dns2.buehlertech.net) in 35 ms > > > > > - 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
On Wed, 20 Feb 2008, Jeff Buehler wrote: > OK, just to add to my confusion, here is part of what is going on - this > server also provides the authoritative DNS for trikorausa.com (but not > local DNS queries or caching!). It does not provide any other services > for trikorausa.com (no email etc.) - the records point to an outside > address. If I do a "dig @an-external-dns-server trikorausa.com +trace" > I still get a "dig: Too many lookups" error. Does that make sense - is > it looping? It seems like it should work - the external primary DNS > knows the server doing the dig provides the authoritative DNS, shouldn't > it simply trace back to it and stop? Essentially the server is simply > doing a trace from an external DNS server back to itself. If I do a dig > using ANY dns server from the server that provides the authoritative DNS > for this domain I get the same result. As Davide reported if I do a dig > to trikorausa.com from an outside line the trace is fine and does not fail. > > Also I don't know what the story is with the other domains - I only have > client reports at this point about unexpected failures. Also, three > weeks ago I was able to send email to trikorausa.com without the > "nxdomain" error. >From here it works just fine: [EMAIL PROTECTED]:~$ dig trikorausa.com mx +trace ; <<>> DiG 9.4.2 <<>> trikorausa.com mx +trace ;; global options: printcmd .. 324708 IN NS J.ROOT-SERVERS.NET. .. 324708 IN NS K.ROOT-SERVERS.NET. .. 324708 IN NS L.ROOT-SERVERS.NET. .. 324708 IN NS M.ROOT-SERVERS.NET. .. 324708 IN NS A.ROOT-SERVERS.NET. .. 324708 IN NS B.ROOT-SERVERS.NET. .. 324708 IN NS C.ROOT-SERVERS.NET. .. 324708 IN NS D.ROOT-SERVERS.NET. .. 324708 IN NS E.ROOT-SERVERS.NET. .. 324708 IN NS F.ROOT-SERVERS.NET. .. 324708 IN NS G.ROOT-SERVERS.NET. .. 324708 IN NS H.ROOT-SERVERS.NET. .. 324708 IN NS I.ROOT-SERVERS.NET. ;; Received 428 bytes from 10.107.17.218#53(10.107.17.218) in 0 ms com.172800 IN NS D.GTLD-SERVERS.NET. com.172800 IN NS F.GTLD-SERVERS.NET. com.172800 IN NS B.GTLD-SERVERS.NET. com.172800 IN NS E.GTLD-SERVERS.NET. com.172800 IN NS H.GTLD-SERVERS.NET. com.172800 IN NS M.GTLD-SERVERS.NET. com.172800 IN NS K.GTLD-SERVERS.NET. com.172800 IN NS C.GTLD-SERVERS.NET. com.172800 IN NS I.GTLD-SERVERS.NET. com.172800 IN NS J.GTLD-SERVERS.NET. com.172800 IN NS L.GTLD-SERVERS.NET. com.172800 IN NS A.GTLD-SERVERS.NET. com.172800 IN NS G.GTLD-SERVERS.NET. ;; Received 492 bytes from 202.12.27.33#53(M.ROOT-SERVERS.NET) in 127 ms trikorausa.com. 172800 IN NS dns1.buehlertech.net. trikorausa.com. 172800 IN NS dns2.buehlertech.net. ;; Received 117 bytes from 192.43.172.30#53(I.GTLD-SERVERS.NET) in 197 ms trikorausa.com. 43200 IN MX 10 mail.trikorausa.com. trikorausa.com. 43200 IN NS dns1.buehlertech.net. trikorausa.com. 43200 IN NS dns2.buehlertech.net. ;; Received 154 bytes from 69.12.155.168#53(dns2.buehlertech.net) in 35 ms - 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
On Wed, 20 Feb 2008, CLEMENT Francis wrote: > Hello Davide > > Recently I asked you how SMARTDnshost variable affected xmail internal > resolver, and you said that when using SmartDnsHost, xmail only ask for = > the > 'final' request (directly the mx lookup without trying first soa, ns, = > ) > > I asked this because I had the same problem as Jeff but was not at this = > time > able to find the reason about xmail resolver without smartdnshost = > setting > able or not to find the mx records for domains that was ok with dig = > and/or > nslookups at xmail server side (so using os resolver) and that the same > xmail server with smartdnshost applied was able to find without = > problems > (with all involved dns servers caches cleaned that don't use smart = > hosts > themself) > > I didn't have time to trace dns queries w/wo SmarDnshost usage (to see > timings, ...) but it seems that in some cases of long latencies on the = > wire > (temporarly high bandwidth usages, ...) xmail 'timeouts' quicker for = > dns > queries than then it use 'classic' resolvers (SmartDnsHost setting in > effect). > The problem could be after this timeout : how xmail handle this ? retry > later ? and on persistent 'no response from dns server', flag the = > domain > with an 'nxdomain' internal error without having any valid 'nxdomain' > responses ? > Could any of these be possible ? > Any way to test xmail resolver by changing xmail internal dns 'timeout' > value ? If there's a timeout, XMail will retry using the standard delivery policies. - 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]
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
OK, just to add to my confusion, here is part of what is going on - this server also provides the authoritative DNS for trikorausa.com (but not local DNS queries or caching!). It does not provide any other services for trikorausa.com (no email etc.) - the records point to an outside address. If I do a "dig @an-external-dns-server trikorausa.com +trace" I still get a "dig: Too many lookups" error. Does that make sense - is it looping? It seems like it should work - the external primary DNS knows the server doing the dig provides the authoritative DNS, shouldn't it simply trace back to it and stop? Essentially the server is simply doing a trace from an external DNS server back to itself. If I do a dig using ANY dns server from the server that provides the authoritative DNS for this domain I get the same result. As Davide reported if I do a dig to trikorausa.com from an outside line the trace is fine and does not fail. Also I don't know what the story is with the other domains - I only have client reports at this point about unexpected failures. Also, three weeks ago I was able to send email to trikorausa.com without the "nxdomain" error. Jeff CLEMENT Francis wrote: > Hello Davide > > Recently I asked you how SMARTDnshost variable affected xmail internal > resolver, and you said that when using SmartDnsHost, xmail only ask for = > the > 'final' request (directly the mx lookup without trying first soa, ns, = > . ) > > I asked this because I had the same problem as Jeff but was not at this = > time > able to find the reason about xmail resolver without smartdnshost = > setting > able or not to find the mx records for domains that was ok with dig = > and/or > nslookups at xmail server side (so using os resolver) and that the same > xmail server with smartdnshost applied was able to find without = > problems > (with all involved dns servers caches cleaned that don't use smart = > hosts > themself) > > I didn't have time to trace dns queries w/wo SmarDnshost usage (to see > timings, ...) but it seems that in some cases of long latencies on the = > wire > (temporarly high bandwidth usages, ...) xmail 'timeouts' quicker for = > dns > queries than then it use 'classic' resolvers (SmartDnsHost setting in > effect). > The problem could be after this timeout : how xmail handle this ? retry > later ? and on persistent 'no response from dns server', flag the = > domain > with an 'nxdomain' internal error without having any valid 'nxdomain' > responses ? > Could any of these be possible ? > Any way to test xmail resolver by changing xmail internal dns 'timeout' > value ? > > Francis > > > -Message d'origine- > De : [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] la part de Davide Libenzi > Envoy=E9 : mardi 19 f=E9vrier 2008 21:33 > =C0 : XMail mailing list > Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem reported > earlier?) > > > On Tue, 19 Feb 2008, Jeff Buehler wrote: > > >> Hi Davide - >> =20 >> Everything works when I use SmartDNS host to point to the same = >> > resolver=20 > >> as the server uses (a m0n0wall router). >> If I do not use SmartDNS host, I get the error to domains that can=20 >> receive email from other sources. >> =20 >> One example domain is trikorausa.com, although I am getting reports = >> > of=20 > >> the error from clients with about 5 other domains that mail can be = >> > sent=20 > >> to from other sources (like Hotmail). The results of a dig=20 >> trikorausa.com mx +trace actually result in a "dig: too many lookups" = >> > > >> failure - apparently the last time I did it a inadvertently did a = >> > "dig=20 > >> trikorausa.com mx + trace" with a space between the + and the trace = >> > and=20 > >> didn't notice that it hadn't performed a trace - sorry about that... >> =20 >> I will research why would I might get a "too many lookups" failure = >> > (the=20 > >> domain is fine and has valid MX records) and try to determine what = >> > may=20 > >> have changed recently (and if XMail is even involved) - I send to = >> > this=20 > >> domain all of the time and this seems to have started about when I=20 >> upgraded to 1.25. However, there were a number of changes around = >> > that=20 > >> time (including a FreeBSD update) so I will continue trying to = >> > isolate=20 > >> what is up and post back if I can find the problem. >> > > There's some configuration problem "inside" your network. The command = > is=20 > with "+trace" (w/out space), and from here is working fine. > So it must be something internal to your net. > > > > - 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 PRO
[xmail] Re: FreeBSD problem (similar to NetBSD problem report ed earlier?)
Hello Davide Recently I asked you how SMARTDnshost variable affected xmail internal resolver, and you said that when using SmartDnsHost, xmail only ask for = the 'final' request (directly the mx lookup without trying first soa, ns, = ) I asked this because I had the same problem as Jeff but was not at this = time able to find the reason about xmail resolver without smartdnshost = setting able or not to find the mx records for domains that was ok with dig = and/or nslookups at xmail server side (so using os resolver) and that the same xmail server with smartdnshost applied was able to find without = problems (with all involved dns servers caches cleaned that don't use smart = hosts themself) I didn't have time to trace dns queries w/wo SmarDnshost usage (to see timings, ...) but it seems that in some cases of long latencies on the = wire (temporarly high bandwidth usages, ...) xmail 'timeouts' quicker for = dns queries than then it use 'classic' resolvers (SmartDnsHost setting in effect). The problem could be after this timeout : how xmail handle this ? retry later ? and on persistent 'no response from dns server', flag the = domain with an 'nxdomain' internal error without having any valid 'nxdomain' responses ? Could any of these be possible ? Any way to test xmail resolver by changing xmail internal dns 'timeout' value ? Francis -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Davide Libenzi Envoy=E9 : mardi 19 f=E9vrier 2008 21:33 =C0 : XMail mailing list Objet : [xmail] Re: FreeBSD problem (similar to NetBSD problem reported earlier?) On Tue, 19 Feb 2008, Jeff Buehler wrote: > Hi Davide - >=20 > Everything works when I use SmartDNS host to point to the same = resolver=20 > as the server uses (a m0n0wall router). > If I do not use SmartDNS host, I get the error to domains that can=20 > receive email from other sources. >=20 > One example domain is trikorausa.com, although I am getting reports = of=20 > the error from clients with about 5 other domains that mail can be = sent=20 > to from other sources (like Hotmail). The results of a dig=20 > trikorausa.com mx +trace actually result in a "dig: too many lookups" = > failure - apparently the last time I did it a inadvertently did a = "dig=20 > trikorausa.com mx + trace" with a space between the + and the trace = and=20 > didn't notice that it hadn't performed a trace - sorry about that... >=20 > I will research why would I might get a "too many lookups" failure = (the=20 > domain is fine and has valid MX records) and try to determine what = may=20 > have changed recently (and if XMail is even involved) - I send to = this=20 > domain all of the time and this seems to have started about when I=20 > upgraded to 1.25. However, there were a number of changes around = that=20 > time (including a FreeBSD update) so I will continue trying to = isolate=20 > what is up and post back if I can find the problem. There's some configuration problem "inside" your network. The command = is=20 with "+trace" (w/out space), and from here is working fine. So it must be something internal to your net. - 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]
