Armed Polite Society
Main Forums => The Roundtable => Topic started by: tyme on October 22, 2010, 11:59:09 AM
-
background:
no-www (http://no-www.org/)
yes-www (http://webcache.googleusercontent.com/search?q=cache:vrP6mIGyTOQJ:www.yes-www.org/www-is-not-deprecated/+yes-www)
-
www prefix only because that is what everyone is used to. If you deviate from that expect to have loads of questions from folks that cannot figure out how to get to the site or complaints that it is down.
There is also nothing stopping someone from making both of them work.
-
I favor owning a domain, then creating hosts inside that domain.
www.foo.com
mail.foo.com
db1.foo.com
-
@41mag As no-www says (they call it class C no-www), making www.foo.com not resolve is not feasible for public websites.
No-www is mostly about (class A) first making sure http://foo.com gets to the same website as http://www.foo.com does, and then (class B) making www.foo.com redirect to foo.com.
-
I get annoyed by the hubris of DNS administration, thinking it all has to do with http requests.
The internet does a LOT more than serve web pages. DNS is used for that, as well.
My ISP (Cox) has DNS servers that are so arrogant, they assume that any name it can't resolve is a failed HTTP request, and redirects the DNS lookup to a search server.
So, a DNS lookup to "myserver.mycompany.local" (a non-existent domain on the public internet, but visible from my split-tunnel VPN connection) will result in their DNS server returning the IP address of their search server.
Since my DNS servers are ordered as:
1. CoxDNS1
2. CoxDNS2
3. 10.1.1.10 (a private DNS server for my internal company, only visible when VPN is active)
I get false DNS resolutions.
I consider that DNS hijacking. A DNS query that doesn't resolve to a valid address should ALWAYS come back with a negative response, so that the client moves on to the next DNS server.
As such, foo.com might do something completely different than www.foo.com. Perhaps it's a VPN endpoint, or an FTP server. DNS-level redirection is a huge assumption to make.
-
My ISP (Cox) has DNS servers that are so arrogant, they assume that any name it can't resolve is a failed HTTP request, and redirects the DNS lookup to a search server.
That's exactly why I manually enter public DNS servers in my router's configuration. I hate the redirects many of the ISPs do.
-
@AZ that leaks internal DNS details outside of your VPN, which you probably don't want. You could list the VPN dns server first, which will result in slow lookups for common internet hosts, or you could use a local caching dns server like
pdnsd (http://www.phys.uu.nl/~rombouts/pdnsd/) or Unbound (http://www.unbound.net/) and tell it to look up your internal domains using the vpn DNS server, while ordinary dns queries get looked up recursively... nicely avoiding Cox's braindead responses.
If you're not going to do that, apparently Cox has alternate nameservers that aren't horribly broken. viz. http://blog.perfectspace.com/2008/10/03/how-to-turn-off-disable-cox-404-hijacking/
-
@AZ that leaks internal DNS details outside of your VPN, which you probably don't want. You could list the VPN dns server first, which will result in slow lookups for common internet hosts [snip]
Meh. You can't get to those boxes without the VPN active anyways. Two layers of Cisco firewall obfuscating them. if you can get into that, getting hostnames isn't going to be challenging (if you need them at all rather than a pingsweep and IP address discovery).
If you're not going to do that, apparently Cox has alternate nameservers that aren't horribly broken. viz. http://blog.perfectspace.com/2008/10/03/how-to-turn-off-disable-cox-404-hijacking/
Yep, I've got some folks doing that, and other folks with HOSTS files ( [barf]) that override the DNS lookups.
But back on topic, I just favor HTTP redirection, over DNS aliases that assume all lookups to foo.com are for HTTP requests. A small Apache/IIS instance on foo.com with a simple redirect page (automatic redirection based on a time limit) to www.foo.com appeals much more to me. Unless foo.com only consists of a small single-server presence, and www. is an alias or duplicate entry for foo.com.
-
Meh. You can't get to those boxes without the VPN active anyways.
Doesn't really avoid the problem. Leaked internal ip address / hostname info can help with planning attacks even if an attacker can't connect inside directly.
Even if you don't care about information leakage, using a local caching nameserver like unbound, and telling it to go to the internal vpn dns server directly for queries within the internal domain, will reduce internal hostname lookup times because you won't have to wait for negative responses from 3rd party dns servers.
Anyway, none of that really has anything to do with www vs no-www. So you're in favor of yes-www, that is, redirecting foo.com to www.foo.com?
-
My domain hoast, Omnis.com provides serving up my domains as either
http://herohog.com/
http://www.herohog.com/
or even
http://terri.herohog.com/