It did actually break something - Kerberos authentication performs a clientside PTR record lookup against the host you&#39;re connecting to, and compares the result against the identity that the server claims to have. If there&#39;s a mismatch, then the authentication can&#39;t continue. Round-robin PTR records create sporadic Kerberos authentication failures and force client software to fall back on other authentication methods. Ignore what I said about SSL certs, it&#39;s incorrect.<div>
<br></div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>An option for the alternative behavior would indeed play nicely with everything. Sorry about going the hypothetical route, I was just wondering if there were any legitimate uses of round-robin PTR in the current approach that I was failing to appreciate. (for my own education)<br>
<br></div><div><br><div class="gmail_quote">On Mon, Jul 25, 2011 at 9:26 AM, bert hubert <span dir="ltr">&lt;<a href="mailto:bert.hubert@netherlabs.nl">bert.hubert@netherlabs.nl</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, Jul 23, 2011 at 06:07:44PM -0400, Andrew Boling wrote:<br>
&gt; canonical name. The current implementation causes problems with software<br>
&gt; that uses any form of name validation against PTR records (i.e. SSL certs or<br>
&gt; Kerberos auth).<br>
<br>
</div>Well.. I don&#39;t think that gets you far anyhow.<br>
<div class="im"><br>
&gt; I am aware of the alternatives of using auth-zone or running a<br>
&gt; separate authoritative server for the local domain, so this isn&#39;t a show<br>
&gt; stopper for me. Round-robin PTRs do seem a little counter-intuitive though,<br>
&gt; so I figured it wouldn&#39;t hurt to see how others felt about it.<br>
<br>
</div>What we did was copy the behaviour of djbdns and several other tools that do<br>
it in this way.<br>
<br>
Was your question theoretical or is it actually breaking some things for<br>
you?<br>
<br>
We could of course add a flag to switch behaviour, but I&#39;d only do so if<br>
someone is really hurt by what we do now.<br>
<br>
--<br>
PowerDNS Website: <a href="http://www.powerdns.com/" target="_blank">http://www.powerdns.com/</a><br>
PowerDNS Community Website: <a href="http://wiki.powerdns.com/" target="_blank">http://wiki.powerdns.com/</a><br>
<div class="im"><br>
<br>
&gt;<br>
&gt;<br>
&gt; As an example, if /etc/hosts contains the following line:<br>
&gt; 192.168.0.1    somehost.mydomain      somehost1 somehost2<br>
&gt;<br>
&gt; Queries against the DNS server will return records like so:<br>
&gt; somehost:/etc/powerdns# host -t PTR 192.168.0.1<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost1.<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost.mydomain.<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost2.<br>
&gt; somehost:/etc/powerdns# host -t PTR 192.168.0.1<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost2.<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost1.<br>
&gt; 1.0.168.192.in-addr.arpa domain name pointer somehost.mydomain.<br>
&gt;<br>
&gt;<br>
&gt; OS: Debian Squeeze<br>
&gt; Version: 3.2 (OS-supplied binary distro, no recompile)<br>
<br>
</div>&gt; _______________________________________________<br>
&gt; Pdns-dev mailing list<br>
&gt; <a href="mailto:Pdns-dev@mailman.powerdns.com">Pdns-dev@mailman.powerdns.com</a><br>
&gt; <a href="http://mailman.powerdns.com/mailman/listinfo/pdns-dev" target="_blank">http://mailman.powerdns.com/mailman/listinfo/pdns-dev</a><br>
<br>
</blockquote></div><br></div>