[DNSOP]Re: Second (short) WGLC for draft-ietf-dnsop-zoneversion

ggestions. We’ve implemented all your suggested changes > in the source document. We’ll wait a few days for any more changes and > then publish a new revision. > > DW > > > > On May 12, 2024, at 1:30 AM, Donald Eastlake wrote: > > > > Caution: This email originated

[DNSOP]Re: Second (short) WGLC for draft-ietf-dnsop-zoneversion

Hi, I support this draft but have the following comments: I would assume this has been discussed before but, presumably, the purpose of this document is to see that the zoneversion option will interoperate between different implementations. So, why isn't it Standards Track? NSID should be

Re: [DNSOP] TKEY and MD5

So Mark, You were the one who kicked-off my so-far feeble effort to do an rfc2930bis in the thread starting with the message below... Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On

Re: [DNSOP] [Ext] About key tags

So, I am the person who added key tags in the initial design of DNSSEC. The idea was just to, probabilistically, avoid unnecessary expensive validation attempts. If key tags are causing problems for some resolvers and validations are not such a problem with modern hardware, you can always just

Re: [DNSOP] WGLC rfc8499bis one week extension for lame delegation definition

I've been around in DNS for quite a while. The way I've always heard "lame delegation" used is in the sense of a useless parent NS record at a delegation point. Note that "delegation" is singular. The usual case is that the server name in the NS RR is a non-existent name or has no address

Re: [DNSOP] WGLC for draft-ietf-dnsop-alt-tld

I support publication of this draft. Since it has no keywords in it, Section 1.1 should be deleted. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com > > *From: *DNSOP on behalf of

Re: [DNSOP] [Ext] I-D Action: draft-ietf-dnsop-dnssec-bcp-04.txt

Hi, On Fri, Oct 7, 2022 at 2:17 PM Peter Thomassen wrote: > On 10/7/22 19:46, Roy Arends wrote: > > Perhaps: > > > > What we refer to as "DNSSEC" is the third iteration of the DNSSEC > specification; [RFC2065] being the first, [RFC2535] being the second. > Earlier iterations have not been

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

I support adoption of this draft. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Tue, Jul 12, 2022 at 9:54 AM Tim Wicinski wrote: > > This starts a Call for Adoption for Negative

Re: [DNSOP] Andrew Alston's Discuss on draft-ietf-dnsop-nsec3-guidance-08: (with DISCUSS and COMMENT)

Hi Andrew, If you want to claim that because of the recommendations in it, this document should be standards track instead of BCP, there might be some merit to such a position, although personally I think it is fine as a BCP and I don't think the code point allocation has anything to do with this

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

What you describe is completely improper but I'm not sure it's exactly accurate. When you said you were "removed" as an author, I assumed that a new revision of a draft was posted where you were a first page author for version N but not listed as an author for version N+1. That would also be

Re: [DNSOP] The serial arithmetic involved in the comparison of the inception and expiration timestamp of RRSIG record

On Thu, Mar 3, 2022 at 7:00 PM Joey Deng wrote: > Hello, > > [RFC 4034 3.1.5. Signature Expiration and Inception > Fields](https://datatracker.ietf.org/doc/html/rfc4034#section-3.1.5) says: > > > The Signature Expiration and Inception field values specify a date and time > > in the form of a

Re: [DNSOP] [Ext] TKEY and MD5

On Mon, Dec 20, 2021 at 10:42 PM Paul Hoffman wrote: > On Dec 20, 2021, at 6:57 PM, Mark Andrews wrote: > > Isn’t it about time we updated DH support in DNS to not use MD5? Currently > > there is > > no FIPS compatible DH key exchange in DNS. I suspect it would be > > relatively straight > >

Re: [DNSOP] [Ext] Martin Duke's Discuss on draft-ietf-dnsop-dnssec-iana-cons-04: (with DISCUSS and COMMENT)

It would seem that registry references are not always fully updated. Another example I stumbled over recently is that RFC 3404 obsoletes RFCs 2915 and 2168 but they were both left in as references in the IANA RR registry entry for NAPTR when RFC 3404 was added as a reference... Last I heard, IANA

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

Hi, I think this is a good, short draft and I support its publication. The assignment requirement level it imposes is more appropriate than the current requirement. I do have some suggestions which range from minor to trivial: - Delete "some" from the first line of the Abstract. - To

Re: [DNSOP] Draft-ietf-dnsop-private-use-tld and the ISO

On Mon, Jul 26, 2021 at 9:02 PM Jim Reid wrote: > > > On 27 Jul 2021, at 01:56, Donald Eastlake wrote: > > > > Looks like initial query from IAB to ISO is > > https://datatracker.ietf.org/liaison/1720/ > > > > Maybe I'm blind but I don't see a response...

Re: [DNSOP] Draft-ietf-dnsop-private-use-tld and the ISO

All in and out liaisons are, I think, supposed to be posted at https://datatracker.ietf.org/liaison/posted/ Looks like initial query from IAB to ISO is https://datatracker.ietf.org/liaison/1720/ Maybe I'm blind but I don't see a response... Thanks, Donald === Donald

Re: [DNSOP] Adoption of new EDNS opcode "rrserial"

Seems like a good idea to me. I think the WG should adopt it. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, Jan 27, 2020 at 10:09 AM Hugo Salgado wrote: > > Dear DNSOPers, as

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

Hi, On Wed, Apr 28, 2021 at 8:24 AM Roy Arends wrote: > Hi Donald, > > On 28 Apr 2021, at 03:34, Donald Eastlake wrote: > > I am not comfortable with grabbing all the permanently unassigned 2-letter > country codes for DNS private use. > > > Note: I was the primary

Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

I am not comfortable with grabbing all the permanently unassigned 2-letter country codes for DNS private use. Note: I was the primary author of RFC 2606 and have been involved in this sort of thing before. See https://datatracker.ietf.org/doc/draft-eastlake-2606bis/

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

Hi, Thanks for the quick response. See below. On Fri, Apr 23, 2021 at 1:36 PM Wessels, Duane wrote: > > > On Apr 22, 2021, at 11:50 AM, Donald Eastlake wrote: > > > > Hi, > > > > This is a good document and I support publication. > > > > However

Re: [DNSOP] WGLC for draft-ietf-dnsop-tcp-requirements

Hi, This is a good document and I support publication. However, I do have some comments. I scanned the Last Call comments by others, and they mostly seem like improvements, but some of my comments below may duplicate others for which I apologize in advance. Section 3, last paragraph: Cut out

Re: [DNSOP] default value of draft-ietf-dnsop-avoid-fragmentation

Hi, On Thu, Mar 18, 2021 at 10:43 PM Viktor Dukhovni wrote: > On Mon, Mar 15, 2021 at 05:38:40PM +, Jim Reid wrote: > > > ... > ... > > This could get nasty with icky CPE > > firmware: imagine every home router in (say) Comcast’s net doing PMTU > > to the same root server. > > These would

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

On Thu, Dec 17, 2020 at 1:19 PM Rob Wilton (rwilton) wrote: > Hi Donald, > > > -Original Message- > > From: Donald Eastlake > > Sent: 17 December 2020 18:00 > > To: Rob Wilton (rwilton) > > Cc: The IESG ; draft-ietf-dnsop-server-cook...@ietf.org; &g

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-server-cookies-04: (with COMMENT)

Hi, On Thu, Dec 17, 2020 at 6:50 AM Robert Wilton via Datatracker wrote: > > Robert Wilton has entered the following ballot position for > draft-ietf-dnsop-server-cookies-04: No Objection > > ... > > -- > COMMENT: >

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Fri, Oct 9, 2020 at 5:23 AM Rob Wilton (rwilton) wrote: > > Hi Donald, > > > -Original Message- > > From: Donald Eastlake > > Sent: 09 October 2020 00:47 > > To: Rob W

Re: [DNSOP] Robert Wilton's No Objection on draft-ietf-dnsop-dns-zone-digest-12: (with COMMENT)

On Thu, Oct 8, 2020 at 7:18 AM Robert Wilton via Datatracker wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-12: No Objection > > ... > > -- > COMMENT: >

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-10.txt

Hi, Replying on just one point: On Mon, Sep 21, 2020 at 2:27 PM Michael StJohns wrote: > > ... > > 2.2.4 - SHA384 has a hash length of 48 bytes. 12 bytes seems to imply > some sort of left or right truncation. Show stopper! Explain how this > value was selected and how it interacts with the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt

Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, May 11, 2020 at 12:29 AM Donald Eastlake wrote: > >> The incremental effort to implement SHA-224 if you are implementing >> SHA-256 is miniscule

Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc2845bis-08.txt

The incremental effort to implement SHA-224 if you are implementing SHA-256 is miniscule. It makes no sense to me for SHA-224 to be NOT RECOMMENDED to use when SHA-256 is MUST implement and RECOMMENDED to use and you can use SHA-256 with truncation to 224 or even fewer bits. Thanks, Donald

Re: [DNSOP] Last Call: (Extended DNS Errors) to Proposed Standard

Hi Wes, On Mon, Mar 30, 2020 at 4:35 PM Wes Hardaker wrote: > > Donald Eastlake writes: > > > My apologies for getting in some minor comments so late. I do not > > suggest any technical changes. However, at least to my eye, there are > > some little glitches an

Re: [DNSOP] Last Call: (Extended DNS Errors) to Proposed Standard

Hi, My apologies for getting in some minor comments so late. I do not suggest any technical changes. However, at least to my eye, there are some little glitches and editorial changes I would suggest. Among the glitches I see are incorrect internal cross references, old implementation key word

Re: [DNSOP] Call for Adoption: draft-sury-toorop-dnsop-server-cookies

Support as an authors. This draft fixes few little ways the existing RFC unintentionally missed on interoperability and makes some simplifying changes. Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 1424 Pro Shop Court, Davenport, FL 33896 USA

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-06.txt

Hi, Two comments: 1. Maybe I'm confused but it seems to me that the RESPONSE-CODE field of 12 bits plus the INFO-CODE field of 16 bits is 28 bits. So I don't understand the 2nd paragraph of Section 3.3 that talks about their concatenation fitting within 24 bits. 2. On the code

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-01.txt

On Mon, May 13, 2019 at 1:03 AM Joe Abley wrote: > > I don't know what experts could be expected to know enough about the entire > ecosystem to make that call. I also don't know that there's any measurement > that could be used in all cases to indicate that an RRTYPE is dead. These > both seem

Re: [DNSOP] I-D Action: draft-ietf-dnsop-extended-error-03.txt

Wes Hardaker > > David C Lawrence > > Filename: draft-ietf-dnsop-extended-error-03.txt > > Pages : 12 > > Date: 2018-12-20 > > 4 Donald Eastlake > .. 4.1 DONE two dimens

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-extended-error

I like the Extended Error Code using EDNS idea. This was effectively what was done with TSIG and TKEY that have an expanded Error field inside the RR. However: >> I don't see any reason for the complex two-dimensional table to new error codes. Given that 16 bits is available for "INFO-CODE"

Re: [DNSOP] DNS cookies and multi-vendor anycast incompatibility

Hi, As the first author of the DNS Cookies RFC, I would be happy to generate a draft to standardize this to improve inter vendor interoperability for anycast servers. Thanks, Donald On Thu, Jun 21, 2018 at 03:54 Ondřej Surý wrote: > > On 21 Jun 2018, at 09:24, Petr Špaček wrote: > > So let

Re: [DNSOP] [Ext] RCODE and CNAME chain

See RFC 6604. Donald from iPhone On Wed, Apr 5, 2017 at 09:34 Edward Lewis wrote: > On 4/5/17, 01:43, "DNSOP on behalf of Mukund Sivaraman" < > dnsop-boun...@ietf.org on behalf of m...@isc.org> wrote: > > >It seems BIND currently returns NXDOMAIN in this case, and the

Re: [DNSOP] BULK RR as optional feature

Wouldn't a BULK RR ignorant DNS server just store the BULK RR as opaque data? Thanks, Donald === Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Mar 28, 2017 at 2:31 PM, John Levine

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

Hi, I've read this thread up to date. Reading the draft, a few minor things occurred to me which I think might be small improvements, but I could be wrong as I'm sure others have studied this more than me. And perhaps some more warning should be sprinkled into it. But, when I get to the bottom

Re: [DNSOP] Looking for IANA registry for --xn

Hi, On Thu, Oct 6, 2016 at 3:14 PM, Jim Reid <j...@rfc1035.com> wrote: > > On 6 Oct 2016, at 18:59, Donald Eastlake <d3e...@gmail.com> wrote: > > I don't believe there is a registry. > > Actually there is. Sort of: % whois -h whois.iana.org テスト > % IANA WHOI

Re: [DNSOP] Looking for IANA registry for --xn

I don't believe there is a registry. It would seem reasonable to reserve labels starting with all other [a-z][a-z]-- besides xn-- and establish a registry. (To avoid people trying to squat on names in advance, the "xn" was selected by the same sort of publicly verifiable random process as nomcom

Re: [DNSOP] Alternative Special-Use TLD problem statement draft

Adrien, On Thu, Apr 7, 2016 at 7:13 PM, Adrien de Croy wrote: > -- Original Message -- > From: "Stephane Bortzmeyer" > To: "Adrien de Croy" > Cc: "Philip Homburg" ; "dnsop@ietf.org" > ; "Ted

Re: [DNSOP] Stephen Farrell's No Objection on draft-ietf-dnsop-cookies-09: (with COMMENT)

Hi Stephen, On Wed, Jan 20, 2016 at 7:10 AM, Stephen Farrell wrote: > Stephen Farrell has entered the following ballot position for > draft-ietf-dnsop-cookies-09: No Objection > > ... > > -- > COMMENT:

Re: [DNSOP] Alissa Cooper's Yes on draft-ietf-dnsop-cookies-09: (with COMMENT)

Hi Alissa, On Tue, Jan 19, 2016 at 8:59 PM, Mark Andrews wrote: > > In message <20160120001031.9209.94235.idtrac...@ietfa.amsl.com>, "Alissa > Cooper > " writes: >> Alissa Cooper has entered the following ballot position for >> draft-ietf-dnsop-cookies-09: Yes >> >> ... >> >>

Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

I endorse and support Stuart Cheshire's remarks below. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire wrote: > Hi Joe,

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-08.txt

This revision resolves SECDIR review comments and one IETF Last Call comment on the IETF discuss list. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Thu, Dec 24, 2015 at 12:29 PM,

Re: [DNSOP] draft-jabley-dnsop-ordered-answers

On Wed, Nov 4, 2015 at 9:37 PM, Joe Abley wrote: > Hi all, > > I couldn't quite interpret the questions and hums in the room; was the > consensus > > (a) this clarification is not needed; the existing spec is clear enough, or > > (b) a clarification might be useful, but the

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt

0/28/15 7:03 AM, Donald Eastlake wrote: >> >> OK. I could produce an updated draft with fixes for those typos to >> upload during IETF meeting week but I'm not sure if other changes are >> desired. >> >> Thanks, >> Donald > > > Please feel free. We've be

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt

Hi Stephane, Sorry for slow response, I've been traveling on vacation. On Sat, Oct 24, 2015 at 3:49 PM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > On Mon, Oct 19, 2015 at 05:33:49PM -0400, > Donald Eastlake <d3e...@gmail.com> wrote > a message of 59 lines which sai

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-06.txt

This revision incorporated editorial improvements and improvements in explanatory and motivational text based on comments on the WG mailing list. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA

Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies

Hi, On Wed, Aug 5, 2015 at 4:58 AM, Ralf Weber d...@fl1ger.de wrote: ... But lets focus on the way the server handles cookies. I think I discussed that with you or Donald in Prague. There are two ways to do this so that each client gets a different cookie, which is what the draft suggest:

Re: [DNSOP] Seeking more WG Last Call reviewfordraft-ietf-dnsop-cookies

Hi Ted, On Tue, Aug 4, 2015 at 11:47 AM, Ted Lemon ted.le...@nominum.com wrote: ... To recap, the reason that I think cookies are more expensive than DNSSEC in practice is that for cookies to be deployed in the real world, the DNS server implementing them will need to maintain state: the fact

Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies

Hi Ted, On Tue, Aug 4, 2015 at 11:50 AM, Ted Lemon ted.le...@nominum.com wrote: On Aug 4, 2015, at 4:20 AM, Mark Andrews ma...@isc.org wrote: If you are under attack the current method drop or send back TC=1. TC=1 means managing many more TCP session on both the server and client side. With

Re: [DNSOP] Seeking more WG Last Call review fordraft-ietf-dnsop-cookies

On Tue, Aug 4, 2015 at 12:39 PM, Ted Lemon ted.le...@nominum.com wrote: On Aug 4, 2015, at 12:30 PM, Donald Eastlake d3e...@gmail.com wrote: I think Mark was pointing out that if you are under attack and want to use weak authentication to help resist that attack, there is no particular reason

Re: [DNSOP] Seeking more WG Last Call review for draft-ietf-dnsop-cookies

Hi Ted, On Mon, Jul 20, 2015 at 8:03 AM, Ted Lemon ted.le...@nominum.com wrote: I sent this out on July 20, but unfortunately just to Paul Hoffman. I was puzzled as to why it didn’t get any response on the mailing list, but this explains it… :} Your headers still seem a bit messed up as

