[As entertainment for the audience, I am sure everyone will enjoy
seeing my brother and I take opposite sides in this discussion.
Enjoy ;) ]
I too have been watching this thread but from the vantage of having
been deeply involved in DNSSEC deployment and, more specifically, as
one of the people urging deploying DNSSEC at the IETF meetings. This
thread began with Russ Housley sending a brief message yesterday:
I have been approached about a plenary experiment regarding
DNSSEC. The idea is for everyone to try using DNSSEC-enabled
clients during the plenary session. I like the idea. What do
others think?
There was actually considerably more context behind this note, and
it's perhaps unfortunate the thread has lurched off in a negative
direction.
I can't speak for the IAOC or others involved in the mechanics, so
the following is my best understanding -- and also what I recommend
-- of what's intended.
There are three distinct elements of what's being planned.
1. Signing of the ietf.org zone
2. Providing a DNSSEC-compliant recursive resolver as part of the
IETF net at the next IETF meeting.
3. An experiment during the plenary.
Russ's note initiated discussion of this last piece without setting
the context with the first two pieces. Let me say a few words about
each piece.
1. Signing ietf.org
Quite a few zones are already signed, and some top level domains,
Sweden (.SE), Bulgaria (.BG), Peurto Rico (.PR), Brazil (.BR), The
Czech Republic (.CZ), and .MUSEUM, are in full DNSSEC operation.
Many of us are running signed zones below the top level, and there is
already a decision and commitment for the key zones related to the
IETF to be signed.
Based on the discussions I heard during the last IETF, the plan is to
sign ietf.org immediately after the parent zone, .ORG, is signed. I
would prefer for the signing of ietf.org to be independent of whether
the parent zone is signed, but that's a separate discussion. In any
case, it's my understanding that the people in charge of running
ietf.org have been tasked with getting it signed. Once signed, I
would expect it will stay in operation. That is, the timing and
operation of the signed zone don't depend on the IETF meeting and
have no direct relationship to the meeting's network.
2. Providing a DNSSEC-compliant recursive resolver as part of the
IETF net at the next IETF meeting.
The other side of the DNSSEC equation is having software that checks
the signatures. This is done by a validating resolver, either a
recursive resolver or the stub resolver. A handful of organizations,
notably Telia in Sweden, Comcast, University of California Berkeley,
and OARC are running DNSSEC-compliant recursive resolvers. I believe
the ISPs, Telia and Comcast, are providing these resolvers as
optional alternatives to the resolvers they regularly run and they
are not including the addresses of these resolvers in the DHCP
configuration parameters. Presumably they will become part of the
standard DHCP configuration at some future time.
The proposed action for the next IETF meeting is to do the same
thing. That is, the IETF network will include a DNSSEC-compliant
recursive resolver as an additional service which is not included in
the list of DNS servers returned during the DHCP process.
All of the above should invisible unless the end system explicitly
invokes the DNSSEC-compliant recursive resolver AND asks for a signed
response.
3. An experiment during the plenary
I have not been involved in a discussion of this third piece, but I
presume the intent is to simply include the DNSSEC-compliant
recursive resolver in the standard DHCP configuration during the
plenary. That is, during the plenary, DHCP responses will include
the DNSSEC-compliant recursive resolver. Even though the normal DNS
requests will thus go through the DNSSEC-compliant recursive
resolver, the end system will see no difference unless the end system
asks for a a signed response. I believe Russ was essentially asking
what people think about this third piece of the plan. (Apologies,
Russ, if I have incorrectly channeled you.)
In line with David's note, there are indeed a lot of details to
cover, including explanatory notes on how end systems need to be
configured to ask for signed responses. measurements, etc., etc. All
normal stuff and all part of what we are more than capable of doing
all the time.
Steve
On Nov 27, 2008, at 1:03 PM, Dave CROCKER wrote:
Peter Koch wrote:
On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote:
I agree with others' views that validation alone is not very
helpful and
some frequently queried for domains' zones should be signed as
part of that
experiment. By IETF74, the IANA (I)TAR might also be available as
one
source of TLD trust anchors.
Still that date might be too early to encourage end system
validation, so
adding validation and an "interesting" set of TAs to the meeting's
recursive
name servers is another option, even if on the WLAN we can't trust
the path
between stub and recursive resolver. However, I'd hope the
limited time
did not imply the proponent(s) offered a demonstration during the
plenary ...
If I understand the thread, so far, there is a current reality that
suffers from missing too many pieces of necessary DNSSec
infrastructure, documentation, maybe software, and definitely
training. Without all of these additional pieces, it's not
reasonable to expect any sort of casual use -- even for "testing".
However it might be possible to put enough pieces in place to
exercise some interesting scenarios.
If the above is anywhere in the vicinity of correct, it would
probably be helpful to formulate an actual project plan for this,
complete with web-site, collaboration tools, etc. Absent something
organized like this, the likelihood of producing anything useful at
test-time would, apparently, be at risk.
Or am I misunderstand the disparity between current reality and
necessary enhancements?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf