NA
Я планировал bind в качестве кэширующего и балансера за ним для размазывания запросов по внешним серверам.
Size: a a a
2019 August 29
NA
Может есть что-то проще?
IH
Поток испшный что ли? В чем проблема с обычным резолвом?
NA
Нууу как-бы очень много dns запросов в единицу времени
NA
В интернете могут не понять ;)
IH
Просто если анализируется трафик предприятия, то большая часть есть в локальном Кеше днс. Или я не понял
IH
А если сидеть на трубе, то да... Но тогда можно с исп закорешиться, ему положено вагонами резолвить
NA
У меня как раз вариант про трубу
NA
IPшники на 95% внешние
IH
Не до конца понятны проблемы, есть труба, нет доступа к днс на трубе. Но можно попробовать поизвращаться с запросами во всякие хуиз ещё
IH
С другой стороны наверняка интернет полон открытых резолверов
AL
Нууу как-бы очень много dns запросов в единицу времени
Коммерческое решение или free ищется?
NA
Free
NA
Нагуглил статейку https://m.habr.com/ru/post/159013/ и комменты к ней
NA
В основном от кэширующего dns я хочу добиться round robin запросов к вышестоящим серверам
m
В основном от кэширующего dns я хочу добиться round robin запросов к вышестоящим серверам
А что мешает самому рекурсивно ресоловить и кешировать безо всяких вышестоящих? Скорость и надежда на кеш вышестоящих?
NA
max
А что мешает самому рекурсивно ресоловить и кешировать безо всяких вышестоящих? Скорость и надежда на кеш вышестоящих?
Ipшники не из локальные сети. Это внешние ip адреса
NA
Это штатная задача, которая возникает при обогащении событий в siem или при обогащении внешних фидов
m
Ipшники не из локальные сети. Это внешние ip адреса
Я, наверно, чего-то в задаче не понимаю. Ставим свой рекурсивный дни и он сам все ресолвит.
m
Это штатная задача, которая возникает при обогащении событий в siem или при обогащении внешних фидов
Это штатная задача, которая есть у почти любого почтового и т.д. сервера. Ну масштабы у тебя побольше на пару порядков, это да. Но это только на скорость разбора очереди ресолва влияет.