[Pdns-users] CNAME resolution problem

[PowerDNS Admin]

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' 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?

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

Do you have any recommendation to help us keep our resolution consistent in
this scenario?

Best regards,

Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20080820/14e1b33c/attachment.html>