Martin Rex wrote: > What DNSsec will provide is what is described in rfc-4033 section 3.1 > data origin authentication and data integrity protection. That is already offered with plain old DNS with UDP checksum, cookie and return routability, though UDP checksum is optional and cookie of message ID is a little bit too short. > In order to obtain any level of "trust", you would not only have > to configure the keys for specific zones that you trust, > but also create an out-of-band trust relationship > (person-to-person, audit) of the registry administrating the > relevant DNS-zones you want to trust, their equiment and > adminstrative procedures, > > *PLUS* > > you will need to create an out-of-band trust relationship to > the adminstrator(s) who operate(s) the server(s)/service(s) > for which you want to resolve the names through DNSsec and > their network admins and the operational procedures that they use. > > That might be a time-consuming, expensive and error-prone effort > that by itself get outdated, and it scales nowhere considering > the size of the DNS. Right. So, DNSSEC is no better than plain old DNS. > I have set up my DSL router to register the IP assigned by the ISP > with dyndns.org (builtin feature of the DSL-router). But whenever > the connection is dropped, that DNS entry with dyndns.org is > inaccurate until my router re-connects and updates it with the new IP. It partially is a problem of unnecessarilly long TTL, which means poor administration of related zones. That is, DNS is not fully responsible for the problem. However, it is almost certain that the zones will have poor administration and, thus, poor security even if DNSSEC were deployed. Masataka Ohta _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf