The PowerDNS Auth. server does not set RA bit even if recursion is available. Up until now this hasn't been a problem, but now it seems that some OSs are shipping with resolver libraries that do care and will discard replies if the RA bit is not set.
For example see the release notes from the latest Bind: http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.1-P1 "dig now warns if 'RA' is not set in the answer when 'RD' was set in the query. host/nslookup skip servers that fail to set 'RA' when 'RD' is set unless a server is explicitly set." I have a customer who sees just this on Fedora Core 7. We run the PowerDNS Auth. server with the PowerDNS Recursor and if you ask our name servers a recursive query they will come back with the RA bit set, but if you ask a question that does not need recursion then the RA bit is not set. [EMAIL PROTECTED] ~]$ dig sonic.net | grep flags ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 [EMAIL PROTECTED] ~]$ dig powerdns.com | grep flags ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 The problem is that these newer resolver libraries expect the name servers listed in /etc/resolv.conf to be recursive servers, so if they ask a question they expect to see the RA bit set even if the AA bit is set. Also (and I hate to use this) it seems to be against the RFC to not set the RA when recursion is available - http://www.faqs.org/rfcs/rfc1035.html "RA Recursion Available - this be is set or cleared in a response, and denotes whether recursive query support is available in the name server." Bert, if you've read down this far, can you comment on the above; from the conversations I've seen with the ISC devels. they seem pretty adamant about keeping this logic in place going forward. -- Augie Schwer - [EMAIL PROTECTED] - http://schwer.us Key fingerprint = 9815 AE19 AFD1 1FE7 5DEE 2AC3 CB99 2784 27B0 C072 _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
