[DNSOP] WGLC for draft-ietf-dnsop-dnssec-automation, "DNSSEC automation".

Dear colleagues, This initiates the Working Group Last Call (WGLC) for draft-ietf-dnsop-dnssec-automation, "DNSSEC automation". The draft can be reviewed here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-automation

[DNSOP] WGLC for draft-ietf-dnsop-compact-denial-of-existence

Dear colleagues, This message starts a Working Group Last Call for draft-ietf-dnsop-compact-denial-of-existence, “Compact Denial of Existence in DNSSEC”. Current and previous versions of the draft are available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existe

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Thanks Brian for your comments. Currently the draft only allows zoneversion extension for records in the ANSWER section of the response. But you're right that even there we could have records from different zones. For the sake of simplicity I'd prefer to clarify the text and declaring such case a

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Top-reply (to avoid adding to confusion by attempting to add in-line commentary of uncertain value): I also agree that this is very valuable and definitely helpful for diagnostics. I think there are a number of edge cases, for which disambiguation might be helpful. Apologies if this seems to add c

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Hi Joe, thanks for your comments. Answers inline: On 14:16 27/04, Joe Abley wrote: > On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed, > Apr 26, 2023 at 23:07, Suzanne Woolf < wrote: > > > This email begins a Working Group Last Call for > > draft-ietf-dnsop-zoneversi

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Yes, that's pretty succinct and clear. G On Sat, 29 Apr 2023, 04:26 Hugo Salgado, wrote: > Thanks a lot George for your comments. > About this suggestion: > > On 14:29 27/04, George Michaelson wrote: > > It's a debug tool. It isn't going to be something I expect to use, but > > I like the idea

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Thanks a lot George for your comments. About this suggestion: On 14:29 27/04, George Michaelson wrote: > It's a debug tool. It isn't going to be something I expect to use, but > I like the idea if something goes awry in the responses I am seeing I > can ask the authority to tell me what SOA serial

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

(speaking as a chair) On Thu, Apr 27, 2023 at 5:22 PM John R Levine wrote: > On Thu, 27 Apr 2023, Miek Gieben wrote: > >> I think it's an interesting idea but I also don't want to spend time on > it > >> if it's just going to be filed and forgotten. > > > > I looked into this for https://github

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

On Thu, 27 Apr 2023, Miek Gieben wrote: I think it's an interesting idea but I also don't want to spend time on it if it's just going to be filed and forgotten. I looked into this for https://github.com/miekg/dns The option is trivial to implemented (in an auth server). I.e. seems similar to

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

[ Quoting in "Re: [DNSOP] WGLC for draft-ietf-dns..." ] It appears that Suzanne Woolf said: Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed th

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

It appears that Suzanne Woolf said: >Colleagues, > > >This email begins a Working Group Last Call for >draft-ietf-dnsop-zoneversion-02 >(https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > >If you've reviewed this document and think it's ready for publication, please >let us and

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf <[swo...@pir.org](mailto:On Wed, Apr 26, 2023 at 23:07, Suzanne Woolf < wrote: > This email begins a Working Group Last Call for > draft-ietf-dnsop-zoneversion-02 > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). > > If you've revie

Re: [DNSOP] WGLC for draft-ietf-dnsop-zoneversion

I've read this draft. I think its a simple and straightforward proposal. It explicitly notes the security issue that its not covered by DNSSEC, it has implementations, and it had a good discussion run 2021/2022 which was overwhelmingly positive. I had no problems understanding the intent. its rea

[DNSOP] WGLC for draft-ietf-dnsop-zoneversion

Colleagues, This email begins a Working Group Last Call for draft-ietf-dnsop-zoneversion-02 (https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/). If you've reviewed this document and think it's ready for publication, please let us and the WG know, by responding on-list to this mess

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

Dear colleagues, After some discussion, the chairs have found we have rough consensus to advance draft-ietf-dnsop-alt-tld. The authors have been considering the WGLC comments and will post a new draft shortly. As we’ve mentioned before, the responsible AD for this draft will be Rob Wilton, as

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

Chairs, Can we get some follow-up on this? Thanks, Eliot On 13.01.23 16:56, Suzanne Woolf wrote: Colleagues, This WGLC is closed,  with many thanks to everyone who commented. The chairs and editors are reviewing the comments and will summarize in the next few days. Suzanne, for the chai

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

Colleagues, This WGLC is closed, with many thanks to everyone who commented. The chairs and editors are reviewing the comments and will summarize in the next few days. Suzanne, for the chairs From: Suzanne Woolf Date: Tuesday, December 13, 2022 at 3:26 PM To: "dnsop@ietf.org" Cc: "dnsop-ch

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

alf of Suzanne Woolf < > swo...@pir.org> > *Date: *Tuesday, December 13, 2022 at 12:26 PM > *To: *"dnsop@ietf.org" > *Cc: *"dnsop-cha...@ietf.org" , "Rob Wilton > (rwilton)" > *Subject: *[EXTERNAL] [DNSOP] WGLC for draft-ietf-dnsop-alt-t

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

> On Dec 13, 2022, at 18:50, Wessels, Duane > wrote: > >  > I > I still think the requirements for library (stub) and caching resolver > behavior should be stronger. i.e. MUST NOT put .alt queries on the wire. > But this is probably a minority opinion. Earlier I had said “should use qu

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

. RFC 8198 says SHOULD, not MUST. Not to mention cache misses. DW From: DNSOP on behalf of Suzanne Woolf Date: Tuesday, December 13, 2022 at 12:26 PM To: "dnsop@ietf.org" Cc: "dnsop-cha...@ietf.org" , "Rob Wilton (rwilton)" Subject: [EXTERNAL] [DNSOP] WGL

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

Dear DNSOP, I support advancing the document in its current form. There's a broken sentence in Section 5: "Care must be taken to ensure that the mapping of thepseudo-TLD into its corresponding non-DNS name resolution system inorder to get whatever security is offered by that system." --> the

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

Hiya, This is good enough, so should proceed. In terms of substantive comments, I can only think of arguments that have already been thrashed out so won't raise any of 'em. A suggestion/nit which I'm fine to see ignored: the text in section 4 (Privacy Considerations) isn't that clear and might

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

Dear colleagues, This message will serve to start a Working Group Last Call on “The ALT Special Use Top Level Domain” (https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/). Due to the end-of-year holidays, we’re starting it now and will give it four weeks. As you’ve seen from Paul Hof

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Abley-san, thanks very much for your comments. > From: Joe Abley > Fujiwara-san, > > On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote: > >> Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and >> they often don't work as expected. >> >> However, it may be easy to avoid usin

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Thu, Sep 22, 2022 at 2:05 AM Kazunori Fujiwara wrote: > > From: Petr Špaček > >> Then, do you agree the following requirements ? (as DNS software > >> developpers) > >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4, > >> and SHOULD not use FRAGMENT header on IPv6. > > > > Theoretic

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Fujiwara-san, On Sep 22, 2022, at 11:05, Kazunori Fujiwara wrote: > Thanks. "Path MTU Disovery" API and setting IP_DF API are complex and > they often don't work as expected. > > However, it may be easy to avoid using the Fragment Header on IPv6. > (limit IPv6 response packet smaller than inter

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

> From: Petr Špaček >> Then, do you agree the following requirements ? (as DNS software >> developpers) >> 1. SHOULD set DF bit on outgoing UDP packets on IPv4, >> and SHOULD not use FRAGMENT header on IPv6. > > Theoretically yes, but it might not be achievable depending on OS > API. We tried

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 14. 09. 22 16:56, Kazunori Fujiwara wrote: From: Petr Špaček On 15. 08. 22 12:18, Kazunori Fujiwara wrote: I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. * UDP requestors MAY probe t

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

1232 is an arbitrary sized based on a multi generational misunderstanding. We should not repeat it or promote it. p vixie On Sep 14, 2022 15:56, Kazunori Fujiwara wrote: > From: Petr Špaček > On 15. 08. 22 12:18, Kazunori Fujiwara wrote: >> >>> I assume section 3.2 means the EDNS bufs

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

> From: Petr Špaček > On 15. 08. 22 12:18, Kazunori Fujiwara wrote: >> >>> I assume section 3.2 means the EDNS bufsize in the request when it >>> says >>> "their payload size", but I am not sure. The text could be clearer on >>> that. >>> * UDP requestors MAY probe to discover the real M

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 15. 08. 22 12:18, Kazunori Fujiwara wrote: I assume section 3.2 means the EDNS bufsize in the request when it says "their payload size", but I am not sure. The text could be clearer on that. * UDP requestors MAY probe to discover the real MTU value per destination. How? For exa

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 17. 08. 22 17:09, Daisuke HIGASHI wrote: Peter van Dijk >: Thank you for reviewing my implementation. Note that the function called "probe_pmtu" does not really probe. At best, it finds some data the kernel cached recently. At worst (i.e. usua

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Peter van Dijk : > Thank you for reviewing my implementation. Note that the function called "probe_pmtu" does not really probe. At > best, it finds some data the kernel cached recently. At worst (i.e. > usually), it tells you the MTU of your local networking interface. That's correct. > > > -

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

> From: "Andrew McConachie" >> Path MTU discovery remains widely undeployed due to >>security issues, and IP fragmentation has exposed weaknesses in >>application protocols. > > PMTUD doesn’t work through NAT and that’s probably the main reason > why it doesn’t work on the Internet. I thi

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Sat, 2022-08-13 at 21:49 +0900, Daisuke HIGASHI wrote: > I wrote an experimental "avoid-fragmentation" patch for NSD (as per > section 3.1 and Appexdix C). Due to dependency on getsockopt(IP_MTU), > currently it should work on Linux only. > > https://github.com/hdais/nsd-avoid-fragmentation#avo

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

> From: Peter van Dijk > Avoiding fragmentation is good. Putting that in a document is also good. > But this document is not ready for publication. It also most definitely > does not describe Best Current Practice; it also does not prescribe a > Best Current Practice I can agree with or even reall

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

I wrote an experimental "avoid-fragmentation" patch for NSD (as per section 3.1 and Appexdix C). Due to dependency on getsockopt(IP_MTU), currently it should work on Linux only. https://github.com/hdais/nsd-avoid-fragmentation#avoid-fragmentation-implementation-for-nsd https://github.com/hdais/nsd

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Brian Dickson wrote on 2022-07-31 13:46 On Sun, Jul 31, 2022 at 11:54 AM Paul Vixie wrote: https://datatracker.ietf.org/wg/plpmtud/about/ (I would note that the above wg is "status: closed".) don't we all just love it when something reaches successful conclusion? i suggest furthe

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

see inline. Andrew McConachie wrote on 2022-08-04 06:32: On 31 Jul 2022, at 20:53, Paul Vixie wrote: https://datatracker.ietf.org/wg/plpmtud/about/ i suggest further reading and perhaps reconsideration. we've got to break out of the MTU 1500 jail some day or the internet will end in head

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Thu, Aug 04, 2022 at 03:49:48PM +0200, Joe Abley wrote: > Hi Andrew, > > On Aug 4, 2022, at 15:33, Andrew McConachie wrote: > > > I apologize for derailing this conversation by bringing up NAT. My point > > was that the document makes a claim that PMTUD ‘remains widely undeployed > > due to

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Hi Andrew, On Aug 4, 2022, at 15:33, Andrew McConachie wrote: > I apologize for derailing this conversation by bringing up NAT. My point was > that the document makes a claim that PMTUD ‘remains widely undeployed due to > security issues’. Yet it makes no reference to anything that might back

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 31 Jul 2022, at 20:53, Paul Vixie wrote: Andrew McConachie wrote on 2022-07-28 03:24: Path MTU discovery remains widely undeployed due to    security issues, and IP fragmentation has exposed weaknesses in    application protocols. PMTUD doesn’t work through NAT and that’s probably the ma

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Sun, Jul 31, 2022 at 11:54 AM Paul Vixie wrote: > > > Andrew McConachie wrote on 2022-07-28 03:24: > >> Path MTU discovery remains widely undeployed due to > >>security issues, and IP fragmentation has exposed weaknesses in > >>application protocols. > > > > PMTUD doesn’t work through

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Andrew McConachie wrote on 2022-07-28 03:24: Path MTU discovery remains widely undeployed due to    security issues, and IP fragmentation has exposed weaknesses in    application protocols. PMTUD doesn’t work through NAT and that’s probably the main reason why it doesn’t work on the Internet

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Hello, On Tue, 2022-07-26 at 21:13 +, Suzanne Woolf wrote: > Dear colleagues, > > > This message starts the Working Group Last Call for > draft-ietf-dnsop-avoid-fragmentation > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The > requested status is BCP. > > Si

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Hi Andrew, On Jul 29, 2022, at 11:14, Andrew McConachie wrote: > We don’t need a useful standard for NAT to recognize that most > implementations break PMTUD, and that those implementations of NAT are > deployed enough to make PMTUD significantly broken. I was really just suggesting that some

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 28 Jul 2022, at 13:19, Joe Abley wrote: On Jul 28, 2022, at 12:24, Andrew McConachie wrote: PMTUD doesn’t work through NAT That's a very definitive statement considering that there's no useful standard for NAT. If there's actual research on this to demonstrate that, pragmatically s

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On 26. 07. 22 23:13, Suzanne Woolf wrote: Dear colleagues, This message starts the Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The requested status is BCP. Since we're starting the Last Call durin

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

On Jul 28, 2022, at 12:24, Andrew McConachie wrote: > PMTUD doesn’t work through NAT That's a very definitive statement considering that there's no useful standard for NAT. If there's actual research on this to demonstrate that, pragmatically speaking, no implementations use the payload of a

Re: [DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Path MTU discovery remains widely undeployed due to security issues, and IP fragmentation has exposed weaknesses in application protocols. PMTUD doesn’t work through NAT and that’s probably the main reason why it doesn’t work on the Internet. I think that’s less of a security issue than

[DNSOP] WGLC for draft-ietf-dnsop-avoid-fragmentation

Dear colleagues, This message starts the Working Group Last Call for draft-ietf-dnsop-avoid-fragmentation (https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). The requested status is BCP. Since we're starting the Last Call during the IETF week, and many folks are on holi

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

Hi, The WGLC resulted in some good discussion of (mostly) small improvements to the text, which the authors are responding to. The chairs will be discussing advancement of this document in our next meeting. Thanks to everyone who commented. Suzanne for the chairs > On Apr 18, 2021, at 7:17

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

John Kristoff wrote: > > However, I think we'd be reluctant to say much about minimal-answers > here in a context that suggests it is some sort of DDoS mitigation > mechanism and that you need it because... "TCP". Maybe there is some > adjustments to the text somewhere that can help highlight tha

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

On Thu, 22 Apr 2021 20:23:19 +0100 Tony Finch wrote: > I needed minimal-any when my auth servers were being hammered by lots of > recursive servers making ANY requests; the responses were being truncated > because my servers have for a long time been configured to avoid > fragmentation, and the r

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, I do have some comments. I scanned the Last Call

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

> On Apr 22, 2021, at 11:50 AM, Donald Eastlake wrote: > > > 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 ot

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

Wessels, Duane wrote: > Thanks for looking through my suggestions! All the changes look good. A few follow-up points: > Oops, correcting myself here. It needs to be RFC 2541 because that is the > one that mentions TCP. Aha, that makes sense > > 2.4: > > > > Last 2 paragraph s re. avoiding fra

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 wi

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

> On Apr 21, 2021, at 4:39 PM, Wessels, Duane > wrote: > >> 2.2: >> >> DNSSEC originally specified in [RFC2541] >> >> I thought this should be RFC 2535 rather than the operational guidelines? > > Sure, 2535 works for me. > Oops, correcting myself here. It needs to be RFC 2541 because th

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

On Wed, 2021-04-21 at 23:47 +, Wessels, Duane wrote: > > application. Applications must be coded and configured to make use > > of this filter. > > > > While it's good to point out that this feature exists, I do not think > > mandating it makes sense - implementers and operators might hav

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

> On Apr 19, 2021, at 9:34 AM, Peter van Dijk > wrote: > >> This message starts the Working Group Last Call for >> draft-ietf-dnsop-tcp-requirements >> (https://secure-web.cisco.com/1GUztR-Nd5B-MpjncjmDNOnqlKoeK5-09UeTvbL1dFyQqc0x3GpwWIzNUMvS9B4MsWztiWQY9T4fEg5m6LLL1pIw6mIP3Glh5Dv0eS5QuBH0_E

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

> On Apr 19, 2021, at 8:45 AM, Tony Finch wrote: > > Suzanne Woolf wrote: >> >> This message starts the Working Group Last Call for >> draft-ietf-dnsop-tcp-requirements > > I have read the draft and I am keen to see it published. Just the other > day I was having a discussion about whether T

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

> On Apr 19, 2021, at 4:31 AM, Joe Abley wrote: > > > Hi Suz, > > On 18 Apr 2021, at 19:17, Suzanne Woolf wrote: > >> This message starts the Working Group Last Call for >> draft-ietf-dnsop-tcp-requirements >> (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/) > >

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

(no hats on) I've read this, and I agree it should move forward. Should there be a reference to RFC8499 in here as well? (with chairs hat on) Mr Finch made some editorial nits that I concur with. I also ran the Nits tool and found several outdated references, among other things. I've requested

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

On Sun, Apr 18, 2021 at 4:17 PM Suzanne Woolf wrote: > Dear colleagues, > > > This message starts the Working Group Last Call > for draft-ietf-dnsop-tcp-requirements ( > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/) > > Since this draft has not been recently discussed i

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

On 19 Apr 2021, at 12:40, Peter van Dijk wrote: > This note on statelessness is good, but I don't think it should be tied to > IPv6. Packets get lost in IPv4 too, especially when they are big, and even if > such evens trigger a report in the form of an ICMP message, the same > lack-of-state pr

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

On Mon, 2021-04-19 at 07:31 -0400, Joe Abley wrote: > NEW: > >For IPv4-connected hosts, the MTU is often the Ethernet payload >size of 1500 bytes. This means that the largest unfragmented >UDP DNS message that can be sent over IPv4 is likely 1472 bytes, >although tunnel encapsulat

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

> This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/) This is a good document. One comment here: The FreeBSD, OpenBSD, and NetBSD operating systems have an "accept filter" fe

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

Suzanne Woolf wrote: > > This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements I have read the draft and I am keen to see it published. Just the other day I was having a discussion about whether TCP support is really needed, and I wanted something stronger than R

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

On 18 Apr 2021, at 19:17, Suzanne Woolf wrote: > We’d like to advance this but it needs some active support, so we need to > hear from folks who have found it useful, especially implementers. I didn't mention explicitly before, sorry, but I think this is a good document, it's useful and it sho

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

Hi John, On 19 Apr 2021, at 07:57, John Kristoff wrote: > On Mon, 19 Apr 2021 07:31:49 -0400 > Joe Abley wrote: > >> NEW: >> >> The specification of the DNS allows both UDP and TCP to be used >> as transport protocols for exchanging unencrypted DNS messages. >> However, for various rea

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

On Mon, 19 Apr 2021 07:31:49 -0400 Joe Abley wrote: > NEW: > >The specification of the DNS allows both UDP and TCP to be used >as transport protocols for exchanging unencrypted DNS messages. >However, for various reasons, the availability of TCP transport >has sometimes been int

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

Hi Suz, On 18 Apr 2021, at 19:17, Suzanne Woolf wrote: > This message starts the Working Group Last Call for > draft-ietf-dnsop-tcp-requirements > (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ >

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

It's time to ship. I mean sure, if somebody who does detailed reading has a killer problem I can see we'd talk it out but we're 7 revisions in, its 4 years later, and it seems rational to document the expectation this is modern DNS, and we do TCP as a MUST SUPPORT, Auth and recursive. Its overdue.

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

Dear colleagues, This message starts the Working Group Last Call for draft-ietf-dnsop-tcp-requirements (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ ) Since this draft has not been recently dis

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

Hi, I was reminded off-list that Warren is not in fact an author on this document— apologies for a bad cut-and-paste from the last WGLC I ran. Warren is handling tcp-requirements as our AD, as usual. Best, Suzanne (My mistake alone, co-chairs are blame-free!) > On Jan 12, 2020, at 12:38 PM, S

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

Dear colleagues, This message starts the Working Group Last Call for draft-ietf-dnsop-tcp-requirements (https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ ) Since this draft has not been recently dis

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Mon, Feb 19, 2018 at 10:00:39AM -0500, Suzanne Woolf wrote a message of 17 lines which said: > We’ve let the discussion continue because it’s been so active, but > we also haven’t forgotten we need to review and determine next steps > on this draft. I don't find anything about the decision

[DNSOP] WGLC for draft-ietf-dnsop-serve-stale

Dear colleagues, This message starts the Working Group Last Call for draft-ietf-dnsop-serve-stale (https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/). Since this draft has not been recently discussed in the WG, we figure people might need to swap it back in, and we will be meetin

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Hi all, We’ve let the discussion continue because it’s been so active, but we also haven’t forgotten we need to review and determine next steps on this draft. Thanks for the lively discussion, and we’ll have followup shortly. Suzanne & Tim > On Jan 22, 2018, at 11:18 AM, Suzanne Woolf wrote:

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Andrew Sullivan wrote: > > …of the "admonition" (or whatever you want to call it). In effect, > the document requires special-casing of "localhost" as a label in > every searchlist context. The way nss-style resolvers work is to do exact match on /etc/hosts (which with the default contents sinks

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On 2018-02-10 23:36, Viktor Dukhovni wrote: On Sat, Feb 10, 2018 at 08:21:14PM +, Warren Kumari wrote: Interestingly enough, Steve Sheng and I wrote just such a document a number of years ago (around the time of the initial name-collisions drama). Even though I'm 95% sure it included the

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Hi, First, let me be clear that I am (personally) not now, nor have I ever been, a member of the resolver implementation party; so my opinion is biased about what is obvious. If various resolver-writers were to chime in to say that what is obvious to you is obvious to them too (and I don't think

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Sat, Feb 10, 2018 at 08:21:14PM +, Warren Kumari wrote: > > Interestingly enough, Steve Sheng and I wrote just such a document a > number of years ago (around the time of the initial name-collisions > drama). Even though I'm 95% sure it included the phrase "tilting at > windmills" my searc

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Sat, Feb 10, 2018 at 9:21 PM, Joe Abley wrote: > Hi Warren, > > I think the advice is good, but I wonder what the practical effect of writing > it down would be. I doubt it would change any of the entrenched habits in > enterprise systems and networking in our remaining lifetimes, for examp

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 10, 2018, at 16:27, Ted Lemon wrote: > Well, for example, when the DHC working group was considering the search list > option for DHCPv6, I argued that there should be no such option because > search lists are bad. My argument was rejected. Had the IETF officially > deprecated searc

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Well, for example, when the DHC working group was considering the search list option for DHCPv6, I argued that there should be no such option because search lists are bad. My argument was rejected. Had the IETF officially deprecated searchlists prior to that, there would be no DHCPv6 search opt

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Hi Warren, I think the advice is good, but I wonder what the practical effect of writing it down would be. I doubt it would change any of the entrenched habits in enterprise systems and networking in our remaining lifetimes, for example, but perhaps I'm just being overly grumpy and am ignorant

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 10, 2018, at 3:21 PM, Warren Kumari wrote: > There are many things which would be safer, less complex, and safer if > search lists didn't exist -- would people be interested in discussing > the idea, or is it just too out there? I think there's not much to discuss. Whenever it comes up,

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Fri, Feb 9, 2018 at 10:55 PM, Andrew Sullivan wrote: > Hi, > > On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote: >> That's pretty clear. This document is not forbidding the appearance of >> such names in the DNS, nor the resolution of such names. >> > > Instead, it is wanting to ha

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 9, 2018, at 5:55 PM, Andrew Sullivan wrote: > > Hi, > > On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote: >> That's pretty clear. This document is not forbidding the appearance of >> such names in the DNS, nor the resolution of such names. >> > > Instead, it is wanting to ha

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Hi, On Tue, Feb 06, 2018 at 12:50:18AM -0500, Ted Lemon wrote: > That's pretty clear. This document is not forbidding the appearance of such > names in the DNS, nor the resolution of such names. > Instead, it is wanting to have its cake and eat it too. Because… > >Note, however, that t

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 6, 2018, at 12:39 AM, Lanlan Pan wrote: > I mean that in 5.2.  'localhost' labels in subdomains > , > localhost.example.com . => localhost. ( > equal to ban it at dns ? ) The te

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Ted Lemon 于2018年2月6日周二 下午1:17写道： > On Feb 5, 2018, at 11:58 PM, Lanlan Pan wrote: > > If we decide to ban localhost.example, > > > Nobody is proposing that we ban localhost.example. > Sorry for my poor english. I mean that in *5.2. 'localhost' labels in subdomains*

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 5, 2018, at 11:58 PM, Lanlan Pan wrote: > If we decide to ban localhost.example, Nobody is proposing that we ban localhost.example. > 1) how many security accidents have caused by this "localhost.example", is it > a serious security problem with low attack cost ? Every security exposu

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Ted Lemon 于2018年2月6日周二 上午12:52写道： > On Feb 5, 2018, at 1:51 AM, Mark Andrews wrote: > > No it is not! The browser knows where the name came from. > > > Walk me through it. How does the browser know where the name came from? > we can return NXDOMAIN for localhost. , little influence. If we dec

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 5, 2018, at 3:28 AM, Matthew Kerwin wrote: > > It can be handy, though. "http://dev01/ " or "http://dev02/ > " is much easier to type. "password123" is easier to type (and remember!) than "rtuzb2tZ6xbsg", too. :) The way to make things easier is to design

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On Feb 5, 2018, at 1:51 AM, Mark Andrews wrote: > No it is not! The browser knows where the name came from. Walk me through it. How does the browser know where the name came from? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/lis

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

On 5 Feb. 2018 16:52, "Mark Andrews" wrote: > On 5 Feb 2018, at 5:10 pm, Ted Lemon wrote: > > On Feb 5, 2018, at 12:18 AM, Mark Andrews wrote: >> The original problem is that HTTP doesn’t specify that names learn across the >> wire, including from on disk html files, need to be treated as abso

Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

> On 5 Feb 2018, at 5:10 pm, Ted Lemon wrote: > > On Feb 5, 2018, at 12:18 AM, Mark Andrews wrote: >> The original problem is that HTTP doesn’t specify that names learn across the >> wire, including from on disk html files, need to be treated as absolute >> names. >> This is HTTP’s mess due to

  1   2   3   >