[Pdns-users] CNAME resolution problem

Joris Dobbelsteen joris at familiedobbelsteen.nl
Wed Aug 27 11:26:21 UTC 2008

PowerDNS Admin wrote, On 20-Aug-2008 17:12:
> Hi,
> We have a PowerDNS Authoritative Server in our company to host our 
> client's zones. Through our subscription form, the clients are able to 
> register whatever zone they can come up with directly on the PowerDNS 
> database, no matter if we are really authoritative for that zone or not 
> (according to the registrar's records).
> We are having issues with CNAME records resolution when, for example, 
> someone add the zone 'com' or 'google.com <http://google.com>' to the 
> database, even when we try to set the option 
> 'out-of-zone-additional-processing' to 'no' in the PowerDNS 
> configuration file.
> We built a test environment using two machines, one with PowerDNS 
> Authoritative Server and another with 
> PowerDNS Recursor 3.1.4, to investigate this behaviour. Then we 
> configured 'query-cache-ttl=0' on the authoritative server and 
> 'query-cache-ttl=0' on the recursor to prevent cache store. We added 
> some zone information into the authoritative server and set up the 
> recursor to redirect to it for the relevant test zones, so that we could 
> use the recursor for name resolution on our tests.
> If we add a CNAME pointing to 'google.com' into an 
> 'example.com' zone on the authoritative server, 
> everything works fine (the recursor properly resolves Google's IP 
> address when queried for that CNAME record). Then, when we add the zone 
> 'com' or 'google.com' to the authoritative server, 
> resolution of this CNAME record starts to fail. Is it possible to change 
> the behaviour of the authoritative server so that it doesn't try to 
> resolve a CNAME record with some other zone's information that is stored 
> on the same database by itself?

I have seen the same problem on my pdns (which is in debian 
etch-backports). The backend is postgresql.

Some settings I made are:
out-of-zone-additional-processing= DEFAULT (not configured)

Turning skip-cname=no in the configuration provides SERVFAILs for CNAME 
records. It requires a second lookup, but at least it works correctly.

I'm not sure whether the behavior is linked in any way to having CNAMEs 
end in a dot (e.g. "example.com." instead of "example.com").

Using a different dns server, such as BIND, as secondary seems a good 
idea. The zone transfers will work correctly and these other servers 
will resolve the query satisfactory. It at least keeps production 
working with a much higher probability.

> We tried searching in the documentation, Wiki, Trac tickets, changelog 
> and Google for a solution. We tried several configuration options too.

This will hopefully get your production going, but, since you have a 
test setup deployed I would very kindly ask you to do some deeper 
investigation! It seems a bug report would be in place.

If you have it on a database (postgresql/mysql), it seems a good idea to 
use wireshark to monitor the queries that flow and at least observe the 
external behaviour of the powerdns server. This requires having the dns 
server and database on different systems/virtual machines though..

I'm also not sure whether I saw this behaviour on my old powerdns 
version that came with Ubuntu 6.06 or the Debian Etch one.


- Joris

More information about the Pdns-users mailing list