Jed: > On Tue, 19 Mar 2002 13:35:45 -0700 (MST) > Jim Ockers wrote: > > So consider how the DNS might work for an IP address. Let's say that > > you wanted to send an e-mail to person@2.3.4.5 . Would "5" be the top- > > level domain? How is your mailer supposed to walk the DNS tree to > > find the MX for a subdomain in the "5" domain? (AFAIK single numbers > > are not valid top-level domains; you can use .COM .NET .ORG .US etc. but > > not numbers.) > Speaking from total ignorance of the relevant RFCs, I can only assert that > a dotted-quad shouldn't require a walk down the DNS lane, or up it's tree, > as the case might be. I mean, traceroute happily notices that I've given > it an IP address, instead of a server name, and scoots right along. We'd > be in a world of hurt, wouldn't we, if we couldn't tell whether > 207.217.96.29 was an IP address or a domain name? This is easy for you to say. There is no guarantee that this will always be the case. Consider the following IP address: CF.D9.60.1D That is the same IP address as you give in your example, but using hexadecimal numbers. I've seen it done and in fact many kernel data structures etc. represent the IP address in hexadecimal. There is no ruleset that you could make that would make sense and would work all the time for software to recognize an IP address and be able to always distinguish it from a domain name. Just because you are used to things being a certain way right now doesn't mean they are always going to stay this way. For instance, "1d" is not a valid top-level domain right now but it could become one in the future. (There is no technical reason why it could not be a top-level domain, you see.) Furthermore, in your example "29" would need to be the top-level domain. Again, there is no technical reason why "29" could not be a top-level domain (that I know of, anyway). Who is to say that it might not become a TLD in the future? The mail software is designed for maximum compatibility with the standards in use now and perhaps the standards that might be in use in the future. (As well as fault tolerance.) This means a compromise and perhaps some lowest-common-denominator functionality, which seems to be the core of your argument. Also, traceroute takes an IP address or a hostname-that-resolves-to-an- IP-address as an argument, and it has only one main function. E-mail is vastly more complex an application. > > Remember that in the DNS, IP addresses are actually represented in the > > inverse notation - ie.e, "5.4.3.2.in-addr.arpa" would be the domain. > > It is possible to put MX records in the inverse zone files for the DNS > > for inverse domains, i.e., the "5" record in that inverse zonefile could > > have an MX record pointing to itself. Then you could send an e-mail to > > person@5.4.3.2.in-addr.arpa if you wanted to. (Assuming that the mail > > program on that system was configured to recognize that domain name as > > well.) > > > > In practice it is very unusual to find MX records in the inverse zones > > since everybody uses the domain name. > > > > The integration of sendmail (and internet mail in general) with the DNS > > is by design. It was not just an arbitrary decision on the part of some > > software developers - that's actually how it is supposed to work. > > > > If you don't want to use the DNS you can just telnet to port 25 on the > > server and send some SMTP commands. > The application design of most (all?) MTAs to use DNS to find the MX is > completely understandable, and sensible. What a mess we'd have if we > needed to know the server name where Joe-Bob receives e-mail. That used to Or perhaps the IP address of the server where Joe-Bob receives e-mail!! > be the case, and I fondly ;-) [if vaguely] remember some of the strange > routing notations necessary for getting mail through various protocols and > gateways. I think some of that syntax is probably still valid, if one > knows how to assemble the proper incantations, although perhaps not using > purely SMTP. There were exclamation points and percent signs, IIRC. > However, to have internet e-mail wholly reliant on DNS seems a poor > decision as well, since DNS problems are possible. As Charlie and Kevin Actually most DNS problems are due to mis-configured DNS zones (or incom- petent DNS or network administrators). The DNS is actually a major Internet success story in terms of scalability, fault tolerance/reliability, and functionality. In general the DNS works really well. > have pointed out, one can get around the DNS lookup. In my case, I didn't > feel it was enough of _my_ problem to warrant calling somebody in > Berkeley, CA. But being able to send mail to postmaster@[n.n.n.n] to say, > "Hey, e-mail to this domain is broken because DNS doesn't resolve.", seems > entirely reasonable. Hopefully they will eventually notice if they broke their DNS. Microsoft had a bad day a year or two ago when their DNS servers all went offline because they were all on the same subnet and some guy screwed up the routing to that subnet. You can bet that they won't do that again. > I don't really understand the MX records in inverse zones thing, and I'm > not at the point of wanting too. But then, I'm still stuck on the notion > of being able to use the actual mailserver name or IPA, when necessary, so > I wouldn't want to use a DNS lookup for an MX record in that case. I bet you did a DNS lookup to get the IP address of the host that is supposed to handle the mail? Unless you already knew it for some reason. -- Jim Ockers (ockers@ockers.net) Contact info: please see http://www.ockers.net/ Fight Spam! Join CAUCE (Coalition Against Unsolicited Commercial Email) at http://www.cauce.org/ .