What can I do to prevent BIND from outputting these logs

Question

I recently noticed that BIND has been producing a large amount of logs in /var/syslog relating to one particular server (ezdns)

Jun  3 03:29:24 overlook named[6586]: success resolving 'ns0.ezdns.tf/AAAA' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns4.ezdns.tf/A' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns4.ezdns.tf/AAAA' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns2.ezdns.tf/A' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns2.ezdns.tf/AAAA' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns5.ezdns.tf/A' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns5.ezdns.tf/AAAA' (in 'ezdns.tf'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns5.ezdns.ms/A' (in 'ezdns.ms'?) after disabling EDNS
Jun  3 03:29:25 overlook named[6586]: success resolving 'ns0.ezdns.pm/AAAA' (in 'ezdns.pm'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:26 overlook named[6586]: success resolving 'ns3.ezdns.yt/AAAA' (in 'ezdns.yt'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:26 overlook named[6586]: success resolving 'ns1.ezdns.pl/A' (in 'ezdns.pl'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:27 overlook named[6586]: success resolving 'ns0.ezdns.it/AAAA' (in 'ezdns.it'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:27 overlook named[6586]: success resolving 'ns1.ezdns.la/AAAA' (in 'ezdns.la'?) after disabling EDNS
Jun  3 03:29:27 overlook named[6586]: success resolving 'ns0.ezdns.yt/AAAA' (in 'ezdns.yt'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:28 overlook named[6586]: success resolving 'ns0.ezdns.sx/AAAA' (in 'ezdns.sx'?) after reducing the advertised EDNS UDP packet size to 512 octets
Jun  3 03:29:29 overlook named[6586]: success resolving 'ns5.ezdns.ms/AAAA' (in 'ezdns.ms'?) after disabling EDNS
Jun  3 03:29:29 overlook named[6586]: success resolving 'ns2.ezdns.pl/A' (in 'ezdns.pl'?) after disabling EDNS
Jun  3 03:29:30 overlook named[6586]: success resolving 'ns0.ezdns.sx/AAAA' (in 'ezdns.sx'?) after disabling EDNS
Jun  3 03:29:30 overlook named[6586]: success resolving 'ns0.ezdns.yt/AAAA' (in 'ezdns.yt'?) after disabling EDNS
Jun  3 03:29:31 overlook named[6586]: success resolving 'ns0.ezdns.ms/AAAA' (in 'ezdns.ms'?) after disabling EDNS
Jun  3 03:29:33 overlook named[6586]: success resolving 'ns0.ezdns.ms/AAAA' (in 'ezdns.ms'?) after disabling EDNS

What can I do to prevent these logs from appearing? Why would this server be the only server that is causing BIND to produce these logs?

I've search around google and have found a few different solutions for hiding these logs, but I would like to know why this one server is so troublesome

Solution

Try to check if it's on your end that something is causing problems with DNS packets that are >512 bytes. This should not be the case but there are firewalls that incorrectly do not allow this.

If the problem does not consistently occur with large packets but only happens with some specific remote servers it would seem that the problem is outside your control.

There are the edns-udp-size (this specifies the largest packet you advertise that you can receive) and max-udp-size (this specifies the largest packet you will send) options. Both default to 4096. Lowering these will increase the likelyhood of truncated responses and fallback to TCP in their respective directions (one is more relevant for recursion, the other for authoritative).

However, it only really makes sense to change these settings if the problem is on your own end rather than if you have just run into some random remote server that has a problem. On the other hand, if the problem is on your end the best solution would typically be to fix the network device that causes the problem rather than configuring bind to limit the packet size.

Comments

[lacrosse1991]

@FredtheMagicWonderDog Hello, sorry about that. Had been concerned that the log excerpt was too large of an amount of text (thought that people would complain). I've updated the question with the actual text

[lacrosse1991]

@HåkanLindqvist Hello, I've updated the question with the actual text. How did you extract the text from that picture by the way? (in the edit that you had made)

[Håkan Lindqvist]

@lacrosse1991 OCR