我的puppet.conf在主人身上

[master]
certname = myname.mydomain.com
ca_server = myname.mydomain.com
certdnsnames = puppet;puppet.local;myname.dyndns.org;hivemind.local;

对于我对定义的certdnsnames的理解,以下应该有效：

puppet agent --server myname.dyndns.org --test

但我收到以下错误：

err: Could not retrieve catalog from Remote Server: hostname was not match with the server certificate

如何避免这个错误？如何正确定义certdnsnames？我找到了关于此的不同文档,但没有简单的例子.我使用“,”分开,我根本无法签名.
我也看过像这样的语法

certdnsnames = puppet:puppet.intra.myserver.fr,puppet.myserver.fr:puppet,puppet:puppet,puppet.intra.myserver.fr,puppet.myserver.fr

http://projects.puppetlabs.com/issues/5776

但对于我来说,还不清楚何时添加“傀儡：”而不是.

为了任何偶然发现这个答案的人的利益：

由于CVE-2011-3872,Puppet不再支持certdnsnames选项.从文档：

The certdnsnames setting is no longer functional,after CVE-2011-3872.
We ignore the value completely. For your own certificate request you
can set dns_alt_names in the configuration and it will apply locally.
There is no configuration option to set DNS alt names,or any other
subjectAltName value,for another nodes certificate. Alternately you
can use the –dns_alt_names command line option to set the labels
added while generating your own CSR.

您可以使用subjectAlternativeName为您的服务器生成SSL证书,如下所示：

$puppet cert generate <puppet master's certname> --dns_alt_names=<comma-separated list of DNS names>

在研究如何在我们的网络中设置一些静态DNS-SD服务时,我遇到了 http://www.dns-sd.org/ServerStaticSetup.html,其中指出Active Directory的DNS服务器不支持带有空格的DNS名称.

有谁知道这是否仍然是真的(因为页面感觉相当陈旧)？

更新：我主要是指PTR和SRV记录,而不是A / CNAME记录.

域名可以包括0到255范围内的任何二进制八位字节.

但是,如果AD条目表示主机名,则空格不是有效字符.主机名(即指向A或AAAA记录的域名)必须遵循RFC 1123中的规则,这基本上将合法字符限制为LDH(“字母数字连字符”).

因此,对于其他条目,MS完全可能误解了RFC.他们不会是第一个,他们肯定不会是最后一个.

参考

§5.1的07：

Quoting conventions allow arbitrary characters to be
stored in domain names.

和§6.1.3.5. RFC 1123：

The DNS defines domain name Syntax very generally — a string of labels each containing up to 63 8-bit octets,separated by dots

和RFC 2181第11号：

any binary string whatever can be used as the label of any resource record

假设我已经使用bird在我的内部网络上设置了一对任意DNS服务器,他们只是在谈论我的核心路由器的OSPF.我在互联网上找到了 this并实现了它.

如果我设置一个比另一个更高的成本路径,那么,我只是做了一个可爱的方法来做故障转移而不会导致我的客户从resolv.conf中的一个主机切换到另一个解析器时的任何超时他们的resolv.conf.

但这对我来说还不够好.我想在我的DNS服务器之间分配负载.因此,我将两者的成本设置为相同,因此路由器现在应该执行ECMP并将50％的请求发送到另一个和50％的请求.

但事实证明我的企业在我们DNS的很大一部分上使用TCP – 假设我们拥有巨大的SRV记录,我们使用DNSSEC因为我们很棒.

现在,我如何设置我聪明的任播设置,以应对TCP请求需要3或4个数据包来完成请求的事实,现在这3个数据包中的一个总是会转到错误的路由器并获得tcp连接重启.

那么,在这样的方案中你可以阻止无效会话的RST响应,不是吗？ :)或(甚至更好),不要将其传递给服务：

– 无效状态？

– 没办法,试试another吧！

P. S.是的,我非常喜欢我在评论中给你的链接“TCP Anycast – Don’t believe the FUD – nanog”.

我试图更好地理解DNS,但我仍然没有完全获得A和NS记录.

据我所知,A记录告诉哪个IP地址属于(子)域,到目前为止我仍然清楚.但据我所知,NS记录告诉哪个名称服务器点属于(子)域,并且该名称服务器应该告诉哪个IP地址属于(子)域.但是,这已在同一DNS文件中的A记录中指定.那么有人可以向我解释NS记录和名称服务器究竟做了什么,因为我可能理解错误.