Re: [DNSOP] I-D Action: draft-ietf-dnsop-cookies-05.txt

This revisions incorporates the early allocation of 23 as the BADCOOKIE RCODE and the changes agreed to on this mailing list. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com On Sat, Aug 1,

Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies

Hi Hosnieh, On Mon, Jul 20, 2015 at 10:55 AM, Hosnieh Rafiee i...@rozanak.com wrote: This is not highlighted in the draft which makes it confusing for the reader which causes to raise such question regarding NAT. Because it is irrelevent has to how the attacker chooses the address to

Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies

Hi, I think Mark has done a good job in responding, so I don't really have much to add. If you can conveniently do configuration at the client and server, then you can get strong authentication with TSIG. If you can't, the weak authentication provided by Cookies is about the best you can do.

Re: [DNSOP] Review of draft: draft-ietf-dnsop-cookies

Hi Ralf, On Mon, Jul 20, 2015 at 7:19 AM, Ralf Weber d...@fl1ger.de wrote: Moin! On 20 Jul 2015, at 4:39, Mark Andrews wrote: No. The server takes the fake_client_cookie + IP client (victim) + server secret + maybe parts of server cookie itself. Computes a server cookie and compares that

Re: [DNSOP] DNS rcode assignment requirements

I see two cases: There are codes from the unified DNS error code space that are not visible at the top level of a DNS message. For example, the Error field of TSIG (RFC 2845) or TKEY (RFC 2930). For things like that I have no problem with Specification Required or Expert Review. However, for top

Re: [DNSOP] Review of draft-ietf-dnsop-cookies

Hi, I'll just reply where Mark did not: On Sun, Jul 5, 2015 at 7:48 PM, Paul Hoffman paul.hoff...@vpnc.org wrote: Greetings. This is a WG LC review of draft-ietf-dnsop-cookies, which I had not looked at carefully in some time. In short: it looks great, the document is complete and

Re: [DNSOP] Summary of the two options in draft-ietf-dnsop-cookies?

Hi, I've made some progress on the FNV code. I expect to be able to advance it, presumably as AD sponsored, before the next IETF. On DNS Cookies errors, I agree that the utility of the error field, as far as we can see right now, is quite limited. Still, there can be error conditions in the

[DNSOP] Fwd: New Version Notification for draft-eastlake-dnsext-cookies-05.txt

Hi, A new version of the DNS Cookies draft has been posted as below. Thanks, Donald = Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e...@gmail.com -- Forwarded message -- From: internet-dra...@ietf.org

Re: [DNSOP] [dhcwg] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

Hi, On Sun, Oct 23, 2011 at 7:49 PM, Mark Andrews ma...@isc.org wrote: In message 96472fb7-8425-4928-8f55-2abf2cb59...@conundrum.com, Matthew Pounse tt writes: On 2011/10/22, at 15:21, Keith Moore wrote: On Oct 22, 2011, at 2:42 PM, Doug Barton wrote: 1. I think we're all in