创build本地主机的logging

创build指向本地主机的logging时,最佳做法是什么? 这是否被认为是禁忌或者是否有一些可以允许的有效案例?

我有十几个我设置“本地”的域名。 指向127.0.0.1的子域在本地开发链接到这些域的Web应用程序时有所帮助。 我和我的团队中的其他开发人员经常必须在本地主机上使用多个站点,并且在URL中引用IP或在主机文件中保留域的本地映射会导致混乱,并且随着时间的推移难以维护。

所以我认为将这些注册为子域名将是一种为每个人提供快捷方式的快捷方式。 它做到了。 它工作了几个星期,然后突然停止工作。 所以我login了我的提供商的DNS控制,果然,所有的“本地”。 logging已被删除。

我的主人是Godaddy。

在Godaddy上核发未经我许可修改我的DNSlogging之前,有没有合法的理由来删除它们? 他们是否认为这是某种安全问题或违规? 一般来说,Godaddy只是一个糟糕的公司,但是切换DNS提供商并不是我名单上的一个难题。 这是我应该合法生气的吗?

虽然也许有点奇怪,但我不知道任何具体的标准或规范,一般禁止在公共DNS中做这样的事情。 GoDaddy平台在使用环回地址时可能会引起某些问题,也可能是因为“非标准”或“奇怪”而被删除。

如果这些机器都在同一个networking上,并且不离开它,那么你可以在内部DNS上创build这些logging吗?

如果我不得不猜测,这可能是一个错误的努力,以防止交通reflection。 以下面的例子:

$ORIGIN example.com. stophittingyourself IN NS ns1.stophittingyourself ns1.stophittingyourself IN A 127.0.0.1 

如果我要发送一个查询noreally.stophittingyourself.example.com. 到一个recursion的DNS服务器,它将遵循引用链并尝试查询127.0.0.1:53。 实际上有一个本地主机监听器的可能性很高,在大多数情况下,最终的结果是服务器正在与自己通话。 这将不可避免地导致可caching失败…但是每当你改变了somethingelse ,就必须按照RFC分别caching失败。

最终的结果是127.0.0.1引用可以比指向一个不响应或不权威的随机IP更有效地浪费资源。 试图在这一层防止它是奇怪的 ,特别是因为它是更有意义的受害者宣布一个networking,它不应该沟通权威的数据(包括127.0.0.0/8),但这从来没有阻止一个企业用手指引用“安全”的名义做傻事。


半相关正切:如果您运行recursionDNS服务器,并且从未想过以这种方式使用引用来引导stream量,则可能需要了解如何configurationDNS软件以忽略这些引用。 虽然防火墙也可以在这里帮助,但我保证,如果您处理客户stream量,环回接口上的数据包计数器将会更安静。

基于BIND的例子:

 # refuse to loop back on ourself server 203.0.113.0/24 { bogus yes; }; server 127.0.0.0/8 { bogus yes; }; server 0000::/3 { bogus yes; }; server fe80::/16 { bogus yes; }; server 169.254.0.0/16 { bogus yes; }; # refuse attempts to funnel requests into private/backbone space server 172.18.53.1/32 { bogus no; }; # whitelisting example server 172.18.53.2/32 { bogus no; }; # whitelisting example server 192.168.0.0/16 { bogus yes; }; server 10.0.0.0/8 { bogus yes; }; server 172.16.0.0/12 { bogus yes; }; server 100.64.0.0/10 { bogus yes; }; 

指向127.0.0.1的Alogging是安全风险,因为它会使XSS攻击成为可能。 更多信息: http : //www.securityfocus.com/archive/1/486606/30/0/threaded