Evaluation and consideration of multiple responses. Kazunori Fujiwara, JPRS OARC 28

Transcription

1 Evaluation and consideration of multiple responses Kazunori Fujiwara, JPRS OARC 28

2 Past discussion Background DNS is query response based protocol Each query contains one QNAME / QTYPE pair Recent applications request multiple DNS queries. For example, dual stack host (IPv4 and IPv6) requires both IPv4 address (type A) and IPv6 address (type AAAA) There have been many proposals to optimize the situation ( QDCOUNT > 1 ) New Query Type that queries both A and AAAA (similar to MAILB or ANY) New DNS protocol that carry multiple queries / responses Pre-populate resolver s cache Copyright 2018 Japan Registry Services Co., Ltd. 2

3 Recent multiple response proposals draft-vavrusa-dnsop-aaaa-for-free Additional AAAA in answer section draft-wkumari-dnsop-multiple-responses Pseudo RR controls additional RRs draft-fujiwara-dnsop-additional-answers Developers choose additional RRs (+NSEC*) draft-bellis-dnsext-multi-qtypes New EDNS option carries additional qtypes draft-yao-dnsop-accompanying-questions New EDNS option carries additional qnames, qtypes, rcodes Copyright 2018 Japan Registry Services Co., Ltd. 3

4 Recent multiple response proposals draft-vavrusa-dnsop-aaaa-for-free These Additional two drafts AAAA propose in answer new section DNS protocol that draft-wkumari-dnsop-multiple-responses carry multiple queries/responses in EDNS0 We Pseudo need RR to develop controls additional new resolvers RRs to evaluate Evaluation is not easy, not tested yet draft-fujiwara-dnsop-additional-answers Developers choose additional RRs (+NSEC*) draft-bellis-dnsext-multi-qtypes New EDNS option carries additional qtypes draft-yao-dnsop-accompanying-questions New EDNS option carries additional qnames, qtypes, rcodes Copyright 2018 Japan Registry Services Co., Ltd. 4

5 Recent multiple response proposals draft-vavrusa-dnsop-aaaa-for-free Additional AAAA in answer section draft-wkumari-dnsop-multiple-responses Pseudo RR controls additional RRs draft-fujiwara-dnsop-additional-answers Developers choose additional RRs (+NSEC*) draft-bellis-dnsext-multi-qtypes These 3 drafts propose additional RRs in responses Pre-populate New EDNS resolvers' option carries cache additional approach qtypes Query draft-yao-dnsop-accompanying-questions is not changed Authoritative New EDNS server option implementation carries additional is qnames, easy Can qtypes, evaluate rcodes current full-resolver implementations Copyright 2018 Japan Registry Services Co., Ltd. 5

6 draft-fujiwara-dnsop-additional-answers proposes adding NSEC in Responses RFC 8198: Aggressive Use of DNSSEC- Validated Cache RFC 8198 enabled NODATA response generation from cached matching NSEC v6.example. IN NSEC zz.example. AAAA RRSIG NSEC If the NSEC RR in the cache, resolvers can generate NODATA of v6.example. A immediately Copyright 2018 Japan Registry Services Co., Ltd. 6

7 Idea: Pre-populate resolvers' cache Full-service resolver 2. Query: AAAA root com Cache (Assumption#2 Accept?) 4. AAAA A? Assumption #1 Delay between queries 1. AAAA AAAA RR (some delay) 6. A A RR or NODATA example.com (patched auth. server) 3. Response: AAAA (Answer) A (Additional) or NSEC Copyright 2018 Japan Registry Services Co., Ltd. 7

8 Possible additional answer pairs Query: additional answer name A: name AAAA (answer section) name A: name AAAA (additional section) name A: name NSEC* (authority section) name AAAA: name A (additional section) name AAAA: name NSEC* (authority section) Existing case of current implementation name MX: mail_exchange A/AAAA (additional) name SRV: target_host A/AAAA (additional) Different QNAME scenario name A/AAAA: _443._tcp.name TLSA/NSEC* _443._tcp.name TLSA: name A/AAAA/NSEC* Copyright 2018 Japan Registry Services Co., Ltd. 8

