Network Working Group K. Fujiwara Internet-Draft JPRS Intended status: Informational October 29, 2017 Expires: May 2, 2018 Returning additional answers in DNS responses draft-fujiwara-dnsop-additional-answers-00 Abstract This document proposes to document the ability to provide multiple answers in single DNS response. For example, authoritative servers may add a NSEC resource record or A/AAAA resource records of the query name. This is especially useful as, in many cases, the entity making the request has no a priori knowledge of what other questions it will need to ask. It is already possible (an authoritative server MAY already sends what it wants in the additional section). This document does not propose any protocol changes, just explanations of an already acceptable practice. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 2, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Fujiwara Expires May 2, 2018 [Page 1] Internet-Draft additional-answers October 2017 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Returning multiple answers . . . . . . . . . . . . . . . . . 4 5. Possible additional answers . . . . . . . . . . . . . . . . . 4 6. Stub-Resolver Considerations . . . . . . . . . . . . . . . . 4 7. Use of Additional information . . . . . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 11. Change History . . . . . . . . . . . . . . . . . . . . . . . 6 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 12.1. Normative References . . . . . . . . . . . . . . . . . . 6 12.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Comparisons of multiple response proposals . . . . . 7 A.1. draft-wkumari-dnsop-multiple-responses . . . . . . . . . 7 A.2. draft-fujiwara-dnsop-additional-answers . . . . . . . . . 7 A.3. draft-bellis-dnsext-multi-qtypes . . . . . . . . . . . . 7 A.4. draft-yao-dnsop-accompanying-questions . . . . . . . . . 8 A.5. QDCOUNT>1 idea . . . . . . . . . . . . . . . . . . . . . 8 A.6. Comparison chart . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction [I-D.wkumari-dnsop-multiple-responses] proposes pseudo resource record that controls resource records added into additional section. It offers any combinations of owner names and record types that are added into additional section. In many cases, combinations are limited and DNS software developers knows well. This document proposes that DNS server software developers choose the combination of additional data. By providing multiple answers in single response, authoritative name servers can assist full-service resolvers in pre-populating their cache before stub resolvers or other clients ask for the subsequent queries. Apart from decreasing the latency for end users [RFC6555], this also decreases the total number of queries that full-service resolvers need to send and authoritative servers need to answer. Fujiwara Expires May 2, 2018 [Page 2] Internet-Draft additional-answers October 2017 By providing NSEC/NSEC3 resource record that matches a query name, validating resolvers can generate NODATA or NXDOMAIN responses with Aggressive Use of DNSSEC-validated cache [RFC8198]. Developers of DNS servers know end users' query patterns or full- service resolvers' query patterns well. Authoritative DNS servers may add any authoritative data in the additional section. For example, QTYPE MX queries are followed by mail exchange hosts A/AAAA queries. When an authoritative server receives a QTYPE MX query, some implementations add mail exchange hosts A/AAAA resource records in additional section if the authoritative server have authoritative data of mail exchange hosts. Other typical examples are A and AAAA, SRV and Target A/AAAA, TLSA RR and corresponding server addresses. This technique, described in this document, is purely an optimization and enables authoritative servers to distribute some other related answers that the client is likely to need along with an answer to the original request. Users get a better experience, full-service resolvers need to send less queries, authoritative servers have to answer fewer queries, etc. 2. Background The DNS specifications ([RFC1034], for instance section 4.3.2) allow for supplemental information to be included in the "additional" section of the DNS response, but in order to defeat cache poisoning attacks most implementations either ignore or don't trust additional records they didn't ask for. For more background, see [RFC2181]. Some implementations add mail exchange A/AAAA resource records in MX responses (an actual example is given in section 3.7.1 of [RFC1034]). Some implementations add Target A/AAAA resource records in SRV responses. 3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Many of the specialized terms used in this specification are defined in DNS Terminology [RFC7719] and [I-D.ietf-dnsop-terminology-bis]. Additional records: Additional records are records that the authoritative nameserver has included in the Additional section. Fujiwara Expires May 2, 2018 [Page 3] Internet-Draft additional-answers October 2017 4. Returning multiple answers An authoritative nameserver MAY include any additional records that help name resolution. These additional records are appended to the additional section of the response. To increase the probability that these extra data will actually be useful for the resolver, it is suggested to send them only if: o The query has DNSSEC OK bit set. o The authoritative server is authoritative for the additional records, and the records to be returned are DNSSEC signed. The additional records contain RRSIGs. o To prove the non-existence of the resource record type, additional records may be NSEC/NSEC3 resource records for the query name and some other query names (for example, TLSA owner name). Validating resolvers can generate negative NODATA/NXDOMAIN response with Aggressive Use of DNSSEC-validated cache [RFC8198]. o Responses with additional records fit in the required response size. 5. Possible additional answers Possible query and additional records pairs are: o NAME A : NAME AAAA (or NAME NSEC/NSEC3) o NAME AAAA : NAME A (or NAME NSEC/NSEC3) o NAME MX : mail exchange A/AAAA (and/or mail exchange NSEC/NSEC3) o NAME SRV : Target host A/AAAA (and/or Target host NSEC/NSEC3) o NAME A/AAAA : _443._tcp.NAME TLSA (and/or NAME NSEC/NSEC3) o _443._tcp.NAME TLSA : NAME A/AAAA (and/or NAME NSEC/NSEC3) TLSA / MX / SRV pairs have different query names. 6. Stub-Resolver Considerations No modifications need to be made to stub-resolvers to get the predominate benefit of this protocol, since the majority of the speed gain will take place between the validating recursive resolver and the authoritative name server. However, stub resolvers and full- Fujiwara Expires May 2, 2018 [Page 4] Internet-Draft additional-answers October 2017 service resolvers may use this technique if stub-resolvers are validating stub resolvers. 7. Use of Additional information When deciding to use additional records in the additional section, a resolver should follow certain rules: o Additional records are validated before being used. o Additional records SHOULD have lower priority in the cache than answers received because they were requested. This is to help evict Additional records from the cache first (to help prevent cache filling attacks). o Recursive resolvers MAY choose to ignore Additional records for any reason, including CPU or cache space concerns, phase of the moon, etc. It may choose to accept all, some or none of the Additional record sets. o Recursive resolvers SHOULD support "Aggressive use of DNSSEC- validated cache" [RFC8198]. These rules are derived from [RFC2181] and DNSSEC RFCs. 8. IANA Considerations This document has no IANA actions. 9. Security Considerations The use of DNSSEC guarantees that these additional records will be accepted and cached by the resolver only if they can be proved genuine. The technique described in this document makes DNS response size large. If DNS response size exceeds path MTU, the response will be fragmented and the fragmentation may cause problems. Authoritative DNS server software developers and operators need to choose suitable response size limit. 10. Acknowledgments The author acknowledges authors of [I-D.wkumari-dnsop-multiple-responses] because many part of idea and texts are copied from the draft. Fujiwara Expires May 2, 2018 [Page 5] Internet-Draft additional-answers October 2017 The author would like to specifically thank Stephane Bortzmeyer for extensive review and comments. 11. Change History 12. References 12.1. Normative References [I-D.ietf-dnsop-terminology-bis] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", draft-ietf-dnsop-terminology-bis-07 (work in progress), October 2017. [I-D.wkumari-dnsop-multiple-responses] Kumari, W., Yan, Z., Hardaker, W., and D. Lawrence, "Returning extra answers in DNS responses.", draft- wkumari-dnsop-multiple-responses-05 (work in progress), July 2017. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC8198] Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198, July 2017, . Fujiwara Expires May 2, 2018 [Page 6] Internet-Draft additional-answers October 2017 12.2. Informative References [I-D.bellis-dnsext-multi-qtypes] Bellis, R., "DNS Multiple QTYPEs", draft-bellis-dnsext- multi-qtypes-04 (work in progress), July 2017. [I-D.yao-dnsop-accompanying-questions] Yao, J., Vixie, P., Kong, N., and X. Lee, "A DNS Query including A Main Question with Accompanying Questions", draft-yao-dnsop-accompanying-questions-04 (work in progress), September 2017. Appendix A. Comparisons of multiple response proposals A.1. draft-wkumari-dnsop-multiple-responses [I-D.wkumari-dnsop-multiple-responses] proposes pseudo resource record that controls resource records added into additional section. No protocol changes between authoritative servers and full-service resolvers. New authoritative server software required. Zone operators need to configure. Supports different owner names and types. Answer size becomes large if the query matches operators configuration. Requires DNSSEC. A.2. draft-fujiwara-dnsop-additional-answers draft-fujiwara-dnsop-additional-answers proposes that authoritative servers add well used additional records and NSEC/NSEC3 resource records in additional section. No protocol changes between authoritative servers and full-service resolvers. New authoritative server software required. No configuration. Supports different owner names and types. Answer size becomes large (always). Requires DNSSEC and [RFC8198]. A.3. draft-bellis-dnsext-multi-qtypes [I-D.bellis-dnsext-multi-qtypes] proposes new EDNS options that carry additional query types. New authoritative server software required. New full-service resolver software required. No configuration. No support of different owner names. Fujiwara Expires May 2, 2018 [Page 7] Internet-Draft additional-answers October 2017 A.4. draft-yao-dnsop-accompanying-questions [I-D.yao-dnsop-accompanying-questions] proposes new EDNS option that carry additional query names, query types and rcodes. New authoritative server software required. New full-service resolver software required. No configuration. A.5. QDCOUNT>1 idea No drafts. QDCOUNT is not limited to 1 in [RFC1035]. No protocol changes between authoritative servers and full-service resolvers, however, some implementations (For example, BIND 9, NSD, Unbound) treats QDCOUNT>1 as FORMERR. New authoritative server software required. New full-service resolver software required. Supports different owner names and types, however, it cannot answer different rcodes. No configuration. A database that each IP address support QDCOUNT>1 is required in full-service resolvers. A.6. Comparison chart ------------------+---------+----------+----------+----------+--------- Draft | wkumari | fujiawra | bellis | yao |QDCOUNT>1 ------------------+---------+----------+----------+----------+--------- Protocol change | No | No | Yes | Yes | Yes New Auth soft | Yes | Yes | Yes | Yes | Yes code size | some | little | large? | large? | large? New Resolver soft | No | No | Required | Required | Required Config complexity | Yes | No | No | No | No Multiple names | Yes | Yes | No | Yes | maybe Multiple types | Yes | Yes | Yes | Yes | Yes Multiple rcodes | --- | --- | need not | Yes | No Require DNSSEC | (Yes) | (Yes) | No | No | No Response fat if | config | always | query | query | query Stub support ? | No | No | possible | possible | possible IP addr Database | No | No | EDNS | EDNS | New Deploy? | Easy | Easy | Yes? | Yes? | No? ------------------+---------+----------+----------+----------+--------- Author's Address Fujiwara Expires May 2, 2018 [Page 8] Internet-Draft additional-answers October 2017 Kazunori Fujiwara Japan Registry Services Co., Ltd. Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda Chiyoda-ku, Tokyo 101-0065 Japan Phone: +81 3 5215 8451 Email: fujiwara@jprs.co.jp Fujiwara Expires May 2, 2018 [Page 9]