<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div><div class="markdown">
<p dir="auto">On 2021-06-29 00:25:30 (+0800), Wessels, Duane wrote:</p>
<blockquote>
<p dir="auto">On Jun 28, 2021, at 3:08 AM, Philip Paeps <a href="mailto:philip@trouble.is">philip@trouble.is</a> wrote:</p>
<blockquote>
<p dir="auto">On 2021-06-26 04:25:22 (+0800), Wessels, Duane via Opendnssec-user wrote:</p>
<blockquote>
<p dir="auto">Based on what I read at the Key States Explained page of the wiki, I expected to see an intermediate SUBMIT state where I would then tell the enforcer that it has been submitted (but not yet seen).</p>
<p dir="auto">My syslog has this: [...]</p>
</blockquote>
<p dir="auto">As I understand it, the SUBMIT state begins when DelegationSignersubmitCommand starts executing and ends when it finishes.</p>
<p dir="auto">Because you have no DelegationSignersubmitCommand configured, the state change is invisible to you.</p>
<p dir="auto">I don't believe there is a way to make a key stay in the ds-unsubmitted state. There is no practical use for such a state though, since nothing will happen to the key until ds-seen is reached. So you may as well hang out in waiting for ds-seen.</p>
</blockquote>
<p dir="auto">Seems like my qualms are mostly with the documentation then. The wiki page on key states says "It either waits for the user confirming the upload" which isn't the case.</p>
</blockquote>
<p dir="auto">Yeah. That's wrong. As far as I can tell, it moves to SUBMITTED unconditionally, passing through SUBMIT, whether or not a DelegationSignersubmitCommand has been configured. The practical outcome is the same though. The only way to progress from SUBMITTED is to send a ds-seen command.</p>
<blockquote>
<p dir="auto">It is not clear when one should execute 'ods-enforcer key ds-seen'. Is that as soon as the DS record first appears in the parent zone? Or should one wait an additional DS TTL so it expires from caches? I suspect it is the former, but in either case it is not clear what is the point of specifying the parent DS TTL in the policy.</p>
</blockquote>
<p dir="auto">The former, indeed: when the key is available at <em>all authoritative servers</em> for the parent zone. The "available for everyone" is important here.</p>
<p dir="auto">I suspect the need to specify the parent DS TTL in the policy relates to the transition from rumoured to omnipresent. Somebody familiar with the code would have to confirm this. I'm afraid to look too closely. :-)</p>
<p dir="auto">Philip</p>
<p dir="auto">--<br />
Philip Paeps<br />
Senior Reality Engineer<br />
Alternative Enterprises</p>
</div></div>
</body>
</html>