#dns_servers — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #dns_servers, aggregated by home.social.
-
#Eigener #DNS- #Server mit Technitium #DNS:
Wie man seine #DNS_Auflösung selbst verwaltet, ohne auf #Upstreamanbieter angewiesen zu sein.
Die Vorteile des #Selbsthostens seines #DNS_Servers liegen auf der Hand: Man ist sicher vor #Zensurbestrebungen durch #Staat und #Provider und kann direkt auf #Domainebene, wie der Artikel zu #dnsmasq schon kurz erwähnt, #Werbung blockieren.
-
#Eigener #DNS- #Server mit Technitium #DNS:
Wie man seine #DNS_Auflösung selbst verwaltet, ohne auf #Upstreamanbieter angewiesen zu sein.
Die Vorteile des #Selbsthostens seines #DNS_Servers liegen auf der Hand: Man ist sicher vor #Zensurbestrebungen durch #Staat und #Provider und kann direkt auf #Domainebene, wie der Artikel zu #dnsmasq schon kurz erwähnt, #Werbung blockieren.
-
#Eigener #DNS- #Server mit Technitium #DNS:
Wie man seine #DNS_Auflösung selbst verwaltet, ohne auf #Upstreamanbieter angewiesen zu sein.
Die Vorteile des #Selbsthostens seines #DNS_Servers liegen auf der Hand: Man ist sicher vor #Zensurbestrebungen durch #Staat und #Provider und kann direkt auf #Domainebene, wie der Artikel zu #dnsmasq schon kurz erwähnt, #Werbung blockieren.
-
#Eigener #DNS- #Server mit Technitium #DNS:
Wie man seine #DNS_Auflösung selbst verwaltet, ohne auf #Upstreamanbieter angewiesen zu sein.
Die Vorteile des #Selbsthostens seines #DNS_Servers liegen auf der Hand: Man ist sicher vor #Zensurbestrebungen durch #Staat und #Provider und kann direkt auf #Domainebene, wie der Artikel zu #dnsmasq schon kurz erwähnt, #Werbung blockieren.
-
#Eigener #DNS- #Server mit Technitium #DNS:
Wie man seine #DNS_Auflösung selbst verwaltet, ohne auf #Upstreamanbieter angewiesen zu sein.
Die Vorteile des #Selbsthostens seines #DNS_Servers liegen auf der Hand: Man ist sicher vor #Zensurbestrebungen durch #Staat und #Provider und kann direkt auf #Domainebene, wie der Artikel zu #dnsmasq schon kurz erwähnt, #Werbung blockieren.
-
CW: Long post
It's missing something to explicitly tell if the problem is DNS. If the images contained
host, this is much easier.You added an explicit
--dns 9.9.9.9to the container run command. I'm not sure where 9.9.9.9 comes from, but that would have masked my problem by making me use an external third-party resolver. This would have then caused later failures when using the Spamhaus DNS RBL, because it blocks queries from open resolvers.I don't think I tried ping, because I thought jails couldn't do raw sockets by default. The OCI spec draft seems to agree that they can't unless you add some explicit config.
Now I'm back at the computer that can log into the machine I was working on:
For systems that use
local_unboundand do not have another resolver configured, you need to do two things.First, add the following in the
server:section of/etc/unbound/unbound.conf:interface: 10.88.0.1
access-control: 10.0.0.0/8 allowAssuming
10.88.0.1is the address of the host on thecni-podman0network. The first line makes it listen on that network, the second makes it actually respond to queries from other things on that network.Next, in
/usr/local/etc/containers/containers.conf, add the following:dns_servers = ["10.88.0.1"]There should be an existing
#dns_servers = []line in the correct place in the file. Again, the IP address here should match the one on the bridge.This will cause podman to populate new containers with a
/etc/resolv.confthat tells them to use the host's resolver.