idnits 2.17.1 draft-wkumari-dnsop-omniscient-as112-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC6304, updated by this document, for RFC5378 checks: 2007-02-28) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2013) is 3959 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6304 (Obsoleted by RFC 7534) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Kumari 3 Internet-Draft Google 4 Updates: 6304 (if approved) W. Sotomayor 5 Intended status: Informational NRC-CNRC 6 Expires: December 23, 2013 J. Abley 7 ICANN 8 R. Bellis 9 Nominet UK 10 June 21, 2013 12 Omniscient AS112 Servers 13 draft-wkumari-dnsop-omniscient-as112-03 15 Abstract 17 The AS112 Project loosely coordinates Domain Name System (DNS) 18 servers to which DNS zones corresponding to private use addresses are 19 delegated. Queries for names within those zones have no useful 20 responses in a global context. The purpose of this project is to 21 reduce the load of such junk queries on the authoritative name 22 servers that would otherwise receive them, and instead direct the 23 load to name servers operated within the AS112 project. 25 Due to the loosely-coordinated nature of the project, adding and 26 dropping zones from the AS112 servers is difficult. This document 27 proposes a mechanism by which AS112 name servers could answer 28 authoritatively for all possible zones. This eliminates the add/drop 29 problem, changing it to a matter of delegation within the DNS and 30 requiring no operational changes on the servers themselves. 32 This document updates RFC 6304. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 23, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 4. Protocol Considerations . . . . . . . . . . . . . . . . . . . 4 72 5. Operational Considerations . . . . . . . . . . . . . . . . . 6 73 6. Addressing Considerations . . . . . . . . . . . . . . . . . . 7 74 7. Updates to RFC 6304 . . . . . . . . . . . . . . . . . . . . . 7 75 7.1. Changes to Section 3.4, Routing Software . . . . . . . . 7 76 7.2. Changes to Section 3.5, DNS Software . . . . . . . . . . 8 77 7.3. Changes to Section 3.6, Testing a Newly Installed Node . 9 78 8. Other Approaches . . . . . . . . . . . . . . . . . . . . . . 9 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 82 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 12.2. Informative References . . . . . . . . . . . . . . . . . 11 85 Appendix A. Implementation / "Running Code" . . . . . . . . . . 11 86 Appendix B. Document Notes . . . . . . . . . . . . . . . . . . . 11 87 B.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 88 B.2. Textual Substitutions . . . . . . . . . . . . . . . . . . 11 89 B.3. Open Questions . . . . . . . . . . . . . . . . . . . . . 11 90 B.4. Change History . . . . . . . . . . . . . . . . . . . . . 12 91 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 . . . . . . . 13 92 B.4.2. draft-wkumari-omniscient-as112-00 . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 The AS112 Project loosely coordinates Domain Name System (DNS) 98 servers [RFC1034] to which DNS zones corresponding to private use 99 addresses are delegated. Queries for names within those zones have 100 no useful responses in a global context. The purpose of the project 101 is to reduce the load of such junk queries on the authoritative name 102 servers that would otherwise receive them, directing the load instead 103 to name servers operated within the AS112 project. 105 To date, AS112 nameservers have been used exclusively for names 106 corresponding to the reverse mapping for private-use IPv4 addresses. 107 A description of current advice for AS112 operators, including 108 motivations and guidance for technical deployment and operations can 109 be found in [RFC6304]. 111 Other DNS domains have analogously local significance. Examples 112 corresponding to the reverse-mapping of special-use IPv4 and IPv6 113 addresses can be found in [RFC6303]. 115 It is to be expected that new domains will be identified from time to 116 time that fit the use pattern for which delegation to AS112 servers 117 might be desirable. There is currently no mechanism by which 118 particular zones can be reliably added to or dropped from AS112 119 servers, however. This is principally a consequence of the loosely- 120 coordinated nature of the project, coupled with a desire to avoid 121 lame delegations which might have unforeseen operational 122 consequences. 124 This document proposes a mechanism by which AS112 servers could 125 provide consistent, reliable negative responses for all DNS queries, 126 eliminating the operational requirement to add or drop particular 127 zones from all AS112 servers. 129 2. Terminology 131 An "Existing AS112 Server" is a DNS name server configured according 132 to the guidance provided in [RFC6304] and listening on the IPv4 133 addresses 192.175.48.1 (PRISONER.IANA.ORG), 192.175.48.6 134 (BLACKHOLE-1.IANA.ORG) and 192.175.48.42 (BLACKHOLE-2.IANA.ORG). 136 An "Omniscient AS112 Server" is a DNS nameserver configured according 137 to the guidance provided in [RFC6304], as extended by this document. 138 Such servers listen on the same addresses as Existing AS112 Servers, 139 but also additional addresses as described in Section 6. 141 Where discussions apply equally to Existing AS112 Servers and 142 Omniscient AS112 Servers, the unqualified phrase "AS112 Server" is 143 used. 145 An "AS112 Zone" is a DNS zone which has been delegated to an AS112 146 Server. 148 An "Existing AS112 Zone" is an AS112 Zone which has been delegated to 149 an existing AS112 Server. 151 3. Overview 153 An Omniscient AS112 Server is one that acts as though it is 154 authorative for all zones, but denies that there is any data. This 155 allows domains to be delegated to it and to receive back an 156 authorative NoError / NoData response for queries for labels in that 157 domain. This allows new zones to be added to or removed from the 158 AS112 project by simply delegating to the Omniscient AS112 servers 159 without needing to co-ordinate with the server operators. 161 It is worth noting that the term Omniscient is imperfect - it makes 162 it sound like an Omniscient AS112 Server knows the answers to 163 everything, whereas all it actually knows that it doesn't know 164 anything. A thesaurus shows that a good antonym for "Omniscient" is 165 "stupid", but we are not using this as we feel that it is too broad a 166 term and covers most nameservers. (:-)) 168 3.1. DNSSEC 170 Responses from Omniscient AS112 servers (like Existing AS112 servers) 171 are not DNSSEC signed. This does not cause issues as responses have 172 no meaning in the global context, and so the delegations to these are 173 either not signed or are insecure delegations. 175 4. Protocol Considerations 177 Familiarity with [RFC1034] and [RFC1035] is assumed. 179 In order to safely cache the response, DNS implementations require 180 the closest-enclosing SOA to be returned. An Omniscient AS112 server 181 (which is not configured with a specific list of zones, and hence 182 zone cuts) cannot necessarily know where that is. Removing labels 183 and guessing (whether to the extreme case of removing all labels, or 184 returning one, or anything in between) cannot be guaranteed to be 185 appropriate, since the answers might clash with authentic answers 186 already present in client caches. A client that has followed a 187 referral to an Omniscient AS112 server is guaranteed not to have a 188 cached SOA that matches the QNAME, however, so Omniscient AS112 189 servers use the QNAME as the SOA and owner name. 191 Please see Appendix A for information on an implementation ("running 192 code") that does this. 194 AS112 Servers respond to AXFR (QTYPE=252) or IXFR (QTYPE=251) with 195 RCODE=REFUSED. 197 A TYPE=6 (SOA) resource record for Omniscient AS112 servers contains: 199 o MNAME = "a.as112.net." 201 o RNAME = "hostmaster.as112.net." 203 o SERIAL = 1 205 o REFRESH =604800 (7 days) 207 o RETRY = 2592000 (30 days) 209 o EXPIRE = 604800 (7 days) 211 o MINIMUM = 604800 (7 days, negative caching TTL) 213 For all queries with QTYPE=2 (NS) an AS112 Server responds with an 214 authoritative (AA=1) answer with NoError (RCODE=0), the owner name 215 copied from the QNAME and two resource records of TYPE=2 (NS), one 216 containing "B.AS112.NET." and the containing "C.AS112.NET.". 218 For all queries with QTYPE=6 (SOA) an AS112 Server responds with an 219 authoritative (AA=1) answer with NoError (RCODE=0), the owner name 220 copied from the QNAME and one (ANCOUNT=1) resource record of TYPE=6 221 (SOA). 223 For all queries with QTYPE=255 (*, also known as ANY) an AS112 Server 224 responds with an authoritative (AA=1) answer with NoError (RCODE=0) 225 the owner name copied from the QNAME and three (ANCOUNT=3) resource 226 records, one containing the SOA (as described above), and two 227 containing NS (also as described above). 229 For all other queries an AS112 Server responds with an authoritative 230 (AA=1) NoError (RCODE=0) with the owner name copied from the QNAME in 231 the request and no answers (ANCOUNT=0). The resource record of 232 TYPE=6 (SOA) (as described above) should be returned in the authority 233 section. The presence of the SOA is to allow the negative cache TTL 234 to be set(see [RFC2308]). 236 5. Operational Considerations 238 Existing AS112 Servers address the protocol considerations described 239 in Section 4 by serving each existing AS112 Zone explicitly. In each 240 case the zone contents are identical, containing only required apex 241 SOA and NS records. Adding or dropping a delegation for an Existing 242 AS112 Zone requires coordination amongst all deployed Existing AS112 243 Server operators. 245 There is no practical expectation that AS112 Server operators 246 coordinate the configuration of their infrastructure or even make 247 their existence known in any systematic way. Delegation of new zones 248 to Existing AS112 Servers is hence problematic; there is an 249 expectation that such delegations would be lame for a significant 250 client population. Since the predictable behaviour of AS112 Servers 251 from clients is desirable, and it is possible that significant 252 variation would have operational consequences, no new zones should be 253 delegated to existing AS112 Servers. 255 Omniscient AS112 Servers generate a response (as described in 256 Section4 (Section 4)) as though they are authoritative for everything 257 ("."). Adding or dropping a delegation for an AS112 Zone therefore 258 imposes no operational requirements on Omniscient AS112 Server 259 operators. 261 Delegation of new AS112 Zones should only be made to Omniscient AS112 262 Servers. Omniscient AS112 Servers, therefore, must listen on 263 additional addresses to those used by existing AS112 Servers. 264 Addressing is discussed in Section 6. 266 By ensuring that Omniscient AS112 Servers listen on Existing AS112 267 Servers' addresses as well as the new addresses specified in 268 Section 6 a smooth migration is possible, allowing Existing AS112 269 Servers to be reconfigured as Omniscient AS112 Servers. Omniscient 270 AS112 Servers are therefore a superset of AS112 Servers. 272 6. Addressing Considerations 274 Omniscient AS112 Servers listen on the following addresses: 276 o IPv4-TBA1 (A.AS112.NET) 278 o IPv6-TBA1 (A.AS112.NET) 280 o IPv4-TBA2 (B.AS112.NET) 282 o IPv6-TBA2 (B.AS112.NET) 284 o IPv4-TBA3 (C.AS112.NET) 286 o IPv6-TBA3 (C.AS112.NET) 288 IPv4-TBA1, IPv4-TBA2 and IPv4-TBA3 are covered by a single IPv4 289 prefix, IPv4-PREFIX-TBA. Similarly, IPv6-TBA1, IPv6-TBA2 and 290 IPv6-TBA3 are covered by a single IPv6 prefix, IPv6-PREFIX-TBA. 292 The addresses specified for Omniscient AS112 Servers are deliberately 293 different from those assigned to Existing AS112 Servers for reasons 294 discussed in Section 5. 296 7. Updates to RFC 6304 298 7.1. Changes to Section 3.4, Routing Software 300 Omniscient AS112 Nodes with IPv4 connectivity should originate the 301 IPv4 service prefix associated with Existing AS112 Nodes, 302 192.175.48.0/24, and also the IPv4 service prefix associated with 303 Omniscient AS112 Nodes, IPv4-PREFIX-TBA. 305 Omniscient AS112 Nodes with IPv6 connectivity should originate the 306 IPv6 service prefix IPv6-PREFIX-TBA. 308 Applying this direction to the "bgpd.conf" file included as an 309 example in this section results in the configuration shown in Figure 310 1. 312 ! bgpd.conf 313 ! 314 hostname as112-bgpd 315 password 316 enable password 317 ! 318 ! Note that all AS112 nodes use the local Autonomous System 319 ! Number 112, and originate IPv4 and IPv6 prefixes (where IPv4 320 ! and IPv6 connectivity is available) as follows: 321 ! 322 ! IPv4: 192.175.48.0/24 323 ! IPv4-PREFIX-TBA 324 ! 325 ! IPv6: IPv6-PREFIX-TBA 326 ! 327 ! All other addresses shown below are illustrative, and 328 ! actual numbers will depend on local circumstances. 329 ! 330 router bgp 112 331 bgp router-id 203.0.113.1 332 ! 333 address-family ipv4 334 network 192.175.48.0 335 neighbor 192.0.2.1 remote-as 64496 336 neighbor 192.0.2.1 next-hop-self 337 neighbor 192.0.2.1 prefix-list AS112-v4 out 338 neighbor 192.0.2.1 filter-list 1 out 339 neighbor 192.0.2.2 remote-as 64497 340 neighbor 192.0.2.2 next-hop-self 341 neighbor 192.0.2.2 prefix-list AS112-v4 out 342 neighbor 192.0.2.2 filter-list 1 out 343 network 192.175.48.0/24 344 network IPv4-PREFIX-TBA 345 ! 346 address-family ipv6 unicast 347 neighbor 2001:db8::1 remote-as 64496 348 neighbor 2001:db8::1 next-hop-self 349 neighbor 2001:db8::1 prefix-list AS112-v6 out 350 neighbor 2001:db8::1 filter-list 1 out 351 neighbor 2001:db8::2 remote-as 64497 352 neighbor 2001:db8::2 next-hop-self 353 neighbor 2001:db8::2 prefix-list AS112-v6 out 354 neighbor 2001:db8::2 filter-list 1 out 355 network IPv6-PREFIX-TBA 356 ! 357 ip prefix-list AS112-v4 permit 192.175.48.0/24 358 ip prefix-list AS112-v4 permit IPv4-PREFIX-TBA 359 ! 360 ipv6 prefix-list AS112-v6 permit IPv6-PREFIX-TBA 361 ! 362 ip as-path access-list 1 permit ^$ 364 Figure 1 366 7.2. Changes to Section 3.5, DNS Software 367 Omniscient AS112 Servers should be configured to listen on the 368 addresses IPv6-TBA1, IPv6-TBA, IPv6-TBA3, IPv4-TBA1, IPv4-TBA2 and 369 IPv4-TBA3 in addition to the addresses used for Existing AS112 370 Servers. 372 Omniscient AS112 Servers generate an answer as described in Section 4 373 instead of explicitly serving the zones specified in [RFC6304]. 375 As ISC BIND [BIND] does not provide the required functionality a 376 custom nameserver implementation needs to be deployed, and so the 377 example "named.conf" file in this section can be disregarded. 379 7.3. Changes to Section 3.6, Testing a Newly Installed Node 381 Testing should include all configured service addresses for an 382 Omniscient AS112 Server (IPv4 or IPv6 or both, as appropriate). Note 383 that the IPv4 service addresses include those described in [RFC6304] 384 for Existing AS112 Servers. 386 8. Other Approaches 388 [Editors note: This is provided for information only. We may want to 389 remove this before publication... or not. If we don't, we should 390 tidy it up, it is conversational at the moment. It is here (instead 391 of in a "Changes / Appendix" section) so that folk read it :-P 393 Other solutions to this problem were considered. There are mentioned 394 here to avoid having to have the discussion from the beginning 395 again.] 397 The original version of this document suggested simply serving an 398 empty root zone. This was tested, but found not to work. In order 399 to prevent poisining, recursive resolvers will only cache the 400 response if it comes from the closest enclosing zone. This was 401 tested in BIND both with and without 'minimal responses'. Thanks to 402 Mark Andrews for pointing this out. 404 Brian Dickson suggested that DNAME could be used (instead of 405 delegating to AS112, DNAME to "foo" and then "foo" could be the SOA. 406 We have not yet fully tested this idea, one concern would be how 407 widely deployed DNAME support is. This is still being considered. 409 Paul Vixie (and others) suggested a metazone solution. This is also 410 worth considering more. A possible concern is stale AXFRs. 412 9. IANA Considerations 413 This document describes infrastructure which could be used in the 414 future to direct the IANA to delegate or redelegate infrastructure 415 zones under its administrative control. 417 However, this document makes no request of the IANA. 419 10. Security Considerations 421 The contents of the Security Considerations section of [RFC6304] 422 should be reviewed, since that discussion is pertinent to the 423 operation of Omniscient AS112 Servers as well as Existing AS112 424 Servers. 426 The deployment of Omniscient AS112 Servers enables new delegations to 427 AS112 Servers. 429 Queries received by an AS112 Server might reveal operational data for 430 which there is an expectation of privacy. For example, leaked 431 queries for an organisation's internal DNS names which are sent to an 432 AS112 Server might reveal the existence of those names to the AS112 433 Server operator. The delegation of new zones to AS112 Servers has 434 the potential to increase opportunities for such unintentional 435 information leakage. 437 The delegation of new zones to AS112 Servers has the potential to 438 increase the traffic received by those servers. AS112 Server 439 operators are encouraged to monitor traffic levels, and to take 440 appropriate steps if traffic levels threaten the stability of their 441 networks. 443 11. Acknowledgements 445 The authors thank and acknowledge the contributions of Dr Paul Vixie, 446 Ed Lewis, Bill Manning, George Michaelson, Mark Andrews, Shane Kerr, 447 Brian Dickson, S. Moonesamy, Chris Thompson, Nick Hilliard, Chris 448 Morrow, Paul Hoffman, Kurt Erik Lindqvist, Erik Kline, Roy Arends and 449 all the folk on the AS112 Project mailing lists in the preparation of 450 this document. 452 12. References 454 12.1. Normative References 456 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 457 STD 13, RFC 1034, November 1987. 459 [RFC1035] Mockapetris, P., "Domain names - implementation and 460 specification", STD 13, RFC 1035, November 1987. 462 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 463 NCACHE)", RFC 2308, March 1998. 465 [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 466 6304, July 2011. 468 12.2. Informative References 470 [BIND] Nominet UK, "Internet Systems Consortium, "BIND"", , 471 . 473 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 474 6303, July 2011. 476 [evldns] Bellis, R., "evldns", , 477 . 479 Appendix A. Implementation / "Running Code" 481 The "evldns" [evldns] library (written by Ray Bellis, Nominet UK) 482 includes an Omniscient AS112 Server implementation in the file 483 "oas112d.c" 485 Appendix B. Document Notes 487 This section (and sub-sections) contain information useful for 488 development and review of this document, and should be removed prior 489 to publication. 491 B.1. Venue 493 This document is an individual submission, and is not the product of 494 an IETF working group. However, a suitable venue for discussion is 495 the dnsop working group mailing list. 497 B.2. Textual Substitutions 499 The strings "IPv4-TBA1", "IPv4-TBA2" and "IPv4-TBA3" should be 500 replaced in this document should be replaced with IPv4 addresses 501 assigned for the purpose described. The covering IPv4 prefix for all 502 three addresses should replace the string "IPv4-PREFIX-TBA". 504 Similarly, the strings "IPv6-TBA1", "IPv6-TBA2", "IPv6-TBA3" and 505 "IPv6-PREFIX-TBA" should be substituted in the text with assigned 506 production values. 508 B.3. Open Questions 509 1. Where to get IPv4 and IPv6 assignments from? There has already 510 been an assignment to DNS-OARC by ARIN for v6 service for AS112 511 servers. 513 B.4. Change History 515 Template: 517 o Initial draft 519 o Initial draft, circulated privately, not submitted. 521 -00: 523 o Rewrote much of the document (especially Section 4 to explain how 524 (and why) resonses should be generated. 526 o Updated "Updates to RFC 6304" section to explain the BIND does not 527 currently implement this, and so named.conf, etc should be 528 ignored. 530 o Removed example "empty" zone. 532 o Changed the addressing bit at the suggestion of SM. 534 -01: 536 o Document title changed to include the dnsop keyword, so that IETF 537 document automation can send courtesy notifications of document 538 actions to the dnsop working group. 540 o Abstract and introduction expanded. 542 o RFC2119 requirements notation removed, since this is an 543 informational document and any normative language would be 544 toothless. 546 o Discussion broken out into Protocol Considerations, Operational 547 Considerations and Addressing Considerations. 549 o Reverted to the custom software / synthesized answers. 551 o Added in the Ray Bellis evldns stuff. 553 -01 to -02: 555 o s/NoError/NXDomain/ -- Suggestion from Paul Vixie (and others). 556 "Nxd says there is no such name, no matter what the type was, and 557 there are no children. No data/noerror says there are either 558 other types or children or both. We know what the truth must be 559 and we know which implications we want the requestor to follow. 560 Right?" -- Paul. 562 o Need to retest with empty root zone, and "minimal responses". 563 Initial test didn't seem to suppress the 'Negative Answers from 564 Authoritative Servers' (rfc2308) 566 o Removed the ''Editor note: [NoError was chosen instead of NXDOMAIN 567 because we did not think that we could reasonably return an SOA RR 568 which clearly indicates that the QNAME does exist, and also return 569 an NXDOMAIN.]" as we are now using NXDomain :-P 571 o This version submitted by Warren, with no real discussion with co- 572 authors. Trying to squeeze things under the -01 cutoff. 574 -02 to -03: 576 o "AS112 servers don't respond to transfers" -> AS112 respond, but 577 with REFUSED" -- thanks to Ed Lewis. 579 o Added an overview section. Before we just lept into protocol 580 discussions. 582 o And after much discussion on the list, and even more so in Orlando 583 we reverted to the NoError/NoData. See Orlando DNSOP audio 584 archives, around 50min. 586 o Added section 3.1 - DNSSEC 588 o Added Section 8 - Other Approaches. This section is 589 conversational. 591 B.4.1. draft-wkumari-dnsop-omniscient-as112-00 593 Document title changed to include the dnsop keyword, so that IETF 594 document automation can send courtesy notifications of document 595 actions to the dnsop working group. 597 Abstract and introduction expanded. 599 RFC2119 requirements notation removed, since this is an informational 600 document and any normative language would be toothless. 602 Discussion broken out into Protocol Considerations, Operational 603 Considerations and Addressing Considerations. 605 Detailed updates to [RFC6304] added. 607 B.4.2. draft-wkumari-omniscient-as112-00 609 Authors' Addresses 611 Warren Kumari 612 Google 613 1600 Ampitheatre Parkway 614 Mountain View, CA 94043 615 USA 617 Email: warren@kumari.net 619 William F. Maton Sotomayor 620 National Research Council of Canada 621 1200 Montreal Road 622 Ottawa, ON K1A 0R6 623 Canada 625 Phone: +1 613 993 0880 626 Email: wfms@ryouko.imsb.nrc.ca 628 Joe Abley 629 ICANN 630 12025 Waterfront Drive, Suite 300 631 Los Angeles, CA 90094-2536 632 USA 634 Phone: +1 519 670 9327 635 Email: joe.abley@icann.org 637 Ray Bellis 638 Nominet UK 639 Edmund Halley Road 640 Oxford OX4 4DQ 641 United Kingdom 643 Phone: +44 1865 332211 644 Email: ray.bellis@nominet.org.uk