Hallo.
Der reverse IPv6 DNS für Mail.guetersloh.freifunk.net geht nicht, daher werden Mails von Gmail und Freunden abgelehnt.
Das erinnert mich daran daß ich den Mailserver ja Mal neu machen wollte. Gibt’s dafür ne VM?
Cord
Ich habe mir das jetzt angesehen und ich verstehe das Konstrukt nicht.
Authorativ für 4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa ist dns-fks. Für diese Zone gibt es ZWEI Zonenfiles:
/var/cache/bind/zonen/4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa
/var/cache/bind/zonen/2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa.upstream
Zusätzlich gibt es in /var/cache/bind/zonen/4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa einen Referal für 2.4.0.0 auf v6.dns.as206946.net.
as206946.net. ist nun wiederum eine Zone die auf de3.dn42.uu.org und librarian.uu.org zeigen.
Beisst sich alles, aber vielleicht gibt es ja eine tiefere Weisheit für dieses Setup?
V6-DNS läuft über all-knowing-dns. Versuch, das per forwarding des Bind zu lösen schlug fehl, daher Delegation direkt auf a-k-d. Die .upstream wird von a-k-d referenziert für ‘echte’ Einträge, die .upstream servieren die Binds.
–verbose, da nun am Rechner:
Generell: die Zonen sind (sollten sein) an dns-gut.4830.org, dns-fks.uu.org delegiert, z. B. 4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. oder 1.3.1.7.f.b.0.1.0.0.2.ip6.arpa. (IN-Berlin ist im Zuge der Delegation für Lippe im ~Mai dazu übergegangen, den gesamten Nibble-Boundary der /44 zu delegieren, statt die 16 Zonen einzeln — dunno, ob ich das schon überall korrigiert habe).
Da v6-DNS wegen der Größe nur generiert funktionieren kann, setze ich all-knowing-dns ein, davon sollte mittlerweile je eine Instanz auf dns-gut und dns-fks laufen — und für die .upstream den lokalen Bind fragen. Bei Hetzner habe ich keine v4-IP frei, daher lauscht er auf dns-fks nur auf einer separaten v6-Adresse.
Ich hatte mal versucht, den bind9 auf dns-fks/dns-gut so zu konfigurieren, daß die konkrete /64 über forwarding durch den Bind9 vom All-Knowing-DNS geholt wird, das schlug aber fehl wegen … weißichnichtmehr. Ich glaube das biß sich mit den Restriktionen bzgl. Rekursivität, Caching usw. — Primary selbst zu fahren macht auch keinen Spaß mehr 
Lösung daher: Die Zonen, z. B. 2001:bf7:170::/64, werden direkt an die a-k-d deligiert (aus der entsprechenden Zone unter Bind-Kontrolle). Bis vor ein paar Monaten gab’s allerdings nur den einen in Falkenstein, den ich v6.dns.as206946.net. nannte. Erst später, in einem Anlauf, das mal redundant auszulegen, kam die Instanz auf dns-gut.4830.org hinzu. (Generell sehe ich eigentlich auch keine Notwendigkeit, v6-DNS für v4-only NS erreichbar zu machen. Aber in GUT war halt noch 'ne v4 “frei”.)
Und ja, das gehört alles mal aufgeräumt (und vorzugsweise per Ansible konfiguriert). Dazu gehörte auch Monitoring, denn …
root@dns-gut:~# systemctl status all-knowing-dns.service
● all-knowing-dns.service - Tiny DNS server for IPv6 Reverse DNS
Loaded: loaded (/lib/systemd/system/all-knowing-dns.service; enabled; vendor
Active: failed (Result: exit-code) since So 2020-08-02 14:47:36 CEST; 1 month
Main PID: 11260 (code=exited, status=255)
Nach dem Restart tut a-k-d wieder:
wusel@luggage:~$ dig +short -x 2001:bf7:170::7 @2a06:e881:1700:1:400::5353:5353
0000000000000007.clients.mueritz.freifunk.net.
wusel@luggage:~$ dig +short -x 2001:bf7:170::5 @2a06:e881:1700:1:400::5353:5353
mueritz-bgp1.mueritz.freifunk.net.
“mueritz-bgp1.mueritz.freifunk.net.” kommt hierbei aus der .upstream-Zone, für die ::7 gab’s keinen Eintrag, also wird einer erzeugt, ebenso bei der Frage nach AAAA:
wusel@luggage:~$ dig +short aaaa 0000000000000007.clients.mueritz.freifunk.net. @2a06:e881:1700:1:400::5353:5353
2001:bf7:170::7
Jetzt klarer? Zonenfiles für Master lege ich traditionell in /var/cache/bind/zonen/ ab, Zonen, wo der Bind nur Slave macht, liegen in /var/cache/bind/slave.
Ah, siehe netbox.4830.org, 2a06:e881:1700::/44 ist der Bereich, mit dem 4830.org-Server arbeiten; 2a06:e881:2600::/44 nutzen meine Server (HAM, AMS). mail.4830.org läuft auf meiner Kiste in HAM (“ham01” für FFGT), daher hat die eine v6 aus AS49745/AS206946. 49745 fällt leider aus Zeitmangel meist eher hinten runter …
Also: 4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. (2a06:e881:2604::/48) ist an dns-fks, dns-gut delegiert.
Darin wird 2.4.0.0 (also 2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa., d. h. 2a06:e881:2604:42::/64) an v6.dns.as206946.net. delegiert.
Das ist der a-k-d, der auf 2a01:4f8:211:132a::53 lauscht (das /64 meiner Büchse bei Hetzner), konkret auf dns-fks:
root@dns-fks-new:~# head /etc/all-knowing-dns.conf
# Configuration file for AllKnowingDNS v1.3
listen 2a01:4f8:211:132a::53
network 2a07:a907:50c:1000::/64
resolves to %DIGITS%.ipv6.uu.org
with upstream 2a01:4f8:211:132a:400:88ff:fef3:163a
network 2001:678:2c0:1::/64
resolves to %DIGITS%.gto.uu.org
with upstream 2a01:4f8:211:132a:400:88ff:fef3:163a
[…]
Der a-k-d soll also 2a01:4f8:211:132a:400:88ff:fef3:163a als “upstream” nehmen, sprich dort in der $zone.upstream gucken, ob ein realer Eintrag existiert.
Dummerweise hat die neue dns-fks-VM statt 2a01:4f8:211:132a:400:… IPs mit 2a01:4f8:211:132a:0: bekommen; vermutl. habe ich da das falsche Netzwerk in ONe angeklickt, als ich die VMs initialisierte. Aber daher tut das eher nicht:
root@dns-fks-new:~# host dns-fks.uu.org
dns-fks.uu.org has address 136.243.22.58
dns-fks.uu.org has IPv6 address 2a01:4f8:211:132a:400:88ff:fef3:163a
root@dns-fks-new:~# ip addr show ens3 |grep fef3:163a
inet6 2a01:4f8:211:132a:0:88ff:fef3:163a/64 scope global
inet6 fe80::88ff:fef3:163a/64 scope link
root@dns-fks-new:~# netstat -antup | grep named
tcp 0 0 136.243.22.58:53 0.0.0.0:* LISTEN 31529/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 31529/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 31529/named
tcp6 0 0 ::1:953 :::* LISTEN 31529/named
udp 0 0 136.243.22.58:53 0.0.0.0:* 31529/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 31529/named
udp6 0 0 :::45864 :::* 31529/named
Nice, Bind startet, obwohl er sich nicht an die IP binden kann?!
root@dns-fks-new:~# ip -6 addr add 2a01:4f8:211:132a:400:88ff:fef3:163a/64 dev ens3 ||:
root@dns-fks-new:~# netstat -antup | grep named
tcp 0 0 136.243.22.58:53 0.0.0.0:* LISTEN 21987/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 21987/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 21987/named
tcp6 0 0 2a01:4f8:211:132a:40:53 :::* LISTEN 21987/named
tcp6 0 0 ::1:953 :::* LISTEN 21987/named
udp 0 0 136.243.22.58:53 0.0.0.0:* 21987/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 21987/named
udp6 0 0 2a01:4f8:211:132a:40:53 :::* 21987/named
Spannend, kaum macht man’s heile, tut’s auch:
wusel@luggage:~$ dig -x 2a06:e881:2604:42::4 @v6.dns.as206946.net.
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> -x 2a06:e881:2604:42::4 @v6.dns.as206946.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33971
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. 86400IN PTR mail.4830.org.
;; Query time: 66 msec
;; SERVER: 2a01:4f8:211:132a::53#53(2a01:4f8:211:132a::53)
;; WHEN: Sat Sep 05 17:24:05 CEST 2020
;; MSG SIZE rcvd: 117
wusel@luggage:~$ dig -x 2a06:e881:2604:42::4 @1.1.1.1
; <<>> DiG 9.11.3-1ubuntu1.13-Ubuntu <<>> -x 2a06:e881:2604:42::4 @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54975
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.4.0.0.4.0.6.2.1.8.8.e.6.0.a.2.ip6.arpa. 86400IN PTR mail.4830.org.
;; Query time: 441 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Sat Sep 05 17:24:19 CEST 2020
;; MSG SIZE rcvd: 200
Fazit: Man könnte akd-gut.4830.org und akd-fks.uu.org eintragen und die /64er Zonen, FF & UU, dorthin delegieren. Oder es hinbekommen, daß Bind die /64 vom all-knowing-dns, der auf z. B. auf ::1, Port 54 läuft, ziehen kann. v6.dns.as206946.net war halt der erste Versuch, irgendwie v6-PTR korrekt zu lösen.
Im Grunde sollte das Setup aber korrekt sein, aus /48-Zone wird /64 wegdelegiert? Das erscheint mir zumindest der logische/technisch korrekte Weg — keine Ahnung, ob man das »bei v6 eigentlich anders« macht 
Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Nachrichten mehr erlaubt.