[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 2.9.21.1 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 2.9.21.1 (which is in debian
etch-backports). The backend is postgresql.
Some settings I made are:
allow-recursion-override=on
out-of-zone-additional-processing= DEFAULT (not configured)
skip-cname=yes
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.
Regards,
- Joris
More information about the Pdns-users
mailing list