Zum Spaß hatte ich mir einen VPS in Japan geklickt. Was damit anfangen? Einen weiteren DNS-Server aufsetzen natürlich. Gute Idee? Nicht wirklich. Der Server steht am anderen Ende der Welt, hat höhere Antwortzeiten und der Resolver wählt zufällig, welchen DNS er fragt. Sporadisch deutlich langsamere Antworten also. Aber für den Spieltrieb war das OK.
FreeBSD 10, BIND 9.11, als Slave für drei Zonen (kernel-error.org, .com, .de). System gepatcht, BIND installiert, DNSSEC-Validierung getestet (TCP, UDP, größer 512 Bytes), alles sauber. Als Slave eingebunden, nochmal getestet, dann bei den übergeordneten Zonen eintragen lassen.
Das Problem
Die Zonen .org und .com haben den neuen Nameserver anstandslos aufgenommen. Die .de-Zone (DENIC) meckerte: DNS-Timeout bei IPv6. Nur bei IPv6. Per dig und drill lief alles einwandfrei:
dig @2001:310:6000:f::1fc7:1 +edns +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de. dig @2001:310:6000:f::1fc7:1 +tcp +edns +norec +bufsize=4096 kernel-error.com IN MX +short 10 smtp.kernel-error.de.
BIND macht keinen Unterschied zwischen IPv4 und IPv6. Alles beantwortet, alles sauber. Auch tcpdump zeigte nichts Auffälliges. PF deaktiviert, kein Unterschied. Provider filtert nicht (nur Switch, iptables und ebtables auf der Infrastruktur, klingt spartanisch). DNSViz meldete ebenfalls einen Fehler, genau wie DENIC.
Die Fehlermeldung der DENIC-API:
ERROR: 223 Timeout after switching from UDP to TCP - switch to TCP due to timeout (target) (ns3.kernel-error.com./2001:310:6000:f:0:0:1fc7:1:53)
Der Query-Log
Query-Log aktiviert. Man sieht die Anfragen der DENIC (2a02:568:201:214::1:15) ankommen und beantwortet werden. UDP, TCP, EDNS, DNSSEC-Queries, alles da:
30-Jan-2017 18:30:04.669 client 2a02:568:201:214::1:15#38145: query: ns3.kernel-error.com IN A -E(0)DC 30-Jan-2017 18:30:04.670 client 2a02:568:201:214::1:15#41589: query: ns3.kernel-error.com IN AAAA -E(0)DC 30-Jan-2017 18:30:04.938 client 2a02:568:201:214::1:15#20703: query: kernel-error.de IN SOA - 30-Jan-2017 18:30:05.510 client 2a02:568:201:214::1:15#58465: query: kernel-error.de IN NS -T 30-Jan-2017 18:30:05.889 client 2a02:568:201:214::1:15#47548: query: kernel-error.de IN SOA -E(0)D 30-Jan-2017 18:30:05.896 client 2a02:568:201:214::1:15#55493: query: kernel-error.de IN DNSKEY -E(0)D 30-Jan-2017 18:30:06.416 client 2a02:568:201:214::1:15#37170: query: kernel-error.de IN DNSKEY -E(0)TD
Die Auflösung
Während ich einem Kollegen das Problem demonstrieren wollte, lief das DENIC-Update plötzlich einfach durch. Keine Änderung meinerseits. Die Antwort von DENIC kam dann auch:
Unsere Kollegen können derzeit nicht genau sagen woran es hängt. Jedoch sind unsere Verbindungen nach Korea zeitweise leicht beeinträchtigt, evtl. wurde die Nast-Prüfung genau in dem Moment durchgeführt.
Vermutlich lag es an der Antwortzeit von 200–300 ms, die zusammen mit einem Routing-Problem auf der DENIC-Seite gerade so in einen Timeout lief. Offiziell geklärt wurde es nie. Ein leicht ungutes Gefühl bleibt.
Die tcpdump-Mitschnitte von damals liegen hier: dns.tar.gz. Wer sich für DNSSEC-Grundlagen interessiert: DNSSEC einrichten mit BIND. Fragen? Einfach melden.