[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-glueless-01.txt
Hi, DNSOP folks, I have been working on the "unsigned glue record" problem (and related "unsigned NS record" problem). This draft is mostly informational, and does not actually require any protocol changes. It might even be worth making a BCP, but I'll leave that up to the WG to decide. I think this is relatively widely applicable, even though it was originally motivated by a problem that needed to be solved within DPRIVE. (That problem is the subject of a draft I will be posting in DPRIVE, for those interested.) I think it's fairly straightforward, but it is difficult to tell without getting feedback, so please let me know what you think. Brian Dickson -- Forwarded message - From: Date: Fri, Sep 17, 2021 at 1:20 PM Subject: New Version Notification for draft-dickson-dnsop-glueless-01.txt To: Brian Dickson A new version of I-D, draft-dickson-dnsop-glueless-01.txt has been successfully submitted by Brian Dickson and posted to the IETF repository. Name: draft-dickson-dnsop-glueless Revision: 01 Title: Operating a Glueless DNS Authority Server Document date: 2021-09-17 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-01.txt Status: https://datatracker.ietf.org/doc/draft-dickson-dnsop-glueless/ Html: https://www.ietf.org/archive/id/draft-dickson-dnsop-glueless-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-glueless Diff: https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-glueless-01 Abstract: This Internet Draft proposes a method for protecting authority servers against MITM and poisoning attacks, using a domain naming strategy to not require glue A/ records and use of DNSSEC. This technique assumes the use of validating resolvers. MITM and poisoning attacks should only be effective/possible against unsigned domains. However, until all domains are signed, this guidance is relevant, in that it can limit the attack surface of unsigned domains. This guidance should be combined with [I-D.dickson-dnsop-ds-hack] The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt
Hi, DNSOP folks, I have been working on the "unsigned NS record" problem (and related "unsigned glue record" problem). I think this is relatively widely applicable, even though it was originally motivated by a problem that needed to be solved within DPRIVE. (That problem is the subject of a draft I will be posting in DPRIVE, for those interested.) I think it's fairly straightforward, but it is difficult to tell without getting feedback, so please let me know what you think. Brian Dickson -- Forwarded message - From: Date: Fri, Sep 17, 2021 at 1:29 AM Subject: New Version Notification for draft-dickson-dnsop-ds-hack-01.txt To: Brian Dickson A new version of I-D, draft-dickson-dnsop-ds-hack-01.txt has been successfully submitted by Brian Dickson and posted to the IETF repository. Name: draft-dickson-dnsop-ds-hack Revision: 01 Title: DS Algorithms for Securing NS and Glue Document date: 2021-09-17 Group: Individual Submission Pages: 6 URL: https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.txt Status: https://datatracker.ietf.org/doc/draft-dickson-dnsop-ds-hack/ Html: https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-01.html Htmlized: https://datatracker.ietf.org/doc/html/draft-dickson-dnsop-ds-hack Diff: https://www.ietf.org/rfcdiff?url2=draft-dickson-dnsop-ds-hack-01 Abstract: This Internet Draft proposes a mechanism to encode relevant data for NS records on the parental side of a zone cut by encoding them in DS records based on a new DNSKEY algorithm. Since DS records are signed by the parent, this creates a method for validation of the otherwise unsigned delegation records. Notably, support for updating DS records in a parent zone is already present (by necessity) in the Registry-Registrar-Registrant (RRR) provisioning system, EPP. Thus, no changes to the EPP protocol are needed, and no changes to registry database or publication systems upstream of the DNS zones published by top level domains (TLDs). This NS validation mechanism is beneficial if the name server _names_ need to be validated prior to use. The IETF Secretariat ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] [Last-Call] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
On Fri, Sep 17, 2021 at 3:47 PM John Kristoff wrote: > On Mon, 13 Sep 2021 21:24:37 -0400 > Warren Kumari wrote: > > > As Robert Sparks helpfully pointed out on last-call list, I was only > > talking about this "particular potential BCP updating a particular > > Informational RFC both in the IETF stream.". > > Hi Warren et al., > > I have this in the appendix: > >The informational document [RFC1536] states UDP is the "chosen >protocol for communication though TCP is used for zone transfers." >That statement should now be considered in its historical context and >is no longer a proper reflection of modern expectations. > > The "historical context" notion is my interpretation of how to handle > that early document's statement. Is this reasonable? Should I change > this? > > Nah, I think that that is perfectly reasonable. W > John > -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- E. W. Dijkstra ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] [Last-Call] Artart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
On Mon, 13 Sep 2021 21:24:37 -0400 Warren Kumari wrote: > As Robert Sparks helpfully pointed out on last-call list, I was only > talking about this "particular potential BCP updating a particular > Informational RFC both in the IETF stream.". Hi Warren et al., I have this in the appendix: The informational document [RFC1536] states UDP is the "chosen protocol for communication though TCP is used for zone transfers." That statement should now be considered in its historical context and is no longer a proper reflection of modern expectations. The "historical context" notion is my interpretation of how to handle that early document's statement. Is this reasonable? Should I change this? John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Tsvart last call review of draft-ietf-dnsop-dns-tcp-requirements-12
> On Sep 7, 2021, at 9:42 AM, Mirja Kuehlewind wrote: > > Thanks for the updates! One quick comment below. > >> On 7. Sep 2021, at 18:23, Wessels, Duane wrote: >> >>> On Aug 25, 2021, at 8:51 AM, Mirja Kühlewind via Datatracker >>> wrote: >>> >>> And a more general comment on section 4.2: this section takes about various >>> limits but doesn't recommend any values. I understand that there is not a >>> one-fits-all solution here but not knowing how to set these values correctly >>> might scared people aways from supporting TCP. So I think having a >>> discussion >>> either of default values or how to derives these values based on a certain >>> configuration would be a very valuable contribution in this document. >> >> I've added some recommendations to the paragraphs in section 4.2. >> >> For the limit on total number of connections: "Absent any other information, >> 150 is a reasonable value for this limit in most cases." >> >> For the limit on connections per source address: "Absent any other >> information, 25 is a reasonable value for this limit in most cases." >> >> For the timeout on idle connections: "Absent any other information, 10 >> seconds is a reasonable value for this timeout in most cases." > > I think it would also make sense to explain a bit more why these values were > taken and what considerations/“other information" can be used to make a > different decisions. I know that might not be fully straight-forward but just > providing “random” numbers might also only provide limited value. > > Mirja Mirja, I have gathered some information from the open source implementations and written a new section to talk about defaults and recommended values (below). The full document and diff from previous can be found in our github repo https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/tree/master/Versions DW 4.5. Defaults and Recommended Limits A survey of features and defults was conducted for popular open source DNS server implementations at the time of writing. This section documents those defaults and makes recommendations for configurable limits that can be used in the absence of any other information. Any recommended values in this document are only intended as a starting point for administrators that are unsure what sorts of limits might be reasonable. Operators SHOULD use application-specific monitoring, system logs, and system monitoring tools to gauge whether their service is operating within or exceeding these limits, and adjust accordingly. Most open sorcue DNS server implementations provide a configurable limit on the total number of established connections. Default values range from 20 to 150. In most cases, where the majority of queries take place over UDP, 150 is a reasonable limit. For services or enviroments where most queries take place over TCP or TLS, 5000 is a more appropriate limit. Only some open source implementations provide a way to limit the number of connections per source IP address or subnet, but the default is to have no limit. For environments or situations where it may be neccessary to enable this limit, 25 connections per source IP address is a reasonable starting point. The limit should be increased when aggregated by subnet, or for services where most queries take place over TCP or TLS. Most open source implementations provide a configurable idle timeout on connections. Default values range from 2 to 30 seconds. In most cases, 10 seconds is a reasonable default for this limit. Longer timeouts improve connection reuse, but busy servers may need to use a lower limit. Only some open source implementations provide a way to limit the number of transactions per connection, but the default is to have no limit. This document does not offer advice on particular values for such a limit. Only some open source implementations provide a way to limit the duration of connection, but the default is to have no limit. This document does not offer advice on particular values for such a limit. smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
