Your message dated Wed, 16 Feb 2011 21:07:16 -0500
with message-id <[email protected]>
and subject line Re: Bug#513987: unbound trusts glue that contradicts local
data for transparent zone
has caused the Debian Bug report #513987,
regarding unbound trusts glue that contradicts local data for transparent zone
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
513987: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=513987
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: unbound
Version: 1.0.2-1
Severity: normal
Unbound seems to trust (and pass on to clients) extra/glue data in
responses from authoritative servers, even when this extra data
contradicts that held locally for a transparent zone.
Example:
Authoritative server has records:
foo.example.com A 192.168.1.1
bar.example.com CNAME a.example.com.
Unbound has the following in a transparent zone:
foo.example.com A 10.1.1.1
A query to unbound, `dig -t a bar.example.com @<unbound ip>` receives
the answer given by the authoritative server:
bar.example.com CNAME a.example.com.
foo.example.com A 192.168.1.1
This is at the very least counter-intuitive, at worst - who knows?
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: powerpc (ppc64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24-etchnhalf.1-powerpc64
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
--- End Message ---
--- Begin Message ---
Nick Phillips wrote:
> On 3/02/2009, at 12:10 PM, Nick Phillips wrote:
>
> >Package: unbound
> >Version: 1.0.2-1
> >Severity: normal
> >
> >Unbound seems to trust (and pass on to clients) extra/glue data in
> >responses from authoritative servers, even when this extra data
> >contradicts that held locally for a transparent zone.
> >
> >Example:
> >
> >Authoritative server has records:
> >foo.example.com A 192.168.1.1
> >bar.example.com CNAME a.example.com.
> >
> >Unbound has the following in a transparent zone:
> >foo.example.com A 10.1.1.1
> >
> >
> >A query to unbound, `dig -t a bar.example.com @<unbound ip>` receives
> >the answer given by the authoritative server:
> >
> >bar.example.com CNAME a.example.com.
> >foo.example.com A 192.168.1.1
> >
> >This is at the very least counter-intuitive, at worst - who knows?
>
>
> Looking at it more closely, it appears the extra record is not being
> helpfully added by the authoritative server and then being passed on
> by unbound; unbound is explicitly making an extra query for that
> information (when it already has the correct information in the
> transparent zone!).
hi,
i don't use local-zones myself, but from reading the unbound.conf man
page:
transparent
If there is a match from local data, the query is answered.
Otherwise if the query has a different name, the query is
resolved normally. If the query is for a name given in
localdata but no such type of data is given in localdata, then
a noerror nodata answer is returned. If no local-zone is given
local-data causes a transparent zone to be created by default.
the behavior you describe makes sense to me given that the man page
describes the behavior of an option for intercepting a particular QNAME,
not for rewriting arbitrary data in the response sections. in your
example the QNAME doesn't match the intercepted name. note also in the
unbound.conf manpage:
"If you need more complicated authoritative data, with referrals,
wildcards, CNAME/DNAME support, or DNSSEC authoritative service, setup
a stub-zone for it as detailed in the stub zone section below."
--
Robert Edmonds
[email protected]
--- End Message ---
