> 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 picked actually *DO*:
>>
>> a) compress
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
Joa
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 WGLC
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 1.
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 i
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
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
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
> 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 are no implication
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 this draft. There are
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 –
> 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? What could break as a resul
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
> 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, and things break
>> as a result…
>
> But
>> 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 definition, impossible? What c
> 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 behind it, and things break
>>> as a result…
>
> Woody
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.
smime.p7
> 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 you, Fred, and apologies for
> 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 understanding?
> 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 behind it, and things break
>>> as a result…
>
> Woo
> 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 lameness, per se, it
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
> 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 what breaks if you remove the la
> 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 registry strips away a lame delegation
attached to a real, operating n
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
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 set.
Friends,
I've been refe
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 what
27 matches
Mail list logo
