[DNSOP] Comment on Ranking data
dnsop WG, RFC 2181 Section 5.4.1 Ranking data should be obsoleted. The "Raning data" draft (draft-toorop-dnsop-ranking-dns-data-00) defines each data's ranking and importance. However, some of the data should be discarded depending on the use cases. We have four DNS functions: Authoritative, Recursive Resolver, Forwarder, Stub. Some implementations have multiple functions. For example, some recursive resolvers have "split-holizon" and "local zones" functions. Both "split-holizen" and "local zones" can be treated as a function where descendants of a specified domain name behave as an authoritative server rather than a recursive server. Authoritative (only) servers: Authoritative-only servers SHOULD answer zone data from a single source (for example, zone file, zone transfer, other database), so rankings SHOULD not be used to replace data. "BBB: Occluded data" SHOULD be discarded. (at least when responding to queries) Recursive (only) resolvers: They don't have "AAA: zone file" / "AA: Data from a zone transfer". "CCC: Names and addresses for the root servers from a hints file" or "CC: built into resolver software" SHOULD be used for the priming only. The data that can be returned to the stub resolver as a name resolution result is "A: The authoritative data included in the answer section of an authoritative reply" only. "A-: Data from the authority section of an authoritative answer." NXDOMAIN response contains a SOA RR in the autority section. Some authoritative servers add NS RRSet in the authority section. I want to discard the NS RR set. If you want it, send NS queries (as described in the ns-revalidation draft). "BB: Data from the answer section of a non-authoritative answer" discard it. "BB: non-authoritative data from the answer section of authoritative answers" discard it. "B: Additional information from an authoritative answer" If those data correspond to type MX, HTTPS/SVCB, or SRV responses, resolvers can decide based on local policy. "B: Data from the authority section of a non-authoritative answer, Additional information from non-authoritative answers." This is a referral response. A non-authoritative response from a server with administrative authority for a certain name that has NS RRSet in the authority section and Glue data in the additional section is a delegated response, and is used only for name resolution and not for responding to stub resolvers. The rank of the referral response is "A", I think. Any other response may be an attack and should be discarded. "AAA: all data that is verifiable DNSSEC secure regardless off were it came from" I don't like this rank. I like to use DNSSEC validation to decide whether to use "Additional information", but I don't like to blindly trust data that has been successfully validated. I believe many recursive resolver implementations have already discarded unnecessary responses. Stub resolvers: accept all responses from the recursive resolver. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Do we need new draft that recommends number limits ?
With DNS, there are several things to consider, such as the number and number of times that can complicate name resolution or cause DoS. For example, number of CNAME chains or number of chains of "unrelated" name server names are not limited. (Each implementations limit.) "KeyTrap" also seems to be caused by the configuration of a large number of DNSKEY RRs and RRSIG RRs in one domain name. For example, - Number of CNAME chains - Number of "unrelated" name server name resolutions (hard to write) - Number of NS RRs in each delegation - Number of RRs in one RRSet. - Number of RRSIG RRs in one RRSet - Number of DNSKEY RRs in one domain name DNSOP WG limitted NSEC3 Parameters in RFC 9276, beyond which DNSSEC validation was not required. Then, we can generate new recommendations that limit numbers and if it exceeds that limits, it might be a name resolution error or no validation. Rather than writing a draft for each limitation, I think it would be better to compile them all into one draft. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unrelated name server name recommendation
Thanks, Daune, > From: "Wessels, Duane" > I understood Fujiwara’s proposal to be slightly different: > > If you are a DNS provider (hosting other zones) then the provider should use > in-domain name servers. > DW This is what I would like to propose. I would like good texts. As Shumon pointed that many DNS providers offer in-domain name server names, however, there are many "unrelated" name server names in use. I know that many DNS hosting providers use in-domain name servers in their infrastructure. (For example, Amazon/AWS, Cloudflare, ...) -- Kazunori Fujiwara, JPRS >> On Mar 4, 2024, at 3:14 PM, Paul Wouters wrote: >> >> On Mar 4, 2024, at 14:04, Paul Vixie >> wrote: >>> >>> >>> >>> this means a zone will always be reachable through at least one in-zone >>> data path (name server name and associated address records.) the result >>> would be that a full resolver would never have to pause its current lookup >>> while searching for address records matching an out-of-zone name server >>> name. >>> >>> i think it's a solid recommendation, >> >> It means every registrant, who doesn’t know about DNS, has to create host >> objects for glue and whenever the ISP changes nameserver names (eg gets >> bought, sold or merges), or IP address, the ISP has to talk to the >> registrant to fix things at their registry. I can promise you those >> in-domain name servers will quickly become very unreliable. >> >> Paul >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://secure-web.cisco.com/1a3MNvrMgvJke3ozLjb1HCuRHhuKPU4kcf25J9eCUq4p-aOa0Aqy6qmiTdxMr02KJy3Ai80ZFNKl9j_c-7cA3MZpUD5480mMQT5pKWiSiUhWWeiTjjFCC6bZdqrh-FHCqvl1sM64AGrDIt4zjPKgcxERVilTSw7U3KPYhiGQ1IMY8wwa-dVkcU7s4T0z9flJabKEE7sH-IvWVC-Sv4i0fKZUk1g-ek5vkhx5JIA8TeMvtjP17WZaKrO79M9HpU6TNwB0ypkRbRMX8btrJZ9nSBar6W3gL2W4TKNRPrzyBFB8/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] unrelated name server name recommendation
dnsop WG, "unrelated" (or, previosly called as out-of-bailiwick) name server names are necessary for DNS hosting providers. However, it increases name resolution costs. Furthermore, it makes it easy to make mistakes like cyclic dependencies. So, I would like to make some recommendations on "unrelated" name server names. I submitted "draft-fujiwara-dnsop-unrelated-name-server-00" as a first step. https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-unrelated-name-server/ I prposed that the domain names that host the name server names MUST be resolvable by delegations using one or more in-domain name server names. I'm not able to write well, I'm looking for good text. Let's improve the current DNS before DELEG RR. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Martin Duke's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS and COMMENT)
I made a mistake in my previous mail. > From: Kazunori Fujiwara > Sorry for too late reply. > Authors submitted -17 today. > >> From: Martin Duke via Datatracker >> Date: Tue, 02 Jan 2024 11:44:09 -0800 > >> Martin Duke has entered the following ballot position for >> draft-ietf-dnsop-avoid-fragmentation-16: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to >> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ >> >> >> >> -- >> DISCUSS: >> -- >> >> 1) I'm unclear about Sec 4, R11 and Appendix B. When configured for minimal >> response, are responses to ALL requesters reduced in size, or only to those >> requesters that indicate a small MTU? >> >> As DNS becomes a more important vehicle for various discovery protocols (e.g. >> ECH), I would hate for responders to globally invoke a policy that makes it >> hard to deploy those protocols. But I'm happy to discuss this. > > When there is a data corresponding to the query, > each DNS response contains one RRSet that matches query (qname, qtype, qcalss) > in the authority section. (Section 4.3.2 of RFC 1034). ^ answer > If a domainname have multiple HTTPS/SVC RRs (that have complex ECH), > it is an RRSet. > > Many 'minimal-responses' implementations simply omit unnecessary RRs, > and the RRSet corresponding to the query responds as is. > > Some query types requires additional data in the additional section. > It is written in third paragraph of Appendix B. > > For example, > MX RR requests mail exchange's A/ into the additional section. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Martin Duke's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS and COMMENT)
Sorry for too late reply. Authors submitted -17 today. > From: Martin Duke via Datatracker > Date: Tue, 02 Jan 2024 11:44:09 -0800 > Martin Duke has entered the following ballot position for > draft-ietf-dnsop-avoid-fragmentation-16: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > > > -- > DISCUSS: > -- > > 1) I'm unclear about Sec 4, R11 and Appendix B. When configured for minimal > response, are responses to ALL requesters reduced in size, or only to those > requesters that indicate a small MTU? > > As DNS becomes a more important vehicle for various discovery protocols (e.g. > ECH), I would hate for responders to globally invoke a policy that makes it > hard to deploy those protocols. But I'm happy to discuss this. When there is a data corresponding to the query, each DNS response contains one RRSet that matches query (qname, qtype, qcalss) in the authority section. (Section 4.3.2 of RFC 1034). If a domainname have multiple HTTPS/SVC RRs (that have complex ECH), it is an RRSet. Many 'minimal-responses' implementations simply omit unnecessary RRs, and the RRSet corresponding to the query responds as is. Some query types requires additional data in the additional section. It is written in third paragraph of Appendix B. For example, MX RR requests mail exchange's A/ into the additional section. > 2) In section 3.2, R8, please add RFC 8961 as a normative reference for how to > set the timeout (e.g. "UDP requestors MUST observe [RFC8961] in setting their > timeout.") added (but, "SHOULD") > -- > COMMENT: > -- > > Thanks to Mirja Kuhlewind for the TSVART review, and to the authors for > responding. > > (1) I support Rob's DISCUSS (and Paul's comment) about SHOULD/MAY. "do it > unless the OS makes it impossible" is a typical use of SHOULD. Changed as "R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. > (2) Section 3.1, R1 says that responders SHOULD omit the fragment header. > Under > what circumstances would it be reasonable to keep it? Changed as "R1. UDP responders SHOULD NOT use IPv6 fragmentation [RFC8200]." -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-17.txt
Dear dnsop WG, Authours submitted avoid-fragmentation-17 following comments from IESG review. > Internet-Draft draft-ietf-dnsop-avoid-fragmentation-17.txt is now available. > It is a work item of the Domain Name System Operations (DNSOP) WG of the IETF. > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-avoid-fragmentation-17 Some recommendations have changed and will be introduced here. Authors intend to respond within the scope of discussions in the dnsop WG. R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. "MAY" was changed as "Where supported," + "SHOULD" R6. UDP requestors SHOULD drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. "MAY" was changed as "SHOULD" R7. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid resolution failures, UDP requestors SHOULD retry using TCP or UDP with a smaller EDNS requestor's maximum UDP payload size per local policy. UDP requestors SHOULD observe [RFC8961] in setting their timeout. "MAY" was changed as "SHOULD". However, all recent implementations do some retries. The details are left to the implementations. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DELEG and parent only resolution
I read draft-dnsop-deleg-00. It proposes new name resolution using only information on the parent side. In the past, the dnsop WG debated parent centric name resolution and child centric, and some people did not like parent centric. If people prefer parent-centric/parent-only name resolution, there are solutions other than DELEG, such as parent centric name resolution, distinguishing the handling of authoritative data, referrals, and glue, and adding a signature of referral/in-domain in the parent. Is anyone interested in proceeding with minor fixes that are not DELEG? Previously, I prposed draft-fujiwara-dnsop-resolver-update and draft-fujiwara-dnsop-delegation-information-signer. (They are too old and need to be updated.) Or, I would like to read complete version of draft-dnsop-deleg that have alpn and tlsa parameters. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dnsdir last call review of draft-ietf-dnsop-avoid-fragmentation-13
Thanks for Dnsdir review. Authors submitted -14. - fixed Acknowledgments section - added "Unbound" in "Known Implementations" section. (Thanks to Wouter Wijngaards) - Change recommendations from itemize to numbered The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-14 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dnsop-avoid-fragmentation-14 -- Kazunori Fujiwara, JPRS > From: Vladimír Čunát via Datatracker > Reviewer: Vladimír Čunát > Review result: Ready > > (assigned review) I re-read the whole text, and noticed nothing that I'd > consider wrong or missing. (I didn't review implementation section; except > Knot's is basically my text.) > > I think the current text is a quite nice reference for DNS fragmentation; I'm > not aware of anything close. IIRC I think the text has improved greatly over > the years. > > Nit which I've already posted somewhere: I don't expect the double thanks is > intentional? (not personal, Peter :-) > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-11.txt
Mukund-san, Thanks very much. I updated my local version. http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html -- Kazunori Fujiwara, JPRS > From: Mukund Sivaraman > Fujiwara-san, Vixie-san, > > On Thu, Jan 19, 2023 at 12:13:02AM -0800, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >> Title : Fragmentation Avoidance in DNS >> Authors : Kazunori Fujiwara >> Paul Vixie >> Filename: draft-ietf-dnsop-avoid-fragmentation-11.txt >> Pages : 10 >> Date: 2023-01-19 >> >> Abstract: >>EDNS0 enables a DNS server to send large responses using UDP and is >>widely deployed. Large DNS/UDP responses are fragmented, and IP >>fragmentation has exposed weaknesses in application protocols. It is >>possible to avoid IP fragmentation in DNS by limiting response size >>where possible, and signaling the need to upgrade from UDP to TCP >>transport where necessary. This document proposes techniques to >>avoid IP fragmentation in DNS. > > Is there still time to mention some editorial nits? If so, please see > the following; I am sorry I did not review the recent revision earlier. > > >> 1. Introduction > >>DNS has an EDNS0 [RFC6891] mechanism. It enables a DNS server to >>send large responses using UDP. EDNS0 is now widely deployed, and >>DNS (over UDP) relies on on IP fragmentation when the EDNS buffer > > I suggest removing the brackets around "(over UDP)", and fix the typo of > two "on"s: > > i.e, write it as "... and DNS over UDP relies on IP fragmentation..." > >>This document proposes that implementations set the "Don't Fragment >>(DF) bit" [RFC0791] on IPv4 and not using the "Fragment header" > > "... and not use the \"Fragment header\"..." > >>[RFC8200] on IPv6 in DNS/UDP messages in order to avoid IP >>fragmentation, and describes how to avoid packet losses due to DF bit > > "... fragmentation. It also describes..." > >> 2. Terminology > >>"Requestor" refers to the side that sends a request. "Responder" >>refers to an authoritative, recursive resolver or other DNS component > > "... to an authoritative server, recursive resolver or..." > >> 3. Proposal to avoid IP fragmentation in DNS > >>These recommendations are intended for nodes with global IP addresses >>on the Internet. Private networks or local networks are out of the >>scope of this document. > >>The methods to avoid IP fragmentation in DNS are described below: > >> 3.1. Recommendations for UDP responders > >>* UDP responders SHOULD send DNS responses without "Fragment header" >> [RFC8200] on IPv6. > >>* UDP responders are RECOMMENDED to set IP "Don't Fragment flag (DF) >> bit" [RFC0791] on IPv4. > > I suggest using the RFC 2119 term SHOULD here as well (synonymous with > RECOMMENDED), so that when reading the text, the recommendation doesn't > appear of a different severity from the other items. > > "UDP responders SHOULD set the IP \"Don't Fragment flag (DF)..." > >>* UDP responders SHOULD compose response packets that fit in both > > "both" implies 2, whereas there are 3 things suggested. I suggest > deleting the word "both" and keeping the rest of the text. > >> the offered requestor's maximum UDP payload size [RFC6891], the >> interface MTU, and the RECOMMENDED maximum DNS/UDP payload size >> 1400. > >>* If the UDP responder detects an immediate error that the UDP > > "... immediate error indicating that the..." > >> packet cannot be sent beyond the path MTU size (EMSGSIZE), the UDP >> responder MAY recreate response packets fit in path MTU size, or >> TC bit set. > > "... recreate response packets to fit in the path MTU size, or with the > TC bit set." > >>* UDP responders SHOULD limit response size when UDP responders are > > "... SHOULD limit the response size..." > >> located on small MTU (<1500) networks. > >> 3.2. Recommendations for UDP requestors > >>* UDP requestors SHOULD limit the reque
Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: PowerDNS
Thanks very much. I updated my local version. http://member.wide.ad.jp/~fujiwara/avoid-fragmentation.html -- Kazunori Fujiwara, JPRS > From: Peter van Dijk > PowerDNS Authoritative Server, PowerDNS Recursor, PowerDNS dnsdist: > > * IP_PMTUDISC_OMIT with fallback to IP_PMTUDISC_DONT > * default EDNS buffer size of 1232, no probing for smaller sizes > * no handling of EMSGSIZE > * Recursor: UDP timeouts do not cause a switch to TCP. "Spoofing > nearmisses" do. > > PowerDNS Authoritative Server: > > * the default DNSSEC algorithm is 13 > * responses are minimal, this is not configurable > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] rfc8499bis: lame
It may be too late, but the word "lame" may have a discriminatory meaning.
As a non-native English user, I ask the dictionaries.
For example, https://www.dictionary.com/browse/lame
The dictionary shows that lame" has four meanings:
"physically disabled", "injury", "weak",
Slang ("dull", "stupid" or "uninteresting").
In the discussions and previous usages of "lame delegation",
the "lame delegation" is not the perfect delegation.
We have the definition of "perfect"/"complete" delegation.
Then, other delegations are "inperfect"/"incomplete" delegation.
"lame" may have the discriminatory meaning.
Then, how about we stop using "lame delegation" and use terms like
"imperfect delegation" or "incomplete delegation" ?
For future discussion, the "imperfect"/"incomplete" delegation may be
classified.
--
Kazunori Fujiwara, JPRS
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] QDCOUNT > 1 (a modest proposal)
> From: Ted Lemon > Ohta-san, thanks for pointing out that text about the motivation for MX in > RFC1035―I hadn't noticed that. "DNS SRV RR" [RFC 2782] also mentions adding SRV RR Target A/ to the additional section. # draft-ietf-dnsop-svcb-https also mentions adding SVCB/HTTPS target A/ # to the additional section. In 2017, 2018, QDCOUNT>1 or multiple qtypes were discussed in dnsop WG. At the time, I proposed draft-fujiwara-dnsop-additional-answers-01 and compared 5 proposals. At the time, all proposals avoided QDCOUNT>1. -- Kazunori Fujiwara ( = fujiw...@jprs.co.jp ) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Implementor's status on draft-ietf-dnsop-avoid-fragmentation: Knot Resolver + Knot DNS
> From: Vladimír Čunát >> Use 'minimal-responses' configuration: > Nit: this formulation makes me wonder what this recommends for SVCB-like > records. Strictly taken I'd say it clashes with some SHOULDs from the > soon-to-be RFC. Either way, SVCB-like queries could be prone to generating > large answers (if this SHOULD is followed). Thanks. I agree. I think we need minimal-responses draft. It may differ between authoritative servers and full-service resolvers. also need to consider MX, CNAME, SVC, NAPTR, ... RRs. And "Appendix C. Minimal-responses" mentions glue, it might be better to remove the appendix or refer to glue-is-not-optional draft. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AD Review of: draft-ietf-dnsop-avoid-fragmentation
server operators" or perhaps "Suggestions for…" (it is unclear who is > "requesting" the change). fixed as "Recommendations for" > 4.1: "Notably, the signature size of ECDSA or EdDSA is smaller than RSA." > I think that this is better as "Notably, the signature sizes of ECDSA and > EdDSA are smaller than than those for RSA." fixed. (with s/than than/than/) > 5: Protocol compliance > O: "In prior research ([Fujiwara2018] and dns-operations mailing > list discussions), there are some authoritative …" > P: "Prior research ([Fujiwara2018] and dns-operations mailing > list discussions) has shown that some authoritative …" > C: I'm not really sure that "and dns-operations mailing list discussions" is a > useful citation. I think it might be better to either drop that, or provide > links to specific messages. If you do keep it, I think that you should at > least provide a reference to "dns-operations mailing list" ( perhaps > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ?). This is > especially important because it is easy for readers to get confused between > the DNS-OARC dns-operations list and the IETF DNS Operations WG mailing > list… Removed "dns-operations mailing list" and changed as "Prior research [Fujiwara2018] has shown that some authoritative servers ignore the EDNS0 requestor's maximum UDP payload size, and return large UDP responses." Add new text in Introduction for future update. NEW A path MTU different from the recommended value could be obtained from static configuration, or server routing hints, or some future discovery protocol; that would be the subject of a future specification and is beyond our scope here. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOP rfc8499bis Interim followup consensus on glue definition
> From: Benno Overeinder > Questions: > > 2. Definition of Glue provided by Duane Wessels on the DNSOP WG > mailing >list: > >"Glue is non-authoritative data in a zone that is transmitted in the >additional section of a referral response on the basis that the data >might be necessary for resolution to proceed at the referred name >servers." > >On the mailing list, we have seen a discussion about "necessary" >versus "useful". "in-domain" glue is necessary. "sibling" glue is not necessary. I don't like "useful". "sibling" glue is not really necessary. However, ".com" name resolution depends on "sibling" glue. from root-server's response com.172800 IN NS d.gtld-servers.net. d.gtld-servers.net. 172800 IN A 192.31.80.30 d.gtld-servers.net. 172800 IN 2001:500:856e::30 If this sibling glue does not exist, resovlers need to resolve d.gtld-servers.net A/ before sending example.com queries to d.gtld-servers.net. gtld-servers.net. 172800 IN NS av1.nstld.com. gtld-servers.net. 172800 IN NS av2.nstld.com. gtld-servers.net. 172800 IN NS av3.nstld.com. gtld-servers.net. 172800 IN NS av4.nstld.com. Then, without sibling glue, "gtld-servers.net" cannot be resolved So with the current configuration of "gtld-servers.net", sibling glue is also necessary. (I don't like) >In this context glue is defined to be exclusively >A/ records (traditional understanding), or do we also consider >other RRtypes to be glue, e.g. SCVB/HTTPS or DS records? Concern is >that "useful" may lead to a definition that is too broad. Section 4.2.1 of RFC 1034 shows that - Data that allows access to name servers for subzones (sometimes called "glue" data). "DS" RR is authoritative data. Then, it is not a glue. Address records attached with "SVCB/HTTPS" RR are considered the same as "MX" RRs. Section 4.1 of RFC1035: the additional records section contains RRs which relate to the query, but are not strictly answers for the question. Then, it is not glue. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] need update of RFC 3901 DNS IPv6 Transport Operational Guidelines
Dear RFC 3901 authors and dnsop WG, I would like to update RFC 3901 DNS IPv6 Transport Operational Guidelines. Now, IPv6 is now just as important as IPv4 and easy to use. Current RFC 3901 prefers IPv4. I would like to propose the following changes to RFC 3901 section 4. # Other sections may require some updates. When the following proposal will become a new BCP, and even if it is implemented in the world, it will not adversely affect name resolution of existing IPv4 only zones and IPv4 only recursive resolvers. # The recursive resolver that implement # draft-momoka-v6ops-ipv6-only-resolver-00 is a dual stack resolver. Title: DNS IPv6 Transport Operational Guidelines remove 4. DNS IPv6 Transport recommended Guidelines remove In order to preserve name space continuity, the following administrative policies are recommended: - every recursive name server SHOULD be either IPv4-only or dual stack,^^^ remove This rules out IPv6-only recursive servers. However, one might ^ IPv4-only or IPv6-only design configurations where a chain of IPv6-only name server ^ IPv4-only or IPv6 only forward queries to a set of dual stack recursive name server actually performing those recursive queries. - every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server. ^ add new text "and at least one IPv6-reachable authoriatative name server" This rules out DNS zones served only by IPv6-only authoritative name servers. ^add new test "or IPv4-only authoriatative name servers" Note: zone validation processes SHOULD ensure that there is at least one IPv4 address record available for the name servers of any child ^add new test "and at least one IPv6 address record" delegations within the zone. As a result, section 4 of RFC 3901 will be the following. New Title: DNS Transport Operational Guidelines 4. DNS Transport recommended Guidelines In order to preserve name space continuity, the following administrative policies are recommended: - every recursive name server SHOULD be dual stack. This rules out IPv4-only or IPv6-only recursive servers. However, one might design configurations where a chain of IPv4-only or IPv6 only name server forward queries to a set of dual stack recursive name server actually performing those recursive queries. - every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server and at least one IPv6-reachable authoriatative name server. This rules out DNS zones served only by IPv6-only authoritative name servers or IPv4-only authoriatative name servers. Note: zone validation processes SHOULD ensure that there are at least one IPv4 address record and at least one IPv6 address record available for the name servers of any child delegations within the zone. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
Abley-san, thanks very much for your comments. > From: Joe Abley > Fujiwara-san, > > On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote: > >> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and >> they often don't work as expected. >> >> However, it may be easy to avoid using the Fragment Header on IPv6. >> (limit IPv6 response packet smaller than interaface MTU.) >> (Or, is it not easy ?) > > I think it's easier if we just recommend a maximum message size for UDP > transport that is likely to avoid truncation in the majority of cases. > Perhaps that is the simplest formulation of your ultimate goal? Just update > the base specification and say it clearly. > > This will make UDP transport only usable for a subset of DNS messages that > are ever sent on the Internet. Other transports can remain as-is and do not > need this limitation. People who ignore the recommendation are on their own. The minimum MTU on IPv6 is 1280. Then, for example, we can specify a maximum message size for UDP transport on IPv6 as 1232. However, the minimum MTU on IPv4 is 68 (Section 3.2 of RFC 791). We need to arbitarily specify the maximum message size for UDP/IPv4. For example, 512, 1232, or 1400. > UDP then becomes a convenient choice for DNS messages that are small and that > do not have requirements for confidentiality, bit not a default choice in the > protocol sense (despite the fact that it will probably remain the choice for > most messages). > The default transport becomes TCP, since that is the alternative, > must-implement transport available in all parts of the system. We can say that the standard transports for DNS are TCP/DoT/DoQ and the standard address family is IPv6, however, UDP transport for DNS and IPv4 will be used in reality, forever. I believe that the BCP document improves many current use cases. >> Then, to allow larger than 1232/1400 and smaller than interface MTU >> response packets, recommendations for UDP requestors are changed as: >> >> UDP responders can send reponses fit in both >> the result of path MTU discovery (if available), >> interface MTU and UDP requestor's payload size. > > I think a formulation to avoid magic numbers is probably better but to be > honest I don't find magic numbers to be so terrible if they make the advice > more clear. > > (I think the current draft's advice is not particularly clear since it > contains a lot of > if then else, but perhaps others think differently.) >From EDNS spec [RFC6891], response size <= UDP requestor's payload size. as new recommendations, Set IP_DF bit on IPv4, Compose response packet fit in interface MTU -> No Fragment header on IPv6. then we don't need the result of path MTU discovery. > The DNS is used in private networks as well as on the Internet. I think it's > ok to say simply that UDP transport is NOT RECOMMENDED for large messages > since fragmentation SHOULD be assumed to be unavailable. I agree. On that case, TC=1 responses will return. > That leaves wriggle room for implementations who have more knowledge of their > network path or who don't care about delivery failures (for example) to do > their own thing. I don't think we should spend too much time imagining what > those things should be. > >>>> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. >>>>(many TCP implementations already set DF bit) >>> >>> I doubt we have control over this from the application. Is there even >>> API to control that on TCP sockets?m > > I don't think we should write as if UDP and TCP are the only transports > available. I also think it's a mistake to dive down into rabbit holes > relating to any particular transport other than UDP. I agree. But until draft-ietf-dprive-unilateral-probing will be published as a RFC, UDP and TCP are only transport to authoritative servers. > UDP is the only transport we have in which the DNS protocol needs to care > about message size. I think the current draft does a good job in restricting > its discussion to UDP. > >> At least, I would like to disable IPv6 fragmentation. >> and I would like to make "avoid IPv4 fragmetion" our goal. > > I think we should just be bold and declare a RECOMMENDED maximum message size > when using UDP transport and make TCP the default choice of transport. Minimal MTU size for IPv4 is 68. Then, 512 octet DNS response may be fragmented (without DF bit). > UDP becomes an acceptable alternative to TCP alongside other transports that > might be available, if suitable for a particular message, according to local > policy. > > The maximum that is specified could be a magic numb
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
> From: Petr Špaček >> Then, do you agree the following requirements ? (as DNS software >> developpers) >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4, >> and SHOULD not use FRAGMENT header on IPv6. > > Theoretically yes, but it might not be achievable depending on OS > API. We tried many iterations in BIND, and discovered that APIs (at > least in Linux) are horrible and there are traps everywhere. Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and they often don't work as expected. However, it may be easy to avoid using the Fragment Header on IPv6. (limit IPv6 response packet smaller than interaface MTU.) (Or, is it not easy ?) Then, do you agree "SHOULD not use FRAGMENT header on IPv6" ? On IPv4, I would like to write it in such a way that "setting the DF bit" is an goal, and that OS implementors and DNS server software developpers will do their best. (For example, UDP responders RECOMMENDED to set DF bit on IPv4.) However, from RFC 2119 keyword definitions, SHOULD==RECOMMENDED, and there may exist valid reasons to ignore a particular item. (When the OS does not have a function to set DF bit, it is a alid reason not to set DF bit.) | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there | may exist valid reasons in particular circumstances to ignore a | particular item, but the full implications must be understood and | carefully weighed before choosing a different course.a >> 2. limit DNS payload size 1232 without path MTU discovery. >> (After DNSFlagDay2020, many implementations use 1232) > > As Paul wrote down thread, it is random number - and so far it works > for us. OK, Then, Then, to allow larger than 1232/1400 and smaller than interface MTU response packets, recommendations for UDP requestors are changed as: UDP responders can send reponses fit in both the result of path MTU discovery (if available), interface MTU and UDP requestor's payload size. Recommendations for UDP requestors are changed as - remove "Don't Fragment" way. - UDP requestors SHOULD limit the requestor's payload size as 1400. [ UDP requestors MAY limit the requestor's payload size as 1232. 1232 is the IPv6 minimal MTU size minus IPv6 header size minus UDP header size. ] >> 3. If path MTU discovery works, UDP responders can send larger (>1232) >> responses fit in the path MTU. > > Possibly, but I think it is kind of moot advice without knowing how it > can be done. Right now there is no such thing as RFC 8899-equivalent > for DNS, so we don't even know if it would work for DNS as we know > it. Quick glance at RFC 8899 section 3 is not encouraging in that > regard, e.g. point 3, as a single example, shows that 8899 does not > match the current state of DNS (because auth does not get answer from > a resolver if the large response got through or not). Then, I would like to change as UDP requestors MAY perform "Path MTU discovery" per destination to use requestor's UDP payload size larger than 1400. Then, calculate their maximum DNS/UDP payload size as the reported path MTU minus IPv4/IPv6 header size (20 or 40) minus UDP header size (8). >> 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. >> (many TCP implementations already set DF bit) > > I doubt we have control over this from the application. Is there even > API to control that on TCP sockets? I agree. I leave it unwritten. >> # If there is a link whose MTU is smaller than 1260 (on IPv4), >> # the link may be a blackhole. > > Definitely. If the default is "too wrong" the whole thing falls apart. > > > I'm sorry for not being more informative. The only I know for certain > is that we had multiple iterations in BIND, are not happy with any of > them, and and it is order of magnitude more complex than we thought. At least, I would like to disable IPv6 fragmentation. and I would like to make "avoid IPv4 fragmetion" our goal. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
> From: Petr Špaček > On 15. 08. 22 12:18, Kazunori Fujiwara wrote: >> >>> I assume section 3.2 means the EDNS bufsize in the request when it >>> says >>> "their payload size", but I am not sure. The text could be clearer on >>> that. >>> >>>>* UDP requestors MAY probe to discover the real MTU value per >>>> destination. >>> How? >> For example, recent BIND 9 starts small EDNS requestors maxiumum >> DNS/UDP payload size (512), and increases gradually. > > Correction: > Recent BIND starts with EDNS buffer size 1232 bytes, and it does not > rise the value to "probe" the destination address by to "probe". > > FTR I'm testing on 9.19.5-dev commit b13d973, but I believe it is like > that for a long time already. THanks very much. commit bb990030d344dafe40a62fe5ed2741de28b8ca66 removed the probing heuristics. BIND 9.17.6 and later 5516. [func] The default EDNS buffer size has been changed from 4096 to 1232 bytes, the EDNS buffer size probing has been removed, and named now sets the DF (Don't Fragment) flag on outgoing UDP packets. [GL #2183] > I think the draft as it is currently does not have enough information > for implementers to be followed in safe way. > > > I'm against publication as it is. > > There should be running code, experiments, and measurements to back up > data in this draft. I can't see them at the moment. Then, do you agree the following requirements ? (as DNS software developpers) 1. SHOULD set DF bit on outgoing UDP packets on IPv4, and SHOULD not use FRAGMENT header on IPv6. 2. limit DNS payload size 1232 without path MTU discovery. (After DNSFlagDay2020, many implementations use 1232) 3. If path MTU discovery works, UDP responders can send larger (>1232) responses fit in the path MTU. 4. TCP implementations SHOULD set DF bit / not use FRAGMENT header. (many TCP implementations already set DF bit) # If there is a link whose MTU is smaller than 1260 (on IPv4), # the link may be a blackhole. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-08.txt
Dear dnsop WG, Thanks very muc for WGLC comments. Authors collected comments and updated the draft to -08. Please check whether your comments has been reflected and whether these updates are acceptable and sufficient. > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-08 Regards, -- Kazunori Fujiwara, JPRS > From: internet-dra...@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Fragmentation Avoidance in DNS > Authors : Kazunori Fujiwara > Paul Vixie > Filename: draft-ietf-dnsop-avoid-fragmentation-08.txt > Pages : 10 > Date: 2022-08-21 > > Abstract: >EDNS0 enables a DNS server to send large responses using UDP and is >widely deployed. Large DNS/UDP responses are fragmented, and IP >fragmentation has exposed weaknesses in application protocols. It is >possible to avoid IP fragmentation in DNS by limiting response size >where possible, and signaling the need to upgrade from UDP to TCP >transport where necessary. This document proposes to avoid IP >fragmentation in DNS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-08 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-08 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
> From: "Andrew McConachie" >> Path MTU discovery remains widely undeployed due to >>security issues, and IP fragmentation has exposed weaknesses in >>application protocols. > > PMTUD doesn’t work through NAT and that’s probably the main reason > why it doesn’t work on the Internet. I think that’s less of a > security issue than just a general issue with PMTUD not working on the > modern Internet. I will remove "Path MTU discovery remains widely undeployed due to security issues". because the text is only present in the abstract. >> Currently, DNS is known to be the largest >>user of IP fragmentation. And I will remove this line. because the text is only present in the abstract. > Compared to what? I would just drop this sentence because it doesn’t > add anything to the document and it’s trying to make a point that > doesn’t need to be made. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation
> From: Mukund Sivaraman > Subject: Re: [DNSOP] [Int-area] Please review > draft-ietf-dnsop-avoid-fragmentation > Date: Tue, 16 Aug 2022 10:58:04 +0530 > On Tue, Aug 16, 2022 at 01:07:34PM +0900, Kazunori Fujiwara wrote: >> Thanks very much for your review. >> >> > From: "to...@strayalpha.com" >> > Some comments: >> > IP fragmentation is controlled at both the system (as a default for all >> > new sockets) and per-socket level; this should >> > be discussed. >> > >> > I disagree with “MAY probe to find path MTU”; IMO, they SHOULD. >> >> I will consider changing to "SHOULD" at recommendations to UDP >> requestors (DNS clients). > > Some resolver implementations where possible turn off the effect of ICMP > v4 frag needed and v6 PTB messages to affect the kernel's PMTU cache (as > a blanket cover for possible vulnerabilities in this area). > > As an example, the resolvers in NIOS, BIND, Loop (all of which are BIND > or derived from BIND code) set the IP_PMTUDISC_OMIT and > IPV6_PMTUDISC_OMIT socket options to prevent how the Linux kernel uses > ICMP frag needed/PTB messages received over udp4/udp6 sockets > respectively to modify the PMTU for that peer. > > Would the SHOULD be satisfied by application layer fallback to smaller > advertised sizes (e.g., RFC 6891 section 6.2.5 fallback to lower > requestor payload sizes)? I meant "Yes". In section 2, "Path MTU discovery" | In this document, the term "Path MTU discovery" includes Classical | Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU | discovery [RFC8899] and as well as similar methods. One of the "similar methods" was supposed to be how BIND 9 chooses EDNS requestors payload size, starting with 512 and larger, per IP address. If you have good idea, please propose good text. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Int-area] Please review draft-ietf-dnsop-avoid-fragmentation
Thanks very much for your review. > From: "to...@strayalpha.com" > Some comments: > > The doc starts by grouping ICMP-based path MTU discovery (PMTUD) with in-band > discovery (PLPMTUD), but asserts (in the > first paragraph) that the group term “path MTU discovery” isn’t deployed due > to security concerns. I have seen no such > concerns about PLPMTUD - if you are aware of them, they should be cited. More > broadly, however, these two mechanisms > should NOT be lumped together. I will remove "Path MTU discovery remains widely undeployed due to security issues" from abstract. > IP fragmentation is controlled at both the system (as a default for all new > sockets) and per-socket level; this should > be discussed. > > I disagree with “MAY probe to find path MTU”; IMO, they SHOULD. I will consider changing to "SHOULD" at recommendations to UDP requestors (DNS clients). For UDP responders (DNS servers), I would like to remain "MAY". > Appendix C implies that there is a way to know the path MTU by direct > request. Unless this is verified with probes (as > in PLPMTUD), any value returned is at best a hint and could be incorrect. > This should be noted. > > It wouldn’t hurt (IMO) to point out the potential to use higher level > fragmentation that avoids the issues with IP > fragmentation. I’m not a DNS wonk but I’m surprised to see this doc imply > that there isn’t such a mechanism at the > application layer. Additionally, we are working on a mechanism at the UDP > layer (UDP options) that may be useful in > the future (not to recommend now, of course). I will consider removing Appenxding C. (and aosl D). -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation
> From: Peter van Dijk > Avoiding fragmentation is good. Putting that in a document is also good. > But this document is not ready for publication. It also most definitely > does not describe Best Current Practice; it also does not prescribe a > Best Current Practice I can agree with or even really implement. > > I'll call out a few specific problems below, but this list is not > complete. > > The (normative!) reference to RFC8900 is very vague. I will change informative reference to RFC8900. > The IP_DONTFRAG reference (well, not really a reference) is handwavy and > ill-defined. The discussion of socket options is also incomplete. (See > also: Petr's email) > (That said, the advice is good.) I would like to change IP_DONTFRAG/IPV6_DONTFRAG related description as follows. If there is a better text, please suggest. | 2.1 "Don't Fragment" way | | In this document, the term "Don't Fragment" way | implies | to set "Don't Fragment flag (DF) bit" [RFC0791] on IPv4 | and not to use "Fragment header" [RFC8200] on IPv6. | | How to set "Don't Fragment flag (DF) bit" on IPv4 varies between | implementations, IP_DONTFRAG option is used on BSD systems to set | the Don't Fragment bit. On Linux systems this is done via | IP_MTU_DISCOVER and IP_PMTUDISC_DO. | | The way without "Fragment header" on IPv6 varies between | implementations. On BSD systems, use IPV6_DONTFRAG socket option | defined in [RFC3542]. | | 3.1. Recommendations for UDP responders - * UDP responders SHOULD send DNS responses with IP_DONTFRAG / - IPV6_DONTFRAG [RFC3542] options. + * UDP requestors SHOULD send DNS requests with "Don't Fragment" way. >> * UDP responders MAY probe to discover the real MTU value per >> destination. > > I have no clue how a responder would do this. If I'm wrong, and this is > possible at all, the document should explain how this would be done. The third and forth paragraphs may be merged, I think. > I assume section 3.2 means the EDNS bufsize in the request when it says > "their payload size", but I am not sure. The text could be clearer on > that. > >> * UDP requestors MAY probe to discover the real MTU value per >> destination. > > How? For example, recent BIND 9 starts small EDNS requestors maxiumum DNS/UDP payload size (512), and increases gradually. Do you have good text ? >> To avoid name resolution fails, UDP requestors need to retry using >> TCP, or UDP with smaller maximum DNS/UDP payload size. > > This lacks 2119/8174 keywords. "need" sounds like SHOULD or MUST, but I > do not think this behaviour should be mandated of implementations. > Several resolver implementations currently do none of this, and they work > fine on the existing Internet. We should not be adding code compensating > for potential breakage we can imagine. So, I suggest this would at most > be a MAY, or a lowercase "can retry using ...". Ok, change to "MAY". >>The proposed method supports incremental deployment. > > In its current shape, this document does not really propose a method for > anything. If the document gets updated to provide implementable advice, > it should get an Implementation Status section. Thanks. Section 4 Incremental deployment may be removed. -- Kazunori Fujiwara, JPRS > Section 5 is solid advice. > > I also agree with the full text of Petr's response. > > Kind regards, > -- > Peter van Dijk > PowerDNS.COM BV - https://www.powerdns.com/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Please review draft-ietf-dnsop-avoid-fragmentation
Dear intarea WG, dnsop WG is working on a document to avoid IP fragmentation in DNS. Now, the draft is on Working Group Last call in dnsop WG (until August 16). The draft attempt to advance the goals of RFC 8900 IP Fragmentation Considered Fragile. (Section 5.1 Domain Name System (DNS)) As one of the co-authors of the draft, I would like advices from intarea because there may be inadequate descriptions related to path MTU discovery and DF bit / IPV6_DONTFRAG. Fragmentation Avoidance in DNS https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ (1) About DF bit, IPV6DONTFRAG | 1. Introduction | | This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP | messages in order to avoid IP fragmentation, and describes how to | avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG. | 2. Terminology | | IP_DONTFRAG option is not defined by any RFCs. It is similar to | IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is | used on BSD systems to set the Don't Fragment bit [RFC0791] when | sending IPv4 packets. On Linux systems this is done via | IP_MTU_DISCOVER and IP_PMTUDISC_DO. | 3.1. Recommendations for UDP responders | | * UDP responders SHOULD send DNS responses with IP_DONTFRAG / | IPV6_DONTFRAG [RFC3542] options. (2) about path MTU discovery | 2. Terminology | | "Path MTU" is the minimum link MTU of all the links in a path between | a source node and a destination node. (Quoted from [RFC8201]) | | In this document, the term "Path MTU discovery" includes Classical | Path MTU discovery [RFC1191], [RFC8201], Packetization Layer Path MTU | discovery [RFC8899] and as well as similar methods. | 3.2. Recommendations for UDP requestors | | * UDP requestors MAY probe to discover the real MTU value per | destination. (Path MTU discovery per destionation) Then, | calculate their maximum DNS/UDP payload size as the reported path | MTU minus IPv4/IPv6 header size (20 or 40) minus UDP header size | (8). If the path MTU discovery failed or is impossible, use the | default maximum DNS/UDP payload size 1400. Regards -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-07.txt
dnsop WG; Authors updated draft-ietf-dnsop-avoid-fragmentation. Please review current verion. > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-07 There is no good static maximum DNS/UDP payload size. We removed complicated Default Maximum DNS/UDP payload size discussions and set the value as 1400. However, when a UDP responder with a path MTU smaller than 1428/1448 octets sends a query with a maximum UDP payload size 1400 and the UDP responder generates a response of 1400 octets (with IP_DF), the response packet drops on the path and the resoponder cannot get the response. In the previous version, the behavior at the timeout depends on implementations. We don't want the name resolution failure caused by this BCP document, so, we added the new text "To avoid name resolution fails, UDP requestors need to retry using TCP, or UDP with smaller maximum DNS/UDP payload size." I would like agreements on the following. - Default Maximum DNS/UDP payload size: choices are 1400, 1232 or others - Need static configuration parameters at authoritative, recursive resolvers, stub rsolvers ? Regards, -- Kazunori Fujiwara, JPRS > From: internet-dra...@ietf.org > Subject: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-07.txt > Date: Sun, 03 Jul 2022 19:30:54 -0700 > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Fragmentation Avoidance in DNS > Authors : Kazunori Fujiwara > Paul Vixie > Filename: draft-ietf-dnsop-avoid-fragmentation-07.txt > Pages : 11 > Date: 2022-07-03 > > Abstract: >EDNS0 enables a DNS server to send large responses using UDP and is >widely deployed. Path MTU discovery remains widely undeployed due to >security issues, and IP fragmentation has exposed weaknesses in >application protocols. Currently, DNS is known to be the largest >user of IP fragmentation. It is possible to avoid IP fragmentation >in DNS by limiting response size where possible, and signaling the >need to upgrade from UDP to TCP transport where necessary. This >document proposes to avoid IP fragmentation in DNS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-07 > > > Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS glue for NS draft
Hello, I read draft-dickson-dnsop-ds-hack-00 and it proposes that - it assign three new DNSKEY algorithms (alg_ns, alg_A, alg_) - it generate 3 new DS RRs for all parent side NS RR and glue (A/) It will increase DS reponse 48bytes * 3 = 144 bytes. (in case of digest type 2) owner IN DS 0 alg_NS digest hash_of(caonnical_order(NS RRset)) owner IN DS 0 alg_A digest hash_of(caonnical_order(glue A)) owner IN DS 0 alg_ digest hash_of(caonnical_order(glue )) Please add such examples. The caonical ordering is defined in RFC 4034 and your draft depends on draft-ietf-dnsop-glue-is-not-optional. Please add them as references. I proposed similar idea "Delegation Information (Referrals) Signer for DNSSEC" at IETF 109 dnsop WG and it was not preferred at the time. See: https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer-00 My idea generates one DS resource record for each delegation point. Signer and verifier generates complete NS RRset and glue set, reorder canonical order, and calculate hash. owner IN DS ? new_alg? new_digest? hash_of(caonnical_order(NS RRset)|canonical_order(glue RRset)) -- Kazunori Fujiwara, JPRS > From: Brian Dickson > This is the work I will be submitting in DNSOP. > > This is what has been described as a “hack”, but provides a needed validation > link for authoritative servers where the latter are in signed zones, but where > the served zones may not be signed. > > NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently. > > It will likely be the case that those overlaps need to be reconciled, based on > use cases and scope. > > I think there are valuable use cases other than privacy, which would make this > more appropriate for DNSOP. > > Comments are welcome. > > The draft can be found at: > > https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt > > Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-avoid-fragmentation-05
Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-05. Please review it. https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-05 https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-05 Major changes are the following: 1. Moved some text from Introduction to Appendix A. Weaknesses of IP fragmentation. 2. Section 3.3 Default Maximum DNS/UDP payload size Generated Table 1 Default maximum DNS/UDP payload size 1400 as "Authors' recommendation". Moved details to Appendix B. Details of maximum DNS/UDP payload size discussions. Changed texts about " operators of DNS servers SHOULD measure their path MTU to UDP payload size. the Internet at setting up DNS servers" 3. added "IP_DONTFRAG option" definition in Terminology section. IP_DONTFRAG option is not defined by any RFCs. It is similar to IPV6_DONTFRAG option defined in [RFC3542]. IP_DONTFRAG option is used on BSD systems to set the Don't Fragment bit [RFC0791] when sending IPv4 packets. On Linux systems this is done via IP_MTU_DISCOVER and IP_PMTUDISC_DO. # IP_DONTFRAG is a macro used in BSD socket API. # IPV6_DONTFRAG is defined by RFC 3452, but it is BSD's IPv6 API. # Then, # We may need to change "IP_DONTFRAG" to "DF" bit. ([RFC0791]) # We may need to change "IPV6_DONTFRAG" to "Sending without Fragmentation". # (Good texts required.) # IPv6 experts, please advice. 4. Appendix sections reordered. Appendix A. Weaknesses of IP fragmentation Appendix B. Details of maximum DNS/UDP payload size discussions Appendix C. How to retrieve path MTU value to a destination from applications Appendix D. How to retrieve minimal MTU value to a destination Appendix E. Minimal-responses 5. Added some names in Acknowledgeent section -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Suggestion related to draft-ietf-dnsop-avoid-fragmentation
> The short version is, the client requests a packet from the resolver, which > is exactly the > size of the MTU. This means the resolver returns a response which is padded > with data, so that the DNS payload size > matches the maximum size allowed per EDNS0 rules: the minimum of the > configured value on the resolver, and the > requested value from the EDNS0 BUFSIZE value. Do you mean that each stub resolver discovers path MTU to a full-service resolver with new method ? If we add aggressive path MTU discovery, we should use RFC 8899 specifies Packetization Layer Path MTU Discovery for Datagram Transports. However, changing stub resolvers is hard. Currently, most of stub resolvers don't use EDNS0 and don't set DO bit. Then, fragmentation does not happen. Software developpers of validating stub resolvers are limited. They know DNS protocol well and limit default DNS/UDP payload size 1232 or other smaller value. When full-service resolvers support this draft, changing stub resolvers are not necessary, I think. -- Kazunori Fujiwara, JPRS > From: Brian Dickson > In my comments regarding section 3.3 of the > draft-ietf-dnsop-avoid-fragmentation, > I alluded to the need for a method of validating a configured DNS UDP default > MTU value, > when a client is starting up, and has been configured to use one or more > resolvers. This test would be performed > towards each resolver, as appropriate. > > If this idea is received with support, I'll write it up. It is quite simple, > I believe, and should > be easy to implement. > > The short version is, the client requests a packet from the resolver, which > is exactly the > size of the MTU. This means the resolver returns a response which is padded > with data, so that the DNS payload size > matches the maximum size allowed per EDNS0 rules: the minimum of the > configured value on the resolver, and the > requested value from the EDNS0 BUFSIZE value. > > The suggested record name, class, type is "lorem.ipsum" CH TXT. > The value would be padded with repeated instances of the canonical "lorem > ipsum" text, > in TXT record format, truncated to the correct length to match the > requirements. > (While "quick brown fox" might be similarly suitable, it is frequently used > by test sets, and its presence as payload > might cause confusion and errors.) > > The resolver would set the DF bit, and if the response is not received, the > client would need to react accordingly. > E.g retry, reduce size, iterate until a response is received. > > Feedback on this idea is welcome. > > Thanks, > Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Introduction section of draft-ietf-dnsop-avoid-fragmentation
Thanks very much. I will refer to your suggestions and try to shorten the introduction section. -- Kazunori Fujiwara, JPRS > From: Brian Dickson > Fujiwara-san, > > I have a suggestion on tweaking the wording of Section 1, Introduction. > The intent is to simplify it a bit. Feel free to ignore this if it doesn't > work, > or use whatever parts of it you feel are useful. > > DNS has EDNS0 [RFC6891] mechanism. It enables a DNS server to send > large responses using UDP. EDNS0 is now widely deployed, and DNS > (over UDP) is said to be the biggest source of IP fragments. > > Fragmented DNS UDP responses have systemic weaknesses, which expose > the requestor to DNS cache poisoning from off-path attackers. (See appendix > for references and details.) The primary weakness is the UDP checksum itself, > and the fact that the UDP header and DNS header will be in the first fragment > only. > In addition, the IPv4 fragmentation and reassembly relies solely on the IPv4 > ID, > a 16-bit value which is weak enough to permit feasible brute force attacks. > > UDP has no inherent ability to react to ICMP messages that would otherwise > alert > the sender to dropped packets with DF=1, due to MTU being exceeded. > Additionally, fragmentation can adversely affect TCP performance, thus the > same logic > is applicable to both UDP and TCP. Fragmentation SHOULD be avoided. > > This document proposes to set IP_DONTFRAG / IPV6_DONTFRAG in DNS/UDP > messages in order to avoid IP fragmentation, and describes how to > avoid packet losses due to IP_DONTFRAG / IPV6_DONTFRAG. > > (Place the rest of the original introduction text and references into an > Appendix.) > > Feedback concerning this suggestion is welcome. > > Sincerely, > Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation
Dear DNSOP participants, Thanks very much for good comments for draft-ietf-dnsop-avoid-fragmentation. These are my proposal of Section 3.3. Default Maximum DNS/UDP payload size. I'm not sure what to do with "MAY, "SHOULD", or "MUST", so please give us your opinion. If it is acceptable, I will submit -05. --- 3.3. Default Maximum DNS/UDP payload size Default maximum DNS/UDP payload size depends on the connectivity of each node, it cannot be determined unconditinally. However, there are good proposed values. Operators MAY select a good number from Table 1. ++==+==+ | Source | IPv4 | IPv6 | ++==+==+ | minimal: RFC 4035 | 1220 | 1220 | ++--+--+ | Software developpers / | 1232 | 1232 | | DNSFlagDay2020 propose | | | ++--+--+ | This document proposes | 1400 | 1400 | ++--+--+ | maximum: ethernet MTU | 1472 | 1452 | | 1500 | | | ++--+--+ | calculate | MTU-20-8 | MTU-40-8 | ++--+--+ Table 1: Default maximum DNS/UDP payload size However, operators of DNS servers SHOULD measure their path MTU to well-known locations on the Internet, such as [a-m].root-servers.net or [a-m].gtld-servers.net at setting up the servers. The smallest value of path MTU is the server's path MTU to the Internet. The server's maximum DNS/UDP payload size SHOULD be smaller than or equal to the reported path MTU minus IPv4/IPv6 header size (20/40) minus UDP header size (8). Details of default maximum DNS/UDP payload size is Appendix C. ----- -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-ietf-dnsop-avoid-fragmentation-04.txt
Dear DNSOP WG, Paul Vixue and I submitted draft-ietf-dnsop-avoid-fragmentation-04.txt . https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-04 We changed to use "default maximum DNS/UDP payload size" instead of "default path MTU value". Please review current version and choose good "Default Maximum DNS/UDP payload size". Default maximum DNS/UDP payload size for IPv6 is . (Choose 1232, 1400, 1472 or other good values before/at WGLC) Default maximum DNS/UDP payload size for IPv4 is . (Choose 1232, 1400, 1452 or other good values before/at WGLC) Regards, -- Kazunori Fujiwara, JPRS > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Fragmentation Avoidance in DNS > Authors : Kazunori Fujiwara > Paul Vixie > Filename: draft-ietf-dnsop-avoid-fragmentation-04.txt > Pages : 11 > Date: 2021-02-22 > > Abstract: >EDNS0 enables a DNS server to send large responses using UDP and is >widely deployed. Path MTU discovery remains widely undeployed due to >security issues, and IP fragmentation has exposed weaknesses in >application protocols. Currently, DNS is known to be the largest >user of IP fragmentation. It is possible to avoid IP fragmentation >in DNS by limiting response size where possible, and signaling the >need to upgrade from UDP to TCP transport where necessary. This >document proposes to avoid IP fragmentation in DNS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-04 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews > DNS is loosely coherent. DiS does not work when the sources of data are not > coherent. Do you mean that the glue is not uniquely determined because the authoritative server merges multiple zone information or the data cached by the resolver part of the DNS server ? > From: Mark Andrews >> I have a question why we did not include signature validation function >> to delegation information ? > > Delegating NS records because the zone would become big and people didn’t > want to have TLD zones have signatures for each delegation. In case of TLDs with many signed (with DS) delegations, the increase of DiS RR is not a problem because DiS is a part of DS RRSet. > We could sign > delegating NS records as you can determine delegating vs top of zone by > looking at the signer field of the NS RRset. You would then have to deal > with the case where you have signed parent and unsigned child and a referral > to the grand child. Do you mean that digest calculation is difficult because RRSets with the same name come from servers in multiple layers and are mixed? > You would have to stop following the referral, verify > the child is unsigned, then restart following the referral. This is a lot > of work for very little benefit. many domains are 3 layered. root: signed (with signed referrals) TLD: signed (with signed referrals) example.com: unsigned (no referral) Then, example.com can't be validated, but at least it's nice to know that the referral from the TLD is correct? > Glue records would need a different signature type and would need to compute > the signature differently to prevent it being used in a replay attack when > the RRset differ. I would like to read such draft (idea). > I suppose you could use the same algorithm as it would > encourage people to keep data coherent. You would still have the parent, > child, grandchild issues from above. If they don't share authoritative servers, referrals (NS RRSet and glue) are uniquely determined. >> And the idea may offer the signature for root priming data. > > It can’t. There is no requirement for addresses records for nameservers > for a zone to exist in the zone, as glue or not, even if the nameservers > are below top of zone. Glue is only required for delegations. Yes. I agree. It's another discussion. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: RFC8499-bis
> From: Tony Finch > I recently noticed that the bailiwick-related definitions are wrong and > muddled. > > I have always understood in-bailiwick to mean that a nameserver name is a > subdomain of its zone apex. That is, exactly the cases where glue is > required by the DNS protocol. The term comes from the discussion of > gluelessness at http://cr.yp.to/djbdns/notes.html - "RFC 1034 specifically > requires glue for referrals to in-bailiwick DNS servers." > > RFC 8499 seems to use "in-domain" for this situation Yes. Before RFC 8499, "in-bailiwick" had two meanings. in-bailiwick to mean that a nameserver name is a subdomain of its zone apex. and "in-domain" http://cr.yp.to/djbdns/notes.html >, which is not a term > I have seen anywhere else. Yes. I borrowed the words "in-domain" and "sibling" from draft-koch-dns-glue-clarifications. (submitted in 2010, draft only) There are no "in-bailiwick" and "out-of-bailiwick" definitions before RFC 7719. We need four types of glue names. In RFC 8499, "out-of-bailiwick", "in-bailiwick", "in-domain", "sibling". Please propose new names. # And I missed a term related to domain name: Occluded Name [(RFC6936]. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews >>> One problem with DiS is that assumes that address records in the additional >>> section *always* come from the delegating zone (see how the hash is >>> created). >>> This is not how DNS works. Address records can, correctly, come from other >>> sources, even when the name is *below* the zone cut. >>> >>> Take a server that serves example.net and sub.child.example.net. That A >>> record >>> comes from sub.child.example.net not example.net when the name of the >>> server is >>> a.sub.example.net. >>> >>> child.example.net NS a.sub.example.net >>> a.sub.example.net A 1.2.3.4 > I ment > child.example.net NS a.sub.child.example.net > a.sub.child.example.net A 1.2.3.4 > > (which should have been obvious from the paragraph above) Do you mean these 2 lines in example.net zone ? > child.example.net NS a.sub.child.example.net > a.sub.child.example.net A 1.2.3.4 Then, we can generate DiS RR. hash ( child.example.net NS | a.sub.child.example.net A). DNSSEC validators can get both "child.example.net NS a.sub.child.example.net" and glue "a.sub.child.example.net A 1.2.3.4", and validate child.example.net DiS RR. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews > One problem with DiS is that assumes that address records in the additional > section *always* come from the delegating zone (see how the hash is created). > This is not how DNS works. Address records can, correctly, come from other > sources, even when the name is *below* the zone cut. > > Take a server that serves example.net and sub.child.example.net. That A > record > comes from sub.child.example.net not example.net when the name of the server > is > a.sub.example.net. > > child.example.net NS a.sub.example.net > a.sub.example.net A 1.2.3.4 > > Mark "a.sub.example.net" is not a "in-domain" glue. (it is "sibling" glue). Then, DiS RR for child.example.net will be generated from "child.example.net NS a.sub.example.net". Authoritative server of "child.example.net" responds child.example.net NS a.sub.example.net in authority section with/without a.sub.example.net A 1.2.3.4 as a glue in additional section. Sibling glue "a.sub.example.net A 1.2.3.4" is not a target of DiS RR for "child.example.net NS". Validator can validate "child.example.net NS a.sub.example.net". Validating resolver can accept the sibling glue "a.sub.example.net A 1.2.3.4". Or, validating resolver may reject the sibling glue "a.sub.example.net A 1.2.3.4", and treat it similar to out-of-bailing domain name, then, resolve "a.sub.example.net" A/ from root (or child.exapmle.net). Then I think the idea works. -- Kazunori Fujiwara, JPRS >> On 4 Nov 2020, at 15:31, fujiw...@jprs.co.jp wrote: >> >> I submitted draft-fujiwara-dnsop-delegation-information-signer-00. >> >> Name:draft-fujiwara-dnsop-delegation-information-signer >> Revision:00 >> Title: Delegation Information (Referrals) Signer for DNSSEC >> Document date: 2020-11-03 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt >> >> DNSSEC does not have a function to validate delegation information. >> I think it is a large missing peace of DNSSEC. >> >> I have a question why we did not include signature validation function >> to delegation information ? >> >> Probably, because it is non-authoritative information. >> Or, because it was difficult to define the necessary and sufficient >> delegation information. >> >> It is now widely agreed (although not explicitly documented) that the >> delegation information is the information used for name resolution and >> does not result in name resolution. >> >> We have a word "in-domain" glue which is the necessary and sufficient glue. >> >> And the idea may offer the signature for root priming data. >> >> If someone interested the document, I would like time slot at dnsop WG >> meeting. >> >> Regards, >> >> -- >> Kazunori Fujiwara, JPRS >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Bob Harold > If an attacker is spoofing responses, it seems that they could send a > different NS and A record, and a new calculated DS hash. So this provides > no protection against spoofing? > > We would need instead (or in addition) an RRSIG record to actually protect > this. Thanks for reading the draft. I'm assuming that DiS RR is treated as the DS RR, so if the parent side is signed, DS (+DiS) RRSet will be signed. > An example would help. Yes. I will add examples in next version. example.com.IN NS ns.example.com. ns.example.com. IN A 2001:dc8::53 example.com.IN DS 12345 8 2 (hash of DNSKEY RR) example.com.IN DS 0 0 100 (hash of (example.com IN NS | ns.example.com IN )) example.com.IN RRSIG DS (signature of DS RRSet (2 DSes)) DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR). -- Kazunori Fujiwara, JPRS > -- > Bob Harold > DNS and DHCP Hostmaster - UMNet > Information and Technology Services (ITS) > rharo...@umich.edu 734-512-7038 > > > On Tue, Nov 3, 2020 at 11:31 PM wrote: > >> I submitted draft-fujiwara-dnsop-delegation-information-signer-00. >> >> Name: draft-fujiwara-dnsop-delegation-information-signer >> Revision: 00 >> Title: Delegation Information (Referrals) Signer for DNSSEC >> Document date: 2020-11-03 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt >> >> DNSSEC does not have a function to validate delegation information. >> I think it is a large missing peace of DNSSEC. >> >> I have a question why we did not include signature validation function >> to delegation information ? >> >> Probably, because it is non-authoritative information. >> Or, because it was difficult to define the necessary and sufficient >> delegation information. >> >> It is now widely agreed (although not explicitly documented) that the >> delegation information is the information used for name resolution and >> does not result in name resolution. >> >> We have a word "in-domain" glue which is the necessary and sufficient glue. >> >> And the idea may offer the signature for root priming data. >> >> If someone interested the document, I would like time slot at dnsop WG >> meeting. >> >> Regards, >> >> -- >> Kazunori Fujiwara, JPRS >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-delegation-information-signer
I submitted draft-fujiwara-dnsop-delegation-information-signer-00. Name: draft-fujiwara-dnsop-delegation-information-signer Revision: 00 Title: Delegation Information (Referrals) Signer for DNSSEC Document date: 2020-11-03 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt DNSSEC does not have a function to validate delegation information. I think it is a large missing peace of DNSSEC. I have a question why we did not include signature validation function to delegation information ? Probably, because it is non-authoritative information. Or, because it was difficult to define the necessary and sufficient delegation information. It is now widely agreed (although not explicitly documented) that the delegation information is the information used for name resolution and does not result in name resolution. We have a word "in-domain" glue which is the necessary and sufficient glue. And the idea may offer the signature for root priming data. If someone interested the document, I would like time slot at dnsop WG meeting. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-02.txt
Hello. We submitted draft-ietf-dnsop-avoid-fragmentation-02. Authors simplified recommendations. Main recommendations are setting IP_DONTFRAG / IPV6_DONTFRAG options and compose DNS packets fit in path MTU. Then, DNS UDP responses are fragmentation free. If people want to use large packet size (with path MTU discovery), they need to calculate EDNS0 size from path MTU size. However, many people wants static recommendaton value for EDNS0 size. I'm wondering if it's better to write a recommended MTU value or a recommended EDNS0 size. -- Kazunori Fujiwara, JPRS > From: internet-dra...@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Fragmentation Avoidance in DNS > Authors : Kazunori Fujiwara > Paul Vixie > Filename: draft-ietf-dnsop-avoid-fragmentation-02.txt > Pages : 10 > Date: 2020-09-15 > > Abstract: >EDNS0 enables a DNS server to send large responses using UDP and is >widely deployed. Path MTU discovery remains widely undeployed due to >security issues, and IP fragmentation has exposed weaknesses in >application protocols. Currently, DNS is known to be the largest >user of IP fragmentation. It is possible to avoid IP fragmentation >in DNS by limiting response size where possible, and signaling the >need to upgrade from UDP to TCP transport where necessary. This >document proposes to avoid IP fragmentation in DNS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-02 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-avoid-fragmentation-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-01.txt
> From: Tony Finch > I've had a look through and I have a few comments. Thanks. > Regarding smallest MTUs, I understand from Geoff Huston that it's common > for IPv6 breakage to start at 1281 bytes. Then, without path MTU discovery, IPv6 default path MTU value should equal to the IPv6 minimum link MTU size 1280. How about IPv4 ? > I would find it easier to understand the recommendations if the > requirements for responder and requester were separated. In particular I > don't know how a responder can do MTU discovery (though a simplified > version might be possible). Then, separate real recommendations to "3.1 Recommendations for UDP requestors" and "3.2 Recommendations for UDP responders". > Here's my understanding of your recommendations: > > Requester: > > * should have a default EDNS buffer size no more than 1500 bytes (smaller > than the 4096 that is currently typical, but bigger than the flag day > recommendation) > > * should probe to discover the real MTU per destination, which can be less > than the default, and use the discovered MTU for the EDNS buffer size in > queries (resolvers already do this) In my opinion, if path MTU discovery to works, then use the value (minus header sizes) as Requestor's Payload Size in EDNS0. Otherwise, use "good" default EDNS buffer size (for example, 1232). > * at the moment UDP timeouts don't cause fallback to TCP, but this should > be added to the list of recovery tactics > > * requesters are supposed to guess (how?) the size of response before > sending a query, so that they can skip UDP and go straight to TCP If requestors set good EDNS Requestor's Payload size, responders can set TC bit if response size exceeds the EDNS0 size. (Otherwise, fragmented responses may lose.) > * should set the DONTFRAG option, though it's unlikely they are sending > a query big enough for this to matter. (UPDATE clients need to care, > though.) > > Responder: > > * should have a default UDP response size limit of no more than 1500 bytes > (smaller than the 4096 that is currently typical, but bigger than the > flag day recommendation) To avoid packet loss caused by IP_DONTFRAG, if responders know real path MTU value, responders compose packets fit in the path MTU. Otherwise, at least, IP_DONTFRAG works well. I think that most of DNS servers are located at 1500-octets MTU area. > * should limit response sizes by based on the minimum of the request's > EDNS buffer size and the server's limit (servers already do this) If operators of DNS servers know that the network does not support 1500-octet MTU, operators should consider good UDP response size limit. > * should use minimal responses > > * should set the DONTFRAG option on responses And responders should set TC=1 (and re-compose smaller response) if sendto returned EMSGSIZE. > * should listen for ICMP frag needed packets, and react by re-sending the > response (which is embedded in the ICMP packet) with a TC bit set It is a part of path MTU discovery. > Network: > > * should send rate-limited ICMP frag needed messages to DNS servers when > appropriate I don't know. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt
etting IP_RECVERR and inspecting MSG_ERRQUEUE. In IPv4 the PTB > messages often have 520 bytes of payload and in IPv6 1184 bytes. This > is enough context to build another response, without having to wait > for any timeout. In my opinion, the captured PTB data is similar to IP_MTU/IPV6_MTU socket options. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-avoid-fragmentation-00.txt
DNSOP WG, Paul Vixie and I submitted draft-ietf-dnsop-avoid-fragmentation-00. Please review it. > https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00 I may have some mistakes, I could not find links to show differences from draft-fujiwara-dnsop-avoid-fragmentation-03. Please see differences from this URL. https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-fujiwara-dnsop-avoid-fragmentation-03.txt=https://tools.ietf.org/id/draft-ietf-dnsop-avoid-fragmentation-00.txt Differences from -03 to 00 are Added "DNSSEC is a countermeasure .." in Intro. Removed 7.2 DNS packet size. Moved details of Minimal-responses to appendix B Added reference to draft-ietf-tsvwg-datagram-plpmtud And more, we would like to make some changes in -01. * Adding new text in abstract. "EDNS0 enables a DNS server to send large responses using UDP and is widely deployed." * Change text related to TCP in Introduction because TCP changes MSS value to avoid IP fragmentation under ICMP NEEDFRAG attacks. OLD By comparison, TCP is considered resistant against IP fragmentation attacks because TCP has a 32-bit sequence number and 32-bit acknowledgment number in each segment. NEW By comparison, TCP protocol stack controls packet size and avoid IP fragmentation under ICMP NEEDFRAG attacks. In TCP, fragmentation should be avoided for performance reasons, whereas for UDP, fragmentation should be avoided for resiliency and authenticity reasons. * I would like to use "in-domain" (defined in RFC 8499) OLD: and in-zone and below-zone glue in the additional data section. NEW: and in-domain (in-zone and below-zone) glue in the additional data section. Regards, -- Kazunori Fujiwara, JPRS > From: internet-dra...@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Fragmentation Avoidance in DNS > Authors : Kazunori Fujiwara > Paul Vixie > Filename: draft-ietf-dnsop-avoid-fragmentation-00.txt > Pages : 10 > Date: 2020-06-30 > > Abstract: >Path MTU discovery remains widely undeployed due to security issues, >and IP fragmentation has exposed weaknesses in application protocols. >Currently, DNS is known to be the largest user of IP fragmentation. >It is possible to avoid IP fragmentation in DNS by limiting response >size where possible, and signaling the need to upgrade from UDP to >TCP transport where necessary. This document proposes to avoid IP >fragmentation in DNS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-avoid-fragmentation-00 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-avoid-fragmentation-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] unsolicited HTTPSSVC responses
> From: Petr Špaček > On 27. 05. 20 1:05, Paul Vixie wrote: >> than one kind of data in a single upstream DNS round trip. QDCOUNT>1 is not >> well defined and is broadly unimplemented. various other multiple-questions >> proposals have been made but nothing gets traction. > > I would much rather spent time on > https://tools.ietf.org/html/draft-bellis-dnsext-multi-qtypes-03 I don't like new protocol and big change like QDCOUNT>1. Please check "dig +dnssec +norec @ns0.amsl.com ietf.org mx" and "dig +dnssec +norec @ams.sns-pb.isc.org. _sip._udp.isc.org srv". ietf.org authoritative servers add "mail.ietf.org A" in additiona section (with RRSIG). isc.org authoritative servers add "asterisk.isc.org A" in additional section (with RRSIG). Authoritative servers can add any A/ RRs related to HTTPSSVC in additional section. Then, adding new text that "authoritative servers MAY add A/ RRs related to HTTPSSVC RR in additional section". Recent resolvers reject/accept additional section data. (If they have RRSIGs, then they may be accepted). -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-03.txt
Hello, Paul Vixie and I submitted draft-fujiwara-dnsop-avoid-fragmentation-03.txt Please review it. Changes from 01 to 03 are: - Changed title as Fragmentation Avoidance in DNS - Refer draft-ietf-intarea-frag-fragile - Fixed: Minimum MTU forIPv4 is 68 (from 576) - Added: DNS flag day 2020 proposed 1232 as an EDNS buffer size. - Added: 'minimal-responses' configuration - Added: consideration of DNS packet size - Added: How to measure path MTU and calculate maximum DNS/UDP payload size I think that we may need definition of "minimal-responses". - A new version of I-D, draft-fujiwara-dnsop-avoid-fragmentation-03.txt has been successfully submitted by Kazunori Fujiwara and posted to the IETF repository. Name: draft-fujiwara-dnsop-avoid-fragmentation Revision: 03 Title: Fragmentation Avoidance in DNS Document date: 2020-04-13 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-03.txt Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/ Htmlized: https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation Diff: https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-avoid-fragmentation-03 Abstract: Path MTU discovery remains widely undeployed due to security issues, and IP fragmentation has exposed weaknesses in application protocols. Currently, DNS is known to be the largest user of IP fragmentation. It is possible to avoid IP fragmentation in DNS by limiting response size where possible, and signaling the need to upgrade from UDP to TCP transport where necessary. This document proposes to avoid IP fragmentation in DNS. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-01
Dear dnsop WG, Please review draft-fujiwara-dnsop-avoid-fragmentation-01. https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-01 Main differences are: - New Co-author - Refer RFC 8085 UDP Usage Guidelines - SHOULD send DNS responses with IP_DONTFRAG / IPV6_DONTFRAG [RFC3542] - Use actual path MTU information, or the default maximum DNS/UDP payload size - Added text about how to retrieve path MTU value in appendix getsockopt() IP_MTU and IPV6_MTU (Linux only) - default maximum DNS/UDP payload size >= 1220, and <= 1400 - Request to zone operator: Use smaller contents (number of RRs, DNSSEC key) -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-avoid-fragmentation-00
Dear DNSOP, I submitted draft-fujiwara-dnsop-avoid-fragmentation-00. https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00 It proposes avoid IP fragmentation operation in DNS. I removed details of attack to path MTU discovery and cache poisoning attacks using IP fragmentation from draft-fujiwara-dnsop-fragmentation-attack01, and changed as recommendations. Details of attacks are written in slides at OARC 30. https://indico.dns-oarc.net/event/31/contributions/692/attachments/660/1115/fujiwara-5.pdf If the draft is interested, I will request timeslot at IETF 105. I think it is time to consider to avoid IP Fragmentation in DNS. It is possible to avoid IP fragmentation as much as possible. It is not good that DNS is the biggest user of IP fragmentation. Regards, -- Kazunori Fujiwara, JPRS A new version of I-D, draft-fujiwara-dnsop-avoid-fragmentation-00.txt has been successfully submitted by Kazunori Fujiwara and posted to the IETF repository. Name: draft-fujiwara-dnsop-avoid-fragmentation Revision: 00 Title: Avoid IP fragmentation in DNS Document date: 2019-07-04 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-avoid-fragmentation-00.txt Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-avoid-fragmentation/ Htmlized: https://tools.ietf.org/html/draft-fujiwara-dnsop-avoid-fragmentation-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-avoid-fragmentation Abstract: Path MTU discovery is vulnerable and IP fragmentation may cause protocol weakness. Currently, DNS is said to be the biggest user of IP fragmentation. However, it is possible to avoid IP fragmentation in DNS because TCP transport and truncation work well. This document proposes to avoid IP fragmentation in DNS. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
> From: Mark Andrews > Or one can use TSIG with a well known key to get a cryptograph hash of the > response. Below is how > how the servers for the Alexa to 1 Million handle unexpected TSIG. It’s well > under a day to add > this to a recursive server that supports TSIG already. It’s a couple of > minutes of configuration > time to add it to a authoritative server that supports TSIG already. Do you mean adding new method like DNS Cookies ? I have a question. If a resolver want to take measures, does the resolver configure TSIG to communicate all authoritative servers ? -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
> From: 神明達哉 >>https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 >> >> It summarized DNS cache poisoning attack using IP fragmentation >> and countermeasures. >> >> If the draft is interested, I will request timeslot at IETF 104. > > I've read the draft. I think it's generally well written and contains > useful information. Thanks very much. > Some specific comments follow: > > - general: I wonder whether the effect of this problem can be > substantially different between IPv6 and IPv4. As the draft itself > discusses, IPv6 has a much larger ID space for fragmentation (the > existence of implementations that generate predictable IDs is an > implementation issue; in the case of IPv4 it's a protocol issue). > IPv6 also has a much larger minimum MTU. In practice, I suspect > most (unsigned) important responses can fit in the minimum MTU, > substantially affecting the practical severity of the attack. I'm > not saying that we don't have to take any measure for the IPv6 case, > but I think this difference is worth noting in the draft explicitly. I agree and need to consider how to update. > - general: the draft the term "full-service resolver" in Abstract and > throughout the document. It may be only me, but I always feel this > term is confusing and misleading, even after the publication of > RFC8499. It's not very clear to me whether "full-service" excludes > "forwarding only" resolvers. RFC8499 refers to RFC1123, and its > definition is also unclear to me in this sense. If this confusion > is not only mine, I think the use of the term is rather harmful, > since the issue discussed in this draft shouldn't exclude forwarding > only resolvers. What matters here is a resolver with a cache, and > in that sense I'd rather suggest just saying "(recursive) resolver"; > it should be obvious that it's about a resolver with the cache from > the context. I will consider the comment. > - general: on a related point, I suspect the discussion about > authoritative servers is not actually specific to authoritative > servers; consider the case of a recursive server that takes queries > from forwarding only resolvers. It should be generally applicable > to any DNS "responder", and I'd suggest revising the draft > accordingly. DNS forwarders and stub resolvers may be target of cache poisoning attacks. Then, path MTU attack targets are DNS responders (auth/resolver servers). > - general: since this is about off-path cache poisoning attacks, you > may also want to refer to DNS cookies (RFC7873) as a possible measure. I agree. > - Section 3 > >Linux 2.6.32, Linux 4.18.20 >and FreeBSD 12.0 accept crafted "ICMPv6 Packet Too Big" packet and >path MTU decreased to 1280. > > I suspect this often doesn't matter much in practice. Since IPv6 > doesn't allow fragmentation and PMTU discovery isn't very effective for ^ on-path fragmentation ? > DNS responders, the server implementation should set > IPV6_USE_MIN_MTU and expect that MTU anyway (several implementations > actually set this option; some others don't, but they are just lucky > to not encounter the problem or receive complaints about it). If setting IPV6_USE_MIN_MTU, does the server use 1280 as all path MTU value ? Without IPV6_DONTFRAG option, are responses larger than 1280 fragmented ? I observed many fragmented IPv6 DNS responses whose packet size are 1496 or 1500. # What I was interested in was that many implementations accept # crafted "ICMPv6 Packet Too Big". > - Section 4.2 > >Limiting EDNS0 requestor's UDP payload size [RFC6891] to 1220/1232 on >IPv6 is a measure of path MTU attacks on IPv6 because minimal MTU >size of IPv6 is 1280 and most of implementations ignore ICMPv6 packet >too big packets whose MTU size is smaller than 1280. > > I suggest removing "and most of implementations..." since even if an > implementation accepts ICMPv6 PMTU with MTU < 1280, it doesn't mean > they fragment packets at that size. > > - Section 4.8 > >Some operators that support [RFC8078] said that they use TCP only for >transport to avoid cache poisoning attacks. > > It's not clear (to me at least) how RFC8078 is related to a TCP-only > operation. Some more explanation may help. > > - Section 5 > >o Full-service resolvers may retry name resolution by TCP. > > I don't get exactly what this means...in which case does it suggest > the retry with TCP? I will add texts. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-fragment-attack-01.txt
Dear DNSOP, I submitted draft-fujiwara-dnsop-fragment-attack-01. https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 It summarized DNS cache poisoning attack using IP fragmentation and countermeasures. If the draft is interested, I will request timeslot at IETF 104. I think it is time to consider to avoid IP Fragmentation in DNS. It is possible to avoid IP fragmentation as much as possible. It is not good that DNS is the biggest user of IP fragmentation. Regards, -- Kazunori Fujiwara, JPRS A new version of I-D, draft-fujiwara-dnsop-fragment-attack-01.txt has been successfully submitted by Kazunori Fujiwara and posted to the IETF repository. Name: draft-fujiwara-dnsop-fragment-attack Revision: 01 Title: Measures against cache poisoning attacks using IP fragmentation in DNS Document date: 2019-03-01 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-fragment-attack-01.txt Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-fragment-attack/ Htmlized: https://tools.ietf.org/html/draft-fujiwara-dnsop-fragment-attack-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-fragment-attack Diff: https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-fragment-attack-01 Abstract: Researchers proposed practical DNS cache poisoning attacks using IP fragmentation. This document shows feasible and adequate measures at full-service resolvers and authoritative servers against these attacks. To protect resolvers from these attacks, avoid fragmentation (limit requestor's UDP payload size to 1220/1232), drop fragmented UDP DNS responses and use TCP at resolver side. To make a domain name robust against these attacks, limit EDNS0 Responder's maximum payload size to 1220, set DONTFRAG option to DNS response packets and use good random fragmentation ID at authoritative server side. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNS without Fragmentation (UDP and DF bit set)
Sorry, too late response. I could not understand second paragraph about TSIG. > From: Mark Andrews > Firstly you are insane to recommend dropping PTB’s. That will break lots of > things > including TCP. Thanks. I agree. I mainly concerned on IPv4. Dropping IPv4 ICMP "fragmentation needed and DF set" and IPv6 PTB may cause TCP problem. Then my proposal changed as follows: Authoritative servers should set static EDNS buffsize 1220. (and set DF bit in responses on IPv4). Full-service resolvers should set static EDNS buffsize 1220 and should drop fragmented DNS response packets by packet filters. IPv4: drop UDP and source port 53, More fragment bit = 1 IPv6: drop packets that have NextHeader = Fragment, fragment offset=0, more fragment = 1, hext header=UDP UDP, source port 53 TCP will work if the end node is under ICMP PTB/need fragment attack and path MTU becomes under 300. > Secondly we could just use a well known TSIG key and have the authoritative > servers add > it to their configuration today, especially the root and TLDs servers. The > recursive > servers could also add the key for root and TLD servers they know have > installed the > the well known key. This is easy to test with tools like dig. Do you mean TSIG protects from second fragmentation attacks ? Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNS without Fragmentation (UDP and DF bit set)
It is time to drop fragmentation (and pMTU discovery) in DNS. A research paper showed that there are many authoritative servers that accept any ICMP destination unreachable / fragmentation needed and DF set (pMTU response packets) and reduce packet size up to 296 bytes. Path MTU discovery is controlled by any attacker. Then the authors sent trigger queries and did second fragmentation attack to CA's resolvers. https://dl.acm.org/citation.cfm?id=3243790 Domain Validation++ For MitM-Resilient PKI Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner Fraunhofer SIT, TU Darmstadt Proposed solution is not good. DNS with TCP transport is enough, I think. I would like to propose to drop fragmentation and pMTU discovery in DNS. Authoritative servers should drop ICMP fragmentation needed, set static EDNS buffsize 1220, and set DF bit in responses. On resolver machines, I would like to drop fragmented response packets. We can write IP filter that drop fragmented packet to resolvers, but it is not beautiful. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
What I want to say about draft-ietf-dnsop-algorithm-update-02 are below: 1. About chapter composition If section 3.2 is "recommendations for operators", Section 3.1 and Section 3.3 are recommendations for software developpers and TLD/Root operators. # Sometimes TLD/Root do not accept newer algorithms and digests. 2. "recommendations for operators" section Section 3.2 lacks texts about RSASHA256 and other algorithms. Currently, both RSASHA256 and ECDSAP256SHA256 are first choices for operators. 3. texts about DS (and CDS) algorithms recommendation for operators needed In section 3.2 or 3.3, please add SHA-256 is necessary and enough DS algorithm for operators now. 4. In my opinion, Ed25519 is best algorithm some yars later. If the document describes both current RECOMMENDATIONS and RECOMMENDATIONS some years later, we can plan. Regards, -- Kazunori Fujiwara, JPRS > From: fujiw...@jprs.co.jp > WGLC comment to draft-ietf-dnsop-algorithm-update-02 > > Section 3.2 is "recommendations for operators". > > There is texts that discuss ECDSAP256SHA256 only in section 3.2. > However, RSASHA256 is still usable. > Please add text about other algorithms. > if there is a table similar to section 3.1, it will help operators. > > For example, > choice of| choice of > sigining algorithm (now) | sigining algorithm (2 years Later) > > RSASHA1*MUST NOT| MUST NOT > RSASHA256 usable | usable/consider change to EC*/Ed* > ECDSAP256* usable | usable > Ed25519 MAY | usable > > > Regards, > > -- > Kazunori Fujiwara, JPRS > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-algorithm-update
WGLC comment to draft-ietf-dnsop-algorithm-update-02 Section 3.2 is "recommendations for operators". There is texts that discuss ECDSAP256SHA256 only in section 3.2. However, RSASHA256 is still usable. Please add text about other algorithms. if there is a table similar to section 3.1, it will help operators. For example, choice of| choice of sigining algorithm (now) | sigining algorithm (2 years Later) RSASHA1*MUST NOT| MUST NOT RSASHA256 usable | usable/consider change to EC*/Ed* ECDSAP256* usable | usable Ed25519 MAY | usable Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
Thanks to Vladimír, > From: Vladimír Čunát > "Bailiwick" definition: I have (also) seen use like "in-bailiwick > records" in the sense being in a subdomain. I can't really judge how > common that usage is, but it has already been discussed wrt. this draft: > https://mailarchive.ietf.org/arch/msg/dnsop/MyEdXXdUKKyTTfX3_4_7AnhE3Io > My understanding of that thread is that the meaning was planned to be extended > in the draft, but the current text seems still restricted to name servers. I missed updating the part. It's too late, but if possible, I would like to update the part a follows. --- "In-bailiwick" is an adjective indicating that a domain name is a subdomain of or (rarely) the same as another domain name. "Out-of-bailiwick" is the antonym of in-bailiwick. (The term "bailiwick" means the district or territory where a bailiff or policeman has jurisdiction.) "In-bailiwick" and "out-of-bailiwick" are usually used for name servers' names. "In-bailiwick" name server is a name server whose name is either a subdomain of or (rarely) the same as the origin of the zone that contains the delegation to the name server. In-bailiwick name servers may have glue records in their parent zone (using the first of the definitions of "glue records" in the definition above). "In-bailiwick" names are divided into two type of name server names: "in-domain" names and "sibling domain" names. In-domain: sibling domain: examples - -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] multiple responses after ietf100
I evaluated current full-service resolver implementations that accept additional resource records or not. Tested resolvers: BIND 9, Unbound, Knot Resolver, PowerDNS recursor, Google Public DNS Result: Knot resolver 2.0.0 and Unbound 1.7.0rc accept additional NSEC RRs (+ SOA RRs) in authority section and generate NODATA responses (a half of additional-answer scenario) PowerDNS recursor accepts additional A/ in answer section (-for-free scenario) Other cases, additional resource records are ignored. Details: https://indico.dns-oarc.net/event/28/session/11/contribution/46/material/slides/0.pdf -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain
Thanks. Adding a example as a text is a little complicated. Adding examples as a table is good ? or too large ? Delegation | Parent | Name Server Name | Type | Zone || +++-- com | . | a.gtld-servers.net | in-bailiwick / sibling domain net | . | a.gtld-servers.net | in-bailiwick / in-domain example.org | org| ns.example.org | in-bailiwick / in-domain example.org | org| ns.ietf.org| in-bailiwick / sibling domain example.org | org| ns.example.com | out-of-bailiwick example.jp | jp | ns.example.jp | in-bailiwick / in-domain example.jp | jp | ns.example.ne.jp | in-bailiwick / sibling domain example.jp | jp | ns.example.com | out-of-bailiwick -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: George Michaelson <g...@algebras.org> > feels like a concrete example in a.b.c.example.com terms would help > define both in-baliwick, and out-of-baliwick, for the cases. > > On Wed, Dec 13, 2017 at 9:42 PM, <fujiw...@jprs.co.jp> wrote: >> Thanks. >> >> terminology-bis-08: >> | In-bailiwick: An adjective to describe a name server whose name is >> |either subordinate to or (rarely) the same as the zone origin. >> >> Ok, In-bailwick in terminology-bis-08 may be restrictive because "the >> zone origin" is unclear. I intended that "the zone origin" is the zone >> origin of parent zone. The sentence needs more words. >> >> NEW >> >> In-bailiwick: An adjective to describe a name server whose name is >>either subordinate to or (rarely) the same as the origin >>of the zone that contains the delegation to the name server. >> >> ... bad english text ... please fix. >> >> -- >> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >> >>> From: Mark Andrews <ma...@isc.org> >>> The text for "in-bailwick" is too restrictive, it doesn’t just cover NS >>> records or >>> glue records. >>> >>> In-bailwick refers to records that in the normal course of DNS resolution >>> would have been requested of by the server the current response is from. >>> e.g. if you are querying a .com server then all records in the response >>> that end >>> with .com are in-bailwick. >>> >>> Mark >>> >>>> On 5 Dec 2017, at 5:27 am, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >>>> >>>> Greetings again. >>>> >>>> Some of the new terms added to the terminology-bis draft >>>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since >>>> RFC 7719 can be a bit tricky. This week, we hope you will look at the >>>> definitions in the draft for: >>>> - In-bailiwick >>>> - Out-of-bailiwick >>>> - In-domain >>>> - Sibling domain >>>> Please review these terms and comment on the list if you think the >>>> definitions should change. >>>> >>>> --Paul Hoffman >>>> >>>> [[ As a reminder, we asked the following last week, but got no reply: For >>>> the past many versions of the terminology-bis draft >>>> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), >>>> Section 2 has definitions of "Global DNS" and "Private DNS", based on the >>>> facets listed in "Naming system". This was discussed heavily on the list >>>> earlier, but it is also a pretty big change, so we want to be sure that it >>>> is what the WG wants. Please review these terms and comment on the list if >>>> you think the definitions should change. ]] >>>> >>>> ___ >>>> DNSOP mailing list >>>> DNSOP@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dnsop >>> >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Please review in terminology-bis: In-bailiwick, Out-of-bailiwick, In-domain, Sibling domain
Thanks. terminology-bis-08: | In-bailiwick: An adjective to describe a name server whose name is |either subordinate to or (rarely) the same as the zone origin. Ok, In-bailwick in terminology-bis-08 may be restrictive because "the zone origin" is unclear. I intended that "the zone origin" is the zone origin of parent zone. The sentence needs more words. NEW In-bailiwick: An adjective to describe a name server whose name is either subordinate to or (rarely) the same as the origin of the zone that contains the delegation to the name server. ... bad english text ... please fix. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Mark Andrews <ma...@isc.org> > The text for "in-bailwick" is too restrictive, it doesn’t just cover NS > records or > glue records. > > In-bailwick refers to records that in the normal course of DNS resolution > would have been requested of by the server the current response is from. > e.g. if you are querying a .com server then all records in the response that > end > with .com are in-bailwick. > > Mark > >> On 5 Dec 2017, at 5:27 am, Paul Hoffman <paul.hoff...@vpnc.org> wrote: >> >> Greetings again. >> >> Some of the new terms added to the terminology-bis draft >> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/)since >> RFC 7719 can be a bit tricky. This week, we hope you will look at the >> definitions in the draft for: >> - In-bailiwick >> - Out-of-bailiwick >> - In-domain >> - Sibling domain >> Please review these terms and comment on the list if you think the >> definitions should change. >> >> --Paul Hoffman >> >> [[ As a reminder, we asked the following last week, but got no reply: For >> the past many versions of the terminology-bis draft >> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/), >> Section 2 has definitions of "Global DNS" and "Private DNS", based on the >> facets listed in "Naming system". This was discussed heavily on the list >> earlier, but it is also a pretty big change, so we want to be sure that it >> is what the WG wants. Please review these terms and comment on the list if >> you think the definitions should change. ]] >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Ask for advice of 3 new RRs for precise traffic scheduling
> From: bert hubert <bert.hub...@powerdns.com> > 3) Serve up multiple copies of the same A record, and weigh like this: > www IN A 1.2.3.4 > www IN A 1.2.3.4 > www IN A 10.11.12.13 > And hope that record shuffling will deliver the 2:1 ratio Same RDATA is not allowed by RFC 2181. | 5. Resource Record Sets | | Each DNS Resource Record (RR) has a label, class, type, and data. It | is meaningless for two records to ever have label, class, type and | data all equal - servers should suppress such duplicates if | encountered. It is however possible for most record types to exist | with the same label, class and type, but with different data. Such a | group of records is hereby defined to be a Resource Record Set | (RRSet). > 1) Get browsers to honour RFC 2782 RFC 6763 DNS-Based Service Discovery shows "_http._tcp" service usage. > From: "zuop...@cnnic.cn" <zuop...@cnnic.cn> > (1) RFC2782 does not solve the problem of using multi-CDN (multiple CNAME > cannot coexist); > here we can use multipile weighted CNMAEXs (need to coexist with CNAME) > to accomplish this; > besides, weighted CNAMEXs can control traffic ratio among several CDN > providers; You can add many SRV RRs. (merge SRV RRs from multi-CDN). > (2) RFC2782 requires browser's support; > Using this method, a browser has no idea about weighted AX/Xs. > It requires no change of browsers. Softwares that support DNS-SD may support _http._tcp. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-additional-answers-00.txt
Hello, I submitted another multiple response proposal. https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00 It is similar to draft-wkumari-dnsop-multiple-responses, however, it proposes authoritative DNS server software developers choose additional resource records. # Many implementations (For example, BIND 9 and NSD) add MX mail # exchange A/ or SRV Target A/ in MX or SRV responses. And the draft proposes to append NSEC/NSEC3 RR if additional RR type does not exist. Validating resolvers can generate NODATA response by RFC 8198. It also contains comparison of multiple responses proposals in Appendix. Please read and comment it. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> Subject: I-D Action: draft-fujiwara-dnsop-additional-answers-00.txt From: internet-dra...@ietf.org To: <i-d-annou...@ietf.org> Date: Sat, 28 Oct 2017 09:57:24 -0700 Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/XqW3OeFv6rczw7inZrIdwe9VY8U> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Returning additional answers in DNS responses Author : Kazunori Fujiwara Filename : draft-fujiwara-dnsop-additional-answers-00.txt Pages : 9 Date: 2017-10-28 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/ 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-additional-answers/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-fujiwara-dnsop-additional-answers-00 https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-additional-answers-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state "Candidate for WG Adoption"
> From: Stephane Bortzmeyer <bortzme...@nic.fr> >> The DNSOP WG has placed draft-bellis-dnsext-multi-qtypes in state >> Candidate for WG Adoption > > Did anyone was brave enough to make a detailed comparison between this > draft and other proposals like draft-yao-dnsop-accompanying-questions? > > (I was thinking myself of writing a draft on a ultra-simple proposal, > allowing QDCOUNT to be > 1 but forcing all QNAMEs to be identical, but > I never got time.) I prefered QDCOUNT>1 idea, but it mixes results of all queries. We want to know each RCODE and want to separate each answer. # Or, multiple DNS data in one UDP packet is possible. # DNSSEC may soluve the multiple RCODE problem. draft-yao-dnsop-accompanying-questions keeps each RCODE information in EDNS0 data. draft-bellis-dnsext-multi-qtypes does not have the problem because the qname is only one. draft-wkumari-dnsop-multiple-responses does not have the problem because the main query is one. We would like to compare all idea before proceeding. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-nsec-aggressiveuse-08
Thanks for the review > From: Jouni Korhonen <jouni.nos...@gmail.com> > Reviewer: Jouni Korhonen > Review result: Has Nits > > I think would be ready if it passed IDnits. I found the document good > read and found no sinkholes in it. Pointing up two implementations was > also great. > > The Proto Write-up seems not be up to date with what IDnits says e.g., > when it comes to downrefs, which is what the IDnits complain about. > > A couple of editorials: > > Lines 118-119 says: "This takes this.." I would reword to something > like: >"This document takes using NXDOMAIN information for more effective > caching further." > > Lines 396 and 397 uses "is NOT" and "IS making". I would use lower > case here. No reason to use capitalized and still non-RFC2119 > language. I will update the parts. > Line 407 is would be great to indicate since which version of Unbound > support has been in place. It is my edit mistake. Unbound does not implement "Aggressive use of DNSSEC-validated Cache" now. See: https://mailarchive.ietf.org/arch/msg/dnsop/Iv1mxko-ZtUBkNWPZnnnwT9LR-A # I implemented NSEC only version using Unbound three years ago as a patch. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Thanks very much for submitting IPR infomation. The idea is not new and I heard that Nominum and some software implemented. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: Andreas Gustafsson <g...@araneus.fi> > fujiw...@jprs.co.jp wrote: >> I also received IPR claim from Nominum. >> >> https://datatracker.ietf.org/ipr/2907/ >> https://patents.google.com/patent/US7769826B2/ > > Just to avoid any possible misunderstanding, the IPR statement > referenced above was submitted by me in my capacity as a DNSOP > participant, as a third-party notification under RFC 3979 section > 6.1.3, because I thought the working group should be aware that the > patent exists. I am not currently affiliated with Nominum and did not > submit the statement on their behalf nor at their request. > -- > Andreas Gustafsson, g...@araneus.fi > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Ondrej.Sury-san, > From: Ondřej Surý <ondrej.s...@nic.cz> > Fujiwara-san, > > I was strongly opposed to the idea after your DNS-OARC presentation > and I am glad you are continuing the effort :). > > I had some private conversation with Ralf Weber from Nominum and > we have conducted few experiments (and I plan to do more). > > My biggest concern is that your draft is missing the impact on the > authoritative side: > > 1) what should happen when there's wrong NS at the child? Resolvers with "overwrite" will become unstable. Resolvers with proposed algorithm don't use the child NS. Queries to parent authoritative servers do not increase. > 2) what should happen when there's no NS at the child? Resolvers with "overwrite" becomes unstable if stub resolvers send child NS queries. Resolvers with proposed algorithm don't use the child NS. Queries to parent authoritative servers do not increase. > 3) what should happen in 1) and 2) when they are at the same server > (generally the child NS is served)? Referrals from the grandparent is used. Queries to the parent zone and the child zone is sent to the shared authoritative server and it answers authoritative data of the child zone. Resolvers with "overwrite" will become unstable if stub resolvers send child NS queries. Resolvers with proposed algorithm don't use the child NS. Queries to authoritative servers do not increase. > The most practical thing would be to require that child and parent NS MUST > match, but we would > be saying at the same time that it won't be used at all. > > The second concern is about TTL. You dismiss it very quickly in 5.4, but > implementation wise - it would be probably best to split "delegation" and RR > caches as you generally the query for: > > "example.com." IN NS > > should return child records with child TTL, but the delegation at parent > could have different values with different TTL. Also I can imagine this will > be very confusing to end-users - when I query my resolver for "IN NS" I > generally want to know when the changes in the delegations will be reflected. True. > One possible way might be to return child NS in ANSWER and parent NS in > AUTHORITY section in such case - but this needs to be addressed in the draft. It's good idea. Thanks. > This will also have an impact on registries - usually the TTL at the parent > is picked by the registry, but when the TTL at the parent could have such > strong impact on the resolver behavior, the registries would have to modify > their systems to allow TTL specification per delegated domain. This applies > especially in the cases when the registry picks some large (but still > reasonable) number for TTL. However, the overwrite does not happen always. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
> From: Stephane Bortzmeyer <bortzme...@nic.fr> > fujiw...@jprs.co.jp <fujiw...@jprs.co.jp> wrote > a message of 61 lines which said: > >> I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to >> improve resolver algorithm. > > I see the point but I have two practical reservations: > > 1) Having two separate caches may be a big change for some > implementations. Yes. Two cache approach have patent problem. There may be another implementation method. > 2) It will make debugging more difficult. With your two-caches system, > "dig @myresolver NS foobar.example" will retrieve the data in > foobar.example, while the resolver will use, when iterating, the data > from .example, which is not showed and I don't see a standard way to > retrieve it from the "delegation cache". - The simplest mode for the client is recursive, since in this mode the name server acts in the role of a resolver and returns either an error or the answer, but never referrals. (RFC 1034 Section 4.3.1) "dig @myresolver NS foobar.example" returns authoritative data. > Apart from that, one detail: section 6 on implementations is too > short. You should expand it at least with the name of the > implementations (you mention two in your OARC talk, so it is not a > secret), and may be with RFC 7942 boilerplate. I will add. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-resolver-update-00
Jinmei-san, thanks very much for your detailed comments.
I also received IPR claim from Nominum.
https://datatracker.ietf.org/ipr/2907/
https://patents.google.com/patent/US7769826B2/
I {will,need to} remove detailed algorithm {,to avoid IPR}.
Then, I will change the main contents to focus on problem collection
and proposal of requirements.
> From: 神明達哉 <jin...@wide.ad.jp>
> - general: the title and file name seem to be too generic for the
> actual content. I suggest making them more specific, focusing on
> the subject of this draft.
Agree.
(I will submit next version to remove detailed algorithm to avoid IPR problem.)
> - Section 1
>
>[...] And it may break requirements of resolvers'
>answers described in Section 3.2.
>
> I don't get it. Specifically which requirement does this refer to?
> And, specifically how this override break that requirement?
Ok, I will add more text...
> - Section 3.1
>
>As described above, parent side NS RRSet makes a new zone. Parent
>side NS RRSet (referral) and glue records are all the information to
>access servers for the child zone.
>
>That is, resolvers SHOULD NOT use child side NS RRSet to iterate
>zones.
>
> There seems to be a logical leap between the first and second
> paragraph; I don't get why we SHOULD NOT use the child side NS
> RRset for subsequent iteration simply because the parent NS RRset is
> used for the iteration first time (which I guess the first para
> tries to say). In fact, the child side NS RRset might be a more
> complete, accurate and up to date set of the NS, while some part of
> the parent NS RRset may be unusable. This is related to the high
> level comment I made in my previous message - I see and support the
> seeming background motivation of this requirement, but I believe we
> need more careful considerations and probably a much less drastic
> update.
I agree that we need more careful consideration.
> - Section 4
>
>However, people sets different NS RRSets with mistakes, or
>intentionally.
>
> Specifically what kind of intent does this "intentionally" mean?
I considered "intentionally means "malicious idea".
next version will relfect your excellent comment.
Regards,
--
Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-resolver-update-00
Hello, I submitted draft-fujiwara-dnsop-resolver-update-00 that tries to improve resolver algorithm. Please read it and comment. I also made a presentation of the same topic at previous DNS-OARC workshop. https://indico.dns-oarc.net/event/25/session/6/contribution/19/material/slides/2.pdf Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: internet-dra...@ietf.org > > A new version of I-D, draft-fujiwara-dnsop-resolver-update-00.txt > has been successfully submitted by Kazunori Fujiwara and posted to the > IETF repository. > > Name: draft-fujiwara-dnsop-resolver-update > Revision: 00 > Title:Updating Resolver Algorithm > Document date:2016-11-01 > Group:Individual Submission > Pages:9 > URL: > https://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-resolver-update-00.txt > Status: > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-resolver-update/ > Htmlized: > https://tools.ietf.org/html/draft-fujiwara-dnsop-resolver-update-00 > > > Abstract: >Parent side NS RRSet and glue records are all information to access >servers for child zone. However, they may be overwritten by child >zone data (zone apex NS RRSet and other A/ RRSets). The >overwrite makes name resolution unstable and induces vulnerabilities. >RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it >is deemed that that all cached data (authoritative data, non- >authoritative data, referrals and glue records) are merged into one. >Resolvers may answer non-authoritative data, referrals and glue >records that should not be returned. This document proposes updating >resolver algorithm that separates the cache to "authoritative data >cache" and "delegation cache". The former is used to answer stub >resolvers, and the latter is used to iterate zones. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The Larger Discussion on Differences in Response Drafts
Hello, > From: Tim Wicinski <tjw.i...@gmail.com> > In Berlin we had two presentations on different methods of returning > multiple responses: > All of these documents are attempting to solve a larger problem in > different ways. > The end result is "Return Associated Answer" to the client. > > The question is starting to coalesce around these two premises: Is it true that the extensions are used both RD=1 (stub to full-service resolver) and RD=0 (full-servicce resolver to authoritative) ? > - Do we want to Server to PUSH any or all Associated Answers, or > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ Full-service resolvers need to preserve/cache EXTRA RR and all related qname/qtype pairs. And then, they need to generate the same answers as the authoritative servers. Stub resolvers need to know/detect the full-service resolver support the extension or not. Currently, stub resolvers send both A and queries. We need to consider how to stop sending multiple queries. > - Do we want the Client to PULL any or all Associated Answers, or > https://datatracker.ietf.org/doc/draft-bellis-dnsext-multi-qtypes/ PULL (multiple queries) case, the stub resolver first sends QDCOUNT>1 or with new EDNS options, and if it received FORMERR / ignored, it can switch to traditional mode. For both cases, we should take care of the nonexistence of additional names or additional types. The associated answers may need NSEC RR. # Non-existent pseudo RDATA may be useful, however, RDLENGTH=0 is not reserved. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
> From: "Jiankang Yao" <ya...@cnnic.cn> >>* My idea > >> I prefer multiple query sections (with some restrictions) >> and merged answers. > >> multiple query examples may be >>NAME A + NAME + MX >>NAME A + NAME + _443._tcp.NAME TLSA >>NAME A + NAME + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ... >> > > Dear Fujiwara-san, > > Your points/scenarios fall in the Draft > > https://www.ietf.org/internet-drafts/draft-yao-dnsop-accompanying-questions-00.txt Thanks. I read the draft. It has similar point and different point. I cannot understand the UAQ bit necessity. When a client sends a query with AQ EDNS0 option, if the server knows the AQ EDNS0 option, the server can answer AQ response because the client knows the AQ extension. If the server does not know the AQ EDNS0 option, the server drops the unknown option. Another comment: the response format is very complicated. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state "Candidate for WG Adoption"
> From: IETF Secretariat <ietf-secretariat-re...@ietf.org> > The DNSOP WG has placed draft-wkumari-dnsop-multiple-responses in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/ I missed previous discussions (at dnsext). However, there were many discussions about multiple queries in one request. We need summaries of previous discussions, and need to consider why many idea stopped. * For the draft, Using unstructured data (TXT format) is not good. I agree query name restriction (Additional records MUST be leaf records at the same node in the DNS tree). I think the multiple queries in one request is not related to DNSSEC and TCP connection. They are separated elements. * My idea I prefer multiple query sections (with some restrictions) and merged answers. multiple query examples may be NAME A + NAME + MX NAME A + NAME + _443._tcp.NAME TLSA NAME A + NAME + _sip._udp.NAME SRV + _sips._tcp.NAME SRV + ... Many people may dislike QDCOUNT != 1. EDNS0 option which contain additional query section may be possible. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
> From: 神明達哉 <jin...@wide.ad.jp> > Ah, okay, now I see it. I think there's some logical gap here, which > I believe could be improved through some wording change: > > - the last paragraph of RFC 4035 Section 4.5 talks about aggressive > use of a cached deduced wildcard (as well as aggressive use of > NSEC) but rather recommends not to rely on it. > - just like the case for the aggressive use of NSEC discussed in this > draft, we could revisit this recommendation. as long as the > recursive server knows a name would not exist without the wildcard > match, it could answer a query for that name using the cached > deduced wildcard, and it may be justified for performance and other > benefits. (Note that, so far, this is orthogonal to "when > aggressive use (of NSEC) is enabled"). > - *Furthermore* when aggressive use of NSEC is enabled, the aggressive > use of cached deduced wildcard will be more effective as the > aggressive NSEC use helps prove more names wouldn't exist without > the wildcard through fewer external queries. Thanks. I used these texts. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
> From: Matthijs Mekking <matth...@pletterpet.nl> >>> - In section 4.3 I suggest to replace the second paragraph with: >>> >>>If the full-service resolver's cache contains an NSEC3 matching >>>the closest encloser, an NSEC3 covering the next closer name, and >>>an NSEC3 covering the source of synthesis, it is possible for the >>>full-service resolver to respond with NXDOMAIN immediately. >> >> Thanks. "closest encloser" and "next closer name" is defined in RFC 5155. >> I cannot find the definition of "source of synthesis". > > It's here: https://tools.ietf.org/html/rfc4592#section-3.3.1 Thanks. I added these key words in terminology section and I will add them to rfc7719bis. I rewrote pseudo code easier. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
> From: 神明達哉 <jin...@wide.ad.jp> >> > - Abstract: I suggest revising this on this point (see above): >> > >> >responses as well as some level of mitigation of random sub-domain >> >attacks (referred to as "Water Torture" attacks). >> > >> > by either simply removing it or clarifying that it's mitigation for >> > authoritative servers. >> >> I would like to remain all benefits in the abstract. I discussed with co-author. I will rewrite "performance improvement for recursive servers" as a purpose of the draft, and "possible countermeasure of some attacks" as side effect. >> > - Section 4.5 >> > >> >Even if a wildcard is cached, it is necessary to send a query to an >> >authoritative server to ensure that the name in question doesn't >> >exist as long as the name is not in the negative cache. >> >> The sentence shows current specifications (Section 4.5 of RFC 4035 and >> previous RFCs). > > Ah, so you actually referred to bullet #1 of RFC 4035 Section 4.5. I > see that, but in that case I'd suggest you refer to the RFC explicitly > here, and clarify that this is a "deduced" wildcard. OK, I will refer the section. >> >When aggressive use is enabled, regardless of description of >> >Section 4.5 of [RFC4035], it is possible to send a positive response >> >immediately when the name in question matches a NSEC/NSEC3 RRs in the >> >negative cache. >> > >> > I don't understand the second paragraph. I also don't understand >> > how the first paragraph is related to the second. I'm not sure if >> > it's only me, but I'd like to see more explanation here. >> >> The second sentence shows the aggressive use of ... changed the first >> paragraph. > > I still don't get it here. Can you perhaps show a specific example of > "send a positive response immediately when the name in question > matches a NSEC/NSEC3 RRs in the negative cache."? Especially about > how "a positive response" is derived from negative cache information? I will update the part to be expressed well. If nonexistence of a domain name is proved and there is a matching wildcard for the domain name, then the domain name matches the wildcard. the current draft may be lack of a description. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
> From: Matthijs Mekking <matth...@pletterpet.nl> > Some comments: > > - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY > do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver > SHOULD support aggressive NSEC usage and enable it by default. This to > me seems inconsistent use of the key words. I agree. I used Shane's text. > - In section 4.3 I suggest to replace the second paragraph with: > >If the full-service resolver's cache contains an NSEC3 matching >the closest encloser, an NSEC3 covering the next closer name, and >an NSEC3 covering the source of synthesis, it is possible for the >full-service resolver to respond with NXDOMAIN immediately. Thanks. "closest encloser" and "next closer name" is defined in RFC 5155. I cannot find the definition of "source of synthesis". I rewrote as an NSEC3 covering wildcards of the closest encloser [[ the part may be replaced as: an NSEC3 covering the source of synthesis ]], # may be rewritten by co-author. > - Section 4.3 suggests to build a separate cache of NSEC and NSEC3 > resource records for each signer domain name. This to me seems like an > implementation detail and is not necessarily required. In fact, a zone > may switch from NSEC to NSEC3 and vice versa, so you will need to check > them both if you implement it as a separate cache. I agree. removed the sentence. > - I don't see why setting the CD bit is an indication that NSEC(3) > aggressive usage should not be used. Could you elaborate on that? Section 3.2.2 of RFC 4035 states that: When the CD bit is set, the recursive name server SHOULD, if possible, return the requested data to the originating resolver, even if the recursive name server's local authentication policy would reject the records in question. aggressive negative caching may be "local authentication policy". > - My body shivers when reading that resolvers MAY use NSEC(3) records in > a NXDOMAIN response without validating them. Luckily the draft already > highly recommends that it should do validation. I would like to make it > even stronger and remove the MAY key word here, and perhaps use the > formal key word SHOULD do validation. Yes. I agree. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
Thanks, Jinmei. > From: 神明達哉 <jin...@wide.ad.jp> > - Abstract: I suggest revising this on this point (see above): > >responses as well as some level of mitigation of random sub-domain >attacks (referred to as "Water Torture" attacks). > > by either simply removing it or clarifying that it's mitigation for > authoritative servers. I would like to remain all benefits in the abstract. I will rewrite the sentense as the following. With this proposal, it is expected that performance improvement for recursive servers, reducing garbage traffic to authoritative servers and possible countermeasure of random subdomain attacks. > - Section 3: IMO this section will have to be completely revised in > terms of the selling point. Even if my point about the effect for > recursive server is refused, this section looks still quite awkward > since it reads as if this is *the* problem this proposal tries to > address, while in (e.g.) abstract it rather sounds a weak subset of > the goals. I will move texts from Section 1 Introduction to Section 3 and add three benefits. > - Section 4.2: this may also depend on the goal of the proposal, but > at this moment I don't think this "SHOULD" is fully justified: > >A full-service resolver implementation SHOULD support aggressive use >of NSEC and enable it by default. It SHOULD provide a configuration >knob to disable aggressive use of NSEC. > > If it's just a possible performance improvement for recursive > servers, it should be totally up to the implementors choice. For > other purposes such as (helping) attack mitigation for authoritative > servers or reduce garbage traffic to the root, some stronger > requirement level may make sense, but I'd like to see more empirical > evidence before making the requirement. agree. > - Section 4.5 > >Even if a wildcard is cached, it is necessary to send a query to an >authoritative server to ensure that the name in question doesn't >exist as long as the name is not in the negative cache. The sentence shows current specifications (Section 4.5 of RFC 4035 and previous RFCs). >When aggressive use is enabled, regardless of description of >Section 4.5 of [RFC4035], it is possible to send a positive response >immediately when the name in question matches a NSEC/NSEC3 RRs in the >negative cache. > > I don't understand the second paragraph. I also don't understand > how the first paragraph is related to the second. I'm not sure if > it's only me, but I'd like to see more explanation here. The second sentence shows the aggressive use of ... changed the first paragraph. > - Section 5.1: IMO, this is an example that makes the document fragile > by trying to defend it as an attack mitigation. If we say something > like this: > >This draft proposes that the CD bit may be ignored to support >aggressive negative caching when the full-service resolver is under >attacks with CD bit set. > > It's useless unless we also specify how to detect the resolver is > under an attack. And, if we can reasonably detect that (which I > guess is possible) we might not necessarily need nsec-aggressiveuse > for mitigation. When it's under an attack, other general counter > measures such as rate limiting can be justified and probably > sufficient. My personal suggestion is to stop the idea of defending > it as an attack mitigation, and simply note the implication of the > CD bit as a fact. It will not immediately make this proposal > useless for other general cases, since such queries would be > relatively much rare. I agree. I added "[[ This section may be removed. ]]" and removed the proposal of ignoring CD bit. > - Section 5.2: ditto. I suggest simply removing this section. > > - Section 9: I don't understand this: > >Aggressive use of NSEC/NSEC3 resource records without DNSSEC >validation may cause security problems. > > Specifically what does "without DNSSEC validation" mean? Something > like a case where a validating resolver receives an NSEC/NSEC3 and > uses that information without DNSSEC-validating it? If so, it's > simply invalid per protocol whether the use is "aggressive" or not. > So I don't see the need for stating that here. If this means > something else, I didn't get it and would like to see more > explanation. These parts may be useless. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] NXDOMAIN synthesis for NSEC3
> From: Shumon Huque <shu...@gmail.com> > For just the TLDs, "most" is true; I have some data at: > > https://www.huque.com/app/dnsstat/category/tld/dnssec/ > > In short, 895 or 79.1% of the signed TLDs are using NSEC3 Many TLDs use NSEC3 with OPT-OUT. # JP uses NSEC3 with OUT-OUT. hidden) delegations between NSEC3 range. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
> From: Bob Harold <rharo...@umich.edu> >>> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > I support adoption. Will read and review. Thanks. > Section 7.3 concerns me. If the range is expanded enough to be useful, > would it then allow zone enumeration? It is true. However, the zone operator controls the range. If the zone operator does not want zone enumeration, he will not change the range. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-fujiwara-dnsop-nsec-aggressiveuse-03.txt
> From: Shane Kerr <sh...@time-travellers.org> >> Last week, Kato and I submitted -03 version of >> draft-fujiwara-dnsop-nsec-aggressiveuse draft. It improved the >> structure of the document for readability and made minor corrections >> but essential idea has not been changed. > > Thank you for this work. I hope that it goes forward. > > The latest draft seems to have spent a lot of time covering NSEC3 more > clearly. Thanks, > My main question is... are there any missing pieces that you know of? It > seems pretty complete to me, although I have not implemented it so I > can't really say. (Implementation of NSEC3 aggressive negative caching is missing.) (I would like to implement NSEC3 version) > If there are not missing pieces, are there controversial parts? There are some controversial parts. - Aggressive negative caching itself - The CD bit If these parts will be agreed, I would like to go ahead. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-fujiwara-dnsop-nsec-aggressiveuse-03.txt
Last week, Kato and I submitted -03 version of draft-fujiwara-dnsop-nsec-aggressiveuse draft. It improved the structure of the document for readability and made minor corrections but essential idea has not been changed. We are appreciated if you read and commet it. Regards, -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > From: internet-dra...@ietf.org > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations of the IETF. > > Title : Aggressive use of NSEC/NSEC3 > Authors : Kazunori Fujiwara > Akira Kato > Filename: draft-fujiwara-dnsop-nsec-aggressiveuse-03.txt > Pages : 14 > Date: 2016-03-17 > > Abstract: >While DNS highly depends on cache, its cache usage of non-existence >information has been limited to exact matching. This draft proposes >the aggressive use of a NSEC/NSEC3 resource record, which is able to >express non-existence of a range of names authoritatively. With this >proposal, it is expected that shorter latency to many of negative >responses as well as some level of mitigation of random sub-domain >attacks (referred to as "Water Torture" attacks). It is also >expected that non-existent TLD queries to Root DNS servers will >decrease. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-fujiwara-dnsop-nsec-aggressiveuse-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-fujiwara-dnsop-nsec-aggressiveuse-03 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-onion-tld-01.txt
Sorry too late to comment, The word "Caching DNS Servers" and "Caching servers" are not defined by DNS RFCs. They should be "full-service resolvers" defined by RFC 1123. # Some authoritative DNS server software have packet cache or hot spot # cache. They may be "caching DNS servers". -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Thanks to Jinmei, Shumon and Mark. From: 神明達哉 jin...@wide.ad.jp While I see what it tries to say and don't disagree with it, I think this is not very accurate. In fact, NXDOMAIN for a.example.com says there is no such name *or any subdomain of it*. So it would still be usable to suppress unnecessary external query for, e.g., foo.a.example.com. I will add some text in next revision. From: Shumon Huque shu...@gmail.com That's indeed the literal meaning of NXDOMAIN, but it turns out most current resolver implementations don't treat it that way. The wording in RFC2308, Section 5 is not entirely precise, but it seems to say that negative answers should be cached only for the exact qname, and not (necessarily) for anything below it. From: Mark Andrews ma...@isc.org Because the consensus at the time was not to support nxdomain synthesis from signed zone (speaketh the author of RFC 2308). I will add texts to update RFC 2308. Extreme care needs to be taken with nxdomain synthesis. You need to choose the correct NSEC records especially for qnames which are the subdomain of the NSEC owner name. The NS bit MUST NOT be set in this case as the presence of the NS bit indicates a delegation. NSEC3 is even more complicted. YES. DLV is only defined to use NSEC signed zones as I wasn't interested in having to working out all the rules for NSEC3. I think the procedure is the same as NSEC3 validation. # and qname minimization discussion is interesting. # It may be listed in draft-ietf-dnsop-root-loopback # as a different approach. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
From: Bob Harold rharo...@umich.edu On Tue, Jul 7, 2015 at 5:20 AM, fujiw...@jprs.co.jp wrote: Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01. https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ ... -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp I am concerned that the AN flag allows for easy zone walking, defeating the purpose of minimal range NSEC records. So I don't think authoritative servers would want to respect it. It's the problem. However, authoritative DNS servers can detect random subdomain attacks. They can generate NSEC resource records with wider range under random subdomain attacks. I am also concerned that random subdomain queries will set the CD bit, if that avoids aggressive negative caching. So I would think that the CD bit should not be allowed to stop aggressive negative caching. Thanks. I will add. Regards, -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-01.txt
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse-01.
https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
* Added reference to DLV {{RFC5074}} and imported some sentences.
* Added Aggressive Negative Caching Flag idea.
* Added detailed algorithms in Appendix.
Please check and comment.
I made a mistake at detailed algorithm part in -01.
I added updated version in this mail and I will update the draft.
NSEC3 validation is difficult for me.
Please check this algorithm.
And where is the pseudo code writing guide ?
~~~
QNAME = the query name;
if (QNAME name entry exists in the cache) {
resolve the query as usual;
// if RRSet (query name and query type) exists in the cache,
// the resolver responds the RRSet from the cache
// Otherwise, the resolver needs to iterate the query.
}
// Find closest enclosing NS RRset in the cache.
// The owner of this NS RRset will be a suffix of the QNAME
//- the longest suffix of any NS RRset in the cache.
SIGNER = closest enclosing NS RRSet of QNAME in the cache;
if (SIGNER zone does not have a special NSEC/NSEC3 data structure) {
Resolve the query as usual;
}
if (SIGNER zone is not signed or not validated) {
Resolve the query as usual;
}
if (SIGNER zone is signed with NSEC) {
// NSEC mode
if (covering NSEC RR of QNAME at SIGNER zone
doesn't exist in the cache) {
Resolve the query as usual.
}
TEST = Find the longest existing domain name of QNAME
from the covering NSEC RR;
if (*.TEST name entry exists in the cache) {
the resolver can generate positive response
or resolve the query as usual;
}
if covering NSEC RR of *.TEST at SIGNER zone exists
in the cache {
the resolver can generate negative response;
}
// Lack of information, need to resolve the query as usual
} else
if (SIGNER zone is signed with NSEC3 and does not use Opt-Out) {
// NSEC3 mode
TEST = SIGNER;
while (TEST != QNAME) {
// if any error happens in this loop, break this loop
UPPER = TEST;
add a label from the QNAME to the start of TEST;
// TEST = label.UPPER
if (TEST name entry exist in the cache) {
continue; // need to check rest of QNAME
}
if (covering NSEC3 of TEST exist in the cache) {
// (non-)terminal name TEST does not exist
if (*.UPPER name entry exist in the cache) {
// TEST does not exist and *.UPPER exist
the resolver can generate positive response;
} else
if (covering NSEC3 of *.UPPER exist in the cache) {
// TEST does not exist and *.UPPER does not exist
the resolver can generate negative response;
}
break; // Lack of information
} else
if (NSEC3 of TEST does not exist in the cache) {
break; // Lack of information
}
// TEST label exist, then need to check rest of QNAME
}
// Lack of information, need to resolve the query as usual
}
Resolve the query as usual
~~~
--
Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback
From: Paul Hoffman paul.hoff...@vpnc.org If resolvers are encouraged to use NSEC records to synthesize NXDOMAIN responses, would there still be any point to this draft? Yes. No one has written up a document on using NSEC records to synthesize NXDOMAIN for the root, and if they do, there will certainly be operational considerations for that that are different than the operational considerations for this draft. I'm not saying one would be better than the other, but I suspect that the operational description of this draft would be easier for an operator to understand. I wroite Aggressive use of NSEC/NSEC3 resource records may decrease queries to Root DNS servers. in draft-fujiwara-dnsop-nsec-aggressiveuse-00 as a side effect. Is it related to root-loopback document? # I will update the draft soon. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt
Akira Kato and I submitted draft-fujiwara-dnsop-nsec-aggressiveuse. If you have interests, please comment. Subject: New Version Notification for draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt From: internet-dra...@ietf.org Date: Mon, 09 Mar 2015 10:20:47 -0700 A new version of I-D, draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt has been successfully submitted by Kazunori Fujiwara and posted to the IETF repository. Name: draft-fujiwara-dnsop-nsec-aggressiveuse Revision: 00 Title: Aggressive use of NSEC/NSEC3 Document date: 2015-03-10 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt Status: https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ Htmlized: http://tools.ietf.org/html/draft-fujiwara-dnsop-nsec-aggressiveuse-00 Abstract: DNS highly depends on cache, however, cache usage of non-existence information was limited to exact matching. This draft proposes the aggressive use of NSEC/NSEC3 resource record, which is able to express non-existence of range of names authoritatively. With this proposal, shorter latency to many of negative response is expected as well as some level of mitigation of random sub-domain attacks (referred to as Water Torture attacks). And more, non-existent TLD queries to Root DNS servers will decrease. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
From: Tony Finch d...@dotat.at It is an interesting draft and I can see why the problem concerns you. The dummy DS is a clever work-around, but it is a pity about the validation bug in Google public DNS. Thanks. I'm not sure that the validation error is a bug or not. I wonder about the possibility of adjusting the rules for caching delegations. Would it make sense to remember that a referral is insecure for the lifetime of the NS RRset, instead of the lifetime of the negative DS answer? This idea requires updating RFC 2308. I'm afraid that when newly registered DS RR will be used if the negative DS answer is cached. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
From: Olafur Gudmundsson o...@ogud.com Your calculations on the amplification are good illustration, but assume that the resolvers use the parental provided NS set, not the child side provided NS set. In the case of google.co.jp. JP side NS has TTL of 1 day but google.co.jp side has is 96 hours (4 days) Unbound resolver has by default of MaxTTL 1 day thus it does not matter in the case of google.co.jp which NS set is stored, but other resolvers do different things. Thanks. Some domain names use shorter NS TTL values. In short I think the simple conclusion is signed domain will see increased DS traffic for unsigned child domains Agree. I would like to know whether the increase of DS queries are observed commonly or not. (with small NCACHE TTL value) -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-ds-query-increase-02
Dear Chairs and WG participants, I updated draft-fujiwara-dnsop-ds-query-increase this Janurary. http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase Recent DS traffic increase seems not high, I did not request time slot of WG meeting. However, Increasing is a fact. Recent DS query graph is here: http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf Please comment to the draft. What should I do about this draft from now on? Regards, -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Draft on rDNS for IPv6: draft-howard-isp-ip6rdns-00
From: Jeremy C. Reed r...@reedmedia.net Now, I'm testing On the Fly generation of PTR and RRs and On the Fly signing using perl + Net::DNS::SEC. I notice it creates a new signature for same look up everytime. So the inception and expiration is increased immediately. It creates a new signature for every query. Would it make sense to possibly attempt to cache these generated signatures for the most frequent requests? Many resolvers don't send the same query while the RRSet is in their cache. The RRSet can be validated in each server. Each resolver may have same PTR and different signature. What problem exist? Or is it better to just have a caching server in front of the On the Fly DNS server? This approach is one solution of performance problem. Or just rely on others to cache (since we assume that won't hit the authoritative again for same query). Also any benchmarks on how fast it can sign on the fly? I tested using queryperf with existing name and type, using 1024bit RSASHA1 ZSK (which is generated by dnssec-keygen), When DO=0, about 541 queries/sec When DO=1, about 193 queries/sec I run it on Xeon 2.8GHz, FreeBSD 7.2 box. It would be great if you can make the newer script available too (the one using Net::DNS::SEC). I put the script on my page as is. http://member.wide.ad.jp/~fujiwara/v6rsec-dnslab.pl I run it as 2001:200:132:6::/64 reverse mapping DNS server. It is very limited prototype. It does not have many necessary functions. It does not have non-existing case (generating NSEC). It copies OPT RR (doesn't check EDNS0 buffer length, I think). # NSEC may be generated because next owner name is next IPv6 address # and type bitmap have PTR only. Regards, -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dynamically Generated PTR, was Re: ... rDNS for IPv6...
From: Edward Lewis ed.le...@neustar.biz Performance problem will be solved by better code and new hardware. In my opinion, Dynamically Generate PTR When Queried works well. I have to ask based on the experience I had with wildcards, how does this work with: 1) Zone transfers? Zone transfer is not required, not defined on my idea. If I need multiple servers, I run same program with same DNSSEC key file on each server. Each server generates same PTRs and different RRSIG (different Signature Inception, Signature Expiration). 2) Dynamic update? Generated hostname is fixed for each IPv6 address on my idea. All IPv6 address have reverse mapped hostname. Dynamic update is not used. 3) DNSSEC? NSEC may be generated because next owner name is next IPv6 address and type bitmap have PTR only. Then, if the server has private keys, then RRSIG is easily generated. Problems are ... - No good code (writing better code solves this problem.) - Performance (better code and new hardware solve this problem.) - Private keys are shared on each authoritative server. -- Kazunori Fujiwara, JPRS fujiw...@jprs.co.jp ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
