是一个通配DNSlogging不好的做法？

如果你曾经把计算机放在这个域中，你将会遇到奇怪的DNS失败，当你试图访问互联网上的一些随机站点时，你会到达你的。

考虑：您拥有域example.com 。 你build立你的工作站并命名它。 …让我们说， yukon.example.com 。 现在你会注意到在它的/etc/resolv.conf有这样一行：

 search example.com 

这很方便，因为这意味着你可以对主机名进行查找，例如www ，它将自动为你自动searchwww.example.com 。 但它有一个阴暗的一面：如果你访问，比如Google，那么它将searchwww.google.com.example.com ，如果你有通配符的DNS，那么这将parsing到你的网站，而不是到达谷歌你会结束自己的网站。

这同样适用于您运行您的网站的服务器 ！ 如果必须调用外部服务，则主机名查找可能会以相同的方式失败。 因此， api.twitter.com突然变成api.twitter.com.example.com ，直接返回到您的网站，当然失败。

这就是为什么我从不使用通配符DNS。

是一个通配DNSlogging不好的做法？

就个人而言，我不喜欢它。 特别是在那个领域有机器的时候。 错别字没有经过检查，错误不太明显……但没有什么根本的错误。

我发现唯一的负面是有人可以链接到我的网站使用http：//i.dont.like.your.website.mywebsite.tld 。

让你的http服务器将所有这样的请求redirect到正确的规范地址，或者根本不回应。 对于nginx来说就像这样 ：

 server { listen 80; server_name *.mywebsite.tld; return 301 $scheme://mywebsite.tld$request_uri; } 

然后是正常的

 server { listen 80; server_name mywebsite.tld; [...] } 

这全是意见。 对我来说这不是一个坏习惯。

我正在创build一个多租户应用程序，每个租户使用一个数据库。 然后根据子域select要使用的数据库。

例如milkman.example.com将使用tenant_milkman数据库。

像这样，我已经为每个租户分开了表，比如tenant_milkman.users ， tenant_fisherman.users ， tenant_bobs_garage.users ，在我看来，这对于这个特定的应用程序来说更容易维护，而不是让所有公司的所有用户同一张桌子。

[edit - Michael Hampton has a good point]

这就是说，如果你没有特定的理由接受任何（可变）子域，就像我一样，那么你不应该接受它们。

这里的另一个问题是SEO：如果所有显示相同内容的* .domain.com，您的网站将被严重引用，至less由Google（ https://support.google.com/webmasters/answer/66359 ）引用。

这是一个坏主意，假设你想在一个Web服务器上托pipe一个子域a.company.com，在另一个web服务器上托pipeb.company.com，可能是另一个ISP。 你会做什么 ？。 所以通配符DNS不是一个选项，应该是精确的，为每个子域创build一条logging并指向相关的IP。 有可能将您的Web服务器从一个ISP移到另一个ISP，在这种情况下，您会做什么？

是一个通配DNSlogging不好的做法？

不，和其他人相反，我认为这是好的做法。

大多数互联网用户在某个时候粗暴地指出一个DNS名称。 他们将inputww.mycompany.com或wwe.mycompany.com你会发生什么，“哎呀，我们无法find该网站”或他们拉你的主要主页？ 更多的时候，让他们拉起你的主页是比较好的。 这是很多人做的事情。

即使有人把一个链接到i.dont.like.your.website.whatever.com它仍然会拉起你的主页，这实际上是你想要的。 毕竟，他们不能让该网站去他们的服务器，你仍然控制DNS路由，所以它去你的。

我认为最好不要有一个通配符DNSlogging的原因是为了避免将您的服务器IP地址泄露给潜在的攻击者，并减less对DDOS攻击的说明。 这也是Cloudflarebuild议的设置： https ： //blog.cloudflare.com/ddos-prevention-protecting-the-origin/