Bug#532256: dnsutils: nsupdate fails to update a reverse PTR record
Michael Stapelberg
Version: 1:9.5.1.dfsg.P2-1
Severity: important
When updating a reverse PTR record with nsupdate, I have to specify the DNS server.
After reading in the manpage that one can leave it out and nsupdate does black
magic to figure it out, I tried and it worked.
However, when also adding a local address to the query, nsupdate fails with the
rather cryptic error message that the protocol families of source/destination
address don’t match (destination isn’t even figured out at that point, strace
says that nsupdate didn’t make any lookups):
echo -e "update add b.a.a.3.6.0.e.f.f.f.6.1.f.1.2.0.2.4.2.4.8.0.0.1.8.8.d.4.1.0.0.2.ip6.arpa. 300 PTR x200.zekjur.net.\nlocal 2001:4d88:1008:4242:21f:16ff:fe06:3aab\nshow\nsend" | nsupdate -v
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags: ; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
b.a.a.3.6.0.e.f.f.f.6.1.f.1.2.0.2.4.2.4.8.0.0.1.8.8.d.4.1.0.0.2.ip6.arpa. 300 IN PTR x200.zekjur.net.
request.c:899: REQUIRE(isc_sockaddr_pf(srcaddr) == isc_sockaddr_pf(destaddr)) failed.
The use of the local keyword is important because you can have multiple
IPv6 addresses (think of a miredo-tunnel being active at the same time). For
the use of update-policy { tcp-self }; on the server side it is important that
the source address is the same as the one which is being updated. I’m not sure
if nsupdate automatically does that…? In any case, specifying it has to work.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.29.1-midna-2 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages dnsutils depends on:
ii bind9-host [host] 1:9.5.1.dfsg.P2-1 Version of 'host' bundled with BIN
ii libbind9-40 1:9.5.1.dfsg.P2-1 BIND9 Shared Library used by BIND
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libcap2 1:2.16-5 support for getting/setting POSIX.
ii libdns45 1:9.5.1.dfsg.P2-1 DNS Shared Library used by BIND
ii libgssapi-krb5-2 1.6.dfsg.4~beta1-13 MIT Kerberos runtime libraries - k
ii libisc45 1:9.5.1.dfsg.P2-1 ISC Shared Library used by BIND
ii libisccfg40 1:9.5.1.dfsg.P2-1 Config File Handling Library used
ii liblwres40 1:9.5.1.dfsg.P2-1 Lightweight Resolver Library used
ii libssl0.9.8 0.9.8g-16 SSL shared libraries
ii libxml2 2.7.3.dfsg-1 GNOME XML library
dnsutils recommends no packages.
Versions of packages dnsutils suggests:
pn rblcheck <none> (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Florian Weimer
> The use of the local keyword is important because you can have
> multiple IPv6 addresses (think of a miredo-tunnel being active at
> the same time). For the use of update-policy { tcp-self }; on the
> server side it is important that the source address is the same as
> the one which is being updated. I’m not sure if nsupdate
> automatically does that…? In any case, specifying it has to work.
Have you checked that the server which had automatically been chosen
by nsupdate has got an AAAA record?
Michael Stapelberg
* [08.06.09 20:47]:
> > The use of the local keyword is important because you can have
> > multiple IPv6 addresses (think of a miredo-tunnel being active at
> > the same time). For the use of update-policy { tcp-self }; on the
> > server side it is important that the source address is the same as
> > the one which is being updated. I’m not sure if nsupdate
> > automatically does that…? In any case, specifying it has to work.
>
> Have you checked that the server which had automatically been chosen
> by nsupdate has got an AAAA record?
The name server which is responsible for the zone has an AAAA record and
fitting glue records. In fact, it will only allow the update query when sent
via IPv6, which happens if I leave out the "local" keyword. I’m not sure if
nslookup correctly detects the server, as I don’t see any lookups when
strace'ing it. It seems it aborts before even trying.
Best regards,
Michael