The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Инициатива DNS flag day 2020 для решения проблем с фрагментацией и поддержкой TCP

01.10.2020 11:01

Сегодня ряд крупных DNS-сервисов и производителей DNS-серверов проведут совместное мероприятие DNS flag day 2020, призванное сфокусировать внимание на решении проблем с IP-фрагментацией при обработке DNS-сообщений большого размера. Это второе подобное мероприятие, в прошлом году "DNS flag day" был сосредоточен на корректной обработке запросов EDNS.

Участники инициативы DNS flag day 2020 призывают зафиксировать рекомендованные размеры буферов для EDNS до значений на уровне 1232 байтов (размер MTU 1280 минус 48 байт для заголовков), а также перевести обработку запросов по TCP в разряд обязательно поддерживаемых на серверах. В RFC 1035 обязательной помечена только поддержка обработки запросов по UDP, а TCP указан как желательный, но не обязательный для работы. Новые RFC 7766 и RFC 5966 явно относят TCP к числу обязательных возможностей, необходимых для корректной работы DNS. В рамках проводимой инициативы предлагается форсировать переход от отправки запросов по UDP к применению TCP в случаях, когда установленного размера буфера EDNS недостаточно.

Предложенные изменения избавят от путаницы с выбором размера буфера EDNS и решат проблему с фрагментацией больших UDP-сообщений, обработка которых нередко приводит к потере пакетов и таймаутам на стороне клиента. На стороне клиента размер буфера EDNS будет постоянным, а большие ответы сразу будут отправляться клиенту по TCP. Исключение отправки больших сообщений по UDP также решит проблемы с отбрасыванием больших пакетов на некоторых межсетевых экранах и позволит блокировать атаки по отравлению кэша DNS, основанные на манипуляции фрагментированными UDP-пакетами (при разбиении на фрагменты, второй фрагмент не включает заголовок с идентификатором, поэтому может быть подделан для чего достаточно только чтобы совпадала контрольная сумма).

Начиная с сегодняшнего дня участвующие в инициативе провайдеры DNS, включая CloudFlare, Quad 9, Cisco (OpenDNS) и Google, постепенно поменяют размер буфера EDNS с 4096 до 1232 байт на своих DNS-серверах (изменение EDNS будет растянуто на 4-6 недель и со временем будет охватывать всё большее число запросов). Ответы на UDP-запросы, не укладывающиеся в новое ограничение, будут отправляться по TCP. Производители DNS-серверов, включая BIND, Unbound, Knot, NSD и PowerDNS выпустят обновления с изменением размера буфера EDNS по умолчанию с 4096 до 1232 байт.

В конечном счёте, вводимые изменения могут привести к проблемам с резолвингом при обращении к DNS-серверам, DNS-ответы которых по UDP превышают 1232 байт, и которые не могут отправить ответ по TCP. Проведённый в Google эксперимент показал, что изменение размера буфера EDNS практически не повлияет на уровень сбоев - при буфере в 4096 байт число урезаемых запросов UDP составляет 0.345%, а число недостижимых повторных ответов по TCP - 0.115%. При буфере в 1232 байт эти показатели составляют 0.367% и 0.116%. Перевод поддержки TCP в разряд обязательных возможностей DNS приведёт к проблемам при взаимодействии с около 0.1% DNS-серверов. Отмечается, что в современных условиях без TCP работа данных серверов и так нестабильна.

Администраторам авторитетных (authoritative) DNS-серверов следует убедиться, что их сервер отвечает по TCP на сетевом порту 53 и данный TCP-порт не блокируется межсетевым экраном. Авторитетный DNS-сервер также не должен отправлять UDP-ответы, размер которых превышает запрошенный размер буфера EDNS. На самом сервере размер буфера EDNS должен быть установлен в 1232 байт. К резолверам предъявляются примерно такие же требования - обязательная возможность ответа по TCP, обязательная поддержка отправки повторных запросов по TCP при получении урезанного ответа UDP и установка буфера EDNS в 1232 байт.