编辑：据我所知,NS记录告诉您要找到具有某个域的A记录的DNS服务器,A记录会告诉您哪个IP地址属于某个域.但是将A和NS记录放在同一个DNS文件中的用途是什么？如果某个域已有A记录,那么为什么需要指向另一个DNS服务器,这可能会给你相同的信息呢？

虚构的foo.com区域文件中的一些示例

....... SOA record & lots more stuff .......
 foo.com.      IN        NS        ns1.bar.com.

 foo.com.      IN        A         192.168.100.1
 ....... More A/CNAME/AAAA/etc. records .......

记录=“名为foo.com的主机位于地址192.168.100.1”NS Record =“如果您想了解foo.com区域中的主机,请询问名称服务器ns1.bar.com”

有人可以通知,请对这两种方法的差异和优缺点作出冗长的答复吗？

我不是DNS专家,不是程序员.我对DNS有一个很好的基本理解,并且有足够的知识来理解kaminsky bug之类的工作原理.根据我的理解,DNSCurve具有更强的加密功能,设置起来更简单,并且是一个更好的解决方案.

DNSSEC不必要地复杂并且使用可破坏的加密,但是它提供了端到端的安全性,而DNSCurve则没有.但是,我读过的很多文章似乎都表明端到端的安全性没有什么用处,也没什么区别.

那么这是真的吗？哪个是更好的解决方案,或者每个的缺点/优势是什么？

编辑：

如果有人可以解释通过加密消息内容获得的内容,当目标是身份验证而不是机密性时,我将不胜感激.

密钥是1024位RSA密钥的证据是here.

DNSCurve为DNS数据包提供实际加密,虽然只是逐跳,特别是在递归服务器和权威服务器之间的跳跃上.

在该路径上使用时,它可以提供区域数据的身份验证.但是,下游的任何客户端都无法从此身份验证中受益,因为安全性只是“逐跳”.位于解析路径中间的恶意解析器仍然可以提供错误数据.

另一方面,DNSSEC提供端到端可验证的加密签名,证明收到的数据与权威服务器上的数据相同. DNSSEC使用加密技术,但实际上并不加密任何DNS流量.

DNSCurve使用椭圆曲线加密算法允许使用比使用RSA小得多的密钥来实现相同级别的加密强度.但是,有人建议在DNSSEC假定的列表中包含类似的算法.

DNSSEC由IETF(RFC 4034和RFC 4035,由RFC 5155更新)标准化,并在几个非常流行的名称服务器实现中实现,包括BIND(当然)和NSD / Unbound. PowerDNS很快将获得DNSSEC支持.

DNSSEC无疑是复杂的,但正在努力简化这一过程(参见例如http://opendnssec.org/),并且部署总是在增加.各种顶级域名(.se,.br,.org,.gov等)已经与DNSSEC签署,并且已宣布根区域将在年底前签署DNSSEC.

DNSCurve非常有趣,但由于其开发的独立方式,它几乎没有机会看到任何重要的部署.恕我直言,它没有机会部署在根服务器上.

BTW你使用“易碎加密”关于DNSSEC的断言似乎是完全没有根据的.在什么基础上你这么说？

区域签名密钥通常(但不一定)1024位长.这些密钥通常每个月左右滚动一次,目前最好的估计是至少需要几年到brute force一个1024位密钥.

At this point in time a brute-force attack against 1024-bit RSA
would require about two years on a few million compute cores with many tens of gigabytes
of memory per processor or mainboard

这不完全是您典型的僵尸网络.从同一篇论文：

Next considering special purpose hardware,the most optimistic approach suggests that sieving
for a 1024-bit RSA modulus can be done in a year for about US $10,000,plus a one-time
development cost of about US $20,and with a comparable time and cost for the
matrix. In our opinion,(common) skepticism met by such designs is beside the point.
Such figures should not be interpreted as upper bounds,i.e.,“Be careful,1024-bit RSA can
be broken in two years for about twenty million bucks (assuming free development),” but as
lower bounds,“No reason to worry too much: even under very favorable attack conditions,factoring a 1024-bit RSA modulus still requires enormous resources.” The estimates should thus not be read as threatening but as confidence-inspiring.

或者从一岁的PCPro article：

To put that into perspective,to crack an RSA 1,024-bit key Kaspersky estimates it would take something like 15 million computers running flat out for a year to succeed

坦率地说,没有人会投入大量精力来破解一个域名的ZSK！

此外,真正的安全性在密钥签名密钥中,并且通常至少为2048位且通常更长(4096位).破解RSA密钥所花费的时间量随密钥长度呈指数增长,而不是线性增长.