"DNS propagation" isn't a real phenomenon, per se. Rather, it is the manifest effect of the caching functionality specified in the DNS protocol. Saying that changes "propagate" between DNS servers is a convenient falsehood that's, arguably, easier to explain to non-technical users than describing all of the details of the DNS protocol. It's not really how the protocol works, though.
Recursive DNS servers make queries on behalf of clients. Recursive DNS servers, typically run by ISPs or IT departments, are used by client computers to resolve names of Internet resources. Recursive DNS servers cache the results of queries they make to improve efficiency. Queries for already-cached information can be answered without making any additional queries. The duration, in seconds, that a result is cached is supposed to be based on a configurable value called the Time To Live (TTL). This value is specified by the authoritative DNS server for the record queried.
There is no one answer to all the questions being asked because DNS is a distributed protocol. The behavior of DNS depends on the configuration of the authoritative DNS server for a given record, the configuration of recursive DNS servers making queries on behalf of client computers, and DNS caching functionality built-in to the client computers' operating systems.
It's good practice to specify a TTL value short enough to accommodate neecssary day-to-day changes to DNS records, but long enough so to create a "win" in caching (i.e. not so short as to age-out of cache too quickly to provide any efficiency improvement). Employing a balanced strategy with TTL values results in a "win" for everyone. It reduces both the load and bandwidth utilization for the authoritative DNS servers for a given domain, the root servers, and the TLD servers. It reduces the upstream bandwidth utilization for the operator of the recursive DNS server. It results in quicker query responses for client computers.
As a DNS record's TTL is set lower load and bandwidth utilization on the authoritative DNS servers will increase because recursive DNS servers will not be able to cache the result for a long duration. As a record's TTL is higher changes to records will not appear to "take effect" quickly because client computers will continue to receive cached results stored on their recursive DNS servers. Setting the optimal TTL comes down to a balancing act between utilization and ability to change records quickly and see those changes reflected on clients.
It is worth noting that some ISPs are abusive and ignore the TTL values specified by the authoritative DNS servers (substituting their own administrative override, which is a violation of RFC). There's nothing to be done about this, from a technical perspective. If the operators of abusive DNS servers can be located complaints to their systems administrators might result in their implementing best practices (arguably what amounts to common sense for any network engineer familiar with DNS). This particular type of abuse isn't a technical problem.
If everybody "plays by the rules" changes to DNS records can "take effect" very quickly. In the case of changing the IP address assigned to an "A" record, for example, an exponential backoff of the TTL value would be performed, leading up to the time the change will be made. The TTL might start at 1 day, for example, and be decreased to 12 hours for a 24 hour period, then 6 hours for a 12 hour period, 3 hours for a 6 hour period, etc, down to some suitably small interval. Once the TTL has been backed-off the record can be changed and the TTL brought back up to the desired value for day-to-day operations. (It is not necessary to use an exponential backoff, however this strategy minimizes the time the record will have a low TTL and decreases load on the authoritative DNS server.)
After making a DNS record change logs should be monitored for access attempts being made as a result of the old DNS record. In the example of changing an "A" record to refer to a new IP address a server should remain present at the old IP address to handle access attempts resulting from client computers still using the old "A" record. Once access attempts based on the old record have reached an acceptably low level the old IP address can be disused. If the requests related to an old record are not abating quickly it is possible that (as described above) a recursive DNS server is ignoring the authoritative TTL. Knowing the source IP address of an access attempt, however, does not provide direct information as to the recursive DNS server responsible for supplying an old record. If the IP addresses of errant access attempts are all related to a single ISP it may be possible to locate the offending DNS server and contact its operator.
Personally, I've seen changes "take effect" immediately, in a few hours, and in some cases with a particular brain-damaged ISP, after several days. Doing a backoff of your TTL and being mindful of how the process works will increase your changes for success, but you can't ever be sure what some well-meaning idiot might be doing with their recursive DNS servers.
Best Answer
A little bit of background on TXT records and how these are used for DKIM
TXT
records are multi-valued, each value is a string that can be up to 255 bytes.In your example you started out with a suggested
TXT
record specified in the standard master file format that had three values.There being three values is indicated by the quotation marks, do note that these are not actually part of the record data, they only specify where each value start and end.
Your
TXT
value:means:
v=DKIM1; k=rsa; p=
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA7UNgSlnndT9JY0soSjxLhFFnvAeVN8b6Y3oKctAunNltMjvXfTD37doER8a9xwEOIXkGPgxJ5UPb/KndvHiIo+j8AScoIZCW1glFWp4AUoKlQkKP7o7vwFnWypU+DmcJAtyuhZ9X5yzag37cVRGYD4icd02yAETLbIpv1mnMUFkTnkdmtSa5gL2cLUueUOValoENwkWTcZR
+kraTEU/VDPIrRgNBu6OJmQdk0sv4qdkwVVvxvquT4C/SimQDoDaQwlFCp2sBryXyaNSRCaAhRxPaKUpKsPmubW0SJF2nQZ3DprJQcaRQLd9Qgxz+V+XaseaXXWPy+6rtB6BlPFk5FwIDAQAB
For the purpose of DKIM it's not actually meaningful to have multiple values, but as each value of a
TXT
record has limited length and the DKIM spec recognizes this and says that, for the purpose of DKIM, multiple values should simply be concatenated into one long string this allows for long keys.Ie, a DKIM client will concatenate the above values into the string
This also means that the above string could have been split at different positions without changing the meaning in DKIM.
Tinydns and TXT
Tinydns has two ways that you could possibly use to represent a
TXT
record (from https://cr.yp.to/djbdns/tinydns-data.html):1)
2)
It does not appear that the built in
TXT
support (1 above) allows for explicitly specifying multiple values but, while the manual does not state this, I found indications that it will split a long string on its own.Ie, something like this should work (assuming that the information on automatic splitting is actually correct):
The other option, the generic record support (2 above), will surely work as long as you give it the appropriate rdata.
The thing is, that the rdata referenced there is a very low-level representation, you absolutely cannot just drop some plain text in there and expect it to work.
Ie, if you go down the route of entering generic record data in tinydns you will not really be helped by the master file format representation of records (the friendly plain text record data that you usually work with, such as the record data that was suggested to you) but you would rather have to look up how that data converts into the DNS wire-format (the actual binary format used in the DNS protocol) and write that (escaping problematic bytes as necessary) into the rdata field.
Ie, for a
TXT
record you would have the value strings prefixed by their lengths (single byte integer, which would need to be escaped in octal as noted in the documentation).Is djbdns/tinydns a lost cause?
Afaict not because of its handling of
TXT
records specifically.It is however a piece of software that in its official form has not seen any updates since 2001 (version 1.05).
There are patches and forks that address various shortcomings (the DNS protocol as well as our demands and expectations have continued evolving over those 15 years) but I think it would make more sense to switch to better maintained and up to date DNS server implementation.