Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
On Tuesday, 11 February 2020 22:21:05 UTC Linda Dunbar wrote: > ... > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ > > During IETF 106, we received comments that the document should cover the > problems associated with DNS service by different Cloud Operators for > Enterprise to utilize Cloud Resources even though DNS is not within the > scope of IETF routing area. We greatly appreciate DNS experts to provide > comments to our description. you've addressed this e-mail to two mailing lists (dnsop@ and rtgwg@) which you are a member of, and both will accept and publish your e-mail. however, some of us here are members of only one of those mailing lists (me, dnsop@), and won't be able to participate in whatever threads may occur on the other mailing list (me, rtgwg@). so, i am removing rtgwg@ from my reply here. > 3.4DNS for Cloud Resources > DNS name resolution is essential for on-premises and cloud-based resources. > For customers with hybrid workloads, which include on-premises and > cloud-based resources, extra steps are necessary to configure DNS to work > seamlessly across both environments. ... you may not realize it, but that is an astonishing statement. i'll explain below. > ... Cloud operators have their own DNS to > resolve resources within their Cloud DCs and to well-known public domains. > Cloud's DNS can be configured to forward queries to customer managed > authoritative DNS servers hosted on-premises, and to respond to DNS queries > forwarded by on-premises DNS servers. ... while this is an obvious approach for each and every cloud service operator, it depends on lock-in, is not multi-cloud ready, and cannot be made so within the DNS paradigm or using any of the common layers added to that paradigm. DNS is currently viral, if you can look up anything at all global, then you can look up everything global. cutouts for non-global names are quite common especially when accompanied by NAT. however, collisions cannot be managed this way. you can have some names (like .cloud or .corp or .internal) visible within your network as long as they aren't also used globally, because there is no way to discriminate which collision-name is wanted, other than by client-ip address and even that is nonstandard, relying on DNS vendor extensions. similarly, if you use an internal name like .cloud and then want your services to be available via or within some other cloud provider which also uses ..cloud, then there can be no discriminator, and so it can't work. this is why most names are global -- there can be no collisions that way. even with large NAT buildouts, it's become common to use the global domain name both internally and externally, and to simply provide different views of that global domain name internally vs. externally. this was explored 25 years ago: http://family.redbarn.org/~vixie/proxynet.pdf can you explain why the simple answer (use unique global names for each cloud resource) isn't reachable by your proposal? > ... For enterprises utilizing Cloud > services by different cloud operators, it is necessary to establish > policies and rules on how/where to forward DNS queries to. ... if the names are local, and never collide, this has been possible in one vendor's DNS implementation for about 20 years, and is variously possible in others. however, this became much more difficult in the DNSSEC era. if the names are local and may collide, no coherent set of policies or rules about how/where to forward DNS queries will be possible. if the names are global then they will be unique and DNS itself will handle the decision of how to route questions to the right authority servers. > ... When > applications in one Cloud need to communication with applications hosted in > another Cloud, there could be DNS queries from one Cloud DC being forwarded > to the enterprise's on premise DNS, which in turn be forwarded to the DNS > service in another Cloud. Needless to say, configuration can be complex > depending on the application communication patterns. it is that complexity that prohibits scale. are you suggesting that the DNS paradigm be expanded to include automated context-dependent naming? i imagine it would look something like BGP4, but for names rather than addresses. but first i hope you can explain why the simpler and existing viral DNS paradigm (all names are global and unique) is unacceptable for your purpose. thanks for bringing your question here, and thanks to otherpaul and suz for what appears to have been vital outreach. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-01.txt
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 : DNS Resolver Information Self-publication Authors : Puneet Sood Roy Arends Paul Hoffman Filename: draft-ietf-dnsop-resolver-information-01.txt Pages : 9 Date: 2020-02-11 Abstract: This document describes methods for DNS resolvers to self-publish information about themselves, such as whether they perform DNSSEC validation or are available over transports other than what is defined in RFC 1035. The information is returned as a JSON object. The names in this object are defined in an IANA registry that allows for light-weight registration. Applications and operating systems can use the methods defined here to get the information from resolvers in order to make choices about how to send future queries to those resolvers. There is a GitHub repo for this draft where pull requests can be issued: https://github.com/DNSOP/draft-ietf-dnsop-resolver- information However, starting issues on the WG mailing list is preferred. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-resolver-information/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-resolver-information-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-resolver-information-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-resolver-information-01 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] I-D Action: draft-ietf-dnsop-terminology-ter-01.txt
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 : Terminology for DNS Transports and Location Author : Paul Hoffman Filename: draft-ietf-dnsop-terminology-ter-01.txt Pages : 3 Date: 2020-02-11 Abstract: This document adds terms and abbreviations to "DNS Terminology" (RFC 8499) that relate to DNS running over various transports, as well as terms and abbreviations for DNS resolution at traditional and non- traditional locations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-ter/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-terminology-ter-01 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-terminology-ter-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-terminology-ter-01 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] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Many thanks to Paul Ebersman and Suzanne Woolf discussion during NANOG about the deep intricate issues around DNS and learned that DNSOP is the right group to solicit feedback about DNS issues for utilizing hybrid Clouds. https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/ describes the problems that enterprises face today when interconnecting their branch offices with dynamic workloads in third party data centers (a..k.a. Cloud DCs). There can be many problems associated with network connecting to or among Clouds, many of which probably are out of the IETF scope. The objective of this document is to identify some of the problems that need additional work in IETF Routing area. Other problems are out of the scope of this document. During IETF 106, we received comments that the document should cover the problems associated with DNS service by different Cloud Operators for Enterprise to utilize Cloud Resources even though DNS is not within the scope of IETF routing area. We greatly appreciate DNS experts to provide comments to our description. 3.4DNS for Cloud Resources DNS name resolution is essential for on-premises and cloud-based resources. For customers with hybrid workloads, which include on-premises and cloud-based resources, extra steps are necessary to configure DNS to work seamlessly across both environments. Cloud operators have their own DNS to resolve resources within their Cloud DCs and to well-known public domains. Cloud's DNS can be configured to forward queries to customer managed authoritative DNS servers hosted on-premises, and to respond to DNS queries forwarded by on-premises DNS servers. For enterprises utilizing Cloud services by different cloud operators, it is necessary to establish policies and rules on how/where to forward DNS queries to. When applications in one Cloud need to communication with applications hosted in another Cloud, there could be DNS queries from one Cloud DC being forwarded to the enterprise's on premise DNS, which in turn be forwarded to the DNS service in another Cloud. Needless to say, configuration can be complex depending on the application communication patterns. Thank you very much. Linda Dunbar ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt
Dear DNSOP, I asked Dmitry to please bring this document to DNSOP for discussion; DNSOP is where we generally discuss the use of different algorithms in DNSSEC. I'd appreciate it if the discussion can be kept to the DNS / DNSSEC parts of the document (using the algorithms for DNSKEY, RRSIG, and DS resource records), and not the crypto itself (CFRG / others are the place for that). W On Tue, Feb 11, 2020 at 12:06 PM Dmitry Belyavsky wrote: > > Dear DNSOP mailing list members, > > Please see the announcement of the draft describing using the > GOST 2012 hash and digital signature algorithms for DNSSec. > > The document pretends to update 2 IANA registries. > > The 1st one implies the "RFC required" status: > https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 > so there are no problems with it. > > The 2nd one, unfortunately for me, requires "Standard action" status > https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 > > so it makes impossible to pass it via ISE. > > I kindly ask to review the draft to make possible assigning the IANA codes > for the algorithms. > The implementation of the draft is also available, see > https://github.com/beldmit/ldns/tree/gost2012 for details. > > Many thanks! > > -- Forwarded message - > From: > Date: Sun, Feb 9, 2020 at 1:43 PM > Subject: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt > To: Vasily Dolmatov , Dmitry Belyavskiy > > > > > A new version of I-D, draft-belyavskiy-rfc5933-bis-01.txt > has been successfully submitted by Dmitry Belyavskiy and posted to the > IETF repository. > > Name: draft-belyavskiy-rfc5933-bis > Revision: 01 > Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG > Resource Records for DNSSEC > Document date: 2020-02-09 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-belyavskiy-rfc5933-bis-01.txt > Status: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ > Htmlized: https://tools.ietf.org/html/draft-belyavskiy-rfc5933-bis-01 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-belyavskiy-rfc5933-bis > Diff: > https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-rfc5933-bis-01 > > Abstract: >This document describes how to produce digital signatures and hash >functions using the GOST R 34.10-2012 and GOST R 34.11-2012 >algorithms for DNSKEY, RRSIG, and DS resource records, for use in the >Domain Name System Security Extensions (DNSSEC). > > > > > 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 > > > > -- > SY, Dmitry Belyavsky > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt
Dear DNSOP mailing list members, Please see the announcement of the draft describing using the GOST 2012 hash and digital signature algorithms for DNSSec. The document pretends to update 2 IANA registries. The 1st one implies the "RFC required" status: https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml#dns-sec-alg-numbers-1 so there are no problems with it. The 2nd one, unfortunately for me, requires "Standard action" status https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1 so it makes impossible to pass it via ISE. I kindly ask to review the draft to make possible assigning the IANA codes for the algorithms. The implementation of the draft is also available, see https://github.com/beldmit/ldns/tree/gost2012 for details. Many thanks! -- Forwarded message - From: Date: Sun, Feb 9, 2020 at 1:43 PM Subject: New Version Notification for draft-belyavskiy-rfc5933-bis-01.txt To: Vasily Dolmatov , Dmitry Belyavskiy < beld...@gmail.com> A new version of I-D, draft-belyavskiy-rfc5933-bis-01.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-rfc5933-bis Revision: 01 Title: Use of GOST 2012 Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC Document date: 2020-02-09 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy-rfc5933-bis-01.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-rfc5933-bis-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy-rfc5933-bis Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-rfc5933-bis-01 Abstract: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). 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 -- SY, Dmitry Belyavsky ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DNSOP at IETF 107: call for agenda items and key dates
Hi, We’re a few weeks away from IETF 107 in Vancouver, BC, so your chairs are starting to put together the DNSOP meeting. First, this note is our first call for agenda items. Send your requests to dnsop-cha...@ietf.org. The chairs will be reaching out to some draft authors about updates and open discussion items so we can use f2f meeting time to resolve issues and make decisions about advancing them (adoption, WGLC, etc.) But if you’ve got a draft that the WG is discussing or you’d like the WG to discuss, don’t be shy! The drafts deadline for Vancouver is 9 March. We only have a couple of days after the drafts deadline to post the WG agenda, so please: if you want your draft on the WG agenda, try to submit it early enough that the WG has time to start discussing it and we’ve got a little bit of time to gauge interest and direction. A few key dates (the full list is at: https://datatracker.ietf.org/meeting/107/important-dates/) 2020-02-28 (Friday): Final agenda to be published. 2020-03-09 (Monday): Internet Draft submission cut-off (for all drafts, including -00) by UTC 23:59. Upload using the ID Submission Tool. 2020-03-11 (Wednesday): Draft Working Group agendas due by UTC 23:59. 2020-03-16 (Monday): Revised Working Group agendas due by UTC 23:59. Thanks and see you in Vancouver, Suzanne, Tim, and Benno ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?
Dick Franks wrote: > > The troublesome length bytes can be avoided by (ab)using a generic URI > RR instead: Indeed :-) The reason I wanted to make the attack work with TXT was the example scenario targeted ACME dns-01, so it's more pointed if we imagine the attacker has very limited access to update the zone. Also it's a fun opportunity to try smuggling arbitrary binary data through a parser that you might not expect would allow it. Tony. -- f.anthony.n.finchhttp://dotat.at/ Shannon: Westerly 7 to severe gale 9, occasionally storm 10 at first in north, backing southerly 4 to 6 later. High or very high, occasionally very rough later. Occasional rain or showers. Moderate, occasionally poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Unknown DNS RDATA type presentation syntax vs. e.g. TXT records?
On Mon, 10 Feb 2020 at 16:19, Tony Finch wrote: >8 > When I was working out how a SHA-1 attack could work with TXT records, > (https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html) > one of the problems was that the collision blocks in the best attack so > far are 588 bytes, which is too big to fit into a single TXT string. So > there will be length bytes inside the collision blocks which can't easily > be controlled by the attacker. The solution is to append 255 zero bytes > which is enough to fill the tail end of any string specified by the last > length byte in the collision blocks, and any excess zero bytes get treated > as a sequence of empty strings. The troublesome length bytes can be avoided by (ab)using a generic URI RR instead: 64kilobeef. TYPE256 \# 8 deadbeefdeadbeef which allows arbitrary content (3 < length < ~64k). Note that the URI target text occupies the remaining RDATA after the weight field. -- Dick ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
