Re: [DNSOP] [Editorial Errata Reported] RFC8552 (6772)
On 12/3/2021 12:35 AM, RFC Errata System wrote: This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. Verified. It is, indeed, a typo. It should be Service4 and not Service 4. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Lars Eggert's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
> On Nov 29, 2021, at 11:51 PM, Lars Eggert wrote: > > >> I dont necessarily agree that operating systems alone do a very good job >> of preventing DOS conditions. It is possible that Im not up-to-date on >> the latest and greatest in terms of operating system features, but I think >> historically applications have fared better when they manage their own >> connections. For example, can we realistically expect the OS to know which >> idle connections should be closed? > > The OS will certainly try to close sufficient connections under DDoS to > remain operational. But if an application wants to see connections closed > according to a certain policy - and DNS servers probably would - they need to > actively engage. Maybe that's the rationale here? > Yes, that is the rationale. I’ve added a new sentence to the end of this paragraph along those lines: Operators of DNS server software SHOULD be aware that operating system and application vendors MAY impose a limit on the total number of established connections. These limits may be designed to protect against DDoS attacks or performance degradation. Operators SHOULD understand how to increase these limits if necessary, and the consequences of doing so. Limits imposed by the application SHOULD be lower than limits imposed by the operating system, so that the application can apply its own policy to connection management, such as closing the oldest idle connections first. >> >>> Section 4.2. , paragraph 3, comment: DNS server software SHOULD provide a configurable timeout for idle TCP connections. For very busy name servers this might be set to a low value, such as a few seconds. For less busy servers it might be set to a higher value, such as tens of seconds. >>> >>> Ditto. >> >> In this case all of the open source implementations I surveyed have this >> limit enabled by default. > > It might be useful to add a brief note similar to the one above here as well. Okay, I’ve done so in this paragraph. Second and third sentences are new: DNS server software SHOULD provide a configurable timeout for idle TCP connections. This can be used to free up resources for new connections and to ensure that idle connections are eventually closed. At the same time, it possibly limits client performance while leaving some TCP resources untilizied. For very busy name servers this might be set to a low value, such as a few seconds. For less busy servers it might be set to a higher value, such as tens of seconds. DNS clients and servers SHOULD signal their timeout values using the edns-tcp-keepalive option [RFC7828]. > > Thanks, > Lars > Thank you! DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
> On Nov 8, 2021, at 4:24 PM, Joe Abley wrote: > > Caution: This email originated from outside the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > On Nov 8, 2021, at 17:35, Wessels, Duane > wrote: > >> Is this better? >> >> The use of TLS places even stronger operational burdens on DNS >> clients and servers. Cryptographic functions for authentication and >> encryption requires additional processing. > > Require, not requires. I know, I know. Fixed! > >> Unoptimized connection >> setup with TLS 1.3 [RFC8446] takes one additional round-trip compared >> to TCP. Connection setup times can be reduced with TCP Fast Open, >> and TLS False Start [RFC7918]. TLS session resumption does not >> reduce round-trip latency becase no application profile for use of >> TLS 0-RTT data with DNS has been published at the time of this >> writing. However, TLS session resumption can reduce the number of >> cryptographic operations. > > [...] > >> Agreed, hopefully this is better: >> >> o Authoritative servers MUST support and service TCP for receiving >> queries, so that resolvers can reliably receive responses that are >> larger than what fits in a single UDP packet. > > RFC 6891 anticipates reassembly and doesn't advise against setting a UDP > payload size that would cause fragmentation (although it mentions that people > should be careful). So "single UDP packet" seems a bit awkward, especially > since in principle the size limit is 0x octets in both the UDP header and > the corresponding EDNS(0) pseudo-header. > > This paragraph (and the ones that follow) seem like they are implying that > large responses are the only reason to use TCP (which is surely just a > side-effect of wording; I'm not suggesting the authors are unaware of other > reasons). Using truncated responses as an example seems fine though. > > I don't think the taxonomy of "authoritative servers", "recursive servers" > and "forwarders" is necessarily complete. The terminology in common usage is > not tightly bound by common sense, and there is an apparently unlimited > supply of words and phrases that people use to mean "a DNS thing attached to > a network". > > This seems like it could be a job for "initiators" and "responders", except > that in this case I think we're really talking about all DNS implementations, > regardless of function. Hooray! Bullet dodged, maybe. > > How about something like: > > o All DNS implementations, regardless of function, MUST support and service > TCP for sending and receiving queries, e.g. to accommodate the sending and > receiving of DNS messages that are too large to handle using UDP without > truncation. Thanks for pointing this out. I agree that “single UDP packet” is problematic and we missed this detail before. Here’s how this text appeared in version 13: o Authoritative servers MUST support and service all TCP queries so that they do not limit the size of responses to what fits in a single UDP packet. o Recursive servers (or forwarders) MUST support and service all TCP queries so that they do not prevent large responses from a TCP- capable server from reaching its TCP-capable clients. Based on Ben’s comments, I then proposed this: o Authoritative servers MUST support and service TCP for receiving queries, so that resolvers can reliably receive responses that are larger than what fits in a single UDP packet. o Recursive servers (and forwarders) MUST support and service TCP for receiving queries, so their TCP-capable clients can reliably receive responses that are larger than what fits in a single UDP packet. o Recursive servers (and forwarders) MUST support TCP for sending queries, so that they can retry truncated UDP responses as necessary. And based on your further suggestions I think it makes sense to combine authoritative and recursive together, but keep clients as a separate bullet: o DNS servers (including forwarders) MUST support and service TCP for receiving queries, so that clients can reliably receive responses that are larger than what either side considers too large for UDP. o DNS clients MUST support TCP for sending queries, so that they can retry truncated UDP responses as necessary. “what either side considers too large for UDP” is an oblique reference to EDNS(0) UDP buffer size parameters. How does that strike you? DW > > > Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC - is there an appetite for Clarifications RFC?
On 30. 11. 21 19:38, John Levine wrote: This blog post has been making the rounds. Since it is about a sequence of DNS operational failures, it seems somewhat relevant here. https://slack.engineering/what-happened-during-slacks-dnssec-rollout/ tl;dr first try was rolled back due to what turned out to be an unrelated failure at some ISP second try was rolled back when they found they had a CNAME at a zone apex, which they had never noticed until it caused DNSSEC validation errors. third try was rolled back when they found random-looking failures that they eventually tracked down to bugs in Amazon's Route 53 DNS server. They had a wildcard with A but not records. When someone did an query, the response was wrong and said there were no records at all, not just no records. This caused failures at 8.8.8.8 clients since Google does aggressive NSEC, not at 1.1.1.1 because Cloudflare doesn't. They also got some bad advice, e.g., yes the .COM zone adds and deletes records very quickly, but that doesn't mean you can unpublish a DS and just turn off DNSSEC because its TTL is a day. Their tooling somehow didn't let them republish the DNSKEY at the zone apex that matched the DS, only a new one that didn't. It is clear from the blog post that this is a fairly sophisticated group of ops people, who had a reasonable test plan, a bunch of test points set up in dnsviz and so forth. Neither of these bugs seem very exotic, and could have been caught by routine tests. Can or should we offer advice on how to do this better, sort of like RFC 8901 but one level of DNS expertise down? During DNS OARC 36, there were talks about an opportunity to write "Clarifications" RFC. Personally I think the current RFC are clear how NSEC(3) bitmaps should look like, but I can also see that making sense various types of "NSEC lies", "type shotguns", etc. and their consequences requires way more research then reading RFC 4034. Are there people on this list interested working on this? I can contribute ideas and some proto-text, but as you can see for yourself someone needs to translate my texts to proper English so I should not be a document editor. -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] How Slack didn't turn on DNSSEC
On 01. 12. 21 12:07, Tim Wicinski wrote: What I noticed in reading this nice write up was the warning image they missed in the Route53 console because of the automation they use. But most folks use automation/tooling/etc in their workflow, and catching those warnings via automation is a bit tricky. Right after this happened several different teams looking to sign their zones got a little nervous. This writeup helps to show people how things can break, but also, there is a great set of testing methods to assist others. Mark's comments about adding tests in DNSVIZ would be pretty great. It is already implemented in DNSViz since December 2020 (so a year+ before the Slack outage), but it is not shown by default: https://github.com/dnsviz/dnsviz/issues/76#issuecomment-985331543 -- Petr Špaček ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Editorial Errata Reported] RFC8552 (6772)
The following errata report has been submitted for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6772 -- Type: Editorial Reported by: Robert Royals Section: 2 Original Text - Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service 4, and _authority would be listed in the IANA registry. Corrected Text -- Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service4, and _authority would be listed in the IANA registry. Notes - Typographical error with an unwanted space character between "_service" and "4" Instructions: - This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
