[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                                        K. Fujiwara
Internet-Draft                                                      JPRS
Intended status: Informational                          January 10, 2018
Expires: July 14, 2018


             Returning additional answers in DNS responses
               draft-fujiwara-dnsop-additional-answers-01

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 July 14, 2018.

Copyright Notice

   Copyright (c) 2018 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 July 14, 2018                 [Page 1]


Internet-Draft             additional-answers               January 2018


   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  . . . . . . . . . . . . . . . .   5
   7.  Use of Additional information . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   6
   11. Change History  . . . . . . . . . . . . . . . . . . . . . . .   6
     11.1.  00 to 01 . . . . . . . . . . . . . . . . . . . . . . . .   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 . . . . . . . . .   8
     A.3.  draft-bellis-dnsext-multi-qtypes  . . . . . . . . . . . .   8
     A.4.  draft-yao-dnsop-accompanying-questions  . . . . . . . . .   8
     A.5.  draft-vavrusa-dnsop-aaaa-for-free . . . . . . . . . . . .   8
     A.6.  QDCOUNT>1 idea  . . . . . . . . . . . . . . . . . . . . .   8
     A.7.  Comparison chart  . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

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],




Fujiwara                  Expires July 14, 2018                 [Page 2]


Internet-Draft             additional-answers               January 2018


   this also decreases the total number of queries that full-service
   resolvers need to send and authoritative servers need to answer.

   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].




Fujiwara                  Expires July 14, 2018                 [Page 3]


Internet-Draft             additional-answers               January 2018


   Additional records:  Additional records are records that the
      authoritative nameserver has included in the Additional section.

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.

   Additional records may be controlled by server configuration.
   "enable additional a/aaaa" or "enable additonal nsec*" options are
   possible.

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.



Fujiwara                  Expires July 14, 2018                 [Page 4]


Internet-Draft             additional-answers               January 2018


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-
   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.





Fujiwara                  Expires July 14, 2018                 [Page 5]


Internet-Draft             additional-answers               January 2018


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.

   The author would like to specifically thank Stephane Bortzmeyer for
   extensive review and comments.

11.  Change History

11.1.  00 to 01

   Sync with IETF 100 presentation

   o  Added system wide configration that controls additional records

   o  Added "draft-vavrusa-dnsop-aaaa-for-free"

   o  Updated comparison table

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-08 (work in
              progress), November 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,
              <https://www.rfc-editor.org/info/rfc1034>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/info/rfc1035>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
              editor.org/info/rfc2119>.



Fujiwara                  Expires July 14, 2018                 [Page 6]


Internet-Draft             additional-answers               January 2018


   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997,
              <https://www.rfc-editor.org/info/rfc2181>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <https://www.rfc-editor.org/info/rfc6555>.

   [RFC7719]  Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
              Terminology", RFC 7719, DOI 10.17487/RFC7719, December
              2015, <https://www.rfc-editor.org/info/rfc7719>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/info/rfc8198>.

12.2.  Informative References

   [I-D.bellis-dnsext-multi-qtypes]
              Bellis, R., "DNS Multiple QTYPEs", draft-bellis-dnsext-
              multi-qtypes-05 (work in progress), January 2018.

   [I-D.vavrusa-dnsop-aaaa-for-free]
              marek@vavrusa.com, m. and O. Gu[eth]mundsson, "Providing
              AAAA records for free with QTYPE=A", draft-vavrusa-dnsop-
              aaaa-for-free-00 (work in progress), March 2016.

   [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.






Fujiwara                  Expires July 14, 2018                 [Page 7]


Internet-Draft             additional-answers               January 2018


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.

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.  draft-vavrusa-dnsop-aaaa-for-free

   [I-D.vavrusa-dnsop-aaaa-for-free] proposes additional AAAA resource
   records in answer section.  New authoritative server software
   required.  New full-service resolver software required because
   existing full-service resolvers ignore additional AAAA resource
   records.  No configuration.

A.6.  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.




Fujiwara                  Expires July 14, 2018                 [Page 8]


Internet-Draft             additional-answers               January 2018


A.7.  Comparison chart

----------------+-----------+----------+---------+---------+------------
Draft           |additional |multiple  |aaaa for | multi   |accompanying
                |answers    |responses |free     | qtypes  |querstions
----------------+-----------+----------+---------+---------+------------
Protocol change |       No  | No       | Yes?    | Yes     | Yes
Code size       |   little  | some     | little  | large?  | large?
Resolver modification   No  | No       | Yes?    | Yes     | Yes
Config complexity|      No  | Yes      | No      | No      | No
Multiple names  |      Yes  | Yes      | No      | No      | Yes
Multiple types  |      Yes  | Yes      | AAAA    | Yes     | Yes
Multiple rcodes |   (NSEC*) | ---      | ---     | ---     | Yes
Negative response |    Yes  | No       | No      | Yes     | Yes
Fat response if |   always  | config   | always  | query   | query
Stub support ?  |       No  | No       | ?       | possible| possible
Deployment      |     easy  | easy     | gradual | gradual | gradual
Require DNSSEC  |     (Yes) | (Yes)    | No      | No      | No
IP addr Database|       No  |  No      | No      | EDNS    | EDNS
----------------+-----------+----------+---------+---------+------------


Author's Address

   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 July 14, 2018                 [Page 9]


Html markup produced by rfcmarkup 1.126, available from https://tools.ietf.org/tools/rfcmarkup/