... | ... | @@ -37,6 +37,9 @@ of this organisation is that each RRSet can be uniquely identified by |
|
|
its owner and type. Hence the `rrset` list has two keys: `owner` and
|
|
|
`type`.
|
|
|
|
|
|
Owner names as well as any domain names appearing in configuration
|
|
|
data must always be *absolute* and without the terminating dot.
|
|
|
|
|
|
TTL is specified at the RRSet level because [RFC 2181][] says that
|
|
|
“the TTLs of all RRs in an RRSet must be the same”. The data model
|
|
|
offers no means for specifying different TTL for a RR.
|
... | ... | @@ -54,16 +57,25 @@ used. However, these keys **do not imply any order** of RR entries – the |
|
|
list is “ordered-by system” (see [Sec. 7.7.5][ordered-by] in [RFC 6020][]).
|
|
|
|
|
|
RDATA fields are wrapped in a container whose name is the same as the
|
|
|
type of the RRSet. So, for example, RDATA for an A RR looks like this
|
|
|
type of the RRSet. So, for example, RDATA for an MX RR looks like this
|
|
|
(in JSON encoding):
|
|
|
|
|
|
```json
|
|
|
"A": {
|
|
|
"address": "192.0.2.5"
|
|
|
"MX": {
|
|
|
"preference": 1,
|
|
|
"exchange": "xx.example"
|
|
|
}
|
|
|
```
|
|
|
|
|
|
This extra container is somewhat redundant because the RR type is
|
|
|
already specified in the `type` parameter of the parent RRSet but it
|
|
|
was needed as a workaround for certain peculiar YANG restrictions. It
|
|
|
has practical advantages, too, e.g. fields of different RR types can
|
|
|
have teh same names without causing a conflict.
|
|
|
|
|
|
The data model also includes semantic constraints that RDATA have to
|
|
|
satisfy. For example, a configuration will not pass validation if SEP
|
|
|
flag in a DNSKEY RR is set but ZONE flag isn't.
|
|
|
|
|
|
## Field Values
|
|
|
|
... | ... | @@ -71,12 +83,39 @@ The data model uses existing standard YANG data types where |
|
|
possible. So, for example, `signature-expiration` and
|
|
|
`signature-inception` fields in the RRSIG record use ISO 8601 date and
|
|
|
time format because it is used by the standard `yang:date-and-time` type
|
|
|
[RFC 6991][]. On the other hand, it was impossible to use the standard
|
|
|
[RFC 6991][].
|
|
|
|
|
|
On the other hand, it was impossible to use the standard
|
|
|
`inet:domain-name` type (also defined in [RFC 6991][]) because it is
|
|
|
essentially limited to host names, so wildcards and CIDR-style reverse
|
|
|
domain names would be rejected. That's why [dns-zones][] module
|
|
|
defines a new `domain-name` type.
|
|
|
|
|
|
RDATA fields encoding (IANA) enumerations always use mnemonic strings
|
|
|
rather than assigned numeric values. Similarly, RDATA fields
|
|
|
containing binary flags are conveniently represented using the YANG
|
|
|
built-in *bits* type. Flags that are set can thus be specified using
|
|
|
mnemonics. For example
|
|
|
|
|
|
```json
|
|
|
"DNSKEY": {
|
|
|
"flags": "ZONE SEP",
|
|
|
"algorithm": "RSASHA1",
|
|
|
...
|
|
|
}
|
|
|
```
|
|
|
|
|
|
Binary fields such as digital keys, signatures or digests are encoded
|
|
|
using the presentation format defined in a corresponding RFC. If the
|
|
|
encoding is *base64*, then the built-in type *binary* is used. For
|
|
|
other encodings (*base32*, hexadecimal digits) the [dns-zones][]
|
|
|
module defines a custom type.
|
|
|
|
|
|
Presentation formats of binary fields often allow whitespace so that
|
|
|
long strings can be broken into multiple lines in a master file. YANG
|
|
|
data types used for such fields **never** allow any whitespace because
|
|
|
it's not needed.
|
|
|
|
|
|
[Daley et al.]: https://www.ietf.org/archive/id/draft-daley-dnsxml-00.txt
|
|
|
[iana-dns-parameters]:
|
|
|
https://gitlab.labs.nic.cz/llhotka/zone-data-yang/blob/master/iana-dns-parameters.yang
|
... | ... | |