• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 21st, 2024

help-circle

  • Have you modified the default unbound config at all? This sounds like increasing the cache size limits and timeframes in the unbound config could help.

    I’m actually chasing an issue I’ve always had where everything works great in my environment, but on mobile certain domains take ages to finally load up for me. I think it’s a combination of my Pihole blocking and the amount of domains tied to a page (advertisements and tracking), but would love to figure it out. I work around it right now by flipping wifi off and on again in those instances.


  • Instead of port 53, I need to run unbound on 5335 (or another obscure port).I believe I also had to make some host level changed for DNS to operate correctly for incoming requests.

    Here’s my podman run commands. These might have changed a bit with Pihole v6, but should still be ok AFAIK.

    #PiHole1 Deployment/Upgrade Script podman run -d --name pihole -p 53:53/tcp -p 53:53/udp -p 8080:80/tcp --hostname pihole --cap-add=CAP_AUDIT_WRITE -e FTLCONF_REPLY_ADDR4=192.168.0.201 -e PIHOLE_DNS_=“192.168.0.201#5335;192.168.0.202#5335” -e TZ=“America/New York” -e WEBPASSWORD=" MyPassword" -v /var/pihole/pihole1:/etc/pihole -v /var/pihole/pihole1/piholedns/:/etc/dnsmasq.d --restart=unless-stopped --label=“io.containers.autoupdate=registry” docker.io/pihole/pihole:latest

    #UnBound1 Deployment/Upgrade Script podman run -d --name unbound -v /var/pihole/pihole1/unbound:/opt/unbound/etc/unbound/ -v /var/pihole/pihole1/unbound/unbound.log:/var/log/unbound/unbound.log -v /var/pihole/pihole1/unbound/root.hints:/opt/unbound/etc/unbound/root.hints -v /var/pihole/pihole1/unbound/a-records.conf:/opt/unbound/etc/unbound/a-records.conf -p 5335:5335/tcp -p 5335:5335/udp --restart=unless-stopped --label=“io.containers.autoupdate=registry” docker.io/mvance/unbound:latest






  • You’ve likely given it full control to whatever storage you’ve mounted in the container anyway, unless you’ve given it the :ro flag, which in that case would operate the same regardless of networking mode. If someone gains access to your internal host, you have bigger problems. Some things just play better under host mode and all bridged mode is doing is creating a virtual switch on your host and passing allowed traffic through it at a base level. The best way to protect is by running a load balancer in a DMZ and proxying all of the traffic through it which is how I have my instance running. I funnel everything external --> TCP\UDP 443 in DMZ vlan load balancer --> internal LAN IP:docker port. I run a mix of host network or bridged mode depending on the container.









  • It’s sad that this statement is true to the core, but I’ve seen statements and videos of Israelites literally claiming that Palestinians are not considered human. They are considered beneath, or less than human due to their belief, and that is how they are justifying their ethnic cleansing of the area.





  • I’ve been running mailcow for almost 2 years with no issues. I’m not doing anything major with it, mainly using it to send myself alerts on the environment, but it does work for external purposes if I want it to as well. Updating is easy and seamless. I did get greylisted almost immediately though, so I use SMTP2Go and it works great as a free relay for the amount of mail I generate.