Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On Wed, May 2, 2018 at 11:47 PM, Edward Lewis wrote: > > > If I can't find the text soon, I'll try to recreate the list of references > at least. > We are in process of implementing a "Lame delegations" policy at AFRINIC We consider "lame"

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

> On 26 Mar 2018, at 16:47, Jim Reid wrote: > > On 24 Mar 2018, at 20:20, Ondřej Surý wrote: >> >>> It might be a different story if one of those zombie RRtypes required >>> additional processing. None spring to mind though. >> >> But (most of) those I

[DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Hi WG Chairs (and WG) We have submitted -12 of this draft which we believe incorperates the substantive review comments made during the WG Last Call period that were posted to the WG Mailing List. > > Editors: Please take “concern about a description of current implementation > status” as

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-12.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 Root Key Trust Anchor Sentinel for DNSSEC Authors : Geoff Huston

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Hi, On 03-05-18 10:15, Geoff Huston wrote: > We have also taken the implementation comments posted to the WG mailing list > and collected them in a new section titled "Implementation Experience” in the > light of Suzanne’s request This draft is by now implemented in Unbound and is in version

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Ed Lewis wrote: > (Only if you like reading history:) > The reason was a flaw in "certain old resolvers" that followed the "upwards > referral" to the root that > the "predominate server code of the time" had decided to use for lameness.. > The result was a lot of > resolver stuck in an

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

On 3 May 2018, at 10:06, Paul Vixie wrote: what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? None. That is, they will either be ready or they won't be, and this draft doesn't change that. This draft is about signaling, not about actually being

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Geoff Huston wrote: On 4 May 2018, at 3:06 am, Paul Vixie wrote: what are the implications for older (pre-KSKROLL) validators when icann eventually rolls the key? I assume that you are referring to security-aware resolvers that do not perform the actions specified in

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

It’s amazing how fast people can fix lame delegations once email and other services stop flowing. The only reason you think it is un- winnable is that you are unwilling to remove the delegation for failing to maintain a properly working configuration. Start removing lame delegation after fair

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Mark Andrews stated: >It’s amazing how fast people can fix lame delegations once email and other >services stop flowing. The only reason you think it is un- winnable is that >you >are unwilling to remove the delegation for failing to maintain a properly >working configuration. Ideally, yes

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On May 3, 2018, at 3:27 PM, David Huberman wrote: > In practical terms, when any type of registry strips away a lame delegation > attached to a real, operating network with users behind it, and things break > as a result… But isn’t that, by definition, impossible?

Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

> On 4 May 2018, at 3:06 am, Paul Vixie wrote: > > what are the implications for older (pre-KSKROLL) validators when icann > eventually rolls the key? I assume that you are referring to security-aware resolvers that do not perform the actions specified in this draft. There

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On Thu, May 03, 2018 at 10:27:30PM +, David Huberman wrote: > Mark Andrews stated: > > >It’s amazing how fast people can fix lame delegations once email and other > >services stop flowing. The only reason you think it is un- winnable is that > >you > >are unwilling to remove the delegation

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On 4 May 2018, at 8:36 am, Bill Woodcock wrote: > > > >> On May 3, 2018, at 3:27 PM, David Huberman wrote: >> In practical terms, when any type of registry strips away a lame delegation >> attached to a real, operating network with users behind it,

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

>> On May 3, 2018, at 3:27 PM, David Huberman wrote: >> In practical terms, when any type of registry strips away a lame delegation >> attached to a real, operating network with users behind it, and things break >> as a result… Woody replied: > But isn’t that, by

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On May 3, 2018, at 4:23 PM, Mark Andrews wrote: > A “Lame Delegation” can be to a particular machines. These delegation for > .fj are lame and have been for over a year. Right, of course, but what breaks if you remove the lame nameservers from the NS list? What am I not

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On May 3, 2018, at 4:33 PM, Mark Andrews wrote: > You see the same with forward zones with domain parking. They set up a ..com > (or root) zone for all the *.com zones parked on the server and break all > negative responses as a consequence. Right, but again, that’s not

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On 4 May 2018, at 10:11 am, Bill Woodcock wrote: > > > >> On May 3, 2018, at 4:23 PM, Mark Andrews wrote: >> A “Lame Delegation” can be to a particular machines. These delegation for >> .fj are lame and have been for over a year. > > Right, of course, but

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On 4 May 2018, at 10:13 am, Bill Woodcock wrote: > > > >> On May 3, 2018, at 4:28 PM, David Huberman wrote: >> On May 3, 2018, at 3:27 PM, David Huberman wrote: In practical terms, when any type of

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On 4 May 2018, at 9:28 am, David Huberman wrote: > >>> On May 3, 2018, at 3:27 PM, David Huberman wrote: >>> In practical terms, when any type of registry strips away a lame delegation >>> attached to a real, operating network with users

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

Fred wrote: >As long as there is community support Mark's observation works as >expected. >Slightly variatios of this policy are in place for LACNIC and APNIC >regions and is very effective. Thank you, Fred, and apologies for my incomplete answer that was biased by my geography.

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On 4 May 2018, at 9:37 am, David Huberman wrote: > > Fred wrote: >> As long as there is community support Mark's observation works as >> expected. > >> Slightly variatios of this policy are in place for LACNIC and APNIC >> regions and is very effective. > > Thank

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

> On May 3, 2018, at 4:28 PM, David Huberman wrote: > >>> On May 3, 2018, at 3:27 PM, David Huberman wrote: >>> In practical terms, when any type of registry strips away a lame delegation >>> attached to a real, operating network with users

Re: [DNSOP] Fixing lame delegations

Please not the change of the subject line. Discussion of how to fix the problem has nothing to do with the definition. Carry on. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-terminology-bis-10

Thanks, those were all good editorial comments. They'll make it into the next draft. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Lameness terminology (was: Status of draft-ietf-dnsop-terminology-bis)

On Thu, 3 May 2018 06:12:42 + Amreesh Phokeer wrote: > We consider "lame" any NS which is either: > - Not responding at all. > - Responding in some way, but not for the specific domain queried. > - Responding for the correct domain, but without the authority bit

Re: [DNSOP] [Ext] Lameness terminology

Mark Andrews wrote: ... The problem is that you can’t just remove the NS records from the parent side because name servers learn the NS records from the child side of the delegation as well as the parent side. The offending NS records need to be removed from both sides. This (or fixing