9 the evaluation Full-service resolvers accept additional Resource Records? (To check assumption 2) Purpose of the evaluation To check easy deployment If existing resolvers accept additional RRs in responses, deployment is easy Updating authoritative server is easy To know implementation status of RFC 8198 Copyright 2018 Japan Registry Services Co., Ltd. 9

10 Authoritative server implementation NSD (4.1.19) is easy to read and patch Add a code at add_rrset() in nsd/query.c Always add A / AAAA / NSEC RRs add_rrset( ) {. switch (rrset_rrtype(rrset)) { case TYPE_A: rrset2 = domain_find_rrset(owner, query->zone, TYPE_AAAA); if (rrset2) { Or ANSWER_SECTION (aaaa for free) answer_add_rrset(answer, ADDITIONAL_A_SECTION, owner, rrset2); } else { answer_nodata(query, answer, owner); // add NSEC* (and SOA) } break; Copyright 2018 Japan Registry Services Co., Ltd. 10

11 Experiment authoritative servers Patched NSD ( ) appends A,AAAA in additional section, NSEC in authority section additonal.dnslab.jp and additional-nosec.dnslab.jp zones both.additional{,-nosec}.dnslab.jp has both A, AAAA (+NSEC) v6.additional{,-nosec}.dnslab.jp has AAAA only (+NSEC) v4.additional{,-nosec}.dnslab.jp has A only (+NSEC) Signed with NSEC (additional.dnslab.jp) Try drill -D -o both.additional.dnslab.jp A drill -D -o v4.additional.dnslab.jp A Patched NSD ( ) appends A,AAAA in answer section (aaaa-for-free scenario) answer-aaaa.dnslab.jp and answer-aaaa-nosec.dnslab.jp zones both.answer-aaaa{,-nosec}.dnslab.jp has both A,AAAA Try drill -D -o both.answer-aaaa.dnslab.jp A Copyright 2018 Japan Registry Services Co., Ltd. 11

12 Tested resolvers BIND BIND rc1 (v9_12 branch at March 6, 2018) Support RFC 8198 (NSEC) Knot Resolver Knot Resolver Supports RFC 8198 (NSEC) Unbound Unbound 1.7.0rc1 Supports RFC 8198 (NSEC): aggressive-nsec: yes PowerDNS Recursor Google Public DNS Copyright 2018 Japan Registry Services Co., Ltd. 12

13 Test result BIND 9, Google Public DNS don t accept/use all additional RRs (A, AAAA, NSEC) Unbound, Knot Resolver don t accept/use additional A, AAAA accept additional NSEC in authority section Knot resolver and Unbound 1.7.0rc1 generate NODATA using cached NSEC RR PowerDNS recursor does not accept/use A,AAAA in additional section accepts additional A,AAAA in answer section (with/without dnssec) Copyright 2018 Japan Registry Services Co., Ltd. 13

14 Reson of rejecting additional RRs Current full-service resolver implementations reject additional RRs because they avoid cache poisoning Recent full-service resolvers accept RRs that match query (QNAME, QTYPE) Even if additional RRs are DNSSEC signed Small/minimal response size is preferred Copyright 2018 Japan Registry Services Co., Ltd. 14

15 Summary Pre-populate resolvers' cache approach requires updating resolver software to accept additional RRs Written in Section Ranking Data of RFC 2181 and Section 8 of draft-wkumari-dnsopmultiple-responses-05 Knot resolver and Unbound 1.7.0rc1 accept additional NSEC RRs and generate NODATA responses (a half of additional-answer scenario) PowerDNS recursor accepts additional A/AAAA in answer section (aaaa-for-free scenario) Copyright 2018 Japan Registry Services Co., Ltd. 15

16 Next steps? My intent is to increase the effect of RFC 8198 Another (minimal) proposal maybe Aggressive append NSEC* by authoritative server Accept additional NSEC* by full-service resolver that support RFC 8198 Copyright 2018 Japan Registry Services Co., Ltd. 16