Opened 7 years ago

Closed 4 years ago

#1196 closed defect (wontfix)

respond using same source address

Reported by: jreed Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: Unclassified Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: DNS Feature Depending on Ticket:
Estimated Difficulty: 0 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

$ 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.

Subtickets

Change History (5)

comment:1 Changed 7 years ago by shane

  • Milestone changed from New Tasks to Year 3 Task Backlog

comment:2 Changed 6 years ago by jreed

This problem continues. (I mistakenly created a duplicate ticket at #1942.)

comment:3 Changed 6 years ago by jreed

Note this was in real production operations and not in a test lab.

I worked around the problem by getting rid of the :: and 0.0.0.0 wildcards and configuring each (7) addresses as separate listen_on configurations.

Last edited 6 years ago by jreed (previous) (diff)

comment:4 Changed 4 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:5 Changed 4 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.