Comment 2 for bug 242956

Thanks for your response.

> What you're seeing here is that the AD bit was redefined here:
> http://www.ietf.org/rfc/rfc3655.txt

That is why options edns0 is defined, so that the client is forced to
ask for the AD bit. Who do you suggest I talk to about this?

Thanks,
--
Bryan Buecking http://www.starling-software.com

On Wed, Jul 02, 2008 at 12:06:46PM -0000, LaMont Jones wrote:
> 9.4.2 rc1 introduced the following change:
> 2249. [bug] Only set Authentic Data bit if client requested DNSSEC, per RFC 3655 [RT #17175]
>
> ** Changed in: bind9 (Ubuntu)
> Assignee: (unassigned) => LaMont Jones (lamont)
> Status: New => Invalid
>
> --
> Bind9 (8.04) not returning 'ad' flag when dnssec is enabled
> https://bugs.launchpad.net/bugs/242956
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “bind9” source package in Ubuntu: Invalid
>
> Bug description:
> Binary package hint: bind9
>
> % lsb_release -rd
> Description: Ubuntu 8.04
> Release: 8.04
>
> % apt-cache policy bind9
> bind9:
> Installed: 1:9.4.2-10
> Candidate: 1:9.4.2-10
> Version table:
> *** 1:9.4.2-10 0
> 500 http://ubuntu-ashisuto.ubuntulinux.jp hardy/main Packages
> 100 /var/lib/dpkg/status
>
> % cat /etc/resolv.conf
> nameserver 127.0.0.1
> options edns0
>
> When running dig against dns server w/DNSSEC enabled it is expected that
> named should return the ad flag for authenticated records; however, this
> system is not returning the correct response. If I query asking for
> +dnssec the ad flag is properly returned - as expected.
>
> Without the ad flag I am not able to use ssh VerifyHostKeyDNS.
>
> I have two systems with identical named configs. System A is a NetBSD
> machine running Bind 9.4.2 built against OpenSSL 0.9.8d 28 Sep 2006, and
> System B Ubuntu 8.04 running Bind 9.4.2 built against OpenSSL 0.9.8g 19
> Oct 2007.
>
> If I dig @system-a foo.example.com A the ad flag is return; but as I
> mentioned above if I dig @system-b foo.example.com A the ad flag is not
> returned even though the configurations are exactly the same.
>
> When quering for an SSHFP record both servers, a and b, return the same
> SSHFP record in the results.