Hi all, Just picked up a really strange issue. I am updated to Core-Update 192 and as of about 30 minutes ago I can no longer access ANY website with .co.za TLD. So in testing, I disabled ALL my DNS servers that I have (6), so that IPFire is running in recursor mode and now I can access any co.za website.
I also saw in my DNS-Unbound logs this message: “info: validation failure : not all NSEC3 records secure from 185.95.218.42 for DS amazon.co.za. while building chain of trust”. This message comes up for ANY co.za website I try.
Is the above message somehow related to the DNS issue I am having or are there two different issues at play here?
I recommend to activate the external DNS servers one after the other, starting with lightningwirelabs.
I suppose some servers may be restrictive, f.e. adguard.
Hi @bbitsch Apologies, I should have mentioned that I did already try that, as soon as I enable ANY one of them, boom, no access to co.za. I have also emailed my ISP on the off-chance it is an issue on their side.
I normally use the recursor mode so I changed mine to use the 6 disabled dns servers I have defined.
I then tried to access amazon.co.za and I also got a failure to connect and in the log it mentions about the NSEC3 problem.
NSEC3 is linked in with dnssec
I then changed back to using the recursor mode and I could connect to that amazon web site.
So I can reproduce what you are seeing but I have no idea what is causing that.
unbound itself has not been changed in CU192.
The dns root zone file was updated in CU192, but if that is the problem then every dns server request in the world would have a problem including, I would expect., the recursor mode and it would not be limited to the .co.za zone.
I will look at testing out the same thing on a vm machine with CU191 on it and see if it is related to the update or due to some other issue.
1 Like
@bonnietwin Thank you, sir. I appreciate the feedback and your testing. Quick question, does recursor mode still use DNSSEC or not? I looked on the IPFire Wiki, however, it is not clear on that score.
Yes, it will still be using dnssec also.
Ah OK, great, then I will just leave it for now as is. As you say, you use recursor mode, so I will leave mine. Just strange that the DNS servers I have worked fine from the update yesterday till now then suddenly, it gave issues.
It is not just your ones. I doubt that you have the same dns servers specified as I have. I have used 5 distributed around the Europe area. They also give me the same problem.
Here are the ones I used for the testing.
1 Like
Oh, I fully understand that. Mine are shown in the first post. You have two the same as mine.
Sorry, missed that. Obviously didn’t have my eyes open when I read your first post 
LOL, all good, sir.
Okay, I didn’t have a vm system with CU191 available on it but I did have one with CU190.
So I tried the same thing with that system using the same dns servers.
I also can’t access amazon.co.za with that. Get the same NSEC3 message.
amazon.co.uk and amazon.nl both work without any problem.
So the issues is not caused by anything from the CU192 update.
OK, thank you for the testing, sir. I truly appreciate the time and effort. I will await a response from my ISP to either confirm if they are having issues or not.
I doubt that they are likely to be the cause as then you, and their other customers, would be the only ones affected. As I also can reproduce the problem it is more wide spread but I have no idea what it might be.
Searching about nsec3 and the whole of .co.za zone didn’t find any results except the ones that tell you what nsec3 is for.
You/we might just have to wait and see if things get fixed and if there end up any posts on the internet with other people experiencing the issue.
1 Like
Ah, I see your point. OK, let me do some more research online, you have certainly provided some good tips and ideas on where to look, so thank you. If I find anything I will post back here.
2 Likes
Hi @bonnietwin,
I am curious why you normally have your IPF DNS setup in recursor mode?
My understanding is that DNS queries (in recursor mode) go out to root servers (when not cached locally) unencrypted (not DoT) over port 53.
This might result in faster DNS performance for cached queries but also less secure for any new DNS queries reaching out to root servers.
Please enlighten me.
@bonnietwin OK, so my ISP did eventually get back to me and apparently there was a DNS issue, however, it seems to have been local DNS only, so this is why co.za sites were affected. Not sure if that makes sense, lol, it doesn’t really to me. DNS is DNS as far as I am concerned. Anyway, thanks again for all the assistance, things seem to be back to normal and my DNS entries are enabled once again.
1 Like
That’s good to hear. I confirm the same thing. I can access amazon.co.za with any dns server set now.
It looks like it was wider than your ISP but local to specific zones or parts of a zone.
Either way, glad it is working for you again and the problem is understood.
1 Like
Hi @rjschilt
My reason was based on this section of an IPFire blog post.
https://www.ipfire.org/blog/what-you-can-do-with-the-new-dns-features-in-ipfire#recursor-mode
3 Likes
The problem hasn’t gone completely. I further get the message.
EDIT: after a restart of unbound, initiated by save in WUI, the problem has gone.