Bugzilla – Full Text Bug Listing
|Summary:||Query / Reply IPv6 address issue in NSD3|
|Product:||NSD||Reporter:||Gijs van den Broek <gijs.vandenbroek>|
|Component:||NSD Code||Assignee:||NSD team <nsd-team>|
|Attachments:||Network trace file showing the issue.|
Description Gijs van den Broek 2011-10-27 12:56:10 CEST
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. Setup Debian version 2.6.32-5-amd64 NSD3 version 3.2.5-1.squeeze1 IPv6 addresses at eth0: 0: 2001:db8:0:3::2/64 1: 2001:db8:0:3:20c:29ff:fe02:c3/64 No other interfaces installed Replication • 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. Opinion 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. Trace 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.
Comment 1 Matthijs Mekking 2011-11-24 10:22:21 CET
Hi, 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. Best regards, Matthijs
Comment 2 egor 2014-02-24 20:09:36 CET
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.
Comment 3 egor 2014-02-24 20:10:54 CET
Also, paragraph 4 of RFC2181 (http://tools.ietf.org/html/rfc2181#section-4) describes source address selection.
Comment 4 Matthijs Mekking 2014-02-25 10:21:31 CET
For zone transfers you can configure "outgoing-interface:" per zone. Best regards, Matthijs
Comment 5 egor 2014-02-27 17:04:55 CET
(In reply to comment #4) > For zone transfers you can configure "outgoing-interface:" per zone. > > Best regards, > Matthijs 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*.
Comment 6 Matthijs Mekking 2014-02-27 17:56:55 CET
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.
Comment 7 egor 2014-02-27 20:07:07 CET
(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 :)