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 [2023/12/21 10:20] – [Data entry] cnaud | extensions:teemip-zone-mgmt [2024/04/04 13:01] – [TXT Records] cnaud | ||
---|---|---|---|
Line 33: | Line 33: | ||
===== Revision History ===== | ===== Revision History ===== | ||
^ Version | ^ Version | ||
+ | | 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 470: | Line 471: | ||
=== Properties === | === Properties === | ||
^ Name ^ Type ^ Mandatory? | ^ Name ^ Type ^ Mandatory? | ||
+ | | **Zone** ||| | ||
| Organization | Foreign key to a(n) Organization | Yes | | | Organization | Foreign key to a(n) Organization | Yes | | ||
| Zone | Foreign key to a(n) Zone | Yes | | | Zone | Foreign key to a(n) Zone | Yes | | ||
+ | | **RRs attributes** ||| | ||
| RR Name | Alphanumeric string | | RR Name | Alphanumeric string | ||
| Overwrite zone TTL | Yes or No | No | | | Overwrite zone TTL | Yes or No | No | | ||
Line 477: | Line 480: | ||
| Text| Alphanumeric string | Yes | | | Text| Alphanumeric string | Yes | | ||
| Comment | Alphanumeric string | No | | | Comment | Alphanumeric string | No | | ||
+ | | **Chaining** ||| | ||
+ | | Previous segment | Foreign key to a(n) TXT Record | No | | ||
+ | | Next segment | Foreign key to a(n) TXT Record | No | | ||
=== 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 **Next segment** of record R0 will be set to R1 | ||
+ | * If **Next segment** of record R1 is set to R2, then **Previous segment** of record R2 will be set to R1 | ||
+ | </ | ||
+ | <note warning> | ||
+ | In a chain, only the RR Name of the **first segment** is relevant. It is considered as the reference of the record when the db file is built. The name of the following records of the chain are just used for reference. | ||
+ | </ | ||
+ | {{ classupdate_txtrecord3x-2.png }} | ||
+ | |||
+ | The tool that generate 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 ==== |