Re: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS)
Hi Authors, Just a note/reminder that I am stepping down as an AD in March. I don’t think that I’ve seen any reply to my DISCUSS comments (perhaps the authors and/or WG are still discussing the resolution), but if you are able to speed this up at all so that I can clear my discuss before I step down that would be preferable. Actually, if you manage to clear all the DISCUSSes on this doc before March, so that Warren can approve it before the new IESG is seated, that would probably make both yours and Warren’s lives slightly easier at the transition. Regards, Rob From: DNSOP on behalf of Robert Wilton via Datatracker Date: Tuesday, 2 January 2024 at 15:41 To: The IESG Cc: draft-ietf-dnsop-avoid-fragmentat...@ietf.org , dnsop-cha...@ietf.org , dnsop@ietf.org , be...@nlnetlabs.nl , swo...@pir.org , tjw.i...@gmail.com , tjw.i...@gmail.com Subject: [DNSOP] Robert Wilton's Discuss on draft-ietf-dnsop-avoid-fragmentation-16: (with DISCUSS) Robert Wilton has entered the following ballot position for draft-ietf-dnsop-avoid-fragmentation-16: 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-avoid-fragmentation/ -- DISCUSS: -- Hi, Thanks for this document. I'm echoing Paul's and the SECDIR review comments here on the use of MAY in recommendations (since everywhere you see MAY it is equally valid for an interpretation to treat it as "MAY NOT"), but I think that this makes the document, as a proposed BCP, unclear enough that I'm raising this to level of a DISCUSS. (1) p 3, sec 3.1. Recommendations for UDP responders At the time of writing, most DNS server software did not set the DF bit for IPv4, and many OS kernel constraints make it difficult to set the DF bit in all cases. Best Current Practice documents should not specify what is currently impossible, so R2, which is setting the DF bit, is "MAY" rather than "SHOULD". I think that this recommendation, particularly because it is using RFC 2119 language, is unclear. I would suggest rephasing this to something like: R2. Where supported, UDP responders SHOULD set IP "Don't Fragment flag (DF) bit" [RFC0791] on IPv4. (2) p 3, sec 3.2. Recommendations for UDP requestors R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to the RECOMMENDED size of 1400 or a smaller size. I find this recommendation to be unclear because it mixes both a "SHOULD" and "RECOMMENDED", i.e., I find it unclear as to what the "SHOULD" applies to. Is the recommendation (i) that UDP requestors should limit the maximum UDP payload. Or (ii) is the recommendation that a limit of 1400 be used, or (iii) perhaps both. Maybe rewording this to something like the following would help: R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size to 1400 bytes, but MAY limit the maximum UDP payload size to a smaller size on small MTU (less than 1500 bytes) networks. or, R6. UDP requestors SHOULD limit the requestor's maximum UDP payload size. It is RECOMMENDED to use a limit of 1400 bytes, but a smaller limit MAY be used. (3) p 3, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. As written, I don't think that this is really a recommendation. Either it is a just a statement or fact (in which case it is not a recommendation), or it should be upgraded to a SHOULD. (4) p 4, sec 3.2. Recommendations for UDP requestors R7. UDP requestors MAY drop fragmented DNS/UDP responses without IP reassembly to avoid cache poisoning attacks. R8. DNS responses may be dropped by IP fragmentation. Upon a timeout, to avoid resolution failures, UDP requestors MAY retry using TCP or UDP with a smaller EDNS requestor's maximum UDP payload size per local policy. Again, I think that this document would be clearer if this was a SHOULD rather than a MAY. Regards, 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
Re: [DNSOP] Followup Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping
All This is a followup on our Working Group Last Call for draft-ietf-dnsop-dnssec-bootstrapping is ongoing until Saturday February 3, 2024, There has been support for publication, but we are always looking for more feedback. The comments raised appear to have been resolved by the authors. If someone feels we missed something, please speak up. thanks tim On Sat, Jan 20, 2024 at 6:23 PM Tim Wicinski wrote: > > All > > Peter has integrated feedback from the first working group last call, and > we'd like to do a followup last call. The diff with the current version > is here: > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-dnssec-bootstrapping-05&url2=draft-ietf-dnsop-dnssec-bootstrapping-07&difftype=--html > > This starts a Working Group Last Call for > draft-ietf-dnsop-dnssec-bootstrapping > > Current versions of the draft is available here: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ > > The Current Intended Status of this document is: Proposed Standards > > Please review the draft and offer relevant comments. > > For WGLC, we need positive support and constructive comments; lack of > objection is not enough. > So if you think this draft should be published as an RFC, please say so. > > If you feel the document is *not* ready for publication, please speak out > with your reasons. > > > This starts a two week Working Group Last Call process, and ends on: > February 3, 2024 > > thanks > tim > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Held for Document Update] RFC8906 (7689)
The following errata report has been held for document update for RFC8906, "A Common Operational Problem in DNS Servers: Failure to Communicate". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7689 -- Status: Held for Document Update Type: Technical Reported by: Josh Soref Date Reported: 2023-10-26 Held by: Warren Kumari (Ops AD) (IESG) Section: 8.2.8 Original Text - expect: DO=1 to be present if an RRSIG is in the response Corrected Text -- expect: flag: do to be present if an RRSIG is in the response Notes - The same section has `expect: flag: aa to be present`, and when running the suggested command, no `DO=1` is shown, which makes the advice unhelpful. Sample command: ``` $ dig +nocookie +edns=0 +noad +norec +dnssec soa $zone @$server ; <<>> DiG 9.16.44-Debian <<>> +nocookie +edns +noad +norec +dnssec soa powerdns.com @2600:3c03::f03c:91ff:fe55:e54d ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 45268 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ;; QUESTION SECTION: ;powerdns.com. IN SOA ;; Query time: 0 msec ;; SERVER: 2600:3c03::f03c:91ff:fe55:e54d#53(2600:3c03::f03c:91ff:fe55:e54d) ;; WHEN: Thu Oct 26 22:26:44 UTC 2023 ;; MSG SIZE rcvd: 41 ``` [ WK: For more info, see thread: https://mailarchive.ietf.org/arch/msg/dnsop/gA71yLWLZ8-eylYgKjNy9emP9hU/ It was also suggested that reminding readers that "@$server" in this case refers to an authoritative server, and not a recursive server - See Sec 8 ] -- RFC8906 (draft-ietf-dnsop-no-response-issue-23) -- Title : A Common Operational Problem in DNS Servers: Failure to Communicate Publication Date: September 2020 Author(s) : M. Andrews, R. Bellis Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Errata 7689 against RFC 8906, "A Common Operational Problem in DNS Servers: Failure to Communicate"
Thanks all, done! W On Tue, Jan 16, 2024 at 5:01 AM, Joe Abley wrote: > Hi Warren, > > On 15 Jan 2024, at 22:49, Warren Kumari wrote: > > Seeing as the document says you should "expect: flag: aa to be present", > it does seem like it would be better if it also said: "expect: flag: do to > be present if an RRSIG is in the response", as that is more inline with > what someone writing a test would see. > > If someone checks for "flag: aa" literally in output they will be > disappointed, given the output in your example. > > Similarly, if someone checks for "flag: do" literally in output they will > suffer a different kind of disappointment, since the dig output uses > "flags" plural. > > However, I think it would actually be better to detach the language more > clearly from the output of a particular version of a particular tool (not > just in this document, but in all documents). It's not like dig is the only > game in town, and it's not like the output of dig is invariant between > releases. > > This seems like a fairly simple clarification / place where things could > have been worded better, but I don't think that it rises to the level of a > "Verified" errata, but it's also not wrong, so my proposed resolution is: > > Accept the errata as Editorial, Hold for Document Update. > > That seems reasonable to me. > > Joe > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Dealing with some open Errata:
On Mon, Jan 15, 2024 at 7:51 PM, John Levine wrote: > It appears that Paul Wouters said: > > Section 4.1.2. says: > | URI| _dccp | [RFC7566] | > > I think this might have been part of a list used to "reserve" the names of > (transport) protocols, so that constructs like _25._quic.example.com > could be constructed where the _name denotes the protocol and not the name > of something. I think dccp got added to this list because it is references > as a "transport protocol" in RFC4340 and the author wanted to make sure > transport protocol names were not accidentally squatted by newly invented > things with a clashing name/acronym. > > I think I'm the one who added it and that was definitely the idea. You > should be able to use SRV or URI with any transport protocol so in view of > the modest set of transport protocols in use, we might as well reserve > their names. Dunno where that RFC number came from, though. > Okey donkey —I think that the best outcome then is to do what Dave suggested above — "leave the registration but take out the reference.". I'd love to be able to ask IANA to make the reference be "Because, well, we felt like it….", but I'm trying to at least pretend to be a grownup, so I won't… W > R's, > John > > ___ > 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] Dealing with some open Errata:
Whoops, apologies, the previous reply was in my Drafts and I hit send on the wrong version. I will ask the IANA to update the reference to be RFC4340, and include a link to this thread. W On Mon, Jan 29, 2024 at 1:27 PM, Warren Kumari wrote: > On Mon, Jan 15, 2024 at 7:51 PM, John Levine wrote: > >> It appears that Paul Wouters said: >> >> Section 4.1.2. says: >> | URI| _dccp | [RFC7566] | >> >> I think this might have been part of a list used to "reserve" the names >> of (transport) protocols, so that constructs like _25._quic.example.com >> could be constructed where the _name denotes the protocol and not the name >> of something. I think dccp got added to this list because it is references >> as a "transport protocol" in RFC4340 and the author wanted to make sure >> transport protocol names were not accidentally squatted by newly invented >> things with a clashing name/acronym. >> >> I think I'm the one who added it and that was definitely the idea. You >> should be able to use SRV or URI with any transport protocol so in view of >> the modest set of transport protocols in use, we might as well reserve >> their names. Dunno where that RFC number came from, though. >> > > > Okey donkey —I think that the best outcome then is to do what Dave > suggested above — "leave the registration but take out the reference.". > > I'd love to be able to ask IANA to make the reference be "Because, well, > we felt like it….", but I'm trying to at least pretend to be a grownup, so > I won't… > > W > > > >> R's, >> John >> >> ___ >> 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] [Errata Verified] RFC8552 (7066)
The following errata report has been verified for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7066 -- Status: Verified Type: Editorial Reported by: Bernie Hoeneisen Date Reported: 2022-08-02 Verified by: Warren Kumari (Ops AD) (IESG) Section: 4.1.2. Original Text - | URI| _dccp | [RFC7566] | Corrected Text -- | URI| _dccp | [RFC4340] | Notes - Wrong reference. RFC7566 does not even mention "dccp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please see the thread for resolution: https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ] -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] [Errata Verified] RFC8552 (7067)
The following errata report has been verified for RFC8552, "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7067 -- Status: Verified Type: Editorial Reported by: Bernie Hoeneisen Date Reported: 2022-08-02 Verified by: Warren Kumari (Ops AD) (IESG) Section: 4.1.2. Original Text - | URI| _sctp | [RFC6118] | Corrected Text -- | URI| _sctp | [RFC4340] | Notes - Wrong reference. RFC6118 does not even mention "sctp". Note that this also has an impact to the IANA registry: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names [ Warren Kumari (Ops AD): Please also see Errata 7066, and the thread https://mailarchive.ietf.org/arch/msg/dnsop/WFMXL5dY8sniHwVtkPfcqvWk3nI/ This was added as "part of a list used to "reserve" the names of (transport) protocols, so that constructs like _25._quic.example.com could be constructed where the _name denotes the protocol and not the name of something." . I am requesting that the IANA update the reference to match. ] -- RFC8552 (draft-ietf-dnsop-attrleaf-16) -- Title : Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves Publication Date: March 2019 Author(s) : D. Crocker Category: BEST CURRENT PRACTICE Source : Domain Name System Operations Area: Operations and Management Stream : IETF Verifying Party : IESG ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Domain Name System Operations (dnsop) WG Virtual Meeting: 2024-01-30
IESG Secretary writes: > The Domain Name System Operations (dnsop) WG will hold a virtual > interim meeting on 2024-01-30 from 18:00 to 19:00 Europe/Amsterdam > (17:00 to 18:00 UTC). I'm sadly very day-job conflicted with this slot, but greatly look forward to watching the replay afterward (I may try to sneak an earpiece into my head but it's unlikely I can pull that off). I'll note that if we're going to go down the road of such a major change to parent/child/resolver interactions, it is highly important we get opinions and viewpoints from all segments of the DNS industries to ensure this is widely deployable. Having said that, if I can't keep my own zones in sync properly with my registry's advertised data: it's time to do something about the problem. [yes I recognize this is not an adequate summary of the problem space, but it's a part]. Whether this is the right solution or not will depend on feedback from many voices. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
Edward Lewis writes: > # 1.6. Facilities > # > #The DELEG record is extensible in such a way that future innovations > #in the domain name system, such as new methods of secure transport, > #message encoding, error reporting, etc, does not depend on a re- > #design of the DNS. > > But the DELEG resource record enables redesigning (portions or all of) > the DNS. I think the point is that DELEG allows the DNS namespace to > continue to be published while there are transitions in the DNS > publication protocol (motivated by improving the state of operations). Put another way: yes, DELEG records are extensible. Just like the DNS is with new RRTYPEs. But we've proven already (and DELEG is an example) that trying to assume adding a new RRTYPE or DELEG flag may require fundamental changes in processing regardless of how that new flag is encoded. Extensibility != easy deployability. It *can* but it shouldn't be assumed that all future simple on the wire changes of any type won't require major code overhauls to handle it. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSOPComments on draft-dnsop-deleg-00.txt - section 1
Moin! On 30 Jan 2024, at 1:00, Wes Hardaker wrote: > Edward Lewis writes: >> But the DELEG resource record enables redesigning (portions or all of) >> the DNS. I think the point is that DELEG allows the DNS namespace to >> continue to be published while there are transitions in the DNS >> publication protocol (motivated by improving the state of operations). > > Put another way: yes, DELEG records are extensible. Just like the DNS > is with new RRTYPEs. But we've proven already (and DELEG is an example) > that trying to assume adding a new RRTYPE or DELEG flag may require > fundamental changes in processing regardless of how that new flag is > encoded. Extensibility != easy deployability. It *can* but it > shouldn't be assumed that all future simple on the wire changes of any > type won't require major code overhauls to handle it. I agree that future extensions will require code changes, but having a record type that is extensible from the start might make it easier to deploy new parameters then it is to do a full RRTYPE, at least that is the hope. So long -Ralf --- Ralf Weber ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] DELEG and parent only resolution
I read draft-dnsop-deleg-00. It proposes new name resolution using only information on the parent side. In the past, the dnsop WG debated parent centric name resolution and child centric, and some people did not like parent centric. If people prefer parent-centric/parent-only name resolution, there are solutions other than DELEG, such as parent centric name resolution, distinguishing the handling of authoritative data, referrals, and glue, and adding a signature of referral/in-domain in the parent. Is anyone interested in proceeding with minor fixes that are not DELEG? Previously, I prposed draft-fujiwara-dnsop-resolver-update and draft-fujiwara-dnsop-delegation-information-signer. (They are too old and need to be updated.) Or, I would like to read complete version of draft-dnsop-deleg that have alpn and tlsa parameters. Regards, -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
