From: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
If people's livelihood depends on something, they're more likely to insure
it actually works.
that's a good point. but it's one thing to make sure that DNS mappings
for "major" services are correct, and quite another to make sure that
the DNS mappings are correct in both directions for every single host.
even the DNS names for major services may not be well maintained.
at one time I did a survey of the reasons for mail bounces
for one of my larger mailing lists. about half of the mail bounces
seemed to be due to configuration errors. about half of those
seemed to be due to DNS configuration errors - e.g. MX records pointing
to the wrong host, zone replicas not being kept in sync, zone
replicas which were different but with the same serial number.
In your view, what is it in the DNS protocol(s) that results in a lack of
reliability?
the reliability problems are mostly not the protocol...though the protocol
does have limitations if you want to use it (as some have proposed) to
support host or process mobility. and in the face of even moderate
packet losses DNS queries can take a very long time.
mainly it's the fact that DNS is maintained as a separate entity.
if you really want it to be in sync with reality, you need some
mechanisms to ensure that updates happen automagically, and/or that
configuration errors are automatically and quickly detected and
the information about the error gets to the person who can fix it.
Problems with DNS maintainance arise from fact that DNS should be
maintained manual. If we return back to routing addresses resolution
it can be deployed on maintainless basis because all needed information
already concentrated in routers. There is not any human-like names here
and allocation of route addresses may be done automatic (on tree base
strategy from some root point in network).
- Leonid Yegoshin, LY22