[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: eduardo.duarte@fccn.pt
Cc: ietf-provreg@cafax.se
From: Stephen.Morris@nominet.org.uk
Date: Mon, 1 Feb 2010 16:51:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Stephen.Morris@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1265043116; x=1296579116; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Stephen.Morris@nominet.org.uk|Subject:=20Re:=20o ff-list=20was=20Re:=20[ietf-provreg]=20Revision=20of=2043 10|Date:=20Mon,=201=20Feb=202010=2016:51:55=20+0000 |Message-ID:=20<OFA3D4C20F.3604D5AA-ONC12576BD.004FBBB6-8 02576BD.005CA4F9@nominet.org.uk>|To:=20eduardo.duarte@fcc n.pt|Cc:=20ietf-provreg@cafax.se|MIME-Version:=201.0 |In-Reply-To:=20<C7874CA4.371AF%jgould@verisign.com> |References:=20<4B61D313.5020802@fccn.pt>=20<C7874CA4.371 AF%jgould@verisign.com>; bh=HAdHjBcjclvjzxUTqyaQLo7lx4UKUlTCdYoQlv2wYRA=; b=uCOAJtD1vmvdfIDG8cjOXEoAveGzjpv4WmGJ8KFa6HOSGB67roltnC1h PavIO6ZUICpZ6XpO5781rSuBLfl0lV7dGahEmCIzmZ81JaSqiSHeSBZms FUIKu3dLbtoyT8O;
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: MIME-Version:Subject:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=OUyJc9CQcx7y5brlOb3yb+8XR7c3QDy/ZhG1a1CAI2ggZSxTzS1kgyBC XJv/0qDPXSMlVmFmbZnhcv6E/X/qENMRRUdT/yrx9GuqQW4gm2ua/TK5X LFtVmk8SUJTdzMq;
In-Reply-To: <C7874CA4.371AF%jgould@verisign.com>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: off-list was Re: [ietf-provreg] Revision of 4310

Eduardo Duarte <eduardo.duarte@fccn.pt> wrote:

> ... we are thinking of adding a
> DS validator in order to publish only the correct DS's. Also we always have
> our data in the database and there we keep the multiple keys associated with
> the domain some in publish state and other in a unpublished state. So when a
> user adds a DS to our system he is adding it to the database and not to the
> zone itself and after, when generating the zone the script, will only pick-up
> and add to the zone the "actives" DS's.

As has been pointed out elsewhere, there are valid reasons for publishing a DS record in the parent without a corresponding DNSKEY in the child (e.g. key rollover). If you are going to validate the DS/DNSKEY correspondences, then a better check would be that at least one of the DS records being published in the parent corresponds to a DNSKEY currently in the child.

Stephen
Home | Date list | Subject list