Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

On Sun, 19 Nov 2017, JW wrote: Hello, This draft was released a couple weeks ago and includes what we feel are some very noteworthy changes. Please take another look when you have time, as always we look forward to and welcome any questions/ comments. I am disappointed I was unable to join the

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

Paul Vixie wrote: > Ray Bellis wrote: > > > > Won't that cause the resolver to cycle through every root server letter > > hoping for one that doesn't give that answer? > > yes. that's what REFUSED is taken to mean, and also, why we never use it for > data-dependent conditions. only the initiator's

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

On 01/02/2018 14:41, Tony Finch wrote: > That's not entirely true - if you are asking an authoritative-only server > then you get REFUSED or not depending on whether the QNAME is in an > authoritative zone. Right, but the resolver behaviour is to assume that that server is a lame delegation, an

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

On Wed, Jan 31, 2018 at 10:04:03AM +, Ray Bellis wrote: > > Won't that cause the resolver to cycle through every root server letter > hoping for one that doesn't give that answer? It might, yes. But that's a poor reason to give an authoritative answer that a name which does exist instead doe

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

Tony Finch wrote: Paul Vixie wrote: Ray Bellis wrote: Won't that cause the resolver to cycle through every root server letter hoping for one that doesn't give that answer? yes. that's what REFUSED is taken to mean, and also, why we never use it for data-dependent conditions. only the initia

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

On Wed, Jan 31, 2018 at 04:15:07PM +, Viktor Dukhovni wrote: > return NXDomain is likely the best option for now. The other > alternative is to actually serve the expected data: > > localhost. IN A 127.0.0.1 > localhost. IN ::1 > > but I don't think that'd be better. It has the

[DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-11.txt

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 : Security Considerations for RFC5011 Publishers Authors : Wes Hardaker

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

On Thu, Feb 01, 2018 at 09:11:37AM -0800, Paul Vixie wrote: > > That's not entirely true - if you are asking an authoritative-only server > > then you get REFUSED or not depending on whether the QNAME is in an > > authoritative zone. > > that's what this group has reached consensus on in recent m

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

Andrew Sullivan wrote: On Wed, Jan 31, 2018 at 04:15:07PM +, Viktor Dukhovni wrote: return NXDomain is likely the best option for now. The other alternative is to actually serve the expected data: localhost. IN A 127.0.0.1 localhost. IN ::1 but I don't think that'd be bet

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

On Feb 1, 2018, at 11:26 AM, Andrew Sullivan wrote: > It has the notable advantage that it's what the RFC says to do. As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem. So a statement in the form you

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

Paul Vixie wrote: > Tony Finch wrote: > > > > if you are asking an authoritative-only server then you get REFUSED or > > not depending on whether the QNAME is in an authoritative zone. > > that's what this group has reached consensus on in recent months, yes. to me > that's a servfail condition, b

Re: [DNSOP] I-D Action: draft-woodworth-bulk-rr-07.txt

> -Original Message- > From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Mikael Abrahamsson > > Hi, I am brought here because of the notification of this in v6ops. > > I am supportive of the general idea of having these kinds of bulk records > standardized. > Hi Mikael, Thank you f

[DNSOP] 5011-security-considerations status

Sorry for the long delay to get this version out (vacation, family issues, deadlines are all just excuses). The -11 version of the document has a redesigned 6.1.6 that I'd love everyone to concentrate on. Hopefully it more clearly articulates the issues surrounding Mike's found need to wait yet

[DNSOP] Working Group Last Call - draft-ietf-dnsop-session-signal

This starts a Working Group Last Call for draft-ietf-dnsop-session-signal Current versions of the draft is available here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-session-signal/ Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for

Re: [DNSOP] 5011-security-considerations status

*pounds head on table*  I'm really not sure how things get worse each time but they appear to. Please, please get rid of activeRefreshOffset, clockskewDriftMargin and retryDriftMargin.    Replace this with a single paragraph noting that the maximum time (assuming no retransmissions) a node has

Re: [DNSOP] A conversational description of sentinel.

> On 26 Jan 2018, at 3:17 am, Paul Hoffman wrote: > > On 25 Jan 2018, at 7:36, Warren Kumari wrote: > >> On Thu, Jan 25, 2018 at 10:10 AM, Tony Finch wrote: >>> Isn't this going to cause problems with software that checks hostname >>> syntax? > > Yes. However, that software will only be on t

Re: [DNSOP] 5011-security-considerations status

Michael StJohns writes: > Please, please get rid of activeRefreshOffset, clockskewDriftMargin > and retryDriftMargin.    Replace this with a single paragraph noting > that the maximum time (assuming no retransmissions) a node has to wait > after its holdDownTime expires is activeRefresh.  (e.g. t

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

On Thu, Feb 01, 2018 at 11:45:26AM -0600, Ted Lemon wrote: > > As a general principle, when what the RFC says to do is not the right thing > to do, the solution is to update the RFC, not to ignore the problem. I strongly agree with this (as I think or anyway hope you know), and if my response se

Re: [DNSOP] A conversational description of sentinel.

On Fri, Feb 02, 2018 at 07:20:45AM +1100, Geoff Huston wrote: > What about if the sentinel spec proposes to use a left-most label of the > form(s): > > xm—-is-ta-[key] > > and > >xm—-not-ta-[key] > > > would this form of hostname be a reasonable way forward? Only if you want to creat

Re: [DNSOP] A conversational description of sentinel.

On 1 Feb 2018, at 12:20, Geoff Huston wrote: What about if the sentinel spec proposes to use a left-most label of the form(s): xm—-is-ta-[key] and xm—-not-ta-[key] would this form of hostname be a reasonable way forward? This was discussed in a different thread in the WG a few day

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

To be clear, I agree that it's a small point, and I was mostly interested for other reasons having to do with another draft (the one I mentioned). I didn't think this was a blocking question. On Wed, Jan 31, 2018 at 09:44:10AM +1000, George Michaelson wrote: > I think we're rat holing. […] > On

[DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)

Hi, Please note that this is not about the document that started this thread. It's a rathole, but in a different field. On Tue, Jan 30, 2018 at 04:58:01PM -0800, Paul Hoffman wrote: > Please, no. As the originator of the original > hack, I think this is the wrong thing to do > for many reason

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

On Feb 1, 2018, at 2:48 PM, Andrew Sullivan wrote: >> As a general principle, when what the RFC says to do is not the right thing >> to do, the solution is to update the RFC, not to ignore the problem. > > I strongly agree with this (as I think or anyway hope you know) Yes, I will admit I was a

Re: [DNSOP] the ??-- thing (was Re: I-D Action: draft-huston-kskroll-sentinel-04.txt)

On 1 Feb 2018, at 13:20, Andrew Sullivan wrote: It seems plain therefore that a registry of in-band in-label prefixes ought to be created, so that instead of heuristics in IDNA2008 we could tell people to use a real rule. Before I go to the bother of writing this up, are there at least five peo

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

Hi, On Thu, Feb 01, 2018 at 03:26:40PM -0600, Ted Lemon wrote: > > As for why I responded to this and not to the formal review, the answer is > that the formal review was a bit overwhelming. You made a lot of assertions > of fact that didn't sound like fact to me—they sounded like strongly-hel

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

Andrew Sullivan writes: > But of course, there _is_ a name "localhost" in the DNS. > It's already defined, in the RFCs, to this effect. You can probably have your cake and eat it too by saying "sure, hypothetically it exists in the DNS because it's magically reserved in an RFC; but there is no d

[DNSOP] Announcing draft plan for continuing with the root KSK roll and public comment period

(Apologies if you see this message more than once. Warren thought it should be posted here, too.) Folks, Please permit me to point you to a posting on the icann.org blog about the root KSK roll that just went live: https://www.icann.org/news/blog/announcing-draft-plan-for-c

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

> On 2 Feb 2018, at 8:50 am, Wes Hardaker wrote: > > Andrew Sullivan writes: > >> But of course, there _is_ a name "localhost" in the DNS. >> It's already defined, in the RFCs, to this effect. > > You can probably have your cake and eat it too by saying "sure, > hypothetically it exists in th

Re: [DNSOP] A conversational description of sentinel.

> On 2 Feb 2018, at 7:56 am, Paul Hoffman wrote: > > On 1 Feb 2018, at 12:20, Geoff Huston wrote: > >> What about if the sentinel spec proposes to use a left-most label of the >> form(s): >> >>xm—-is-ta-[key] >> >> and >> >> xm—-not-ta-[key] >> >> >> would this form of hostname be a

Re: [DNSOP] A conversational description of sentinel.

rather than a conversational description, could someone perhaps produce a flow chart or pascal-style flow diagram of each actor's decision tree? i am lost. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A conversational description of sentinel.

On 1 Feb 2018, at 16:48, Geoff Huston wrote: I’ve reviewed the (lengthening) thread on this draft, but while I saw posted objections to the use of “xm—" as the initial part of the left-most label here, I did not see any concrete alternate proposals. So on the assumption that I must’ve missed t

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

On Feb 1, 2018, at 3:41 PM, Andrew Sullivan wrote: > I think that this is an example of attempting to > do so: to make a name that already appears today in the DNS > (localhost) go away. Okay, but this simply isn't true. I think you actually responded to the dig traces I sent earlier. The ro

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

> On 2 Feb 2018, at 12:27 pm, Ted Lemon wrote: > > On Feb 1, 2018, at 3:41 PM, Andrew Sullivan wrote: >> I think that this is an example of attempting to >> do so: to make a name that already appears today in the DNS >> (localhost) go away. > > Okay, but this simply isn't true. I think you a

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

Ted Lemon wrote: On Feb 1, 2018, at 3:41 PM, Andrew Sullivan mailto:a...@anvilwalrusden.com>> wrote: I think that this is an example of attempting to do so: to make a name that already appears today in the DNS (localhost) go away. Okay, but this simply isn't true. I think you actually respon

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

> On Feb 1, 2018, at 20:27, Ted Lemon wrote: > >> On Feb 1, 2018, at 3:41 PM, Andrew Sullivan wrote: >> I think that this is an example of attempting to >> do so: to make a name that already appears today in the DNS >> (localhost) go away. > > Okay, but this simply isn't true. I think you act

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

On Feb 1, 2018, at 7:46 PM, Joe Abley wrote: > Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly > ambiguous and think about whether we mean the protocol, any particular > implementation, any particular installation or the namespace (and if so, > which one, since the

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

> On Feb 1, 2018, at 21:03, Ted Lemon wrote: > >> On Feb 1, 2018, at 7:46 PM, Joe Abley wrote: >> Can we take a brief pause to acknowledge that "the DNS" as a phrase is >> highly ambiguous and think about whether we mean the protocol, any >> particular implementation, any particular installati

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

On Feb 1, 2018, at 8:57 PM, Joe Abley wrote: > Which distinction? I think I listed at least four degrees of freedom. Good point. Possibly that is where the disconnect is. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dns

Re: [DNSOP] A conversational description of sentinel.

Paul Hoffman: My preference is #1 because, in general, a label starting with _ has been meant for infrastructure, and that's what these labels are. Others might like #2 so they don't have to add configuration to BIND (and maybe other authoritative servers). just checked, my NSD and POWER

Re: [DNSOP] A conversational description of sentinel.

On 2.2.2018 07:55, A. Schulze wrote> Paul Hoffman: >> My preference is #1 because, in general, a label starting with _ has >> been meant for infrastructure, and that's what these labels are. >> Others might like #2 so they don't have to add configuration to BIND >> (and maybe other authoritative se