On 11 apr 2014, at 23:48, Warren Kumari <war...@kumari.net> wrote: >> This is not YOUR fault, and you can not fix this problem in THIS draft. I >> just find it being...not fun. > > Yup, me too. > If they made me President of the Universe: > 1: SPAM would be a capitol offense. > 2: All movies **MUST** (RFC2119-style) contain a blooper reel (if > nothing funny happened while filming, well then film some more...) > 3: Everyone would take DNSKEYs (I used to think DS but Antoin > convinced me otherwise....). > 4: By the time they reach 21, everyone would have to have visited at > least 3 other countries, with noticeably different language and > culture (government assistance would be provided to those who really > cannot afford this on their own). > 5: Kylie Minogue's "Locomotion" would be banned. I dislike censorship > as much as the next person, but you have to draw the line somewhere.
Where do I cast my vote?
>> Yup, I did understand this, but just felt it was not really crystal clear
>> enough. I know DNSSEC (I think....:-) ) and still had to look at some of the
>> text a few times to ensure that there where no loopholes.
>
> I *think* the -04 version addresses this now -- good 'nuff?
> Actually, in my edit buffer (which will become -05 -- "Launch and
> iterate") I have:
> "This proposal does not include all operations needed for the
> maintenance of DNSSEC key material, specifically the initial
> introduction or complete removal of all keys. Because of this,
> alternate communications mechanisms must always exist, potentially
> introducing more complexity."
Excellent!
> In my -05 edit buffer:
> The child SHOULD publish both CDS and CDNSKEY. If the child knows
> which the parent consumes, it MAY choose to only publish that record
> type (for example, some children wish the parent to publish a DS, but
> they wish to keep the DNSKEY "hidden" until needed). If the child
> publishes both, the two RRsets MUST match in content. The parent
> should use whichever one they choose, but SHOULD NOT query for both
> and perform consistency checks between the CDS and CDNSKEY records.
>
> Note: It is not an error for a child to have published CDS records and
> not have CDNSKEYs that hash to those records, nor for there to be
> CDNSKEY records without matching CDS records. This is because a child
> might have been publishing CDS records and then the parent's policy
> changes to require CDNSKEY records. The child might forget to remove
> the CDS, etc. This avoids all sorts of error conditions / complexity,
> etc"
>
> Is this better / clearer? I'm uncomfortable with the "If the child
> publishes both, the two RRsets MUST match in content.". It sort of
> sounds like the rdata must be identical. Can anyone suggest better
> text? "the two RRsets MUST have the same semantic meaning?" something?
Excellent.
The rest of the comments are approximately this. You only have to say this once.
>> 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.
>>
>> Maybe I am more relaxed if you explicitly say that is a normal case.
>
> Just sent mail to the list explicitly asking which folk would prefer.
> My preference is that children just leave the records around (and
> update the doc to say so). We had originally put this in because
> someone asked us too (and we cannot remember who that was!).
> Hopefully folk will want the behavior you (and Matthijs) are asking for.
We'll see.
>> How often do you click "yes" and "no" when your ssh client show you an
>> initial fingerprint? ;-)
>
> Well, I never click Yes *and* No :-)
Mumble, I blame a few reports from the Swedish Government on Fibre deployment
that was pure crap, lack of coffee and other things.
> Do you like:
> "The delegation user interface has a button {Fetch DS} when pushed
> preforms the CDS / CDNSKEY processing. If the Parent zone does not
> contain DS for this delegation then the "push" SHOULD be ignored. If
> the Parental Agent displays the contents of the CDS / CDSNKEY to the
> user and gets confirmation that this represents their key, the
> Parental Agent MAY use this for initial enrolment (when the Parent
> zone does not contain the DS for this delgation). "
Good!
>>>>> 6.2. Using the new CDS / CDNSKEY records
>>>>>
>>>>> Regardless of how the Parental Agent detected changes to a CDS /
>>>>> CDNSKEY RR, the Parental Agent MUST use a DNSSEC validator to obtain
>>>>> a validated CDS / CDNSKEY RRset from the Child zone. It would be a
>>>>> good idea if the Parental Agent checked all NS RRs listed at the
>>>>> delegation.
>>>>
>>>> What does "would be a good idea" mean in RFC 1918 speak? :-)
>>>>
>>>> More seriously, no, I do not think that requirement should be there at all.
>>>
>>> Which one? I'm assuming you are fine with / like the "Parental Agent
>>> MUST use a DNSSEC validator"?
>>
>> I just wanted to know in official MAY/MUST/SHOULD language what "be a good
>> idea" means first of all.
>>
>>>> How to handle lame delegation, inability to use cached information, what
>>>> TTL can be acceptable etc is hidden in this "good idea". Just remove it.
>>>>
>>>> Either DNS is used to fetch the RR or not.
>>>>
>>>>> The Parental Agent MUST ensure that old versions of the CDS / CDNSKEY
>>>>> RRset do not overwrite newer versions.
>>>>
>>>> I do not think this is a good idea. See above.
>>>>
>>>> Please remove.
>>>>
>>>> This is because there is a requirement on state in the parent. I dislike
>>>> that. Much better if the CDS/CDNSKEY is always reflecting the current
>>>> state in the child zone. And just say so.
>>>
>>> This was specifically added because folk asked for it. You have a
>>> "primary" DNS server and a bunch of "secondaries" (by "primary" and
>>> "secondary" I mean you have one server where you make the changes, and
>>> the others all slave from it).
>>> You are in the process of rolling from key BAR to key FOO.
>>>
>>> You have:
>>> . CDS KEY_FOO on the primary.
>>> and
>>> . CDS KEY_BAR on the secondaries because they have not yet AXFRed the zone.
>>>
>>> The parent chooses an NS at random - it picks the "primary" and
>>> updates what it publishes for the child.
>>> It then tries again, and happens to hit a "secondary".. and updates
>>> what it publishes for the child.
>>> Lather, rinse, repeat.
>>
>> No, I absolutely do not like this.
>>
>> You also have caching, you have lame delegation and a million other things.
>>
>> This is why we do key rollover with multiple keys.
>>
>> So you never jump from CDS KEY_FOO to CDS KEY_BAR in one hop. You always
>> have them overlap, OR, you get the problem you talk about. And it is not the
>> parents responsibility to ensure you do not as a child shoot yourself in
>> your foot.
>>
>> We already have too many parents that have I do not know how many stupid
>> rules for what various values must be in the child hosting situation, and in
>> many cases that make it plain impossible to do what you want as a child.
>> Really silly rules.
>>
>> Parent should not control the child.
>>
>> If the child do NOT want the problem you talk about, have overlapping
>> CDS/CDNSKEY. If you want to jump quickly, do what you suggest with non
>> overlapping CDS/CDNSKEY but risk that the wrong DS might be published in
>> parent zone. Up to you as a child.
>>
>> Compared to many other things that I suggest, I can give up my arguments,
>> but not this. This I must really be convinced why I am wrong.
>
> Ok. Fair. Removed.
Thank you VERY much!
Hint: Try to register a domain name in the .IS ccTLD. That is the latest hangup
I have regarding broken policy by a registry. There are probably others as
well, but this is my latest "interesting" case.
Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
