ietf
[Top] [All Lists]

Re: Proposed DNSSEC Plenary Experiment for IETF 74

2008-11-27 15:53:32
[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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>