[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE
On Fri, Jul 5, 2024 at 2:42 PM Paul Hoffman wrote: > On Jul 5, 2024, at 14:33, Erik Kline wrote: > > > > "expect to find two strings" > > > > I didn't see this specified so thought I'd ask: what is the separator of > the two strings? ASCII whitespace, or ...? > > Welcome to RFC 1035 and and TXT records. There is no > separator: the TXT record (and thus now the WALLET record) takes "One or > more s". A is "a single length octet > followed by that number of characters". > > --Paul Hoffman Ah, TIL; thanks! ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: [Ext] Revised the application for the WALLET RRTYPE
"expect to find two strings" I didn't see this specified so thought I'd ask: what is the separator of the two strings? ASCII whitespace, or ...? On Mon, Jul 1, 2024 at 12:22 PM Paul Hoffman wrote: > Thanks again for the input on the new RRTYPE. I submitted it to the RRTYPE > expert reviewers, and the new definition is posted at < > https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template>. > It has "2024-06-24" as its submission date. > > --Paul Hoffman > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: IPN and CLA RRTYPEs to support Bundle Protocol RFC9171
Speaking as the responsible AD for DTN, I think the DTN working group should probably have a discussion about what it wants to do (if anything) vis. DNS RRs. On Tue, Jun 25, 2024 at 08:27 Scott Johnson wrote: > Hi Mark, > > On Tue, 25 Jun 2024, Mark Andrews wrote: > > > > > > >> On 25 Jun 2024, at 16:36, Scott Johnson > wrote: > >> > >> Hi Mark, > >> > >> Noted and changed. Good stuff, thanks. Updated draft (04) at > datatracker using that verbiage: > >> https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > >> > >> Is it appropriate to add an acknowledgments section or co-authors at > this point? > > > > I’m not fussed either way. > > (05) of the draft adds a "Contributors" section. > > > > >> As well, should I be asking for WG adoption (DNSOP or DTN WG), or as an > Informational document, is Individual submission sufficient? > > > > I’ll leave that for the chairs to answer. > > Ack. Thank you so much for your time and attention to this document. > > ScottJ > > > > >> Thanks, > >> ScottJ > >> > >> > >> On Tue, 25 Jun 2024, Mark Andrews wrote: > >> > >>> Made the IPN description more specific. > >>> > >>> > >>> Wire format encoding shall > >>> be an unsigned 64-bit integer in network order. Presentation format, > for these > >>> resource records are either a 64 bit unsigned decimal integer, or two > 32 bit > >>> unsigned decimal integers delimited by a period with the most > significant 32 bits > >>> first and least significant 32 bits last. Values are not to be zero > padded. > >>> > On 25 Jun 2024, at 15:22, Scott Johnson > wrote: > > Hi Scott, > > Wire format of 64 bit unsigned integer it is for IPN. > Updated draft (03) incorporating all changes posted at: > https://datatracker.ietf.org/doc/draft-johnson-dns-ipn-cla/ > > Let me know if you see anything else, Mark, and thanks! > > > ScottJ > > > On Mon, 24 Jun 2024, sburleig...@gmail.com wrote: > > > I've lost lock on the ipn-scheme RFC, but my own assessment is that > always sending a single 64-bit unsigned integer would be fine. The > application receiving the resource can figure out whether or not it wants > to condense the value by representing it as two 32-bit integers in ASCII > with leading zeroes suppressed and a period between the two. Internally > it's always going to be a 64-bitunsigned integer, from which a 32-bit > "allocator" number can be obtained by simply shifting 32 bits to the right; > if the result is zero then we're looking at an old-style IPN node number. > > > > Scott > > > > -Original Message- > > From: Scott Johnson > > Sent: Monday, June 24, 2024 8:26 PM > > To: Mark Andrews ; sburleig...@gmail.com > > Cc: dnsop > > Subject: Re: [DNSOP] IPN and CLA RRTYPEs to support Bundle Protocol > RFC9171 > > > > Hi Mark, > > > > > > On Tue, 25 Jun 2024, Mark Andrews wrote: > > > >> > >> > >>> On 25 Jun 2024, at 10:32, Scott Johnson > wrote: > >>> > >>> Hi Mark, > >>> > >>> On Tue, 25 Jun 2024, Mark Andrews wrote: > >>> > An obvious correction “LTP--v6” -> “LTP-v6” > >>> > >>> Aha! Good eye. > >>> > > For IPN why isn’t the wire format two network 64 bit integers? > That is 16 bytes. Also 2^64-1 is 20 characters so 2 64-bit numbers > separated by “." is 41 characters. It’s not clear where then 21 comes from. > >>> > >>> EID is the basic unit of IPN naming, which is indeed two 64 bit > integers separated by a ".". We are seeking to represent only the node-nbr > component of an EID, as the service-nbr component is loosely analagous to a > UDP or TCP port, for which there is one publicly defined service in the > registry, and a collection of space agencies who lay claim to another chunk > of them: > >>> > https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-num > >>> bers As such, there is no gain in including the second 64-bit > >>> integer, representing service-nbr in the DNS records, and indeed, > a loss of utility on the application level. > >>> > >>> The node-nbr component is presently, under RFC7116, a 64 bit > unsigned integer. There is a draft from the DTN WG currently making it's > way through the IESG which will amend the IPN naming scheme. Perhaps I > should add it to normative references? > >>> https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/ > >>> > >>> In effect it splits the node-nbr component into two-32 bit > integers; Allocator Identifier and Node Number in the "Three-Element > Scheme-Specific Encoding" of Section 6.1.2 over the above. Section 6.1.1 > describes the "Two-Element Scheme-Specific Encoding" method which retains > the use of a single 64-bit integer. Thus, a single 64 bit integer (20 > characters) or two 32-bit integers (10 characters each) delimited by a "." > >>
[DNSOP]Re: Erik Kline's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)
On Fri, May 10, 2024 at 10:12 PM Erik Kline wrote: > On Tue, May 7, 2024 at 12:59 AM Peter Thomassen wrote: > >> Hi Erik, >> >> Thanks for your review! >> >> On 5/5/24 00:18, Erik Kline via Datatracker wrote: >> > ## Comments >> > >> > ### S7 >> > >> > * Should there be some kind of registration or reservation for the >> "_dsboot" >> >meaning and usage described in this document? >> The authors were wondering as well. >> >> We figured that unlike in case of the existing underscore registry, the >> issue seems less pressing: >> >> The _dsboot etc. labels are under the "main" underscore label right in >> front of the nameserver name. As a result, the signaling type label (like >> _dsboot) is somewhat "shielded", in the sense that they are only used under >> the signaling mechanism, i.e., by DNS operators announcing stuff about >> their managed zones. Given the limited target group for the signaling >> mechanism overall, collisions seem less likely than with underscore labels >> in general. >> >> The authors are also not sure under which conditions such registries >> should or should not be erected. In short, we don't really have an answer >> to your question, except that less may be more, but it's not clear. >> >> That said, the authors think "why not", and if you wish, we can add a >> section to address this. I imagine this would be something like RFC 8552 >> Section 4.1 [1]. This would add ~2 pages to the draft, unless there's a >> shorter way to do it. >> >> [1]: https://www.rfc-editor.org/rfc/rfc8552#section-4.1 >> >> Thanks, >> Peter and Nils >> > > Thanks for your reply. I have no particular intuition telling me what's > best here. I'm happy to wait and see what other reviews think. > I should add that if no registration of any sort is made then it may be worth a sentence or two saying why nothing is established at this time. But again: I'm happy to wait and see what consensus emerges. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP]Re: Erik Kline's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)
On Tue, May 7, 2024 at 12:59 AM Peter Thomassen wrote: > Hi Erik, > > Thanks for your review! > > On 5/5/24 00:18, Erik Kline via Datatracker wrote: > > ## Comments > > > > ### S7 > > > > * Should there be some kind of registration or reservation for the > "_dsboot" > >meaning and usage described in this document? > The authors were wondering as well. > > We figured that unlike in case of the existing underscore registry, the > issue seems less pressing: > > The _dsboot etc. labels are under the "main" underscore label right in > front of the nameserver name. As a result, the signaling type label (like > _dsboot) is somewhat "shielded", in the sense that they are only used under > the signaling mechanism, i.e., by DNS operators announcing stuff about > their managed zones. Given the limited target group for the signaling > mechanism overall, collisions seem less likely than with underscore labels > in general. > > The authors are also not sure under which conditions such registries > should or should not be erected. In short, we don't really have an answer > to your question, except that less may be more, but it's not clear. > > That said, the authors think "why not", and if you wish, we can add a > section to address this. I imagine this would be something like RFC 8552 > Section 4.1 [1]. This would add ~2 pages to the draft, unless there's a > shorter way to do it. > > [1]: https://www.rfc-editor.org/rfc/rfc8552#section-4.1 > > Thanks, > Peter and Nils > Thanks for your reply. I have no particular intuition telling me what's best here. I'm happy to wait and see what other reviews think. ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-dnssec-bootstrapping-08: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-08: No Objection 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-dnssec-bootstrapping/ -- COMMENT: -- # Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S7 * Should there be some kind of registration or reservation for the "_dsboot" meaning and usage described in this document? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-avoid-fragmentation-16: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: No Objection 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/ -- COMMENT: -- # Internet AD comments for draft-ietf-dnsop-avoid-fragmentation-16 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Comments ### S1 * "TCP avoids fragmentation by ..." TCP also benefits hugely from widespread support for MSS rewriting. If something like an "EDNS0 Payload Size rewriting" function was available and as widely deployed there might be a very different conversation to be had. No text changes necessary; just a random thought. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-caching-resolution-failures-07: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-caching-resolution-failures-07: No Objection 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-caching-resolution-failures/ -- COMMENT: -- # Internet AD comments for draft-ietf-dnsop-caching-resolution-failures-07 CC @ekline * comment syntax: - https://github.com/mnot/ietf-comments/blob/main/format.md * "Handling Ballot Positions": - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ ## Nits ### S1.2 * "only exacerbated" -> "further exacerbated"? Use of "only" here might be misread. ### S2.2 * s/2001:DB8:1::/2001:db8:1::/g in accordance with RFC 5952 section 4.3 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's No Objection on draft-ietf-dnsop-dns-catalog-zones-08: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-catalog-zones-08: No Objection 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-dns-catalog-zones/ -- COMMENT: -- # Internet AD comments for draft-ietf-dnsop-dns-catalog-zones-08 CC @ekline ## Nits ### S4.3 * "Member-specific properties are described in Section 4.3" -> "Member-specific properties are described in Section 4.4" ### S4.4.2.1 * S4.3.1 has quotation marks around the contents of the TXT record, whereas this section does not. Recommend standardizing on one format, and probably the one with surrounding quotation marks, i.e.: group..zones.$CATZ 0 IN TXT"nodnssec" group..zones.$CATZ 0 IN TXT"operator-x-sign-with-nsec3" group..zones.$CATZ 0 IN TXT"operator-y-nsec3" Although, perhaps I've misunderstood something and this is not relevant. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-svcb-https-09: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-svcb-https-09: Yes 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-svcb-https/ -- COMMENT: -- Thanks for the changes! (Referring to 4001 seems odd to me, and maybe unnecessary.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Discuss on draft-ietf-dnsop-svcb-https-08: (with DISCUSS and COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-svcb-https-08: 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-svcb-https/ -- DISCUSS: -- [Appendix D.2] * Sorry to be super nitpicky/petty about this. With respect to Figure 7: IPv4-mapped IPv6 addresses have a complicated history (see RFC 4942 S2.2 for an amuse-bouche, as well as itojun's draft-itojun-v6ops-v4mapped-harmful). Unless there is something very useful to be gained by the inclusion of this example (what?) I would strongly suggest removing it. I fear it will only cause confusion. -- COMMENT: -- [S2.3; comment] * "When a prior CNAME or SVCB record has aliased to a SVCB record, each RR shall be returned under its own owner name." I think this could use some explanation and a reference to Section 11. Perhaps something along the lines of This is in account of the client resolution process [Section 3]. See also discussion in [Section 11.1]. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Fri, Nov 5, 2021 at 10:02 AM Wessels, Duane wrote: > > > > On Nov 1, 2021, at 3:29 PM, Erik Kline 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. > > > >>> [S4.1, comment] > >>> > >>> * "Resolvers and other DNS clients should be aware that some servers > >>> might not be reachable over TCP. For this reason, clients MAY want > >>> to track and limit the number of TCP connections and connection > >>> attempts to a single server." > >>> > >>> I think the same comment could be made about paths to a server from > >>> a given network, e.g., in the case of one network filtering TCP/53 for > >>> some reason. > >>> > >>> I'm not sure how to best reword this to add a per-network notion to > >>> TCP connection success tracking, but I did want to note that a mobile > >>> client's measure of TCP connection success to a single server might > >>> vary from network to network. (for your consideration) > >> > >> Is this because mobile devices are more likely to have multiple network > choices (say wifi and cellular data) and so the device should include the > local network when remembering which works and which doesn’t? > > > > Yes, they have multiple networks simultaneously and also through time. > > What's reachable/unreachable on one network might not be > > reachable/unreachable on another. Just moving from one Wi-Fi SSID to > > another can make a difference, e.g.: > > > >* imagine two SSIDs that each hand out 8.8.8.8 but have different > > TCP 53 filtering policies, and > > > >* (more concretely) I have DNS-over-TLS active on my phone and on > > one nearby coffee shop SSID TCP 853 is blocked while on another > > everything works just fine > > > > (Hopefully I'm making some kind of sense.) > > Thanks Erik, how does this look to you? > >Resolvers and other DNS clients should be aware that some >servers might not be reachable over TCP. For this reason, clients >MAY track and limit the number of TCP connections and >connection attempts to a single server. Reachability problems >can be caused by network elements close to the server, close >to the client, or anywhere along the path between them. Mobile >clients that cache connection failures MAY do so on a per-network >basis, or MAY clear such a cache upon change of network. > > DW > > LGTM. s/MAY/SHOULD/g also LGTM (since I know some mobile OSes already do stuff like this) Thanks! ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
> > [S4.1, comment] > > > > * "Resolvers and other DNS clients should be aware that some servers > > might not be reachable over TCP. For this reason, clients MAY want > > to track and limit the number of TCP connections and connection > > attempts to a single server." > > > > I think the same comment could be made about paths to a server from > > a given network, e.g., in the case of one network filtering TCP/53 for > > some reason. > > > > I'm not sure how to best reword this to add a per-network notion to > > TCP connection success tracking, but I did want to note that a mobile > > client's measure of TCP connection success to a single server might > > vary from network to network. (for your consideration) > > Is this because mobile devices are more likely to have multiple network > choices (say wifi and cellular data) and so the device should include the > local network when remembering which works and which doesn’t? Yes, they have multiple networks simultaneously and also through time. What's reachable/unreachable on one network might not be reachable/unreachable on another. Just moving from one Wi-Fi SSID to another can make a difference, e.g.: * imagine two SSIDs that each hand out 8.8.8.8 but have different TCP 53 filtering policies, and * (more concretely) I have DNS-over-TLS active on my phone and on one nearby coffee shop SSID TCP 853 is blocked while on another everything works just fine (Hopefully I'm making some kind of sense.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
On Tue, Oct 26, 2021 at 1:13 PM Benjamin Kaduk wrote: > On Tue, Oct 26, 2021 at 01:09:00PM -0700, Erik Kline via Datatracker wrote: > > Erik Kline has entered the following ballot position for > > draft-ietf-dnsop-dns-tcp-requirements-13: Yes > > > > 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/blog/handling-iesg-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-dns-tcp-requirements/ > > > > > > > > -- > > COMMENT: > > -- > > > > [abstract vs. S1/S3, question] > > > > * The abstract says: > > > >"...strongly > >encourages the operational practice of permitting DNS messages to be > >carried over TCP" > > > > while section 1 says: > > > >"...all DNS resolvers and recursive > >servers MUST support and service both TCP and UDP queries" > > > > and section 3 also some MUST text. > > > > Should the abstract be updated to say MUST rather than just > > "strongly encourages", or is there a subtly in here I'm missing? > > "require" might be better than "MUST", on the principle that if a given > requirement is stated in more than one place, there is risk of inadvertent > skew between what is actually stated; such skew can cause interoperability > failure or security vulnerabilities if different implementations use the > differing behaviors. > > -Ben > +1 sgtm ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-tcp-requirements-13: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Yes 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/blog/handling-iesg-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-dns-tcp-requirements/ -- COMMENT: -- [abstract vs. S1/S3, question] * The abstract says: "...strongly encourages the operational practice of permitting DNS messages to be carried over TCP" while section 1 says: "...all DNS resolvers and recursive servers MUST support and service both TCP and UDP queries" and section 3 also some MUST text. Should the abstract be updated to say MUST rather than just "strongly encourages", or is there a subtly in here I'm missing? [S4.1, comment] * "Resolvers and other DNS clients should be aware that some servers might not be reachable over TCP. For this reason, clients MAY want to track and limit the number of TCP connections and connection attempts to a single server." I think the same comment could be made about paths to a server from a given network, e.g., in the case of one network filtering TCP/53 for some reason. I'm not sure how to best reword this to add a per-network notion to TCP connection success tracking, but I did want to note that a mobile client's measure of TCP connection success to a single server might vary from network to network. (for your consideration) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Éric Vyncke's Discuss on draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS)
Works for me too. My main observation was to consider acknowledging there might be some nuance in this QTYPE area, and this sounds sufficiently nuance-y for me. Thanks Paul! On Tue, Aug 24, 2021 at 10:36 PM Eric Vyncke (evyncke) wrote: > Paul, > > First , thank you for your reply. > > Second, your proposed change actually addresses my DISCUSS and will be > happy to change my ballot in a NO OBJECTION once a revised I-D is published > ;-) > > Regards > > -éric > > -Original Message- > From: iesg on behalf of Paul Hoffman < > paul.hoff...@icann.org> > Date: Wednesday, 25 August 2021 at 00:44 > To: Eric Vyncke > Cc: dnsop , The IESG , " > draft-ietf-dnsop-rfc7816...@ietf.org" < > draft-ietf-dnsop-rfc7816...@ietf.org> > Subject: Re: [Ext] Éric Vyncke's Discuss on > draft-ietf-dnsop-rfc7816bis-10: (with DISCUSS) > > On Aug 24, 2021, at 5:23 AM, Éric Vyncke via Datatracker < > nore...@ietf.org> wrote: > > == DISCUSS == > > > > -- Section 2.1 -- > > I support Erik Kline's COMMENT on this and am raising it to a > blocking DISCUSS. > > > > A/ in all the discussion in the last §, a would have the same > benefit when > > compared to a NS QTYPE. Or what did I miss ? > > > > B/ the last two sentences "Another potential benefit...happy > eyeballs query for > > the A QTYPE." are puzzling as using A QTYPE will actually only cache > the A > > answer for the minimized request and more and more Internet users > are using > > IPv6 nowadays (and possibly even more recursive DNS servers). > > > > Hence, I would welcome some discussion in the last § about the > benefit of using > > A QTYPE rather than QTYPE and, as suggested by Erik Kline, > please remove > > the last 2 sentences. > > If we change from: > >A good candidate is to always use the "A" >QTYPE because this is the least likely to raise issues in DNS >software and middleboxes that do not properly support all QTYPEs. >The QTYPE=A queries will also blend into traffic from non-minimising >resolvers, making it in some cases harder to observe that the >resolver is using QNAME minimisation. Using the QTYPE that occurs >most in incoming queries will slightly reduce the number of queries, >as there is no extra check needed for delegations on non-apex >records. Another potential benefit of using QTYPE=A is that >[RFC8305] clients that need answers for both the A and types >will send the query first. When minimising using QTYPE=A the >minimised query might be useful, and now already in the cache, for >the happy eyeballs query for the A QTYPE. > > to: > >Good candidatesare to always use the "A" or "" >QTYPE because these is the least likely to raise issues in DNS >software and middleboxes that do not properly support all QTYPEs. >QTYPE=A or QTYPE= queries will also blend into traffic from > non-minimising >resolvers, making it in some cases harder to observe that the >resolver is using QNAME minimisation. Using a QTYPE that occurs >most in incoming queries will slightly reduce the number of queries, >as there is no extra check needed for delegations on non-apex >records. > > does that alleviate your concers? > > --Paul Hoffman > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-rfc7816bis-10: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-rfc7816bis-10: Yes 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/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc7816bis/ -- COMMENT: -- [S2.1 comment] * It seems to me that using A QTYPEs for Happy Eyeballs clients is only a "potential benefit" for an IPv4 connection setup, and does nothing to aid any possible IPv6 connection setup. There are networks with IPv6-only clients accessing mostly IPv6-reachable services for which this might actually slow down services (by delaying resolution resulting in an IPv4 connection setup that uses something like NAT64 rather than native IPv6). Suggestion 1: Just trim these HE-related sentences. Suggestion 2: Make it clear that this might not always be a "benefit" in certain network deployments. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-server-cookies-04: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-server-cookies-04: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ -- COMMENT: -- [ questions ]] [ section 3 ] * I assume it's not a big deal that sometimes the client cannot easily tell when its upstream IP address has changed (vis. RFC 7873 S6 considerations)? NAT makes it difficult to comply with the MUST for clients stated in section 8, but...what should a client do if only has, say, an RFC 1918 address and is quite likely to be behind a NAT? If its server is also a likely-NAT'd IP then it might presume no NAT between the two, but if the server has a global IP address...I suppose it can just rotate the per-server cookies once per year? [[ nits ]] [ section 1 ] * Final sentence of the final paragraph: "in a Client protecting fashion" -> "in a privacy protecting fashion"? (to match the abstract) [ section 8 ] * "five minute" -> "five minutes" ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-dns-zone-digest-12: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-zone-digest/ -- COMMENT: -- [[ nits ]] [ section 1.2 ] * "Whereas DNSSEC is primarily protects" -> "Whereas DNSSEC primarily protects" [ section 6.2 ] * "DNSSESC" -> "DNSSEC" ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Erik Kline's Yes on draft-ietf-dnsop-extended-error-14: (with COMMENT)
Erik Kline has entered the following ballot position for draft-ietf-dnsop-extended-error-14: Yes 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-extended-error/ -- COMMENT: -- Some non-mushroom-infection-related thoughts: [ section 2 ] * I'm insufficiently fluent in Unicode but is some reference here appropriate? Perhaps RFC 5198 (if not 3629)? * Is some text of the form "EDE text may be null terminated but MUST NOT be assumed to be; the length MUST be derived from the OPTION-LENGTH field" worth including? [ section 4.1 ] ? s/a EXTRA-TEXT/an EXTRA-TEXT/ perhaps [ section 4.5 ] * should DNS64 servers send "Forged Answer" EDEs with a NOERROR synthesized response? [ section 4.22 ] * "Not Supported" because something has been deprecated seems sufficiently specific that perhaps "Deprecated" or "No longer supported" would be more appropriate? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Erik Kline's Yes on draft-ietf-dnsop-no-response-issue-18: (with COMMENT)
LGTM, thanks
On Sun, Apr 5, 2020 at 6:43 PM Mark Andrews wrote:
>
>
> > On 5 Apr 2020, at 15:45, Erik Kline via Datatracker
> wrote:
> >
> > Erik Kline has entered the following ballot position for
> > draft-ietf-dnsop-no-response-issue-18: Yes
> >
> > 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/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> > {Yes}
> >
> > [nits]
> >
> > S3.2.2
> >
> > * s/answers responses/responses/ (or answers)
>
> Addressed.
> >
> > S5
> >
> > * Is there a reference for a definition of "scrubbing service”?
>
> I’ve attempted to add one to the section. See -19.
>
> >
> > S10
> >
> > * s/None the tests/None of the tests/
>
> Addressed.
> >
> >
> >
>
> --
> 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] Erik Kline's Yes on draft-ietf-dnsop-no-response-issue-18: (with COMMENT)
Erik Kline has entered the following ballot position for
draft-ietf-dnsop-no-response-issue-18: Yes
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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
--
COMMENT:
--
{Yes}
[nits]
S3.2.2
* s/answers responses/responses/ (or answers)
S5
* Is there a reference for a definition of "scrubbing service"?
S10
* s/None the tests/None of the tests/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] status of the aname and svcb/httpsvc drafts
On Wed, Feb 19, 2020 at 1:13 PM Warren Kumari wrote: > On Thu, Feb 20, 2020 at 6:13 AM Tommy Pauly > wrote: > > > > > > > > On Feb 18, 2020, at 6:15 PM, Rob Sayre wrote: > > > > On Tue, Feb 18, 2020 at 8:17 AM Olli Vanhoja > wrote: > >> > >> > >> SVCB is active almost every day of the week in GitHub. > > > > > > If someone wanted to follow this work, which GitHub repo is relevant? > > > > I found this one: https://github.com/MikeBishop/dns-alt-svc > > > > But I'm not sure that's the right one. > > > > > > Yes, that is the correct GitHub. > > Could I suggest adding something like: > [ RFC Editor - please remove before publication. This document is being > collaborated on in Github at: > https://github.com/MikeBishop/dns-alt-svc. The most > recent version of the document, open issues, etc should all be > available here. The authors (gratefully) accept pull requests.] > > to the abstract - that way, people reading the draft know where submit > PRs, etc. > W > > Seems like something worth noting in draft-ietf-git-using-github too (I scanned the two wg docs and no existing text jumped out at me). > > > > Thanks, > > Tommy > > > > > > thanks, > > Rob > > > > ___ > > 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 > > > > -- > 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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] port number in HTTPSSVC
I think removing port number flexibility might unduly constrain some data center use cases where service reachability might not have the more common 443-only limitations. On Fri, Jan 3, 2020 at 11:33 AM Ben Schwartz wrote: > HTTPSSVC co-editor here. > > The effect of this change seems similar to deprecating support for > non-default ports in HTTP/3. While I have some misgivings about the > handling of non-default ports in HTTPS, I would want to see consensus in > the HTTP and QUIC working groups before making this change. > > I would suggest sending your proposal to those lists, and we can adjust > the HTTPSSVC draft based on their conclusions. > > On Fri, Jan 3, 2020 at 1:24 PM Paul Vixie wrote: > >> in SRV we added a port number to the rdata because the /etc/services file >> was >> painful to keep globally updated. SRV was protocol independent. >> >> HTTPSSVC is protocol specific, and when it copied SRV, it included the >> port >> number in the rdata, which i think is both unnecessary and error-prone. >> >> managed private networks who want to permit outbound HTTP/3 are going to >> add a >> rule like "if the far end port number is 443, add a stateful rule". >> anyone who >> uses the port number field (if it exists) in HTTPSSVC to specify a >> different >> port number is going to suffer, as will many of the clients trying to >> access >> that service. >> >> i suggest that the port 443 assumption for HTTP/3 be baked in, and that >> this >> field be removed from the HTTPSSVC rdata. >> >> -- >> Paul >> >> >> ___ >> 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] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
On Tue, Oct 29, 2019 at 6:10 PM Ben Schwartz wrote: > > > On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters wrote: > >> On Tue, 29 Oct 2019, Neil Cook wrote: >> >> > FWIW, I've previously stated a preference for dropping the use >> of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name >> instead of reverse-IP, in order to improve support for >> > passive forwarders. I understand this was changed in the hope of >> offering some kind of security here with DNSSEC, but I think it's unlikely >> to work in practice, and we're better off keeping >> > things simple. >> > >> > >> > I completely agree. I’d much rather see something like >> "resolver-info.arpa" instead of reverse-IP. >> >> Throwing DNSSEC under the bus for a "simpler" name seems rather >> excessive. I for one would like to see DNSSEC in the reverse >> support when possible. For a future where not everything is >> chained to a single all-powerful LetsEncrypt root CA. >> > > The concern here is not "simplicity" as such. The main concern is the > large fraction of devices whose configured DNS server is actually a > forwarder (usually with an RFC 1918 address). Even if the actual recursive > implements RESINFO support, these devices will not be able to retrieve the > information, because they won't be querying the reverse address that the > recursive resolver thinks it owns. > > This can be solved if the forwarder implements some sort of RESINFO query > rewriting, but it certainly won't work for the existing install base. I > think this is the crux: should the upstream RESINFO be available through a > naive forwarder, or only through a forwarder that actively works to support > RESINFO? I prefer the former, because I think serving the existing install > base is worthwhile. > > I don't see significant value in DNSSEC for this application, because an > adversary who can forge DNS responses (the DNSSEC adversary) can also forge > DNS configuration messages (DHCP or RA). What good does it do me to prove > that 1.2.0.192.in-addr.arpa is authentically publishing this RESINFO, if > the attacker forged the DNS configuration message that said 192.0.2.1? > But this sounds more like you want to lookup RESINFO for resinfo.arpa with some DNS hop count decrementing and get back a CNAME to the rev-addr RESINFO record. I don't know how we do DNS hop count decrementing, but it could be done by convention (i.e. "0.resinfo.arpa", "1.resinfo.arpa", "2.resinfo.arpa", ). (But still, it just sounds like want you want is somewhat orthogonal to/separable from what's discussed in this draft.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-resolver-information-00.txt
IIRC Ben Schwartz at the mic (Prague? Montreal?) mentioned he was
interested in seeing something like "traceroute but for DNS", which (a) is
what your described scenario sounds like to me and (b) is a
separate objective from this draft. I think it's just...unrelated. I
don't think we have DNS hop-by-hop -type semantics, which would make the
discovery of intermediate resolvers/forwarders easier.
On Mon, Oct 28, 2019 at 9:03 AM Neil Cook wrote:
> I was quite surprised that there was no reaction to my comments. Are they
> not worth replying to, or is there just not enough interest in this draft?
>
> Resolver discovery seems like such an important topic given what is
> happening with DoH and DoT, I can’t believe that folks aren’t interested in
> progressing this, and I think ensuring that it works for the extremely
> widely deployed use-case of a DNS proxy/forwarder is very important.
>
> Neil
>
> > On 11 Oct 2019, at 14:41, Neil Cook wrote:
> >
> > I have some comments on this draft.
> >
> > I’m particularly concerned about the extremely common use-case where a
> DNS proxy is used in front of the actual resolver; this is the case for
> many home routers/CPEs, particularly those provided by ISPs. They tend to
> give out DNS via DHCP on a private IP address e.g. 192.168.0.x, and then
> use dnsmasq (or homegrown software) to proxy to the actual resolver of the
> ISP located in the network on a public IP address.
> >
> > TL;DR - there are two mechanisms defined in this draft. The first
> mechanism "Retrieving Resolver Information by DNS” seems like it would work
> ok with the above scenario. The second mechanism "Retrieving Resolver
> Information by Well-Known URI” would require changes to every CPE of the
> type described above, which IMO makes it unworkable for that scenario. (BTW
> for CPE insert any kind of DNS proxy/forwarder, which would have the same
> issue).
> >
> > My main concern is that given that there are two mechanisms specified,
> clients may choose only to implement one of them. The draft doesn’t appear
> to specify that client authors must implement one or the other, or both. So
> I’d like to see the draft mandate that if only one of the mechanisms is
> implemented, it must be the "Retrieving Resolver Information by DNS” method.
> >
> > I’d like to see the draft give due consideration to this very common
> use-case, (both CPEs and the more general case of DNS proxies/forwarders)..
> >
> > A few additional comments which I think need to be considered:
> >
> > - For the Well-Known URI mechanism by resolver IP, clearly private IP
> addresses can never get valid certificates, so even if CPEs were to
> implement this mechanism, they can never be authenticated.
> >
> > - For the DNS method, given that a resolver never knows if DNS proxies
> are being used (in CPEs or elsewhere) or indeed what IP addresses are being
> used behind those proxies, I would imagine that at a minimum it would need
> to answer RESINFO queries for *all* RFC1918 addresses. This does then lead
> to the question, why include the IP address in the query at all? I assume
> the answer is “DNSSEC”, but see below for some more questions/comments on
> that.
> >
> > - There is an acknowledgement "Erik Kline suggested using
> ".{in-addr,ip6}.arpa" as the
> > domain name to allow for the possibility of DNSSEC-signed responses.”
> >
> > I think it’s worth noting that RESINFO queries for private IP addresses
> will never be able to generate DNSSEC-signed responses. Also given the
> restriction "Authoritative servers MUST NOT answer queries that are defined
> in this protocol.” it seems unlikely that many resolvers would be capable
> of generating DNSSEC-signed responses, especially given that resolvers and
> authoritative servers tend to be completely separate entities these days.
> >
> > This also begs the question, why create that restriction at all? Why
> must Authoritative Servers not answer those queries? The draft also states
> 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.” Which seems to contradict the previous
> MUST NOT - surely this is an implementation detail that should not be
> mentioned in an IETF draft?
> >
> > Neil Cook
> >
> >> On 19 Aug 2019, at 20:28, 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.
> >
Re: [DNSOP] Special-use TLDs in resolvers
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain I have wondered whether or not it would be useful for IANA to have a git repo where these canonical data could live alongside scripts that transform them into things like C #include header files and zone file formats and so on. On Fri, 16 Aug 2019 at 08:00, Steve Crocker wrote: > At the risk of revealing that I haven't been following this thread > carefully, I don't understand how a resolver is supposed to know all of the > special names. Resolvers that are configured to know that invalid, > local, onion, and test are special will not know about the next name > that's put on the special list. > > I guess the larger picture is that onion is a protocol switch, so it's not > sufficient for a resolver to know that it shouldn't look up strings ending > in onion in the global DNS; it must also know what it should do. > > Steve > > > On Fri, Aug 16, 2019 at 10:47 AM Andrew Sullivan > wrote: > >> As I often note, I work for ISOC but I'm not speaking for it. >> >> On Fri, Aug 16, 2019 at 11:30:06AM +0200, Vladimír Čunát wrote: >> >> > I've been wondering what's best to do around these TLDs: invalid, local, >> > onion, test. The RFCs say that resolvers SHOULD recognize them as >> > special and answer NXDOMAIN without any interaction with nameservers (by >> > default). What do you think about NOT following this "advice", subject >> > to some conditions that I explain below? >> >> I think it's less than ideal, because the point of resolvers immediately >> answering NXDOMAIN is that these are not and never will be names in >> the global DNS. That is, they really are special-use, and part of >> that specialness is that they're part of the domain name space but not >> part of the global DNS name space. >> >> This is particularly true of onion, which is a protocol switch. It's >> intended to signal that you should _never_ look up that name in the >> DNS. That's its whole function. >> >> Best regards, >> >> A >> >> -- >> Andrew Sullivan >> a...@anvilwalrusden.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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New draft, seeking comments: draft-sah-resolver-information
Can I ask why you went with resolver-info.arpa instead of
.{in-addr,ip6}.arpa of the resolver IP to which the query is being
issued? I think the temp-field2. trick still works, and maybe we
could get DNSSEC validation (IDK about dnssec validation in the rev-ip
..arpa space).
On Tue, 30 Apr 2019 at 14:10, Paul Hoffman wrote:
> [[ GH. The abstract of the draft says it should be discussed on the
> ADD list. That's wrong, it belongs here. ]]
>
> [[ GH2. I didn't include the draft info.
> Title : DNS Resolver Information Self-publication
> Authors : Puneet Sood
> Roy Arends
> Paul Hoffman
> Filename: draft-sah-resolver-information-00.txt
> Pages : 9
> Date: 2019-04-30 ]]
>
> Greetings again. Puneet, Roy and I have just published a -00 with an idea
> for how to get information about a recursive resolver from the resolver, if
> it wants to give that information. This is an outgrowth of my earlier work
> in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on
> that latter draft in Prague had a couple of people saying "this should be
> more general than just DoH" and "what about DoT", which sparked the idea
> for draft-sah-resolver-information.
>
> Note as you read this document that we have *not* started filling in the
> kind of information that a resolver might return; we haven't even specified
> the DoH stuff. We wanted to be sure that DNSOP folks thought that the
> direction here might be viable; if so, I'll write an associated draft for a
> resolver's associated DoH and DoT servers, and some of you might start
> writing drafts for other ideas.
>
> Also note that this is explicitly only for resolvers; we might later do a
> second protocol for authoritative servers who want to give information
> about themselves (such as if they do DoT, if that moves forward in DPRIVE).
> The reason for the split is that a resolver that doesn't know the protocol
> here might pass the query on to the authoritative servers for the root or
> .arpa, and the response to the stub would then be ambiguous.
>
> We look forward to your bashing and/or support.
>
> --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
Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
On Wed, 13 Mar 2019 at 16:10, Paul Vixie wrote: > On Wednesday, 13 March 2019 19:23:55 UTC Erik Kline wrote: > > > If there is a malicious user or app on a network that someone is > trying to > > > protect, isn't the very existence of these players the actual issue > that > > > needs to be addressed? > > > > I tend to think this is the real issue. Any app can craft its own > > non-cleartext-DNS name resolution service; DoH makes it a bit easier > > perhaps, but not much (vis. JSON DNS, etc...). > > if you guys would appreciate a half day seminar on network security > economics, > in which the value of anomalousness will figure prominently, let's meet up. > I'd be a fool to turn down such an offer. Thank you. > My suspicion is that controlling a network's DNS is less and less likely > to > > be a decent control point for network security w.r.t. to the craftier > > apps. > > your suspicion directly contradicts both my long-term and recent > experience. > > > I'm sure the monitoring and interference with things looking up > > "really-evil.evil" still has some value. But much more sophistication is > > probably required nowadays to deal with even moderately competent > > adversaries...I suspect. > > alas, meeting only the most competent adversaries is not a choice we can > make. > > vixie > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Concerns around deployment of DNS over HTTPS (DoH)
> > > If there is a malicious user or app on a network that someone is trying to > protect, isn't the very existence of these players the actual issue that > needs to be addressed? > I tend to think this is the real issue. Any app can craft its own non-cleartext-DNS name resolution service; DoH makes it a bit easier perhaps, but not much (vis. JSON DNS, etc...). My suspicion is that controlling a network's DNS is less and less likely to be a decent control point for network security w.r.t. to the craftier apps. I'm sure the monitoring and interference with things looking up "really-evil.evil" still has some value. But much more sophistication is probably required nowadays to deal with even moderately competent adversaries...I suspect. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Delegation into the interior of a zone?
On Thu, 27 Dec 2018 at 11:27, John Levine wrote: > Over in bind-users somone suggested a CIDR rDNS kludge in which you > delegate a bunch of names out of a rDNS zone to a second server, > and the second server answers them all from one zone, like this > > $ORIGIN 1.1.1.in-addr.arpa. > @ SOA blah > > 10 NS otherserver > 11 NS otherserver > 12 NS otherserver > > > and on the other server > > $ORIGIN 1.1.1.in-addr.arpa. > @ SOA blah > > 10 PTR foo > 11 PTR bar > 12 PTR baz > > That is, the two zones have the same apex, and NS records point into > the interior of the second zone, not at the apex. That works in BIND, > of course, but it seems wrong. I am having trouble tracking down the > specification of why it is wrong. > > Any sugestions? It would fail with DNSSEC since there's no DNSKEY > to match the delegation DS, but how wrong was it before that? > > Signed, > Confused > So, the NS listed in some zone above would be "wrong", i.e. the glue records point to namservers hosting a zone with these different nameservers? Seems like a resolver being pedantic about glue records might be nonplussed. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
On Mon, 5 Nov 2018 at 09:56, Dave Crocker wrote:
>
> On 11/4/2018 6:28 PM, Erik Kline wrote:
> > One thing I missed earlier (and please forgive me if this was already
> > discussed), was whether or not _example* should be reserved in the
> > table in draft-ietf-dnsop-attrleaf-15#section-4.3.
> >
> > Basically, is there any value in reserving _example* for future RFCs
> > to use (ones that don't care about the specific _foo label but apply
> > to all such labels in some way).
>
>
> Clever suggestion. Seems like obvious benefit with no obvious detriment.
>
> So I immediately went to add it and then realized that doing this
> cleanly will take an entry for each RR...
>
> Not so sure we want to do that?
Perhaps doable via a {see section #X.Y} e.g.:
| * | _example* {see #X.Y} | [this doc] |
X.Y Reserved _example* label
For use in RFC documentation describing behaviour applicable to
any label associate with any RR type. More awesome text also goes
here.
I'm not sure about the strictness requirements for this kind of table for IANA.
Also, this doesn't address whether it's an actually useful suggestion. :-)
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-15.txt
Dave (others), One thing I missed earlier (and please forgive me if this was already discussed), was whether or not _example* should be reserved in the table in draft-ietf-dnsop-attrleaf-15#section-4.3. Basically, is there any value in reserving _example* for future RFCs to use (ones that don't care about the specific _foo label but apply to all such labels in some way). Sorry for the last-minute distraction, -Erik On Sun, 4 Nov 2018 at 03:23, 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 : DNS Scoped Data Through "Underscore" Naming of > Attribute Leaves > Author : Dave Crocker > Filename: draft-ietf-dnsop-attrleaf-15.txt > Pages : 14 > Date: 2018-11-03 > > Abstract: >Formally, any DNS resource record may occur under any domain name. >However some services use an operational convention for defining >specific interpretations of an RRset, by locating the records in a >DNS branch, under the parent domain to which the RRset actually >applies. The top of this subordinate branch is defined by a naming >convention that uses a reserved node name, which begins with an >_underscore. The underscored naming construct defines a semantic >scope for DNS record types that are associated with the parent >domain, above the underscored branch. This specification explores >the nature of this DNS usage and defines the "DNS Global Underscore >Scoped Entry Registry" with IANA. The purpose of the Underscore >registry is to avoid collisions resulting from the use of the same >underscore-based name, for different services. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-15 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-15 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-15 > > > 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
[DNSOP] Genart last call review of draft-ietf-dnsop-attrleaf-13
Reviewer: Erik Kline Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-attrleaf-13 Reviewer: Erik Kline Review Date: 2018-09-26 IETF LC End Date: 2018-09-25 IESG Telechat date: Not scheduled for a telechat Major issues: none Minor issues: none Nits/editorial comments: just a few things that look like they may be typos Section 2: "DNS nodes names" doesn't quite scan for me. "DNS node names" perhaps? Section 4.2: s/simply/simplify/? Section 5: s/in the of/in the/? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] BIG RRSETS EDNS0 and ipv6 framentation.
On 16 June 2013 23:15, Mark Andrews wrote: > > In message <51bc6c18.3020...@bogus.com>, joel jaeggli writes: >> I'm interested in the intersection between the requested payload size >> and the use of the v6 fragmentation header, 6891 I think is missing some >> advice to implementers that might reasonably prevent fragmented replies >> from being dropped and limit the degree of amplification that can be >> achieved with large RRsets. > > Fragments get dropped because of badly configured/designed firewalls > and PMTUD. Setting IPV6_USE_MIN_MTU to 1 helps with the latter > though it may result in a addition fragment being sent. Unfortunately the former are far too prevalent. It's undoubtedly too late, but unfortunately it might have been better to do the fragmentation within the UDP payload (i.e. inside DNS) somehow (c.f. http://tools.ietf.org/html/rfc5405#section-3.2). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] fyi: draft-jabley-dnsext-eui48-eui64-rrtypes as AD sponsored individual sumission...
I too am not a long-standing dnsop participant, but this draft raised a
question for me. Does the class have any relevance anymore, really?
To be clear, I have no substantive comment on this document. But when I
read "The EUI{48,64} RR is class-independent" I thought, that's a
bit...weird. It seemed to me that if there were, for example, an IEEE
class then this would be perfectly suitable. But I guess that the RR
number-space is effectively flat? Do people even contemplate new classes
anymore?
Apologies for my naivete.
PS: If there are clarifying statements being added it might be worth
stating (the obvious) that EUI64 != Modified EUI64 as used by IPv6 SLAAC
(so don't go flipping bits unnecessarily).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Adoption of as a WG work item?
I know I'm late, but for what it's worth I'd support this. I'm happy to help, if possible. Perhaps I can sync with Warren et alia in person in Orlando. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
