These are chat archives for CZ-NIC/knot-resolver

19th
Sep 2018
Robert Šefr
@robcza
Sep 19 2018 06:14

Just experienced a weird behavior regarding how kresd binds to IP addresses on the machine. The setup is:

  • kresd 2.4.1
  • network config: net = {'0.0.0.0'}
  • except loopback there is just the eth0 interface with multiple IP addresses:
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      link/ether ...... brd ff:ff:ff:ff:ff:ff
      inet 10.10.0.1/26 brd 10.10.0.63 scope global eth0
         valid_lft forever preferred_lft forever
      inet 10.10.0.3/26 brd 10.10.0.63 scope global secondary eth0
         valid_lft forever preferred_lft forever
      inet6 ......../64 scope link
         valid_lft forever preferred_lft forever

In this setup, kresd answers on the IP address 10.10.0.1 only and ignores 10.10.0.3.

netstat output show kresd listening on port 53 and 0.0.0.0
what do I do wrong?
Petr Špaček
@pspacek
Sep 19 2018 06:16
@robcza Morning! That's weird. My guess is that "something" was listening on 10.10.0.3:53 when kresd was started but that's a really wild guess.
I assume that you did not forget kresd which is bound to 0.0.0.0 might answer from different IP than it received the request, but from your descriprion it sounds that kresd does not reply at all.
Robert Šefr
@robcza
Sep 19 2018 07:06
@pspacek kresd answering from different IP address when configured with net = {'0.0.0.0'} is something we have already seen. That could actually be the reason.
The solution was to iterate through interfaces and bind to them directly, as described in the documentation: https://knot-resolver.readthedocs.io/en/stable/daemon.html#dynamic-configuration
Vladimír Čunát
@vcunat
Sep 19 2018 08:01
Yes, that happens. ATM listening on '0.0.0.0' results into sending the answers from '0.0.0.0', so the OS chooses the real outgoing address. Therefore it's not good to use this wildcard when using multiple addresses (whose network's address ranges overlap).
Robert Šefr
@robcza
Sep 19 2018 08:24
I find it rather important, e.g. users switching from unbound can be surprised as unbound offers a configuration switch to honor the IP address that was used to accept the query even for the outgoing direction.
Proposed a warning to the docs: CZ-NIC/knot-resolver#57
Petr Špaček
@pspacek
Sep 19 2018 08:26
@robcza Thanks, we will review it.
Please, use Gitlab for next PR - it is easier to manage for us + it executes doc tests automatically.
Robert Šefr
@robcza
Sep 19 2018 08:27
oh sorry. got it, will do