[dnssec-deployment] DNSSEC Deployment Roadmap Draft -- Revised diagrams
Ed.Lewis at neustar.biz
Mon Jan 17 13:15:55 EST 2005
At 16:03 -0500 1/4/05, Amy Friedlander wrote:
>The revised diagrams for the DNSSEC Roadmap are attached for comment.
This is going back a bit in time, but here is how I think I may
divide the DNSSEC "problem areas"
1) Root Zone
2) ARPA Zone
3a) gTLD, by which I mean, .com, .mil, .biz, .info
3b) ccTLD, including .tv, .us, .de, .to
3c) arpaTLD, including in-addr, e164
3d) subTLD, including co.uk
3e) Shared Registries, such as .net
3f) Other In-Direct Registries, such as the RIRs
3g) Direct-only Registries, off hand I don't know
3h) ICANN accredited registries
3i) Non-ICANN " "
4a) DNS outsourcing operators
5) DNS Cache Operators, like "to the home" ISPs
Dividing #3 is not easy. All registries ought to fit into one (and
only one) of 3a-3d. Also, one and only one of 3e-3g, and in one and
only one of 3h-3i.
The problem with #3 is that the first division reflects how a
registry (operator) reports. (Ex., "we" "report to" ICANN for .biz,
US DOC for .us.) This will highlight dependencies, but that's about
all. The second division is more along the lines of how a registry
is externally architected, e.g., whether EPP is the main input, SMTP
is the main input, and the kind of relationship it has with the
customers. The third division tries to put circles around the policy
I suppose I could divide 3i into "membership run" organizations like
the RIR's and into "some other decision making model".
What I haven't divided amongst is technical "DNA" - I suspect that it
probably isn't useful though, well, really, I shouldn't say. I don't
know if code, like that offered by .br, is prevalent.
As far as the others,
Cat 1 - The uniqueness is that they have to figure out how to
distribute and redistribute the SEP key for the zone. There has to
be some organizational object that manages the SEP key too, and this
needs to be clearly defined with respect to the relationships of the
root zone name server operators.
Cat 2 - This zone is unique in that it is, like, just "sitting there"
in the middle with not much action. It has to be accounted for, and
if I'm right, is the "property" of the IAB. A proper "deed" ought to
be drawn up and published, so that the operators of the zone are
Note that by "arpa." I mean the zone, not the domain.
Cat 3 - I've already wrung my hands over this a bit.
I think the may the division is made will depend on the phase of
deployment considered. To wit:
o Generally the software in use is not a matter of obligation,
usually that's left to service level agreements. Grouping along
technical DNA is best here, a bit towards whether it's a ccTLD or now.
o Including DNSSEC records in a zone may be a decision gated on
something in an operations agreement. This plays to whether it's an
o Offering the service of registrant DS registration may need review
of a membership or other decision making body that has purview over
budget and mission scope. Here it's a matter of governing body.
o The means by with DS registration may be via an EPP extension (or
RRP, et.al.), or via an ad hoc text-based template, or via a secured
web portal. This plays to shared registries, etc.
o Whether there are dependencies by external organizations is
important - ICANN-style shared registries have accredited registrars
that have to be able to play, For the RIR's, ISP's, LIR's, and NIR's
as appropriate will have to be able to deal with DNSSEC requests too.
I think that there's no clear division of the registries in general
because there are so many sub-steps. Some sub-steps are technical,
some are not.
Cat 4 - This covers those who "pay" to put stuff into the DNS. This
may be the same org that does the DNS, it might be that the DNS
operator is a third party and is the one dealing with the registry.
E.g., some registrars are also the DNS hosters, ISP's are essentially
that for RIR's.
Cat 5 - We've been over looking this group. This is the set of folks
that don't put data into DNS, but do put the SEP keys into their
servers. AOL leaps to mind here as one example, cox.net as a
cable-model service, dial-ups, etc.
Maybe this is a bit off-topic, but it's something that I needs to be
reflected in the plan - if the Internet is the Information
Superhighway (and old, tired paradigm), the registries are the on and
off ramps and the registrars are the signs that say "Freeway Begins
Here" (for those in California). User-ISP's, like AOL, are also like
the signs, maybe a slightly different way.
If you've ever driven so long on a highway that you began to enter a
snow storm and have tried to get off - you know that it is as
important to plow the ramps as it is important to plow the highway
(more so in cloverleafs). The problem is that we/IETF spend so much
time worrying about plowing the highway we tend to neglect the ramps.
Trying to get on to this highway, even if the ramps are salted and
plowed is only possible if you see the signs. Signs are technically
boring, like documentation, and we usually leave them last.
If you want DNSSEC to go anywhere, make sure we manage the signs and
the ramps. I think this group understands the need to salt and plow
the ramps, but I don't think we've spent enough time on the signs.
This is why I added cat 5, and has some to do with what's in cat 3.
Edward Lewis +1-571-434-5468
"A noble spirit embiggens the smallest man." - Jebediah Springfield
More information about the Dnssec-deployment