Bugzilla – Bug 417
Query / Reply IPv6 address issue in NSD3
Last modified: 2014-02-27 20:07:07 CET
Created attachment 191 [details]
Network trace file showing the issue.
Introduction of issue
DNSSEC Experiments with NSD3 in a lab environment consisting of multiple virtual computers in different subnets have shown the following:
If no interfaces to bind to are specified in nsd.conf and the system has multiple (globally routable) IPv6 addresses assigned to a single interface, it may reply to a client with a different source IPv6 address than the IPv6 address the query was addressed to. It has not been checked whether this applies to IPv4 as well.
I am not sure whether this issue has been covered in bugfix #362: outgoing-interface and v4 vs. v6 leads to spurious warning messages.
Debian version 2.6.32-5-amd64
NSD3 version 3.2.5-1.squeeze1
IPv6 addresses at eth0:
No other interfaces installed
• Let the system have multiple IPv6 addresses on a single NIC;
• Commenting any IPv6 address NSD3 can bind to in nsd.conf and starting the NSD3 service;
• Use dig or a similar tool to query this NSD3 server on 2001:db8:0:3::2 from a different node;
• Dig reports that replies originate from an unexpected source (namely 2001:db8:0:3:20c:29ff:fe02:c3) and does not accept them.
I believe the source IPv6 address of the reply must be the same as the destination IPv6 address in the query since many resolvers couple this information, amongst other things, for security reasons.
The attached pcap file contains 8 packets. The first 4 are from the scenario stated above where NSD3 was not configured to bind to any IPv6 address. You can see that the IPv6 addresses do not match. The last 4 packets are recorded after binding NSD3 explicitly to 2001:db8:0:3::2 in nsd.conf.
I agree that this would be a nicer approach. The short term solution is to resolve this issue is, as you have already pointed out, to explicitly set the interfaces that NSD has to use.
This workaround doesn't work for anycast IPs when I need outgoing requests (AXFR for instance) to be originated from unicast IP, while replies to incoming DNS requests (those are received at anycast address) should retain that address in replies.
Also, paragraph 4 of RFC2181 (http://tools.ietf.org/html/rfc2181#section-4) describes source address selection.
For zone transfers you can configure "outgoing-interface:" per zone.
(In reply to comment #4)
> For zone transfers you can configure "outgoing-interface:" per zone.
> Best regards,
This would require to maintain several configurations for different name servers (ns1/ns2/ns..) which makes things way over complicated and is not an option at all in some corner cases when one server for several reasons have to reply for ns*.
Yes, this is getting a bit ugly.
We will be working on a fix, until then you might want to consider a work around. The outgoing-interface setting might help with that.
(In reply to comment #6)
> Yes, this is getting a bit ugly.
> We will be working on a fix, until then you might want to consider a work
> around. The outgoing-interface setting might help with that.
Yeah, I have work-around for now, it is a bit less ugly that what I'd have to do with outgoing-interface, but nonetheless ugly :)