This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
extensions:teemip-zone-mgmt [2024/04/04 12:30] – [TXT Records] cnaud | extensions:teemip-zone-mgmt [2024/04/04 14:40] – [Revision History] cnaud | ||
---|---|---|---|
Line 33: | Line 33: | ||
===== Revision History ===== | ===== Revision History ===== | ||
^ Version | ^ Version | ||
- | | 3.1.2 | 2024-xx-yy | + | | 3.1.2 | 2024-xx-yy |
| **3.1.1** | | **3.1.1** | ||
| 3.1.0 | 2023-06-21 | | 3.1.0 | 2023-06-21 | ||
Line 483: | Line 483: | ||
| Previous segment | Foreign key to a(n) TXT Record | No | | | Previous segment | Foreign key to a(n) TXT Record | No | | ||
| Next segment | Foreign key to a(n) TXT Record | No | | | Next segment | Foreign key to a(n) TXT Record | No | | ||
- | |||
- | We may have more than 255 characters of data in a TXT record, but **not** more than 255 characters in a single string, which is problematic for long chains like DKIM keys. RFC 4408 defines how to get around this limitation : a TXT record is allowed to contain multiple strings which should then be concatenated together by the reading application. TeemIP implements this concept through a chaining mechanism. TXT records with the **exact same** RR Name may be chained together. The tool that generate Zone data files will take the chain into consideration and will create the proper entry in the db file. | ||
=== Update === | === Update === | ||
- | A TXT record may be updated from the detailed view of the object. | + | A TXT record may be updated from the detailed view of the object. |
{{ classupdate_txtrecord3x.png }} | {{ classupdate_txtrecord3x.png }} | ||
+ | |||
+ | === TXT Records with a payload over 255 chars == | ||
+ | A TXT record may have more than 255 characters of data, but **not** more than 255 characters in a single string, which is problematic for long chains like DKIM keys. RFC 4408 defines how to get around this limitation : a TXT record is allowed to contain multiple strings which should then be concatenated together by the reading application. TeemIP implements this concept through a chaining mechanism. | ||
+ | |||
+ | <note tip> | ||
+ | When a segment is set in a given TXT record, its counter part is automatically updated. | ||
+ | * If **Previous segment** of record R1 is set to R0, then TeemIP will set **Next segment** of record R0 to R1 | ||
+ | * If **Next segment** of record R1 is set to R2, then TeemIp will set **Previous segment** of record R2 to R1 | ||
+ | </ | ||
+ | <note warning> | ||
+ | In a chain, only the RR Name of the **first segment** is relevant. It is considered as the reference for the TXT Record when the db file is built. The name of the following records of the chain are just used to name the objects. | ||
+ | </ | ||
+ | {{ classupdate_txtrecord3x-2.png }} | ||
+ | |||
+ | The tool that generates Zone data files will take the chain into consideration and will create the proper entry in the db file as shown in the exemple below: | ||
+ | |||
+ | {{ dbfile_long_txtrecord.png }} | ||
==== Generic Records ==== | ==== Generic Records ==== |