Re: MX-only domains dying?

Dennis Peterson wrote:
What is the harm in that? If you portmap a lot of domains you'll find all manner of services running on the domain.tld IP. I've always thought of the www host as being an artifact of the good old days of the web where DNS was used as part of the maintenance methodology - if you needed to service a box you switched the IP in DNS to the hot spare. With clustered systems, rr dns, proxies, and BigIP front ends that is much less common if done at all. The www, ftp, telnet, gopher, archie, etc. hostnames are pretty much meaningless/pointless now. When I host new web domains I always alias the www to the subscriber's domain, but I'd honestly rather not go to the bother.

(With out starting a vi vs. emacs style argument...)

Using service names allows you to have each respective service(s) resolve to different address(es), thus allowing you to spread services across different hosts. I.e. www can resolve to one IP (or set there of), ftp can resolve to another, while gopher can resolve to yet another. If you do not use service names, you are stuck with all services resolving to the same IP (or set there of). Sure, you could put some sort of redirection on that IP but (IMHO) that is more clunky than using service names to segregate where traffic is directed to.

If you subscribe to this belief (or hummer me for the sake of discussion) then you are forced to have the domain name resolve to the same place as the www service name does.

Now consider if you will multiple domains being set up in this fashion with the service names configured as CNAMEs to an FQDN of the host(s) that provide said service(s). If you want to move the web server to a different IP (for what ever reason) all you have to do is update the one FQDN record to reference the new IP(s). Now, if you do not use service names (or provide support for the lack of a service name) for said domains, you have to update all the DNS zones for the effected domains to the new IP address. IMHO this makes it much more likely for an error to happen.

For example, I can have the following domains set up in DNS and only have to update one record if I move the server(s).

www.domain1.tld. IN CNAME www_server.fqdn.tld.
www.domain2.tld. IN CNAME www_server.fqdn.tld.
www.domain3.tld. IN CNAME www_server.fqdn.tld.
....
www.domainN.tld. IN CNAME www_server.fqdn.tld.
....
www_server.fqdn.tld. IN A w.x.y.z

Now if you want domainN.tld to resolve to a web server you would have to have the following:

www.domain1.tld. IN CNAME www_server.fqdn.tld.
domain1.tld. IN A w.x.y.z
www.domain2.tld. IN CNAME www_server.fqdn.tld.
domain2.tld. IN A w.x.y.z
www.domain3.tld. IN CNAME www_server.fqdn.tld.
domain3.tld. IN A w.x.y.z
....
www.domainN.tld. IN CNAME www_server.fqdn.tld.
domainN.tld. IN A w.x.y.z
....
www_server.fqdn.tld. IN A w.x.y.z

In this case there would be MANY MANY more places that you would have to update IP addresses, thus making things that much more prone to being incorrect / failing.

I guess you could argue that this is more of a scalability / maintainability issue than it is an operability issue. However this is one of the smaller nuances that I see that bothers me.

If you are wondering why I have A records for domainN.tld verses a CNAME record, I have never been able to get CNAME records to co-exist with any other record type for a given name. As I understand it, this is the correct behavior for CNAMEs in DNS too. Thus you are forced to use an A record if you want to have any other type of service offered on the domain. This is especially true for email seeing as how an MX record will not reliably be correctly resolved if the MX record points to a CNAME. I suppose that if you only wanted to offer web services (or really any thing but email) for a domain, you could create a larger zone that was just the tld with something like the following:

domain1.tld IN CNAME www_server.fqdn.tld.
domain2.tld IN CNAME www_server.fqdn.tld.
domain3.tld IN CNAME www_server.fqdn.tld.
....
domainN.tld IN CNAME www_server.fqdn.tld.

Something I find maddening is browsers that have a round robin set of alternate URL's they will go through if you mistype a domain, or if what you type doesn't exist, and then finally land you on a default URL at, oh, say, microsoft.com. It might as well be a web beacon, as it provides information to the default server things you may rather it not know.

I find this both good and bad. In my experience the round robining as you say tends to try the six combinations of "(|www).<domain_you_typed>.(com|net|org)" in addition to <domain_you_typed> if the latter fails. Yes it is possible that some information may be given away by the fact that you are trying to reach something that does not exist and that the browser inadvertently tries a permutation of the domain name as a convenience. If one of these permutations is valid, some information could be handed off to the per mutated server, i.e. you were trying to get to a domain that is a per mutated form of what was requested. This can be used to gather statistics or typo squatting, etc. However I do like the fact that it will prepend "www" in front of just the domain name, usually first. IMHO the prepending of "www" helps me in my quest to use service names and have some support for lazy people that do not want to type in four more letters.

(Ok, I'm getting off my soapbox now.)



Grant. . . .

.

Relevant Pages

  • Re: Beating the spam filter ...
    ... touch on the matter agree that pointing an MX at a name that has a CNAME ... of abstraction for the host name of mx.hosting-company.tld such that they ... to a pool with out the need to update all the client DNS zones. ... It is dead wrong to have multiple CNAME records for one name. ...
    (comp.mail.sendmail)
  • Re: CEICW after loading third party certificate
    ... I've been known to disagree with Dr Tom however, yes, the one remaining part of the puzzle is DNS in/outside the LAN. ... ISA, unlike most commodity routers, doesn't really care if references to ourname.domain.com resolve to its internal or external IP. ... The requests will be handed to ISA anyway and processed through forward/reverse proxy by the actions of the ISA Firewall Client, which should be on all ISA client PCs. ... So we create a DNS ZONE (not host) for ourname.domain.com to point to the IP address. ...
    (microsoft.public.windows.server.sbs)
  • Name resolution in .Net - arrrrrggghhhh!
    ... "The Resolve method queries a DNS server for the IP address associated ... "When hostName is a DNS-style host name associated with multiple IP ... documentation, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Beating the spam filter ...
    ... Now consider if you will the desire of the hosting company to have a level of abstraction for the host name of mx.hosting-company.tld such that they can freely move the SMTP service from host to host, or add additional hosts to a pool with out the need to update all the client DNS zones. ... Thus the hosting-company uses a CNAME for mx.hosting-company.tld to reference the back end SMTP servers that they want their clients to use at the time. ... It is perfectly reasonable to have multiple names with A records resolving to the same address. ...
    (comp.mail.sendmail)
  • Re: Beating the spam filter ...
    ... alias and the alias is listed in the MX records for REMOTE. ... Or are you referencing the fact that a CNAME should be the only RR for the given name of the CNAME RR? ... Now consider if you will the desire of the hosting company to have a level of abstraction for the host name of mx.hosting-company.tld such that they can freely move the SMTP service from host to host, or add additional hosts to a pool with out the need to update all the client DNS zones. ... To accomplish such with out using CNAMEs, mx.hosting-company.tld would have to use A recordthat resolve to the IP addressof the current mail server. ...
    (comp.mail.sendmail)