Re: Example of stupid inconsistencies between registries

MICHAEL YOUNG <[email protected]>
Newsgroups gmane.ietf.provreg
Message-ID <[email protected]>
Ok I see this argument but on the other hand I have to ask how much responsibility does the registry want to take on?  Some ccTLDs won't even complete the registration process until the proposed child zone is up and verification checks are run by the registry. I can see a logical extension of that practice would be to verify the DS data.  However, lets face it, I can publish whatever I want to the registry and then later on mess my zone up because I mis-manage something.  

Besides, if the DS data is wrong, then DNSSEC validation is just going to choke anyways right? Seems like its a self-regulating problem that the registry doesn't need to try and solve.  The fact that most of the registries are going the  DS route implies they aren't that interested the job of verifying the data. 

Michael


On 2012-03-05, at 8:45 AM, Andrew Sullivan wrote:

> On Mon, Mar 05, 2012 at 11:43:30AM +0100, Patrik Fältström wrote:
> 
>> 
> even though the client might believe that passing the DS data is the
> easiest, the registry might want the DNSKEY data.  The reason to
> prefer the DNSKEY data is because the DS is authoritative _only at the
> parent_.  In principle, then, it is a mistake to accept any old DS
> data from the child side of the zone cut and publish it as
> authoritative data: the registry can't be sure it has that right.
> Therefore, it either should accept DS data with a DNSKEY that it can
> validate the DS with, or else it should just accept the DNSKEY data
> and generate the DS itself.
> 
> 
> Best,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email protected]
> _______________________________________________
> provreg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/provreg




MICHAEL YOUNG
[email protected]

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.