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

On 2/10/2012 8:44 AM, Stephane Bortzmeyer wrote:
> On Thu, Feb 09, 2012 at 03:09:26PM +0000,
>  paul vixie <vixie@isc.org> wrote 
>  a message of 34 lines which said:
>
>> remove (B) and section 3, 
> Why? It seems fine to me (even if He-Who-Must-Not-Be-Named disagrees).

because arguing those merits will take time, and the other parts of the
proposal which are less controversial should not have to wait while
those arguments complete.

>> progress it not as an improvement but as a security and resiliency
>> requirement (so, a proposed standard) in the face of the "ghost domain"
>> problem.
> It seems to me that this draft does not currently address the ghost
> domain problem. It mandates revalidation at the parent when the
> records expire, but it does not say anything about the rules that
> allow an authoritative server to overwrite the old TTL with a new
> value, thus preventing expiration.
>
> Would it be a better idea to use this draft as a starting point to
> work on the issues proposed by the ghost domains paper? (Replacing >=
> by > in the credibility rules and other measures.)

i think there's some editorial flaw that leads to the above observation.
perhaps an explicit reference to RFC 2181 and some examples about how NS
replacement will work in light of credibility rules, would help explain
why this draft obviates the ghost domain problem.

for example the ghost problem appears to be about glue names (A/AAAA
RRsets referred to by NS RRs) whereas the resimprove solution set seems
to be only about the NS RRsets. but the effect of removing the NS RRsets
due to revalidation will be to purge the cache of any glue names which
were subdomains of those zone apexes.

paul
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext