search

ietf-wg-dance / draft-dance-architecture

Dane Authentication for Network Clients Everywhere
Other
5 stars 5 forks source link

DNSdir: Expand text on DNS zone construction #61

Closed oej closed 2 weeks ago

oej commented 2 months ago

In these cases it is important to consider the architecture of the DNS zone and when possible use a tree-like structure with many subdomain parts, much like reverse DNS records or how telephone numbers are represented in the ENUM standard (RFC 6116). [...] We may want to have a discussion [...]

I don't have any real data at hand, but from what I've heard this splitting up into not-too-huge zones can help with speed of updates in some server implementations. So this "adding of dots" into the proposed naming schemes can be an aspect to consider; a particular zone owner can then choose whether to split zones at some dots or not.

Note that this tradeoff will surely increase the total number of queries from resolvers, be it for QNAME minimization or to obtain the DNSSEC chain that got longer by inserting zone cuts. Various large zones do exist in the wild already, say signed ccTLDs with million(s) of records and update time within several minutes.

https://datatracker.ietf.org/doc/review-ietf-dance-architecture-06-dnsdir-early-cunat-2024-07-19/

oej commented 2 months ago

Good feedback, but does it lead to any text changes? I think not.

oej commented 2 months ago

The original text was written after consultation with a member of the DNS directorate. I checked with another DNS guru and I think the text is fine, but we can clarify that each implementation spec ("How to dance") needs to clarify how names are handled in DNS.

mcr commented 2 months ago

Whether or not it is more efficient or not, depends upon the implementation of the server. A general purpose server might be less efficient for a flat domain, and may benefit from additional "dots"

oej commented 1 month ago

This is handled by a pull request https://github.com/ietf-wg-dance/draft-dance-architecture/pull/69