Need help with my VLAN firewall rules to make sure they do what I think they do
IMHO that doesn't make sense.
I was thinking maybe it was some kind of tracking, to get the "real" ip of the pihole machine. But since you do an update right after, you are going to reveal your ip to them anyway.
So that doesn't make sense either.
It seems to be a "klugde" to circumvent a problem that doesn't exist.
And I have seen mobile phones just doing an ipv6 dns request to google v6 dns to see if ipv6 connectivity exists.
Thats not what its doing - its doing a specific query to a specific IPv4 address.. I am curious if the query is done via hard coded IP, of if it has to lookup ns1.pihole.net first?
I'm thinking @bingo600 is on the right track with its some kludge to work around something that is not actually a problem..
I am curious if the query is done via hard coded IP, of if it has to lookup ns1.pihole.net first?
Well that is even more stupid then ;)
Just at a loss to WTF they are thinking doing something like that.. I understand it with something like a browser wanting your DNS..
But what is the point of such shenanigans from something like pihole? Just at a loss to understand the point of that..
There is this:
That's concerning the installer.
I use a pi-hole and have never noticed that. I'll have to look and see if it's hitting that nameserver.
Why does that nameserver even exist? Do they intend you to forward to it instead of some other public nameserver...
Yeah @bingo600 had already linked to that.. They mention something about a problem with AD dns?? Which is nonsense MS dns can do TXT lookups..
And if you look at that git commit , they actually had it running wo. the ns1 stuff before.
Wonder if we should just rip the ns1 addition out of
But it would be nicer if they removed it from the upstream git repos.
They are resolving the supported OS'es (during instal/update) via a DNS TXT record.
@bingo600 OK, ummmm. I guess... I can think of other ways to do that... Are they doing two things at once. That the box can resolv some domain and getting the list of supported OS's in one go. Why...
Looking into a bit deeper something about MS dns not supporting cookie options.. But looks to me like the suggested work around was to just set +nocookie in the dig command.
No matter what lame reasoning they came up with - doing a directed query like that is not the way to do it if you ask me.
You could offer it up as a solution if the normal query failed, etc. But doing it in the background not a fan of.. Other option was to hard code the supported OS versions.. which would of been better options I think as well.
jwj last edited by
Did you find the git PR that shows the cookie issue ?
I had a brief look , but didn't find any.
Yeah and it was with 2008r2 that is DEAD... full end of life was jan 2020, so why would they be doing something to work around an issue with that in july of 2020?
All seems a bit stupid to me..
Yes .. We're talking about pi-hole , and DNS blocking.
And that pi-hole won't update if you block DNS to anything but the pfSense.
@bingo600 I see. Interesting. Thanks!
I just got a new update for my pihole, i suppose you ought to see it too
This time i tried
PIHOLE_SKIP_OS_CHECK=true sudo -E pihole -r
Selected repair , and the update went through wo. opening for ns1
But damm annoying
Looks like an update to FTL.. lets see what happens.. I have these rules in place..
For the vlan that my pihole sits on..
Yeah this is nonsense...
[✗] Retrieval of supported OS list failed. dig failed with return code 9. Unable to determine if the detected OS (Raspbian 10) is supported Possible causes for this include: - Firewall blocking certain DNS lookups from Pi-hole device - ns1.pi-hole.net being blocked (required to obtain TXT record from versions.pi-hole.net containing supported operating systems) - Other internet connectivity issues
This is zero issue with grabbing that info.. Other that you forcing a direct query to ns1.. Gawd this just pisses me off that they do nonsense like this.. Arrrghh.. Why are people so freaking stupid?????
root@pi-hole:/home/pi# dig versions.pi-hole.net txt ; <<>> DiG 9.11.5-P4-5.1+deb10u2-Raspbian <<>> versions.pi-hole.net txt ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16772 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;versions.pi-hole.net. IN TXT ;; ANSWER SECTION: versions.pi-hole.net. 3600 IN TXT "Raspbian=9,10 Ubuntu=16,18,20 Debian=9,10 Fedora=31,32 CentOS=7,8" ;; Query time: 356 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Dec 26 19:21:24 CST 2020 ;; MSG SIZE rcvd: 127 root@pi-hole:/home/pi#
So they fixed working with some antiquated dns windows server 2008??? That is EOL!!! By just bypassing it. To break everyone else that would be filtering dns other than their own.. Ie pretty much every pihole user on the planet ;) This is just some of the stupidest shit ever.. WTF!!!
While I am a fan of pihole - this is just borked.. Same goes with some of the nonsense they are trying to do with dnssec.. If your going to forward, dnssec is pointless - he doesn't get that either.. Maybe we should fork their code ;)
While I am a fan of pihole - this is just borked..
Totally agree .. Fix for an old outdated OS , and "bork" everyone else.
Same goes with some of the nonsense they are trying to do with dnssec.. If your going to forward, dnssec is pointless - he doesn't get that either..
I thought they wouldn't touch DoH at all as "PH is not a security product"
Maybe we should fork their code ;)
Intriquing , but i doubt i have time for that.