lip Hallam-Baker writes:
On Tue, Jul 20, 2010 at 12:12 AM, Mark Andrews <marka(_at_)isc(_dot_)org>
lip Hallam-Baker writes:
Being able to verify signatures is of no value.
The system only has value when you can act differently according to
whether the signature verifies or not.
I keep asking, but nobody will tell me how I get the keys for my
domains into the TLD.
Firstly you get DS records into the TLD not DNSKEY records. Secondly
it is/will be by a mechanism similar to how you get NS records into
the TLD. In other words go ask your registrar when they are going
to support adding DS records and stop complaining here.
I am not asking about the TLD keys, I am asking about my keys.
I will repeat myself. The parent zone has DS records added to it
not DNSKEY records. Your keys are added to your zone so I presume
you know how to update your zones.
And I really hope that the mechanism for handling the name holder keys
recognizes that registering a million keys is different to
distributing a hundred where all the parties know each other
Well you know your parent or its agent (registrar). You hand the
DS to them to publish. The rest of the world gets the DS from them.
The only keys that have to be widely distributed are those for the
root zone and that's a similar problem to distributing the list of
root nameservers and their addresses. Millions of recursives server
operators have managed that.
You would not be saying "go ask your registrar when they are going to
support adding DS records" if you didn't know that the answer was that
the registrars have made no commitment to deploy.
Well pick one that does. GoDaddy does accord to reports I've seen.
There are others that also support DS records.
Holding a key signing ceremony is not a new technological achievement.
It is being held now with great fanfare in the hope that if everyone
makes enough noise about how much momentum DNSSEC has that the
opposition of the registrars will somehow disappear.
No one said it would magically fix things. It does however remove
one of the more common excuses people have been using to not do the
could of minutes work that is required to turn on DNSSEC.
I don't see why that strategy would work. I have certainly never seen
it work in the past.
We go complain to your registrar. Say you will take you business
away unless they add support and do it when they don't.
This is not a technological problem. It is a business problem
between you, your registrar and the registry.
You are an engineer. If the technology does not meet the business
needs then you have failed.
The technology is not the problem. It's getting the registrars to
change their web forms to support adding DS records. That is the
last step. EPP supports DS. The nameservers support DS. The
clients support DS.
Adding DS records is really no harder than adding NS, A and AAAA
records that are required to make a delegation work.
If DNSSEC is not going to fail we need to re-engineer it to propose a
business model that actually works. Sitting on the sidelines and
shouting 'the technology is perfect damit, go make the business model
work', is not going to solve the problem. Nor is 'go away, my
technology is perfect, perfect I tell you'.
What has me very worried here are the comments to the effect 'the
registrars are behind'. What if the registrars are not 'behind', what
if they have no interest in deployment or are actively opposed but
unable to say so openly while Cerf and co are saying that DNSSEC is
the historic solution to solve the problem of Internet security?
Except they arn't all against it. Some have already started accepting
This is not a trivial issue. There is a question of liability to be
addressed. So far ICANN and VeriSign Registry Services have addressed
the issue by booting it down the chain. But the system as a whole
cannot work until there is someone willing to accept the liability and
for that to happen they are going to require tools to manage their
How is the liability different from that of accepting NS records?
DS records don't magically change the liability. Stuffing up either
NS or DS records will break the delegation.
Yes they do.
An NS record specifies the address of the DNS server
No. It specifies the NAME of a nameserver. A/AAAA records specify
A DS record specifies an intermediate certificate in the chain of
trust for authenticating any entity that is attached to the domain.
And a registrar should be treating changes to NS, A, AAAA and DS
records with a equal level of respect. They shouldn't be accepting
changes from anybody. They should already be doing the level of
checking needed for DS records for NS, A and AAAA changes. Afterall
stuffing up any of these will break the delegation / allow it to
In the case of an NS record it is established that the design does not
provide security in the DNS layer and this has to be provided
independently via an end to end mechanism such as SSL with DV or EV
You are confusing the trust level needed to add/change records to
the database to that of the transport used to retieve data from the
In the case of a DS record the design is expressly designed to provide
for authentication of assertions relating to a domain name distributed
through the DNS.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
Ietf mailing list