On Nov 26, 2008, at 10:05 AM, John C Klensin wrote:
I also assume those clients will be performing validation
against a signed root zone,
Sure, if they configure their trust anchor according to
https://ns.iana.org/dnssec/status.html
(There are other testbeds too, but I don't recall where to dig up
their trust anchors)
signed ORG,
Might be in limited testing by the next IETF -- I don't remember
offhand the schedule of when ORG was going to be signed...
COM,
Won't be ready by the next IETF so I understand.
and several national ccTLD zones,
Yep: SE, BR, PR, BG, & CZ at this point. And, of course: MUSEUM and
the test IDN TLDs. Might be more by the next IETF. Also, if you're
using the ns.iana.org IANA testbed, you'll also get INT, ARPA, and
ARPA children.
Do you have a plan about who is going to supply the low-velocity
flying pigs for this meeting? Perhaps we could get them to
listen for DNS queries and cache and transport responses.
Unnecessary. All it would take would be for the folks who set up the
caching servers to configure the appropriate root (or TLD) trust
anchors. It isn't really that hard. I've been doing it on my laptop
now for over a year.
Of course, the real issue is whether or not anyone would actually
notice. The vast majority of folks (the ones who get the IP addresses
for their caching servers via DHCP) would see absolutely no change
unless there is a validation failure, in which case they'll get back a
SERVFAIL response which will likely be interpreted as 'host not found'.
Sorry for the sarcasm, but some operational reality would be a
good idea for ideas like this.
The operational reality is that folks are deploying DNSSEC and there
are even folks who are validating responses with it. Turning on
DNSSEC in the IETF-supplied caching servers should probably be the
default. Any reason not to?
Regards,
-drc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf