Please see upstream ticket. PowerDNS logs "not authoritative for" message and returns SERVFAIL if CNAME points to external domain. Reproducible: Always Steps to Reproduce:
Created attachment 231335 [details, diff] pdns-2.9.22-cname.patch Works fine with this patch.
I think this is totally valid behaviour, see http://mailman.powerdns.com/pipermail/pdns-users/2007-August/004684.html
Seems you point to not correct discussion. This patch is from upstream issue, as I've mentioned here in URL section, http://wiki.powerdns.com/trac/ticket/212 There is more complete description of this issue there. I'd like to get code from trunk, but this method seems to be completely rewritten now.
No, I think the link to the discussion is exactly on topic for this bug report. > PowerDNS logs "not authoritative for" message The message only gets logged if the request has the rd (recursion desired) flag set. This flag is only set for clients querying recursive nameservers, which pdns isn't and hence it logs a message. Recursive nameservers don't set this flag when querying other (authoritative) nameservers for resolving records. > and returns SERVFAIL if CNAME points to external domain And this is totally valid behaviour for queries with the rd flag set. You ask pdns to completely resolve (that is to recurse if neccessary) the record and it answers SERVFAL, because it can't provide you with a complete answer, because it's not configured to forward these queries to a recursing nameserver. When the rd flag is not set or the query is for the CNAME record only the answer is NOERROR. I even configured the authoritative pdns server to recurse to pdns-recursor and a CNAME pointing to external domain gets correctly resolved with NOERROR and nothing is logged.
Hmm... That's very strange. Really, I do not understand your setup - which role is for recursor? I have local domain for which my PowerDNS is authoritative for. Authoritative: mydomain.com Wanted CNAME to external: ext.mydomain.com I added CNAME to ghs (does not metter) and PowerDNS returns SERVFAIL for all queries except direct CNAME. With this patch it responds like this: ------------- $ host ext.mydomain.com 123.45.67.89 Using domain server: Name: 123.45.67.89 Address: 123.45.67.89#53 Aliases: ext.mydomain.com is an alias for ghs.google.com. ------------- As it should be. No one will know that there is such CNAME until server replies.
(In reply to comment #5) > Hmm... > > That's very strange. Really, I do not understand your setup - which role is for > recursor? That's just equal to the setup mentioned in the powerdns ticket, but I don't think it's need to explain your case. > I have local domain for which my PowerDNS is authoritative for. > Authoritative: mydomain.com > Wanted CNAME to external: ext.mydomain.com > > I added CNAME to ghs (does not metter) and PowerDNS returns SERVFAIL for all > queries except direct CNAME. It responds with SERVFAIL, but that's what it should do. The host command makes queries with the recursion desired flag set by default. It wants the server to fully resolve the query, having it contact other nameservers if necessary. That's what the recursion desired flag implies. In this case pdns answers SERVFAIL, because it can't fulfill this request, because it can't (or isn't configured to) resolve the CNAME target. The answer packet does indeed contain the CNAME record, but host isn't showing it to you, because it stops parsing the answer when it sees SERVFAIL. Here is example ouput of "dig cname.example.com @ns.example.com": > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6207 > ;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;cname.example.com. IN A > > ;; ANSWER SECTION: > cname.example.com. 43200 IN CNAME cnametarget.example.net. Above, the request was for an A record and recursion was desired and pdns answers SERVFAIL, because it can't fulfill this request. When the recursion desired flag is cleared, the answer becomes: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42510 > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 > > ;; QUESTION SECTION: > ;cname.example.com. IN A > > ;; ANSWER SECTION: > cname.example.com. 43200 IN CNAME cnametarget.example.net. It's NOERROR, because we got all the information we asked for. You can use host -r to do non-recursing queries and it should show you the CNAME it received. > With this patch it responds like this: > ------------- > $ host ext.mydomain.com 123.45.67.89 > Using domain server: > Name: 123.45.67.89 > Address: 123.45.67.89#53 > Aliases: > > ext.mydomain.com is an alias for ghs.google.com. > ------------- > > As it should be. No one will know that there is such CNAME until server > replies. That's wrong, host asked the server for an A record, which pdns can't return in its answer. host is making DNS queries like the libc resolver does, it sets the recursion desired flag, because it expects the nameserver to fully resolve the query. These queries are only to be sent to a nameserver that is configured to do recursion, that is to contact other nameservers to get the answer. To sum up: clients (e.g. libc resolver) must always ask an nameserver that is configured to do recursing or has all the information needed at hand, i.e. it's authoritative for all of the data and that it includes targets of CNAMEs. These nameservers then ask authoritative nameservers, with the recursion flag not set. Or they can be configued to ask other recursing nameservers.
As said, I consider this not a bug, that's just how DNS works.
