malformed list is naively accepted, in some cases problematically #12
Comments
|
Oh, and I left out one thing: The reason why this suddenly became problematic this morning is that the site in question, malwaredomainlist.com, is now no longer serving the essentially empty list it had been serving. Instead, it's now a domain parking page, and the HTML source of that domain parking page is what void-zone-tools is inappropriately treating as if it were a void zones list. |
|
@cyclaero, could you perhaps tag a new release with this change included? It would make for a smooth bump in the FreeBSD ports tree. |
freebsd-git
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Sep 24, 2023
void-zones-tools downloads a set of pre-defined lists of undesirable domains and creates "voided" dns zones for Unbound, blocking access to these domains via dns. One of the default lists is no longer maintained, and was removed from the upstream code. However, there hasn't been released a new version after the change was made, thus the port has not been updated. This has not been a problem up until now because the update script has been downloading an empty file, essentially a no-op in the zone creation/loading, but at some point today it started serving a domain parking page, and the HTML of that page is being dumped into the dns zone file resulting in parse errors and Unbound cannot start. While waiting for upstream to tag a new version, I changed the port to track the latest GitHub commit. This fixes the issue for now. PR: 274027 Upstream issue: cyclaero/void-zones-tools#12 Reported by: Robert William Vesterman <bob@vesterman.com> MFH: 2023Q3
freebsd-git
pushed a commit
to freebsd/freebsd-ports
that referenced
this issue
Sep 24, 2023
void-zones-tools downloads a set of pre-defined lists of undesirable domains and creates "voided" dns zones for Unbound, blocking access to these domains via dns. One of the default lists is no longer maintained, and was removed from the upstream code. However, there hasn't been released a new version after the change was made, thus the port has not been updated. This has not been a problem up until now because the update script has been downloading an empty file, essentially a no-op in the zone creation/loading, but at some point today it started serving a domain parking page, and the HTML of that page is being dumped into the dns zone file resulting in parse errors and Unbound cannot start. While waiting for upstream to tag a new version, I changed the port to track the latest GitHub commit. This fixes the issue for now. PR: 274027 Upstream issue: cyclaero/void-zones-tools#12 Reported by: Robert William Vesterman <bob@vesterman.com> MFH: 2023Q3 (cherry picked from commit 27c31c5)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This morning, I woke up to find that none of my computers could get to the internet.
Just to remind you of a bit of background info: About a year ago, I noticed that the file "mdl_void_hosts.txt" was (essentially) empty. This didn't seem to cause any issues, but looking into it a little more I found that the website it was being pulled from was no longer maintained. So, I suggested here that maybe void-zone-tools shouldn't pull from there anymore at all, and you then updated void-zone-tools so that it doesn't.
Back to this morning: I found that my internet problems were really DNS problems, and narrowed it down to my unbound server, which was not running. Upon trying to start it up, it complained about syntax errors, and immediately shut itself down because of them. These syntax errors were coming from within the void hosts list file. The problematic lines looked like snippets of HTML and/or Javascript. I found that these were coming from mdl_void_hosts.txt, which had been updated while I was asleep.
That was surprising, as you had updated void-zones-tools so that it no longer used that file. Turns out, that change never made it into the FreeBSD version of void-zones-tools. I have submitted a bug report on FreeBSD's bugzilla, so hopefully they'll soon update from upstream, and this will no longer be an issue.
However, even if they do, that still leaves that void-zones-tools is accepting whatever it gets from its sources, without bothering to check that it's actually a void zones list, potentially resulting in serious issues (such as happened to me here), so I thought I should report it to you as well.
The text was updated successfully, but these errors were encountered: