Re: [DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07

Hi, Speaking only for myself and not the other editors: On Tue, Nov 14, 2017 at 03:09:39PM +0800, Mukund Sivaraman wrote: > The terminology document seems to contain both easy and > hard-to-come-by definitions. Without knowing what to filter, I keep > getting a large vocabulary of DNS phrases to

Re: [DNSOP] About draft-ietf-dnsop-extended-error

Viktor, Viktor Dukhovni: > On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > >> Tony Finch writes: >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as well as NXDOMAIN... >>> >>> Or, neither of them are errors :-) >> >> We'll remove the restriction in

Re: [DNSOP] About draft-ietf-dnsop-extended-error

On Mon, Nov 13, 2017 at 06:02:11PM -0800, Wes Hardaker wrote: > Tony Finch writes: > > >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as > >> well as NXDOMAIN... > > > > Or, neither of them are errors :-) > > We'll remove the restriction in any wording that says it can onl

[DNSOP] Some comments on draft-ietf-dnsop-terminology-bis-07

I haven't done a full review, but want to. Please answer this first: The terminology document seems to contain both easy and hard-to-come-by definitions. Without knowing what to filter, I keep getting a large vocabulary of DNS phrases to propose but I don't know if they belong in this terminology d

Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan wrote: Hi, On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote: If I ask the authoritative server for example.com about a name label.example.net, in a graph-theoretic sense the NS RRset for the root zone is clearly closer to label.example.net than anything else I can gi

