Недавно я заметил, что BIND создает большое количество журналов в / var / syslog, относящихся к одному конкретному серверу (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
Что я могу сделать, чтобы эти журналы не появлялись? Почему этот сервер должен быть единственным сервером, который заставляет BIND создавать эти журналы?
Я поискал в Google и нашел несколько разных решений для сокрытия этих журналов, но я хотел бы знать, почему этот сервер так проблематичен
Попробуйте проверить, не вызывает ли что-то с вашей стороны проблемы с DNS-пакетами размером> 512 байт. Это не должно быть так, но есть брандмауэры, которые неправильно этого не допускают.
Если проблема не всегда возникает с большими пакетами, а возникает только с некоторыми конкретными удаленными серверами, может показаться, что проблема находится вне вашего контроля.
Есть edns-udp-size (это определяет самый большой пакет, который вы рекламируете, который вы можете получить) и max-udp-size (это указывает самый большой пакет, который вы отправите) options. Оба по умолчанию равны 4096. Понижение этих значений увеличит вероятность усеченных ответов и отката к TCP в соответствующих направлениях (одно более актуально для рекурсии, а другое - для авторитетного).
Однако на самом деле имеет смысл изменять эти настройки только в том случае, если проблема на вашей стороне, а не если вы только что столкнулись с каким-то случайным удаленным сервером, на котором возникла проблема. С другой стороны, если проблема находится на вашей стороне, лучшим решением, как правило, было бы исправить сетевое устройство, которое вызывает проблему, а не настраивать привязку для ограничения размера пакета.