On 03/13/2013 10:02 AM, Joe Abley wrote:
On 2013-03-13, at 12:54, Doug Barton <[email protected]> wrote:
On 03/13/2013 09:39 AM, Joe Abley wrote:
However, there's nothing to stop registrars making arrangements
with their registrants to receive change requests via signed
RRSets. It may that for gTLDs (and other TLDs in a similar
sitaution), we don't need buy-in from lots of registries; we need
buy in from a registrar.
That makes the problem worse, right? As there are many more
registrars than there are registry operators.
Depends what you think the problem is. I think it makes the problem
better; you only need one registrar with a relationship with many
registries to do this, and you have a one stop shop for all your
domains that you want to manage this way.
Assuming that all of your domains are at registries that registrar has
relationships with. In order to really make this work a non-trivial
number of TLD registries (which have a variety of different rules and
policies) AND registrars would have to be on board. Has anyone
communicated with them about this topic? The ICANN forums for both
groups would be a good place to start.
The question of how likely it is that anybody will implement this
is difficult to answer without time travel capability. However,
if there's no standardised mechansm, I think chances are good
that nobody will implement anything.
Um ... aren't you looking at it bass-ackwards? It doesn't matter if
we develop a standard if it doesn't meet a real-world need.
Communicating with the primary target audience for the thing we are
developing would seem to be a good step in the process.
You weren't asking whether you thought there was a need; you were
asking whether this particular mechanism would be implemented.
Anybody who has used existing tools to maintain even a modest
portfolio of signed domains understands that there is a need, I
think. What we have right now sucks.
You're defining "need" differently than I am. You're saying, "We need an
automated mechanism to deal with DS records." I'm saying that unless the
registries and registrars are on board with the mechanism we create, it
doesn't matter how good it is, it isn't going to solve the real-world need.
Or put more simply, "Creating protocols in a vacuum is bad."
2. Because sometimes you want to publish DS RRs in your
parent that correspond to standby keys that are not published
in the child.
If the parents are actually using some method of accepting
signals from the child to scrape the zone (whether CDS; actual
scraping of NS, DNSKEY, etc.; or some other method) wouldn't
that lower the barrier to entry for standby keys?
I don't understand the question. What does "lower the barrier to
entry for standby keys" mean?
If I have confidence that as a result of whatever mechanism gets
implemented that my parent is going to create a DS record for my
new key in near real time, how important is it that I pre-publish
standby keys?
It's important if you care about being able to retire compromised
keys promptly and not have to wait the DS TTL for people to be able
to see you again.
Also, I don't know how realistic "near real time" is, if you consider
the problem of a parent operator having to poll 5,000,000 children
for changes. "Some time today" would satisfy the need I see.
... which is why I agreed with the others that raised the idea of a
special packet for the child to send to the parent to signal the need to
scrape.
Doug
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
