Re: [dnsext] perhaps we should reintroduce "resimprove"

Florian Weimer <fw@deneb.enyo.de> Fri, 10 February 2012 14:50 UTC

From: Florian Weimer <fw@deneb.enyo.de>
To: "W.C.A. Wijngaards" <wouter@nlnetlabs.nl>
References: <3699_1328861785_4F34D258_3699_2027_1_4F33E1A6.4030902@isc.org> <20120210084439.GB7284@laperouse.bortzmeyer.org> <4F34E0BF.9060305@nlnetlabs.nl>
Date: Fri, 10 Feb 2012 15:50:06 +0100
In-Reply-To: <4F34E0BF.9060305@nlnetlabs.nl> (W. C. A. Wijngaards's message of "Fri, 10 Feb 2012 10:17:51 +0100")
Message-ID: <87lioayc81.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Cc: dnsext@ietf.org
Subject: Re: [dnsext] perhaps we should reintroduce "resimprove"
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: dnsext-bounces@ietf.org
Errors-To: dnsext-bounces@ietf.org

* W. C. A. Wijngaards:

> This replacement is wrong.  We must have '=' in >= to pick up zone
> changes from the same server.  We must have revalidation at the parent
> for the ghost-domain problem, it is simply a case of having the NS TTL
> expire (i.e. meaning, the NS RRset can be replaced with a newer one but
> the NS TTL does not increase).

This is correct for the immediate delegation.  However, it does not
help if there is yet another delegation.  This one would have
attacker-controlled TTLs in the parent (child) and child (grandchild).

Therefore, I fear that an approach which just picks up the data from
the child while keeping the TTL from the parent does not actually
address the issue of crafted TTLs.  Some sort of recursive,
tree-dependent approach appears to be required.
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

[dnsext] perhaps we should reintroduce "resimprov… paul vixie
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Frederico A C Neves
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Andrew Sullivan
Re: [dnsext] perhaps we should reintroduce "resim… Warren Kumari
Re: [dnsext] perhaps we should reintroduce "resim… Stephane Bortzmeyer
Re: [dnsext] perhaps we should reintroduce "resim… paul vixie
Re: [dnsext] perhaps we should reintroduce "resim… W.C.A. Wijngaards
Re: [dnsext] perhaps we should reintroduce "resim… Florian Weimer
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] perhaps we should reintroduce "resim… Nicholas Weaver
Re: [dnsext] perhaps we should reintroduce "resim… Paul Hoffman
Re: [dnsext] perhaps we should reintroduce "resim… Evan Hunt
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] perhaps we should reintroduce "resim… Blacka, David
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
[dnsext] Ghost domain names Edward Lewis
Re: [dnsext] perhaps we should reintroduce "resim… Blacka, David
Re: [dnsext] perhaps we should reintroduce "resim… Olafur Gudmundsson
Re: [dnsext] Ghost domain names Florian Weimer
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy
Re: [dnsext] perhaps we should reintroduce "resim… Edward Lewis
Re: [dnsext] perhaps we should reintroduce "resim… Paul Vixie
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy
Re: [dnsext] perhaps we should reintroduce "resim… Mark Andrews
Re: [dnsext] perhaps we should reintroduce "resim… Mohan Parthasarathy