Not resolving domains

General questions.
salida
Posts: 32
Joined: July 18th, 2015, 9:33 pm

Not resolving domains

Post by salida » June 29th, 2019, 4:58 pm

Hello everyone,

there has been many days that i have noticed (first noticed on Core update 122) the inability to resolve domain name to IP. My first thought was the DNS server that i have been using. Thus i use 1.1.1.1 and the primary from opendns just to be sure i can resolved fast and kinda secure. So the inability to resolve DNS lies on the IPfire.
Anyone having the same issue?

currently i was not able to resolve archive.raspberrypi.org .

IPFire version:
IPFire 2.23 (x86_64) - Core Update 133

Addons installed:
cifs-utils
guardian
htop
iftop
nmap
perl-Net-IP
perl-common-sense
perl-inotify2
sarg
wio
Last edited by salida on June 29th, 2019, 6:34 pm, edited 1 time in total.

User avatar
RHV1
Posts: 42
Joined: May 10th, 2015, 1:12 am
Contact:

Re: Not resolving domains

Post by RHV1 » June 29th, 2019, 5:37 pm

i stopped using my ipfire firewall for DNS many years ago after they made a change that broke my host file I was using to block ADs, malware, etc...

my ipfire points to "the google" DNS servers.

my ipfire's DHCP gives out one internal DNS server address which is an internal (green side) rpi running "pi-hole".

Mentalic
Posts: 31
Joined: April 14th, 2018, 2:51 pm

Re: Not resolving domains

Post by Mentalic » June 30th, 2019, 3:59 am

After core update 132 cloudfare DNS has problems and perhaps others DNS servers as well but its the only one I know for sure does not play well. I'm using Verisign DNS servers with no apparent problems. Submitted a bug for this.
Image
Image

Mentalic
Posts: 31
Joined: April 14th, 2018, 2:51 pm

Re: Not resolving domains

Post by Mentalic » June 30th, 2019, 4:06 am

RHV1 wrote:
June 29th, 2019, 5:37 pm
i stopped using my ipfire firewall for DNS many years ago after they made a change that broke my host file I was using to block ADs, malware, etc...

my ipfire points to "the google" DNS servers.

my ipfire's DHCP gives out one internal DNS server address which is an internal (green side) rpi running "pi-hole".
You might want to take a look at this to get your add blocker function back. I'm running it and only issue I have is it seems that IPS service needs to be stopped to set it up or update it, then restart IPS.
viewtopic.php?f=50&t=17787
Image
Image

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8490
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Not resolving domains

Post by Arne.F » June 30th, 2019, 6:23 am

Opendns will not work with IPFire because they strip the DNSSec signatures.

cloudflare seems somtimes give strange answers, they are even blocked by the IPS without log entry because the dns packet decoder fails not by triggering a rule.

Maybee one server behind 1.1.1.1 is/was faulty
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

salida
Posts: 32
Joined: July 18th, 2015, 9:33 pm

Re: Not resolving domains

Post by salida » June 30th, 2019, 8:39 am

Gday,

Stopped IPS-> DNS resolving not working
Stopped Guardian -> DNS started resolving

Is guardian causing any problems to others, or it is just irrelevant ?

I do not consider either 1.1.1.1 or opendns to have an issue because the DNS resolving issue does not exists permanently, but i will investigate further

Alorotom
Posts: 427
Joined: March 30th, 2015, 6:56 am

Re: Not resolving domains

Post by Alorotom » June 30th, 2019, 9:01 am

Isn't Guardian needless since Suricata is implemented in IPFire?
Image
Image

salida
Posts: 32
Joined: July 18th, 2015, 9:33 pm

Re: Not resolving domains

Post by salida » June 30th, 2019, 12:22 pm

Alorotom wrote:
June 30th, 2019, 9:01 am
Isn't Guardian needless since Suricata is implemented in IPFire?
from the newletter:
The guardian add-on is no longer required any more for the IDS to work but still provides means against SSH brute-force attacks and brute-force attacks against the IPFire Web UI.

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8490
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Not resolving domains