Re: [DNSOP] Clarifying referrals (#35)

Hi, On Mon, Nov 13, 2017 at 08:14:14AM -0800, Paul Vixie wrote: > > If I ask the authoritative server for example.com about a name > > label.example.net, in a graph-theoretic sense the NS RRset for the > > root zone is clearly closer to label.example.net than anything else I > > can give. > > dns

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

Paul Wouters wrote: I'm not sure that the need for robustness outweighs the expectation of someone explicitly adding a trust anchor anymore. But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor. We just ask you not to block us from do

Re: [DNSOP] Clarifying referrals (#35)

Robert Edmonds wrote: Paul Vixie wrote: the implication of REFUSED is that if someone else asked this question, we might be able to answer. so if BIND is doing what you say, it's wrong. In theory, any authoritative nameserver could secretly also be a resolver that will answer from cache if the

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

> On 14 Nov 2017, at 12:48 pm, Joe Abley wrote: > > On Nov 14, 2017, at 09:37, George Michaelson wrote: > >> Stephane, I don't entirely understand your response. old systems can >> never understand new code point assignments, or know what to do with >> it, no proposed change can alter this. Mi

[DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.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 : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston

[DNSOP] I-D Action: draft-huston-kskroll-sentinel-03.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 : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

> > I'm not sure that the need for robustness outweighs the expectation of > someone explicitly adding a trust anchor anymore. But that’s not your call to make, but the call of the entity deciding to put in that hard coded trust anchor. We just ask you not to block us from doing as we have b

Re: [DNSOP] About draft-ietf-dnsop-extended-error

Tony Finch writes: > Stephane Bortzmeyer wrote: >> >> > It can be included in any error response (SERVFAIL, NXDOMAIN, >> > REFUSED, etc) >> >> It can be argued that NODATA (pseudo rcode, I know) is an "error" as >> well as NXDOMAIN... > > Or, neither of them are errors :-) We'll remove the rest

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

On Tue, Nov 14, 2017 at 09:48:28AM +0800, Joe Abley wrote a message of 24 lines which said: > The implication is, I think, that some new code points are more > likely to survive the attention of Sauron's Middleware than others. ... > it seems intuitively true that the impact of each is probabl

[DNSOP] another draft (was Re: Clarifying referrals (#35) )

On Mon, Nov 13, 2017 at 08:52:35AM -0600, John Kristoff wrote: > On Mon, 13 Nov 2017 03:26:41 + > Andrew Sullivan wrote: > > > This is quite a helpful response, thanks. I wonder whether more of it > > ought to go in discussion (or a new draft), > > I'd suggest a new draft be produced with w

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

On Nov 14, 2017, at 09:37, George Michaelson wrote: > Stephane, I don't entirely understand your response. old systems can > never understand new code point assignments, or know what to do with > it, no proposed change can alter this. Middleboxes dropping unexpected > things will hit almost any p

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Stephane, I don't entirely understand your response. old systems can never understand new code point assignments, or know what to do with it, no proposed change can alter this. Middleboxes dropping unexpected things will hit almost any proposed modification of packets in flight. Basically, I don't

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

On Mon, Nov 13, 2017 at 08:54:16PM +0800, Ray Bellis wrote a message of 29 lines which said: > Would it be feasible to reserve a standard RCODE value in the header > that just means "see extended error"? First reaction: no. Middleboxes would block these responses, or old clients would not kno

Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

On Tue, Nov 14, 2017 at 09:16:43AM +1100, Mark Andrews wrote: > Remember the draft was designed to handle ALL record updates to the > parent zone after being approved by the registrar in a unified manner. > NS, DS, A, DNAME, , TXT, CNAME, etc. This isn’t restricted to DS > records. In the pr

Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

> On 14 Nov 2017, at 5:45 am, Edward Lewis wrote: > > On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" behalf of e...@isc.org> wrote: > >> Mark's idea to push updates to the parent instead of relying on polling used >> a SRV query to identify the correct recipient of an UPDATE: >> >> ...

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

> On 14 Nov 2017, at 8:19 am, Joe Abley wrote: > > Hi Geoff, > > I think the number 4 on the slide was different from the one in the mail. I thought so too, but I wasn’t sure if it was me not paying attention in the WG meeting or not! > > The option on the slide that I mentioned I liked th

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Hi Geoff, I think the number 4 on the slide was different from the one in the mail. The option on the slide that I mentioned I liked the most was the one that didn't copy the RCODE value from the header, but in effect provided a 16/32/whatever-bit sub-code for whatever the RCODE happened to be.

Re: [DNSOP] Clarifying referrals (#35)

On Mon, Nov 13, 2017 at 11:12:52AM -0800, Matthew Pounsett wrote: > I haven't got the time this morning to search release notes, but I'm fairly > sure that in 2012, when you wrote that article, current versions of BIND > were already handing out REFUSED to indicate "I'm not authoritative for > that

Re: [DNSOP] Clarifying referrals (#35)

Paul Vixie wrote: > Matthew Pounsett wrote: > > I haven't got the time this morning to search release notes, but I'm > > fairly sure that in 2012, when you wrote that article, current versions > > of BIND were already handing out REFUSED to indicate "I'm not > > authoritative for that." At the ver

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett wrote: ... I have seen no similar discussion of REFUSED-generated chaos in recursive servers. If someone is seeing such brokenness, they haven't brought it to dnsop@, or dns-operations@, or an OARC or NANOG meeting. If someone is seeing such brokenness, hopefully they'll spe

Re: [DNSOP] Clarifying referrals (#35)

On 13 November 2017 at 11:28, Paul Vixie wrote: > > ... If that were a problem, given BIND's market share, we should be >> > seeing widespread brokenness, but I don't think we are–none that's >> making it from my support department to me or to our hostmaster@ >> accounts, at any rate. >> > > yike

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett wrote: On 13 November 2017 at 10:55, Paul Vixie mailto:p...@redbarn.org>> wrote: > why is this nor a broken configuration? It's my understanding that SERVFAIL indicates that the server sending the RCODE–or in the case of a recursive response, the upstream authoritative ser

Re: [DNSOP] Clarifying referrals (#35)

On 13 November 2017 at 10:55, Paul Vixie wrote: > > > Matthew Pounsett wrote: > >> >> >> On 13 November 2017 at 06:52, John Kristoff > > wrote: >> >> REFUSED does not seem ideal to me either, but what if anything might >> be >> better is probably ripe discussion in

Re: [DNSOP] Clarifying referrals (#35)

Matthew Pounsett wrote: On 13 November 2017 at 06:52, John Kristoff mailto:j...@depaul.edu>> wrote: REFUSED does not seem ideal to me either, but what if anything might be better is probably ripe discussion in a new draft. It makes perfect sense to me. REFUSED is an indication that

Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

Evan Hunt wrote: ... Mark's idea to push updates to the parent instead of relying on polling used a SRV query to identify the correct recipient of an UPDATE: https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04 The same trick could be used to find the right NOTIFY target.

Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

On 11/13/17, 13:30, "DNSOP on behalf of Evan Hunt" wrote: >Mark's idea to push updates to the parent instead of relying on polling used a >SRV query to identify the correct recipient of an UPDATE: > >...draft-andrews-dnsop-update-parent-zones-04... This would mean then signing all the SRV

Re: [DNSOP] Clarifying referrals (#35)

On 13 November 2017 at 06:52, John Kristoff wrote: > REFUSED does not seem ideal to me either, but what if anything might be > better is probably ripe discussion in a new draft. > > It makes perfect sense to me. REFUSED is an indication that the querier has been blocked from asking that question

Re: [DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

On Mon, Nov 13, 2017 at 03:19:23PM +, Tony Finch wrote: > It seems to me that a reasonable in-band mechanism would be to send a > NOTIFY to the parental agent. I can only find a little discussion of this > idea in 2014, and it wasn't very enthusiastic - there were questions like, > how do you k

Re: [DNSOP] Clarifying referrals (#35)

John Kristoff wrote: ... Paul, are you willing and able to work on a draft for this? For what it's worth I'd be supportive of that work. my drafting skills seem to be gone. nothing i've written in the last ten years was adopted. i think it would be better for me to review and to provide t

Re: [DNSOP] Clarifying referrals (#35)

Andrew Sullivan wrote: Hi, This is quite a helpful response, thanks. I wonder whether more of it ought to go in discussion (or a new draft), however. i probably should not be involved in a new draft other than as a reviewer. (consider the fate of resimprove.) For I'm struck by this: On

Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" wrote: >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: >> Nice write-up Edward! You have nicely summarized why Mark and me agree >> that validator should use longest suffix match when selecting TA to >> validate data.

Re: [DNSOP] The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state "Candidate for WG Adoption"

On Mon, Nov 13, 2017 at 4:11 AM, IETF Secretariat < ietf-secretariat-re...@ietf.org> wrote: > > The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state > Candidate for WG Adoption (entered by Tim Wicinski) > > The document is available at > https://datatracker.ietf.org/doc/draft-dupont-dnso

[DNSOP] CDS polling, was Re: [Ext] Re: Clarifying referrals (#35)

Edward Lewis wrote: > > The same issue came into play when trying to design the "Automating > DNSSEC Delegation Trust Maintenance" - related to scaling (the parent > has to poll the children, not the other way around). (In "Detecting a > Changed CDS/CDNSKEY", the parent either polls or has to hav

Re: [DNSOP] [Ext] Re: Clarifying referrals (#35)

At the tail of this thread, I'll add my (random) thoughts. 1) Upward referrals are an example of something that started out as a good idea, good intention, but ran into operational problems as the DNS setting changed. Early, in the late 90's, a popular DNS implementation would chase an upward

Re: [DNSOP] Clarifying referrals (#35)

On Mon, 13 Nov 2017 03:26:41 + Andrew Sullivan wrote: > This is quite a helpful response, thanks. I wonder whether more of it > ought to go in discussion (or a new draft), I'd suggest a new draft be produced with which discussion could ensue. The references Paul cites would not be clear to

Re: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption"

At the end of section 4 it says: "or a case of mixed signals (SERVFAIL in all three responses), which is similarly an indeterminate response" But I think that maybe this case tells us that at least one of the resolvers is Vold, and we could count this answer as Vold. Would that work? -

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

On 13/11/2017 21:13, Tony Finch wrote: > Ray Bellis wrote: >> >> Would it be feasible to reserve a standard RCODE value in the >> header that just means "see extended error"? > > That would require client-to-server signalling, It would. Perhaps the *request* RCODE could contain the same valu

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

Ray Bellis wrote: > > Would it be feasible to reserve a standard RCODE value in the header > that just means "see extended error"? That would require client-to-server signalling, and the server would be unable to simply unconditionally include the extended error in the OPT record. > It has alway

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

On 13/11/2017 19:01, Geoff Huston wrote: > errr - what would it mean if the rcode in the error code header differed > from the rcode value in the extended-error component? > > The issue with duplicated information in a packet is that you then have > add even further consideration to cope with t

Re: [DNSOP] About draft-ietf-dnsop-extended-error

Stephane Bortzmeyer wrote: > > > It can be included in any error response (SERVFAIL, NXDOMAIN, > > REFUSED, etc) > > It can be argued that NODATA (pseudo rcode, I know) is an "error" as > well as NXDOMAIN... Or, neither of them are errors :-) Tony. -- f.anthony.n.finchhttp://dotat.at/ - I

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

> On 13 Nov 2017, at 9:43 pm, tjw ietf wrote: > > To follow up from the meeting this morning, it sounded from the room that in > the case of these > four options, #4 was the one which makes the most sense. > > ….. > > 4. 32 bit code field, repeating rcode from elsewhere in the packet

Re: [DNSOP] draft-ietf-dnsop-extended-error code options

To follow up from the meeting this morning, it sounded from the room that in the case of these four options, #4 was the one which makes the most sense. tim On Tue, Oct 17, 2017 at 6:39 AM, Wes Hardaker wrote: > > Folks, > > We were given feedback during the call for adoption to "use numeric >

Re: [DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption"

Dear colleagues, In our meeting earlier today at IETF 100, Geoff presented on this draft. (Slides are at https://datatracker.ietf.org/meeting/100/materials/slides-100-dnsop-sessa-draft-huston-kskroll-sentinel/

[DNSOP] The DNSOP WG has placed draft-huston-kskroll-sentinel in state "Candidate for WG Adoption"

The DNSOP WG has placed draft-huston-kskroll-sentinel in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ ___ DNSOP mailing list DNSOP@ietf.org https:

[DNSOP] The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state "Candidate for WG Adoption"

The DNSOP WG has placed draft-dupont-dnsop-rfc2845bis in state Candidate for WG Adoption (entered by Tim Wicinski) The document is available at https://datatracker.ietf.org/doc/draft-dupont-dnsop-rfc2845bis/ ___ DNSOP mailing list DNSOP@ietf.org https: