О функционале DHCP/BOOTP, разумеется. Вообще, у него несколько иное назначение.
Если эти фичи, в итоге, не уменьшают, а увеличивают приватность, тогда это только плюс.
Безусловно. Только мне, как и разработчикам Unbound, не понятно зачем HTTP нужен в DNS сервере. Как показано в статье, при желании вопрос решается написанием простой прослойки при помощи любого удобного инструмента.
Например, тем, что, во-первых, он тоже не умеет полноценное кэширование (насколько я помню, он запоминает только негативные результаты), не говоря уже про префетч, и является только форвардером, а, во-вторых, имеет избыточный для данной задачи функционал.
DoH в Unbound все равно нет
И, скорее всего, не будет, потому что это больше про HTTP, чем про DNS. И слава богу.
В случае Unbound нужда в дополнительных прокси, каковым и является Stubby, отсутствует.
Возвращаясь к теме статьи. Для DoH желательно иметь DNS ресолвер который будет максимально быстро отвечать на запросы и Unbound с его кэшем в памяти и, кстати, префетчем обновлений кэшированных данных, просто идеальный кандидат.
Сам DNS, вообще-то, по умолчанию использует UDP.
DNScrypt, несмотря на то, что он был первым относительно популярным решением по защите DNS трафика, я считаю классическим примером оверинжениринга, дурно скроенным и сложным в настройке и поддержке. Использование стандартных DNSSEC/DANE в связке с DoT делает его не нужным. Писать об этом здесь подробно вряд ли имеет смысл.
В данном случае тогда не понятно зачем весь этот оверхед с инскапсуляцией пакетов DNS в HTTP и затем в TLS (DoH), когда можно обойтись прямой DNS в TLS (DoT).
То есть в случае защиты DNS трафика на уровне сервера DoH избыточен и куда как лучше использовать DoT.
Но все равно придется форвардить трафик на публичные днс провайдеры
Не придётся. То есть можно, но зачем это делать при наличии собственного рекурсивного DNS да ещё и с кэшем?
Подскажите, есть ли смысл дома поднять unbound?
Смысл есть.
Схема зависит от вашего случая. Оптимально поднять Unbound локально (вар. — в локальной сети), а на нём использовать форвадинг к серверу(ам) с поддержкой DNS-over-TLS. Опять же, можете использовать второй Unbound расположенный в юрисдикции не столь высокодуховных стран, как, к примеру, Россия или Иран.
В случае настройки без forwarders в том, что вы получаете данные из первых рук, а не через DNS провайдера / CDN / Public DNS.
Шифрование это другой аспект, но Unbound умеет и его тоже (см. Безопасность и защита DNS трафика). Вопрос в том, умеют ли его опрашиваемые сервера.
Безопасность ещё и может обеспечиваться через DNSSEC для доменов, его использующих. Unbound, разумеется, его поддерживает.
constb
Unbound это кэширующий рекурсивный DNS сервер. Соответственно, запрос разворачивается от корневых DNS серверов через TLD непосредственно к DNS обслуживающим конкретный домен. Использование собственного DNS, в данном случае через DoH API, сервера это попытка избежать контроля всякого рода, в том числе и со стороны CDN, для повышения безопасности и приватности.
В общем, всё выглядит так, что мэйджоры спят и видят как заполучить ещё и данные с пользовательских DNS для улучшения своей аналитики (читай — повышения прибылей), и, поэтому, всячески форсят внедрение DoH.
и DoT пока не панацея
DoH требует модификации всего клиентского софта, в то время как DoT модификации системы и вообще не затрагивает прикладное программное обеспечение.
С такой прозорливостью (право слово удивительной — предвидеть перспективы DEC и её архитектуры на десятилетия вперёд) вы должны нынче быть, ну, как минимум, мультимиллионером.
Для всех остальных же в 80-х годах это было совершенно не очевидно.
ЕС ПЭВМ 184х, то нескольких десятков тысяч за экземпляр
Да, вполне возможно. Мне тогда цифру называли и я помню что ох… ох как удивился, но за давностью лет уже не припомню, кроме того что порядок был другой. Сама машина, что я работал, была в двухкорпусном исполнении с цветным CGA монитором т.е. скорей всего клон XT. Видимо EC 1841, как я тут погуглил по-быстрому.
Наиболее массовыми, я так понимаю, были классы на базе БК-0010 с головным ДВК в качестве сервера. Но да, 8-битные Ямахи были по мультимедийным возможностям круче.
Ну, например, потому, что очень дорого. Отечественные клоны IBM PC (точную маркировку не помню уже, боюсь соврать) во второй половине 80x выпускались, но встречались in the wild нечасто и, стоили каких-то тысяч рублей за экземпляр, в то время, как БК и УКНЦ стоили от примерно 700 и до 1000 руб. за комплект с монитором и сетью.
Сколько стоила Yamaha я не знаю, поскольку в свободной продаже (ну насколько она была свободной во время тотального советского дефицита) их никогда не было.
Определение дано, но его вы, видимо, не поняли.
В этой ситуации, действительно, дискутировать будет самоубийственно.
Но к рекомендации, всё же, прислушайтесь. Чтобы больше не попадать впросак.
Безусловно потому, что это самоочевидно. Границу провести очень просто. Если в языке есть абстракция от машинных кодов, за исключением мнемонических обозначений для упрощения восприятия, то это язык высокого уровня. Конец истории.
В этом плане даже продвинутые ассемблеры могут быть не вполне языками низкого уровня? поскольку включают некоторые конструкции над машинным кодом.
В C нет ничего от языка низкого уровня, за исключением атавизмов (впрочем, полезных) вроде автоинкремента.
Мои вот требования
Ваши требования не отменяют необходимости понимания базовых вещей.
Я бы порекомендовал автору, если не пописать в/на машинных кодах / Ассемблере / Форте / С, то, хотя бы, почитать побольше для понимания проблематики.
C это, безусловно, язык высокого уровня. Ассемблер — низкого. Даже Форт можно считать языком низкого уровня только если он работает на форт-процессоре (таких хватает), хотя, безотносительно, у него куда как больше оснований чем у С чтобы на это претендовать.
На тот момент, когда я смотрел dnsmasq кэшировать, как я и написал выше, он не умел.
О функционале DHCP/BOOTP, разумеется. Вообще, у него несколько иное назначение.
Безусловно. Только мне, как и разработчикам Unbound, не понятно зачем HTTP нужен в DNS сервере. Как показано в статье, при желании вопрос решается написанием простой прослойки при помощи любого удобного инструмента.
Например, тем, что, во-первых, он тоже не умеет полноценное кэширование (насколько я помню, он запоминает только негативные результаты), не говоря уже про префетч, и является только форвардером, а, во-вторых, имеет избыточный для данной задачи функционал.
И, скорее всего, не будет, потому что это больше про HTTP, чем про DNS. И слава богу.
В случае Unbound нужда в дополнительных прокси, каковым и является Stubby, отсутствует.
Возвращаясь к теме статьи. Для DoH желательно иметь DNS ресолвер который будет максимально быстро отвечать на запросы и Unbound с его кэшем в памяти и, кстати, префетчем обновлений кэшированных данных, просто идеальный кандидат.
Отказать.
Сам DNS, вообще-то, по умолчанию использует UDP.
DNScrypt, несмотря на то, что он был первым относительно популярным решением по защите DNS трафика, я считаю классическим примером оверинжениринга, дурно скроенным и сложным в настройке и поддержке. Использование стандартных DNSSEC/DANE в связке с DoT делает его не нужным. Писать об этом здесь подробно вряд ли имеет смысл.
В данном случае тогда не понятно зачем весь этот оверхед с инскапсуляцией пакетов DNS в HTTP и затем в TLS (DoH), когда можно обойтись прямой DNS в TLS (DoT).
То есть в случае защиты DNS трафика на уровне сервера DoH избыточен и куда как лучше использовать DoT.
Да, всё верно. Локальный Unbound обращается по защищённому каналу к облачному.
Эта жалкая клоунада в исполнении импотентов с сопутствующими разрушениями всего вокруг уже порядком поднадоела.
Не придётся. То есть можно, но зачем это делать при наличии собственного рекурсивного DNS да ещё и с кэшем?
Смысл есть.
Схема зависит от вашего случая. Оптимально поднять Unbound локально (вар. — в локальной сети), а на нём использовать форвадинг к серверу(ам) с поддержкой DNS-over-TLS. Опять же, можете использовать второй Unbound расположенный в юрисдикции не столь высокодуховных стран, как, к примеру, Россия или Иран.
В случае настройки без forwarders в том, что вы получаете данные из первых рук, а не через DNS провайдера / CDN / Public DNS.
Шифрование это другой аспект, но Unbound умеет и его тоже (см.
Безопасность и защита DNS трафика). Вопрос в том, умеют ли его опрашиваемые сервера.
Безопасность ещё и может обеспечиваться через DNSSEC для доменов, его использующих. Unbound, разумеется, его поддерживает.
constb
Unbound это кэширующий рекурсивный DNS сервер. Соответственно, запрос разворачивается от корневых DNS серверов через TLD непосредственно к DNS обслуживающим конкретный домен. Использование собственного DNS, в данном случае через DoH API, сервера это попытка избежать контроля всякого рода, в том числе и со стороны CDN, для повышения безопасности и приватности.
В общем, всё выглядит так, что мэйджоры спят и видят как заполучить ещё и данные с пользовательских DNS для улучшения своей аналитики (читай — повышения прибылей), и, поэтому, всячески форсят внедрение DoH.
DoH требует модификации всего клиентского софта, в то время как DoT модификации системы и вообще не затрагивает прикладное программное обеспечение.
С такой прозорливостью (право слово удивительной — предвидеть перспективы DEC и её архитектуры на десятилетия вперёд) вы должны нынче быть, ну, как минимум, мультимиллионером.
Для всех остальных же в 80-х годах это было совершенно не очевидно.
Да, вполне возможно. Мне тогда цифру называли и я помню что ох… ох как удивился, но за давностью лет уже не припомню, кроме того что порядок был другой. Сама машина, что я работал, была в двухкорпусном исполнении с цветным CGA монитором т.е. скорей всего клон XT. Видимо EC 1841, как я тут погуглил по-быстрому.
Наиболее массовыми, я так понимаю, были классы на базе БК-0010 с головным ДВК в качестве сервера. Но да, 8-битные Ямахи были по мультимедийным возможностям круче.
Ну, например, потому, что очень дорого. Отечественные клоны IBM PC (точную маркировку не помню уже, боюсь соврать) во второй половине 80x выпускались, но встречались in the wild нечасто и, стоили каких-то тысяч рублей за экземпляр, в то время, как БК и УКНЦ стоили от примерно 700 и до 1000 руб. за комплект с монитором и сетью.
Сколько стоила Yamaha я не знаю, поскольку в свободной продаже (ну насколько она была свободной во время тотального советского дефицита) их никогда не было.
Ждём на Хабре статьи от астрологов, гомеопатов и прочих уфологов.
Определение дано, но его вы, видимо, не поняли.
В этой ситуации, действительно, дискутировать будет самоубийственно.
Но к рекомендации, всё же, прислушайтесь. Чтобы больше не попадать впросак.
Безусловно потому, что это самоочевидно. Границу провести очень просто. Если в языке есть абстракция от машинных кодов, за исключением мнемонических обозначений для упрощения восприятия, то это язык высокого уровня. Конец истории.
В этом плане даже продвинутые ассемблеры могут быть не вполне языками низкого уровня? поскольку включают некоторые конструкции над машинным кодом.
В C нет ничего от языка низкого уровня, за исключением атавизмов (впрочем, полезных) вроде автоинкремента.
Ваши требования не отменяют необходимости понимания базовых вещей.
Я бы порекомендовал автору, если не пописать в/на машинных кодах / Ассемблере / Форте / С, то, хотя бы, почитать побольше для понимания проблематики.
C это, безусловно, язык высокого уровня. Ассемблер — низкого. Даже Форт можно считать языком низкого уровня только если он работает на форт-процессоре (таких хватает), хотя, безотносительно, у него куда как больше оснований чем у С чтобы на это претендовать.