|
|
|
# Design Considerations
|
|
|
|
|
|
|
|
Unlike [Daley et al.][1] who aimed to “use as closely as possible the presentation format for
|
|
|
|
RDATA fields given in various RFCs”, this data model uses an
|
|
|
|
organisation of data and types of RR fields so as to make
|
|
|
|
configuration of zones as effective and convenient as possible, even
|
|
|
|
though experienced DNS admins may need some time to get used to some
|
|
|
|
aspects.
|
|
|
|
Unlike [Daley et al.][] who aimed to “use as closely as possible the
|
|
|
|
presentation format for RDATA fields given in various RFCs”, this data
|
|
|
|
model uses an organisation of data and types of RR fields that should
|
|
|
|
make configuration of zones as effective and convenient as possible,
|
|
|
|
even though experienced DNS admins may need some time to get used to
|
|
|
|
some aspects.
|
|
|
|
|
|
|
|
The data model currently consists of two YANG modules [README](README.md)
|
|
|
|
|
|
|
|
The
|
|
|
|
[data tree](https://gitlab.labs.nic.cz/llhotka/zone-data-yang/raw/master/model.tree)
|
| ... | ... | @@ -14,6 +16,4 @@ zone is uniquely identified by its (domain) name. |
|
|
|
|
|
|
|
Resource records are organised into RRSet
|
|
|
|
|
|
|
|
## References
|
|
|
|
|
|
|
|
[1]: https://www.ietf.org/archive/id/draft-daley-dnsxml-00.txt |
|
|
|
[Daley et al.]: https://www.ietf.org/archive/id/draft-daley-dnsxml-00.txt |
