Hello David On Sep 13, 2012, at 2:48 , David Hawthorne wrote:
> I don't know how this is happening and I'm having a hard time tracing the > logic in packethandler.cc (pdns-3.1) to find out. I'm getting positive > responses with NXDOMAIN status: > > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22185 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; ANSWER SECTION: > foo. 30 IN CNAME foo.bar. > > ;; AUTHORITY SECTION: > foo.bar. 60 IN SOA self.com. hostmaster.self.com. 3 60 60 60 60 > > I suspect it's because it's doing a second lookup for foo.bar since foo was > CNAME'd to foo.bar, and not finding an answer there, so setting NXDOMAIN on > the response. I suspect it's doing this because I've hard-wired getSOA to > fill in hard-coded defaults and always return true. > > Does that explanation make sense? Secondly, is there a configuration change > I can make to tell pdns not to do a SOA lookup when it gets a CNAME response > back from the backend, and to just return that CNAME response to the client? Yes, the NXDOMAIN is for foo.bar (see the definition of QNAME in RFC2308). It's also wrong because apparently foo.bar has a SOA. Your backend or patch is causing PowerDNS to return bogus data - don't do that. Note that this is not a positive response - it has NXDOMAIN. PowerDNS does not currently have any mechanism to avoid following CNAMEs. Such a mechanism would be hard to get right, too - http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/djbdns-problems.html#tinydns-alias-chain-truncation I'm not sure what to advise here. If there is anything we can do to help, please post again. Kind regards, -- Peter van Dijk Netherlabs Computer Consulting BV - http://www.netherlabs.nl/ _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
