Если запросы к URIBL заблокированы из-за того, что URIBL «обнаруживает», что ваш DNS-запрос использует IP-адрес DNS-преобразователя, который уже сделал слишком много запросов и превысил лимит ...
Как можно обойти это с помощью ЛОКАЛЬНОЙ службы DNS, такой как Bind9?
Мое ограниченное понимание:
Когда запускается запрос к провайдеру URIBL,
локальные зоны Bind9 не будут содержать никаких записей о URIBL
поэтому для разрешения URIBL EDIT потребуется обратиться к серверу пересылки DNS: моя терминология неверна. Bind9 будет запрашивать у rootrvrs подсказки gTLD
но если сервер пересылки DNS вашего сервера - 8.8.8.8 (ферма Google DNS), и этому IP-адресу уже было отказано в запросах к URIBL,
как вам обойти эту очевидную уловку-22?
РЕДАКТИРОВАТЬ: узнав, как bind9 использует корневые srvrs, я удалил значения пересылки dns 8.8.8.8 и настройки сервера имен почтового сервера, а bind9 вернул ответ, потому что он сам выполнял поиск, а не передавал его серверам имен 8.8.8.8.
Я прочитал по меньшей мере 50 веб-страниц об этом, но ни на одной из них не объясняется, как это разрешается.
РЕДАКТИРОВАТЬ: оставшаяся часть этого вопроса была удалена, это было лишним, я задам отдельный вопрос по этому поводу.
Думаю, вас смущает, как bind работает как кеширующий сервер имен. Сервер пересылки DNS действительно вступает в игру только тогда, когда вы говорите с точки зрения клиента, и не имеет отношения к настройке кэширующего сервера имен. Когда привязка запрашивается для записи, которой у нее нет, она следует обычному процессу разрешения имени домена, начиная с корневых серверов. я нашел эта ссылка чтобы быть интересным способом продемонстрировать, что происходит в этом процессе. Вы также можете увидеть весь уродливый процесс для любого интересующего вас домена - попробуйте его, используя dig +trace serverfault.com. То, что вы видите, будет той же цепочкой разрешения, которой следует bind. После того, как bind получил результаты и предположил, что для него включено кеширование, последующие запросы будут обслуживаться из кеша до тех пор, пока не истечет TTL записи, и в этом случае он выполняет этот процесс снова, чтобы обновить свой кеш.
Итак, если вы настроили кэширующий сервер имен и пытаетесь запросить URIBL через это будет отклонено, это не будет отклонением Google - это будет IP вашего собственного сервера. Для подтверждения попробуйте покопать оба сервера имен - свой собственный (dig @<your_bind_server> test.uribl.com.multi.uribl.com) и Google (dig @8.8.8.8 test.uribl.com.multi.uribl.com) и посмотрите, где происходит отказ.
Кроме того, нет, привязка не должна кэшировать отклонения.