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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf