1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
//! Domain names.
//!
//! Domain names are a core concept of DNS. The whole system is essentially
//! just a mapping from domain names to arbitrary information. This module
//! provides types and essential functionality for working with them.
//!
//! A domain name is a sequence of labels, separated by ASCII periods (`.`).
//! For example, `example.org.` contains three labels: `example`, `org`, and
//! `` (the root label). Outside DNS-specific code, the root label (and its
//! separator) are almost always omitted, but keep them in mind here.
//!
//! Domain names form a hierarchy, where `b.a` is the "parent" of `.c.b.a`.
//! The owner of `example.org` is thus responsible for _every_ domain ending
//! with the `.example.org` suffix. The reverse order in which this hierarchy
//! is expressed can sometimes be confusing.
//!
//! ## Domain Name Types
//!
//! There are several different types that can be used to represent domain
//! names. Each one is appropriate for certain situations and less useful for
//! others. Most of `domain`'s high-level APIs will hard-code domain name
//! types to the right options.
//!
//! - [`Name`] is the standard domain name type. As is common in DNS
//! implementations, it stores labels in the wire format from innermost to
//! outermost (i.e. `example, org` for `example.org.`). It is the right
//! type to use in DNS record data.
//!
//! - [`RevName`] is similar to [`Name`], except that labels are stored in
//! _reverse_ order, from outermost to innermost (i.e. `org, example` in
//! `example.org.`). It is the right type to use as the owner name of a
//! DNS record ([`Record`]`.rname`). The [`RevName`] type is introduced to
//! improve manipulations done on a Domain Name.
//!
//! During serialization with [`BuildBytes`] to wire format both types result
//! the same byte sequence.
//!
//! [`Record`]: domain::new::base::Record
//!
//! These types are _dynamically sized_; this means that they cannot be used
//! by value. The following table illustrates the various container and
//! pointer types that can be used around them, and the situations they are
//! most appropriate for.
//!
//! | Type | Ownership | Decompression | Intended Usage |
//! |----------------|-----|-----|----------------------------|
//! | `&'a Name` | No | No | Whenever possible
//! | `Box<Name>` | Yes | Yes | Compact, long-term storage
//! | `NameBuf` | Yes | Yes | Efficient short-term usage
//! | `Box<RevName>` | Yes | Yes | Compact, long-term storage
//! | `RevNameBuf` | Yes | Yes | Efficient short-term usage
//!
//!
//! ### Usage example
//!
//! In the following example a `str` is parsed into a [`NameBuf`] which is the
//! owner of the data buffer. The [`NameBuf`] is be passed on as a [`Name`]
//! reference. Later the [`NameBuf`] gets moved into a [`RevNameBuf`] which is
//! in turn passed on as a [`RevName`].
//!
//! ```
//! use domain::new::base::name;
//!
//! let name_buf: name::NameBuf =
//! "www.nlnetlabs.nl".parse().unwrap();
//! let name_ref: &name::Name = &name_buf;
//!
//! println!("NameBuf {}, &Name {}", name_buf, name_ref);
//!
//! let revname_buf: name::RevNameBuf = name_buf.into();
//! let revname_ref: &name::RevName = &revname_buf;
//!
//! println!(
//! "RevNameBuf {:?}, &RevName {:?}",
//! revname_buf, revname_ref
//! );
//! ```
use Ordering;
use ;
//--- Submodules
pub use ;
pub use ;
pub use ;
pub use UnparsedName;
pub use NameCompressor;
//----------- CanonicalName --------------------------------------------------
/// DNSSEC-conformant operations for domain names.
///
/// As specified by [RFC 4034, section 6], domain names are used in two
/// different ways: they can be serialized into byte sequences or compared.
///
/// - In record data, they are serialized following the regular wire format
/// (specifically without name compression). However, in some record data
/// types, labels are converted to lowercase for serialization.
///
/// - In record owner names, they are compared from the root label outwards,
/// with the contents of each label being compared case-insensitively.
///
/// - In record data, they are compared as serialized byte sequences. As
/// explained above, there are two different valid serializations (i.e. the
/// labels may be lowercased, or the original case may be retained).
///
/// [RFC 4034, section 6]: https://datatracker.ietf.org/doc/html/rfc4034#section-6
///
/// If a domain name type implements [`CanonicalName`], then [`BuildBytes`]
/// will serialize the name in the wire format (without changing the case of
/// its labels). [`Ord`] will compare domain names as if they were the owner
/// names of records (i.e. not as if they were serialized byte sequences).
/// Implement [`CanonicalName`] for a [`Deref`]-based generic container.
=> ;
}
impl_canonical_name_for_deref!