Antoin Verschuren <antoin.verschu...@sidn.nl> writes: > In simple words, what do I do as a parent (or parental agent) when I > recieve information over the DNS that conflicts with data I receive > over the administrative channel. Which data should I follow.
Well, ordering really matters for that, right? I mean there are two choices: 1) I detect a change in DNS data and then receive an operational change via HTTP or some other mechanism. In this case, I think it's fairly clear that the out-of-band HTTP configuration should always supersede. 2) I receive the HTTP request and then notice a DNS change. This case also looks fairly straight forward (but keep reading), as clearly you act on the HTTP request and then a second request (via DNS) comes in second. So you act then on it. The only problem with this approach is when an admin really isn't thinking, publishing something in DNS to make a change, realizes he wants to act immediately and publishes something through the HTTP form interface that *conflicts* with the DNS publish. The HTTP poke goes through immediately, because it's client initiated, so the DNS pull from the parent could come *after* the http submission even though it was published first. If the admin failed to revoke the DNS CSYNC (or whatever) request when in the process of updating over http, that's a mistake on their part (if it conflicts at least). I'd argue that we shouldn't worry about solving this case, as it's clearly a publication of conflict of information. We could warn against it in the operational guidance section though. > It was stated that when a parent is requesting DNSKEY instead of DS, > and the parent calculates the DS, the disadvantage is that the child > cannot choose the digest algorithm. You're right the parent can offer static preferences configured elsewhere. But it's not done in-band. There are rumors (which I haven't verified) that some parents dictate what algorithms they use and the child has no choice. I'm sure there are others that have a set of checkboxes, which lets the child configure the parent's engine too. (and many more parents, of course, allow for DS uploading leaving everything in the hands of the child). > I fail to see how publishing a DS in a CDS record for your standby key > is much more safer from publishing the DNSKEY of your standby key. I agree with you, assuming you can publish your DNSKEY as a separate record (or else people may read it, cache it, memorize it, run tests with it, etc). But no matter how much I agree with you it won't stop others from wanting an oxymoron: "the private public key". -- Wes Hardaker Parsons _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