За настройку размера буфера EDNS в разных DNS-серверах отвечают следующие параметры:

  • BIND
    
        options {
          edns-udp-size 1232;
          max-udp-size 1232;
        };
    
  • Knot DNS
    
          max-udp-payload: 1232
    
  • Knot Resolver
    
        net.bufsize(1232)
    
  • PowerDNS Authoritative
    
        udp-truncation-threshold=1232
    
  • PowerDNS Recursor
    
        edns-outgoing-bufsize=1232
        udp-truncation-threshold=1232
    
  • Unbound
    
          edns-buffer-size: 1232
    
  • NSD
    
          ipv4-edns-size: 1232
          ipv6-edns-size: 1232
    
    
    


    1. Главная ссылка к новости (https://dnsflagday.net/2020/...)
    2. OpenNews: Крупнейшие DNS-сервисы и серверы прекратят поддержку проблемных реализаций DNS
    3. OpenNews: Атака NXNSAttack, затрагивающая все DNS-резолверы
    4. OpenNews: DNS Push-уведомления получили статус предложенного стандарта
    5. OpenNews: Почти половина трафика на корневые DNS-серверы вызвана активностью Chromium
    6. OpenNews: Выпуск DNS-сервера KnotDNS 3.0.0
    Лицензия: CC BY 3.0
    Короткая ссылка: https://opennet.ru/53816-dns
    Ключевые слова: dns
    При перепечатке указание ссылки на opennet.ru обязательно


    Обсуждение (93) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:06, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    флаг зыс щит

    лучше бы запретили провайдерам заворачивать все днс запросы на свои резолверы

     
     
  • 2.2, Аноним (2), 12:19, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Так запретили давно уже. Только конечно же всем пофиг. Следующий вопрос.
     
     
  • 3.6, Аноним4 (?), 12:58, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –7 +/
    Законодательно запретили?
     
     
  • 4.47, Аноним (47), 20:57, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +10 +/
    В библии записали, всё равно грешат
     
     
  • 5.89, Аноним (2), 20:07, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да не возжелай пакета юзера своего на порту пяти десятин третьем.

    Мак. 53:10

     
  • 2.9, Аноним (9), 13:13, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Прикинь, тебе у себя дома запретят указать DNS'ом 192.168.1.1. Будешь исполнять?
     
     
  • 3.11, Аноним (11), 13:27, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Провайдер не мой дом
     
     
  • 4.95, Аноним (95), 16:34, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У вас с провайдером юридический договор, там что написано? Вы же сами разрешили ему подделывать ваш транзитный трафик подписав его.

    Нужна публичная компания «MITM — не подписываем», займитесь на досуге :-)

     
  • 3.13, не то (?), 13:31, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    это никто не запрещает, запрещают заворачивать днс траффик на гипотетический 8.8.8.8 и резолвить его на своем подставном сервере.
     
     
  • 4.49, Аноним (49), 22:06, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Пруфов, конечно, не будет.
     
  • 2.25, бублички (?), 15:00, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    ты какой-то бред пишешь. либо твой провайдер оперирует покруче Кашпировского в паре с Гитлеолм, пригрозив тебе нименуемой и жестокой расправой если вдруг решишь в своей домашней сети поднять собственный кеширующий резолвер. мне видится причина не в провайдерах, а в отсутствии у тебя элементарных представлений о том как работает DNS. разруха не в клозетах, а в головах
     
     
  • 3.40, Moomintroll (ok), 17:56, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    >> лучше бы запретили провайдерам заворачивать все днс запросы на свои резолверы
    > ты какой-то бред пишешь

    Ну вообще-то, зависит от упоротости провайдера.
    Технически проблемы нет завернуть весь DNS-трафик на свои серверы. А на фоне блокировок РКН, это вполне может быть реализовано отдельными особо ретивыми провайдерами.

    > если вдруг решишь в своей домашней сети поднять собственный кеширующий резолвер

    ... он будет кешировать фальшивые ответы серверов провайдера, куда тот завернул весь трафик DNS

    > причина не в провайдерах, а в отсутствии у тебя элементарных представлений о том как работает DNS

    Может Вы нас просветите, что может помешать провайдеру завернуть весь трафик DNS куда ему угодно?

     
     
  • 4.81, Аноним (81), 14:48, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    РФ 8212 не Британия, тут уже давно DPI у каждого провейдера Грубые методы, т... большой текст свёрнут, показать
     
  • 3.46, flkghdfgklh (?), 20:48, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Перенаправление всего 53/udp на свои сервера и резолвинг там это простейший метод исполнения приказов о цензуре в РФ, обычно его используют мелкие провайдеры, которым проблемно сделать иные решения.

    Обходится за счет DNSCrypt, DoH и DoT.

     
     
  • 4.52, Аноним (81), 23:03, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > о цензуре в РФ

    В РФ? Вы ничего не путаете? https://www.opennet.ru/opennews/art.shtml?num=51046

     
     
  • 5.56, flkghdfgklh (?), 23:14, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я ничего не путаю. Я говорю о запрещенной в РФ, но осуществляемой неким РКН цензуре. И именно о ней.
    Будешь отрицать ее существование?

    На Thu, 01 Oct 2020 22:00:04 +0200 в российском цензурном списке сети интернет 375084 строк

    И это чисто строк с урлами и доменами, без учета блокированных целиком подсетей.

     
     
  • 6.75, Аноним (81), 12:57, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Не путайте цензуру и демократические ковровые бом^Wблокировки. Вторые никто не запрещал.
    И флагманом в этой области является отнюдь не ваша любимая РФ.
     
     
  • 7.86, flkghdfgklh (?), 15:10, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не путайте цензуру и демократические ковровые бом^Wблокировки. Вторые никто не запрещал.
    > И флагманом в этой области является отнюдь не ваша любимая РФ.

    Цензура запрещена. Но она осуществляется в РФ.
    А флагманом является Китай, без вопросов. Тот самый Китай на который вы онанируете. Про остальные же страны вы всегда врете и не можете подтвердить своих слов о цензуре.

     
     
  • 8.94, Печаль (?), 11:23, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Там вам выше на цензуру в мелкобритании показали, но это другое да Про цензуру ... текст свёрнут, показать
     
     
  • 9.96, Аноним (95), 16:39, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Давай сначала с терминами определимся 171 Цензура 8212 ограничения либо не... текст свёрнут, показать
     
  • 9.99, flkghdfgklh (?), 18:59, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Нет, не слышал Цензура может осуществляться только государством Частник у себя... текст свёрнут, показать
     
     
  • 10.101, nuclight (??), 20:06, 16/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Только государством Да щазз Нет в определении цензуры ничего такого ... текст свёрнут, показать
     
  • 7.97, Аноним (95), 16:44, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А мы и не путаем парламентарную монархию с президентско-парламентской республикой, это у вас проблемы вечно, с головой видимо.
     
  • 3.79, YetAnotherOnanym (ok), 13:49, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    У как минимум одного опсоса (которым я когда-то пользовался) при исчерпании дневного лимита трафика все DNS-запросы вдруг начинали возвращать один и тот же IP, если туда тыкался броузер с http-запросом, выдавалась страничка о том, что провайдер хочет денег за дополнительный гигабайт. Остальной трафик просто дропался. Возвращалась именно подставная A-record, проверено.
    Впрочем, если вбить нужные IP в /etc/hosts, всё равно трафик на 80 порт перенаправлялся, а остальной дропался.
     
     
  • 4.83, Аноним (81), 14:57, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    NB: если пров начинал перехватывать DNS после исчерпания лимит, это еще не значит, что он это делал до.
    По факту, с _неоплаченным_ трафиком он может делать все, что хочет. Как минимум — блокировать с ICMP port unreachable или TCP reset. То, что он запарился и проинформировал вас о причине проблем — уже сугубо его добрая воля, никто его так делать не обязывал.
     
     
  • 5.88, YetAnotherOnanym (ok), 18:23, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну, скажем так, и до исчерпания лимита он влезал в незашифрованный http-трафик -... большой текст свёрнут, показать
     
  • 2.87, Аноним (87), 18:03, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вообще-то в этом смысл днс, чтобы в каждой подсети был свой днс сервер, а к корневым обращались только крупные провайдеры
     
  • 2.90, Онаним (?), 21:06, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ваш провайдер заворачивает все запросы на свои резолверы?
    Меняйте провайдера.
     

  • 1.3, Аноним (3), 12:32, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Да, надо как-то решить проблему с фрагментацией. А то web-трафик over DNS медленно ходит :D
     
     
  • 2.35, Аноним (-), 16:20, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Вот из-за таких как ты так и живем, ни толку ни плана по маргинализации быдла. Что за человек такой .
     

  • 1.4, б.б. (?), 12:36, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    dns flag na shey day

    dns baraban v ruki day

     
  • 1.5, Аноним (5), 12:46, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    по-моему у вас очепятка - вместо "создать проблем там где их раньше не было" в новости почему-то написано "решить проблемы".

     
     
  • 2.7, Амоним (?), 13:02, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Просто самой проблемы вы не заметили, хотя она в тексте и описана. Вообще-то это дыра в безопасности, причем размеров потрясающих. Подмена ответов днс через фрагментированные ответы человеком в середине. Дальше думайте сами, человек может быть и в звании майора.
     
     
  • 3.8, товарищ майор (?), 13:11, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У моего человека в звании лейтенанта НЕТ никакой проблемы перехватить вашу tcp сессию еще до того как SYN доберется до реального адресата.

    Задача противодействия легко решается другими (штатными) средствами, но мы вам о них - не расскажем.

     
     
  • 4.19, Амоним (?), 14:17, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Действительно, глупость сморозил, этак каждый провайдер творил бы что хотел.
    Но виню я себя в другой ошибке.
     
     
  • 5.80, YetAnotherOnanym (ok), 13:51, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > каждый провайдер творил бы что хотел

    Ты не поверишь...

     
  • 3.18, Аноним (81), 14:01, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > Вообще-то это дыра в безопасности, причем размеров потрясающих. Подмена ответов днс через фрагментированные ответы человеком в середине.

    Восхитительный пример безграмотности.
    Вообще-то, не фрагментированный UDP-ответ подменить легче, чем фрагментированный.

     
  • 3.72, alexrayne (?), 10:45, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    если без звания майора, не менее интересно.
     

  • 1.10, CAE (ok), 13:17, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Получается resolver libc должен открыть два соединения?
    Одно UDP, другое TCP?
     
     
  • 2.14, Аноним (81), 13:32, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Только если у него запрос не укладывается в килобайт.
    Часто вы сталкиваетесь с именами в килобайт длиной?
     
     
  • 3.23, Аноним (23), 14:59, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Длина имени ограничена 256 байтами, запрос в принципе не может быть большим. А вот ответы с кучей записей CNAME и NS, очень даже могут. К тому тут вроде бы речь про DNSSEC, а цифровые подписи огромны!
     
     
  • 4.27, Аноним (81), 15:07, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Резать тяжелые UDP-ответы — вполне нормальная практика, reflection attack не вчера изобрели.

    Я даже вот так делаю (dnsdist):

    addAction(AndRule({MaxQPSIPRule(100, 30), TCPRule(false)}), TCAction())

    чтобы для "клиентов" (точнее, подсетей /30), генерирующих больше 100 RPS, форсировать переход на TCP независимо от размера ответа. На TCP рефлексировать не очень получается)

     
  • 2.17, Аноним (81), 13:59, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, у UDP нет соединений (если не вникать в костыли для stateful NAT & firewalling, о которых ни libc resolver, ни отвечающий ему сервер ничего не знают).
     
     
  • 3.20, CAE (ok), 14:26, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Кстати, у UDP нет соединений (если не вникать в костыли для stateful
    > NAT & firewalling, о которых ни libc resolver, ни отвечающий ему
    > сервер ничего не знают).

    Имею ввиду два сокета открывать и в одном делать connect, ожидая вероятного ответа, а другим делать sendto

     
     
  • 4.26, Аноним (81), 15:01, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, connect() делать только после получения по UDP ответа с флагом TC.

    Чтобы на это напороться, нужно либо запросить QNAME больше 1200 байт, либо получить ответ больше 1200 байт (например, TXT запись). На моих DNS-рекурсорах (обслуживают порядка пятисот машин сотрудников и двухсот серверов) такой случается примерно раз в два часа, при среднем QPS по UDP порядка 150.

     
     
  • 5.31, CAE (ok), 16:05, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Нет, connect() делать только после получения по UDP ответа с флагом TC.

    ok. Это другое дело.

     
  • 5.102, nuclight (??), 20:09, 16/02/2021 [^] [^^] [^^^] [ответить]  
  • +/
    Щито? QNAME больше 256 байтов не бывает, в запросе это может быть только если запросов больше одного, но такое совсем не все сервера и резольверы умеют.
     
  • 2.28, Аноним (28), 15:26, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Получается resolver libc должен открыть два соединения? Одно UDP, другое TCP?

    Я, конечно, не настоящий сварщик, но просветите момент: как клиентский хост должен догадаться, что в ответ на запрос через UDP резолвер ответит по TCP? Для установки TCP соединения вроде хендшейк нужен, или уже нет? Кто инициатор сессии по TCP? Хост, резолвер, с какого порта на какой? Непонятно.

     
     
  • 3.30, Нанобот (ok), 16:02, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Насколько я помню, на клиентский udp-запрос сервер отвечает ошибкой "используй tcp", после чего клиент должен повторить свой запрос по tcp
     

  • 1.12, PnD (??), 13:29, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Согласитесь, это безобразие, что вместо того чтобы сразу учиться интегрироваться с cloudFlare API на бесплатный (поначалу) план, всякие Васяны (Джоны Смиты) поднимают свой DNS. Настала пора безобразие это решительно искоренить. Для начала, переведём весь протокол на TCP. Превратив (почти) не требовавший ранее внимания сервис в лютый high-load.
    </sarcasm>
     
     
  • 2.22, Аноним (22), 14:56, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >> Начиная с сегодняшнего дня участвующие в инициативе провайдеры DNS, включая CloudFlare, Quad 9, Cisco (OpenDNS) и Google

    Что вы такое говорите!?
    Это все организации-альтруисты. Они же о нас заботятся!

     

  • 1.15, Аноним (81), 13:54, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    ENDS вообще прикольная штука. Желающим убедиться рекомендую выполнить команду
    host -t txt whoami-ecs.lua.powerdns.org 8.8.8.8
    и внимательно посмотреть на поле netmask в ответе.
     
     
  • 2.16, Аноним (81), 13:57, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Для veteran unix admins и прочих адептов unix way, у которых под рукой только винда: публичные рекурсивные резолверы сдают адрес клиента с точностью до подсети авторитетному серваку.

    Конечно же, это не для слежки, а чтобы геолокация корректно работала.

     
     
  • 3.24, Аноним (22), 15:00, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Методов слежки им и так хватает.
    Это стандартизация рынка "под себя".
     
  • 3.32, Нанобот (ok), 16:10, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Для veteran unix admins и прочих адептов unix way, у которых под рукой только винда

    вообще-то под виндой так тоже можно сделать: nslookup -type=txt whoami-ecs.lua.powerdns.org 8.8.8.8

     
     
  • 4.54, Аноним (81), 23:07, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я не воин юниксвея, а обычная макака-смузихлеб, мне можно не знать тонкостей работы винды.
     
  • 3.42, Аноним (1), 19:25, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    а вот интересно кто и где ведёт базу привязки айпи к гео координатам? похоже все крупные провайдеры юзают некий пул, куда сливают примерные координаты каждого абонента. тот же гугл с точностью до района знает по айпи, а в некоторых странах (на букву У) даже с точностью до улицы.
     
     
  • 4.43, Сейд (ok), 19:47, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    MaxMind
     
     
  • 5.45, Аноним (1), 19:52, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    наверное должен быть стимул провайдерам делиться. хотя бесплатная версия как-то не блещет. наверное "для своих" там база поинтереснее.
     
  • 4.58, flkghdfgklh (?), 23:27, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Есть общедоступная база MaxMind, есть ее платная версия с точностью до райнов Н... большой текст свёрнут, показать
     
  • 4.60, Anonim (??), 00:07, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    гугль ведет свою..все андроиды сливают IP, координаты и все видимые вокруг вай фай точки папе. после суток, иногда двух, прошедших как новый IP приехал на рутер, если к точке ктото цепляется с вендроида, гугл карты начинают открываться спозиционоированной с квартирой аккуратно в середине экрана даже на устройствах ничего не знающих про геолокацию. Если же вендроидов в сети нет (возможно надо еще чтобы небыло других утройств умеющих  определять координаты и гугл браузера, у меня таких вокруг нет, не проверял), то мы довольно долго будем наблюдать дом того абрнента провайдера, кому IP был выдан до нас..

    а максмайд тормозное гумно, его не пнешь, (а не все провайдеры заморачиваются пинанием), он не обновится. за что они денег берут я так и не понимаю. я по их данным уже пол года как в Одинцово переехал. Яндекс так и предлагает чтото в Одинцово, и только Гугл знает правду, у него одинцово быстро закончилось.. (но яндекс приложений вроде почти нет на телефонах, туда стучать некому)

     
     
  • 5.66, flkghdfgklh (?), 01:07, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > гугль ведет свою..все андроиды сливают IP, координаты и все видимые вокруг вай фай точки

    Не все, а только те на которых включены сервисы и ты разрешил это делать. Не обманывай людей.

     
     
  • 6.73, Аноним (73), 12:46, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Нет. Это было бы правдой, если бы оно небыло бы включено по умолчанию...
    Это будет не так в некоторых версиях андроида, где таки можно выключить всё, и у тех, кто сходил в настройки и выключил ВСЕ (на _всех_ устройствах могущих быть в этой вай фай сети, т.к. достаточно одного стукачка, чтобы IP-координаты спалились).. не во всех оно полностью выключается, их там за это попинывают временами и они чинят.. да и в общем 99.9999% пользователей и не выключают даже то что спрашивается при первом включении, а не еще там и там и вот там....
     
     
  • 7.74, flkghdfgklh (?), 12:57, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Нет. Это было бы правдой, если бы оно небыло бы включено по
    > умолчанию...

    А оно и не включено. Это — настройка в аккаунте и она по дефолту ОТКЛЮЧЕНА. Отключена, понимаешь?

     
  • 6.76, Аноним (81), 12:59, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Не все, а только те на которых включены сервисы и ты разрешил это делать. Не обманывай людей.

    То есть на всех, кроме Сяоми и Хуавей. Ну и всяких LineageOS.

     
     
  • 7.85, flkghdfgklh (?), 15:08, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    и ты разрешил это делать
    и ты разрешил это делать
    и ты разрешил это делать
    и ты разрешил это делать
    и ты разрешил это делать
     
  • 3.65, antonimus (?), 00:48, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Конечно же, это не для слежки, а чтобы геолокация корректно работала.

    Ну да, конечно чтобы геолокация. Работала. Корректно. Для получателя. Который запрашивает DNS у "резолвера". Да кому интересен получатель?

     
     
  • 4.77, Аноним (81), 13:00, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Всем интересен получатель. Нынче данные трекинга — один из самых ценных "цифровых товаров".
     
  • 2.68, antonimus (?), 01:11, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    whoami-ecs.lua.powerdns.org - покажет адрес твоей подсети, если он белый.

    host whoami.v4.powerdns.org
    :)

     

  • 1.29, Аноним (23), 15:29, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Ведь ежу же понятно, что огромные пакеты EDNS не влезут в обычные пакеты без фрагментации. И всем известно как отвратно работает фрагментация в IPv4. Нужно было делать новый DNS на отдельном порту, со встроенным механизмом фрагментации и быстрого восстановления потерянных фрагментов. Какой идиот предложил фрагментировать UDP/DNS?
    Инициатива этой компашки тоже понятна, запросы через TCP замедлят DNS раза в три, а у DoH такой проблемы нет, все дружно переходим на DoH. Можно даже избавиться от обычного DNS и прописывать зоны зразу на серверах гугла или другой корпорации, так работать будет быстрее всего.
     
     
  • 2.33, Аноним (33), 16:11, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Какой идиот предложил фрагментировать UDP/DNS?

    Может это была особенность UDP? Нет?

    > у DoH такой проблемы нет, все дружно переходим на DoH

    DoH не замена DNS. DoH по сути - это только зашифрованный туннель до вашего DNS сервера. И нужен он, чтобы ваш провайдер не мог путём мониторинга ваших пакетов узнавать куда вы ходите.

     
     
  • 3.34, Аноним (23), 16:17, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Может это была особенность UDP? Нет?

    В изначальном UDP/DNS был лимит 512 байт, он втискивался даже в ATM.

    > DoH не замена DNS.

    Пока ещё не замена DNS.

     
     
  • 4.82, Аноним (81), 14:52, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >> DoH не замена DNS.
    > Пока ещё не замена DNS.

    Если в браузерах добровольно-принудительно запретить обычный DNS и разрешить работу только с NSA approved DoH providers вполне реально (и процесс уже идет), то весь остальной сетевой софт так порезать весьма проблематично. Поэтому в ближайшие годы DNS продолжит играть значимую роль в структуре Сети.

     
     
  • 5.84, Аноним (23), 15:02, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > то весь остальной сетевой софт так порезать весьма проблематично. Поэтому в
    > ближайшие годы DNS продолжит играть значимую роль в структуре Сети.

    Кому нужен ваш дремучий легаси, когда есть модно-молодёжный PWA? К тому же уже сейчас роутеры учатся использовать DoH в качестве своего резолвера.

     
  • 3.37, Аноним (-), 16:27, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Будто бы это сейчас для людей все сделано. Пусть померает к чертям, не нужен такой "интернет" нормальным людям.
     
  • 3.64, antonimus (?), 00:42, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >И нужен он, чтобы ваш провайдер не мог путём мониторинга ваших пакетов узнавать куда вы ходите.

    Он нужен, чтобы только гугл знал, куда вы ходите. И ИСКЛЮЧИТЕЛЬНО гугл.
    Чтобы провайдер не узнал, есть куча вариантов.
    А вздесь вариант только один - гугл.

     
     
  • 4.67, flkghdfgklh (?), 01:09, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У тебя шапочка из фольги съехала
     
     
  • 5.69, antonimus (?), 02:22, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ой.
     
  • 2.48, deb (?), 21:18, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не переживайте,  в вашей стране скоро запретят DOH и ESNI законодательно. И Вы сможете наслаждаться своим любимым, быстрым и не безопасным udp dns.
     
     
  • 3.55, Аноним (81), 23:10, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Надо держаться европейских трендов (хотя Британия уже не Европа).
     
     
  • 4.57, Аноним (-), 23:18, 01/10/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Разваливается союз..
     
     
  • 5.78, Аноним (81), 13:02, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что вы хотели? Социализма в нем едва ли не больше, чем в СССР 80-х. Одна хорошая холодная война — и капец очередному союзу.
     
     
  • 6.100, flkghdfgklh (?), 19:04, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А что вы хотели? Социализма в нем едва ли не больше, чем
    > в СССР 80-х. Одна хорошая холодная война — и капец очередному
    > союзу.

    Социализма в ЕС нет вообще. Одним из признаков социализма является запрет на частную собственность на средства производства. Нет такого в ЕС и никогда не будет. Ты путаешь социализм(людоедскую идеологию насаждавшуюся советским союзом) и меры социальной поддержки. Это вещи совершенно разные и не родственные. Не путай их.

     

  • 1.51, Аноним (51), 22:55, 01/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    4096 байт было слишком много всем и потому решили что 1232 будет всем в самый раз.
    А по факту сделали костыль в виде EDNS и теперь огребают проблемы с размерами записей и фрагментацией.
    Но ладно бы так. Но они сделали ещё лучше и теперь вместо получения двух фрагментов пакета мы получаем ошибку, устанавливаем TCP соединение, затем повторно посылаем весь запрос заново и снова ждём ответа.
     
     
  • 2.92, Дрочевый напильник (?), 00:44, 03/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну тебе никто не запрещает предложить свой собственный идеальный стандарт для решения всех проблем Вселенной.
     
     
  • 3.98, Аноним (95), 16:54, 06/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть остаётся так как сейчас с 4096
     

  • 1.59, antonimus (?), 00:04, 02/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Сегодня ряд крупных DNS-сервисов и производителей DNS-серверов проведут совместное мероприятие DNS flag day 2020

    А вчера нельзя было?

     
     
  • 2.61, Anonim (??), 00:10, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    00:04, 02/10/2020
    специально для Вас, оно было вчера... :)
     
     
  • 3.63, antonimus (?), 00:28, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это был сарказм.
     

  • 1.70, Соня Мармеладова (?), 08:18, 02/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А как случилось, что MTU стал 1280,а не 1500? Это типа с накидкой VPN?
     
     
  • 2.71, dalco (ok), 10:29, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Из объяснений в первоисточнике я понял, что им, наоборот, нужен минимально возможный mtu. А IPv6 требует не менее 1280.
     
  • 2.91, Онаним (?), 21:09, 02/10/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это с накидыванием говноV6 на вентилятор. Который overbloat как он есть.
     

  • 1.93, Аноним (93), 01:03, 05/10/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Можно хранение DNS в браузере через about:config поставить "сутки" и все проблемы решены.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру