Date: Wed, 27 Aug 2008 09:22:40 -0700
From: Michael Thomas <mike@mtcc.com>
Kevin Oberman wrote:
>> Date: Tue, 26 Aug 2008 16:53:24 -0400
>> From: "Bill Bogstad" <bogstad@pobox.com>
>>
>> Not sure what this will actually mean in the long run, but it's at
>> least worth noting.
>>
>> http://www.gcn.com/online/vol1_no1/46987-1.html
>> http://www.whitehouse.gov/omb/memoranda/fy2008/m08-23.pdf
>
> It will mean something in the medium term as '.gov' and '.org' will be
> signed very soon and OMB might be able to even get the root
> signed. (Since OMB can pull funding, no one argues with them much.)
> All of this will increase pressure on Verisign to deal with '.com' and
> '.net'.
>
> Note that this only has an impact on '.gov' and the zones immediately
> below it, but I suspect most sub-domains of *.gov will be signed as a
> result of this, even if it is not required.
So the question I have is... will operators (ISP, etc) turn on DNSsec
checking? Or a more basic question of whether you even _could_ turn on
checking if you were so inclined?
As far as I can see, at least with bind-9.5, operators would have to
turn it off. It looks to me like dnssec-validation defaults to on. It
also appears that bind-9.4 defaults to 'off'.
Right. The real questions are the clients and the trust anchor -- what
root key do you support?
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Steven M. Bellovin wrote:
So the question I have is... will operators (ISP, etc) turn on
DNSsec checking? Or a more basic question of whether you even
_could_ turn on checking if you were so inclined?
As far as I can see, at least with bind-9.5, operators would have to
turn it off. It looks to me like dnssec-validation defaults to on. It
also appears that bind-9.4 defaults to 'off'.
Right. The real questions are the clients and the trust anchor -- what
root key do you support?
A distributed one. I personally don't really see an issue with
downloading a public key for every TLD out there. These keys could come
in a pack even by an OS distribution, nicely PGP signed et all...
Nobody in his right mind manages this per box anymore anyway, and
packages for distributions and auto-updates are well-present anyway.
The presence of a key file can also mean to the resolver that one
can/has_to check dnssec results.
Greets,
Jeroen
Jeroen Massar wrote:
Steven M. Bellovin wrote:
So the question I have is... will operators (ISP, etc) turn on
DNSsec checking? Or a more basic question of whether you even
_could_ turn on checking if you were so inclined?
As far as I can see, at least with bind-9.5, operators would have to
turn it off. It looks to me like dnssec-validation defaults to on. It
also appears that bind-9.4 defaults to 'off'.
Right. The real questions are the clients and the trust anchor -- what
root key do you support?
A distributed one. I personally don't really see an issue with
downloading a public key for every TLD out there. These keys could come
in a pack even by an OS distribution, nicely PGP signed et all...
Nobody in his right mind manages this per box anymore anyway, and
packages for distributions and auto-updates are well-present anyway.
The presence of a key file can also mean to the resolver that one
can/has_to check dnssec results.
Heh, maybe you could manage root key update like any other security
alert/update on your host OS... Of course embedded frobs that don't
auto-update like, oh say, your favorite router could be problematic.
And I'd assume that those key parts of the infrastructure are probably
not too keen on trusting their upstream resolver to do the checking
for them.
In any case, the point of my first question was really about the
concern of false positives. Do we really have any idea what will
happen if you hard fail dnssec failures? If I were running a large
site, I'd want to monitor the failures for a while. If nothing
else, dnssec is a complicated beast and bakeoffs can only flush
so many bugs out.
Mike
Of course embedded frobs that don't
auto-update like, oh say, your favorite router could be problematic.
You have a router that supports DNSSEC that can't be made to do some form of auto-update?
In any case, the point of my first question was really about the
concern of false positives. Do we really have any idea what will
happen if you hard fail dnssec failures?
As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In the caching servers I'm familiar with, if a name fails to validate, it used to be that it doesn't get cached and SERVFAIL is returned. Maybe that's been fixed?
Regards,
-drc
David Conrad wrote:
In any case, the point of my first question was really about the
concern of false positives. Do we really have any idea what will
happen if you hard fail dnssec failures?
As far as I'm aware, there is no 'soft fail' for DNSSEC failures. In the caching servers I'm familiar with, if a name fails to validate, it used to be that it doesn't get cached and SERVFAIL is returned. Maybe that's been fixed?
Sure, but my point is that if DNSsec all of a sudden has some relevance
which is not the case today, any false positives are going to come into
pretty stark relief. As in, .gov could quite possibly setting themselves
up for self-inflicted denial of service given buginess in the signers,
the verifiers or both.
Given how integral DNS is to everything, it seems a little scary to just
trust that all of that software across many, many vendors is going to
interoperate at *scale*. It seems that some training wheels like an
accept-failure-but-log mode with feedback like "your domain failed"
to the domain's admins might be safer. At least for a while, as
this new treadmill's operational care and feeding is established.
Mike
Michael,
Sure, but my point is that if DNSsec all of a sudden has some relevance
which is not the case today, any false positives are going to come into
pretty stark relief.
Yep.
As in, .gov could quite possibly setting themselves
up for self-inflicted denial of service given buginess in the signers,
the verifiers or both.
Given how long the signers and verifiers have been around, I suspect a more likely failure mode is folks running caching servers forgetting to update trust anchors and/or signers forgetting to resign before the validity period expires. However, bugs do happen...
Given how integral DNS is to everything, it seems a little scary to just
trust that all of that software across many, many vendors is going to
interoperate at *scale*. It seems that some training wheels like an
accept-failure-but-log mode with feedback like "your domain failed"
to the domain's admins might be safer. At least for a while, as
this new treadmill's operational care and feeding is established.
I agree and I know for certain this has been suggested in the past for at least one of the validating caching servers. However, I gather this hasn't been implemented....
Regards,
-drc