2

I see lines such as

Feb 13 21:45:48 srv named[2355]: address not available resolving 'secure.gravatar.com/A/IN': 2a04:fa87:ffff::c6b5:7405#53
Feb 13 21:42:29 srv named[2355]: address not available resolving 'la1.akamaiedge.net/AAAA/IN': 2001:500:a8::e#53

in /var/log/syslog despite running bind in IPv4 mode only

srv # cat /etc/default/bind9
# run resolvconf?
RESOLVCONF=no

# startup options for the server
OPTIONS="-u bind -4"

Why is it so?

WoJ
  • 3,365
  • 8
  • 46
  • 75

4 Answers4

6

If the system is using systemd then editing /etc/default/bind9 will have no effect.

Edit /lib/systemd/system/bind9.service file instead and add -4 option to ExecStart variable. I'm using Ubuntu 16 and had to do that.

ExecStart=/usr/sbin/named -f -4 -u bind

Also double check that after restarting the named is running with -4 option.

There is actually a bug filled about this configuration confusion https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1565060

Nicolae Namolovan
  • 76
  • 2
  • On Debian 11 I had an issue with loading defaults parameters from file – Lukáš Viktora Nov 17 '21 at 16:13
  • This answer is not correct. systemd unit files on Debian and Ubuntu typically use the corresponding files in `/etc/default` via `EnvironmentFile`. The bind9/named unit certainly does. With Debian 11 aka *bullseye* (and *buster-backports*) the file was [changed](https://salsa.debian.org/dns-team/bind9/-/commit/6fd962a36bb54e0106e001aff6cce056d54e2526) from `/etc/default/bind` to `/etc/default/named` however. – Sebastian Schrader Jan 05 '22 at 19:35
2

As an alternative to adding -4 to the named command line (which does work, but may be inconvenient depending on how named is started), it's also possible to add the following to the configuration with similar effect regarding not attempting to connect over IPv6:

server ::/0 {
        bogus yes;
};

This flags servers with IPv6 addresses as bogus, preventing queries to these addresses.

It probably goes without saying, but both these options should only be used in environments without global IPv6 connectivity, where named keeps logging these kinds of errors for everything all the time.
If you only run into some occasional connection problems to specific servers, that is no reason to disable the use of a whole protocol on your own end.

Håkan Lindqvist
  • 33,741
  • 5
  • 65
  • 90
  • Thank you, this is exactly what I needed in my situation. Avoiding changes to the startup command makes managing my bind configuration files much simpler. This is a great option to have and not a solution I would've thought of myself. – cecilkorik Nov 01 '21 at 23:22
2

The -4 option only changes tells bind to listen and respond on IPv4 packets. It doesn't disable the use of AAAA records.

So is there a way to discard IPv6 addresses in bind?

If that is what you really want then you could adjust your bind configuration to include the following. You must disable dnssec validation, since you are dropping valid records.

options {
    ...
    dnssec-enable no;
    filter-aaaa-on-v4 yes;
    ...
};
Zoredache
  • 128,755
  • 40
  • 271
  • 413
  • So is there a way to discard IPv6 addresses in `bind`? (so that they are not handled at all, or not logged at least) – WoJ Feb 17 '17 at 20:20
  • I some a configuration example that might give you want you want. – Zoredache Feb 17 '17 at 21:26
  • Thank you but it did not help to stop the messages. I found the solution, though, and posted an answer. – WoJ Feb 19 '17 at 15:43
  • This solved a weird issue for me. I have many local bind servers that were causing the same issue here: https://serverfault.com/questions/335359/how-is-it-possible-that-i-can-do-a-host-lookup-but-not-a-curl. Applying this configuration change fixed it for all clients. – senorsmile Feb 22 '18 at 19:15
0

For Redhat Linux and its derivatives, the options should be added to /etc/sysconfig/named .

To disable listening on IPv6 and use exclusively IPv4, use the following line:

OPTIONS="-4"
Robert Newton
  • 171
  • 1
  • 5