Re: [DNSOP] AD review of draft-ietf-dnsop-7706bis-07
No reason to do it now; it can wait. b On Fri, Feb 14, 2020 at 12:57 AM Warren Kumari wrote: > > > On Fri, Feb 14, 2020 at 7:42 AM Barry Leiba > wrote: > >> I am handling this document as responsible AD because Warren, who would >> otherwise do it, is irresponsible an author of the >> document. >> >> I have only two comments, below, that are total nits, and I will request >> last call as soon as I send this message. Nice work, as always, Warren and >> Paul. >> > > Awesome, thank you. > Please let me / us know if you would like a new version posted with the > below comments addressed, or if you would prefer we wait until after LC > ends. > > Thanks again, > W > > > >> Barry >> >> — Section 1.2 — >> It’s a small thing, but please use the BCP 14 boilerplate from RFC 8174 >> exactly (you left out “NOT RECOMMENDED” here). >> >> — Section 4 — >> >>As stated in Section 1, this design explicitly only allows the local >>copy of the root zone information to be available only from resolvers >> >> Nit: you don’t need both “only”s. I suggest removing the first one. >> >> -- > 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
Re: [DNSOP] AD review of draft-ietf-dnsop-7706bis-07
On Fri, Feb 14, 2020 at 7:42 AM Barry Leiba wrote: > I am handling this document as responsible AD because Warren, who would > otherwise do it, is irresponsible an author of the > document. > > I have only two comments, below, that are total nits, and I will request > last call as soon as I send this message. Nice work, as always, Warren and > Paul. > Awesome, thank you. Please let me / us know if you would like a new version posted with the below comments addressed, or if you would prefer we wait until after LC ends. Thanks again, W > Barry > > — Section 1.2 — > It’s a small thing, but please use the BCP 14 boilerplate from RFC 8174 > exactly (you left out “NOT RECOMMENDED” here). > > — Section 4 — > >As stated in Section 1, this design explicitly only allows the local >copy of the root zone information to be available only from resolvers > > Nit: you don’t need both “only”s. I suggest removing the first one. > > -- 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] AD review of draft-ietf-dnsop-7706bis-07
I am handling this document as responsible AD because Warren, who would otherwise do it, is irresponsible an author of the document. I have only two comments, below, that are total nits, and I will request last call as soon as I send this message. Nice work, as always, Warren and Paul. Barry — Section 1.2 — It’s a small thing, but please use the BCP 14 boilerplate from RFC 8174 exactly (you left out “NOT RECOMMENDED” here). — Section 4 — As stated in Section 1, this design explicitly only allows the local copy of the root zone information to be available only from resolvers Nit: you don’t need both “only”s. I suggest removing the first one. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] QUIC and udp options
On Fri, Feb 14, 2020, at 05:56, Paul Vixie wrote: > something of this form will likely be created, in order to support quic, a > new > udp based transport protocol which is expected to be used by http/3. Not wanting to distract from Paul's request for consideration of the UDP options draft. However, this point seems to be a stretch. This has only been discussed very briefly on the QUIC mailing list in relation to a non-working group proposal. From my perspective, I don't see QUIC creating a dependency on UDP options in any way. So "will likely" is really only speculation. I suggest that if you are interested in this topic we take this to the QUIC list. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] udp options draft
as most dns technologists are aware, ip and tcp have options, and udp does not. there is a draft: https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ which has been ongoing since 2015, which proposes to add options to udp: Internet-DraftTransport Options for UDP September 2019 IP transport payload <-> ++-+--+--+ | IP Hdr | UDP Hdr | UDP user data| surplus area | ++-+--+--+ <--> UDP Length Figure 3 IP transport payload vs. UDP Length this relies on the unaccounted octets which follow the udp header and data, inside the ip length but outside the udp length. this is moderately controversial since it's a deliberate layering violation, but it may be more workable than creating a new "udp2" ip datagram type, due to middleboxes. the options proposed are: Internet-DraftTransport Options for UDP September 2019 KindLengthMeaning -- 0* - End of Options List (EOL) 1* - No operation (NOP) 2* 3 Option checksum (OCS) 3* 6 Alternate checksum (ACS) 4* 4 Lite (LITE) 5* 4 Maximum segment size (MSS) 6* 8/10 Fragmentation (FRAG) 7 10Timestamps (TIME) 8 (varies) Authentication and Encryption (AE) 9 6 Request (REQ) 10 6 Response (RES) 11-126 (varies) UNASSIGNED (assignable by IANA) 127-253 RESERVED 254 N(>=4)RFC 3692-style experiments (EXP) 255 Reserved since dns has been the greatest single user of wide area udp, i suggest that those in dnsop who have an interest in this topic, please review this draft. something of this form will likely be created, in order to support quic, a new udp based transport protocol which is expected to be used by http/3. -- Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Solicit feedback on the problems of DNS for Cloud Resources described by the draft-ietf-rtgwg-net2cloud-problem-statement
Linda Dunbar wrote: >Thank you very much for suggesting using the Globally unique domain name and >having subdomains not resolvable outside the organization. >I took some of your wording into the section. Please let us know if the >description can be improved. Thanks. I think that covers a reasonable approach to avoid collisions and ensure resolution and validation occur as desired by the organization with administrative control over the domains used. I realized I accidentally omitted a 'when' that makes the last sentence scan properly. In the process, I noticed what looked like a couple of other minor edits that could improve readability. I did not see any substantive issues with the revised text but did include those minor proposed edits below. Scott 3.4. DNS 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. When applications in one Cloud need to communicate 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 can be forwarded to the DNS service in another Cloud. Needless to say, configuration can be complex depending on the application communication patterns. However, even with carefully managed policies and configurations, collisions can still occur. 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 it can't work. Therefore, it is better to use the global domain name even when an organization does not make all its namespace globally resolvable. An organization's globally unique DNS can include subdomains that cannot be resolved at all outside certain restricted paths, zones that resolve differently based on the origin of the query and zones that resolve the same globally for all queries from any source. Globally unique names do not equate to globally resolvable names or even global names that resolve the same way from every perspective. Globally unique names do prevent any possibility of collision at the present or in the future and they make DNSSEC trust manageable. It's not as if there is or even could be some sort of shortage in available names that can be used, especially when subdomains and the ability to delegate administrative boundaries are considered. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-resolver-information-01.txt
That would be clearer or possibly just change that first "MUST NOT" to "Authoritative only servers MUST NOT answer queries that are defined in this protocol." As the advice that: "if the resolver can be configured to also be authoritative for some zones, it can use that configuration to actually be authoritative for the addresses on which it responds." Surely means that it is answering a query made to the authoritative part so would again be contradicted by saying: "MUST only answer queries that are intended for the recursive resolver portion of the server." Sent from Mailbird [http://www.getmailbird.com/?utm_source=Mailbirdutm_medium=emailutm_campaign=sent-from-mailbird] On 12/02/2020 16:50:16, Paul Hoffman wrote: On Feb 12, 2020, at 1:59 AM, Robert Mortimer wrote: > > I may be missing something obvious but this draft seems to contradict it self > as it says in the introduction: > > "Authoritative servers MUST NOT answer queries that are defined in this > protocol." > > and then goes onto say in section 2: > > "if the resolver can be configured to also be authoritative for some zones, > it can use that configuration to actually be authoritative for the addresses > on which it responds." > > I also wonder what the correct behavior is for a server which is both > recursive and authoritative - is it prohibited from supporting this protocol > by that first "MUST NOT"? Good call. Would it make both parts clearer if the introduction instead said: Because the information returned in this protocol only applies to recursive resolvers, servers that are acting as both authoritative servers and recursive resolvers MUST only answer queries that are intended for the recursive resolver portion of the server. Servers that are only authoritative servers MUST NOT answer queries that are defined in this protocol. --Paul Hoffman___ 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
