>From: Keith Moore <[EMAIL PROTECTED]>
>
>> 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
