Hi Alex,
leider habe ich das Thema nicht weiter verfolgt. Ich vermute aber, dass es am Netz von Netcup liegt. Da ich zumindest einen funktionierenden IPv6 Nameserver habe, vertraue ich darauf, dass der genutzt wird und nicht ausfällt 
Hast du schon mal mit verschiedenen Betriebssystemen herumprobiert?
VG
Flo
Sorry, habe über die Feiertage nicht daran gesessen.
Was ich heute noch herausfinden konnte, dass irgendwo auf der Strecke IP Fragmente gefiltert werden müssen.
Undzwar gibt es den OARC's DNS Reply Size Test (OARC's DNS Reply Size Test Server | DNS-OARC)
Den habe ich mit drei verschiedenen vServern ausprobiert, da die Pakete laut TCPDUMP fragmentiert werden:
16:01:07.729024 IP6 tartaros.flexhost.it.54395 > gaia.flexhost.it.domain: 8738+ [1au] MX? serverkostenlos.eu. (47)
16:01:07.729398 IP6 gaia.flexhost.it > tartaros.flexhost.it: frag (0|1232) domain > 54395: 8738*- 2/5/13 MX gaia.flexhost.it. 10, RRSIG (1224)
16:01:07.729409 IP6 gaia.flexhost.it > tartaros.flexhost.it: frag (1232|1232)
16:01:07.729411 IP6 gaia.flexhost.it > tartaros.flexhost.it: frag (2464|234)Der problematische Server gibt folgendes im Test aus:
dig +short rs.dns-oarc.net txt
rst.x1008.rs.dns-oarc.net.
rst.x1253.x1008.rs.dns-oarc.net.
rst.x1447.x1253.x1008.rs.dns-oarc.net.
"2a03:4000:6:401b::1 sent EDNS buffer size 4096"
"2a03:4000:6:401b::1 DNS reply size limit is at least 1447"
"Tested at 2015-01-02 16:13:45 UTC"
Ein anderer vServer von netcup in einem anderen Netz:
dig +short rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
rst.x4090.rs.dns-oarc.net.
rst.x4060.x4090.rs.dns-oarc.net.
rst.x4066.x4060.x4090.rs.dns-oarc.net.
"Tested at 2015-01-02 16:52:55 UTC"
"2a03:4000:6:110b::1 sent EDNS buffer size 4096"
"2a03:4000:6:110b::1 DNS reply size limit is at least 4090"
Und ein anderer vServer von einem anderen Provider:
dig +short rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
rst.x4050.rs.dns-oarc.net.
rst.x4060.x4050.rs.dns-oarc.net.
rst.x4066.x4060.x4050.rs.dns-oarc.net.
"Tested at 2015-01-02 16:42:43 UTC"
"2001:41d0:52:d00::cc3 sent EDNS buffer size 4096"
"2001:41d0:52:d00::cc3 DNS reply size limit is at least 4066"
Daher auf die Timeouts, die du erhalten hast. Das konnte ich sogar innerhalb der netcup-Netze nachvollziehen:
traceroute to gaia.flexhost.it (2a03:4000:6:401b::1), 30 hops max, 80 byte packets
1 2a03:4000:6:1000::2 (2a03:4000:6:1000::2) 0.616 ms 0.572 ms 0.563 ms
2 gaia.flexhost.it (2a03:4000:6:401b::1) 0.489 ms 0.496 ms 0.488 ms
dig @2a03:4000:6:401b::1 MX serverkostenlos.eu +dnssec
; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> @2a03:4000:6:401b::1 MX serverkostenlos.eu +dnssec
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Also entweder netcup hat eine Firewall zwischen den Netzen oder aber es liegt am vServer.
Habe schon mit verschiedenen Netzwerkkarten herumprobiert, aber auch ohne Erfolg.
Habe ehrlich gesagt keine Lust auf Verdacht den Server neu zu installieren, weil es ein Produktivsystem ist, aber mir fällt gerade keine andere Möglichkeit ein...
Die Antworten für DNSKEYs und MX-Records sind gezwungenermaßen größer, ja.
Das Reproduzieren ist leicht: Ich aktualisiere die Domain und setze dabei die IPv6-Adresse als zusätzlichen Nameserver. Das reicht schon, wenn der Server mit abgefragt wird, also in der Zone steht und bei der EURid aktualisiert wird.
Es geht um die Domain serverkostenlos.eu, hier mal der Direktlink zum dnsviz: serverkostenlos.eu | DNSViz
Die IPv6-Adresse, die dabei Probleme macht: 2a03:4000:6:401b::1
Laut der Beschreibung versucht der Server einen Payload zu senden der größer ist, als er senden kann.
[Blockierte Grafik: http://dnsviz.net/static/images/dnssec_legend/dnskey-warning.png]If a yellow warning symbol appears in the DNSKEY node, it is because one or more authoritative servers have a path MTU (PMTU) problem. Such servers are attempting unsuccessfully to send a payload larger than what that of which they are capable.
Das komische ist auch, dass der Fehler nur bei den DNSKEYs und beim MX-Record auftritt.
Der EURid-Robot meldet dadurch beim DNSKEY einen Timeout beim aktualisieren der Domain.
DynUpdate completed for domain name: xxxxxxx.eu; Result: An error occurredError code 257: An issue occurred while querying 1234:1234:1234:1234::1#53 for host name xxxxxxx.eu.: timeout
Die Masterarbeit habe ich mir mal durchgelesen und habe daher mal die MTU auf 1280 gesetzt, was aber auch nicht geholfen hat.
Ich habe auf beiden Servern mal ein tcpdump laufen lassen und sehe, dass Pakete fragmentiert werden, da sie größer als die MTU sind. Das ist ansich ja kein Problem. Ich bekomme auch keine Packet too Big Pakete zurück. Also scheint das PMTU Discovery zu funktionieren, denke ich.
Kann es sein, dass Netcup im Netz irgendwo Pakete filtert (seien es ICMP oder fragmentierte Pakete)?
Daran dachte ich auch zwischenzeitlich, aber ich habe eigentlich ICMP auf IPv6 Ebene erlaubt:
ip6tables -A INPUT -p icmpv6 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 -j ACCEPT
Mittlerweile habe ich alles erlaubt:
ip6tables -vnL
Chain INPUT (policy ACCEPT 347 packets, 38266 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 338 packets, 331K bytes)
pkts bytes target prot opt in out source destination
Funktioniert leider trotzdem nicht.
Hallo zusammen,
ich habe mir auf einem vServer einen Bind-Nameserver installiert, der über IPv4 und IPv6 erreichbar ist.
Das Ganze funktioniert auch problemlos.
Jetzt verwende ich für meine Domains DNSSEC.
Wenn ich jetzt über dnsviz.net den DNSSEC-Status überprüfen möchte, erhalte ich die Warnung PMTU_EXCEEDED.
Das hängt mit der Paketgröße bzw. der Fragmentierung zusammen.
Kennt sich hier jemand mit dem Thema aus und weiß, was den Fehler verursacht? Denn dadurch kann der EURid-Robot (für eine .eu-Domain) den DNSKEY nicht überprüfen und freischalten.
Bei einem anderen vServer, ebenfalls über IPv6, bei einem anderen Anbieter (zwecks höherer Redundanz), gibt es das Problem nicht.
Herzlichen Dank für jegliche Hilfe!
