BIND 10 #1196: respond using same source address

[BIND 10 Development]

#1196: respond using same source address
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |                       Status:  new
            Priority:  major         |                    Milestone:  New
           Component:  Unclassified  |  Tasks
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 {{{

 $ dig @2001:04f8:3:d::95 bind10.isc.org
 ;; reply from unexpected source: 2001:4f8:3:d::80#53, expected
 2001:4f8:3:d::95#53

 }}}

 or

 {{{

 $ dig @149.20.48.80 bind10.isc.org
 ;; reply from unexpected source: 149.20.48.59#53, expected 149.20.48.80#53
 ;; reply from unexpected source: 149.20.48.59#53, expected 149.20.48.80#53

 }}}

 I will copy some from jabber:


 (12:43:11) jinmei: in general, a DNS server implementation must either
 listen on a specific address or use the IPv6 pkthdr API to ensure query
 dest addr = response src addr.
 ...
 (12:54:48) shane: Yes, I agree. Probably we can use the work of the DHCP
 team to give us interfaces and we can bind to them.
 (12:55:49) vorner: Can we add and remove them (eg. get notified of
 addition and removal) of interface at runtime? Because when I instruct it
 to bind to *, I mean even future *.
 (12:56:03) shane: Yes, that's the idea.
 (12:56:36) shane: BIND 9 works that way; apparently IPv6 in Linux is a lot
 faster if you bind to specific interfaces instead of the wildcard.
 (12:56:46) shane: At least, it was in the past... not sure about now.
 ...
 (13:04:45) jinmei: the solutions may be different for IPv4 and IPv6: for
 IPv6 we could use the help of API (with possible performance implication
 as Shane noted); for IPv4 there's a similar API but it's not so commonly
 available, we should probably need to introduce interface (address)
 scanning mechanism and listen-on every one of them as we find a new one.
 (13:05:57) jinmei: FYI: this is what BIND9 does.
 (13:06:57) shane: The DHCP code in BIND 10 already uses the technique, if
 you are interested to see how it works.
 (13:07:03) shane: (It's DHCPv6 only right now.)
 (13:07:28) vorner: The scanning of IPv4 could be directly borrowed from
 bind9, no?
 (13:10:31) jinmei: in its essence, yes, I think so.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1196>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development