[DNSOP] (no subject)
Followup One Week Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation All After pulling this back (Thanks Peter again), we went back to the authors and In the case of the DF bit, the wording is changed from "UDP responders are RECOMMENDED" to "UDP responders MAY" They also added some additional text in the security section. The authors relabeled the suggestions using "R1" -> "R12", which actually was better than my idea. The diffs can be found here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-avoid-fragmentation-14&url2=draft-ietf-dnsop-avoid-fragmentation-15&difftype=--html This will be a one week working group followup last call. We want to make sure the implementers etc are happy with these changes. This Working Group Last Call will end on September 20, 2023 thanks tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] (no subject)
Thanks for your feedback about the extended errors draft. Below are responses to some of your previously raised points in email to dnsop: 8.1 Puneet Sood ~~~ My comments on the latest version. General: Thanks for writing this - it provides useful information for our public DNS resolver implementation. 8.1.1 NOCHANGE > Section 1. Introduction and background --- > Para 4. "Authoritative servers MAY parse and use them ..." Comment: Why talk about auth servers parsing this since this field is only meant to be present in responses? + Response: because we are trying to specify what an authoritative server *should* do when it receives one, even if it doesn't expect them. IE, the DNS protocol doesn't prohibit clients from sending them so we should at least mention that servers should be prepared to receive them (even if useless). 8.1.2 DONE > Section 3.1 The R (retry) flag --- > Para 2. "implementations may receive EDE codes that it does not > understand. The R flag allows implementations to make a decision > as to what to do if it receives a response with an unknown code - > retry or drop the query." Comment: It is unclear what should be done if a response contains multiple EDE options and the R flag value is different across them. + Response: good question. Due to popular request, the R bit has now been dropped so this issue goes away. 8.1.3 NOCHANGE multiple EDE vs single - Comment: On a related note, what is the reasoning for allowing multiple instance of the EDE option in a response versus encoding all the (Response-CODE, INFO-CODE, EXTRA-TEXT) tuples in a single EDE option? A single EDE option would avoid having different values for the R flag and any new flag in the future. 16-bit length field means that total size of all EDE options should fit in a single option. + Response: Implementations already need to parse multiple extra EDE options (to avoid crashing, over-writing, etc). And the parsing structure is significantly easier if they can take the option record, pull off the 16 bit option and take the rest as text. If we added a length record for both the number of options and the number of text fields (of different lengths), this seems more complex to us than adding multiple options instead. Feel free to try to convince us otherwise, or better get all the implementations to prefer it. 8.1.4 DONE > Section 4.1.3 and 4.1.3.1 NOERROR Extended DNS Error Code 3 - Stale Answer --- Comment: 4.1.3.1 should be 4.1.3? + Response: I (Wes) just rewrote that section and ensured everything is consistent. Thanks for the catch though. 8.1.5 NOCHANGE DNSSEC bit - > Section 4.2 INFO-CODEs for use with RESPONSE-CODE: SERVFAIL(2) Comment: There are a number of INFO-CODEs here for DNSSEC failures. Over time it will be extra work for implementations to stay up to date with new INFO-CODEs added for DNSSEC failures. The R bit signals whether a resolution should be retried. Do we want also want a bit for signalling DNSSEC validation failures? Only needed if some DNSSEC related behavior needs to be different from the R bit value. + Response: 1) we've now removed the R bit, and 2) interesting idea... It seems premature without a worked example/need. Do you have an exact use case where this would prove beneficial. 8.1.6 NOCHANGE dnssec protection opts - > Section 6. Security Considerations Para 2: "but until we live in an > era where all DNS answers are authenticated via DNSSEC or other > mechanisms, there are some tradeoffs." Comment: Not clear how > DNSSEC would help here since the OPT RR is not protected by any > DNSSEC mechanism. + Response: Yes, that's true. But the sentence is talking generically, and refers to "other mechanisms" too... DNSSEC won't help with opt codes, you're right. But I don't think that was the point of the sentence. If you have specific text you'd like to propose, I'd love to see it! 8.1.7 NOCHANGE > Appendix A. -- Editorial: Missing diff summaries for new versions. + Response: very true. Sigh. I'm (Wes) horrible at remembering to write those, and I never put them in my drafts in the first place. With the advent of online diffs I don't find them as useful either. Since we're nearing last call (again), I'll likely not try to go back and retrofit them. -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] (no subject)
>From not-for-mail Fri Oct 7 22:00:19 2016 To: list-iecc-lists-ietf-dn...@johnlevine.com Path: not-for-mail Subject: Re: [DNSOP] In a vacuum, nobody can hear you scream, was On the call for adoption on Special Use Names Date: Sat, 8 Oct 2016 02:00:18 + (UTC) Organization: Taughannock Networks, Trumansburg NY Message-ID: References: <20161007012033.23623.qm...@ary.lan> <1b1fe5e9-2708-82de-a77d-a9fc20c3a...@gnu.org> Cleverness: some X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: jo...@aryv.lan (John L) From: John Levine >We have .example and example.* for documentation, yet the XMPP >documentation uses shakespeare.lit (I don't think .lit matches any SUN >or any entry in any DNS-related RFC.) FWIW, wikipedia sends .lit to some >Microsoft file extension. One cannot say that Peter St Andre is >ignorant of IETF processes. Use of *example* in documentation and >.invalid in free software is a good sign that developers are ready to >follow suit and respect the norms. In RFC 6120, it's shakespeare.example.com and shakespeare.example. If you're referring to some random web site, life is too short to enumerate all of the things that are wrong on the web. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] (no subject)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 op 11-04-14 23:12, Warren Kumari schreef: > > Can folk please let us know if they would prefer: A: The child > SHOULD remove the CDS/CDNSKEY RR from the zone once the parent has > published it (currently documented behavior) or > > B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a > small edit to the doc) I can remember the arguments against leaving them in the zone. They were: - -Leaving them in the zone makes the zone larger for a longer period of time, consuming more memory and bandwith for master-slave transfers. I think this is only minor, but it is an argument. - -Zones that do not support CDNSKEY/CDS don't have those records in the zone as well, so a provision by the server what to do in absence of the records should be made anyway for backward compatibility. - -If a zone is transfered to an operator not (yet) supporting CDNSKEY/CDS, what's the procedure for removing the records from the zone if they were compulsary? That's why we concluded that it was not compulsory to leave them in the zone, or even have them in the zone, but no harm should be done if people left them in the zone. I think the current text assumes people should allways remove the records. That I think is wrong. The text should say: - -It's ok to leave the records in the zone. - -It's also ok to take the records out of the zone, but if you do so, please follow these rules about the order to take them out: State rules. Because the procedure HOW to take the records out consumes more text, it looks like that's the standard procedure, but it isn't. That should be made more clear. Both leaving them in and taking them out are ok with me. So the text I would go with would be: C: The child MAY remove the CDS/CDNSKEY RR from the zone once the parent has published it, and this is how to do that safely. - -- Antoin Verschuren Technical Policy Advisor SIDN Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 M: +31 6 23368970 Mailto: antoin.verschu...@sidn.nl XMPP: antoin.verschu...@jabber.sidn.nl HTTP://www.sidn.nl/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJTS5aRAAoJEDqHrM883AgnkmkH+gINnriK4+jXSt60Fxv5RCSB s5HlL+D5ddfI9yq25p1Y/D438bqsSzOhiAufh3c9FVOmS36rTC3VJO2S5AcTLcOx IiCAI1yZW8zft6JEDGvz8ZGz/oA0lHuxIhrZLbMIGwDN4NPcAMOVsn/WbRrZ/7Eg ibrNrJ5ws87CzVyLIe0R6+ZQ/x65vyryai/Oq2plK6wXmmPPQPz5rw+da3qD2HI2 3b5VeIAGuo4TRgPZbF4Byo6BILZynTN0y5WQxzlTfX0OsRMQIdKQp3/C++uXCSTl 4kULKymoa6qjNuaxfBz3zuo+yQjdOv50iX0ULxx+GBC151iiTWD0bjJMggKSxhE= =rHOE -END PGP SIGNATURE- ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] (no subject)
On 11 apr 2014, at 23:12, Warren Kumari wrote: > Hi there all, > > At the moment this document says that the child SHOULD remove the > CDS/CDNSKEY record once the parent has consumed / acted on it (this > behavior was requested by someone -- unfortunately I cannot remember > whom). > > I *think* that I'm hearing that folk would prefer that the child > SHOULD leave it in, or, less strongly MAY remove it. > > This (IMO) makes the doc and the child's life simpler, but potentially > makes a bit more work for the parent -- currently most of the > time the parent will see no CDS, and so will go back to sleep. If the > child leaves them around, the parent will need to check them against > what is currently published and take action if they differ. > > Can folk please let us know if they would prefer: > A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the > parent has published it (currently documented behavior) or > > B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a > small edit to the doc) > > My personal preference is for B - it seems more elegant, but (as > always) we'll do whatever the WG wants. Let me try to explain in a neutral way what I see as an issue: As I am one of the persons that have rised the issue that we must be extremely clear on what we thing is ok here, let me explain the situation I am looking at, and that is how things work when child want to do a key rollover. I.e. child has for example DS foo and want to swap to DS bar. This implies having CDS for foo ate some point in time, CDS for foo and bar at some interval and then CDS for bar at some point in time. I.e. both add bar and remove foo. This is, I think -- but can be wrong, much easier if CDS foo is in the zone all the time DS for foo is to be valid, and then CDS for bar is in the zone as long as the DS for bar is to be valid. Example below is for CDS because it is shorter to type, but can be valid for CDNSKEY as well of course (and yes, Antoine has convinced me as well that DNSKEY is the path forward...;-) ). The argument for me is that if CDS is removed, then we have: 1. Add DS foo 1.1. Add CDS foo 1.2. Remove CDS foo 2. Add DS bar and remove DS foo 1.2. Add CDS foo 2.2. Add CDS bar 2.3. Remove CDS foo 2.4. Remove CDS bar I am here nervous over the parent detecting 2.4 before 2.3, and the wrong DS is removed. Note that the last DS is never removed if the last CDS is removed from the zone. And the parent still must detect when CDS foo is added that that is already in the parent zone, and no action is needed. If the CDS stays in the zone, we have: 1. Add DS foo 1.1 Add CDS foo 2. Add DS bar and remove DS foo 2.1. Add CDS bar 2.2 Remove CDS foo So I am in favor of B. Patrik signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] (no subject)
Hi there all, At the moment this document says that the child SHOULD remove the CDS/CDNSKEY record once the parent has consumed / acted on it (this behavior was requested by someone -- unfortunately I cannot remember whom). I *think* that I'm hearing that folk would prefer that the child SHOULD leave it in, or, less strongly MAY remove it. This (IMO) makes the doc and the child's life simpler, but potentially makes a bit more work for the parent -- currently most of the time the parent will see no CDS, and so will go back to sleep. If the child leaves them around, the parent will need to check them against what is currently published and take action if they differ. Can folk please let us know if they would prefer: A: The child SHOULD remove the CDS/CDNSKEY RR from the zone once the parent has published it (currently documented behavior) or B: The child SHOULD NOT remove the CDS/CDNSKEY RR (will require a small edit to the doc) My personal preference is for B - it seems more elegant, but (as always) we'll do whatever the WG wants. W ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
