Bug im DNS Tab für lange Strings

    Meddl Loide,

    in den DNS Settings habe ich das Problem, dass lange Strings scheinbar automatisch gesplittet werden aber die Logik scheint buggy zu sein, da sie am Ende einen unnötigen Empty String anhängt.

    Beispiel:

    Ich richte für meine Domain und meinen Mail Server einen dkim._domainkey TXT ein in der Länge 2048 oder länger, und kopiere das in das Destination Feld.

    Nutze ich dann später dig gegen meine Domain, erhalte ich eine offensichtlich gesplittete Version, allerdings mit diesem seltsamen Empty String Element am Ende:

    Code
    ;; ANSWER SECTION:
dkim._domainkey.<MEINE DOMAIN>.de. 424 IN    TXT    "v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzSs3I15YZQG8DgtEEM0hUu458fK9Sj4PBmWPzeobh8uVx6jWzuYDewW7SkQPmJDkzvs7VLYAAKwhOolffb4iYdC8k82i2VFjpR4MZZ1V+fmuA+UfnlP/9cFWVmNtTw5OXsNXLTAIZskGBoF8nEFWbi5CbyiX9m1rIsU4glBuiOqmDmXXgwF2E3T" "oa0hlacFw8u6BoED0VqPVwgG61eGvQPw4JTa+JxGYTmXzV00JXOxgjnnq4pvmRTSk1mgtNJzpYJ87oB/zw5Z+/PYk2HQQujttPvQyzbmELuLUutb3QkGqAczUYL43IGJLhf40FBQ0kvBgU1BbUrVXvByJzZy+UQIDAQAB" ""

    Es ist jetzt keine große Sache, aber tatsächlich mögen manche großen Mailcompanies das nicht, auf gmx erhalte ich dafür ein auth result: permerror wenn die versuchen meinen key zu lesen.

    Code
    Authentication-Results
