[–] 16 points 5 hours ago

Yeah, sure. The left simply can't communicate, while the right does it so well. The left is also stupid and has no actual plan while the right has a unified vision to sell.

...or we just take a look at who owns the media and realize that it's not about the story or the communication but all about the platforms and what actually reaches the people.

  • source
  • [–] 2 points 8 hours ago* (last edited 8 hours ago)

    Just pick a blocklist (usually via curl, coming in a "0.0.0.0 " format), reformat it to "local-zone: always_refuse" (sed is your friend) then add an include-line to the unbound config.

    And yes, you would need to set some timer to update it from time to time.

    PS: I stopped using unbound and went with dnsproxy (see my other comment here) because it was less cumbersome (just a few command line parameters instead of an extensive config) to serve at the same time as my local dns while also providing it via DoQ (and DoH for those stupidly restrictive networks) for me when I'm not at home. Also proper parallel querying is -iirc; I didn't look at it for quite a while- still missing from unbound and it can work with DoQ upstream but not serve it yet.

  • source
  • parent
  • context
  • [–] 2 points 9 hours ago (2 children)

    I never understood the point in setting up unbound and pi-hole. Unbound is perfectly able to use all the filter lists you use with pi-hole, so at this point it's nothing but an additional layer for some fancy webui with stats you never actually look at.

  • source
  • parent
  • context
  • [–] 4 points 9 hours ago* (last edited 9 hours ago)
    1. AdGuard

    Adguard's dnsproxy also works well on its own. And it can very well spare you much of the overhead. Just pick a few dns providers you trust, query them in parallel and add whatever ad-blocking list you want to use locally. All with such on not that complicated command...

    Example: dnsproxy --listen=127.0.0.1 --port=53 --bootstrap=9.9.9.9 \

    --hosts-file-enabled --hosts-files=/etc/dnsproxy/blocklist \

    --upstream=https://unfiltered.joindns4.eu/dns-query --http3 \

    --upstream tls://dot.libredns.gr \

    --upstream tls://dns3.digitalcourage.de \

    --upstream tls://dns.digitale-gesellschaft.ch \

    --upstream tls://anycast.uncensoreddns.org \

    --upstream=quic://dns10.quad9.net \

    --upstream=h3://cloudflare-dns.com/dns-query \

    --upstream-mode=parallel \

    --cache

    Yes, that's an unreasonable amount of dns' queried but I just wanted to get a few useful ones listed, also a wide spread from https (http2 and 3), tls and quic.

  • source
  • [–] 1 point 10 hours ago

    which under an authoritarian regime can be torture in prison or being summarily executed or dissapeared

    The finer point is that you are still thinking in terms of authoritarian regimes ruling by force or intimidation. You don't need to if you can direct the opinion of 90%+ of the population via methods totally unfit to do what they claim they are employed for.

    For some very strange reason you seem to be under the impression that I downplay this massive insane censorship measure they try to enact with this bill. I'm not. Quite the contrary I am telling you very plainly that it's inefficient FOR WHAT THEY CLAIM THE GOAL IS. Because they are lying.

  • source
  • parent
  • context
  • [–] 2 points 17 hours ago (2 children)

    Internet censorship is very easy to do, I don’t know why some people tunnel-vision on the fact it’s not perfect. It doesn’t have to be perfect to still be very effective.

    That was my actual point. It's effective for censorship and targeting the broader population. It's ineffective for preventing piracy as a lot of people there are indeed tech-affine and belonging to the <1% that will go the extra mile to circumvent it.

    So implementing provider and dns blocks against piracy is either stupid or an intentional lie. I assume the latter.

  • source
  • parent
  • context
  • [–] 14 points 1 day ago* (last edited 1 day ago)

    Sowas hier ist ein Steingarten:

    Steine, Felsen, Gebirgsflora. Sehr naturbelassen und dank der eher zähen Pflänzchen, die sich in Berggebieten heimisch fühlen und sich in harten Oberflächen festwurzeln, sehr temperatur- und trockenheitsresistent.

    Das hier ist ein Schottergarten:

    Hat also nicht das geringste mit 'nem Garten zu tun und ist eher 'ne rein optische Alternative zum Betonieren (und die kleinen Pflanzen, die sich da –siehe Bild– trotzdem todesmutig versuchen anzusiedeln, werden meist rigoros getötet).

  • source
  • parent
  • context
  • [–] 8 points 1 day ago (3 children)

    Danke dafür, nicht irrtümlicherweise wie so viele Menschen von Steingärten zu reden. Die sind im Gegensatz nämlich schön und sinnvoll.

  • source
  •  

    As this will -thanks to me being quite clueless- be a very open question I will start with the setup:

    One nginx server on an old Raspi getting ports 80 and 443 routed from the access point and serving several pages as well as some reverse proxies for other sevices.

    So a (very simplified) nginx server-block that looks like this:

    # serve stuff internally (without a hostname) via http
    server {
    	listen 80 default_server;
    	http2 on;
    	server_name _; 
    	location / {
    		proxy_pass http://localhost:5555/;
                    \# that's where all actual stuff is located
    	}
    }
    # reroute http traffic with hostname to https
    server {
    	listen 80;
    	http2 on;
    	server_name server_a.bla;
    	location / {
    		return 301 https://$host$request_uri;
    	}
    }
    server {
    	listen 443 ssl default_server;
    	http2 on;
    	server_name server_a.bla;
       	ssl_certificate     A_fullchain.pem;
        	ssl_certificate_key A_privkey.pem;
    	location / {
    		proxy_pass http://localhost:5555/;
    	}
    }
    #actual content here...
    server {
    	listen 5555;
    	http2 on;
        	root /srv/http;
    	location / {
            	index index.html;
       	} 
        	location = /page1 {
    		return 301 page1.html;
    	}
        	location = /page2 {
    		return 301 page2.html;
    	}
            #reverse proxy for an example webdav server 
    	location /dav/ {
    		proxy_pass        http://localhost:6666/;
    	}
    }
    

    Which works well.

    And intuitively it looked like putting Anubis into the chain should be simple. Just point the proxy_pass (and the required headers) in the "port 443"-section to Anubis and set it to pass along to localhost:5555 again.

    Which really worked just as expected... but only for server_a.bla, server_a.bla/page1 or server_a.bla/page2.

    server_a.bla/dav just hangs and hangs, to then time out, seemingly trying to open server_a.bla:6666/dav.

    So long story short...

    How does proxy_pass actually work that the first setup works, yet the second breaks? How does a call for localhost:6666 (already behind earlier proxy passes in both cases) somehow end up querying the hostname instead?

    And what do I need to configure -or what information/header do I need to pass on- to keep the internal communication intact?

    view more: next ›