Post by Arne.F » June 30th, 2019, 4:25 pm

I have not sayd that cloudflare always fail. It only sometimes does strange things.

Most it looks like this:

Code: Select all

[root@EeePC ~]# /etc/init.d/unbound test-name-server 1.1.1.1
1.1.1.1 is validating
1.1.1.1 supports TCP fallback
EDNS buffer size for 1.1.1.1: 4096
Which is OK.

OpenDNS always fail:

Code: Select all

[root@EeePC ~]# /etc/init.d/unbound test-name-server 208.67.222.222
Unable to retrieve the following resource records from 208.67.222.222: RRSIG
208.67.222.222 is NOT DNSSEC-aware
208.67.222.222 supports TCP fallback
EDNS buffer size for 208.67.222.222: 4096
[root@EeePC ~]# /etc/init.d/unbound test-name-server 208.67.220.220
Unable to retrieve the following resource records from 208.67.220.220: RRSIG
208.67.220.220 is NOT DNSSEC-aware
208.67.220.220 supports TCP fallback
EDNS buffer size for 208.67.220.220: 4096
So IPFire refuse to use it (except no other server is reachable at all.)
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

dnl
Posts: 375
Joined: June 28th, 2013, 11:03 am

Re: Not resolving domains

Post by dnl » July 2nd, 2019, 7:27 am

Mentalic wrote:
June 30th, 2019, 4:06 am
RHV1 wrote:
June 29th, 2019, 5:37 pm
i stopped using my ipfire firewall for DNS many years ago after they made a change that broke my host file I was using to block ADs, malware, etc...

my ipfire points to "the google" DNS servers.

my ipfire's DHCP gives out one internal DNS server address which is an internal (green side) rpi running "pi-hole".
You might want to take a look at this to get your add blocker function back. I'm running it and only issue I have is it seems that IPS service needs to be stopped to set it up or update it, then restart IPS.
viewtopic.php?f=50&t=17787
I'm currently using a pi-hole in addition (that is upstream) to my IPFire system at home (on a raspberry Pi). In my experience the (default) blocklists that the pi-hole uses are much more effective than those available in IPFire today. Sadly the pi-hole UI is also significantly better today and it has a mobile view. It's easy to find which DNS entries were blocked for which system and to track down errant IPv6 DNS queries on an IPv4 only network (for example). You cannot easily do that in IPFire today.

I just wish it was easy to implement the pi-hole functionality and web UI straight in to IPFire, but they are different in so many ways.
IPFire 2.x (Latest Update) on x86_64 Intel Bay Trail CPU, 4GiB RAM, RED + GREEN + BLUE + ORANGE

yorch
Posts: 5
Joined: November 30th, 2015, 4:30 am

Re: Not resolving domains

Post by yorch » July 14th, 2019, 3:58 am

I'm currently having a similar problem, some domains are not resolved by unbound in IPFire. I first realized of the problem because my debian boxes would not get updates when they tried to connect to deb.debian.org, and realized that org domains are not able to be resolved for some reason.

Running from IPFire itself:

Code: Select all

[root@ipfire unbound]# dig google.com @localhost

; <<>> DiG 9.11.8 <<>> google.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36414
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		83	IN	A	172.217.15.110

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 13 23:52:46 EDT 2019
;; MSG SIZE  rcvd: 55

[root@ipfire unbound]# dig debian.org @localhost

; <<>> DiG 9.11.8 <<>> debian.org @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 27997
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;debian.org.			IN	A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jul 13 23:53:04 EDT 2019
;; MSG SIZE  rcvd: 39

[root@ipfire unbound]# dig debian.org @1.1.1.1

; <<>> DiG 9.11.8 <<>> debian.org @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32557
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;debian.org.			IN	A

