John C Klensin <[EMAIL PROTECTED]> wrote: > > We have tried variations on "look over here (e.g., in the DNS) > to see, definitively, if something is available over there > (e.g., some service)" several times, with similar results. > Those results closely parallel discoveries in [other] areas of > computer science (see e.g., Ed Codd's original paper on > relational database models). If one has two different, but > intimately related, pieces of information that are stored in > different places and often maintained by different people in > different roles, things _will_ get out of synch and to bad > effect. Often it doesn't even require different people -- it is > just too hard to keep track when things need to be updated in > different types of systems.
++observation > Like it or not, there is a big difference between using the DNS > to advertise the availability or location of a service and > believing that the absence of information in the DNS is a > definitive indication that the service doesn't exist at that > node. This is such a good statement of the issue that I can't resist responding to it. I don't recall ever seeing a consensus on which of these we _want_ email to be. Clearly, when we write email to <[EMAIL PROTECTED] we intend it to go to that "machine" _if_ it supports SMTP. (If whatever server answers on port 25 of that interface doesn't know what to make of such an address, it is at least _the_ best authority on what to do with it.) IMHO, when we write email to <[EMAIL PROTECTED]> we want it to go to an appropriate server for the _domain_ IBM.com. If there happens to be an A)ddress record for IBM.com, that really isn't where we want it to go; and we trust IBM.com to do the right magic in DNS to ensure it instead goes to an "official" SMTP server. That, IMHO, is the perfect example of what John K is saying: that this sort of DNS magic _will_ get out of sync. Thus, IMHO, we are ill-advised to design an email system which depends upon it staying in sync. It is easily demonstrated that many cases exist where an A)ddress RR gets out of sync, and points to some "machine" which has no clue what to do with email addressed to that domain -- _whether_or_not_ it happens to listen on port 25. Whatever error it may _or_may_not_ return is unlikely to be helpful to someone trying to send email to that domain. Thus, IMHO, we SHOULD clearly state that <[EMAIL PROTECTED]> means the email is intended for the _domain_ example.com; and that if the DNS gets out of sync with the routing, the _DNS_ is authoritative, not the routing. (That still leaves us an opportunity to argue whether the absence of an MX record indicates the absence of an official email service, BTW...) > It will be that way until and unless we redesign the network > architecture to treat the DNS as part of TCP or IP such that, > e.g., the act of turning on a listener for a particular service > is the act that creates corresponding records in the DNS. John K is baying at the wrong moon, IMHO. Turning on a process listening on port 25 is quite a different matter than deciding that you want email coming to a domain. Neither can I imagine any case in which it would make sense to automatically advertise an MX RR when a port 25 service is detected. (I can barely imagine any _way_ to do this!) > That is the message in the failure of WKS as a definitive > service-availability indicator and what I was trying to point > you to when I pointed you to 1123. (I include this only to avoid a charge that I quoted John K out of context: it's quite unrelated to any point I intended to make.) -- John Leslie <[EMAIL PROTECTED]>
