[dnssec-deployment] DNSSEC Deployment Roadmap Draft -- Revised diagrams

Edward Lewis 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
3) Registries
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 "          "
4) Registrants
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 
setting bodies.

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 
obviously legitimate.

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 
ICANN/not registry.

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 mailing list