I am running ipfire in Virtualbox and I can't resolve any .org addreeses. The only way I could get it to work was: 2014-10-14 ipfire couldn't resolve any .org domains so Hacked this file vi /etc/init.d/dnsmasq changed ENABLE_DNSSEC=0 #ENABLE_DNSSEC=1 then restarted dnsmasq Still don't know why it stopped. You could resolve all other domains just not .org. I am using Ipfire 2.17 (i586) core update 88 It has done it before and I had written down what to do as it took me a while to find the fix the solution I put above this came from my changelog I keep. So it was doing it back in 2014-10-14 and it must have reset back when I upgraded to core 88. Thanks.
This may not be an issue directly related to DNSSEC. The difference of the .org zone to most of the others is that they use longer keys and usually more than just one key. One of the most complicated things when DNSSEC was adopted was to handle the bigger DNS responses which also could be more than one UDP packet. I assume that the DNS server of your provider does not handle these responses correctly. Maybe it truncates them. These things happen. Please try using an alternative DNS server instead. Here is a list: http://wiki.ipfire.org/en/dns/public-servers
Created attachment 283 [details] attachment-3631-0.html I am using Google dns sever 8.8.8.8 Sent from Samsung Mobile -------- Original message -------- From: bugzilla@ipfire.org Date:04/04/2015 22:35 (GMT+10:00) To: gr786@exemail.com.au Subject: [Bug 10786] Cannot resolve any .org addresses until dnssec=0 is in /etc/init.d/dnsmasq file Michael Tremer changed bug 10786 What Removed Added Component basesystem --- CC michael.tremer@ipfire.org Status NEW ASSIGNED Assignee nobody@ipfire.org michael.tremer@ipfire.org Comment # 1 on bug 10786 from Michael Tremer This may not be an issue directly related to DNSSEC. The difference of the .org zone to most of the others is that they use longer keys and usually more than just one key. One of the most complicated things when DNSSEC was adopted was to handle the bigger DNS responses which also could be more than one UDP packet. I assume that the DNS server of your provider does not handle these responses correctly. Maybe it truncates them. These things happen. Please try using an alternative DNS server instead. Here is a list: http://wiki.ipfire.org/en/dns/public-servers You are receiving this mail because: You reported the bug.
Could you please check that there are no MTU issues on the way to the closest instance?
Created attachment 284 [details] attachment-5440-0.html Hi. I am not that technical and don't understand what you mean. I have mtu set at 1492 on the ppp set up page on ipfire. Has anyone else had this issue? Thanks Sent from Samsung Mobile -------- Original message -------- From: bugzilla@ipfire.org Date:05/04/2015 20:37 (GMT+10:00) To: gr786@exemail.com.au Subject: [Bug 10786] Cannot resolve any .org addresses until dnssec=0 is in /etc/init.d/dnsmasq file Comment # 3 on bug 10786 from Michael Tremer Could you please check that there are no MTU issues on the way to the closest instance? You are receiving this mail because: You reported the bug.
Hi, I have upgraded to core 89 and after that I still cannot resolve ipfire.org As soon as I edit vi /etc/init.d/dnsmasq and set DDNSSEC=0 and restart dnsmasq it works. See below: [root@ipfire ~]# nslookup ipfire.org ^C [root@ipfire ~]# vi /etc/init.d/dnsmasq [root@ipfire ~]# /etc/init.d/dnsmasq restart Stopping Domain Name Service Proxy... [ OK ] Starting Domain Name Service Proxy... [ OK ] Using DNS server(s): 8.8.8.8 8.8.4.4 [root@ipfire ~]# nslookup ipfire.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: ipfire.org Address: 178.63.73.246 > https://bugzilla.ipfire.org/show_bug.cgi?id=10786 > > --- Comment #3 from Michael Tremer <michael.tremer@ipfire.org> --- > Could you please check that there are no MTU issues on the way to the > closest > instance? > > -- > You are receiving this mail because: > You reported the bug.
CCC dns servers are also affected by this 194.150.168.168 213.73.91.35 host ipfire.org ;; Truncated, retrying in TCP mode. Host ipfire.org not found: 2(SERVFAIL) FreeDNS works with no problem Still a bad thing to encounter after upgrade to 89 :D
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2015q2/009453.html
Created attachment 342 [details] Patched dnsmasq binary for x86 Could you please replace /usr/sbin/dnsmasq by the file attached and tell me if this works for you?
Created attachment 343 [details] attachment-14051-0.html I stopped dnsmasq I replaced the binary with the one you sent and then changed DNSSEC=1 restarted dnsmasq then: [root@ipfire sbin]# vi /etc/init.d/dnsmasq [root@ipfire sbin]# /etc/init.d/dnsmasq start Starting Domain Name Service Proxy... [ OK ] Using DNS server(s): 8.8.8.8 8.8.4.4 [root@ipfire sbin]# nslookup ipfire.org ;; connection timed out; no servers could be reached [root@ipfire sbin]# vi /etc/init.d/dnsmasq (changed DNSSEC=0) [root@ipfire sbin]# /etc/init.d/dnsmasq restart Stopping Domain Name Service Proxy... [ OK ] Starting Domain Name Service Proxy... [ OK ] Using DNS server(s): 8.8.8.8 8.8.4.4 [root@ipfire sbin]# nslookup ipfire.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: ipfire.org Address: 178.63.73.246 So no the new binary didn't work for me. On 29 April 2015 at 19:21, <bugzilla@ipfire.org> wrote: > *Comment # 8 <https://bugzilla.ipfire.org/show_bug.cgi?id=10786#c8> on > bug 10786 <https://bugzilla.ipfire.org/show_bug.cgi?id=10786> from Michael > Tremer <michael.tremer@ipfire.org> * > > Created attachment 342 [details] <https://bugzilla.ipfire.org/attachment.cgi?id=342> [details] <https://bugzilla.ipfire.org/attachment.cgi?id=342&action=edit> > Patched dnsmasq binary for x86 > > Could you please replace /usr/sbin/dnsmasq by the file attached and tell me if > this works for you? > > ------------------------------ > You are receiving this mail because: > > - You reported the bug. > >
I assume (as this hasn't been updated in a while) that this issue is gone. We have shipped multiple new versions of dnsmasq with many fixes and it seems to work fine.