Format danych TXT w rekordzie DNS?

9

Rekord TXT dla mojej domeny ma obecnie prawne wyłączenie odpowiedzialności i warunki. Zostały dodane jakiś czas temu z powodu spamerów i innych przestępców (aby zapewnić mi legalną trakcję, jeśli kiedykolwiek będę tego potrzebować).

Muszę dodać więcej informacji, które różnią się od pierwszych. Zgodnie z RFC 1035, 3.3.14 :

3.3.14. TXT RDATA format


    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   TXT-DATA                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

TXT-DATA        One or more <character-string>s.

TXT RRs are used to hold descriptive text.  The semantics of the text
depends on the domain where it is found.

Jak dokładnie dodawany jest drugi (lub trzeci) ciąg? Jakie są / są ograniczniki TXT-DATA?

Czy mogę dodać drugi (lub trzeci) rekord TXT? Czy dozwolone są nawet wielokrotne zapisy TXT?

jww
źródło

Odpowiedzi:

9

W przypadku namednajpopularniejszego serwera DNS można użyć dowolnego z następujących formularzy, aby utworzyć dłuższy rekord TXT:

  • Jeden ciąg, jedna linia:

    name IN TXT "very long string here"
    
  • Wiele ciągów w jednej linii:

    name IN TXT "very long " "string here"
    
  • Wiele ciągów, po jednym w wierszu, w nawiasach:

    name IN TXT ("very long "
                 "string here")
    

W przypadku form wielostrunowych łańcuchy są po prostu konkatenowane razem dosłownie (wszystkie powyższe przykłady dają identyczny wynik).

Zauważ, że większość narzędzi DNS nie obsługuje jawnego tworzenia wielu rekordów TXT przeciwko nim name. Ponadto w rzeczywistości większość rekordów TXT jest wykorzystywana do SPF lub DKIM. Nawet jeśli w jakiś sposób uda ci się utworzyć wiele rekordów TXT przeciwko temu samemu name, dla SPF byłoby to nielegalne i jako takie nie jest zalecane.

Spójrz także na to z innego punktu widzenia. Na przykład możesz mieć wiele Arekordów dla danej nazwy, co służy do określenia, że ​​Twoja witryna ma więcej niż jeden serwer. Jednak zgodnie z regułami DNS musi on automatycznie losować ich kolejność na podstawie zapytania DNS (inaczej round robin), tak aby większość żądań klientów była równo podzielona między wszystkie adresy IP.

Jeśli utworzysz wiele rekordów TXT, oznacza to, że DNS również musi je losowo losować i musi ci je przekazać w ŻADNEJ kolejności. To byłoby bardzo niezręczne: twój tekst będzie czytał jako

"very long ", "string here"

lub jako

"string here", "very long "

Innymi słowy, nie próbuj tego robić - po prostu utwórz pojedynczy wieloliniowy rekord TXT i nazwij go dniem.

mvp
źródło
OK, więc w końcu miałem okazję wrócić do tego ... Popularny moduł sprawdzania SPF nie może obsłużyć wielu ciągów w jednym rekordzie TXT; parser SPF również nie może być na [email protected](jest to adres e-mail i zwraca automatyczny raport).
jww
Myślę, że posiadanie wielu rekordów TXT dla tej samej nazwy jest łatwe i całkowicie poprawne, przy użyciu jednego z nich dla SPF. RFC 7208 sekcja 4.5 stwierdza, że ​​rekordy, które nie zaczynają się od v=spf1powinny być ignorowane.
Martin
Co to jest separator binarny w pakiecie?
CoolAJ86,
Ciągi nie są ani konkatenowane, ani nie powodują wielu rekordów TXT - może istnieć wiele rekordów txt z wieloma oddzielnymi łańcuchami, a łączenie ich byłoby niewłaściwe dla niektórych aplikacji.
Pamiętaj Monikę
@MarcLehmann: twój komentarz nie ma sensu. Ciągi mogą się łączyć (np. Przy użyciu postaci wielowierszowej, jak opisano powyżej), ale może istnieć wiele rekordów TXT (być może przy użyciu tych długich ciągów). Istotą tej odpowiedzi jest to, że używanie wielu rekordów TXT nie jest zalecane, ponieważ może to mylić narzędzia, które oczekują tylko 1 rekordu TXT.
mvp