;; ANSWER SECTION:
debian.org.		162	IN	A	149.20.4.15
debian.org.		162	IN	A	5.153.231.4
debian.org.		162	IN	A	128.31.0.62
debian.org.		162	IN	A	130.89.148.14

;; Query time: 11 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Jul 13 23:55:18 EDT 2019
;; MSG SIZE  rcvd: 103
I'm running Core 134 with IPS and Guardian enabled if it makes a difference. Thought it was a faulty / corrupt roots.hints file, so I manually updated mine from the one in https://www.internic.net/domain/named.root and restarted unbound, still same problem. Trying to figure how to debug in more depth this DNS resolution problem, so any pointers would be appreciated.

Thanks

PS: Funny story, given that this forum is hosted in an org domain, I found this thread in Google, but could not get to the page, so needed to use a SOCKS proxy :/

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8490
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Not resolving domains

Post by Arne.F » July 14th, 2019, 4:35 am

I single outdated entry should not the reason for this problem. B has changed the IPv4 IP
the rest is except from the Timestamp and some whitespaces in comments equal.

Code: Select all

ThinkPad-X220 unbound # wget https://www.internic.net/domain/named.root
--2019-07-14 06:28:49--  https://www.internic.net/domain/named.root
Auflösen des Hostnamen »www.internic.net (www.internic.net)«... 192.0.32.9, 2620:0:2d0:200::9
Verbindungsaufbau zu www.internic.net (www.internic.net)|192.0.32.9|:443... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 3312 (3,2K) [text/plain]
In »»named.root«« speichern.

named.root          100%[===================>]   3,23K  --.-KB/s    in 0s      

2019-07-14 06:28:50 (20,4 MB/s) - »named.root« gespeichert [3312/3312]

ThinkPad-X220 unbound # diff -Naur root.hints named.root 
--- root.hints	2019-06-28 07:57:07.000000000 +0200
+++ named.root	2019-07-03 16:00:00.000000000 +0200
@@ -1,92 +1,92 @@
-;       This file holds the information on root name servers needed to
+;       This file holds the information on root name servers needed to 
 ;       initialize cache of Internet domain name servers
 ;       (e.g. reference this file in the "cache  .  <file>"
-;       configuration file of BIND domain name servers).
-;
+;       configuration file of BIND domain name servers). 
+; 
 ;       This file is made available by InterNIC 
 ;       under anonymous FTP as
-;           file                /domain/named.cache
+;           file                /domain/named.cache 
 ;           on server           FTP.INTERNIC.NET
 ;       -OR-                    RS.INTERNIC.NET
-;
-;       last update:     July 26, 2017
-;       related version of root zone:     2017072601
-;
-; FORMERLY NS.INTERNIC.NET
+; 
+;       last update:     July 03, 2019 
+;       related version of root zone:     2019070301
+; 
+; FORMERLY NS.INTERNIC.NET 
 ;
 .                        3600000      NS    A.ROOT-SERVERS.NET.
 A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
 A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:ba3e::2:30
-;
-; FORMERLY NS1.ISI.EDU
+; 
+; FORMERLY NS1.ISI.EDU 
 ;
 .                        3600000      NS    B.ROOT-SERVERS.NET.
-B.ROOT-SERVERS.NET.      3600000      A     192.228.79.201
+B.ROOT-SERVERS.NET.      3600000      A     199.9.14.201
 B.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:200::b
-;
-; FORMERLY C.PSI.NET
+; 
+; FORMERLY C.PSI.NET 
 ;
 .                        3600000      NS    C.ROOT-SERVERS.NET.
 C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12
 C.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2::c
-;
-; FORMERLY TERP.UMD.EDU
+; 
+; FORMERLY TERP.UMD.EDU 
 ;
 .                        3600000      NS    D.ROOT-SERVERS.NET.
 D.ROOT-SERVERS.NET.      3600000      A     199.7.91.13
 D.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2d::d
-;
+; 
 ; FORMERLY NS.NASA.GOV
 ;
 .                        3600000      NS    E.ROOT-SERVERS.NET.
 E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10
 E.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:a8::e
