Nameserver unter IPv6 (DNSSEC, PMTU)

  • 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!

  • 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.

  • Laut der Beschreibung versucht der Server einen Payload zu senden der größer ist, als er senden kann.
    [Blocked Image: 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)?

  • Möglich wäre schon, dass netcup Pakete filtert. Es könnte aber auch irgendein Router auf dem Weg zwischen dsnviz/EURid und deinem Server schuld sein. Allerdings glaube ich nicht, dass das Problem hier liegt.


    Sind die Antworten für die RRs DSNKEY und MX größer als A und AAAA? Das würde erklären, warum das Problem nur bei diesen auftritt. Hast du schon versucht, das Problem irgendwie zu reproduzieren? Um welche Domains und Server handelt es sich denn? Dann kann ich das gern selbst mal versuchen.

  • 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

  • Hm, irgendwas ist da faul. Folgender Befehl bringt mir ein Timeout:

    Code
    1. dig @2a03:4000:6:401b::1 MX serverkostenlos.eu +dnssec


    Lasse ich aber die Option +dnssec weg oder nutze deinen anderen DNS-Server (2001:41d0:52:d00::cc3) funktioniert es.


    Auf dem Responses-Tab von dnsviz sieht man, dass manche Antworten von diesem Server deutlich kleiner sind als von den drei anderen Servern. Dies deckt sich aber nicht mit dem PMTU_EXCEEDED von MX und DNSKEY.

  • 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:




    Code
    1. 16:01:07.729024 IP6 tartaros.flexhost.it.54395 > gaia.flexhost.it.domain: 8738+ [1au] MX? serverkostenlos.eu. (47)
    2. 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)
    3. 16:01:07.729409 IP6 gaia.flexhost.it > tartaros.flexhost.it: frag (1232|1232)
    4. 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...

  • Welcher Nameserver beantwortet denn jeweils diese Anfragen? Wenn du mal das +short weglässt, steht dabei, von welchem Nameserver die Antwort liefert.

    Code
    1. ;; SERVER: 46.38.252.230#53(46.38.252.230)


    Was mich aber sehr stutzig macht ist folgende Zeile in zwei deiner drei Listings:

    Code
    1. ;; Truncated, retrying in TCP mode.


    Dies deutet darauf hin, dass irgendetwas große UDP-Pakete blockiert und als fallback deshalb TCP genutzt wird. Ich konnte das aber auf keinem vserver bei netcup reproduzieren. Interessanterweise tritt das Problem auf dem problematischen Server genau nicht auf. Dieser Server hat dafür eine sehr geringe reply size. Laut der Website ist das aber nicht eindeutig, nur bei einer size von weniger als 1400 is das ein Indikator für Blockade.

  • ich habe das Problem auch ....
    siehe:


    flauschfunk.de | DNSViz


    FloMeyer bist du denn weiter gekommen?



    • flauschfunk.de./A: No response
      was received until the UDP payload size was decreased, indicating that
      the server might be attempting to send a payload that exceeds the path
      maximum transmission unit (PMTU) size.
      (2a03:4000:6:3043::1)
    • flauschfunk.de./AAAA: No
      response was received until the UDP payload size was decreased,
      indicating that the server might be attempting to send a payload that
      exceeds the path maximum transmission unit (PMTU) size.
      (2a03:4000:6:3043::1)
    • flauschfunk.de./MX: No
      response was received until the UDP payload size was decreased,
      indicating that the server might be attempting to send a payload that
      exceeds the path maximum transmission unit (PMTU) size.
      (2a03:4000:2:5f::1, 2a03:4000:6:3043::1)
    • flauschfunk.de./SOA: No
      response was received until the UDP payload size was decreased,
      indicating that the server might be attempting to send a payload that
      exceeds the path maximum transmission unit (PMTU) size.
      (2a03:4000:6:3043::1)
    • flauschfunk.de./TXT: No
      response was received until the UDP payload size was decreased,
      indicating that the server might be attempting to send a payload that
      exceeds the path maximum transmission unit (PMTU) size.
      (2a03:4000:6:3043::1)

    Bei mir tritt das problem bei zwei netcup vservern auf
    lg,
    alex

  • 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 :-D


    Hast du schon mal mit verschiedenen Betriebssystemen herumprobiert?


    VG
    Flo

  • Guten Abend,

    Quote

    Ich vermute aber, dass es am Netz von Netcup liegt.

    woran machen Sie das fest?


    Was ich mir vorstellen kann, ist dass das an dem Treiber von VirtIO liegt. Daher könnten Sie Testhalber über das VCP die Netzwerkkarte auf den e1000 Chipsatz umstellen. Hier kommt dann seitens des Kernels ein Intel-Treiber zum Einsatz. Dieser ist in machen Dingen stabiler.



    Mit freundlichen Grüßen


    Felix Preuß

  • Guten Abend,

    woran machen Sie das fest?


    Was ich mir vorstellen kann, ist dass das an dem Treiber von VirtIO liegt. Daher könnten Sie Testhalber über das VCP die Netzwerkkarte auf den e1000 Chipsatz umstellen. Hier kommt dann seitens des Kernels ein Intel-Treiber zum Einsatz. Dieser ist in machen Dingen stabiler.
    \[..\]
    Felix Preuß


    ich habe auf einer Maschine bei Ihnen eine e1000 und auf der anderen eine virtio ... bei beiden tritt das Problem auf.


    Mit freundlichen Grüßen
    alex


    ps ich habe schon mit so manchen gesprochen .... aber noch führt es nicht zu einer idee wie sich das gescheit testen lässt :(


    es könnte ja auch ein Problem bei DNSViz | A DNS visualization tool sein .... dieses IPv6 :P ;( :love:

  • Laut RFC1981
    It is possible that a packetization layer, perhaps a UDP application outside the kernel, is unable to change the size of messages it sends. This may result in a packet size that exceeds the Path MTU.To accommodate such situations, IPv6 defines a mechanism that allows large payloads to be divided into fragments, with each fragment sent in a separate packet (see [IPv6-SPEC] section "Fragment Header").


    File:
    /proc/sys/net/ipv4/route/min_pmtu #default 552, den ggf. mal etwas erhöhen.
    Hinweis:
    Most probably there will be 40 additional bytes for the IP and TCP headers leading to 512 + 20 + 20 = 552.That's Linux's minimum PMTU!

    Du kannst es auch mal probeweise aus/einschalten:
    "echo 0 >/proc/sys/net/ipv4/ip_no_pmtu_disc" => ausschalten
    "echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc" => einschalten