At last, a material benefit from all those years of putting 24 hour expiries into BIND configs.

NOT TODAY, SATAN.

Schöner DNS-Workaround, den ich bis jetzt noch nicht kannte/brauchte: Um die (z.B. aus versehen zu weit in die Zukunft gesetzte) serial number eines Eintrags zurückzusetzen, muss man einfach nur das 32-bit große Feld zum Überlauf und damit wieder auf 0 bringen. Anschließend kann man es neu auf den Wunschwert setzen

https://www.zytrax.com/books/dns/ch9/serial.html

Adventures getting #Netflix to work in a somewhat complex home #network

I decided to give their plan with ads a chance, sounding like a somewhat fair deal. First issue was, I couldn't even register. It only offered me US plans. Figured that's because my #IPv6 connectivity is tunnelled through #HE (for reasons, different story). Of course using an endpoint here in Germany, but nevertheless, Netflix seemed to think it's a US located address.

Running my own #bind9 instance, I found a way to hide relevant AAAA records (netflix' own domain and also amazonws) by adding a view only operating on local loopback and filtering out ALL AAAA records, and then adding forward-only zones for these domains to this local view. Horrible, but works, now I could register, forcing #IPv4.

One particularly cheap "smart-tv" still couldn't connect to netflix, always showing me an error that I was using some "VPN". No way to analyze what exactly was happening there, but I finally found a solution for that as well: I created an entirely new network segment (with its own #vlan on the switch). I don't offer IPv6 in this segment at all, and only allow it to access the internet as well as my local #dns server. Putting all tv sets and my #minidlna instance into this segment, everything finally works.

The nice thing is, I always wanted to isolate the tv sets anyways, and this is now finally done, they're unable to see the rest of my home network! Still a bit sad I have to restrict them to IPv4 for now, just to work around netflix' geolocation stuff...

I’m currently playing around with DNSSEC. I have a hidden primary BIND server sign my zone and push it to publicly-visible secondaries.

But for KSK rollovers, I have to use my registrar’s REST API to publish a new DS record set.

With opendnssec, when it’s time to publish a new set of DS records, it can call a script to that effect. Can BIND also run such custom commands?

Someone here know their way around #bind9 releases? I expected v9.20 end of March 2024 as documented in https://kb.isc.org/docs/aa-00896 :/

https://gitlab.isc.org/isc-projects/bind9/-/milestones/69#tab-issues also does not really help with an ETA

#dns
@iscdotorg

Bild ich mir das ein?
Am #Debian #Laptop vorhin an den #DNS Einstellungen gebastelt. Browsen geht nun etwas fixer als zuvor...

#Bind9 installileren

sudo nano /etc/systemd/resolved.conf

DNS=IP Adresse vom DNS anbieter ;-)
FallbackDNS=alternativ IP
DNSSEC=yes
DNSOverTLS=yes
ReadEtcHosts=yes

sudo systemctl restart systemd-resolved

fertig

ugh i don't even know how to search for this properly

there's a domain that lists two DNS servers, one is fine, the second is a non-resolving hostname. it's not just not answering: it doesn't even resolve to an IP address.

(no, it's not just me, google DNS can't resolve the broken one either.)

if _my_ instance of bind9 on _my_ domain's DNS server tries the broken nameserver first, it obviously fails to resolve in any form.

the problem is that it does _not_ proceed to try the server that I know is working, and it should.

i've told the domain's owner that their DNS is fucked up and how, but really, I shouldn't've ever noticed.

anybody got any ideas why bind9 isn't trying the second server? because this is dumb.

Anyone notice that dumping the cache with unbound-control dump_cache in #Unbound is a lot slower than rndc dumpdb in #bind9

"apt update" on a Sunday night and my e-mail starts filling up with cron errors:

"Use of K* file pairs for HMAC is deprecated"

That -k syntax is still in the manual page, so I have no idea what happened. Looking at BIND 9 release notes the only thing which seems possibly related is this:

"The ability to read HMAC-MD5 key files, which was accidentally lost in BIND 9.18.8, has been restored."

But that is about *restoring* access, and Debian is at 9.18.19, so it should be fixed?

Portava dies revisant la configuració tant del servidor #DNS #Bind9 com de systemd-resolved i no hi havia manera d'aconseguir evitar el fotimer de "SERVFAIL":

cat /var/log/named/general|grep "query failed (SERVFAIL)" |wc -l
34532

Al final he desinstal·lat Bind9 i he aturat l'unitat systemd-resolved i en el seu lloc tinc funcionant el servidor DNS #Unbound
Ja porta 10 hores funcionant sense cap problema ni cap error.
A Ubuntu Server 22.04 Bind9 i systemd-resolved estan trencats, no van.

How to completely disable DNSSEC in bind9 for exactly one zone?