When I use unbount as the DNS service, it usually doesn’t work as expected as the IPFire 2.29 start each time. And the DNS Servers’s status is as below:
TCP should be the default setting. I don’t know why they specified UDP by default. For the DNS protocol. Other than its a little faster and some ISP have adopted it, but not all.
TCP is used for both types of DNS. Although modern DNSSEC servers are usually set for TLS, but will fall back and pick up a TCP connection and upgrade it.
yes, because that is the standard default in routers up to these last few years and most likely the isp haven’t updated those serves yet to accept udp.
Changing the protocol won’t fix the problem I would expect. If it is not working with udp it also won’t work with TCP or TLS.
Just to confirm, your Home page does show that your red interface is connected?
If it is showing as connected, then place your mouse pointer over the Broken status for your ISP’s DNS and also over the Error status for the 114.114.114.114 DNS server.
After a short while with the mouse pointer over the status you will get a message which gives the core reason for the Error or the Broken status.
If it is related to the protocol or to something else, this message should help to identify what the problem is.
I think I got it the other way around. Like DNS servers are not always configured with UDP. But in this case its associated with a router setting since the red address is 10.0.2.5 so I would suspect it being toggled to Tcp or TLS but you won’t know if the other modes work or not if you don’t try them either or there is further configuration needed in the router or other firewall box, like dns forwarders.
The nslookup failed when internet router restart each time, and after running /etc/init.d/unbound restart serveral times, the nslookup may be able to get the dns result.
I would remove that DNS Server and have a look at selecting some other ones from the IPFire list. I would also remove the one that shows Not Validating. That means that one supports DNSSEC but is not validating any DNSSEC requests. The Status of any individual server should end up being a green OK.
There is a list for DNS Servers for UDP/TCP and another one for DNS over TLS.
Initially select from the UDP/TCP list. When you get the overall status showing Working in Green and all the DNS servers you have showing individual statuses of OK in Green then you have a fully working DNS system and you can then look at changing to using the TLS option which means all your DNS queries are encrypted.
If the packets are over a certain size or other DNSSEC functions are required internally, a DNS server will stop listening to UDP from a connection. The fallback protocol that is used is TCP for both non DNSSEC UDP DNS servers as well as TLS DNSSEC DNS.
What is the DNS server? Because it does sound like a configuration. If it doesn’t work correctly with TCP protocol, then the firewall box/router before is not configured correctly. Which does sound like the case. Even if 10.0.2.x network have computers on them that have a working DNS.
For debugging purposes, in /etc/resolv.conf, change:
options edns0 trust-ad
to
options edns0
reboot, and if its working, then you have a configuration issue in the DNS server regarding DNSSEC.
Sorry for late reply, I have added the 1.1.1.1 as the dns server and this dns server is listed in www.ipfire.org - List of Public DNS Servers, hoswerver, the dns service is still broken as below:
I think this may not be the problem of DNSSEC, I have already add 8.8.8.8 as the DNS Server, howerver, nslookup doen’s work, but nslookup with specified dns server 8.8.8.8 can work.
Morever, When I restart the unbound service serveral times (may be one time or two times), then nslookup can work!
If you can ping ip addresses, then the mechanism for DSNSEC is blocked or disabled on the 10.0.2 side. Of course if 10.0.2 is a vpn network the dns pass through has to be setup properly.
So did you test removing trust-ad?
sometimes Ubound reloaded in a certain network state will ignore iptables.
another way would be provisioning iptables to accept local dns from 10.0.2.x, but there will be no dnssec connection from red to 10.0.2.x gateway:
iptables -A INPUT -p udp --dport 53 -j ACCEPT
of course you provision tcp at the same time since its the fallback protocal:
You are leaving the broken or error DNS servers still enabled. IPFire will test out using all the ones you have enabled.
So from your list I would disable the 114.114.114.114 and the 1.1.1.1
Although, before disabling 1.1.1.1 what message do you get when you have the mouse pointer over it. I just added 1.1.1.1 to my list with udp and it gave me a green OK and the rDNS worked fine.
Maybe if you get rid of the broken 114.114.114.114 entry it might work better.
Another alternative is to use recursor mode. Disable all DNS entries in that table, and leave the ISP entries disabled as well and the Status at the top left should change to
Before disabling 1.1.1.1, the message is “response timeout for 1.1.1.1@53(UDP) …” which can be seen in my previous image.
To reproduce my problem, I uploaded the corresponding ova file here Internet Router.ova - Google 云端硬盘, which can be opened with virtualbox. My virtualbox version is 6.1.50 on Ubuntu20.04.
I exported all my network card information to ova. To reproduce this problem, you need to include the mac addresses of all network cards when importing.
Also, I think you should stop and restart the internet router twice to reproduce above problem.
You can use the following command to create the same network as mine:
Then run this ova, and after starting the virtual machine, you will find that nslookup some commonly used domain names, such as www.github.com, download.microsoft.com, ftp.ubuntu.org, etc., do not work properly, but nslookup plus the specified domain name server 8.8.8.8 can work properly
You didn’t mention till now that you were running this on a vm.
No I can’t. I do have IPFire vm’s set up using virtualbox but they are on Arch Linux.
I have virtualbox version 7.1.4 running on Arch Linux which is a rolling release and so has no version number but is up to date to a few days ago whe I did the last pacman -Syu update.
If you are having trouble getting out on the red with DNS then a potential issue is the virtualbox mode you have for your red network interface.
I will check up the network settings that I have running for my Virtualbox development systems when I get the time to login on my other system that has the vm’s on it.
I have been running multiple IPFire systems for development and testing purposes for several years now and never had a problem so I will share what setup I have with those.