:
gmx.net; dkim=permerror

    Dass es kein grundsätzliches Problem mit meinen Einstellungen ist, kann ich ausschließen, denn wenn ich auf eine Schlüssellänge von 1024 gehe, kommt es nicht zu dieser Split Automatik, und alles funktioniert fehlerfrei und auch bei gmx ändert sich das result auf dkim=pass.

    Somit bin ich mir eigentlich relativ sicher, dass der Fehler in einem Netcup Script liegt.

    Bevor ich den Support belästige wollte ich mal fragen, ob es schon jemand mal hinbekommen hat mit einem längeren Schlüssel oder TXT-Wert.

    VG

  • Zur hilfreichsten Antwort springen

    ich pack meine dkim keys mit 2 trennern " " im string in die zone datei - dann wird nicht mehr gemeckert

    "v=DKIM1; k=rsa; t=s; s=email;....adsfj;ldajsfldsajlkfjdlakfjs" "ladjlfjldkjfldjaslfhdsjahfl;asdjfla" "ladfjdlafldjlkfjdlkasjfljdkasjflkjds"

    The universe tends toward maximum irony. Don't push it.

    Einmal editiert, zuletzt von webdesignheld (18. Januar 2026 um 15:32)

    Hmm, meine Mail von einer Domain, deren DNS ebenfalls bei netcup ist und die auch einen leeren String am Ende anzeigt, wird von GMX nicht beanstandet (dkim=pass)

    Einmal editiert, zuletzt von tab (18. Januar 2026 um 15:41)

    Wild. Aber danke für die Info.

    Allen anderen sei gesagt, ich trage den Wert ja ohne jegliche Anführungszeichen ein! So nämlich:

    Code
    v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzSs3I15YZQG8DgtEEM0hUu458fK9Sj4PBmWPzeobh8uVx6jWzuYDewW7SkQPmJDkzvs7VLYAAKwhOolffb4iYdC8k82i2VFjpR4MZZ1V+fmuA+UfnlP/9cFWVmNtTw5OXsNXLTAIZskGBoF8nEFWbi5CbyiX9m1rIsU4glBuiOqmDmXXgwF2E3Toa0hlacFw8u6BoED0VqPVwgG61eGvQPw4JTa+JxGYTmXzV00JXOxgjnnq4pvmRTSk1mgtNJzpYJ87oB/zw5Z+/PYk2HQQujttPvQyzbmELuLUutb3QkGqAczUYL43IGJLhf40FBQ0kvBgU1BbUrVXvByJzZy+UQIDAQAB

    Habe jetzt eigentlich keine Lust, da irgendwelche String Magic selbst zu implementieren

    Ich sage auch ganz bestimmt nicht, dass ich diesen leeren String am Ende toll finde. Der kann von mir aus gern weg. Aber bin halt mit den entsprechenden Mails noch nirgends wegen fehlerhaftem DKIM angemeckert worden. Es wird dich nicht trösten, aber ich habe gerade mit dig den Domainkey meiner Testdomain für das neue DNS von netcup ausgelesen. Da ist kein "" am Ende.

    Zitat von tab

    Da ist kein "" am Ende.

    das kann ich bestätigen, bei mir auch nicht:

    Code
    "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzRxRxHB6e18qbmxYXEuzalEidXSzxsWphw5tBWiotaraL00DLRTY16mhWp9Rpkdd5M6YssbkbwUJEIVk/eZ5YRTSjM/eAsfMxw6WiXgTRQz4gxMAlenJ1ZwZ/fD" "XLrBzJi/ZN8wrbCUYPAvkYSzHubupCoZzw4ynMGLcOry9uo6blRk8044OuJjQ7o848sg0GUr97HFdii1hq8vY12qfQ+sBykOAP6J0xuqLom+OqinDKz/mksx6XTbpn+KY18F2vzNbgXV95" "OboXmKgqZZ50LwWUgaubW3D+JmtDxSbe/TwOJkjQR7B/j7rMyEWraaXgEgAQ5i95kI58qgyW18A7wIDAQAB"

    wenn man bei 220 splitted braucht man den 2ten trenner nicht wenn bei 165 schluss ist

    The universe tends toward maximum irony. Don't push it.

    3 Mal editiert, zuletzt von webdesignheld (18. Januar 2026 um 17:44)

    Merkwürdigerweise wurde aber auch dein String in 3 Teile geschnitten, aber in 3 relativ kurze, während es bei mir 2 lange Teile sind und am Ende das Leere.

    Ich weiß jetzt auch nicht, wieviel Zeit ich noch reinstecken will, da es mit 1024 funktioniert und ich auch keinen Bedarf habe, es zu ändern.

    • Hilfreichste Antwort

    " " quote Leerzeichen quote - das trennt den string damit es passt und wird aber vom parser ignoriert - der liest das nicht so wie ich das verstanden habe - da ist irgendein 255 zeichen max length im spiel - aber wie gesagt - hörensagen

    The universe tends toward maximum irony. Don't push it.

  • weiglt85 19. Januar 2026 um 12:29

    Hat einen Beitrag als hilfreichste Antwort ausgewählt.

    Laut RFC 1035 hat ein txt record den Datentyp

    Code
    <character-string> is a singlelength octet followed by that number of characters.  <character-string>is treated as binary information, and can be up to 256 characters inlength (including the length octet).

    Also max 255 Zeichen. Hast Du mehr, muss das ganze in mehrere Einträge aufgeteilt werden, dass sind die einzelnen "..." "...". Bei DKIM & co werden die einzelnen Teile dann einfach nach der DNS Abfrage vom Client zusammengefügt. Ein leerer String am Ende stellt da eigentlich überhaupt kein Problem dar, genauso egal sind Leerzeichen zwischen den einzelnen Strings

    Das heißt, binär wird also

    Code
    <character-string_n> = 0000 0000

    gesendet. Da kann ich schon verstehen, wenn ein Server auch mal sagt, "also naja...", für einen concat string scheint es einfach keinen Sinn zu machen.