Date: Tue, 23 Sep 2008 14:08:39 -0700 From: "Eugene M. Kim" <20080111.freebsd.org@ab.ote.we.lv> To: freebsd-net@freebsd.org Subject: Request for review - PR bin/127951: spurious warning against DNAME RRs Message-ID: <48D95AD7.2070604@ab.ote.we.lv>
next in thread | raw e-mail | index | archive | help
Greetings, I just submitted a very simple PR/patch - http://www.freebsd.org/cgi/query-pr.cgi?pr=127591 - which fixes spurious but annoying warnings against DNAME RRs (annoying because they spam syslog at auth.notice level). The patch should not cause any regression, because it just suppresses the warning without altering any other control flow, but I am not entirely sure if there is a valid case where DNAMEs should trigger a strong security warning just as they currently do. Could someone please review and/or take care of this PR? Cheers, Eugene P.S. A bit of background information, for those who are not familiar with the subject: DNAME RRs, as defined in RFC 2672, provides a useful mechanism for mapping/aliasing an entire DNS tree. For (a real) example, given a primary domain "the-7.net" and a number of secondary domains such as the-7.com, the-7.org, the-seven.net and so on, instead of having to add CNAMEs for "www", "mail" and other subdomains to every single secondary domain, one can simply add "IN DNAME the-7.net." to the zone apex of those secondary domains, and the DNS server will take care of all possible - current /and/ future - subdomains automatically, by returning a synthesized CNAME: $ dig www.the-7.com IN A +noall +answer ; <<>> DiG 9.4.2-P1 <<>> www.the-7.com IN A +noall +answer ;; global options: printcmd the-7.com. 300 IN DNAME the-7.net. www.the-7.com. 0 IN CNAME www.the-7.net. www.the-7.net. 300 IN CNAME purple.the-7.net. purple.the-7.net. 300 IN A 64.71.156.34 $
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48D95AD7.2070604>