` dig -4 `возвращает IPv6-адрес

  • Вместо суперпользователя -super -вы можете ограничить root. видеть Какие существуют способы установки прав доступа к файлам и т. д. в gnu/linux

  • Также есть AppArmor и SELinux.

  • И/или настроить sudo, чтобы не отдавать полные привилегии суперпользователя. Вы можете настроить его так, чтобы пользователь мог запускать только предварительно -согласованные команды с предварительно -согласованными аргументами.

  • Вы также можете использовать виртуализацию для ограничения root:

    • cgroups, namespaces, chroot и т. д. (Docker делает это)
    • Зен
    • Виртуальный бокс
  • См. такжеetckeeper:эта версия инструмента управляет каталогом /etcи синхронизируется с apt. По умолчанию это небезопасно, вредоносная установка может саботировать его, но вы также можете заставить его отправлять изменения в хранилище резервных копий, защищенное огнем -.

  • Использование системы контроля версий в целом с огнестойким -защищенным хранилищем резервных копий. Это помогает при случайных, преднамеренных повреждениях и сбоях оборудования.


  • Репозитории резервных копий, защищенные брандмауэром, могут находиться на другой машине, в Интернете, на другой виртуальной машине (или на хосте виртуальной машины ).

0
05.09.2020, 07:43
1 ответ

Это вы делаете что-то не так. ☺

Описанный эффект -c INсвязан с тем, что вы сделали это неправильно. Оба запроса явно были IN, так как в любом случае это класс по умолчанию. Но обратите внимание, что тот, который не удался, искал доменное имя TXT., а не доменное имя o-o.myaddr.l.google.com.. Вы перепутали digи заставили его думать, что аргумент типа записи ресурса был доменным именем.

Обратите внимание, что обработка type domain-nameв качестве аргументов является костылем для людей, которые не читали руководство dig, где четко указано, что порядок domain-name type class. ☺ (У узла DNS kdigнемного другой порядок domain-name class typeв руководстве, но он также пытается справиться с людьми, которые приводят аргументы не в ту сторону.)

Также обратите внимание, что в руководстве рекомендуется явно использовать -tи -q, чтобы избежать двусмысленности с доменными именами (верхнего -уровня ).

-4на самом деле не имеет к этому никакого отношения. Это просто заставляет его говорить IPv4 с DNS-сервером. Но вы ошиблись DNS-сервером.

Это @8.8.8.8важный фактор.

Предполагается, что этот запрос будет выполняться непосредственно на контентных DNS-серверах Google. Они (на момент написания )в мире IPv4:

% dnsqr ns l.google.com. | awk '/answer:/ {print $5}' | xargs dnsip
216.239.34.10
216.239.32.10
216.239.36.10
216.239.38.10
%

Эти контентные DNS-серверы возвращают исходный IP-адрес и любую информацию EDNS0 в виде TXTнабора записей ресурсов при запросе этого доменного имени.

Вместо этого вы выполняете это против общедоступных разрешающих прокси DNS-серверов Google. Вы получаете информацию EDNS0 и исходный IP-адрес внутренней части конкретного используемого прокси-сервера(8.8.8.8, являющегося произвольным ), а не собственным IP-адресом вашей машины. DNS-сервер общедоступного прокси-сервера Google контактирует с контентным DNS-сервером Google, поэтому именно IP-адрес и информация EDNS0 этой транзакции возвращаются контентным DNS-сервером в наборе записей ресурсов обратно в Google. прокси и оттуда с прокси к вам.

Тот факт, что TTL составляет 54 секунды вместо 60 секунд, которые использует контент DNS-сервер Google, является важной подсказкой здесь, как и тот факт, что это не ваш ] IPv6-адрес.

Причина того, что сокращенные формы использования digи host, приведенные в большинстве документов, без явного направления транзакции на DNS-серверы контента Google, обычно работают, заключается в том, что она проходит через локальный разрешение прокси-сервера DNS на вашем собственном компьютере , чьи обратные -конечные запросы, конечно же, исходят с IP-адреса вашей машины. Наличие локального разрешающего прокси-сервера DNS было и остается нормой в мире Unix и Linux. Это не (не -сервер )Microsoft Windows.

Однако :Использовать чужой разрешающий прокси-сервер DNS путем переадресации со своего собственного прокси-сервера DNS, настроив чужой сервер в /etc/resolv.conf,или (, как здесь ), явно направив запрос куда-то вроде 8.8.8.8/1.1.1.1/9.9.9.9, и вы получите информацию о задней -стороне этого чужого прокси-сервера DNS.

% DNSCACHEIP=1.1.1.1 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
105 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 36 TXT \0342400:cb00:63:1024::a29e:2192
%
% DNSCACHEIP=1.0.0.1 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
105 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 12 TXT \0342400:cb00:63:1024::a29e:2192
%
% DNSCACHEIP=9.9.9.9 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
71 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 60 TXT \0212620:171:fa:f0::7
%

Вас не должно шокировать, что задняя часть -разрешающего прокси-сервера DNS, запущенного CloudFlare, имеет IPv6-адрес, назначенный CloudFlare -. ☺

Некоторые из них даже имеют несколько обратных -конечных IP-адресов, либо потому, что они действительно имеют это, либо (что более вероятно )по мере продвижения произвольной рассылки. (Между некоторыми из них я сделал небольшую паузу.)

% DNSCACHEIP=8.8.8.8 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
114 bytes, 1+2+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 59 TXT \01574.125.181.14
answer: o-o.myaddr.l.google.com 59 TXT "edns0-client-subnet\040Ahem!
% DNSCACHEIP=8.8.8.8 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
124 bytes, 1+2+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 59 TXT \0272a00:1450:400c:c01::106
answer: o-o.myaddr.l.google.com 59 TXT "edns0-client-subnet\040Ahem!
% DNSCACHEIP=8.8.8.8 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
124 bytes, 1+2+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 59 TXT \0272a00:1450:400c:c01::107
answer: o-o.myaddr.l.google.com 59 TXT "edns0-client-subnet\040Ahem!
%
% DNSCACHEIP=9.9.9.10 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
71 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 60 TXT \0212620:171:fa:f0::3
% DNSCACHEIP=9.9.9.10 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
66 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 31 TXT \01474.63.26.248
% DNSCACHEIP=9.9.9.10 dnsqr txt o-o.myaddr.l.google.com
16 o-o.myaddr.l.google.com:
66 bytes, 1+1+0+0 records, response, noerror
query: 16 o-o.myaddr.l.google.com
answer: o-o.myaddr.l.google.com 60 TXT \01474.63.26.250
%

dnsqrнесколько наивно сбрасывает TXTзаписей ресурсов. Эти восьмеричные escape-последовательности - это просто байт длины. Я, наверное, должен исправить это. ☺

Дополнительная литература

3
18.03.2021, 23:07

Теги

Похожие вопросы