[DNSOP] state management related to TTL

tonight's exchanges here related to "use-stale" seem discordant to me. i'd like to play the straight man for a moment and ask some indulgent person to bring me up to speed by way of correcting my impressions. the DNS TTL field is a state management variable. in this case the held state is in

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

On Wed, Nov 15, 2017 at 9:45 AM, Joe Abley wrote: > Hi Bob, > > On Nov 15, 2017, at 00:23, Bob Harold wrote: > > If I have to add those entries to each zone, I worry that the automated DNS > appliance that I use might not be able to create the broken

Re: [DNSOP] 5011-security-considerations and the safetyMargin

Wes Hardaker writes: > After thinking about this for far far too long, I've now switched my own > opinion to that of 2C (errr... that should have been "2B") -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

On November 14, 2017 9:13:29 PM PST, Dave Lawrence wrote: >Paul Vixie writes: >> i'm of the opposite view. we should not change behaviour without >> explicit signaling. if that means it takes 10 years to reach 50% >> penetration, like EDNS did, then that's the cost of doing

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Paul Vixie writes: > i'm of the opposite view. we should not change behaviour without > explicit signaling. if that means it takes 10 years to reach 50% > penetration, like EDNS did, then that's the cost of doing business. Just so I'm clear, am I understanding correctly from this that you

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

On Tue, 14 Nov 2017, Jacques Latour wrote: Personally, I like a mix of #3 and #1, on a regular basis poll the entire zone for changes, and have a mechanism to listen to child notifications for urgent changes. Agreed. _AND_ remember, the preferred method by far is to submit a DS/DNSKEY

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

tale: >> It is significantly less operationally beneficial if it demands EDNS. Paul, and echoed by Paul: > i'm of the opposite view. we should not change behaviour without > explicit signaling. I've opened this as an issue to track toward WG consensus and suspect that, unless strong consensus

[DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-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 : Reverse DNS in IPv6 for Internet Service Providers Author : Lee Howard Filename

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

On Tue, 14 Nov 2017, Paul Vixie wrote: It is significantly less operationally beneficial if it demands EDNS. i'm of the opposite view. we should not change behaviour without explicit signaling. if that means it takes 10 years to reach 50% penetration, like EDNS did, then that's the cost of

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

On Wed, 15 Nov 2017, Frederico A C Neves wrote: Yes. And add to that cases were TLDs rolled just before adding to the root. So what is the security model then? Let's say .example rolled and now has a bad DS. Someone overrides this with a local trust anchor so the domain does not go dark. -

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Dave Lawrence wrote: Alexander Mayrhofer writes: I'm torn on the question whether or not stale data should be served (without signaling, in that case) when the request does *not* contain an OPT request. I'm personally not torn on this; for me the whole point of implementing this

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Ray Bellis wrote: ... I'm not particularly arguing either way on this question of signalling, but do we have any feel for how many stubs ever send EDNS? libresolv can do it, and getdns does, but I don't think glibc's resolver routinely sends EDNS. i would look to opendns or gdns for those

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Alexander Mayrhofer writes: > I'm torn on the question whether or not stale data should be served > (without signaling, in that case) when the request does *not* > contain an OPT request. I'm personally not torn on this; for me the whole point of implementing this functionality is to add

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

> I'm not particularly arguing either way on this question of signalling, > but do we have any feel for how many stubs ever send EDNS? > > libresolv can do it, and getdns does, but I don't think glibc's resolver > routinely sends EDNS. Ray, i do agree - having figures "from the field" about this

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

On 15/11/2017 11:47, Alexander Mayrhofer wrote: > I agree that signaling is important, and i also believe that if > there's an OPT in the request, we can safely assume that the client > would not choke on this option. I'm torn on the question whether or > not stale data should be served (without

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

On Wed, Nov 15, 2017 at 9:57 AM, Dave Lawrence wrote: > I personally am of the belief that yes, if the request has an OPT then > a responder can include an option code that was not in the request. > At least I don't see anything in 6891 to prohibit it. This is > behaviour that

Re: [DNSOP] Clarifying referrals (#35)

Dave Lawrence wrote: Evan Hunt writes: Okay. I haven't encountered a resolver that propgates REFUSED from the authority to the stub. If there is such a beast, then IMHO that, not the authority, is the one that's mis-using REFUSED; REFUSED only makes sense on a hop-by-hop basis. i'll stop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Dave Lawrence wrote: Bob Harold writes: I am a little concerned about yet another option that the client might want to send with every query. Can the existence of *any* EDNS option from the client be taken to mean that EDNS options are understood in general, and the resolver is ok to respond

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

On Mon, Nov 13, 2017 at 03:45:30PM +, Edward Lewis wrote: > On 11/9/17, 12:48, "DNSOP on behalf of Evan Hunt" behalf of e...@isc.org> wrote: > > >On Thu, Nov 09, 2017 at 03:48:26PM +0100, Petr Špaček wrote: > >> Nice write-up Edward! You have nicely

Re: [DNSOP] Clarifying referrals (#35)

Evan Hunt writes: > Okay. I haven't encountered a resolver that propgates REFUSED from the > authority to the stub. If there is such a beast, then IMHO that, not the > authority, is the one that's mis-using REFUSED; REFUSED only makes sense on > a hop-by-hop basis. Very much agree. I'd be

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Bob Harold writes: > I am a little concerned about yet another option that the client > might want to send with every query. Can the existence of *any* > EDNS option from the client be taken to mean that EDNS options are > understood in general, and the resolver is ok to respond with this > ENDS

[DNSOP] 5011-security-considerations and the safetyMargin

The discussion has been long with respect to the safetyMargin in the 5011 security considerations document. There hasn't been a huge conclusion and many different ideas have been floated by, and we're now at the point where we need to pick between them. Below, I try to lay out the primary and

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

Hi Bob, On Nov 15, 2017, at 00:23, Bob Harold wrote: If I have to add those entries to each zone, I worry that the automated DNS appliance that I use might not be able to create the broken records required. Since the implementation of the mechanism requires special handling

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

Actually Wes, it was absolutely bad for me making the poor assumption on the choices aligned between the email and the slide. You are correct the preferred option we hear as the 16 bit value. On Wed, Nov 15, 2017 at 8:40 AM, Wes Hardaker wrote: > Geoff Huston

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

Parental synchronization is inevitable so we would be better to find the best way to make it happen. I think there are 3 plausible methods to do the synchronization. 1. Child Notification: Child sends NOTIFY to a predefined parental destination. The parent then polls the child zone for changes

Re: [DNSOP] Clarifying referrals (#35)

On Tue, Nov 14, 2017 at 12:21:11AM -0800, Paul Vixie wrote: > i mean propagating REFUSED back to the stub so that it can return an > error to its application or user. Okay. I haven't encountered a resolver that propgates REFUSED from the authority to the stub. If there is such a beast, then

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

On Mon, Nov 13, 2017 at 9:26 PM, wrote: > > 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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

On Tue, Nov 14, 2017 at 4:10 AM, Dave Lawrence wrote: > Dave Lawrence writes: > > The main changes, based on previous feedback, are: > > > > * Clarifying what the action is for Standards Track; > > * Describing the algorithm previously proposed (and still included) as > > one

[DNSOP] I-D Action: draft-ietf-dnsop-dns-tcp-requirements-01.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 : DNS Transport over TCP - Operational Requirements Authors : John Kristoff

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

On 11/13/17, 21:15, "DNSOP on behalf of 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

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

Evan Hunt wrote: > > In the present context, I was only suggesting this method be used for > NOTIFY, not UPDATE -- to signal the parent that it should poll the child > for CDS/CDNSKEY. (I guess CSYNC could be included in the mix as well, > though, for updating NS and glue.) Yes.

Re: [DNSOP] Clarifying referrals (#35)

Hi, On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > > there is no reason for an authority server to know who the root name servers > are. so, there can be no expectation that it would know any "closer" name > server set than the one at its zone bottom. I think your claim there

Re: [DNSOP] DINRG update

On 11/14/17 5:13 PM, Dave Lawrence wrote: > Given that the Thursday dnsop slot from 15:50-17:50 has been > cancelled, is there interest in having another get-together then? That's still scheduled against both nwcrg and acme, so it's not a great time. The core issue that led to us canceling the

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

On 14/11/2017 01:37, Evan Hunt wrote: > 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

Re: [DNSOP] DINRG update

On Nov 13, 2017, at 8:12 AM, Melinda Shore wrote: > With regrets to the fine folks of dnsop, we've scheduled the > dinrg side meeting from 9:30 - 12:00 this morning. We realize > that there are many people in the dns community who are > interested in decentralized

Re: [DNSOP] I-D Action: draft-ietf-dnsop-serve-stale-00.txt

Dave Lawrence writes: > The main changes, based on previous feedback, are: > > * Clarifying what the action is for Standards Track; > * Describing the algorithm previously proposed (and still included) as > one example way of achieving the goals; and, > * Adding a rough proposal for an EDNS

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

Joe Abley wrote: ... I don't think it's sensible to say absolutely that there will never be a need to disambiguate NXDOMAIN or NOERROR since never is an awfully long time, and who knows or dares to dream? that outcome depends on scope. if you imagine a protocol speaker behaving differently

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

On Nov 14, 2017, at 16:47, Viktor Dukhovni wrote: Well, once we're in the "lying with DNS" business, we hardly need to restrict extended diagnostics to errors, we can equally contemplate them for policy-based answers that don't reflect the authoritative zone content...

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

On Mon, 13 Nov 2017, Paul Vixie wrote: whether DNS can adapt remains to be seen. but declaring working and desired configurations such as split-DNS to be undesireable, or breaking them, or failing to support them, are head-in-sand moves. the internet historically responds to head-in-sand

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

On Tue, Nov 14, 2017 at 07:56:00AM +, Shane Kerr wrote: > > And indeed unlike actual errors, there is nothing one could possibly > > add in the form extended "error" diagnostics when returning a NODATA > > or NXDomain response, these non-error conditions don't require any > > additional

Re: [DNSOP] Clarifying referrals (#35)

Evan Hunt wrote: On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: while specific guidance was not given as to resolver action in response to each possible authority RCODE, i have both witnessed and implemented full resolvers which treated REFUSED as a permanent failure whereas

Re: [DNSOP] Clarifying referrals (#35)

On Mon, Nov 13, 2017 at 11:03:11PM -0800, Paul Vixie wrote: > while specific guidance was not given as to resolver action in response > to each possible authority RCODE, i have both witnessed and implemented > full resolvers which treated REFUSED as a permanent failure whereas > SERVFAIL was a