Asked on Bluesky and got no responses, so I'm going to ask here where there are more techies and fewer poasters: is there an actual specification for the RFC 1035 "master file format" representation of TXT records? #DNS
=> More informations about this toot | More toots from wollman@mastodon.social
@wollman https://chatgpt.com/share/67355d86-bbbc-800f-b991-d8eeaef8983c
=> More informations about this toot | More toots from schizanon@mastodon.social
@wollman RFC8499: " Presentation format: The text format used in master files. This
format is shown but not formally defined in [RFC1034] or
[RFC1035]. The term "presentation format" first appears in
[RFC4034].". So lots of things back then are not formally specified. Early `bind` implementations are kind of authoritative. And `TXT` being the biggest lie of all, as they are binary content, not characters at all. 1/x
=> More informations about this toot | More toots from pmevzek@framapiaf.org
@wollman But the core answer is really in RFC1035 as such: ยง3.3.14 gives us: "TXT-DATA One or more s." and then ยง5.1 has: " is expressed in one or two ways: as a contiguous set
of characters without interior spaces, or as a string beginning with a "
and ending with a ". Inside a " delimited string any character can
occur, except for a " itself, which must be quoted using \ (back slash)."
=> More informations about this toot | More toots from pmevzek@framapiaf.org
@pmevzek So I've seen all that. But any character? NUL? CR-LF? Bare backslashes? Is the same syntax for octal escapes as for unquoted strings also accepted in quoted strings?
=> More informations about this toot | More toots from wollman@mastodon.social
@wollman As I said at the beginning "So lots of things back then are not formally specified.". Also, everywhere document says "character" it should say "byte" in fact.
=> More informations about this toot | More toots from pmevzek@framapiaf.org
@wollman Granted, this still doesn't specify things 100%. Because everyone uses "a" "b"
where the quoted text doesn't prohibit "a"XXXX"b"
either. In fact, at least dnspython
will parse that as 3 character strings.
=> More informations about this toot | More toots from pmevzek@framapiaf.org
@pmevzek Length limits are unclear too. I found by error-and-trial-and-error that there's a shorter limit on the individual quoted-string bits, and the querier apparently just glues the multiple strings together in the common cases (like DKIM keys)?
=> More informations about this toot | More toots from wollman@mastodon.social
@wollman That part, on length is clear: since on the wire each character string has its length encoded as one byte in front of it, it makes each character string at most 255 bytes long. As for multiple strings, there are 2 cases: glued without space (SPF, DKIM, DMARC), or considered as key=value
so not glued at all/or glued with a space (for DNS-SD, and idea expressed at RFC1464 the start of the crazyness of TXT abuse). This is spelled out in each RFCs for those protocols.
=> More informations about this toot | More toots from pmevzek@framapiaf.org
@wollman You are probably best off consulting your authoritative name server software. Probably ISC's specifically. Here is the closest thing I could find where they say something more about the TXT format specifically: https://kb.isc.org/v1/docs/en/aa-00356
The minimal guidance from that RFC was essentially based on the initial BIND implementation. While many alternatives now support a BIND file format, this is largely an accident of history. The "standard" is really just what BIND does.
Implementations are free to use whatever format (or database for example) they like.
There is a bit more detail in the BIND ARM but no specific examples for TXT RRs that I could find: https://bind9.readthedocs.io/en/stable/chapter3.html#soa-rr
=> More informations about this toot | More toots from jtk@infosec.exchange
@jtk I am always amused to see DNS documents from before the introduction of EXAMPLE that contain names that (a) still exist, and (b) point to systems that I operate.
=> More informations about this toot | More toots from wollman@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini