Hi,
On 04/10/2014 09:54 PM, Patrik Fältström wrote:
>>>> 2.2.1. Solution Space
>>> : :
>>>> Some parents want the child to express their DNSKEYS in the
>>>> form of DS records, while others want to receive the DNSKEY
>>>> records and calculate the DS records themselves. There is no
>>>> consensus on which method is better; both have good reasons to
>>>> exist. The proposal below can operate with both models, but
>>>> the child needs to be aware of the parental policies.
>>>
>>> Mumble...I really dislike the fact we have not agreed on what to
>>> do. It increases complexity _a_lot_. And yes, this is one of the
>>> reasons why we do not see more deployment of DNSSEC.
>>>
>>> Why do we (IETF) fail on this?
>>>
>>
>> Yes; however, we want this to be deployed and usable by as many
>> people as possible, so we are avoiding the religious argument in
>> this document. Registry operators are entitled to their own
>> opinion, as much as we dislike it....
>
> This is not YOUR fault, and you can not fix this problem in THIS
> draft. I just find it being...not fun.
I had proposed to have one CDS record that has the RDATA identical as
the DNSKEY record, plus a hash digest type field. For example:
example.com. 86400 IN CDS *1* 257 3 8 AwEAA...
This would work for both agents that want DS and agents that want
DNSKEY. Counter arguments from Warren were:
1. No, because now the parents who want DS are not getting DS -- they
are getting DNSKEY.
My understanding was that the reason why parents want DS is so that the
child can determine the hash digest to be used. So the format of the CDS
record does not really matter.
2. Some children want to be able to publish a DS record, but not expose
the DNSKEY until they start using it -- the method you have described
doesn't allow for that
Why would you not want to expose the DNSKEY that you are going to use?
I had not yet received good responses for my 'counter-counter'
questions. But if Warren's arguments are valid, then having two
different records is imo the cleanest solution.
>>>> 4.1. CDS / CDNSKEY processing rules
>>>>
>>>> If there are no CDS / CDNSKEY resource records in the child,
>>>> this signals that no change should be made to the current DS
>>>> set. This means that, once the child and parent are in sync,
>>>> the child DNS operator MAY remove all CDS records from the
>>>> zone.
>>>
>>> I am really nervous we will have a state enforced somewhere, that
>>> must remember what has happened. I much rather want to see the
>>> child always have CDS/CDNSKEY for the proper key set.
>>>
>>> So, there must be a reason why this is not allowed?
>>
>> Much of the point of this is to *avoid* the parent having to keep
>> state. If it queries the zone and sees no CDS records, it simply
>> goes back to sleep.
If the child will maintain the CDS/CDNSKEY RRset in its zone, the only
extra step the parental agent has to make is to do a compare and if the
compare returns 'in-sync', it simply goes back to sleep.
>> Let's say that example.com is signed but has never used CDS /
>> CDNSKEY (like every signed zone currently is). We really don't want
>> the parent going through and removing DS records because there is
>> no CDS published :-) By having a "take no action if there is no
>> CDS/CNSKEY" rule the parent doesn't need to track which children
>> use this.
But you have to do the polling anyway. And there is no tracking or
maintaining state for the parent if the child maintains the CDS/CDNSKEY
RRset.
So, it makes it marginally more difficult (one compare per poll) for the
parent, while the rule of removing the CDS/CDNSKEY RRset when in-sync
makes it much more complex for the child, with all the polling and
additional state it needs to maintain.
>>>> When the Parent DS is "in-sync" with the CDS / CDNSKEY, the
>>>> Child DNS Operator MAY delete the CDS / CDNSKEY RRset(s).
>>>
>>> See above. How does the child know? Do you because of this
>>> require the child to poll the parent zone? And if the parent want
>>> to re-fetch the data for some reason, it might be gone from the
>>> child zone. Not good.
>>
>> Yes, the child checks the parent to see if it's in sync. A number
>> of working group participants (I had thought yourself included),
>> had indicated that they would rather have this as more of a
>> transaction system, so that the user publishes a record, the
>> parental agent performs the operation, and then the user is
>> expected to remove the "instruction." The reason for this was so
>> that the user's intent is clear and parental agents can, if they
>> wish, log the "transaction." I will see if I can find references to
>> that (it's not noted in the minutes, but I think Antoin Verschuren
>> said it and a bunch of other folk agreed).
>
> See above.
>
> I am lazy as a programmer. I do not want people to start to REQUIRE
> the CDS/CDNSKEY to be removed. It must be perfectly ok to have the
> CDS/CDNSKEY in the zone all the time.
I am a programmer. I do not want to track and remove the CDS/CDNSKEY if
they are in-sync.
> Maybe I am more relaxed if you explicitly say that is a normal case.
Fully agree.
>>>> A child MAY publish both CDS and CDNSKEY. If a child chooses
>>>> to publish both, it SHOULD attempt to maintain consistency (a
>>>> matching CDS for each CDNSKEY)
>>>
>>> No, it MUST represent the same data. Please!
>>
>> DONE. It seems like you feel strongly about this :-) My reason for
>> originally having this as a SHOULD are described above (expecting
>> users the follow a MUST leads to implementers to treat "violations"
>> of the MUST as an error...). But, seems like I'm off in the rough,
>> changed...
>
> Ha ha ha...
>
> See above, I now understand.
>
> I want to know what happens both from the child and parent
> perspective IF the CDS and CDNSKEY differs.
>
> Just say what the result should be.
>
> Parent pick one at random?
At random? Then you still don't really know that the result would be ;)
Best regards,
Matthijs
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
