draft-schanzen-gns.xml (203968B)
1 <?xml version='1.0' encoding='utf-8'?> 2 <!DOCTYPE rfc [ 3 <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml"> 4 <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml"> 5 <!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml"> 6 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> 7 <!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">--> 8 <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml"> 9 <!ENTITY RFC3629 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml"> 10 <!ENTITY RFC3686 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3686.xml"> 11 <!ENTITY RFC3826 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3826.xml"> 12 <!ENTITY RFC4033 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml"> 13 <!ENTITY RFC5237 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5237.xml"> 14 <!--<!ENTITY RFC3912 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml">--> 15 <!ENTITY RFC5869 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5869.xml"> 16 <!ENTITY RFC5890 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml"> 17 <!ENTITY RFC5895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5895.xml"> 18 <!ENTITY RFC6066 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"> 19 <!ENTITY RFC6234 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6234.xml"> 20 <!ENTITY RFC6761 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6761.xml"> 21 <!ENTITY RFC6895 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6895.xml"> 22 <!ENTITY RFC6979 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml"> 23 <!ENTITY RFC7363 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7363.xml"> 24 <!ENTITY RFC8806 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8806.xml"> 25 <!ENTITY RFC7748 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7748.xml"> 26 <!ENTITY RFC8032 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8032.xml"> 27 <!ENTITY RFC8126 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml"> 28 <!ENTITY RFC8174 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> 29 <!ENTITY RFC8244 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8244.xml"> 30 <!ENTITY RFC8324 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8324.xml"> 31 <!ENTITY RFC8499 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8499.xml"> 32 <!ENTITY RFC9106 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9106.xml"> 33 <!ENTITY RFC9476 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.9476.xml"> 34 ]> 35 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> 36 <?rfc strict="yes" ?> 37 <?rfc toc="yes" ?> 38 <?rfc symrefs="yes"?> 39 <?rfc sortrefs="yes" ?> 40 <?rfc compact="yes" ?> 41 <?rfc subcompact="no" ?> 42 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="info" docName="draft-schanzen-gns-28" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" version="3"> 43 <!-- xml2rfc v2v3 conversion 2.26.0 --> 44 <front> 45 <title abbrev="The GNU Name System"> 46 The GNU Name System 47 </title> 48 <seriesInfo name="Internet-Draft" value="draft-schanzen-gns-28"/> 49 <author fullname="Martin Schanzenbach" initials="M." surname="Schanzenbach"> 50 <organization>Fraunhofer AISEC</organization> 51 <address> 52 <postal> 53 <street>Lichtenbergstrasse 11</street> 54 <city>Garching</city> 55 <code>85748</code> 56 <country>DE</country> 57 </postal> 58 <email>martin.schanzenbach@aisec.fraunhofer.de</email> 59 </address> 60 </author> 61 <author fullname="Christian Grothoff" initials="C." surname="Grothoff"> 62 <organization>Berner Fachhochschule</organization> 63 <address> 64 <postal> 65 <street>Hoeheweg 80</street> 66 <city>Biel/Bienne</city> 67 <code>2501</code> 68 <country>CH</country> 69 </postal> 70 <email>christian.grothoff@bfh.ch</email> 71 </address> 72 </author> 73 <author fullname="Bernd Fix" initials="B." surname="Fix"> 74 <organization>GNUnet e.V.</organization> 75 <address> 76 <postal> 77 <street>Boltzmannstrasse 3</street> 78 <city>Garching</city> 79 <code>85748</code> 80 <country>DE</country> 81 </postal> 82 <email>fix@gnunet.org</email> 83 </address> 84 </author> 85 86 <!-- Meta-data Declarations --> 87 <area>General</area> 88 <workgroup>Independent Stream</workgroup> 89 <keyword>name systems</keyword> 90 <abstract> 91 <t> 92 This document contains the GNU Name System (GNS) technical 93 specification. 94 GNS is a decentralized and censorship-resistant domain name 95 resolution protocol that provides a privacy-enhancing alternative to the 96 Domain Name System (DNS) protocols. 97 </t> 98 <t> 99 This document defines the normative wire format of resource records, 100 resolution processes, cryptographic routines and security 101 considerations for use by implementers. 102 </t> 103 <t> 104 This specification was developed outside the IETF and does not have 105 IETF consensus. It is published here to inform readers about the 106 function of GNS, guide future GNS implementations, and ensure 107 interoperability among implementations including with the pre-existing 108 GNUnet implementation. 109 </t> 110 </abstract> 111 </front> 112 <middle> 113 <section anchor="introduction" numbered="true" toc="default"> 114 <name>Introduction</name> 115 <t> 116 This specification describes the GNU Name System (GNS), a 117 censorship-resistant, privacy-preserving and decentralized 118 domain name resolution protocol. GNS cryptographically secures 119 the binding of names to arbitrary tokens, enabling it to double 120 in some respects as an alternative to some of today’s public 121 key infrastructures. 122 </t> 123 <t> 124 In the terminology of the Domain Name System (DNS) <xref 125 target="RFC1035" />, GNS roughly follows the idea of a local 126 root zone deployment (see <xref target="RFC8806"/>), with the 127 difference that the design encourages alternative roots and 128 does not expect all deployments to use the same or any specific 129 root zone. In the GNS reference implementation, users can 130 autonomously and freely delegate control of names to zones 131 through their local configurations. 132 GNS expects each user to be in control of their setup. 133 By following <xref target="namespace_ambiguity" /> guidelines, 134 users should manage to avoid any confusion as to how names are 135 resolved. 136 </t> 137 <t> 138 Name resolution and zone dissemination is based on the 139 principle of a petname system where users can assign local 140 names to zones. The GNS has its roots in ideas from the Simple 141 Distributed Security Infrastructure <xref target="SDSI" />, 142 enabling the decentralized mapping of secure identifiers to 143 memorable names. A first academic description of the 144 cryptographic ideas behind GNS can be found in <xref 145 target="GNS" />. 146 </t> 147 <t> 148 This document defines the normative wire format of resource 149 records, resolution processes, cryptographic routines and 150 security considerations for use by implementers. 151 </t> 152 <t> 153 This specification was developed outside the IETF and does not have 154 IETF consensus. It is published here to guide implementers of GNS 155 and to ensure interoperability among implementations. 156 </t> 157 <section numbered="true" toc="default"> 158 <name>Requirements Notation</name> 159 <t> 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in 163 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only 164 when, they appear in all capitals, as shown here. 165 </t> 166 </section> 167 </section> 168 <section> 169 <name>Terminology</name> 170 <dl> 171 <dt>Apex Label</dt> 172 <dd> 173 This type of label is used to publish resource 174 records in a zone that can be resolved without providing a specific 175 label. It is the GNS method to provide what is the "zone apex" in DNS 176 <xref target="RFC4033"/>. 177 The apex label is represented using the character U+0040 ("@" without 178 the quotes). 179 </dd> 180 <dt>Application</dt> 181 <dd> 182 A component which uses a GNS implementation 183 to resolve names into records and processes its contents. 184 </dd> 185 <dt>Blinded Zone Key</dt> 186 <dd> 187 Key derived from a zone key and a label. 188 The zone key and any blinded zone key derived from it are unlinkable 189 without knowledge of the specific label used for the derivation. 190 </dd> 191 <dt>Extension Label</dt> 192 <dd> 193 This type of label is used to refer to the authoritative zone that the record is in. 194 The primary use for the extension label is in redirections where the redirection 195 target is defined relative to the authoritative zone of the redirection 196 record (see <xref target="gnsrecords_redirect"/>). 197 The extension label is represented using the character U+002B ("+" 198 without the quotes). 199 </dd> 200 <dt>Label Separator</dt> 201 <dd> 202 Labels in a name are separated using the label separator U+002E 203 ("." without the quotes). 204 In GNS, with the exceptions of zone Top-Level Domains 205 (see below) and boxed records (see <xref target="gnsrecords_box"/>), 206 every label separator in a name indicates delegation to another zone. 207 </dd> 208 <dt>Label</dt> 209 <dd> 210 A GNS label is a label as defined in <xref target="RFC8499"/>. 211 Labels are UTF-8 strings in Unicode 212 Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. 213 The apex label and the extension label have 214 special purposes in the resolution protocol which are defined 215 in the rest of the document. 216 Zone administrators <bcp14>MAY</bcp14> disallow certain labels that 217 might be easily confused with other labels through registration policies 218 (see also <xref target="security_abuse"/>). 219 </dd> 220 221 <dt>Name</dt> 222 <dd> 223 A name in GNS is a domain name as defined in <xref target="RFC8499"/>: 224 Names are UTF-8 <xref target="RFC3629" /> strings consisting of an 225 ordered list of labels concatenated with a label separator. 226 Names are resolved starting from the rightmost label. 227 GNS does not impose length restrictions on names or labels. 228 However, applications <bcp14>MAY</bcp14> ensure that name and label lengths are 229 compatible with DNS and in particular IDNA <xref target="RFC5890"/>. 230 In the spirit of <xref target="RFC5895"/>, applications <bcp14>MAY</bcp14> preprocess 231 names and labels to ensure compatibility with DNS or support 232 specific user expectations, for example according to 233 <xref target="Unicode-UTS46"/>. 234 A GNS name may be indistinguishable from a DNS name and care must 235 be taken by applications and implementors when handling GNS names 236 (see <xref target="namespace_ambiguity"/>). 237 In order to avoid misinterpretation of example domains with (reserved) 238 DNS domains this draft uses the suffix ".gns.alt" in examples which 239 is also registered in the GANA ".alt Subdomains" registry 240 <xref target="GANA"/> (see also <xref target="RFC9476"/>). 241 </dd> 242 <dt>Resolver</dt> 243 <dd> 244 The component of a GNS implementation which provides 245 the recursive name resolution logic defined in 246 <xref target="resolution"/>. 247 </dd> 248 <dt>Resource Record</dt> 249 <dd> 250 A GNS resource record is the information associated with a label in a 251 GNS zone. 252 A GNS resource record contains information as defined by its 253 resource record type. 254 </dd> 255 <dt>Start Zone</dt> 256 <dd> 257 In order to resolve any given GNS name an initial start zone must be 258 determined for this name. 259 The start zone can be explicitly defined as part of the name using a 260 zone Top-Level Domain (zTLD). 261 Otherwise, it is determined through a local suffix-to-zone mapping 262 (see <xref target="governance"/>). 263 </dd> 264 265 <dt>Top-Level Domain</dt> 266 <dd> 267 The rightmost part of a GNS name is a GNS Top-Level Domain (TLD). 268 A GNS TLD can consist of one or more labels. 269 Unlike DNS Top-Level Domains (defined in <xref target="RFC8499"/>), 270 GNS does not expect all users to use the same global root zone. Instead, 271 with the exception of Zone Top-Level Domains (see <xref target="zTLD"/>), 272 GNS TLDs are typically part of the configuration of the local resolver 273 (see <xref target="governance"/>), and might thus not be globally unique. 274 </dd> 275 <dt>Zone</dt> 276 <dd> 277 A GNS zone contains authoritative information (resource records). 278 A zone is uniquely identified by its zone key. Unlike DNS zones, 279 a GNS zone does not need to have a SOA record under the apex label. 280 </dd> 281 <dt>Zone Key</dt> 282 <dd> 283 A key which uniquely identifies a zone. 284 It is usually a public key of an asymmetric key pair. 285 However, the established technical term "public key" is misleading, 286 as in GNS a zone key may be a shared secret 287 that should not be disclosed to unauthorized parties. 288 </dd> 289 <dt>Zone Key Derivation Function</dt> 290 <dd> 291 The zone key derivation function (ZKDF) blinds a zone key using a label. 292 </dd> 293 294 <dt>Zone Master</dt> 295 <dd> 296 The component of a GNS implementation which provides 297 local zone management and publication as defined in 298 <xref target="publish"/>. 299 </dd> 300 <dt>Zone Owner</dt> 301 <dd> 302 The holder of the secret (typically a private key) 303 that (together with a label and a value to sign) allows the creation of zone 304 signatures that can be validated against the respective blinded zone key. 305 </dd> 306 <dt>Zone Top-Level Domain</dt> 307 <dd> 308 A GNS Zone Top-Level Domain (zTLD) is a sequence of GNS labels at 309 the end of a GNS name which encodes a zone type and 310 zone key of a zone (see <xref target="zTLD"/>). 311 Due to the statistical uniqueness of zone keys, zTLDs are also globally unique. 312 A zTLD label sequence can only be distinguished from ordinary TLD label sequences 313 by attempting to decode the labels into a zone type and zone key. 314 </dd> 315 316 <dt>Zone Type</dt> 317 <dd> 318 The type of a GNS zone determines the cipher system and binary encoding 319 format of the zone key, blinded zone keys, and cryptographic signatures. 320 </dd> 321 </dl> 322 </section> 323 <section anchor="overview" numbered="true" toc="default"> 324 <name>Overview</name> 325 <t> 326 GNS exhibits the three properties that are commonly used to describe 327 a petname system: 328 </t> 329 <ol> 330 <li> 331 Global names through the concept of zone top-level 332 domains (zTLDs): As zones can be uniquely identified by their zone key 333 and are statistically unique, zTLDs are globally unique mappings to zones. 334 Consequently, GNS domain names with a zTLD suffix are also globally unique. 335 Names with zTLDs suffixes are not human-readable. 336 </li> 337 <li> 338 Memorable petnames for zones: 339 Users can configure local, human-readable references to zones. 340 Such petnames serve as zTLD monikers which provide 341 convenient names for zones to the local operator. 342 The petnames may also be published as suggestions for other 343 users searching for good label to use when referencing the 344 respective zone. 345 </li> 346 <li> 347 A secure mapping from names to records: 348 GNS allows zone owners to map labels to resource records or to 349 delegate authority of names in the subdomain induced by a label to other zones. 350 Zone owners may choose to publish this information to make it 351 available to other users. 352 Mappings are encrypted and signed 353 using keys derived from the respective label before being published to remote storage. 354 When names are resolved, signatures on resource records 355 including delegations are verified by the recursive resolver. 356 </li> 357 </ol> 358 <t> 359 In the remainder of this document, the "implementer" refers to the developer building 360 a GNS implementation including the resolver, zone master, and 361 supporting configuration such as start zones (see <xref target="governance"/>). 362 </t> 363 <section anchor="names" numbered="true" toc="default"> 364 <name>Names and Zones</name> 365 <t> 366 It follows from the above that GNS does not support names which are 367 simultaneously global, secure and human-readable. 368 Instead, names are either global and not human-readable or not globally 369 unique and human-readable. 370 An example for a global name pointing to the record "example" in 371 a zone is: 372 </t> 373 <sourcecode> 374 example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884 375 </sourcecode> 376 <t> 377 Now consider the case where a user locally configured the petname 378 "pet.gns.alt" for the zone with the "example" record of the name 379 above. 380 The name "example.pet.gns.alt" would then point to the same record as the 381 globally unique name above, but name resolution would only 382 work on the local system where the "pet.gns.alt" petname is 383 configured. 384 </t> 385 <t> 386 The delegation of petnames and subsequent resolution of delegation 387 builds on ideas from the Simple Distributed Security Infrastructure 388 <xref target="SDSI" />. 389 In GNS, any user can create and manage any number of zones 390 (see <xref target="zones"/>) if their system provides a zone master implementation. 391 For each zone, the zone type determines the respective set of cryptographic operations 392 and the wire formats for encrypted data, public keys and signatures. 393 A zone can be populated with mappings from labels to resource records 394 (see <xref target="rrecords"/>) by its owner. 395 A label can be mapped to a delegation record which results in the 396 corresponding subdomain being delegated to another zone. Circular 397 delegations are explicitly allowed, including delegating a subdomain 398 to its immediate parent zone. In 399 order to support (legacy) applications as well as to facilitate the use 400 of petnames, GNS defines auxiliary record types in addition to 401 supporting existing DNS records. 402 </t> 403 </section> 404 <section anchor="publishing" numbered="true" toc="default"> 405 <name>Publishing Binding Information</name> 406 <t> 407 Zone contents are encrypted and signed 408 before being published in a remote key-value storage (see <xref target="publish"/>) 409 as illustrated in <xref target="figure_arch_publish"/>. 410 In this process, unique zone identification is hidden from the network 411 through the use of key blinding. 412 Key blinding allows the creation of signatures for zone contents 413 using a blinded public/private key pair. 414 This blinding is realized using a deterministic key 415 derivation from 416 the original zone key and corresponding private key using record label values 417 as inputs from which blinding factors are derived. 418 Specifically, the zone owner can derive blinded private keys for each record 419 set published under a label, and a 420 resolver can derive the corresponding blinded public keys. 421 It is expected that GNS implementations use decentralized remote 422 storages such as distributed hash tables (DHT) in order to facilitate 423 availability within a network without the need for dedicated infrastructure. 424 Specification of such a distributed or decentralized storage is out of 425 scope of this document, but possible existing implementations include those 426 based on <xref target="RFC7363" />, <xref target="Kademlia" /> or 427 <xref target="R5N" />. 428 </t> 429 <figure anchor="figure_arch_publish" title="An example diagram of two hosts publishing GNS zones."> 430 <artwork name="" type="" align="left" alt=""><![CDATA[ 431 Host A | Remote | Host B 432 | Storage | 433 | | 434 | +---------+ | 435 | / /| | 436 Publish | +---------+ | | Publish 437 +---------+ Records | | | | | Records +---------+ 438 | Zone |----------|->| Record | |<-|----------| Zone | 439 | Master | | | Storage | | | | Master | 440 +---------+ | | |/ | +---------+ 441 A | +---------+ | A 442 | | | | 443 +---------+ | | +---------+ 444 / | /| | | / | /| 445 +---------+ | | | +---------+ | 446 | | | | | | | | 447 | Local | | | | | Local | | 448 | Zones | | | | | Zones | | 449 | |/ | | | |/ 450 +---------+ | | +---------+ 451 ]]></artwork> 452 </figure> 453 <t> 454 A zone master implementation <bcp14>SHOULD</bcp14> be provided as 455 part of a GNS implementation to enable users to create and manage zones. 456 If this functionality is not implemented, names can still be resolved 457 if zone keys for the initial step in the name resolution have been 458 configured (see <xref target="resolution"/>) or if the names end with a 459 zTLD suffix. 460 </t> 461 </section> 462 <section anchor="resolving" numbered="true" toc="default"> 463 <name>Resolving Names</name> 464 <t> 465 Applications use the resolver to lookup GNS names. 466 Starting from a configurable start zone, names are resolved by following zone 467 delegations recursively as illustrated in <xref target="figure_arch_resolv"/>. 468 For each label in a name, the recursive GNS resolver 469 fetches the respective record set from the storage layer (see <xref target="resolution"/>). 470 Without knowledge of the label values and the zone keys, the 471 different derived keys are unlinkable both to the original zone key and to each 472 other. 473 This prevents zone enumeration (except via expensive online brute 474 force attacks): To confirm affiliation of a 475 query or the corresponding encrypted record set with a 476 specific zone requires knowledge of both the zone key and the label, 477 neither of which are disclosed to remote storage by the protocol. 478 At the same time, the blinded zone key and digital signatures 479 associated with each encrypted record set allow resolvers and oblivious remote 480 storage to verify the integrity of the published information 481 without disclosing anything about the originating zone or the record sets. 482 </t> 483 <figure anchor="figure_arch_resolv" title="High-level view of the GNS resolution process."> 484 <artwork name="" type="" align="left" alt=""><![CDATA[ 485 Local Host | Remote 486 | Storage 487 | 488 | +---------+ 489 | / /| 490 | +---------+ | 491 +-----------+ Name +----------+ Recursive | | | | 492 | | Lookup | | Resolution | | Record | | 493 |Application|----------| Resolver |-------------|->| Storage | | 494 | |<---------| |<------------|--| |/ 495 +-----------+ Results +----------+ Intermediate| +---------+ 496 A Results | 497 | | 498 +---------+ | 499 / | /| | 500 +---------+ | | 501 | | | | 502 | Start | | | 503 | Zones | | | 504 | |/ | 505 +---------+ | 506 ]]></artwork> 507 </figure> 508 </section> 509 </section> 510 <section anchor="zones" numbered="true" toc="default"> 511 <name>Zones</name> 512 <t> 513 A zone in GNS is uniquely identified by its zone type and zone key. 514 Each zone can be referenced by its zone Top-Level Domain (zTLD) string 515 (see <xref target="zTLD" />) which encodes the zone type and zone key. 516 A zone type (ztype) is a unique 32-bit number which corresponds to 517 a resource record type number identifying a delegation record type 518 in the GANA "GNS Record Types" registry <xref target="GANA" />. 519 The ztype is a unique identifier for the set cryptographic functions 520 of the zone and the format of the delegation record type. 521 Any ztype registration <bcp14>MUST</bcp14> define the following set of cryptographic functions: 522 </t> 523 <dl> 524 <dt>KeyGen() -> d, zk</dt> 525 <dd> 526 is a function to generate a new private key d and 527 the corresponding public zone key zk. 528 </dd> 529 <dt>ZKDF(zk,label) -> zk'</dt> 530 <dd> 531 is a zone key derivation function which blinds a zone key zk 532 using a label. zk and zk' must be unlinkable. Furthermore, 533 blinding zk with different values for the label must result 534 in different, unlinkable zk' values. 535 </dd> 536 <dt>S-Encrypt(zk,label,expiration,plaintext) -> ciphertext</dt> 537 <dd> 538 is a symmetric encryption function which encrypts the plaintext 539 to derive ciphertext based on key material derived from the zone key zk, 540 a label and an expiration timestamp. 541 In order to leverage performance-enhancing caching features of certain 542 underlying storages, in particular DHTs, a deterministic encryption 543 scheme is recommended. 544 </dd> 545 <dt>S-Decrypt(zk,label,expiration,ciphertext) -> plaintext</dt> 546 <dd> 547 is a symmetric decryption function which decrypts the ciphertext 548 into plaintext based on key material derived from the zone key, 549 a label, and an expiration timestamp. 550 </dd> 551 <dt>Sign(d,message) -> signature</dt> 552 <dd> 553 is a function to sign a message using the private 554 key d, yielding an unforgeable cryptographic signature. 555 In order to leverage performance-enhancing caching features of certain 556 underlying storages, in particular DHTs, a deterministic signature 557 scheme is recommended. 558 </dd> 559 <dt>Verify(zk,message,signature) -> boolean</dt> 560 <dd> 561 is a function to verify the signature was created using 562 the private key d corresponding to the zone key zk 563 where d,zk := Keygen(). 564 The function returns a boolean value of "TRUE" if the signature is valid, 565 and otherwise "FALSE". 566 </dd> 567 <dt>SignDerived(d,label,message) -> signature</dt> 568 <dd> 569 is a function to sign a message (typically encrypted record data) that 570 can be verified using the derived zone key zk' := ZKDF(zk,label). 571 In order to leverage performance-enhancing caching features of certain 572 underlying storages, in particular DHTs, a deterministic signature 573 scheme is recommended. 574 </dd> 575 <dt>VerifyDerived(zk,label,message,signature) -> boolean</dt> 576 <dd> 577 is function to verify the signature using the derived zone key 578 zk' := ZKDF(zk,label). 579 The function returns a boolean value of "TRUE" if the signature is valid, 580 and otherwise "FALSE". 581 </dd> 582 </dl> 583 <t> 584 The cryptographic functions of the default ztypes are specified with 585 their corresponding delegation records in <xref target="gnsrecords_delegation"/>. 586 In order to support cryptographic agility, additional ztypes <bcp14>MAY</bcp14> 587 be defined in the future which replace or update the default ztypes defined in this 588 document. 589 All ztypes <bcp14>MUST</bcp14> be registered as dedicated zone delegation 590 record types in the GANA "GNS Record Types" registry (see <xref target="GANA"/>). 591 When defining new record types the cryptographic security considerations 592 of this document apply, in particular <xref target="security_cryptography"/>. 593 </t> 594 <section anchor="zTLD" numbered="true" toc="default"> 595 <name>Zone Top-Level Domain</name> 596 <t> 597 A zone Top-Level Domain (zTLD) is a string which encodes the 598 zone type and zone key into a domain name suffix. 599 A zTLD is used as a globally unique references to a 600 zone in the process of name resolution. 601 It is created by encoding a binary concatenation of the zone type and 602 zone key (see <xref target="figure_zid"/>). 603 The used encoding is a variation of the Crockford Base32 encoding 604 <xref target="CrockfordB32"/> called Base32GNS. 605 The encoding and decoding symbols for Base32GNS including this 606 modification are defined in <xref target="CrockfordB32Encode"/>. 607 The functions for encoding and decoding based on this table are called 608 Base32GNS-Encode and Base32GNS-Decode, respectively. 609 </t> 610 <figure anchor="figure_zid" title="The binary representation of the zTLD"> 611 <artwork name="" type="" align="left" alt=""><![CDATA[ 612 0 8 16 24 32 40 48 56 613 +-----+-----+-----+-----+-----+-----+-----+-----+ 614 | ZONE TYPE | ZONE KEY / 615 +-----+-----+-----+-----+ / 616 / / 617 / / 618 +-----+-----+-----+-----+-----+-----+-----+-----+ 619 ]]></artwork> 620 </figure> 621 <t> 622 The ZONE TYPE must be encoded in network byte order. The format 623 of the ZONE KEY depends entirely on the ZONE TYPE. 624 </t> 625 <t> 626 Consequently, a zTLD is encoded and decoded as follows: 627 </t> 628 <artwork name="" type="" align="left" alt=""><![CDATA[ 629 zTLD := Base32GNS-Encode(ztype||zkey) 630 ztype||zkey := Base32GNS-Decode(zTLD) 631 ]]></artwork> 632 <t> 633 where "||" is the concatenation operator. 634 </t> 635 <t> 636 The zTLD can be used as-is as a rightmost label in a GNS name. 637 If an application wants to ensure DNS compatibility of the name, 638 it <bcp14>MAY</bcp14> also represent the zTLD as follows: 639 If the zTLD is less than or equal to 63 characters, it can 640 be used as a zTLD as-is. 641 If the zTLD is longer than 63 characters, the 642 zTLD is divided into smaller labels separated by the label separator. 643 Here, the most significant bytes of the "ztype||zkey" concatenation 644 must be contained in the rightmost label of the resulting string and 645 the least significant bytes in the leftmost label of the resulting string. This allows the 646 resolver to determine the ztype and zTLD length from the rightmost 647 label and to subsequently determine how many labels the zTLD should span. 648 A GNS implementation <bcp14>MUST</bcp14> support the division of zTLDs 649 in DNS compatible label lengths. 650 For example, assuming a zTLD of 130 characters, the division is: 651 </t> 652 <!-- FIXME: Is this really really necessary? Really? --> 653 <artwork name="" type="" align="left" alt=""><![CDATA[ 654 zTLD[126..129].zTLD[63..125].zTLD[0..62] 655 ]]></artwork> 656 </section> 657 <section anchor="revocation" numbered="true" toc="default"> 658 <name>Zone Revocation</name> 659 <t> 660 In order to revoke a zone key, a signed revocation message <bcp14>MUST</bcp14> be 661 published. 662 This message <bcp14>MUST</bcp14> be signed using the private key of the zone. 663 The revocation message is broadcast to the network. 664 The specification of the broadcast mechanism is out of scope for this 665 document. 666 A possible broadcast mechanism for efficient flooding in a distributed 667 network is implemented in <xref target="GNUnet"/>. 668 Alternatively, revocation messages could also be distributed via a 669 distributed ledger or a trusted central server. 670 To prevent 671 flooding attacks, the revocation message <bcp14>MUST</bcp14> contain a proof of work 672 (PoW). 673 The revocation message including the PoW <bcp14>MAY</bcp14> be calculated 674 ahead of time to support timely revocation. 675 </t> 676 <t> 677 For all occurrences below, "Argon2id" is the Password-based Key 678 Derivation Function as defined in <xref target="RFC9106" />. For the 679 PoW calculations the algorithm is instantiated with the 680 following parameters: 681 </t> 682 <dl> 683 <dt>S</dt> 684 <dd>The salt. Fixed 16-byte string: "GnsRevocationPow".</dd> 685 <dt>t</dt> 686 <dd>Number of iterations: 3</dd> 687 <dt>m</dt> 688 <dd>Memory size in KiB: 1024</dd> 689 <dt>T</dt> 690 <dd>Output length of hash in bytes: 64</dd> 691 <dt>p</dt> 692 <dd>Parallelization parameter: 1</dd> 693 <dt>v</dt> 694 <dd>Algorithm version: 0x13</dd> 695 <dt>y</dt> 696 <dd>Algorithm type (Argon2id): 2</dd> 697 <dt>X</dt><dd>Unused</dd> 698 <dt>K</dt><dd>Unused</dd> 699 </dl> 700 <t> 701 <xref target="figure_revocation"/> illustrates the format 702 of the data "P" on which the PoW is calculated. 703 </t> 704 <figure anchor="figure_revocation" title="The Format of the PoW Data."> 705 <artwork name="" type="" align="left" alt=""><![CDATA[ 706 0 8 16 24 32 40 48 56 707 +-----+-----+-----+-----+-----+-----+-----+-----+ 708 | POW | 709 +-----------------------------------------------+ 710 | TIMESTAMP | 711 +-----------------------------------------------+ 712 | ZONE TYPE | ZONE KEY | 713 +-----+-----+-----+-----+ | 714 / / 715 / / 716 +-----+-----+-----+-----+-----+-----+-----+-----+ 717 ]]></artwork> 718 </figure> 719 <dl> 720 <dt>POW</dt> 721 <dd> 722 A 64-bit value that is a solution to the PoW. In network byte order. 723 </dd> 724 <dt>TIMESTAMP</dt> 725 <dd> 726 denotes the absolute 64-bit date when the revocation was computed. 727 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 728 byte order. 729 </dd> 730 <dt>ZONE TYPE</dt> 731 <dd> 732 is the 32-bit zone type in network byte order. 733 </dd> 734 <dt>ZONE KEY</dt> 735 <dd> 736 is the 256-bit public key zk of the zone which is being revoked. 737 The wire format of this value is defined by the ZONE TYPE. 738 </dd> 739 </dl> 740 <t> 741 Usually, PoW schemes require to find one POW value such that 742 a specific number of leading zeroes are found in the hash result. 743 This number is then referred to as the difficulty of the PoW. 744 In order to reduce the variance in time it takes to calculate the 745 PoW, a valid GNS revocation requires that a number Z different PoWs 746 must be found that on average have D leading zeroes. 747 </t> 748 <t> 749 Given an average difficulty of D, the proofs have an 750 expiration time of EPOCH. Applications <bcp14>MAY</bcp14> calculate proofs 751 with a difficulty that is higher than D by providing POW 752 values where there are (on average) more than D bits of leading zeros. 753 With each additional bit of difficulty, the 754 lifetime of the proof is prolonged by another EPOCH. 755 Consequently, by calculating a more difficult PoW, the lifetime of the 756 proof and thus the persistence of the revocation message 757 can be increased on demand by the zone owner. 758 </t> 759 <t> 760 The parameters are defined as follows: 761 </t> 762 <dl> 763 <dt>Z</dt> 764 <dd>The number of PoWs that are required. Its value is fixed at 32.</dd> 765 <dt>D</dt> 766 <dd>The lower limit of the average difficulty. Its value is fixed at 22.</dd> 767 <dt>EPOCH</dt> 768 <dd>A single epoch. Its value is fixed at 365 days in microseconds.</dd> 769 </dl> 770 <t> 771 The revocation message wire format is illustrated in 772 <xref target="figure_revocationdata"/>. 773 </t> 774 <figure anchor="figure_revocationdata" title="The Revocation Message Wire Format."> 775 <artwork name="" type="" align="left" alt=""><![CDATA[ 776 0 8 16 24 32 40 48 56 777 +-----+-----+-----+-----+-----+-----+-----+-----+ 778 | TIMESTAMP | 779 +-----+-----+-----+-----+-----+-----+-----+-----+ 780 | TTL | 781 +-----+-----+-----+-----+-----+-----+-----+-----+ 782 | POW_0 | 783 +-----+-----+-----+-----+-----+-----+-----+-----+ 784 | ... | 785 +-----+-----+-----+-----+-----+-----+-----+-----+ 786 | POW_Z-1 | 787 +-----------------------------------------------+ 788 | ZONE TYPE | ZONE KEY | 789 +-----+-----+-----+-----+ | 790 / / 791 / / 792 +-----+-----+-----+-----+-----+-----+-----+-----+ 793 | SIGNATURE | 794 / / 795 / / 796 | | 797 +-----+-----+-----+-----+-----+-----+-----+-----+ 798 ]]></artwork> 799 </figure> 800 <dl> 801 <dt>TIMESTAMP</dt> 802 <dd> 803 denotes the absolute 64-bit date when the revocation was computed. 804 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 805 byte order. This is the same value as the time stamp used in the 806 individual PoW calculations. 807 </dd> 808 <dt>TTL</dt> 809 <dd> 810 denotes the relative 64-bit time to live of the record in 811 microseconds in network byte order. 812 The field <bcp14>SHOULD</bcp14> be set to EPOCH * 1.1. 813 Given an average number of leading zeros D', then the field value 814 <bcp14>MAY</bcp14> be increased up to (D'-D+1) * EPOCH * 1.1. 815 Validators <bcp14>MAY</bcp14> reject messages with lower or higher 816 values when received. 817 </dd> 818 <dt>POW_i</dt> 819 <dd> 820 The values calculated as part of the PoW, in network byte order. 821 Each POW_i <bcp14>MUST</bcp14> be unique in the set of POW values. 822 To facilitate fast verification 823 of uniqueness, the POW values must be given in strictly 824 monotonically increasing order in the message. 825 </dd> 826 <dt>ZONE TYPE</dt> 827 <dd> 828 The 32-bit zone type corresponding to the zone key in network byte order. 829 </dd> 830 <dt>ZONE KEY</dt> 831 <dd> 832 is the public key zk of the zone which is being revoked and 833 the key to be used to verify SIGNATURE. 834 </dd> 835 <dt>SIGNATURE</dt> 836 <dd> 837 A signature over a time stamp and the zone zk of the zone 838 which is revoked and corresponds to the key used in the PoW. 839 The signature is created using the Sign() function of 840 the cryptosystem of the zone and the private key 841 (see <xref target="zones" />). 842 </dd> 843 </dl> 844 <t> 845 The signature over the public key covers a 32-bit header 846 prefixed to the time stamp and public key fields. 847 The header includes the key length and signature purpose. 848 The wire format is illustrated 849 in <xref target="figure_revsigwithpseudo"/>. 850 </t> 851 <figure anchor="figure_revsigwithpseudo" title="The Wire Format of the Revocation Data for Signing."> 852 <artwork name="" type="" align="left" alt=""><![CDATA[ 853 0 8 16 24 32 40 48 56 854 +-----+-----+-----+-----+-----+-----+-----+-----+ 855 | SIZE | PURPOSE (0x03) | 856 +-----+-----+-----+-----+-----+-----+-----+-----+ 857 | TIMESTAMP | 858 +-----+-----+-----+-----+-----+-----+-----+-----+ 859 | ZONE TYPE | ZONE KEY | 860 +-----+-----+-----+-----+ | 861 / / 862 / / 863 +-----+-----+-----+-----+-----+-----+-----+-----+ 864 ]]></artwork> 865 </figure> 866 <dl> 867 <dt>SIZE</dt> 868 <dd> 869 A 32-bit value containing the length of the signed data in bytes 870 in network byte order. 871 </dd> 872 <dt>PURPOSE</dt> 873 <dd> 874 A 32-bit signature purpose flag. 875 The value of this field <bcp14>MUST</bcp14> be 3. 876 The value is encoded in network byte order. 877 It defines the context in which 878 the signature is created so that it cannot be reused in other parts 879 of the protocol including possible future extensions. 880 The value of this field corresponds to an entry in the 881 GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>. 882 </dd> 883 <dt>TIMESTAMP</dt> 884 <dd> 885 Field as defined in the revocation message above. 886 </dd> 887 <dt>ZONE TYPE</dt> 888 <dd> 889 Field as defined in the revocation message above. 890 </dd> 891 <dt>ZONE KEY</dt> 892 <dd>Field as defined in the revocation message above.</dd> 893 </dl> 894 <t> 895 In order to validate a revocation the following steps <bcp14>MUST</bcp14> be taken: 896 </t> 897 <ol> 898 <li>The signature <bcp14>MUST</bcp14> be verified against the zone key.</li> 899 <li>The set of POW values <bcp14>MUST</bcp14> NOT contain duplicates which <bcp14>MUST</bcp14> be checked by verifying that the values are strictly monotonically increasing.</li> 900 <li>The average number of leading zeroes D' resulting from the provided 901 POW values <bcp14>MUST</bcp14> be greater than or equal to D. Implementers 902 <bcp14>MUST NOT</bcp14> use an integer data type to calculate or represent D'.</li> 903 </ol> 904 <t> 905 The TTL field in the revocation message is informational. 906 A revocation <bcp14>MAY</bcp14> be discarded without checking the POW 907 values or the signature if the TTL (in combination with TIMESTAMP) 908 indicates that the revocation has already expired. 909 The actual validity period of the 910 revocation <bcp14>MUST</bcp14> be determined by examining the leading 911 zeroes in the POW values. 912 </t> 913 <t> 914 The validity period of the revocation is calculated as 915 (D'-D+1) * EPOCH * 1.1. The EPOCH is extended by 916 10% in order to deal with unsynchronized clocks. 917 The validity period added on top of the TIMESTAMP yields the 918 expiration date. 919 If the current time is after the expiration date, the 920 revocation is considered stale. 921 </t> 922 <t> 923 Verified revocations <bcp14>MUST</bcp14> be stored locally. 924 The implementation <bcp14>MAY</bcp14> discard stale revocations and 925 evict then from the local store at any time. 926 </t> 927 <t> 928 Implementations <bcp14>MUST</bcp14> broadcast received revocations 929 if they are valid and not stale. 930 Should the calculated validity period differ from the TTL field value, 931 the calculated value <bcp14>MUST</bcp14> be used as TTL field value 932 when forwarding the revocation message. 933 Systems might disagree on the current time, so implementations 934 <bcp14>MAY</bcp14> use stale but otherwise valid 935 revocations but <bcp14>SHOULD NOT</bcp14> broadcast them. 936 Forwarded stale revocations <bcp14>MAY</bcp14> be discarded. 937 </t> 938 <t> 939 Any locally stored revocation <bcp14>MUST</bcp14> be considered during 940 delegation record processing (see <xref target="delegation_processing"/>). 941 </t> 942 </section> 943 944 945 </section> 946 <section anchor="rrecords" numbered="true" toc="default"> 947 <name>Resource Records</name> 948 <t> 949 A GNS implementation <bcp14>SHOULD</bcp14> provide a mechanism to create and manage local 950 zones as well as a persistence mechanism (such as a local database) for resource 951 records. 952 A new local zone is established by selecting a zone type and creating a 953 zone key pair. 954 If this mechanism is not implemented, 955 no zones can be published in the storage (see <xref target="publish"/>) 956 and name resolution is limited to non-local start zones 957 (see <xref target="governance"/>). 958 </t> 959 <t> 960 A GNS resource record holds the data of a specific record in a zone. 961 The resource record format is defined in 962 <xref target="figure_gnsrecord"/>. 963 </t> 964 <figure anchor="figure_gnsrecord" title="The Resource Record Wire Format."> 965 <artwork name="" type="" align="left" alt=""><![CDATA[ 966 0 8 16 24 32 40 48 56 967 +-----+-----+-----+-----+-----+-----+-----+-----+ 968 | EXPIRATION | 969 +-----+-----+-----+-----+-----+-----+-----+-----+ 970 | SIZE | FLAGS | TYPE | 971 +-----+-----+-----+-----+-----+-----+-----+-----+ 972 | DATA / 973 / / 974 / / 975 ]]></artwork> 976 </figure> 977 <dl> 978 <dt>EXPIRATION</dt> 979 <dd> 980 denotes the absolute 64-bit expiration date of the record. 981 In microseconds since midnight (0 hour), January 1, 1970 UTC in network 982 byte order. 983 </dd> 984 <dt>SIZE</dt> 985 <dd> 986 denotes the 16-bit size of the DATA field in bytes in network byte 987 order. 988 </dd> 989 <dt>FLAGS</dt> 990 <dd> 991 is a 16-bit bit field indicating special properties of the resource record. 992 The semantics of the different bits are defined below. 993 </dd> 994 <dt>TYPE</dt> 995 <dd> 996 is the 32-bit resource record type in 997 network byte order. This type can be one of the GNS resource 998 records as defined in <xref target="rrecords" /> or a DNS record 999 type as defined in <xref target="RFC1035" /> or any of the 1000 complementary standardized DNS resource record types. 1001 Note that values 1002 below 2^16 are reserved for 16-bit DNS Resorce Record types allocated by IANA <xref target="RFC6895" />. 1003 Values above 2^16 are allocated by the 1004 GANA "GNS Record Types" registry <xref target="GANA" />. 1005 </dd> 1006 <dt>DATA</dt> 1007 <dd> 1008 the variable-length resource record data payload. The content is defined 1009 by the 1010 respective type of the resource record. 1011 </dd> 1012 </dl> 1013 <t> 1014 The FLAGS field is used to indicate special properties of the resource record. 1015 An application creating resource records <bcp14>MUST</bcp14> set all bits 1016 in FLAGS to 0 unless it specifically understands and 1017 wants to set the respective flag. 1018 As additional flags can be defined in future protocol versions, 1019 if an application or implementation encounters a flag which it does not 1020 recognize, it <bcp14>MUST</bcp14> be ignored. However, all implementations 1021 <bcp14>MUST</bcp14> understand the SHADOW and CRITICAL flags defined below. 1022 Any combination of the flags specified below are valid. 1023 <xref target="figure_flag"/> 1024 illustrates the flag distribution in the 16-bit FLAGS field of a 1025 resource record: 1026 </t> 1027 <figure anchor="figure_flag" title="The Resource Record Flag Wire Format."> 1028 <artwork name="" type="" align="left" alt=""><![CDATA[ 1029 0 13 14 15 1030 +--------...+-------------+-------+---------+ 1031 | Reserved |SUPPLEMENTAL |SHADOW |CRITICAL | 1032 +--------...+-------------+-------+---------+ 1033 ]]></artwork> 1034 </figure> 1035 <dl> 1036 <dt>CRITICAL</dt> 1037 <dd> 1038 If this flag is set, it indicates that processing is critical. 1039 Implementations that do not support the record type or are otherwise 1040 unable to process the record <bcp14>MUST</bcp14> abort resolution upon encountering 1041 the record in the resolution process. 1042 </dd> 1043 <dt>SHADOW</dt> 1044 <dd> 1045 If this flag is set, this record <bcp14>MUST</bcp14> be ignored by resolvers unless all (other) 1046 records of the same record type have expired. Used to allow zone publishers to 1047 facilitate good performance when records change by allowing them to put future 1048 values of records into the storage. 1049 This way, future values can propagate and can be 1050 cached before the transition becomes active. 1051 </dd> 1052 <dt>SUPPLEMENTAL</dt> 1053 <dd> 1054 This is a supplemental record. It is provided in addition to the 1055 other records. This flag indicates that this record is not explicitly 1056 managed alongside the other records under the respective name but 1057 might be useful for the application. 1058 </dd> 1059 </dl> 1060 <section anchor="gnsrecords_delegation" numbered="true" toc="default"> 1061 <name>Zone Delegation Records</name> 1062 <t> 1063 This section defines the initial set of zone delegation record types. 1064 Any implementation <bcp14>SHOULD</bcp14> support all zone types defined here and 1065 <bcp14>MAY</bcp14> support any number of additional delegation records defined in 1066 the GANA "GNS Record Types" registry (see <xref target="GANA"/>). 1067 Not supporting some zone types will result in resolution failures in case 1068 the respective zone type is encountered. 1069 This can be a valid choice if some zone delegation record types have been 1070 determined to be cryptographically insecure. 1071 Zone delegation records <bcp14>MUST NOT</bcp14> be stored and published 1072 under the apex label. 1073 A zone delegation record type value is the same as the respective ztype 1074 value. 1075 The ztype defines the cryptographic primitives for the zone that is 1076 being delegated to. 1077 A zone delegation record payload contains the public key of 1078 the zone to delegate to. 1079 A zone delegation record <bcp14>MUST</bcp14> have the CRITICAL flag set 1080 and <bcp14>MUST</bcp14> be the only non-supplemental record under a label. 1081 There <bcp14>MAY</bcp14> be inactive records of the same type which have 1082 the SHADOW flag set in order to facilitate smooth key rollovers. 1083 </t> 1084 <t> 1085 In the following, "||" is the concatenation operator of two byte strings. 1086 The algorithm specification uses character strings such as GNS labels or 1087 constant values. 1088 When used in concatenations or as input to functions the 1089 null-terminator of the character strings <bcp14>MUST NOT</bcp14> be 1090 included. 1091 </t> 1092 <section anchor="gnsrecords_pkey" numbered="true" toc="default"> 1093 <name>PKEY</name> 1094 <t> 1095 In GNS, a delegation of a label to a zone of type "PKEY" is 1096 represented through a PKEY record. The PKEY DATA entry wire format can be found in <xref target="figure_pkeyrecord"/>. 1097 </t> 1098 <figure anchor="figure_pkeyrecord" title="The PKEY Wire Format."> 1099 <artwork name="" type="" align="left" alt=""><![CDATA[ 1100 0 8 16 24 32 40 48 56 1101 +-----+-----+-----+-----+-----+-----+-----+-----+ 1102 | PUBLIC KEY | 1103 | | 1104 | | 1105 | | 1106 +-----+-----+-----+-----+-----+-----+-----+-----+ 1107 ]]></artwork> 1108 </figure> 1109 <dl> 1110 <dt>PUBLIC KEY</dt> 1111 <dd> 1112 A 256-bit Ed25519 public key. 1113 </dd> 1114 </dl> 1115 1116 <t> 1117 For PKEY zones the zone key material is derived using the 1118 curve parameters of the twisted Edwards representation 1119 of Curve25519 <xref target="RFC7748" /> (the reasoning behind choosing 1120 this curve can be found in <xref target="security_cryptography"/>) 1121 with the ECDSA scheme <xref target="RFC6979" />. 1122 The following naming convention is used for the cryptographic primitives of PKEY zones: 1123 </t> 1124 <dl> 1125 <dt>d</dt> 1126 <dd> 1127 is a 256-bit Ed25519 private key (clamped private scalar). 1128 </dd> 1129 <dt>zk</dt> 1130 <dd> 1131 is the Ed25519 public zone key corresponding to d. 1132 </dd> 1133 <dt>p</dt> 1134 <dd> 1135 is the prime of edwards25519 as defined in <xref target="RFC7748" />, i.e. 1136 2^255 - 19. 1137 </dd> 1138 <dt>G</dt> 1139 <dd> 1140 is the group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in 1141 <xref target="RFC7748" />. 1142 </dd> 1143 <dt>L</dt> 1144 <dd> 1145 is the order of the prime-order subgroup of edwards25519 in <xref target="RFC7748" />. 1146 </dd> 1147 <dt>KeyGen()</dt> 1148 <dd>The generation of the private 1149 scalar d and the curve point zk := d*G (where G is the group generator 1150 of the elliptic curve) as defined in Section 2.2. of 1151 <xref target="RFC6979" /> represents the KeyGen() function. 1152 </dd> 1153 </dl> 1154 <t> 1155 The zone type and zone key of a PKEY are 4 + 32 bytes in length. This means that 1156 a zTLD will always fit into a single label and does 1157 not need any further conversion. 1158 Given a label, the output zk' of the ZKDF(zk,label) function is 1159 calculated as follows for PKEY zones: 1160 </t> 1161 <artwork name="" type="" align="left" alt=""><![CDATA[ 1162 ZKDF(zk,label): 1163 PRK_h := HKDF-Extract ("key-derivation", zk) 1164 h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) 1165 zk' := (h mod L) * zk 1166 return zk' 1167 ]]></artwork> 1168 <t> 1169 The PKEY cryptosystem uses a hash-based key derivation function (HKDF) as defined in 1170 <xref target="RFC5869" />, using SHA-512 <xref target="RFC6234"/> for the extraction 1171 phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1172 PRK_h is key material retrieved using an HKDF using the string 1173 "key-derivation" as salt and the zone key as initial 1174 keying material. 1175 h is the 512-bit HKDF expansion result and must be interpreted in 1176 network byte order. The expansion information input is 1177 a concatenation of the label and the string "gns". 1178 The multiplication of zk with h is a point multiplication, 1179 while the multiplication of d with h is a scalar multiplication. 1180 </t> 1181 <t> 1182 The Sign() and Verify() functions 1183 for PKEY zones are implemented using 512-bit ECDSA deterministic 1184 signatures as specified in <xref target="RFC6979" />. 1185 The same functions can be used for derived keys: 1186 </t> 1187 <artwork name="" type="" align="left" alt=""><![CDATA[ 1188 SignDerived(d,label,message): 1189 zk := d * G 1190 PRK_h := HKDF-Extract ("key-derivation", zk) 1191 h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) 1192 d' := (h * d) mod L 1193 return Sign(d',message) 1194 ]]></artwork> 1195 <t> 1196 A signature (R,S) is valid if the following holds: 1197 </t> 1198 <artwork name="" type="" align="left" alt=""><![CDATA[ 1199 VerifyDerived(zk,label,message,signature): 1200 zk' := ZKDF(zk,label) 1201 return Verify(zk',message,signature) 1202 ]]></artwork> 1203 <t> 1204 The S-Encrypt() and S-Decrypt() functions use AES in counter mode 1205 as defined in <xref target="MODES" /> (CTR-AES-256): 1206 </t> 1207 <artwork name="" type="" align="left" alt=""><![CDATA[ 1208 S-Encrypt(zk,label,expiration,plaintext): 1209 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 1210 PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) 1211 K := HKDF-Expand (PRK_k, label, 256 / 8) 1212 NONCE := HKDF-Expand (PRK_n, label, 32 / 8) 1213 IV := NONCE || expiration || 0x0000000000000001 1214 return CTR-AES256(K, IV, plaintext) 1215 1216 S-Decrypt(zk,label,expiration,ciphertext): 1217 PRK_k := HKDF-Extract ("gns-aes-ctx-key", zk) 1218 PRK_n := HKDF-Extract ("gns-aes-ctx-iv", zk) 1219 K := HKDF-Expand (PRK_k, label, 256 / 8) 1220 NONCE := HKDF-Expand (PRK_n, label, 32 / 8) 1221 IV := NONCE || expiration || 0x0000000000000001 1222 return CTR-AES256(K, IV, ciphertext) 1223 ]]></artwork> 1224 <t> 1225 The key K and counter IV are derived from 1226 the record label and the zone key zk using a hash-based key 1227 derivation function (HKDF) as defined in <xref target="RFC5869" />. 1228 SHA-512 <xref target="RFC6234"/> is used for the 1229 extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1230 The output keying material is 32 bytes (256 bits) for the symmetric 1231 key and 4 bytes (32 bits) for the nonce. 1232 The symmetric key K is a 256-bit AES <xref target="RFC3826" /> key. 1233 </t> 1234 <t> 1235 The nonce is combined with a 64-bit initialization vector and a 1236 32-bit block counter as defined in <xref target="RFC3686" />. 1237 The block counter begins with the value of 1, and it is incremented 1238 to generate subsequent portions of the key stream. 1239 The block counter is a 32-bit integer value in network byte order. 1240 The initialization vector is the expiration time of the 1241 resource record block in network byte order. 1242 The resulting counter (IV) wire format can be found in 1243 <xref target="figure_hkdf_ivs_pkey"/>. 1244 </t> 1245 <figure anchor="figure_hkdf_ivs_pkey" title="The Block Counter Wire Format."> 1246 <artwork name="" type="" align="left" alt=""><![CDATA[ 1247 0 8 16 24 32 1248 +-----+-----+-----+-----+ 1249 | NONCE | 1250 +-----+-----+-----+-----+ 1251 | EXPIRATION | 1252 | | 1253 +-----+-----+-----+-----+ 1254 | BLOCK COUNTER | 1255 +-----+-----+-----+-----+ 1256 ]]></artwork> 1257 </figure> 1258 </section> 1259 <section anchor="gnsrecords_edkey" numbered="true" toc="default"> 1260 <name>EDKEY</name> 1261 <t> 1262 In GNS, a delegation of a label to a zone of type "EDKEY" is 1263 represented through a EDKEY record. 1264 The EDKEY DATA entry wire format 1265 is illustrated in <xref target="figure_edkeyrecord"/>. 1266 </t> 1267 <figure anchor="figure_edkeyrecord" title="The EDKEY DATA Wire Format."> 1268 <artwork name="" type="" align="left" alt=""><![CDATA[ 1269 0 8 16 24 32 40 48 56 1270 +-----+-----+-----+-----+-----+-----+-----+-----+ 1271 | PUBLIC KEY | 1272 | | 1273 | | 1274 | | 1275 +-----+-----+-----+-----+-----+-----+-----+-----+ 1276 ]]></artwork> 1277 </figure> 1278 <dl> 1279 <dt>PUBLIC KEY</dt> 1280 <dd> 1281 A 256-bit EdDSA zone key. 1282 </dd> 1283 </dl> 1284 <t> 1285 For EDKEY zones the zone key material is derived using the 1286 curve parameters of the twisted edwards representation 1287 of Curve25519 <xref target="RFC7748" /> (a.k.a. Ed25519) 1288 with the Ed25519 scheme <xref target="ed25519" /> as specified in 1289 <xref target="RFC8032" />. 1290 The following naming convention is used for the 1291 cryptographic primitives of EDKEY zones: 1292 </t> 1293 <!-- Check if we want to use RFC8032 instead of paper ed25519 --> 1294 <dl> 1295 <dt>d</dt> 1296 <dd> 1297 is a 256-bit EdDSA private key. 1298 </dd> 1299 <dt>a</dt> 1300 <dd> 1301 is is an integer derived from d using the SHA-512 hash function 1302 as defined in <xref target="RFC8032" />. 1303 </dd> 1304 <dt>zk</dt> 1305 <dd> 1306 is the EdDSA public key corresponding to d. It is defined 1307 as the curve point a*G where G is the 1308 group generator of the elliptic curve 1309 as defined in <xref target="RFC8032" />. 1310 </dd> 1311 <dt>p</dt> 1312 <dd> 1313 is the prime of edwards25519 as defined in <xref target="RFC8032" />, i.e. 1314 2^255 - 19. 1315 </dd> 1316 <dt>G</dt> 1317 <dd> 1318 is the group generator (X(P),Y(P)). With X(P),Y(P) of edwards25519 as defined in 1319 <xref target="RFC8032" />. 1320 </dd> 1321 <dt>L</dt> 1322 <dd> 1323 is the order of the prime-order subgroup of edwards25519 in <xref target="RFC8032" />. 1324 </dd> 1325 <dt>KeyGen()</dt> 1326 <dd> 1327 The generation of the private key d and the associated public 1328 key zk := a*G where G is the 1329 group generator of the elliptic curve and a is an integer 1330 derived from d using the SHA-512 hash function 1331 as defined 1332 in Section 5.1.5 of <xref target="RFC8032" /> represents the KeyGen() 1333 function. 1334 </dd> 1335 </dl> 1336 <t> 1337 The zone type and zone key of an EDKEY are 4 + 32 bytes in length. This means that 1338 a zTLD will always fit into a single label and does 1339 not need any further conversion. 1340 </t> 1341 <t> 1342 The "EDKEY" ZKDF instantiation is based on <xref target="Tor224"/>. 1343 The calculation of a is defined in Section 5.1.5 of <xref target="RFC8032" />. 1344 Given a label, the output of the ZKDF function is 1345 calculated as follows: 1346 </t> 1347 <artwork name="" type="" align="left" alt=""><![CDATA[ 1348 ZKDF(zk,label): 1349 /* Calculate the blinding factor */ 1350 PRK_h := HKDF-Extract ("key-derivation", zk) 1351 h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) 1352 /* Ensure that h == h mod L */ 1353 h = h mod L 1354 1355 zk' := h * zk 1356 return zk' 1357 ]]></artwork> 1358 <t> 1359 Implementers <bcp14>SHOULD</bcp14> employ a constant time scalar 1360 multiplication for the constructions above to protect against 1361 timing attacks. Otherwise, timing attacks could leak private key 1362 material if an attacker can predict when a system starts the 1363 publication process. 1364 <!--Also, implementers 1365 <bcp14>MUST</bcp14> ensure that the private key a is an ed25519 private key 1366 and specifically that "a[0] & 7 == 0" holds.--> 1367 </t> 1368 <t> 1369 The EDKEY cryptosystem uses a 1370 hash-based key derivation function (HKDF) as defined in 1371 <xref target="RFC5869" />, using SHA-512 <xref target="RFC6234"/> for the extraction 1372 phase and HMAC-SHA256 <xref target="RFC6234"/> for the expansion phase. 1373 PRK_h is key material retrieved using an HKDF using the string 1374 "key-derivation" as salt and the zone key as initial 1375 keying material. 1376 The blinding factor h is the 512-bit HKDF expansion result. 1377 The expansion information input is 1378 a concatenation of the label and the string "gns". 1379 The result of the HKDF must be clamped and interpreted in network 1380 byte order. 1381 a is the 256-bit integer corresponding to the 256-bit private 1382 key d. 1383 The multiplication of zk with h is a point multiplication, 1384 while the division and multiplication of a and a1 with the 1385 co-factor are integer operations. 1386 </t> 1387 <t> 1388 The Sign(d,message) and Verify(zk,message,signature) procedures <bcp14>MUST</bcp14> 1389 be implemented as defined in <xref target="RFC8032" />. 1390 </t> 1391 <t> 1392 Signatures for EDKEY zones use a derived private scalar d' 1393 which is not compliant with <xref target="RFC8032" />. 1394 As the corresponding private key to the derived private scalar 1395 is not known, it is not possible to deterministically derive the 1396 signature part R according to <xref target="RFC8032" />. 1397 Instead, signatures <bcp14>MUST</bcp14> be generated as follows for any given 1398 message and private zone key: 1399 A nonce is calculated from the highest 32 bytes of the 1400 expansion of the private key d and the blinding factor h. 1401 The nonce is then hashed with the message to r. 1402 This way, the full derivation path is included in the calculation 1403 of the R value of the signature, ensuring that it is never reused 1404 for two different derivation paths or messages. 1405 </t> 1406 <artwork name="" type="" align="left" alt=""><![CDATA[ 1407 SignDerived(d,label,message): 1408 /* Key expansion */ 1409 dh := SHA-512 (d) 1410 /* EdDSA clamping */ 1411 a := dh[0..31] 1412 a[0] &= 248 1413 a[31] &= 127 1414 a[31] |= 64 1415 /* Calculate zk corresponding to d */ 1416 zk := a * G 1417 1418 /* Calculate blinding factor */ 1419 PRK_h := HKDF-Extract ("key-derivation", zk) 1420 h := HKDF-Expand (PRK_h, label || "gns", 512 / 8) 1421 /* Ensure that h == h mod L */ 1422 h = h mod L 1423 1424 zk' := h * zk 1425 d' := (h * a) mod L 1426 nonce := SHA-256 (dh[32..63] || h) 1427 r := SHA-512 (nonce || message) 1428 R := r * G 1429 S := r + SHA-512(R || zk' || message) * d' mod L 1430 return (R,S) 1431 ]]></artwork> 1432 <t> 1433 A signature (R,S) is valid if the following holds: 1434 </t> 1435 <artwork name="" type="" align="left" alt=""><![CDATA[ 1436 VerifyDerived(zk,label,message,signature): 1437 zk' := ZKDF(zk,label) 1438 (R,S) := signature 1439 return S * G == R + SHA-512(R, zk', message) * zk' 1440 ]]></artwork> 1441 <t> 1442 The S-Encrypt() and S-Decrypt() functions use XSalsa20 1443 as defined in <xref target="XSalsa20" /> 1444 (XSalsa20-Poly1305): 1445 </t> 1446 <artwork name="" type="" align="left" alt=""><![CDATA[ 1447 S-Encrypt(zk,label,expiration,plaintext): 1448 PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) 1449 PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) 1450 K := HKDF-Expand (PRK_k, label, 256 / 8) 1451 NONCE := HKDF-Expand (PRK_n, label, 128 / 8) 1452 IV := NONCE || expiration 1453 return XSalsa20-Poly1305(K, IV, plaintext) 1454 1455 S-Decrypt(zk,label,expiration,ciphertext): 1456 PRK_k := HKDF-Extract ("gns-xsalsa-ctx-key", zk) 1457 PRK_n := HKDF-Extract ("gns-xsalsa-ctx-iv", zk) 1458 K := HKDF-Expand (PRK_k, label, 256 / 8) 1459 NONCE := HKDF-Expand (PRK_n, label, 128 / 8) 1460 IV := NONCE || expiration 1461 return XSalsa20-Poly1305(K, IV, ciphertext) 1462 ]]></artwork> 1463 <t> 1464 The result of the XSalsa20-Poly1305 encryption function is the encrypted 1465 ciphertext followed by the 128-bit authentication 1466 tag. 1467 Accordingly, the length of encrypted data equals the length of the 1468 data plus the 16 bytes of the authentication tag. 1469 </t> 1470 <t> 1471 The key K and counter IV are derived from 1472 the record label and the zone key zk using a hash-based key 1473 derivation function (HKDF) as defined in 1474 <xref target="RFC5869" />. 1475 SHA-512 <xref target="RFC6234"/> is used for the 1476 extraction phase and SHA-256 <xref target="RFC6234"/> for the expansion phase. 1477 The output keying material is 32 bytes (256 bits) for the symmetric 1478 key and 16 bytes (128 bits) for the NONCE. 1479 The symmetric key K is a 256-bit XSalsa20 1480 <xref target="XSalsa20" /> key. 1481 No additional authenticated data (AAD) is used. 1482 </t> 1483 <t> 1484 The nonce is combined with an 8 byte initialization vector. 1485 The initialization vector is the expiration time of the 1486 resource record block in network byte order. 1487 The resulting counter (IV) wire format is illustrated in 1488 <xref target="figure_hkdf_ivs_edkey"/>. 1489 </t> 1490 <figure anchor="figure_hkdf_ivs_edkey" title="The Counter Block Initialization Vector."> 1491 <artwork name="" type="" align="left" alt=""><![CDATA[ 1492 0 8 16 24 32 1493 +-----+-----+-----+-----+ 1494 | NONCE | 1495 | | 1496 | | 1497 | | 1498 +-----+-----+-----+-----+ 1499 | EXPIRATION | 1500 | | 1501 +-----+-----+-----+-----+ 1502 ]]></artwork> 1503 </figure> 1504 </section> 1505 </section> 1506 <section anchor="gnsrecords_redirect" numbered="true" toc="default"> 1507 <name>Redirection Records</name> 1508 <t> 1509 Redirect records are used to redirect resolution. 1510 Any implementation <bcp14>SHOULD</bcp14> support all redirection record types defined here 1511 and <bcp14>MAY</bcp14> support any number of additional redirection records defined in 1512 the GANA "GNS Record Types" registry <xref target="GANA"/>. 1513 Redirection records <bcp14>MUST</bcp14> have the CRITICAL flag set. 1514 Not supporting some record types can result in resolution failures. 1515 This can be a valid choice if some redirection record types have been 1516 determined to be insecure, or if an application has reasons to not 1517 support redirection to DNS for reasons such as complexity or security. 1518 Redirection records <bcp14>MUST NOT</bcp14> be stored and published under the apex label. 1519 </t> 1520 <section anchor="gnsrecords_rdr" numbered="true" toc="default"> 1521 <name>REDIRECT</name> 1522 <t> 1523 A REDIRECT record is the GNS equivalent of a CNAME record in DNS. 1524 A REDIRECT record <bcp14>MUST</bcp14> be the only non-supplemental 1525 record under a label. 1526 There <bcp14>MAY</bcp14> be inactive records of the same type which have 1527 the SHADOW flag set in order to facilitate smooth changes of redirection 1528 targets. 1529 No other records are allowed. 1530 Details on processing of this record is defined in <xref target="redirect_processing"/>. 1531 1532 A REDIRECT DATA entry is illustrated in <xref target="figure_redirectrecord"/>. 1533 </t> 1534 <figure anchor="figure_redirectrecord" title="The REDIRECT DATA Wire Format."> 1535 <artwork name="" type="" align="left" alt=""><![CDATA[ 1536 0 8 16 24 32 40 48 56 1537 +-----+-----+-----+-----+-----+-----+-----+-----+ 1538 | REDIRECT NAME | 1539 / / 1540 / / 1541 | | 1542 +-----+-----+-----+-----+-----+-----+-----+-----+ 1543 ]]></artwork> 1544 </figure> 1545 <dl> 1546 <dt>REDIRECT NAME</dt> 1547 <dd> 1548 The name to continue with. 1549 The value of a redirect record can be a regular name, or a relative 1550 name. 1551 Relative GNS names are indicated by an extension label (U+002B, "+") 1552 as rightmost label. 1553 The string is UTF-8 encoded and 0-terminated. 1554 </dd> 1555 </dl> 1556 </section> 1557 <section anchor="gnsrecords_gns2dns" numbered="true" toc="default"> 1558 <name>GNS2DNS</name> 1559 <t> 1560 A GNS2DNS record delegates resolution to DNS. 1561 The resource record contains a DNS name for the resolver to continue with 1562 in DNS followed by a DNS server. Both names are in the format defined in 1563 <xref target="RFC1034" /> for DNS names. 1564 There <bcp14>MAY</bcp14> be multiple GNS2DNS records under a label. 1565 There <bcp14>MAY</bcp14> also be DNSSEC DS records or any other records used to 1566 secure the connection with the DNS servers under the same label. 1567 There <bcp14>MAY</bcp14> be inactive records of the same type(s) which have 1568 the SHADOW flag set in order to facilitate smooth changes of redirection 1569 targets. 1570 No other non-supplemental record types are allowed in the same record set. 1571 A GNS2DNS DATA entry is illustrated in <xref target="figure_gns2dnsrecord"/>.</t> 1572 <figure anchor="figure_gns2dnsrecord" title="The GNS2DNS DATA Wire Format."> 1573 <artwork name="" type="" align="left" alt=""><![CDATA[ 1574 0 8 16 24 32 40 48 56 1575 +-----+-----+-----+-----+-----+-----+-----+-----+ 1576 | NAME | 1577 / / 1578 / / 1579 | | 1580 +-----+-----+-----+-----+-----+-----+-----+-----+ 1581 | DNS SERVER NAME | 1582 / / 1583 / / 1584 | | 1585 +-----------------------------------------------+ 1586 ]]></artwork> 1587 </figure> 1588 <dl> 1589 <dt>NAME</dt> 1590 <dd> 1591 The name to continue with in DNS. The value is UTF-8 encoded and 1592 0-terminated. 1593 </dd> 1594 <dt>DNS SERVER NAME</dt> 1595 <dd> 1596 The DNS server to use. This value can be an IPv4 address in dotted-decimal 1597 form or an IPv6 address in colon-hexadecimal form or a DNS name. 1598 It can also be a relative GNS name ending with a 1599 "+" as the rightmost label. 1600 The implementation <bcp14>MUST</bcp14> check the string syntactically for 1601 an IP address in the respective notation before checking for a 1602 relative GNS name. 1603 If all three checks fail, the name <bcp14>MUST</bcp14> be treated as a DNS name. 1604 The value is UTF-8 encoded and 0-terminated. 1605 </dd> 1606 </dl> 1607 <t> 1608 NOTE: If an application uses DNS names obtained from GNS2DNS records 1609 in a DNS request they <bcp14>MUST</bcp14> first be converted to an IDNA compliant 1610 representation <xref target="RFC5890" />. 1611 </t> 1612 </section> 1613 </section> 1614 <section anchor="gnsrecords_other" numbered="true" toc="default"> 1615 <name>Auxiliary Records</name> 1616 <t> 1617 This section defines the initial set of auxiliary GNS record types. Any 1618 implementation <bcp14>SHOULD</bcp14> be able to process the specified record types 1619 according to <xref target="record_processing"/>. 1620 </t> 1621 <section anchor="gnsrecords_leho" numbered="true" toc="default"> 1622 <name>LEHO</name> 1623 <t> 1624 This record is used to provide a hint for LEgacy HOstnames: 1625 Applications can use the GNS to lookup IPv4 or IPv6 addresses of 1626 internet services. 1627 However, sometimes connecting to such services does not only require 1628 the knowledge of an address and port, but also requires the canonical 1629 DNS name of the service to be transmitted over the transport protocol. 1630 In GNS, legacy host name records provide applications the DNS name that 1631 is required to establish a connection to such a service. 1632 The most common use case is HTTP virtual hosting and TLS Server Name 1633 Indication <xref target="RFC6066"/>, where a DNS name must 1634 be supplied in the HTTP "Host"-header and the TLS handshake, 1635 respectively. 1636 Using a GNS name in those cases might not work as 1637 it might not be globally unique. Furthermore, even if uniqueness is 1638 not an issue, the legacy service might not even be aware of GNS. 1639 </t> 1640 <t> 1641 A LEHO resource record is expected to be found together in a single 1642 resource record with an IPv4 or IPv6 address. 1643 A LEHO DATA entry is illustrated in <xref target="figure_lehorecord"/>. 1644 </t> 1645 <figure anchor="figure_lehorecord" title="The LEHO DATA Wire Format."> 1646 <artwork name="" type="" align="left" alt=""><![CDATA[ 1647 0 8 16 24 32 40 48 56 1648 +-----+-----+-----+-----+-----+-----+-----+-----+ 1649 | LEGACY HOSTNAME | 1650 / / 1651 / / 1652 | | 1653 +-----+-----+-----+-----+-----+-----+-----+-----+ 1654 ]]></artwork> 1655 </figure> 1656 <dl> 1657 <dt>LEGACY HOSTNAME</dt> 1658 <dd> 1659 A UTF-8 string (which is not 0-terminated) representing the legacy hostname. 1660 </dd> 1661 </dl> 1662 <t> 1663 NOTE: If an application uses a LEHO value in an HTTP request header 1664 (e.g. "Host:" header) it <bcp14>MUST</bcp14> be converted to an IDNA compliant representation 1665 <xref target="RFC5890" />. 1666 </t> 1667 </section> 1668 <section anchor="gnsrecords_nick" numbered="true" toc="default"> 1669 <name>NICK</name> 1670 <t> 1671 Nickname records can be used by zone administrators to publish a 1672 label that a zone prefers to have used when it is referred to. 1673 This is a suggestion to other zones what label to use when creating a 1674 delegation record (<xref target="gnsrecords_delegation" />) containing 1675 this zone key. 1676 This record <bcp14>SHOULD</bcp14> only be stored locally 1677 under the apex label "@" but <bcp14>MAY</bcp14> be 1678 returned with record sets under any label as a supplemental record. 1679 <xref target="nick_processing"/> details how a resolver must process 1680 supplemental and non-supplemental NICK records. 1681 A NICK DATA entry is illustrated in <xref target="figure_nickrecord"/>. 1682 </t> 1683 <figure anchor="figure_nickrecord" title="The NICK DATA Wire Format."> 1684 <artwork name="" type="" align="left" alt=""><![CDATA[ 1685 0 8 16 24 32 40 48 56 1686 +-----+-----+-----+-----+-----+-----+-----+-----+ 1687 | NICKNAME | 1688 / / 1689 / / 1690 | | 1691 +-----+-----+-----+-----+-----+-----+-----+-----+ 1692 ]]></artwork> 1693 </figure> 1694 <dl> 1695 <dt>NICKNAME</dt> 1696 <dd> 1697 A UTF-8 string (which is not 0-terminated) representing the preferred 1698 label of the zone. This string <bcp14>MUST</bcp14> be a valid GNS label. 1699 </dd> 1700 </dl> 1701 </section> 1702 <section anchor="gnsrecords_box" numbered="true" toc="default"> 1703 <name>BOX</name> 1704 <t> 1705 GNS lookups are expected to return all of the required useful 1706 information in one record set. This avoids unnecessary additional 1707 lookups and cryptographically ties together information that belongs 1708 together, making it impossible for an adversarial storage to provide 1709 partial answers that might omit information critical for security. 1710 </t> 1711 <t> 1712 This general strategy is incompatible with the 1713 special labels used by DNS for SRV and TLSA records. Thus, GNS 1714 defines the BOX record format to box up SRV and TLSA records and 1715 include them in the record set of the label they are associated 1716 with. For example, a 1717 TLSA record for "_https._tcp.example.org" will be stored in the record set of 1718 "example.org" as a BOX record with service (SVC) 443 (https) and protocol (PROTO) 6 1719 (tcp) and record TYPE "TLSA". 1720 For reference, see also <xref target="RFC2782" />. 1721 A BOX DATA entry is illustrated in <xref target="figure_boxrecord"/>. 1722 </t> 1723 <figure anchor="figure_boxrecord" title="The BOX DATA Wire Format."> 1724 <artwork name="" type="" align="left" alt=""><![CDATA[ 1725 0 8 16 24 32 40 48 56 1726 +-----+-----+-----+-----+-----+-----+-----+-----+ 1727 | PROTO | SVC | TYPE | 1728 +-----------+-----------------------------------+ 1729 | RECORD DATA | 1730 / / 1731 / / 1732 | | 1733 +-----+-----+-----+-----+-----+-----+-----+-----+ 1734 ]]></artwork> 1735 </figure> 1736 <dl> 1737 <dt>PROTO</dt> 1738 <dd> 1739 the 16-bit protocol number in network byte order. 1740 Values 1741 below 2^8 are reserved for 8-bit Internet Protocol numbers allocated by IANA <xref target="RFC5237" /> 1742 (e.g. 6 for TCP). 1743 Values above 2^8 are allocated by the 1744 GANA "Overlay Protocols" registry <xref target="GANA" />. 1745 </dd> 1746 <dt>SVC</dt> 1747 <dd> 1748 the 16-bit service value of the boxed record in network byte order. In case of 1749 TCP and UDP it is the port number. 1750 </dd> 1751 <dt>TYPE</dt> 1752 <dd> 1753 is the 32-bit record type of the boxed record in network byte order. 1754 </dd> 1755 <dt>RECORD DATA</dt> 1756 <dd> 1757 is a variable length field containing the "DATA" format of TYPE as 1758 defined for the respective TYPE. Thus, for TYPE values below 2^16, the 1759 format is the same as the respective record type's binary format in DNS. 1760 </dd> 1761 </dl> 1762 </section> 1763 </section> 1764 </section> 1765 <section anchor="publish" numbered="true" toc="default"> 1766 <name>Record Encoding for Remote Storage</name> 1767 <t> 1768 Any API which allows storing a block under a 512-bit key and retrieving 1769 one or more blocks from a key can be used by an implementation for remote storage. 1770 To be useful, the API <bcp14>MUST</bcp14> permit storing at least 176 byte blocks 1771 to be able to support the defined zone delegation record encodings, 1772 and <bcp14>SHOULD</bcp14> allow at least 1024 byte blocks. 1773 In the following, it is assumed that an implementation realizes two 1774 procedures on top of a storage: 1775 </t> 1776 <artwork name="" type="" align="left" alt=""><![CDATA[ 1777 PUT(key,block) 1778 GET(key) -> block 1779 ]]></artwork> 1780 <t> 1781 A GNS implementation publishes blocks 1782 in accordance to the properties and recommendations of the underlying 1783 remote storage. This can include a periodic refresh operation to preserve the 1784 availability of published blocks. 1785 </t> 1786 <t> 1787 There is no mechanism to explicitly delete individual blocks from remote storage. 1788 However, blocks include an EXPIRATION field which guides remote 1789 storage implementations to decide when to delete blocks. Given multiple blocks 1790 for the same key, remote storage implementations <bcp14>SHOULD</bcp14> try 1791 to preserve and return the block with the largest EXPIRATION value. 1792 </t> 1793 <t> 1794 All resource records from the same zone sharing the same label are 1795 encrypted and published together in a single resource records block 1796 (RRBLOCK) in the remote storage under a key q as illustrated 1797 in <xref target="figure_storage_publish"/>. 1798 A GNS implementation <bcp14>MUST NOT</bcp14> include expired resource 1799 records in blocks. 1800 An implementation <bcp14>MUST</bcp14> use the PUT storage procedure 1801 when record sets change to update the zone contents. Implementations 1802 <bcp14>MUST</bcp14> ensure that the EXPIRATION fields of RRBLOCKs 1803 increases strictly monotonically for every change, even if the smallest 1804 expiration time of records in the block does not. 1805 </t> 1806 <figure anchor="figure_storage_publish" title="Management and publication of local zones in the distributed storage."> 1807 <artwork name="" type="" align="left" alt=""><![CDATA[ 1808 Local Host | Remote 1809 | Storage 1810 | 1811 | +---------+ 1812 | / /| 1813 | +---------+ | 1814 +-----------+ | | | | 1815 | | +---------+PUT(q, RRBLOCK) | | Record | | 1816 | User | | Zone |----------------|->| Storage | | 1817 | | | Master | | | |/ 1818 +-----------+ +---------+ | +---------+ 1819 | A | 1820 | | Zone records | 1821 | | grouped by label | 1822 | | | 1823 | +---------+ | 1824 |Create / Delete / | /| | 1825 |and Update +---------+ | | 1826 |Local Zones | | | | 1827 | | Local | | | 1828 +-------------->| Zones | | | 1829 | |/ | 1830 +---------+ | 1831 ]]></artwork> 1832 </figure> 1833 <t> 1834 The storage key derivation and records 1835 block creation is specified in the following sections and 1836 illustrated in <xref target="figure_storage_derivations"/>. 1837 </t> 1838 <figure anchor="figure_storage_derivations" title="Storage key and records block creation overview."> 1839 <artwork name="" type="" align="left" alt=""><![CDATA[ 1840 +----------+ +-------+ +------------+ +-------------+ 1841 | Zone Key | | Label | | Record Set | | Private Key | 1842 +----------+ +-------+ +------------+ +-------------+ 1843 | | | | 1844 | | v | 1845 | | +-----------+ | 1846 | +---------->| S-Encrypt | | 1847 +----------|---------->+-----------+ | 1848 | | | | | 1849 | | | v v 1850 | | | +-------------+ 1851 | +---------------|-->| SignDerived | 1852 | | | +-------------+ 1853 | | | | 1854 | v v v 1855 | +------+ +---------------+ 1856 +----->| ZKDF |------->| Records Block | 1857 +------+ +---------------+ 1858 | 1859 v 1860 +------+ +-------------+ 1861 | Hash |------->| Storage Key | 1862 +------+ +-------------+ 1863 ]]></artwork> 1864 </figure> 1865 <section anchor="blinding" numbered="true" toc="default"> 1866 <name>The Storage Key</name> 1867 <t> 1868 The storage key is derived from the zone key and the respective 1869 label of the contained records. 1870 The required knowledge of both zone key and label in combination 1871 with the similarly derived symmetric secret keys and blinded zone keys 1872 ensures query privacy (see <xref target="RFC8324"/>, Section 3.5). 1873 </t> 1874 <t> 1875 Given a label, the storage key q is derived as follows: 1876 </t> 1877 <artwork name="" type="" align="left" alt=""><![CDATA[ 1878 q := SHA-512 (ZKDF(zk, label)) 1879 ]]></artwork> 1880 <dl> 1881 <dt>label</dt> 1882 <dd>is a UTF-8 string under which the resource records are published. 1883 </dd> 1884 <dt>zk</dt> 1885 <dd> 1886 is the zone key. 1887 </dd> 1888 <dt>q</dt> 1889 <dd> 1890 Is the 512-bit storage key under which the resource records block is 1891 published. 1892 It is the SHA-512 hash <xref target="RFC6234"/> over the derived zone key. 1893 </dd> 1894 </dl> 1895 </section> 1896 <section anchor="rdata" numbered="true" toc="default"> 1897 <name>Plaintext Record Data (RDATA)</name> 1898 <t> 1899 GNS records from a zone are grouped by their labels such that all 1900 records under the same label published together as a single 1901 block in the storage. Such grouped record sets <bcp14>MAY</bcp14> be paired with 1902 supplemental records. 1903 </t> 1904 <t> 1905 Record data (RDATA) is the format used to encode such a group of GNS records. 1906 The binary format of RDATA is illustrated in 1907 <xref target="figure_rdata"/>. 1908 </t> 1909 <figure anchor="figure_rdata" title="The RDATA Wire Format."> 1910 <artwork name="" type="" align="left" alt=""><![CDATA[ 1911 0 8 16 24 32 40 48 56 1912 +-----+-----+-----+-----+-----+-----+-----+-----+ 1913 | EXPIRATION | 1914 +-----+-----+-----+-----+-----+-----+-----+-----+ 1915 | SIZE | FLAGS | TYPE | 1916 +-----+-----+-----+-----+-----+-----+-----+-----+ 1917 | DATA / 1918 / / 1919 / / 1920 +-----+-----+-----+-----+-----+-----+-----+-----+ 1921 | EXPIRATION | 1922 +-----+-----+-----+-----+-----+-----+-----+-----+ 1923 | SIZE | FLAGS | TYPE | 1924 +-----+-----+-----+-----+-----+-----+-----+-----+ 1925 | DATA / 1926 / / 1927 +-----+-----+-----+-----+-----+-----+-----+-----+ 1928 / PADDING / 1929 / / 1930 +-----+-----+-----+-----+-----+-----+-----+-----+ 1931 ]]></artwork> 1932 </figure> 1933 <dl> 1934 <dt>EXPIRATION, SIZE, TYPE, FLAGS and DATA</dt> 1935 <dd> 1936 These fields were defined 1937 in the resource record format in <xref target="rrecords" />. 1938 </dd> 1939 <dt>PADDING</dt> 1940 <dd> 1941 When serializing records into RDATA, a GNS implementation <bcp14>MUST</bcp14> ensure that 1942 the size of the RDATA is a power of two 1943 using the padding field. The field <bcp14>MUST</bcp14> be set to zero and <bcp14>MUST</bcp14> be 1944 ignored on receipt. 1945 As a special exception, record sets with (only) a zone delegation 1946 record type are never padded. 1947 </dd> 1948 </dl> 1949 </section> 1950 <section anchor="records_block" numbered="true" toc="default"> 1951 <name>The Resource Records Block</name> 1952 <t> 1953 The resource records grouped in an RDATA are encrypted using the S-Encrypt() 1954 function defined by the zone type of the zone to which the resource records belong 1955 and prefixed with meta data into a resource record block (RRBLOCK) for remote storage. 1956 The GNS RRBLOCK wire format is illustrated in 1957 <xref target="figure_record_block"/>. 1958 </t> 1959 <figure anchor="figure_record_block" title="The RRBLOCK Wire Format."> 1960 <artwork name="" type="" align="left" alt=""><![CDATA[ 1961 0 8 16 24 32 40 48 56 1962 +-----+-----+-----+-----+-----+-----+-----+-----+ 1963 | SIZE | ZONE TYPE | 1964 +-----+-----+-----+-----+-----+-----+-----+-----+ 1965 / ZONE KEY / 1966 / (BLINDED) / 1967 | | 1968 +-----+-----+-----+-----+-----+-----+-----+-----+ 1969 | SIGNATURE | 1970 / / 1971 / / 1972 | | 1973 +-----+-----+-----+-----+-----+-----+-----+-----+ 1974 | EXPIRATION | 1975 +-----+-----+-----+-----+-----+-----+-----+-----+ 1976 | BDATA / 1977 / / 1978 / | 1979 +-----+-----+-----+-----+-----+-----+-----+-----+ 1980 ]]></artwork> 1981 </figure> 1982 <dl> 1983 <dt>SIZE</dt> 1984 <dd> 1985 A 32-bit value containing the length of the block in bytes in network byte order. 1986 Despite the message format's use of a 32-bit value, 1987 implementations <bcp14>MAY</bcp14> refuse to publish blocks beyond a certain 1988 size significantly below the theoretical block size limit of 4 GB. 1989 </dd> 1990 <dt>ZONE TYPE</dt> 1991 <dd> 1992 is the 32-bit ztype in network byte order. 1993 </dd> 1994 <dt>ZONE KEY (BLINDED)</dt> 1995 <dd> 1996 is the blinded zone key "ZKDF(zk, label)" 1997 to be used to verify SIGNATURE. 1998 The length and format of the blinded public key depends on the ztype. 1999 </dd> 2000 <dt>SIGNATURE</dt> 2001 <dd> 2002 The signature is computed over the EXPIRATION and BDATA fields 2003 as detailed in <xref target="figure_rrsigwithpseudo"/>. 2004 The length and format of the signature depends on the ztype. 2005 The signature is created using the SignDerived() function of 2006 the cryptosystem of the zone (see <xref target="zones" />). 2007 </dd> 2008 <dt>EXPIRATION</dt> 2009 <dd> 2010 Specifies when the RRBLOCK expires and the encrypted block 2011 <bcp14>SHOULD</bcp14> be removed from the storage and caches as it is likely stale. 2012 However, applications <bcp14>MAY</bcp14> continue to use non-expired individual 2013 records until they expire. The value <bcp14>MUST</bcp14> be set to the maximum of 2014 the expiration time of the resource record contained within this block with the 2015 smallest expiration time and the previous EXPIRATION value (if any) plus one 2016 to ensure strict monotonicity (see <xref target="security_cryptography" />). 2017 If the RDATA includes shadow records, then the maximum 2018 expiration time of all shadow records with matching type and the 2019 expiration times of the non-shadow records is considered. 2020 This is a 64-bit absolute date in microseconds since midnight 2021 (0 hour), January 1, 1970 UTC in network byte order. 2022 </dd> 2023 <dt>BDATA</dt> 2024 <dd> 2025 The encrypted RDATA computed using S-Encrypt() with the 2026 zone key, label and expiration time as additional inputs. 2027 Its ultimate size and content are determined by 2028 the S-Encrypt() function of the ztype. 2029 </dd> 2030 </dl> 2031 <t> 2032 The signature over the public key covers a 32-bit pseudo header 2033 conceptually prefixed to the EXPIRATION and the BDATA fields. 2034 The wire format is illustrated 2035 in <xref target="figure_rrsigwithpseudo"/>. 2036 </t> 2037 <figure anchor="figure_rrsigwithpseudo" title="The Wire Format used for creating the signature of the RRBLOCK."> 2038 <artwork name="" type="" align="left" alt=""><![CDATA[ 2039 0 8 16 24 32 40 48 56 2040 +-----+-----+-----+-----+-----+-----+-----+-----+ 2041 | SIZE | PURPOSE (0x0F) | 2042 +-----+-----+-----+-----+-----+-----+-----+-----+ 2043 | EXPIRATION | 2044 +-----+-----+-----+-----+-----+-----+-----+-----+ 2045 | BDATA | 2046 / / 2047 / / 2048 +-----+-----+-----+-----+-----+-----+-----+-----+ 2049 ]]></artwork> 2050 </figure> 2051 <dl> 2052 <dt>SIZE</dt> 2053 <dd> 2054 A 32-bit value containing the length of the signed data in bytes 2055 in network byte order. 2056 </dd> 2057 <dt>PURPOSE</dt> 2058 <dd> 2059 A 32-bit signature purpose flag in network byte order. The value of this 2060 field <bcp14>MUST</bcp14> be 15. It defines the context in which 2061 the signature is created so that it cannot be reused in other parts 2062 of the protocol including possible future extensions. 2063 The value of this field corresponds to an entry in the 2064 GANA "GNUnet Signature Purpose" registry <xref target="GANA"/>. 2065 </dd> 2066 <dt>EXPIRATION</dt> 2067 <dd> 2068 Field as defined in the RRBLOCK message above. 2069 </dd> 2070 <dt>BDATA</dt> 2071 <dd>Field as defined in the RRBLOCK message above.</dd> 2072 </dl> 2073 </section> 2074 </section> 2075 <section anchor="resolution" numbered="true" toc="default"> 2076 <name>Name Resolution</name> 2077 <t> 2078 Names in GNS are resolved by recursively querying the record storage. 2079 Recursive in this context means that a resolver does not provide 2080 intermediate results for a query to the application. 2081 Instead, it <bcp14>MUST</bcp14> respond to a resolution request with either the 2082 requested resource record or an error message in case resolution 2083 fails. 2084 <xref target="figure_resolution"/> illustrates how an application 2085 requests the lookup of a GNS name (1). 2086 The application <bcp14>MAY</bcp14> provide a desired record type to the resolver. 2087 Subsequently, a Start Zone is determined (2) and the recursive 2088 resolution process started. 2089 This is where the desired record type is used to guide processing. 2090 For example, if a zone delegation record type is requested, the 2091 resolution of the apex label in that zone must be skipped, as 2092 the desired record is already found. 2093 Details on how the resolution process is initiated and each iterative 2094 result (3a,3b) in the resolution is processed are provided in the sections below. 2095 The results of the lookup are eventually returned to the application (4). 2096 The implementation <bcp14>MUST NOT</bcp14> filter the returned resource 2097 record sets according to the desired record type. 2098 Filtering of record sets is typically done by the application. 2099 </t> 2100 <figure anchor="figure_resolution" title="The recursive GNS resolution process."> 2101 <artwork name="" type="" align="left" alt=""><![CDATA[ 2102 Local Host | Remote 2103 | Storage 2104 | 2105 | +---------+ 2106 | / /| 2107 | +---------+ | 2108 +-----------+ (1) Name +----------+ | | | | 2109 | | Lookup | | (3a) GET(q) | | Record | | 2110 |Application|----------| Resolver |---------------|->| Storage | | 2111 | |<---------| |<--------------|--| |/ 2112 +-----------+ (4) +----------+ (3b) RRBLOCK | +---------+ 2113 Records A | 2114 | | 2115 (2) Determination of | | 2116 Start Zone | | 2117 | | 2118 +---------+ | 2119 / | /| | 2120 +---------+ | | 2121 | | | | 2122 | Start | | | 2123 | Zones | | | 2124 | |/ | 2125 +---------+ | 2126 ]]></artwork> 2127 </figure> 2128 <section anchor="governance" numbered="true" toc="default"> 2129 <name>Start Zones</name> 2130 <t> 2131 The resolution of a GNS name starts by identifying the start zone 2132 suffix. Once the start zone suffix is identified, recursive resolution 2133 of the remainder of the name is initiated (see <xref target="recursion"/>). 2134 There are two types of start zone suffixes: zTLDs and local 2135 suffix-to-zone mappings. 2136 The choice of available suffix-to-zone mappings is at the sole 2137 discretion of the local system administrator or user. 2138 This property addresses the issue of a single hierarchy with a 2139 centrally controlled root and the related issue of distribution and 2140 management of root servers in DNS (see <xref target="RFC8324"/>, Sections 3.10 and 3.12). 2141 </t> 2142 <t> 2143 For names ending with a zTLD the start zone is explicitly given in the 2144 suffix of the name to resolve. 2145 In order to ensure uniqueness of names with zTLDs any 2146 implementation <bcp14>MUST</bcp14> use the given zone as start zone. 2147 An implementation <bcp14>MUST</bcp14> first try to interpret the rightmost label of 2148 the given name as the beginning of a zTLD (see <xref target="zTLD"/>). 2149 If the rightmost label cannot be (partially) decoded or if it does not 2150 indicate a supported ztype, the name is treated as a normal name and 2151 start zone discovery <bcp14>MUST</bcp14> continue with finding a local suffix-to-zone 2152 mapping. 2153 If a valid ztype can be found in the rightmost label, the 2154 implementation <bcp14>MUST</bcp14> try to synthesize and decode the zTLD to retrieve 2155 the start zone key according to <xref target="zTLD"/>. 2156 If the zTLD cannot be synthesized or decoded, the resolution of 2157 the name fails and an error is returned to the application. 2158 Otherwise, the zone key <bcp14>MUST</bcp14> be used as the start zone: 2159 </t> 2160 <artwork name="" type="" align="left" alt=""><![CDATA[ 2161 Example name: www.example.<zTLD> 2162 => Start zone: zk of type ztype 2163 => Name to resolve from start zone: www.example 2164 ]]></artwork> 2165 <t> 2166 For names not ending with a zTLD the resolver <bcp14>MUST</bcp14> determine the start 2167 zone through a local suffix-to-zone mapping. 2168 Suffix-to-zone mappings <bcp14>MUST</bcp14> be configurable through a local 2169 configuration file or database by the user or system administrator. 2170 A suffix <bcp14>MAY</bcp14> consist of multiple GNS labels concatenated with a 2171 label separator. 2172 If multiple suffixes match the name to resolve, the longest 2173 matching suffix <bcp14>MUST</bcp14> be used. The suffix length of two results 2174 <bcp14>MUST NOT</bcp14> be equal. This indicates a misconfiguration and the 2175 implementation <bcp14>MUST</bcp14> return an error. 2176 The following is a non-normative example mapping of start zones: 2177 </t> 2178 <artwork name="" type="" align="left" alt=""><![CDATA[ 2179 Example name: www.example.xyz.gns.alt 2180 Local suffix mappings: 2181 xyz.gns.alt = zTLD0 := Base32GNS(ztype0||zk0) 2182 example.xyz.gns.alt = zTLD1 := Base32GNS(ztype1||zk1) 2183 example.com.gns.alt = zTLD2 := Base32GNS(ztype2||zk2) 2184 ... 2185 => Start zone: zk1 2186 => Name to resolve from start zone: www 2187 ]]></artwork> 2188 <t> 2189 The process given above <bcp14>MAY</bcp14> be supplemented with other mechanisms if 2190 the particular application requires a different process. 2191 If no start zone can be discovered, resolution <bcp14>MUST</bcp14> fail and an 2192 error <bcp14>MUST</bcp14> be returned to the application. 2193 </t> 2194 </section> 2195 <section anchor="recursion" numbered="true" toc="default"> 2196 <name>Recursion</name> 2197 <t> 2198 In each step of the recursive name resolution, there is an 2199 authoritative zone zk and a name to resolve. 2200 The name <bcp14>MAY</bcp14> be empty. 2201 If the name is empty, it is interpreted as the apex label "@". 2202 Initially, the authoritative zone is the start zone. 2203 </t> 2204 <t> 2205 From here, the following steps are recursively executed, in order: 2206 </t> 2207 <ol> 2208 <li>Extract the right-most label from the name to look up.</li> 2209 <li>Calculate q using the label and zk as defined in 2210 <xref target="blinding" />.</li> 2211 <li>Perform a storage query GET(q) to retrieve the RRBLOCK.</li> 2212 <li>Check that (a) the block is not expired, (b) the SHA-512 hash 2213 of the derived authoritative zone key zk' from the RRBLOCK matches 2214 the query q, and (c) the signature is valid. If any of these 2215 tests fail, the RRBLOCK <bcp14>MUST</bcp14> 2216 be ignored and, if applicable, the storage lookup GET(q) 2217 <bcp14>MUST</bcp14> continue to look for other RRBLOCKs.</li> 2218 <li>Obtain the RDATA by decrypting the BDATA contained in the 2219 RRBLOCK using S-Decrypt() as defined by the zone type, effectively 2220 inverting the process described in <xref target="records_block" />.</li> 2221 </ol> 2222 <t> 2223 Once a well-formed block has been decrypted, the records from 2224 RDATA are subjected to record processing. 2225 </t> 2226 </section> 2227 <section anchor="record_processing" numbered="true" toc="default"> 2228 <name>Record Processing</name> 2229 <t> 2230 In record processing, only the valid records obtained are considered. 2231 To filter records by validity, the resolver 2232 <bcp14>MUST</bcp14> at least check the expiration time and the FLAGS field of the 2233 respective record. 2234 Specifically, the resolver <bcp14>MUST</bcp14> disregard expired records. 2235 Furthermore, SHADOW and 2236 SUPPLEMENTAL flags can also exclude records from being considered. 2237 If the resolver encounters a record with the CRITICAL flag set and 2238 does not support the record type the resolution <bcp14>MUST</bcp14> be aborted 2239 and an error <bcp14>MUST</bcp14> be returned. The information that the critical 2240 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error 2241 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2242 merely complicating troubleshooting for the user. 2243 </t> 2244 <t> 2245 The next steps depend on the context of the name that is being 2246 resolved: 2247 </t> 2248 <ul> 2249 <li> 2250 Case 1: 2251 If the filtered record set consists of a single REDIRECT record, 2252 the remainder of the name is prepended to the REDIRECT data and the 2253 recursion is started again from the resulting name. 2254 Details are described in <xref target="redirect_processing" />. 2255 </li> 2256 <li> 2257 Case 2: 2258 If the filtered record set consists exclusively of one or more GNS2DNS records 2259 resolution continues with DNS. 2260 Details are described in <xref target="gns2dns_processing" />. 2261 </li> 2262 <li> 2263 Case 3: 2264 If the remainder of the name to be resolved is of the format 2265 "_SERVICE._PROTO" and the record set contains one or more matching BOX 2266 records, the records in the BOX records are the final result and the recursion 2267 is concluded as described in <xref target="box_processing" />. 2268 </li> 2269 <li> 2270 Case 4: 2271 If the current record set 2272 consist of a single delegation record, 2273 resolution of the remainder of the name is delegated to 2274 the target zone as described in <xref target="delegation_processing" />. 2275 </li> 2276 <li> 2277 Case 5: 2278 If the remainder of the name to resolve is empty 2279 the record set is the final result. 2280 If any NICK records are in the final result set, they <bcp14>MUST</bcp14> 2281 first be processed according to <xref target="nick_processing" />. 2282 Otherwise, the record result set is directly returned as the final result. 2283 </li> 2284 <li> 2285 Finally, if none of the above is applicable, resolution fails and the 2286 resolver <bcp14>MUST</bcp14> return an empty record set. 2287 </li> 2288 </ul> 2289 <section anchor="redirect_processing" numbered="true" toc="default"> 2290 <name>REDIRECT</name> 2291 <t> 2292 If the remaining name is empty and the desired record type is 2293 REDIRECT, in which case the resolution concludes with the REDIRECT record. 2294 If the rightmost label of the redirect name is the extension label 2295 (U+002B, "+"), 2296 resolution continues in GNS with the new name in the 2297 current zone. 2298 Otherwise, the resulting name is resolved via the 2299 default operating system name resolution process. 2300 This can in turn trigger a GNS name resolution process depending 2301 on the system configuration. 2302 In case resolution continues in DNS, the name <bcp14>MUST</bcp14> first be 2303 converted to an IDNA compliant representation <xref target="RFC5890" />. 2304 </t> 2305 <t> 2306 In order to prevent infinite loops, the resolver <bcp14>MUST</bcp14> 2307 implement loop detection or limit the number of recursive 2308 resolution steps. 2309 The loop detection <bcp14>MUST</bcp14> be effective even 2310 if a REDIRECT found in GNS triggers subsequent GNS lookups via 2311 the default operating system name resolution process. 2312 </t> 2313 </section> 2314 <section anchor="gns2dns_processing" numbered="true" toc="default"> 2315 <name>GNS2DNS</name> 2316 <t> 2317 When a resolver encounters one or more GNS2DNS records and the remaining name 2318 is empty and the desired record type is GNS2DNS, the GNS2DNS 2319 records are returned. 2320 </t> 2321 <t> 2322 Otherwise, it is expected that the resolver first resolves the 2323 IP addresses of the specified DNS name servers. 2324 The DNS name <bcp14>MUST</bcp14> be converted to an IDNA compliant 2325 representation <xref target="RFC5890" /> for resolution in DNS. 2326 GNS2DNS records <bcp14>MAY</bcp14> 2327 contain numeric IPv4 or IPv6 addresses, allowing the resolver to 2328 skip this step. 2329 The DNS server names might themselves be names in GNS or DNS. 2330 If the rightmost label of the DNS server name is the extension label 2331 (U+002B, "+"), the rest of the name is to be 2332 interpreted relative to the zone of the GNS2DNS record. 2333 If the DNS server name ends in a label representation of a 2334 zone key, the DNS server name is to be resolved against 2335 the GNS zone zk. 2336 </t> 2337 <t> 2338 Multiple GNS2DNS records can be stored under the same label, 2339 in which case the resolver <bcp14>MUST</bcp14> try all of them. 2340 The resolver <bcp14>MAY</bcp14> try them in any order or even in parallel. 2341 If multiple GNS2DNS records are present, the DNS name <bcp14>MUST</bcp14> be 2342 identical for all of them. Otherwise, it is not clear which name 2343 the resolver is supposed to follow. If different DNS names are 2344 present the resolution fails and an 2345 appropriate error is <bcp14>SHOULD</bcp14> be returned to the application. 2346 </t> 2347 <t> 2348 If there are DNSSEC DS records or any other records used to 2349 secure the connection with the DNS servers stored under the label, 2350 the DNS resolver <bcp14>SHOULD</bcp14> use them to secure the connection with 2351 the DNS server. 2352 </t> 2353 <t> 2354 Once the IP addresses of the DNS servers have been determined, 2355 the DNS name from the GNS2DNS record is appended 2356 to the remainder of the name to be resolved, and 2357 resolved by querying the DNS name server(s). 2358 The synthesized name has to be converted to an IDNA compliant 2359 representation <xref target="RFC5890" /> for resolution in DNS. 2360 If such a conversion is not possible, the resolution <bcp14>MUST</bcp14> be aborted 2361 and an error <bcp14>MUST</bcp14> be returned. The information that the critical 2362 record could not be processed <bcp14>SHOULD</bcp14> be returned in the error 2363 description. The implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2364 merely complicating troubleshooting for the user. 2365 </t> 2366 <t> 2367 As the DNS servers 2368 specified are possibly authoritative DNS servers, the GNS resolver <bcp14>MUST</bcp14> 2369 support recursive DNS resolution and <bcp14>MUST NOT</bcp14> delegate this to the 2370 authoritative DNS servers. 2371 The first successful recursive name resolution result 2372 is returned to the application. 2373 In addition, the resolver <bcp14>SHOULD</bcp14> return the queried DNS name as a 2374 supplemental LEHO record (see <xref target="gnsrecords_leho" />) with a 2375 relative expiration time of one hour. 2376 </t> 2377 <t> 2378 Once the transition from GNS into DNS is made through a 2379 GNS2DNS record, there is no "going back". 2380 The (possibly recursive) resolution of the DNS name <bcp14>MUST NOT</bcp14> 2381 delegate back into GNS and should only follow the DNS specifications. 2382 For example, names contained in DNS CNAME records <bcp14>MUST NOT</bcp14> be 2383 interpreted by resolvers that support both DNS and GNS as GNS names. 2384 </t> 2385 <t> 2386 GNS resolvers <bcp14>SHOULD</bcp14> offer a configuration 2387 option to disable DNS processing to avoid information leakage 2388 and provide a consistent security profile for all name resolutions. 2389 Such resolvers would return an empty record set upon encountering 2390 a GNS2DNS record during the recursion. However, if GNS2DNS records 2391 are encountered in the record set for the apex label and a GNS2DNS record 2392 is explicitly requested by the application, such records <bcp14>MUST</bcp14> 2393 still be returned, even if DNS support is disabled by the 2394 GNS resolver configuration. 2395 </t> 2396 </section> 2397 <section anchor="box_processing" numbered="true" toc="default"> 2398 <name>BOX</name> 2399 <t> 2400 When a BOX record is received, a GNS resolver must unbox it if the 2401 name to be resolved continues with "_SERVICE._PROTO". 2402 Otherwise, the BOX record is to be left untouched. This way, TLSA 2403 (and SRV) records do not require a separate network request, and 2404 TLSA records become inseparable from the corresponding address 2405 records. 2406 </t> 2407 </section> 2408 <section anchor="delegation_processing" numbered="true" toc="default"> 2409 <name>Zone Delegation Records</name> 2410 <t> 2411 When the resolver encounters a record of a supported 2412 zone delegation record type (such as PKEY or EDKEY) 2413 and the remainder of the name is not empty, resolution continues 2414 recursively with the remainder of the name in the 2415 GNS zone specified in the delegation record. 2416 </t> 2417 <t> 2418 Whenever a resolver encounters a new GNS zone, it <bcp14>MUST</bcp14> 2419 check against the local revocation list (see <xref target="revocation" />) 2420 whether the respective 2421 zone key has been revoked. If the zone key was revoked, the 2422 resolution <bcp14>MUST</bcp14> fail with an empty result set. 2423 </t> 2424 <t> 2425 Implementations <bcp14>MUST NOT</bcp14> allow multiple different zone 2426 delegations under a single label (except if some are shadow records). 2427 Implementations <bcp14>MAY</bcp14> support any subset of ztypes. 2428 Implementations <bcp14>MUST NOT</bcp14> process zone delegation records 2429 stored under the apex label ("@"). If a zone delegation record is encountered under 2430 the apex label, resolution fails and an error <bcp14>MUST</bcp14> be returned. The 2431 implementation <bcp14>MAY</bcp14> choose not to return the reason for the failure, 2432 merely impacting troubleshooting information for the user. 2433 </t> 2434 <t> 2435 If the remainder of the name to resolve is empty and a record set 2436 was received containing only a single delegation record, the 2437 recursion is continued with the record value as authoritative zone 2438 and the apex label "@" as remaining name. 2439 Except in the case where the desired record type as specified by 2440 the application is equal to the ztype, in which case the delegation 2441 record is returned. 2442 </t> 2443 </section> 2444 <section anchor="nick_processing" numbered="true" toc="default"> 2445 <name>NICK</name> 2446 <t> 2447 NICK records are only relevant to the recursive resolver 2448 if the record set in question is the final result which is to 2449 be returned to the application. The encountered NICK records can either 2450 be supplemental (see <xref target="rrecords"/>) or 2451 non-supplemental. 2452 If the NICK record is supplemental, the resolver only returns the 2453 record set if one of the non-supplemental records matches the 2454 queried record type. 2455 It is possible that one record set contains both supplemental 2456 and non-supplemental NICK records. 2457 </t> 2458 <t> 2459 The differentiation between a supplemental and non-supplemental 2460 NICK record allows the application to match the record to the 2461 authoritative zone. Consider the following example: 2462 </t> 2463 <artwork name="" type="" align="left" alt=""><![CDATA[ 2464 Query: alice.example.gns.alt (type=A) 2465 Result: 2466 A: 192.0.2.1 2467 NICK: eve (non-supplemental) 2468 ]]></artwork> 2469 <t> 2470 In this example, the returned NICK record is non-supplemental. 2471 For the application, this means that the NICK belongs to the zone 2472 "alice.example.gns.alt" and is published under the apex label along with an A 2473 record. The NICK record is interpreted as: The zone defined by 2474 "alice.example.gns.alt" wants to be referred to as "eve". 2475 In contrast, consider the following: 2476 </t> 2477 <artwork name="" type="" align="left" alt=""><![CDATA[ 2478 Query: alice.example.gns.alt (type=AAAA) 2479 Result: 2480 AAAA: 2001:DB8::1 2481 NICK: john (supplemental) 2482 ]]></artwork> 2483 <t> 2484 In this case, the NICK record is marked as supplemental. This means that 2485 the NICK record belongs to the zone "example.gns.alt" and is published under the 2486 label "alice" along with an AAAA record. Here, the NICK record should be 2487 interpreted as: The zone defined by "example.gns.alt" wants to be referred to as 2488 "john". This distinction is likely useful for other records published as 2489 supplemental. 2490 </t> 2491 </section> 2492 </section> 2493 </section> 2494 <section anchor="encoding" numbered="true" toc="default"> 2495 <name>Internationalization and Character Encoding</name> 2496 <t> 2497 All names in GNS are encoded in UTF-8 <xref target="RFC3629" />. 2498 Labels <bcp14>MUST</bcp14> be canonicalized using 2499 Normalization Form C (NFC) <xref target="Unicode-UAX15"/>. 2500 This does not include any DNS names found in DNS records, such as CNAME 2501 record data, which is internationalized through the IDNA specifications 2502 <xref target="RFC5890" />. 2503 </t> 2504 </section> 2505 <section anchor="security" numbered="true" toc="default"> 2506 <name>Security and Privacy Considerations</name> 2507 <section anchor="security_availability" numbered="true" toc="default"> 2508 <name>Availability</name> 2509 <t> 2510 In order to ensure availability of records beyond their 2511 absolute expiration times, implementations <bcp14>MAY</bcp14> allow to locally 2512 define relative expiration time values of records. 2513 Records can then be published recurringly with updated 2514 absolute expiration times by the implementation. 2515 </t> 2516 <t> 2517 Implementations <bcp14>MAY</bcp14> allow users to manage private records in 2518 their zones that are not published in the storage. 2519 Private records are considered just like 2520 regular records when resolving labels in local zones, 2521 but their data is completely unavailable to non-local users. 2522 </t> 2523 </section> 2524 <section anchor="security_agility" numbered="true" toc="default"> 2525 <name>Agility</name> 2526 <t> 2527 The security of cryptographic systems depends on both the strength of 2528 the cryptographic algorithms chosen and the strength of the keys used 2529 with those algorithms. The security also depends on the engineering 2530 of the protocol used by the system to ensure that there are no 2531 non-cryptographic ways to bypass the security of the overall system. 2532 This is why developers of applications managing GNS zones <bcp14>SHOULD</bcp14> 2533 select a default ztype considered secure at the time of 2534 releasing the software. 2535 For applications targeting end users that are not expected to 2536 understand cryptography, the application developer <bcp14>MUST NOT</bcp14> leave 2537 the ztype selection of new zones to end users. 2538 </t> 2539 <t> 2540 This document concerns itself with the selection of cryptographic 2541 algorithms used in GNS. 2542 The algorithms identified in this document are not known to be 2543 broken (in the cryptographic sense) at the current time, and 2544 cryptographic research so far leads us to believe that they are 2545 likely to remain secure into the foreseeable future. However, this 2546 is not necessarily forever, and it is expected that new revisions of 2547 this document will be issued from time to time to reflect the current 2548 best practices in this area. 2549 </t> 2550 <t> 2551 In terms of crypto-agility, whenever the need for an updated cryptographic 2552 scheme arises to, for example, replace ECDSA over Ed25519 for 2553 PKEY records, it can simply be introduced 2554 through a new record type. 2555 Zone administrators can then replace 2556 the delegation record type for future records. 2557 The old record type remains 2558 and zones can iteratively migrate to the updated zone keys. 2559 To ensure that implementations correctly generate an error message 2560 when encountering a ztype that they do not support, 2561 current and future delegation records must always have the 2562 CRITICAL flag set. 2563 </t> 2564 </section> 2565 <section anchor="security_cryptography" numbered="true" toc="default"> 2566 <name>Cryptography</name> 2567 <t> 2568 The following considerations provide background on the design choices 2569 of the ztypes specified in this document. 2570 When specifying new ztypes as per <xref target="zones"/>, the same 2571 considerations apply. 2572 </t> 2573 <t> 2574 GNS PKEY zone keys use ECDSA over Ed25519. 2575 This is an unconventional choice, 2576 as ECDSA is usually used with other curves. However, standardized 2577 ECDSA curves are problematic for a range of reasons described in 2578 the Curve25519 and EdDSA papers <xref target="ed25519"/>. 2579 Using EdDSA directly is also 2580 not possible, as a hash function is used on the private key which 2581 destroys the linearity that the key blinding in GNS depends upon. 2582 We are not aware of anyone suggesting that using Ed25519 instead 2583 of another common curve of similar size would lower the security of 2584 ECDSA. GNS uses 256-bit curves because that way the encoded (public) 2585 keys fit into a single DNS label, which is good for usability. 2586 </t> 2587 <t> 2588 In order to ensure ciphertext indistinguishability, care must be 2589 taken with respect to the initialization vector in the counter 2590 block. In our design, the IV always includes the expiration time of the 2591 record block. 2592 When applications store records with relative expiration times, 2593 monotonicity is implicitly 2594 ensured because each time a block is published into the storage, its IV is 2595 unique as the expiration time is calculated dynamically and increases 2596 monotonically with the system time. Still, 2597 an implementation <bcp14>MUST</bcp14> ensure that when relative expiration times 2598 are decreased, the expiration time of the next record block <bcp14>MUST</bcp14> 2599 be after the last published block. 2600 For records where an absolute expiration time is used, the implementation 2601 <bcp14>MUST</bcp14> ensure that the expiration time is always increased when the record 2602 data changes. For example, the expiration time on the wire could be increased 2603 by a single microsecond even if the user did not request a change. 2604 In case of deletion of all resource records under a label, the 2605 implementation <bcp14>MUST</bcp14> keep track of the last absolute expiration time 2606 of the last published resource block. Implementations <bcp14>MAY</bcp14> define 2607 and use a special record type as a tombstone that preserves the last 2608 absolute expiration time, but then <bcp14>MUST</bcp14> take care to not publish a 2609 block with such a tombstone record. 2610 When new records are added under this label later, the implementation 2611 <bcp14>MUST</bcp14> ensure that the expiration times are after the last published 2612 block. 2613 Finally, in order to ensure monotonically increasing expiration times 2614 the implementation <bcp14>MUST</bcp14> keep a local record of the last time obtained 2615 from the system clock, so as to construct a monotonic clock in case 2616 the system clock jumps backwards. 2617 </t> 2618 </section> 2619 <section anchor="security_abuse" numbered="true" toc="default"> 2620 <name>Abuse Mitigation</name> 2621 <t> 2622 GNS names are UTF-8 strings. Consequently, GNS faces similar issues 2623 with respect to name spoofing as DNS does for internationalized 2624 domain names. 2625 In DNS, attackers can register similar sounding or looking 2626 names (see above) in order to execute phishing attacks. 2627 GNS zone administrators must take into account this attack vector and 2628 incorporate rules in order to mitigate it. 2629 </t> 2630 <t> 2631 Further, DNS can be used to combat illegal content on the Internet 2632 by having the respective domains seized by authorities. 2633 However, the same mechanisms can also be abused in order to impose 2634 state censorship. 2635 Avoiding that possibility is one of the motivations behind GNS. 2636 In GNS, TLDs are not enumerable. By design, the start zone of 2637 the resolver is defined locally and hence such a seizure is 2638 difficult and ineffective in GNS. 2639 <!--In particular, GNS does not support WHOIS (<xref target="RFC3912" />).--> 2640 </t> 2641 </section> 2642 <section anchor="security_keymanagement" numbered="true" toc="default"> 2643 <name>Zone Management</name> 2644 <t> 2645 In GNS, zone administrators need to manage and protect their zone 2646 keys. Once a private zone key is lost, it cannot be recovered and 2647 the zone revocation message cannot be computed anymore. 2648 Revocation messages can be pre-calculated if revocation is 2649 required in case a private zone key is lost. 2650 Zone administrators, and for GNS this includes end-users, are 2651 required to responsibly and diligently protect their cryptographic 2652 keys. 2653 GNS supports signing records in advance ("offline") in order to 2654 support processes (such as air gaps) which aim to protect private keys. 2655 <!-- It does not support separate zone signing and key-signing keys 2656 (as in <xref target="RFC6781" />) in order to provide usable security. This is not useful for any implementer --> 2657 </t> 2658 <t> 2659 Similarly, users are required to manage their local start zone configuration. 2660 In order to ensure integrity and availability or names, users must 2661 ensure that their local start zone information is not compromised or 2662 outdated. 2663 It can be expected that the processing of zone revocations and an 2664 initial start zone is provided with a GNS implementation 2665 ("drop shipping"). 2666 Shipping an initial start zone configuration effectively establishes 2667 a root zone. 2668 Extension and customization of the zone is at the full discretion of 2669 the user. 2670 </t> 2671 <t> 2672 While implementations following this specification will be 2673 interoperable, if two implementations connect to different remote storages 2674 they are mutually unreachable. 2675 This can lead to a state where a record exists in the global 2676 namespace for a particular name, but the implementation is not 2677 communicating with the remote storage that contains the respective 2678 block and is hence unable to resolve it. 2679 This situation is similar to a split-horizon DNS configuration. 2680 Which remote storages are implemented usually depends on the application 2681 it is built for. 2682 The remote storage used will most likely depend on the specific application 2683 context using GNS resolution. 2684 For example, one application is the resolution of hidden services 2685 within the Tor network, which would suggest using Tor routers for remote storage. 2686 <!-- FIXME: add non-normative reference to Tor / Tor hidden services here? --> 2687 Implementations of "aggregated" remote storages are conceivable, but 2688 are expected to be the exception. 2689 </t> 2690 </section> 2691 <section anchor="security_dht" numbered="true" toc="default"> 2692 <name>DHTs as Remote Storage</name> 2693 <t> 2694 This document does not specify the properties of the underlying 2695 remote storage which is required by any GNS implementation. 2696 It is important to note that the properties of the underlying 2697 remote storage are directly inherited by the 2698 GNS implementation. This includes both security as well as 2699 other non-functional properties such as scalability and performance. 2700 Implementers should take great care when selecting or implementing 2701 a DHT for use as remote storage in a GNS implementation. 2702 DHTs with reasonable security and performance properties exist 2703 <xref target="R5N"/>. 2704 It should also be taken into consideration that GNS implementations 2705 which build upon different DHT overlays are unlikely to be 2706 interoperable with each other. 2707 </t> 2708 </section> 2709 <section anchor="security_rev" numbered="true" toc="default"> 2710 <name>Revocations</name> 2711 <t> 2712 Zone administrators are advised to pre-generate zone revocations 2713 and to securely store the revocation information in case the zone 2714 key is lost, compromised or replaced in the future. 2715 Pre-calculated revocations can cease to be valid due to expirations 2716 or protocol changes such as epoch adjustments. 2717 Consequently, implementers and users must take precautions in order 2718 to manage revocations accordingly. 2719 </t> 2720 <t> 2721 Revocation payloads do not include a 'new' key for key replacement. 2722 Inclusion of such a key would have two major disadvantages: 2723 </t> 2724 <ol> 2725 <li> 2726 If a revocation is published after a private key was compromised, 2727 allowing key replacement would be dangerous: if an 2728 adversary took over the private key, the adversary could then 2729 broadcast a revocation with a key replacement. For the replacement, 2730 the compromised owner would have no chance to issue a 2731 revocation. Thus, allowing a revocation message to replace a private 2732 key makes dealing with key compromise situations worse. 2733 </li> 2734 <li> 2735 Sometimes, key revocations are used with the objective of changing 2736 cryptosystems. Migration to another cryptosystem by replacing keys 2737 via a revocation message would only be secure as long as both 2738 cryptosystems are still secure against forgery. Such a planned, 2739 non-emergency migration to another cryptosystem should be done by 2740 running zones for both cipher systems in parallel for a while. The 2741 migration would conclude by revoking the legacy zone key only once 2742 it is deemed no longer secure, and hopefully after most users have 2743 migrated to the replacement. 2744 </li> 2745 </ol> 2746 </section> 2747 <section anchor="privacy_labels" numbered="true" toc="default"> 2748 <name>Zone Privacy</name> 2749 <t> 2750 GNS does not support authenticated denial of existence of names 2751 within a zone. 2752 Record data is published in encrypted form using keys derived from the 2753 zone key and record label. Zone administrators should 2754 carefully consider if a label and zone key are public, or if 2755 one or both of these should be used as a shared secret to restrict access 2756 to the corresponding record data. 2757 Unlike public zone keys, low-entropy labels can be guessed by an attacker. If an attacker 2758 knows the public zone key, the use of well known or guessable 2759 labels effectively threatens the disclosure of the corresponding records. 2760 </t> 2761 <t> 2762 It should be noted that the guessing attack on labels only applies if the 2763 zone key is somehow disclosed to the adversary. GNS itself 2764 does not disclose it during a lookup or when resource records are 2765 published (as only the blinded zone keys are used on the network). 2766 However, zone keys do become public during revocation. 2767 </t> 2768 <t> 2769 It is thus <bcp14>RECOMMENDED</bcp14> to use a 2770 label with sufficient entropy to prevent guessing attacks 2771 if any data in a resource record set is sensitive. 2772 </t> 2773 </section> 2774 <section anchor="sec_governance"> 2775 <name>Zone Governance</name> 2776 <t> 2777 While DNS is distributed, in practice it 2778 relies on centralized, trusted registrars to provide globally unique 2779 names. As the awareness of the central role DNS plays on the Internet 2780 rises, various institutions are using their power (including legal means) 2781 to engage in attacks on the DNS, thus threatening the global availability 2782 and integrity of information on the Internet. 2783 While a wider discussion of this issue is out of scope for this document, 2784 analyses and investigations can be found in recent academic research 2785 works including <xref target="SecureNS"/>. 2786 </t> 2787 <t> 2788 GNS is designed to provide a secure, privacy-enhancing alternative to the 2789 DNS name resolution protocol, especially when censorship or manipulation 2790 is encountered. 2791 In particular, it directly addresses concerns in DNS with respect to 2792 query privacy. 2793 However, depending on the governance of the root zone, any deployment 2794 will likely suffer from the issues of a 2795 "Single Hierarchy with a Centrally Controlled Root" and 2796 "Distribution and Management of Root Servers" as raised in 2797 <xref target="RFC8324"/>. 2798 In DNS, those issues are a direct result from the centralized root 2799 zone governance at the Internet Corporation for Assigned Names and 2800 Numbers (ICANN) which allows it to provide globally unique names. 2801 </t> 2802 <t> 2803 In GNS, start zones give users local authority over their preferred 2804 root zone governance. 2805 It enables users to replace or enhance a trusted root zone 2806 configuration provided by a third party (e.g. the implementer or a 2807 multi-stakeholder governance body like ICANN) with secure delegation of 2808 authority using local petnames while operating under a 2809 very strong adversary model. 2810 In combination with zTLDs, this provides users of GNS with a global, 2811 secure and memorable mapping without a trusted authority. 2812 </t> 2813 <t> 2814 Any GNS implementation <bcp14>MAY</bcp14> provide a default 2815 governance model in the form of an initial start zone mapping. 2816 </t> 2817 </section> 2818 <section anchor="namespace_ambiguity"> 2819 <name>Namespace Ambiguity</name> 2820 <t> 2821 Technically, the GNS protocol can be used to resolve names in the 2822 namespace of the global DNS. 2823 However, this would require the respective governance bodies and 2824 stakeholders (e.g. IETF and ICANN) to standardize the use of GNS for this particular use 2825 case. 2826 </t> 2827 <t> 2828 However, this capability implies that GNS names may be 2829 indistinguishable from DNS names in their 2830 respective common display format <xref target="RFC8499"/> or 2831 other special-use domain names <xref target="RFC6761"/> if 2832 a local start zone configuration maps suffixes from the 2833 global DNS to GNS zones. 2834 For applications, it is then ambiguous which name system should be 2835 used in order to resolve a given name. 2836 This poses a risk when trying to resolve a name through DNS when 2837 it is actually a GNS name as discussed in <xref target="RFC8244"/>. 2838 In such a case, the GNS name is likely to be leaked as part of the DNS 2839 resolution. 2840 </t> 2841 <t> 2842 In order to prevent disclosure of queried GNS names it is 2843 <bcp14>RECOMMENDED</bcp14> that GNS-aware applications try to resolve 2844 a given name in GNS before any other method taking into account 2845 potential suffix-to-zone mappings and zTLDs. 2846 Suffix-to-zone mappings are expected to be configured by the user or 2847 local administrator and as such the resolution in GNS is 2848 in line with user expectations even if the name could also be resolved 2849 through DNS. 2850 If no suffix-to-zone mapping for the name exists and no zTLD is found, 2851 resolution <bcp14>MAY</bcp14> continue with other methods such as DNS. 2852 If a suffix-to-zone mapping for the name exists or the name ends with 2853 a zTLD, it <bcp14>MUST</bcp14> be resolved using GNS and 2854 resolution <bcp14>MUST NOT</bcp14> continue by any other means 2855 independent of the GNS resolution result. 2856 </t> 2857 <t> 2858 Mechanisms such as the Name Service Switch (NSS) of Unix-like 2859 operating systems are an example of how such a resolution process 2860 can be implemented and used. 2861 It allows system administrators to configure host name resolution 2862 precedence and is integrated with the system resolver implementation. 2863 </t> 2864 <t> 2865 For use cases where GNS names may be confused with names 2866 of other name resolution mechanisms (in particular DNS), the 2867 ".gns.alt" domain <bcp14>SHOULD</bcp14> be used. 2868 For use cases like implementing sinkholes to block 2869 malware sites or serving DNS domains via GNS to bypass censorship, 2870 GNS <bcp14>MAY</bcp14> be deliberately used in ways that interfere 2871 with resolution of another name system. 2872 </t> 2873 </section> 2874 </section> 2875 <section anchor="gana" numbered="true" toc="default"> 2876 <name>GANA Considerations</name> 2877 <t> 2878 GANA has assigned signature purposes in its 2879 "GNUnet Signature Purpose" registry as listed in 2880 <xref target="figure_purposenums"/>. 2881 </t> 2882 <figure anchor="figure_purposenums" title="Requested Changes in the GANA GNUnet Signature Purpose Registry."> 2883 <artwork name="" type="" align="left" alt=""><![CDATA[ 2884 Purpose | Name | References | Comment 2885 --------+-----------------+------------+-------------------------- 2886 3 | GNS_REVOCATION | [This.I-D] | GNS zone key revocation 2887 15 | GNS_RECORD_SIGN | [This.I-D] | GNS record set signature 2888 ]]></artwork> 2889 </figure> 2890 <section anchor="gana_gnsrr"> 2891 <name>GNS Record Types Registry</name> 2892 <t> 2893 GANA <xref target="GANA" /> 2894 manages the "GNS Record Types" registry. 2895 Each entry has the following format: 2896 </t> 2897 <ul> 2898 <li>Name: The name of the record type (case-insensitive ASCII 2899 string, restricted to alphanumeric characters). For zone delegation 2900 records, the assigned number represents the ztype value of the zone.</li> 2901 <li>Number: 32-bit, above 65535</li> 2902 <li>Comment: Optionally, a brief English text describing the purpose of 2903 the record type (in UTF-8)</li> 2904 <li>Contact: Optionally, the contact information of a person to contact for 2905 further information.</li> 2906 <li>References: Optionally, references describing the record type 2907 (such as an RFC).</li> 2908 </ul> 2909 <t> 2910 The registration policy for this registry is "First Come First 2911 Served". This policy is modeled on that described in <xref target="RFC8126"/>, 2912 and describes the actions taken by GANA: 2913 </t> 2914 <t> 2915 Adding new entries is possible after review by any authorized 2916 GANA contributor, using a 2917 first-come-first-served policy for unique name allocation. 2918 Reviewers are responsible to ensure that the chosen "Name" is 2919 appropriate for the record type. 2920 The registry will define a unique number for the entry. 2921 </t> 2922 <t> 2923 Authorized GANA contributors for review of new entries are reachable at 2924 gns-registry@gnunet.org. 2925 </t> 2926 <t> 2927 Any request <bcp14>MUST</bcp14> contain a unique name and a point of contact. 2928 The contact information <bcp14>MAY</bcp14> be added to the registry given the consent 2929 of the requester. 2930 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well 2931 as a descriptive comment as defined above. 2932 </t> 2933 <t> 2934 GANA has assigned numbers for the record types defined in this 2935 specification in the "GNU Name System Record Types" registry 2936 as listed in <xref target="figure_rrtypenums"/>. 2937 </t> 2938 <figure anchor="figure_rrtypenums" title="The GANA Resource Record Registry."> 2939 <artwork name="" type="" align="left" alt=""><![CDATA[ 2940 Number | Name | Contact | References | Comment 2941 -------+---------+---------+------------+------------------------- 2942 65536 | PKEY | (*) | [This.I-D] | GNS zone delegation (PKEY) 2943 65537 | NICK | (*) | [This.I-D] | GNS zone nickname 2944 65538 | LEHO | (*) | [This.I-D] | GNS legacy hostname 2945 65540 | GNS2DNS | (*) | [This.I-D] | Delegation to DNS 2946 65541 | BOX | (*) | [This.I-D] | Boxed records 2947 65551 | REDIRECT| (*) | [This.I-D] | Redirection record 2948 65556 | EDKEY | (*) | [This.I-D] | GNS zone delegation (EDKEY) 2949 2950 (*): gns-registry@gnunet.org 2951 ]]></artwork> 2952 </figure> 2953 </section> 2954 <section anchor="gana_alt"> 2955 <name>.alt Subdomains Registry</name> 2956 <t> 2957 GANA <xref target="GANA" /> 2958 manages the ".alt Subdomains" registry. 2959 Each entry has the following format: 2960 </t> 2961 <ul> 2962 <li>Label: The label of the subdomain (in DNS LDH format as defined in Section 2.3.1 of <xref target="RFC5890"/>).</li> 2963 <li>Comment: Optionally, a brief English text describing the purpose of 2964 the subdomain (in UTF-8)</li> 2965 <li>Contact: Optionally, the contact information of a person to contact for 2966 further information.</li> 2967 <li>References: Optionally, references describing the record type 2968 (such as an RFC).</li> 2969 </ul> 2970 <t> 2971 The registration policy for this registry is "First Come First 2972 Served". This policy is modeled on that described in <xref target="RFC8126"/>, 2973 and describes the actions taken by GANA: 2974 </t> 2975 <t> 2976 Adding new entries is possible after review by any authorized 2977 GANA contributor, using a 2978 first-come-first-served policy for unique subdomain allocation. 2979 Reviewers are responsible to ensure that the chosen "Subdomain" is 2980 appropriate for the purpose. 2981 </t> 2982 <t> 2983 Authorized GANA contributors for review of new entries are reachable at 2984 alt-registry@gnunet.org. 2985 </t> 2986 <t> 2987 Any request <bcp14>MUST</bcp14> contain a unique subdomain and a point of contact. 2988 The contact information <bcp14>MAY</bcp14> be added to the registry given the consent 2989 of the requester. 2990 The request <bcp14>MAY</bcp14> optionally also contain relevant references as well 2991 as a descriptive comment as defined above. 2992 </t> 2993 <t> 2994 GANA has assigned the subdomain defined in this 2995 specification in the ".alt subdomains" registry 2996 as listed in <xref target="figure_altsubdomains"/>. 2997 </t> 2998 <figure anchor="figure_altsubdomains" title="The GANA .alt Subdomains Registry."> 2999 <artwork name="" type="" align="left" alt=""><![CDATA[ 3000 Subdomain | Contact | References | Comment 3001 ----------+---------+------------+---------------------------- 3002 gns | (*) | [This.I-D] | The .alt subdomain for GNS 3003 3004 (*): alt-registry@gnunet.org 3005 ]]></artwork> 3006 </figure> 3007 </section> 3008 </section> 3009 <!-- gana --> 3010 <section> 3011 <name>IANA Considerations</name> 3012 <t> 3013 This document makes no requests for IANA action. 3014 This section may be removed on publication as an RFC. 3015 </t> 3016 </section> 3017 <section> 3018 <name>Implementation and Deployment Status</name> 3019 <t> 3020 There are two implementations conforming to this specification written 3021 in C and Go, respectively. The C implementation as part of GNUnet 3022 <xref target="GNUnetGNS"/> represents the original 3023 and reference implementation. The Go implementation 3024 <xref target="GoGNS"/> demonstrates how two implementations of GNS are 3025 interoperable if they are built on top of the same underlying 3026 DHT storage. 3027 </t> 3028 <t> 3029 Currently, the GNUnet peer-to-peer network <xref target="GNUnet"/> 3030 is an active deployment of GNS on top of its <xref target="R5N"/> 3031 DHT. The <xref target="GoGNS"/> implementation uses this deployment 3032 by building on top of the GNUnet DHT services available on any 3033 GNUnet peer. It shows how GNS implementations 3034 can attach to this existing deployment and participate in name 3035 resolution as well as zone publication. 3036 </t> 3037 <t> 3038 The self-sovereign identity system re:claimID <xref target="reclaim"/> 3039 is using GNS in order to selectively share identity attributes and 3040 attestations with third parties. 3041 </t> 3042 <t> 3043 The Ascension tool <xref target="Ascension"/> facilitates the migration of DNS zones to 3044 GNS zones by translating information retrieved from a DNS zone 3045 transfer into a GNS zone. 3046 </t> 3047 </section> 3048 <section> 3049 <name>Acknowledgements</name> 3050 <t> 3051 The authors thank all reviewers for their comments. In particular, 3052 we thank D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear and R. Salz for their 3053 insightful and detailed technical reviews. We thank J. Yao and J. Klensin for the 3054 internationalization reviews. We thank NLnet and NGI DISCOVERY for funding 3055 work on the GNU Name System. 3056 </t> 3057 </section> 3058 </middle> 3059 <back> 3060 <references> 3061 <name>Normative References</name> 3062 3063 &RFC1034; 3064 &RFC1035; 3065 &RFC2782; 3066 &RFC2119; 3067 &RFC3629; 3068 &RFC3686; 3069 &RFC3826; 3070 &RFC5237; 3071 &RFC5869; 3072 &RFC5890; 3073 &RFC5895; 3074 &RFC6234; 3075 &RFC6895; 3076 &RFC6979; 3077 &RFC7748; 3078 &RFC8032; 3079 &RFC8126; 3080 &RFC8174; 3081 &RFC8499; 3082 &RFC9106; 3083 3084 <reference anchor="GANA" target="https://gana.gnunet.org/"> 3085 <front> 3086 <title>GNUnet Assigned Numbers Authority (GANA)</title> 3087 <author><organization>GNUnet e.V.</organization> 3088 </author> 3089 <date month="November" year="2022" /> 3090 </front> 3091 </reference> 3092 3093 <reference anchor="MODES" target="https://doi.org/10.6028/NIST.SP.800-38A"> 3094 <front> 3095 <title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title> 3096 <author initials="M." surname="Dworkin" fullname="Morris Dworkin"> 3097 <organization>NIST</organization> 3098 </author> 3099 3100 <date year="2001" month="December"/> 3101 <abstract> 3102 <t> 3103 This recommendation defines five confidentiality modes of operation for use with an underlying symmetric key block cipher algorithm: Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), Output Feedback (OFB), and Counter (CTR). Used with an underlying block cipher algorithm that is approved in a Federal Information Processing Standard (FIPS), these modes can provide cryptographic protection for sensitive, but unclassified, computer data. 3104 </t> 3105 </abstract> 3106 </front> 3107 </reference> 3108 <!-- <reference anchor="GCM" target="https://doi.org/10.6028/NIST.SP.800-38D"> 3109 <front> 3110 <title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title> 3111 <author initials="M." surname="Dworkin" fullname="Morris Dworkin"> 3112 <organization>NIST</organization> 3113 </author> 3114 3115 <date year="2007" month="November"/> 3116 <abstract> 3117 <t> 3118 This Recommendation specifies the Galois/Counter Mode (GCM), an algorithm for authenticated encryption with associated data, and its specialization, GMAC, for generating a message authentication code (MAC) on data that is not encrypted. GCM and GMAC are modes of operation for an underlying approved symmetric key block cipher. 3119 </t> 3120 </abstract> 3121 </front> 3122 </reference>--> 3123 <!-- FIXME replace with RFC --> 3124 <reference anchor="CrockfordB32" target="https://www.crockford.com/base32.html"> 3125 <front> 3126 <title>Base32</title> 3127 <author initials="D." surname="Douglas" fullname="Douglas Crockford"> 3128 </author> 3129 3130 <date year="2019" month="March"/> 3131 </front> 3132 </reference> 3133 <reference anchor="XSalsa20" target="https://cr.yp.to/snuffle/xsalsa-20110204.pdf"> 3134 <front> 3135 <title>Extending the Salsa20 nonce</title> 3136 <author initials="D." surname="Bernstein" fullname="Daniel Bernstein"> 3137 <organization>University of Illinois at Chicago</organization> 3138 </author> 3139 <date year="2011"/> 3140 </front> 3141 </reference> 3142 <reference anchor="Unicode-UAX15" target="http://www.unicode.org/reports/tr15/tr15-31.html"> 3143 <front> 3144 <title>Unicode Standard Annex #15: Unicode Normalization Forms, Revision 31</title> 3145 <author> 3146 <organization>The Unicode Consortium</organization> 3147 </author> 3148 <date year="2009" month="September"/> 3149 </front> 3150 </reference> 3151 <reference anchor="Unicode-UTS46" target="https://www.unicode.org/reports/tr46"> 3152 <front> 3153 <title>Unicode Technical Standard #46: Unicode IDNA Compatibility Processing, Revision 27</title> 3154 <author> 3155 <organization>The Unicode Consortium</organization> 3156 </author> 3157 <date year="2021" month="August"/> 3158 </front> 3159 </reference> 3160 3161 3162 3163 3164 <!-- <reference anchor="ISO20022"> 3165 <front> 3166 <title>ISO 20022 Financial Services - Universal financial industry message scheme</title> 3167 <author> 3168 <organization>International Organization for Standardization</organization> 3169 <address> 3170 <uri>http://www.iso.ch</uri> 3171 </address> 3172 </author> 3173 <date month="May" year="2013"/> 3174 </front> 3175 </reference>--> 3176 </references> 3177 <references> 3178 <name>Informative References</name> 3179 &RFC1928; 3180 &RFC4033; 3181 &RFC6066; 3182 &RFC7363; 3183 &RFC8324; 3184 &RFC8806; 3185 &RFC6761; 3186 &RFC8244; 3187 &RFC9476; 3188 3189 <reference anchor="Tor224" target="https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n2135"> 3190 <front> 3191 <title>Next-Generation Hidden Services in Tor</title> 3192 <author initials="D." surname="Goulet" fullname="David Goulet"> 3193 </author> 3194 <author initials="G." surname="Kadianakis" fullname="George Kadianakis"> 3195 </author> 3196 <author initials="N." surname="Mathewson" fullname="Nick Mathewson"> 3197 </author> 3198 3199 <date year="2013" month="November"/> 3200 </front> 3201 </reference> 3202 <reference anchor="SDSI" target="http://people.csail.mit.edu/rivest/Sdsi10.ps"> 3203 <front> 3204 <title>SDSI - A Simple Distributed Security Infrastructure</title> 3205 <author initials="R." surname="Rivest" fullname="Ron Rivest"> 3206 </author> 3207 <author initials="B." surname="Lampson" fullname="Butler Lampson"> 3208 </author> 3209 <date year="1996" month="April"/> 3210 </front> 3211 </reference> 3212 <reference anchor="Kademlia" target="http://css.csail.mit.edu/6.824/2014/papers/kademlia.pdf"> 3213 <front> 3214 <title>Kademlia: A peer-to-peer information system based on the xor metric.</title> 3215 <author initials="P." surname="Maymounkov" fullname="Petar Maymounkov"> 3216 </author> 3217 3218 <author initials="D." surname="Mazieres" 3219 fullname="David Mazieres"> 3220 </author> 3221 <date year="2002"/> 3222 </front> 3223 </reference> 3224 <!--<reference anchor="Ipfs" target="https://arxiv.org/pdf/1407.3561"> 3225 <front> 3226 <title>Ipfs-content addressed, versioned, p2p file system.</title> 3227 <author initials="J." surname="Benet" fullname="Juan Benet"> 3228 </author> 3229 <date year="2014"/> 3230 </front> 3231 </reference> 3232 --> 3233 3234 <reference anchor="ed25519" target="https://ed25519.cr.yp.to/ed25519-20110926.pdf"> 3235 <front> 3236 <title>High-Speed High-Security Signatures</title> 3237 <author initials="D." surname="Bernstein" fullname="Daniel Bernstein"> 3238 <organization>University of Illinois at Chicago</organization> 3239 </author> 3240 3241 <author initials="N." surname="Duif" 3242 fullname="Niels Duif"> 3243 <organization>Technische Universiteit Eindhoven</organization> 3244 3245 </author> 3246 <author initials="T." surname="Lange" 3247 fullname="Tanja Lange"> 3248 <organization>Technische Universiteit Eindhoven</organization> 3249 3250 </author> 3251 <author initials="P." surname="Schwabe" 3252 fullname="Peter Schwabe"> 3253 <organization>National Taiwan University</organization> 3254 3255 </author> 3256 <author initials="B." surname="Yang" 3257 fullname="Bo-Yin Yang"> 3258 <organization>Academia Sinica</organization> 3259 3260 </author> 3261 <date year="2011"/> 3262 </front> 3263 </reference> 3264 <reference anchor="GNS" target="https://sci-hub.st/10.1007/978-3-319-12280-9_9"> 3265 <front> 3266 <title>A Censorship-Resistant, Privacy-Enhancing and Fully Decentralized Name System</title> 3267 <author initials="M." surname="Wachs" fullname="Matthias Wachs"> 3268 <organization>Technische Universität München</organization> 3269 </author> 3270 3271 <author initials="M." surname="Schanzenbach" fullname="Martin Schanzenbach"> 3272 <organization>Technische Universität München</organization> 3273 </author> 3274 3275 <author initials="C." surname="Grothoff" 3276 fullname="Christian Grothoff"> 3277 <organization>Technische Universität München</organization> 3278 </author> 3279 <date year="2014"/> 3280 </front> 3281 </reference> 3282 <reference anchor="R5N" target="https://sci-hub.st/10.1109/ICNSS.2011.6060022"> 3283 <front> 3284 <title>R5N: Randomized recursive routing for restricted-route networks</title> 3285 <author initials="N. S." surname="Evans" fullname="Nathan S. Evans"> 3286 <organization>Technische Universität München</organization> 3287 </author> 3288 3289 <author initials="C." surname="Grothoff" 3290 fullname="Christian Grothoff"> 3291 <organization>Technische Universität München</organization> 3292 </author> 3293 <date year="2011"/> 3294 </front> 3295 </reference> 3296 <reference anchor="SecureNS" target="https://sci-hub.st/https://doi.org/10.1016/j.cose.2018.01.018"> 3297 <front> 3298 <title>Towards secure name resolution on the Internet</title> 3299 <author initials="C." surname="Grothoff" 3300 fullname="Christian Grothoff"> 3301 <organization>Bern University of Applied Sciences</organization> 3302 </author> 3303 <author initials="M." surname="Wachs" 3304 fullname="Matthias Wachs"> 3305 <organization>Technische Universität München</organization> 3306 </author> 3307 <author initials="M." surname="Ermert" 3308 fullname="Monika Ermert"> 3309 </author> 3310 3311 <author initials="J." surname="Appelbaum" 3312 fullname="Jacob Appelbaum"> 3313 <organization>TU Eindhoven</organization> 3314 </author> 3315 <date year="2018"/> 3316 </front> 3317 </reference> 3318 3319 <reference anchor="GNUnetGNS" target="https://git.gnunet.org/gnunet.git/tree/src/gns"> 3320 <front> 3321 <title>The GNUnet GNS Implementation</title> 3322 <author> 3323 <organization>GNUnet e.V.</organization> 3324 </author> 3325 </front> 3326 </reference> 3327 <reference anchor="Ascension" target="https://git.gnunet.org/ascension.git"> 3328 <front> 3329 <title>The Ascension Implementation</title> 3330 <author> 3331 <organization>GNUnet e.V.</organization> 3332 </author> 3333 </front> 3334 </reference> 3335 3336 <reference anchor="GNUnet" target="https://gnunet.org"> 3337 <front> 3338 <title>The GNUnet Project</title> 3339 <author> 3340 <organization>GNUnet e.V.</organization> 3341 </author> 3342 </front> 3343 </reference> 3344 <reference anchor="reclaim" target="https://reclaim.gnunet.org"> 3345 <front> 3346 <title>re:claimID</title> 3347 <author> 3348 <organization>GNUnet e.V.</organization> 3349 </author> 3350 </front> 3351 </reference> 3352 3353 <reference anchor="GoGNS" target="https://github.com/bfix/gnunet-go/tree/master/src/gnunet/service/gns"> 3354 <front> 3355 <title>The Go GNS Implementation</title> 3356 <author initials="B." surname="Fix" fullname="Bernd Fix"> 3357 </author> 3358 </front> 3359 </reference> 3360 3361 <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html"> 3362 <front> 3363 <title>System Databases and Name Service Switch</title> 3364 <author> 3365 <organization>GNU Project</organization> 3366 </author> 3367 </front> 3368 </reference> 3369 3370 </references> 3371 <section> 3372 <name>Usage and Migration</name> 3373 <t> 3374 This section outlines a number of specific use cases which may 3375 help readers of the technical specification to understand the protocol 3376 better. 3377 The considerations below are not meant to be normative for the 3378 GNS protocol in any way. 3379 Instead, they are provided in order to give context and to provide 3380 some background on what the intended use of the protocol is 3381 by its designers. 3382 Further, this section contains pointers to migration paths. 3383 </t> 3384 <section anchor="day_in_zoneowner"> 3385 <name>Zone Dissemination</name> 3386 <t> 3387 In order to become a zone owner, it is sufficient to generate 3388 a zone key and a corresponding secret key using a GNS implementation. 3389 At this point, the zone owner can manage GNS resource records in a 3390 local zone database. 3391 The resource records can then be published by a GNS implementation 3392 as defined in <xref target="publish"/>. 3393 For other users to resolve the resource records, respective 3394 zone information must be disseminated first. 3395 The zone owner may decide to make the zone key and labels known 3396 to a selected set of users only or to make this information available 3397 to the general public. 3398 </t> 3399 <t> 3400 Sharing zone information directly with specific users not only allows 3401 to potentially preserve zone and record privacy, but also allows 3402 the zone owner and the user to establish strong trust relationships. 3403 For example, a bank may send a customer letter with a QR code which 3404 contains the GNS zone of the bank. 3405 This allows the user to scan the QR code and establish a strong 3406 link to the zone of the bank and with it, for example, the IP address 3407 of the online banking web site. 3408 </t> 3409 <t> 3410 Most Internet services likely want to make their zones available 3411 to the general public as efficiently as possible. 3412 First, it is reasonable to assume that zones which are commanding 3413 high levels of reputation and trust are likely included in the 3414 default suffix-to-zone mappings of implementations. 3415 Hence dissemination of a zone through delegation under such zones 3416 can be a viable path in order to disseminate a zone publicly. 3417 For example, it is conceivable that organizations such as ICANN 3418 or country-code top-level domain registrars also manage GNS zones 3419 and offer registration or delegation services. 3420 </t> 3421 <t> 3422 Following best practices in particularly those relating to 3423 security and abuse mitigation are methods which allow zone owners 3424 and aspiring registrars to gain a good reputation and eventually 3425 trust. 3426 This includes, of course, diligent protection of private zone key 3427 material. 3428 Formalizing such best practices is out of scope of this 3429 specification and should be addressed in a separate document and take 3430 <xref target="security"/> into account. 3431 </t> 3432 </section> 3433 <section> 3434 <name>Start Zone Configuration</name> 3435 <t> 3436 A user is expected to install a GNS implementation if it is not already 3437 provided through other means such as the operating system 3438 or the browser. 3439 It is likely that the implementation ships with a 3440 default start zone configuration. 3441 This means that the user is able to resolve GNS names ending on a 3442 zTLD or ending on any suffix-to-name mapping that is part of the 3443 default start zone configuration. 3444 At this point the user may delete or otherwise modify the 3445 implementation's default configuration: 3446 </t> 3447 <t> 3448 Deletion of suffix-to-zone mappings may become necessary of the 3449 zone owner referenced by the mapping has lost the trust of the user. 3450 For example, this could be due to lax registration policies resulting 3451 in phishing activities. 3452 Modification and addition of new mappings are means to heal the 3453 namespace perforation which would occur in the case of a deletion 3454 or to simply establish a strong direct trust relationship. 3455 However, this requires the user's knowledge of the respective zone 3456 keys. 3457 This information must be retrieved out of band, as illustrated in 3458 <xref target="day_in_zoneowner"/>: 3459 A bank may send the user a letter with a QR code which contains the 3460 GNS zone of the bank. 3461 The user scans the QR code and adds a new suffix-to-name mapping 3462 using a chosen local name for his bank. 3463 Other examples include scanning zone information off the device of 3464 a friend, from a storefront, or an advertisement. 3465 The level of trust in the respective zone is contextual and likely 3466 varies from user to user. 3467 Trust in a zone provided through a letter from a bank which 3468 may also include a credit card is certainly different from a zone 3469 found on a random advertisement in the streets. 3470 However, this trust is immediately tangible to the user and can 3471 be reflected in the local naming as well. 3472 </t> 3473 <t> 3474 User clients should facilitate the modification of the start zone 3475 configuration, for example by providing a QR code reader or other 3476 import mechanisms. 3477 Implementations are ideally implemented 3478 according to best practices and addressing applicable points 3479 from <xref target="security"/>. 3480 Formalizing such best practices is out of scope of this 3481 specification. 3482 </t> 3483 </section> 3484 <section anchor="uc_virthost"> 3485 <name>Globally Unique Names and the Web</name> 3486 <t> 3487 HTTP virtual hosting and TLS Server Name Indication are common 3488 use cases on the Web. 3489 HTTP clients supply a DNS name in the HTTP 3490 "Host"-header or as part of the TLS handshake, respectively. 3491 This allows the HTTP server to serve the indicated virtual host 3492 with a matching TLS certificate. 3493 The global uniqueness of DNS names are a prerequisite of those use cases. 3494 </t> 3495 <t> 3496 Not all GNS names are globally unique. 3497 But, any resource record in GNS can be represented as a 3498 concatenation of of a GNS label and the zTLD of the zone. 3499 While not human-readable, this globally unique GNS name can be 3500 leveraged in order to facilitate the same use cases. 3501 Consider the GNS name "www.example.gns" entered in a GNS-aware 3502 HTTP client. 3503 At first, "www.example.gns" is resolved using GNS yielding a record 3504 set. 3505 Then, the HTTP client determines the virtual host as follows: 3506 </t> 3507 <t> 3508 If there is a LEHO record (<xref target="gnsrecords_leho"/>) 3509 containing "www.example.com" in the record set, then the HTTP 3510 client uses this as the value of the 3511 "Host"-header field of the HTTP request: 3512 </t> 3513 <artwork name="" type="" align="left" alt=""><![CDATA[ 3514 GET / HTTP/1.1 3515 Host: www.example.com 3516 ]]></artwork> 3517 <t> 3518 If there is no LEHO record in the record set, 3519 then the HTTP client tries to find the zone of the record 3520 and translates the GNS name into a globally unique 3521 zTLD-representation before using it in the "Host"-header field of 3522 the HTTP request: 3523 </t> 3524 <artwork name="" type="" align="left" alt=""><![CDATA[ 3525 GET / HTTP/1.1 3526 Host: www.000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3527 ]]></artwork> 3528 <t> 3529 In order to determine the canonical representation of the record with 3530 a zTLD, at most two queries are required: 3531 First, it must be checked whether "www.example.gns.alt" itself points to 3532 a zone delegation record which would imply that the record set which 3533 was originally resolved is published under the apex label. 3534 If it does, the unique GNS name is simply the zTLD representation 3535 of the delegated zone: 3536 </t> 3537 <artwork name="" type="" align="left" alt=""><![CDATA[ 3538 GET / HTTP/1.1 3539 Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3540 ]]></artwork> 3541 <t> 3542 If it does not, the unique GNS name is the concatenation of the 3543 label "www" and the zTLD representation of the zone as given in the 3544 example above. 3545 In any case, this representation is globally unique. 3546 As such, it can be configured by the HTTP server administrator as a 3547 virtual host name and respective certificates may be issued. 3548 </t> 3549 <t> 3550 If the HTTP client is a browser, the use of a unique GNS name 3551 for virtual hosting or TLS SNI does not necessarily have to be 3552 shown to the user. 3553 For example, the name in the URL bar may remain as "www.example.gns.alt" 3554 even if the used unique name differs. 3555 </t> 3556 </section> 3557 <section> 3558 <name>Migration Paths</name> 3559 <t> 3560 DNS resolution is built into a variety of existing software 3561 components. 3562 Most significantly operating systems and HTTP clients. 3563 This section illustrates possible migration paths for both in order 3564 to enable "legacy" applications to resolve GNS names. 3565 </t> 3566 <t> 3567 One way to efficiently facilitate the resolution of GNS names 3568 are GNS-enabled DNS server implementations. 3569 Local DNS queries are thereby either rerouted or explicitly configured 3570 to be resolved by a "DNS-to-GNS" server that runs locally. 3571 This DNS server tries to interpret any incoming query for a name 3572 as a GNS resolution request. 3573 If no start zone can be found for the name and it does not end in 3574 a zTLD, the server tries to resolve the name in DNS. 3575 Otherwise, the name is resolved in GNS. 3576 In the latter case, the resulting record set is converted to a DNS 3577 answer packet and is returned accordingly. 3578 An implementation of a DNS-to-GNS server can be found in 3579 <xref target="GNUnet"/>. 3580 </t> 3581 <t> 3582 A similar approach is to use operating systems extensions such as 3583 the name service switch <xref target="nsswitch"/>. 3584 It allows the system administrator to configure plugins 3585 which are used for hostname resolution. 3586 A GNS name service switch plugin can be used in a similar fashion as 3587 the "DNS-to-GNS" server. 3588 An implementation of a glibc-compatible nsswitch plugin for GNS 3589 can be found in <xref target="GNUnet"/>. 3590 </t> 3591 <t> 3592 The methods above are usually also effective for HTTP client 3593 software. 3594 However, HTTP clients are commonly used in combination with 3595 TLS. 3596 TLS certificate validation and in particular server name indication 3597 (SNI) requires additional logic in HTTP clients when GNS names are 3598 in play (<xref target="uc_virthost"/>). 3599 In order to transparently enable this functionality for migration 3600 purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"/> 3601 can be configured to resolve domain names. 3602 The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable 3603 of resolving both GNS and DNS names. 3604 In the event of a TLS connection request with a GNS name, the SOCKS5 3605 proxy can act as a man-in-the-middle, terminating the TLS connection 3606 and establishing a secure connection against the requested host. 3607 In order to establish a secure connection, the proxy may use LEHO 3608 and TLSA records stored in the record set under the GNS name. 3609 The proxy must provide a locally trusted certificate for the GNS 3610 name to the HTTP client which usually requires the generation and 3611 configuration of a local trust anchor in the browser. 3612 An implementation of this SOCKS5 proxy can be found in 3613 <xref target="GNUnet"/>. 3614 </t> 3615 </section> 3616 </section> 3617 <section> 3618 <name>Example flows</name> 3619 <section> 3620 <name>AAAA Example Resolution</name> 3621 <figure anchor="figure_resolution_ex_aaaa" title="Example resolution of an IPv6 address."> 3622 <artwork name="" type="" align="left" alt=""><![CDATA[ 3623 Local Host | Remote 3624 | Storage 3625 | 3626 | +---------+ 3627 | / /| 3628 | +---------+ | 3629 +-----------+ (1) +----------+ | | | | 3630 | | | | (4,6) | | Record | | 3631 |Application|----------| Resolver |---------------|->| Storage | | 3632 | |<---------| |<--------------|--| |/ 3633 +-----------+ (8) +----------+ (5,7) | +---------+ 3634 A | 3635 | | 3636 (2,3) | | 3637 | | 3638 | | 3639 +---------+ | 3640 / v /| | 3641 +---------+ | | 3642 | | | | 3643 | Start | | | 3644 | Zones | | | 3645 | |/ | 3646 +---------+ | 3647 ]]></artwork> 3648 </figure> 3649 <ol> 3650 <li>Lookup AAAA record for name: www.example.gnu.gns.alt.</li> 3651 <li>Determine start zone for www.example.gnu.gns.alt.</li> 3652 <li>Start zone: zk0 - Remainder: www.example.</li> 3653 <li>Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0).</li> 3654 <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zk1.</li> 3655 <li>Calculate q1=SHA512(ZKDF(zk1, "www")) and initiate GET(q1).</li> 3656 <li>Retrieve RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3657 <li>Return record set to application</li> 3658 </ol> 3659 </section> 3660 <section> 3661 <name>REDIRECT Example Resolution</name> 3662 <figure anchor="figure_resolution_ex_redir" title="Example resolution of an IPv6 address with redirect."> 3663 <artwork name="" type="" align="left" alt=""><![CDATA[ 3664 Local Host | Remote 3665 | Storage 3666 | 3667 | +---------+ 3668 | / /| 3669 | +---------+ | 3670 +-----------+ (1) +----------+ | | | | 3671 | | | | (4,6,8) | | Record | | 3672 |Application|----------| Resolver |----------------|->| Storage | | 3673 | |<---------| |<---------------|--| |/ 3674 +-----------+ (10) +----------+ (5,7,9) | +---------+ 3675 A | 3676 | | 3677 (2,3) | | 3678 | | 3679 | | 3680 +---------+ | 3681 / v /| | 3682 +---------+ | | 3683 | | | | 3684 | Start | | | 3685 | Zones | | | 3686 | |/ | 3687 +---------+ | 3688 ]]></artwork> 3689 </figure> 3690 <ol> 3691 <li>Lookup AAAA record for name: www.example.tld.gns.alt.</li> 3692 <li>Determine start zone for www.example.tld.gns.alt.</li> 3693 <li>Start zone: zk0 - Remainder: www.example.</li> 3694 <li>Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0).</li> 3695 <li>Retrieve and decrypt RRBLOCK consisting of a single PKEY record containing zk1.</li> 3696 <li>Calculate q1=SHA512(ZKDF(zk1, "www")) and initiate GET(q1).</li> 3697 <li>Retrieve and decrypt RRBLOCK consisting of a single REDIRECT record containing www2.+.</li> 3698 <li>Calculate q2=SHA512(ZKDF(zk1, "www2")) and initiate GET(q2).</li> 3699 <li>Retrieve and decrypt RRBLOCK consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3700 <li>Return record set to application.</li> 3701 </ol> 3702 </section> 3703 <section> 3704 <name>GNS2DNS Example Resolution</name> 3705 <figure anchor="figure_resolution_ex_gnsdns" title="Example resolution of an IPv6 address with DNS handover."> 3706 <artwork name="" type="" align="left" alt=""><![CDATA[ 3707 Local Host | Remote 3708 | Storage 3709 | 3710 | +---------+ 3711 | / /| 3712 | +---------+ | 3713 +-----------+ (1) +----------+ | | | | 3714 | | | | (4) | | Record | | 3715 |Application|----------| Resolver |------------------|->| Storage | | 3716 | |<---------| |<-----------------|--| |/ 3717 +-----------+ (8) +----------+ (5) | +---------+ 3718 A A | 3719 | | (6,7) | 3720 (2,3) | +----------+ | 3721 | | | 3722 | v | 3723 +---------+ +------------+ | 3724 / v /| | System DNS | | 3725 +---------+ | | resolver | | 3726 | | | +------------+ | 3727 | Start | | | 3728 | Zones | | | 3729 | |/ | 3730 +---------+ | 3731 ]]></artwork> 3732 </figure> 3733 <ol> 3734 <li>Lookup AAAA record for name: www.example.gnu.gns.alt</li> 3735 <li>Determine start zone for www.example.gnu.gns.alt.</li> 3736 <li>Start zone: zk0 - Remainder: www.example.</li> 3737 <li>Calculate q0=SHA512(ZKDF(zk0, "example")) and initiate GET(q0).</li> 3738 <li>Retrieve and decrypt RRBLOCK consisting of a single GNS2DNS record containing the name example.com and the DNS server IPv4 address 192.0.2.1.</li> 3739 <li>Use system resolver to lookup an AAAA record for the DNS name www.example.com.</li> 3740 <li>Retrieve a DNS reply consisting of a single AAAA record containing the IPv6 address 2001:db8::1.</li> 3741 <li>Return record set to application.</li> 3742 </ol> 3743 </section> 3744 3745 </section> 3746 <section> 3747 <name>Base32GNS</name> 3748 <t> 3749 Encoding converts a byte array into a string of symbols. 3750 Decoding converts a string of symbols into a byte array. 3751 Decoding fails if the input string has symbols outside the defined set. 3752 </t> 3753 <t> 3754 This table defines the encode and decode symbols for a given 3755 symbol value. 3756 Each symbol value encodes 5 bits. 3757 It can be used to implement the encoding by reading it as: 3758 A symbol "A" or "a" is decoded to a 5 bit value 10 when decoding. 3759 A 5 bit block with a value of 18 is encoded to the character "J" when encoding. 3760 If the bit length of the byte string to encode is not a multiple of 5 3761 it is padded to the next multiple with zeroes. 3762 In order to further increase tolerance for failures in character 3763 recognition, the letter "U" <bcp14>MUST</bcp14> be decoded to the same value as the 3764 letter "V" in Base32GNS. 3765 </t> 3766 <figure anchor="CrockfordB32Encode" title="The Base32GNS Alphabet Including the Additional U Encode Symbol."> 3767 <artwork name="" type="" align="left" alt=""><![CDATA[ 3768 Symbol Decode Encode 3769 Value Symbol Symbol 3770 0 0 O o 0 3771 1 1 I i L l 1 3772 2 2 2 3773 3 3 3 3774 4 4 4 3775 5 5 5 3776 6 6 6 3777 7 7 7 3778 8 8 8 3779 9 9 9 3780 10 A a A 3781 11 B b B 3782 12 C c C 3783 13 D d D 3784 14 E e E 3785 15 F f F 3786 16 G g G 3787 17 H h H 3788 18 J j J 3789 19 K k K 3790 20 M m M 3791 21 N n N 3792 22 P p P 3793 23 Q q Q 3794 24 R r R 3795 25 S s S 3796 26 T t T 3797 27 V v U u V 3798 28 W w W 3799 29 X x X 3800 30 Y y Y 3801 31 Z z Z 3802 ]]></artwork> 3803 </figure> 3804 </section> 3805 3806 <section> 3807 <name>Test Vectors</name> 3808 <t> 3809 The following test vectors can be used by implementations to test 3810 for conformance with this specification. Unless indicated otherwise, 3811 the test vectors are provided as hexadecimal byte arrays. 3812 </t> 3813 <section> 3814 <name>Base32GNS en-/decoding</name> 3815 <t> 3816 The following are test vectors for the Base32GNS encoding used for zTLDs. The input strings are encoded without the zero terminator. 3817 </t> 3818 3819 <artwork name="" type="" align="left" alt=""> 3820 <![CDATA[ 3821 Base32GNS-Encode: 3822 Input string: "Hello World" 3823 Output string: "91JPRV3F41BPYWKCCG" 3824 3825 Input bytes: 474e55204e616d652053797374656d 3826 Output string: "8X75A82EC5PPA82KF5SQ8SBD" 3827 3828 Base32GNS-Decode: 3829 Input string: "91JPRV3F41BPYWKCCG" 3830 Output string: "Hello World" 3831 3832 Input string: "91JPRU3F41BPYWKCCG" 3833 Output string: "Hello World" 3834 ]]> 3835 </artwork> 3836 </section> 3837 <section> 3838 <name>Record sets</name> 3839 3840 <t> 3841 The test vectors include record sets with a variety 3842 of record types and flags for both PKEY and EDKEY zones. 3843 This includes labels with UTF-8 characters to demonstrate 3844 internationalized labels. 3845 </t> 3846 <t><strong>(1) PKEY zone with ASCII label and one delegation record</strong></t> 3847 <artwork name="" type="" align="left" alt=""> 3848 <![CDATA[ 3849 Zone private key (d, big-endian): 3850 50 d7 b6 52 a4 ef ea df 3851 f3 73 96 90 97 85 e5 95 3852 21 71 a0 21 78 c8 e7 d4 3853 50 fa 90 79 25 fa fd 98 3854 3855 Zone identifier (ztype|zkey): 3856 00 01 00 00 67 7c 47 7d 3857 2d 93 09 7c 85 b1 95 c6 3858 f9 6d 84 ff 61 f5 98 2c 3859 2c 4f e0 2d 5a 11 fe df 3860 b0 c2 90 1f 3861 3862 zTLD: 3863 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3864 3865 Label: 3866 74 65 73 74 64 65 6c 65 3867 67 61 74 69 6f 6e 3868 3869 Number of records (integer): 1 3870 3871 Record #0 := ( 3872 EXPIRATION: 8143584694000000 us 3873 00 1c ee 8c 10 e2 59 80 3874 3875 DATA_SIZE: 3876 00 20 3877 3878 TYPE: 3879 00 01 00 00 3880 3881 FLAGS: 00 01 3882 3883 DATA: 3884 21 e3 b3 0f f9 3b c6 d3 3885 5a c8 c6 e0 e1 3a fd ff 3886 79 4c b7 b4 4b bb c7 48 3887 d2 59 d0 a0 28 4d be 84 3888 3889 ) 3890 3891 RDATA: 3892 00 1c ee 8c 10 e2 59 80 3893 00 20 00 01 00 01 00 00 3894 21 e3 b3 0f f9 3b c6 d3 3895 5a c8 c6 e0 e1 3a fd ff 3896 79 4c b7 b4 4b bb c7 48 3897 d2 59 d0 a0 28 4d be 84 3898 3899 Encryption NONCE|EXPIRATION|BLOCK COUNTER: 3900 e9 0a 00 61 00 1c ee 8c 3901 10 e2 59 80 00 00 00 01 3902 3903 Encryption key (K): 3904 86 4e 71 38 ea e7 fd 91 3905 a3 01 36 89 9c 13 2b 23 3906 ac eb db 2c ef 43 cb 19 3907 f6 bf 55 b6 7d b9 b3 b3 3908 3909 Storage key (q): 3910 4a dc 67 c5 ec ee 9f 76 3911 98 6a bd 71 c2 22 4a 3d 3912 ce 2e 91 70 26 c9 a0 9d 3913 fd 44 ce f3 d2 0f 55 a2 3914 73 32 72 5a 6c 8a fb bb 3915 b0 f7 ec 9a f1 cc 42 64 3916 12 99 40 6b 04 fd 9b 5b 3917 57 91 f8 6c 4b 08 d5 f4 3918 3919 ZKDF(zkey): 3920 18 2b b6 36 ed a7 9f 79 3921 57 11 bc 27 08 ad bb 24 3922 2a 60 44 6a d3 c3 08 03 3923 12 1d 03 d3 48 b7 ce b6 3924 3925 Derived private key (d', big-endian): 3926 0a 4c 5e 0f 00 63 df ce 3927 db c8 c7 f2 b2 2c 03 0c 3928 86 28 b2 c2 cb ac 9f a7 3929 29 aa e6 1f 89 db 3e 9c 3930 3931 BDATA: 3932 0c 1e da 5c c0 94 a1 c7 3933 a8 88 64 9d 25 fa ee bd 3934 60 da e6 07 3d 57 d8 ae 3935 8d 45 5f 4f 13 92 c0 74 3936 e2 6a c6 69 bd ee c2 34 3937 62 b9 62 95 2c c6 e9 eb 3938 3939 RRBLOCK: 3940 00 00 00 a0 00 01 00 00 3941 18 2b b6 36 ed a7 9f 79 3942 57 11 bc 27 08 ad bb 24 3943 2a 60 44 6a d3 c3 08 03 3944 12 1d 03 d3 48 b7 ce b6 3945 0a d1 0b c1 3b 40 3b 5b 3946 25 61 26 b2 14 5a 6f 60 3947 c5 14 f9 51 ff a7 66 f7 3948 a3 fd 4b ac 4a 4e 19 90 3949 05 5c b8 7e 8d 1b fd 19 3950 aa 09 a4 29 f7 29 e9 f5 3951 c6 ee c2 47 0a ce e2 22 3952 07 59 e9 e3 6c 88 6f 35 3953 00 1c ee 8c 10 e2 59 80 3954 0c 1e da 5c c0 94 a1 c7 3955 a8 88 64 9d 25 fa ee bd 3956 60 da e6 07 3d 57 d8 ae 3957 8d 45 5f 4f 13 92 c0 74 3958 e2 6a c6 69 bd ee c2 34 3959 62 b9 62 95 2c c6 e9 eb 3960 ]]> 3961 </artwork> 3962 <t><strong>(2) PKEY zone with UTF-8 label and three records</strong></t> 3963 <artwork name="" type="" align="left" alt=""> 3964 <![CDATA[ 3965 Zone private key (d, big-endian): 3966 50 d7 b6 52 a4 ef ea df 3967 f3 73 96 90 97 85 e5 95 3968 21 71 a0 21 78 c8 e7 d4 3969 50 fa 90 79 25 fa fd 98 3970 3971 Zone identifier (ztype|zkey): 3972 00 01 00 00 67 7c 47 7d 3973 2d 93 09 7c 85 b1 95 c6 3974 f9 6d 84 ff 61 f5 98 2c 3975 2c 4f e0 2d 5a 11 fe df 3976 b0 c2 90 1f 3977 3978 zTLD: 3979 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W 3980 3981 Label: 3982 e5 a4 a9 e4 b8 8b e7 84 3983 a1 e6 95 b5 3984 3985 Number of records (integer): 3 3986 3987 Record #0 := ( 3988 EXPIRATION: 8143584694000000 us 3989 00 1c ee 8c 10 e2 59 80 3990 3991 DATA_SIZE: 3992 00 10 3993 3994 TYPE: 3995 00 00 00 1c 3996 3997 FLAGS: 00 00 3998 3999 DATA: 4000 00 00 00 00 00 00 00 00 4001 00 00 00 00 de ad be ef 4002 4003 ) 4004 4005 Record #1 := ( 4006 EXPIRATION: 17999736901000000 us 4007 00 3f f2 aa 54 08 db 40 4008 4009 DATA_SIZE: 4010 00 06 4011 4012 TYPE: 4013 00 01 00 01 4014 4015 FLAGS: 00 00 4016 4017 DATA: 4018 e6 84 9b e7 a7 b0 4019 4020 ) 4021 4022 Record #2 := ( 4023 EXPIRATION: 11464693629000000 us 4024 00 28 bb 13 ff 37 19 40 4025 4026 DATA_SIZE: 4027 00 0b 4028 4029 TYPE: 4030 00 00 00 10 4031 4032 FLAGS: 00 04 4033 4034 DATA: 4035 48 65 6c 6c 6f 20 57 6f 4036 72 6c 64 4037 4038 ) 4039 4040 RDATA: 4041 00 1c ee 8c 10 e2 59 80 4042 00 10 00 00 00 00 00 1c 4043 00 00 00 00 00 00 00 00 4044 00 00 00 00 de ad be ef 4045 00 3f f2 aa 54 08 db 40 4046 00 06 00 00 00 01 00 01 4047 e6 84 9b e7 a7 b0 00 28 4048 bb 13 ff 37 19 40 00 0b 4049 00 04 00 00 00 10 48 65 4050 6c 6c 6f 20 57 6f 72 6c 4051 64 00 00 00 00 00 00 00 4052 00 00 00 00 00 00 00 00 4053 00 00 00 00 00 00 00 00 4054 00 00 00 00 00 00 00 00 4055 00 00 00 00 00 00 00 00 4056 00 00 00 00 00 00 00 00 4057 4058 Encryption NONCE|EXPIRATION|BLOCK COUNTER: 4059 ee 96 33 c1 00 1c ee 8c 4060 10 e2 59 80 00 00 00 01 4061 4062 Encryption key (K): 4063 fb 3a b5 de 23 bd da e1 4064 99 7a af 7b 92 c2 d2 71 4065 51 40 8b 77 af 7a 41 ac 4066 79 05 7c 4d f5 38 3d 01 4067 4068 Storage key (q): 4069 af f0 ad 6a 44 09 73 68 4070 42 9a c4 76 df a1 f3 4b 4071 ee 4c 36 e7 47 6d 07 aa 4072 64 63 ff 20 91 5b 10 05 4073 c0 99 1d ef 91 fc 3e 10 4074 90 9f 87 02 c0 be 40 43 4075 67 78 c7 11 f2 ca 47 d5 4076 5c f0 b5 4d 23 5d a9 77 4077 4078 ZKDF(zkey): 4079 a5 12 96 df 75 7e e2 75 4080 ca 11 8d 4f 07 fa 7a ae 4081 55 08 bc f5 12 aa 41 12 4082 14 29 d4 a0 de 9d 05 7e 4083 4084 Derived private key (d', big-endian): 4085 0a be 56 d6 80 68 ab 40 4086 e1 44 79 0c de 9a cf 4d 4087 78 7f 2d 3c 63 b8 53 05 4088 74 6e 68 03 32 15 f2 ab 4089 4090 BDATA: 4091 d8 c2 8d 2f d6 96 7d 1a 4092 b7 22 53 f2 10 98 b8 14 4093 a4 10 be 1f 59 98 de 03 4094 f5 8f 7e 7c db 7f 08 a6 4095 16 51 be 4d 0b 6f 8a 61 4096 df 15 30 44 0b d7 47 dc 4097 f0 d7 10 4f 6b 8d 24 c2 4098 ac 9b c1 3d 9c 6f e8 29 4099 05 25 d2 a6 d0 f8 84 42 4100 67 a1 57 0e 8e 29 4d c9 4101 3a 31 9f cf c0 3e a2 70 4102 17 d6 fd a3 47 b4 a7 94 4103 97 d7 f6 b1 42 2d 4e dd 4104 82 1c 19 93 4e 96 c1 aa 4105 87 76 57 25 d4 94 c7 64 4106 b1 55 dc 6d 13 26 91 74 4107 4108 RRBLOCK: 4109 00 00 00 f0 00 01 00 00 4110 a5 12 96 df 75 7e e2 75 4111 ca 11 8d 4f 07 fa 7a ae 4112 55 08 bc f5 12 aa 41 12 4113 14 29 d4 a0 de 9d 05 7e 4114 08 5b d6 5f d4 85 10 51 4115 ba ce 2a 45 2a fc 8a 7e 4116 4f 6b 2c 1f 74 f0 20 35 4117 d9 64 1a cd ba a4 66 e0 4118 00 ce d6 f2 d2 3b 63 1c 4119 8e 8a 0b 38 e2 ba e7 9a 4120 22 ca d8 1d 4c 50 d2 25 4121 35 8e bc 17 ac 0f 89 9e 4122 00 1c ee 8c 10 e2 59 80 4123 d8 c2 8d 2f d6 96 7d 1a 4124 b7 22 53 f2 10 98 b8 14 4125 a4 10 be 1f 59 98 de 03 4126 f5 8f 7e 7c db 7f 08 a6 4127 16 51 be 4d 0b 6f 8a 61 4128 df 15 30 44 0b d7 47 dc 4129 f0 d7 10 4f 6b 8d 24 c2 4130 ac 9b c1 3d 9c 6f e8 29 4131 05 25 d2 a6 d0 f8 84 42 4132 67 a1 57 0e 8e 29 4d c9 4133 3a 31 9f cf c0 3e a2 70 4134 17 d6 fd a3 47 b4 a7 94 4135 97 d7 f6 b1 42 2d 4e dd 4136 82 1c 19 93 4e 96 c1 aa 4137 87 76 57 25 d4 94 c7 64 4138 b1 55 dc 6d 13 26 91 74 ]]> 4139 </artwork> 4140 <t><strong>(3) EDKEY zone with ASCII label and delegation record</strong></t> 4141 <artwork name="" type="" align="left" alt=""> 4142 <![CDATA[ 4143 Zone private key (d): 4144 5a f7 02 0e e1 91 60 32 4145 88 32 35 2b bc 6a 68 a8 4146 d7 1a 7c be 1b 92 99 69 4147 a7 c6 6d 41 5a 0d 8f 65 4148 4149 Zone identifier (ztype|zkey): 4150 00 01 00 14 3c f4 b9 24 4151 03 20 22 f0 dc 50 58 14 4152 53 b8 5d 93 b0 47 b6 3d 4153 44 6c 58 45 cb 48 44 5d 4154 db 96 68 8f 4155 4156 zTLD: 4157 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4158 4159 Label: 4160 74 65 73 74 64 65 6c 65 4161 67 61 74 69 6f 6e 4162 4163 Number of records (integer): 1 4164 4165 Record #0 := ( 4166 EXPIRATION: 8143584694000000 us 4167 00 1c ee 8c 10 e2 59 80 4168 4169 DATA_SIZE: 4170 00 20 4171 4172 TYPE: 4173 00 01 00 00 4174 4175 FLAGS: 00 01 4176 4177 DATA: 4178 21 e3 b3 0f f9 3b c6 d3 4179 5a c8 c6 e0 e1 3a fd ff 4180 79 4c b7 b4 4b bb c7 48 4181 d2 59 d0 a0 28 4d be 84 4182 4183 ) 4184 4185 RDATA: 4186 00 1c ee 8c 10 e2 59 80 4187 00 20 00 01 00 01 00 00 4188 21 e3 b3 0f f9 3b c6 d3 4189 5a c8 c6 e0 e1 3a fd ff 4190 79 4c b7 b4 4b bb c7 48 4191 d2 59 d0 a0 28 4d be 84 4192 4193 Encryption NONCE|EXPIRATION: 4194 98 13 2e a8 68 59 d3 5c 4195 88 bf d3 17 fa 99 1b cb 4196 00 1c ee 8c 10 e2 59 80 4197 4198 Encryption key (K): 4199 85 c4 29 a9 56 7a a6 33 4200 41 1a 96 91 e9 09 4c 45 4201 28 16 72 be 58 60 34 aa 4202 e4 a2 a2 cc 71 61 59 e2 4203 4204 Storage key (q): 4205 ab aa ba c0 e1 24 94 59 4206 75 98 83 95 aa c0 24 1e 4207 55 59 c4 1c 40 74 e2 55 4208 7b 9f e6 d1 54 b6 14 fb 4209 cd d4 7f c7 f5 1d 78 6d 4210 c2 e0 b1 ec e7 60 37 c0 4211 a1 57 8c 38 4e c6 1d 44 4212 56 36 a9 4e 88 03 29 e9 4213 4214 ZKDF(zkey): 4215 9b f2 33 19 8c 6d 53 bb 4216 db ac 49 5c ab d9 10 49 4217 a6 84 af 3f 40 51 ba ca 4218 b0 dc f2 1c 8c f2 7a 1a 4219 4220 nonce := SHA-256 (dh[32..63] || h): 4221 14 f2 c0 6b ed c3 aa 2d 4222 f0 71 13 9c 50 39 34 f3 4223 4b fa 63 11 a8 52 f2 11 4224 f7 3a df 2e 07 61 ec 35 4225 4226 Derived private key (d', big-endian): 4227 3b 1b 29 d4 23 0b 10 a8 4228 ec 4d a3 c8 6e db 88 ea 4229 cd 54 08 5c 1d db 63 f7 4230 a9 d7 3f 7c cb 2f c3 98 4231 4232 BDATA: 4233 57 7c c6 c9 5a 14 e7 04 4234 09 f2 0b 01 67 e6 36 d0 4235 10 80 7c 4f 00 37 2d 69 4236 8c 82 6b d9 2b c2 2b d6 4237 bb 45 e5 27 7c 01 88 1d 4238 6a 43 60 68 e4 dd f1 c6 4239 b7 d1 41 6f af a6 69 7c 4240 25 ed d9 ea e9 91 67 c3 4241 4242 RRBLOCK: 4243 00 00 00 b0 00 01 00 14 4244 9b f2 33 19 8c 6d 53 bb 4245 db ac 49 5c ab d9 10 49 4246 a6 84 af 3f 40 51 ba ca 4247 b0 dc f2 1c 8c f2 7a 1a 4248 9f 56 a8 86 ea 73 9d 59 4249 17 50 8f 9b 75 56 39 f3 4250 a9 ac fa ed ed ca 7f bf 4251 a7 94 b1 92 e0 8b f9 ed 4252 4c 7e c8 59 4c 9f 7b 4e 4253 19 77 4f f8 38 ec 38 7a 4254 8f 34 23 da ac 44 9f 59 4255 db 4e 83 94 3f 90 72 00 4256 00 1c ee 8c 10 e2 59 80 4257 57 7c c6 c9 5a 14 e7 04 4258 09 f2 0b 01 67 e6 36 d0 4259 10 80 7c 4f 00 37 2d 69 4260 8c 82 6b d9 2b c2 2b d6 4261 bb 45 e5 27 7c 01 88 1d 4262 6a 43 60 68 e4 dd f1 c6 4263 b7 d1 41 6f af a6 69 7c 4264 25 ed d9 ea e9 91 67 c3]]> 4265 </artwork> 4266 <t><strong>(4) EDKEY zone with UTF-8 label and three records</strong></t> 4267 <artwork name="" type="" align="left" alt=""> 4268 <![CDATA[ 4269 Zone private key (d): 4270 5a f7 02 0e e1 91 60 32 4271 88 32 35 2b bc 6a 68 a8 4272 d7 1a 7c be 1b 92 99 69 4273 a7 c6 6d 41 5a 0d 8f 65 4274 4275 Zone identifier (ztype|zkey): 4276 00 01 00 14 3c f4 b9 24 4277 03 20 22 f0 dc 50 58 14 4278 53 b8 5d 93 b0 47 b6 3d 4279 44 6c 58 45 cb 48 44 5d 4280 db 96 68 8f 4281 4282 zTLD: 4283 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4284 4285 Label: 4286 e5 a4 a9 e4 b8 8b e7 84 4287 a1 e6 95 b5 4288 4289 Number of records (integer): 3 4290 4291 Record #0 := ( 4292 EXPIRATION: 8143584694000000 us 4293 00 1c ee 8c 10 e2 59 80 4294 4295 DATA_SIZE: 4296 00 10 4297 4298 TYPE: 4299 00 00 00 1c 4300 4301 FLAGS: 00 00 4302 4303 DATA: 4304 00 00 00 00 00 00 00 00 4305 00 00 00 00 de ad be ef 4306 4307 ) 4308 4309 Record #1 := ( 4310 EXPIRATION: 17999736901000000 us 4311 00 3f f2 aa 54 08 db 40 4312 4313 DATA_SIZE: 4314 00 06 4315 4316 TYPE: 4317 00 01 00 01 4318 4319 FLAGS: 00 00 4320 4321 DATA: 4322 e6 84 9b e7 a7 b0 4323 4324 ) 4325 4326 Record #2 := ( 4327 EXPIRATION: 11464693629000000 us 4328 00 28 bb 13 ff 37 19 40 4329 4330 DATA_SIZE: 4331 00 0b 4332 4333 TYPE: 4334 00 00 00 10 4335 4336 FLAGS: 00 04 4337 4338 DATA: 4339 48 65 6c 6c 6f 20 57 6f 4340 72 6c 64 4341 4342 ) 4343 4344 RDATA: 4345 00 1c ee 8c 10 e2 59 80 4346 00 10 00 00 00 00 00 1c 4347 00 00 00 00 00 00 00 00 4348 00 00 00 00 de ad be ef 4349 00 3f f2 aa 54 08 db 40 4350 00 06 00 00 00 01 00 01 4351 e6 84 9b e7 a7 b0 00 28 4352 bb 13 ff 37 19 40 00 0b 4353 00 04 00 00 00 10 48 65 4354 6c 6c 6f 20 57 6f 72 6c 4355 64 00 00 00 00 00 00 00 4356 00 00 00 00 00 00 00 00 4357 00 00 00 00 00 00 00 00 4358 00 00 00 00 00 00 00 00 4359 00 00 00 00 00 00 00 00 4360 00 00 00 00 00 00 00 00 4361 4362 Encryption NONCE|EXPIRATION: 4363 bb 0d 3f 0f bd 22 42 77 4364 50 da 5d 69 12 16 e6 c9 4365 00 1c ee 8c 10 e2 59 80 4366 4367 Encryption key (K): 4368 3d f8 05 bd 66 87 aa 14 4369 20 96 28 c2 44 b1 11 91 4370 88 c3 92 56 37 a4 1e 5d 4371 76 49 6c 29 45 dc 37 7b 4372 4373 Storage key (q): 4374 ba f8 21 77 ee c0 81 e0 4375 74 a7 da 47 ff c6 48 77 4376 58 fb 0d f0 1a 6c 7f bb 4377 52 fc 8a 31 be f0 29 af 4378 74 aa 0d c1 5a b8 e2 fa 4379 7a 54 b4 f5 f6 37 f6 15 4380 8f a7 f0 3c 3f ce be 78 4381 d3 f9 d6 40 aa c0 d1 ed 4382 4383 ZKDF(zkey): 4384 74 f9 00 68 f1 67 69 53 4385 52 a8 a6 c2 eb 98 48 98 4386 c5 3a cc a0 98 04 70 c6 4387 c8 12 64 cb dd 78 ad 11 4388 4389 nonce := SHA-256 (dh[32..63] || h): 4390 f8 6a b5 33 8a 74 d7 a1 4391 d2 77 ea 11 ff 95 cb e8 4392 3a cf d3 97 3b b4 ab ca 4393 0a 1b 60 62 c3 7a b3 9c 4394 4395 Derived private key (d', big-endian): 4396 17 c0 68 a6 c3 f7 20 de 4397 0e 1b 69 ff 3f 53 e0 5d 4398 3f e5 c5 b0 51 25 7a 89 4399 a6 3c 1a d3 5a c4 35 58 4400 4401 BDATA: 4402 4e b3 5a 50 d4 0f e1 a4 4403 29 c7 f4 b2 67 a0 59 de 4404 4e 2c 8a 89 a5 ed 53 d3 4405 d4 92 58 59 d2 94 9f 7f 4406 30 d8 a2 0c aa 96 f8 81 4407 45 05 2d 1c da 04 12 49 4408 8f f2 5f f2 81 6e f0 ce 4409 61 fe 69 9b fa c7 2c 15 4410 dc 83 0e a9 b0 36 17 1c 4411 cf ca bb dd a8 de 3c 86 4412 ed e2 95 70 d0 17 4b 82 4413 82 09 48 a9 28 b7 f0 0e 4414 fb 40 1c 10 fe 80 bb bb 4415 02 76 33 1b f7 f5 1b 8d 4416 74 57 9c 14 14 f2 2d 50 4417 1a d2 5a e2 49 f5 bb f2 4418 a6 c3 72 59 d1 75 e4 40 4419 b2 94 39 c6 05 19 cb b1 4420 4421 RRBLOCK: 4422 00 00 01 00 00 01 00 14 4423 74 f9 00 68 f1 67 69 53 4424 52 a8 a6 c2 eb 98 48 98 4425 c5 3a cc a0 98 04 70 c6 4426 c8 12 64 cb dd 78 ad 11 4427 75 6d 2c 15 7a d2 ea 4f 4428 c0 b1 b9 1c 08 03 79 44 4429 61 d3 de f2 0d d1 63 6c 4430 fe dc 03 89 c5 49 d1 43 4431 6c c3 5b 4e 1b f8 89 5a 4432 64 6b d9 a6 f4 6b 83 48 4433 1d 9c 0e 91 d4 e1 be bb 4434 6a 83 52 6f b7 25 2a 06 4435 00 1c ee 8c 10 e2 59 80 4436 4e b3 5a 50 d4 0f e1 a4 4437 29 c7 f4 b2 67 a0 59 de 4438 4e 2c 8a 89 a5 ed 53 d3 4439 d4 92 58 59 d2 94 9f 7f 4440 30 d8 a2 0c aa 96 f8 81 4441 45 05 2d 1c da 04 12 49 4442 8f f2 5f f2 81 6e f0 ce 4443 61 fe 69 9b fa c7 2c 15 4444 dc 83 0e a9 b0 36 17 1c 4445 cf ca bb dd a8 de 3c 86 4446 ed e2 95 70 d0 17 4b 82 4447 82 09 48 a9 28 b7 f0 0e 4448 fb 40 1c 10 fe 80 bb bb 4449 02 76 33 1b f7 f5 1b 8d 4450 74 57 9c 14 14 f2 2d 50 4451 1a d2 5a e2 49 f5 bb f2 4452 a6 c3 72 59 d1 75 e4 40 4453 b2 94 39 c6 05 19 cb b1]]> 4454 </artwork> 4455 </section> 4456 <section> 4457 <name>Zone revocation</name> 4458 <t> 4459 The following is an example revocation for a PKEY zone: 4460 </t> 4461 <artwork name="" type="" align="left" alt=""> 4462 <![CDATA[ 4463 Zone private key (d, big-endian): 4464 6f ea 32 c0 5a f5 8b fa 4465 97 95 53 d1 88 60 5f d5 4466 7d 8b f9 cc 26 3b 78 d5 4467 f7 47 8c 07 b9 98 ed 70 4468 4469 Zone identifier (ztype|zkey): 4470 00 01 00 00 2c a2 23 e8 4471 79 ec c4 bb de b5 da 17 4472 31 92 81 d6 3b 2e 3b 69 4473 55 f1 c3 77 5c 80 4a 98 4474 d5 f8 dd aa 4475 4476 Encoded zone identifier (zkl = zTLD): 4477 000G001CM8HYGYFCRJXXXDET2WRS50EP7CQ3PTANY71QEQ409ACDBY6XN8 4478 4479 Difficulty (5 base difficulty + 2 epochs): 7 4480 4481 Signed message: 4482 00 00 00 34 00 00 00 03 4483 00 05 ff 1c 56 e4 b2 68 4484 00 01 00 00 2c a2 23 e8 4485 79 ec c4 bb de b5 da 17 4486 31 92 81 d6 3b 2e 3b 69 4487 55 f1 c3 77 5c 80 4a 98 4488 d5 f8 dd aa 4489 4490 Proof: 4491 00 05 ff 1c 56 e4 b2 68 4492 00 00 39 5d 18 27 c0 00 4493 38 0b 54 aa 70 16 ac a2 4494 38 0b 54 aa 70 16 ad 62 4495 38 0b 54 aa 70 16 af 3e 4496 38 0b 54 aa 70 16 af 93 4497 38 0b 54 aa 70 16 b0 bf 4498 38 0b 54 aa 70 16 b0 ee 4499 38 0b 54 aa 70 16 b1 c9 4500 38 0b 54 aa 70 16 b1 e5 4501 38 0b 54 aa 70 16 b2 78 4502 38 0b 54 aa 70 16 b2 b2 4503 38 0b 54 aa 70 16 b2 d6 4504 38 0b 54 aa 70 16 b2 e4 4505 38 0b 54 aa 70 16 b3 2c 4506 38 0b 54 aa 70 16 b3 5a 4507 38 0b 54 aa 70 16 b3 9d 4508 38 0b 54 aa 70 16 b3 c0 4509 38 0b 54 aa 70 16 b3 dd 4510 38 0b 54 aa 70 16 b3 f4 4511 38 0b 54 aa 70 16 b4 42 4512 38 0b 54 aa 70 16 b4 76 4513 38 0b 54 aa 70 16 b4 8c 4514 38 0b 54 aa 70 16 b4 a4 4515 38 0b 54 aa 70 16 b4 c9 4516 38 0b 54 aa 70 16 b4 f0 4517 38 0b 54 aa 70 16 b4 f7 4518 38 0b 54 aa 70 16 b5 79 4519 38 0b 54 aa 70 16 b6 34 4520 38 0b 54 aa 70 16 b6 8e 4521 38 0b 54 aa 70 16 b7 b4 4522 38 0b 54 aa 70 16 b8 7e 4523 38 0b 54 aa 70 16 b8 f8 4524 38 0b 54 aa 70 16 b9 2a 4525 00 01 00 00 2c a2 23 e8 4526 79 ec c4 bb de b5 da 17 4527 31 92 81 d6 3b 2e 3b 69 4528 55 f1 c3 77 5c 80 4a 98 4529 d5 f8 dd aa 08 ca ff de 4530 3c 6d f1 45 f7 e0 79 81 4531 15 37 b2 b0 42 2d 5e 1f 4532 b2 01 97 81 ec a2 61 d1 4533 f9 d8 ea 81 0a bc 2f 33 4534 47 7f 04 e3 64 81 11 be 4535 71 c2 48 82 1a d6 04 f4 4536 94 e7 4d 0b f5 11 d2 c1 4537 62 77 2e 81 4538 ]]> 4539 </artwork> 4540 <t> 4541 The following is an example revocation for an EDKEY zone: 4542 </t> 4543 <artwork name="" type="" align="left" alt=""> 4544 <![CDATA[ 4545 Zone private key (d): 4546 5a f7 02 0e e1 91 60 32 4547 88 32 35 2b bc 6a 68 a8 4548 d7 1a 7c be 1b 92 99 69 4549 a7 c6 6d 41 5a 0d 8f 65 4550 4551 Zone identifier (ztype|zkey): 4552 00 01 00 14 3c f4 b9 24 4553 03 20 22 f0 dc 50 58 14 4554 53 b8 5d 93 b0 47 b6 3d 4555 44 6c 58 45 cb 48 44 5d 4556 db 96 68 8f 4557 4558 Encoded zone identifier (zkl = zTLD): 4559 000G051WYJWJ80S04BRDRM2R2H9VGQCKP13VCFA4DHC4BJT88HEXQ5K8HW 4560 4561 Difficulty (5 base difficulty + 2 epochs): 7 4562 4563 Signed message: 4564 00 00 00 34 00 00 00 03 4565 00 05 ff 1c 57 35 42 bd 4566 00 01 00 14 3c f4 b9 24 4567 03 20 22 f0 dc 50 58 14 4568 53 b8 5d 93 b0 47 b6 3d 4569 44 6c 58 45 cb 48 44 5d 4570 db 96 68 8f 4571 4572 Proof: 4573 00 05 ff 1c 57 35 42 bd 4574 00 00 39 5d 18 27 c0 00 4575 58 4c 93 3c b0 99 2a 08 4576 58 4c 93 3c b0 99 2d f7 4577 58 4c 93 3c b0 99 2e 21 4578 58 4c 93 3c b0 99 2e 2a 4579 58 4c 93 3c b0 99 2e 53 4580 58 4c 93 3c b0 99 2e 8e 4581 58 4c 93 3c b0 99 2f 13 4582 58 4c 93 3c b0 99 2f 2d 4583 58 4c 93 3c b0 99 2f 3c 4584 58 4c 93 3c b0 99 2f 41 4585 58 4c 93 3c b0 99 2f fd 4586 58 4c 93 3c b0 99 30 33 4587 58 4c 93 3c b0 99 30 82 4588 58 4c 93 3c b0 99 30 a2 4589 58 4c 93 3c b0 99 30 e1 4590 58 4c 93 3c b0 99 31 ce 4591 58 4c 93 3c b0 99 31 de 4592 58 4c 93 3c b0 99 32 12 4593 58 4c 93 3c b0 99 32 4e 4594 58 4c 93 3c b0 99 32 9f 4595 58 4c 93 3c b0 99 33 31 4596 58 4c 93 3c b0 99 33 87 4597 58 4c 93 3c b0 99 33 8c 4598 58 4c 93 3c b0 99 33 e5 4599 58 4c 93 3c b0 99 33 f3 4600 58 4c 93 3c b0 99 34 26 4601 58 4c 93 3c b0 99 34 30 4602 58 4c 93 3c b0 99 34 68 4603 58 4c 93 3c b0 99 34 88 4604 58 4c 93 3c b0 99 34 8a 4605 58 4c 93 3c b0 99 35 4c 4606 58 4c 93 3c b0 99 35 bd 4607 00 01 00 14 3c f4 b9 24 4608 03 20 22 f0 dc 50 58 14 4609 53 b8 5d 93 b0 47 b6 3d 4610 44 6c 58 45 cb 48 44 5d 4611 db 96 68 8f 04 ae 26 f7 4612 63 56 5a b7 aa ab 01 71 4613 72 4f 3c a8 bc c5 1a 98 4614 b7 d4 c9 2e a3 3c d9 34 4615 4c a8 b6 3e 04 53 3a bf 4616 1a 3c 05 49 16 b3 68 2c 4617 5c a8 cb 4d d0 f8 4c 3b 4618 77 48 7a ac 6e ce 38 48 4619 0b a9 d5 00 4620 ]]> 4621 </artwork> 4622 </section> 4623 </section> 4624 <!-- Change Log 4625 v00 2017-07-23 MS Initial version 4626 --> 4627 </back> 4628 </rfc>