Для начала поговорим о том, для чего нужен локальный dns-резолвер. Вообще, полезен он и на сервере, и на вашем ноутбучке (только для разного, пожалуй), а написать эту статью меня вынудил именно новый провайдер (самизнаетепочему).
Локальный резолвер позволяет получать мгновенный ответ от dns (кроме случая, когда мы впервые спрашиваем определенную запись). Резолверы провайдера/хостера бывают перегружены, запрос в них в любом случае занимает какие-то миллисекунды, да и протокол UDP весьма не надежен, если говорить про один конкретный запрос — от этого мы спасаемся резолвером без форвардинга, выигрывая пару миллисекунд на любом обращении к dns. Вкупе с опцией prefetch — ответ всегда будет мнгновенным, потому что unbound будет самостоятельно в фоне (без запросов на резолв от системы) обновлять отдельные записи, когда их ttl в кэше будет подходить к концу.

Защищает локальный резолвер и от того, что провайдер знает и логгирует все записи, которые мы спрашиваем у его dns-сервера. Таким образом провайдер узнаёт, какие именно https-сайты вы посещаете (можно и из заголовка SNI узнать, но не весь софт шлёт этот заголовок). Бывают и хреновые случаи — когда провайдер перехватывает весь dns-трафик с нашего компа/сервера и заворачивает его в свой резолвер (фильтруя и подменяя записи), но от этого спасёт использование форварда в tls-резолвер (в статье будут приведены для примера публичные, но и свой поднять в доверенной сети никто не мешает).

Свой резолвер защищает и от самодурства администраторов чужого — некоторые провайдеры и хостеры выставляют у себя опцию min-ttl большую (тем самым, повышая минимальный ttl в своём кэше, снижая нагрузку — в отдельных упоротых случаях мне встречался min-ttl в 30 дней), подменяют записи, ломают DNSSEC, дропают CAA записи, да много чего делают. Если при этом они не заворачивают весь трафик по 53-му порту во всей сети в свой резолвер — то и от этого защитимся (а если заворачивают — привет, dns over tls).

Ещё один плюс — вы сами контролируете (если не используете forward, или используете forward в свой сервер) сброс кэшей на резолвере. Например, ваши сервера ходят в какое-то API бэкэнда. У вас появилась необходимость переключить запись для этого бэкэнда. Меняем запись в dns, рестартим все резолверы, вуаля — на всех уже новая запись. Очень удобно.

Почему именно unbound. Не буду чего-то придумывать — в unbound опция prefetch появилась давно, а в bind — только в десятой версии (которая до сих пор не доехала до стабильных дистрибутивов в базовых репозиториях). Unbound есть во всех поддерживаемых убунтах и дебианах, не нужно подключать сторонние репозитории. Других причин, в целом, нет.

Для начала ставим пакет с unbound:

Редактируем файл /etc/unbound/unbound.conf
Полностью он у нас будет выглядеть так:

Если нам всё же хочется использовать форвард в другой dns-сервер (при этом стоит понимать, что unbound всё ещё будет делать prefetch для записей в кэше, даже при включенном форварде), то добавляем в конфиг такие буквы (сторонние сервера, само собой, можете указать другие):

Если же вам хочется dns загнать через tls, то добавляем кусок конфига ниже (вместо куска конфига выше, само собой). Все коннекты к этим серверам (а значит, и все записи, которыми вы обмениваетесь) будут зашифрованы. Это ещё не dnscrypt, который вовсе не подвержен MItM, но и не plain-dns, который спуфят все, кому ни лень.
Я привожу рабочий список tls-серверов, но они «чьи-то». Вы скрываете свой dns-трафик от провайдера, но дарите его кому-то ещё, имейте в виду.

После операций с конфигом, само собой, рестартим unbound

Потестируем наш резолвер (если команды host нет — поставьте пакет bind9-host) на записи, которая уже в кеше локально:

Сравним с 8.8.8.8:

И это — при RTT в 5ms до адреса 8.8.8.8. Экономия — 80мс.

Остаётся самая малость, заставить систему использовать наш резолвер. Для начала выясняем, является ли /etc/resolv.conf симлинком куда-то там:

Если видим такую надпись — делаем так:

Тем самым мы запрещаем всяким NetworkManager-ам менять этот файл. Ну а сам файл создаём и приводим к такому виду:

Если беспокоимся о том, что unbound упадёт и резолв сломается, то оставляем резервом другие резолверы:

Если у вас systemd (ubuntu 16+, debian 8+), то resolv.conf нужно «применять» перезапуском сервиса resolvconf:

Ну а почитать все возможные опции советую на официальном сайте — https://www.unbound.net/documentation/unbound.conf.html, может там ещё что интересное валяется.