0000948: DNS not working

Notes
(0001321) peter (administrator) 2008-06-18 10:01	we face no such problems on any of our installations. maybe it is related to something on with your setup. can you add "query-logs" to /var/efw/dnsmasq/dnsmasq.custom.tmpl and then restartdnsmasq.py afterwards you will have more dnsmasq debug messages in /var/log/messages so maybe you can sort out the problem. possible causes: - an internal client is flooding the resolver with to many dns requests - one of the resolvers is not working properly (you should see that in the logs then)

(0001332) jsalgado (reporter) 2008-06-18 21:36	I is very odd, because I do have experienced it on every single rc1 install I have done (over 8 now) on 3 XEN, 3 AMD, 2 INTEL, 1 Dual Athlon, It has happened on T1, Static IP, dinamic IP, PPPoE. And every one of them, now and then loose dns resolution, and have to be rebooted. I have tested on 8 different LANs (not just ours) they all failed ON or near the first install, and then over time (which then may agree on a flood maybe) I have heavily tested the resolvers before posting this bug, I tested over 8 diferent LANs, with different Internet providers, and hardware, and i have never come to feel comfortable about RC1 dns resolving It is really far from "rock solid", we are testing right here one RC1 box, with just linux clients, 3 at most simultaneously, and we still get DNS dropped about once a week. Is the same case to my Xen friends (they almos reboot daily just to be ahead the dns stall), my T1 Friend is holding his fist week, havent failed after the install day which lasted the whole day without DNS, we had to map, directly to the ISPs DNSs (which were exactly the same ON the endian box). As I mentioned before when this fails, the endian box is able to solve DNS without any hazle, it just stops providing DNS solving for the LAN clients. Thank you.

(0001347) peter (administrator) 2008-06-24 00:40	can you try to restart the service with: restartdnsmasq.py --force if that does not help with: /etc/init.d/dnsmasq restart if that does not help please create the file: /var/efw/dnsmasq/dnsmasq.custom.tmpl with content: log-queries and restart with: restartdnsmasq.py dnsmasq will then log messages for each query to /var/log/messages please try to see if there is a problem with a dns. here may be a problem with the restart of dnsmasq, i faced a similar situation, but i am unsure if that was only bad configuration, since it worked thereafter. your information would be much appreciated.

(0001349) jsalgado (reporter) 2008-06-24 06:41 edited on: 2008-06-24 06:44	Thank you very much for your help, I once did test with /etc/init.d/dnsmasq before with my T1 friend, I have rebooted three times, and I was erroneously looking for the "bind" service, when i found dnsmasq, I restarted it... and DNS came back to life, but we were already, using the PDC DNS, I have not been able to test once more because when this happens I/we usually reboot, but I will test on our next chance. I couldnt be more betrayed by myself, I actualy leave WIN2003 for DNS!!! (well I will keep that a secret) =) Thanks again, I do agree it seems to be a restart or start problem with dnsmasq. Because when I configure a a regular Linux Box as a router, I follow the steps I did to know where the problem is, And thats why I was looking for "BIND", since he is not here I will suspect from his brother dnsmasq.

(0001351) peter (administrator) 2008-06-24 11:57	aah ok, so there's probably another cause: did you configure internal resolvers on our uplink? this is not going to work. we automatically create policy routes in order to force dns traffic for the respective dns resolver to exit to the uplink where that resolver is configured. this way we can use all dns resolvers of all providers at the same time. otherwise providers may block dns treffic if it does not come from an ip address of their pool. if you need to configure internal dns servers you can do that with dns proxy > custom nameserver

(0001356) jvodan (reporter) 2008-06-25 04:50	I got this problem post update (last few days) I found that if I put in a system access rule for DNS on the firewall DNS works again.

(0001368) jsalgado (reporter) 2008-06-25 19:02	Thank you peter, do you mean by "internal resolvers" a DNS server on my LAN? Well either way I have used 2 kinds of DNS, the automatic for PPPoE, and for T1/E1 I have set always the providers own DNS servers ( External to my network offcourse) I understand what you say, about providers blocking dns traffic out of their pool request. But I havent sent DNSs other than the provider's. But this is interesting to know, and it get me to think, that my provider uses DNS s server addresses more or less out of their (at least) expected pool. My ip is 189.X.X.X and our DNSs service is 200.X.X.X . Do you think this will have trouble with the automatically crated policies ?

(0001371) jsalgado (reporter) 2008-06-25 23:47	Thank you jvodan, I havent been able to test you solution, because DNS has been working for some days... But isnt DNS system access rule a preset out of the box?

(0001372) jvodan (reporter) 2008-06-26 02:37	Using netstat I saw that somthing was listening of 0.0.0.0:53 yet using tcpdump I could see no replies from dns request, after that it was kind of instinctive to add a system rule for access to port 53. I assume there is normally a rule in there (though hidden from the gui) I guess somehow/someway, post recent updates it doesn't get added when the software rebuilds the revlevant files in /etc/ from /var/efw/. Well that's my guess. I haven't being using efw long.

Issue History
Date Modified	Username	Field	Change
2008-06-13 23:21	jsalgado	New Issue
2008-06-13 23:21	jsalgado	Status	new => assigned
2008-06-13 23:21	jsalgado	Assigned To	=> peter
2008-06-14 19:56	jsalgado	Issue Monitored: jsalgado
2008-06-18 10:01	peter	Note Added: 0001321
2008-06-18 10:01	peter	Status	assigned => feedback
2008-06-18 21:36	jsalgado	Note Added: 0001332
2008-06-24 00:36	peter	Target Version	=> 2.2-rc2
2008-06-24 00:40	peter	Note Added: 0001347
2008-06-24 06:41	jsalgado	Note Added: 0001349
2008-06-24 06:44	jsalgado	Note Edited: 0001349
2008-06-24 11:57	peter	Note Added: 0001351
2008-06-25 04:50	jvodan	Note Added: 0001356
2008-06-25 14:56	peter	Relationship added	related to 0000923
2008-06-25 19:02	jsalgado	Note Added: 0001368
2008-06-25 23:47	jsalgado	Note Added: 0001371
2008-06-26 02:37	jvodan	Note Added: 0001372
2008-06-30 12:18	peter	Relationship added	related to 0001039
2008-07-24 18:05	ra	Target Version	2.2-rc2 => 2.2-rc3
2008-07-28 12:49	peter	Priority	normal => urgent
2008-08-04 19:22	peter	Status	feedback => resolved
2008-08-04 19:22	peter	Fixed in Version	=> 2.2-rc3
2008-08-04 19:22	peter	Resolution	open => fixed
2008-10-08 15:30	peter	Status	resolved => closed