-;
+; 
 ; FORMERLY NS.ISC.ORG
 ;
 .                        3600000      NS    F.ROOT-SERVERS.NET.
 F.ROOT-SERVERS.NET.      3600000      A     192.5.5.241
 F.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:2f::f
-;
+; 
 ; FORMERLY NS.NIC.DDN.MIL
 ;
 .                        3600000      NS    G.ROOT-SERVERS.NET.
 G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4
 G.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:12::d0d
-;
+; 
 ; FORMERLY AOS.ARL.ARMY.MIL
 ;
 .                        3600000      NS    H.ROOT-SERVERS.NET.
 H.ROOT-SERVERS.NET.      3600000      A     198.97.190.53
 H.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:1::53
-;
+; 
 ; FORMERLY NIC.NORDU.NET
 ;
 .                        3600000      NS    I.ROOT-SERVERS.NET.
 I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17
 I.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fe::53
-;
+; 
 ; OPERATED BY VERISIGN, INC.
 ;
 .                        3600000      NS    J.ROOT-SERVERS.NET.
 J.ROOT-SERVERS.NET.      3600000      A     192.58.128.30
 J.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:c27::2:30
-;
+; 
 ; OPERATED BY RIPE NCC
 ;
 .                        3600000      NS    K.ROOT-SERVERS.NET.
 K.ROOT-SERVERS.NET.      3600000      A     193.0.14.129
 K.ROOT-SERVERS.NET.      3600000      AAAA  2001:7fd::1
-;
+; 
 ; OPERATED BY ICANN
 ;
 .                        3600000      NS    L.ROOT-SERVERS.NET.
 L.ROOT-SERVERS.NET.      3600000      A     199.7.83.42
 L.ROOT-SERVERS.NET.      3600000      AAAA  2001:500:9f::42
-;
+; 
 ; OPERATED BY WIDE
 ;
 .                        3600000      NS    M.ROOT-SERVERS.NET.
 M.ROOT-SERVERS.NET.      3600000      A     202.12.27.33
 M.ROOT-SERVERS.NET.      3600000      AAAA  2001:dc3::35
-; End of file
+; End of file
\ Kein Zeilenumbruch am Dateiende.

Also the root.hints is only used in fallback "local recursor mode" wich means that the configured upstream recursors are not work properly or your ISP relay DNS Traffic to other servers.
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

salida
Posts: 32
Joined: July 18th, 2015, 9:33 pm

Re: Not resolving domains

Post by salida » July 14th, 2019, 7:41 am

So to cut a long story short.The suggested solution is to stop using cloudflare & opendns ?


Any suggestions for other known to work DNS servers ?

User avatar
Arne.F
Core Developer
Core Developer
Posts: 8490
Joined: May 7th, 2006, 8:57 am
Location: BS <-> NDH
Contact:

Re: Not resolving domains

Post by Arne.F » July 14th, 2019, 9:00 am

In this list cloudflare is still listed ok but there are some Problems reported in conjunction with ips.

I use one of my ISP and Lightning Wire Labs.
https://wiki.ipfire.org/dns/public-servers
Arne

Support the project on the donation!

Image

Image

Image
PS: I will not answer support questions via email and ignore IPFire related messages on my non IPFire.org mail addresses.

salida
Posts: 32
Joined: July 18th, 2015, 9:33 pm

Re: Not resolving domains

Post by salida » July 27th, 2019, 2:10 pm

I was struggling with issues resolving domains.This was the first time that i had this issue and i was somewhat unprepared.

The first step was to enter monitoring mode in IPS.
I noted down some repetitive rules that were causing troubles.
Then i disabled these rules and enabled IPS again. For a few days everything was working fine.

Sadly two days ago i was unable to update any of my linux (debian based) distributions on my home network.
So i completely disabled IPS. Currently everything is working fine.

Eventually i really had to consider some alternatives :(

Post Reply