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

У меня есть очень примитивный сервер имен, написанный на Python, который использует только socket и dnslib, в основном предназначенные для ответов на запросы Let's Encrypt DNS-01, а также пару записей A для экспериментальных целей.

Мой вопрос в том, что должен ответить сервер имен, когда запрос достигает сервера, но он не содержит соответствующих данных, на которые сервер хочет ответить?

Должен ли он просто игнорировать это?

Я спрашиваю, потому что получаю запросы на ANY leth.cc, которые, по-видимому, используются для атак с усилением DNS. Прежде чем заметить это, я отвечал на запросы с пустым разделом ответов, теперь я ничего не отправляю обратно по указанному адресу.

Я изменил с

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
sock_dns.sendto(a.pack(), addr)

to

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
if len(a.rr) > 0:
 sock_dns.sendto(a.pack(), addr)

Это приемлемое поведение?


Принимая во внимание ответ Патрика Мевзека, я изменил его на

data, addr = sock_dns.recvfrom(1024)
q = dnslib.DNSRecord.parse(data)
a = q.reply()
# add an answer if query is relevant
# a.add_answer(*dnslib.RR.fromZone(qname + " 30 IN TXT " + verification_code))
if not a.rr:
  a.header.rcode = dnslib.RCODE.REFUSED
sock_dns.sendto(a.pack(), addr)

Хотя это может быть правильным ответом для действительных клиентов, при нормальной работе ни один запрос для leth.cc никогда не должен доходить до сервера, так как нет ничего, указывающего на мой сервер имен, кроме записей NS, которые я настроил в онлайн-интерфейсе конфигурации DNS регистраторов. Это их серверы имен указывают, что клиент должен пойти и попросить мой сервер имен дать ответ на более конкретные запросы, на которые они не могут ответить.

Но в случае запроса leth.cc, доходящего до моего сервера, этот запрос, скорее всего, исходит из очень необычного источника. Можно ли по-прежнему отвечать на эти запросы с помощью RCODE.REFUSED, или запрос мог быть подделан таким образом, что addr содержал адрес, с которым не следует связываться, чтобы избежать DDOS-атаки на этот адрес? В конце концов, это атака усиления; это что-то вроде отраженной DDOS-атаки? Я не возражаю против того, чтобы МОЙ сервер имен подвергался DDOS-атаке (это мое дело решать), я просто не хочу, чтобы он участвовал в ней, если это возможно.

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


person Daniel F    schedule 13.08.2018    source источник


Ответы (1)


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

Возможные коды возврата определены в https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-6 и в основном определен в RFC 1035.

Думаю, что для вашего случая у вас есть именно то, что вам нужно: ОТКАЗАНО

Это определяется как таковое:

Сервер имен отказывается выполнять указанную операцию по причинам политики. Например, сервер имен может не желать предоставлять информацию конкретному запрашивающему лицу, или сервер имен может не желать выполнять определенную операцию (например, передачу зоны) для определенных данных.

Теперь ваш сервер имен является авторитетным для некоторых доменных имен. Если он получает запрос для других, он должен сказать, что он не является авторитетным для них, которым является NXDOMAIN или точно RCODE 3, определенный как таковой в RFC 1035:

Ошибка имени - имеет значение только для ответов от авторитетного сервера имен, этот код означает, что доменное имя, указанное в запросе, не существует.

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

DDOS будет, если вы ответите на запрос с еще большим ответом (например, если бы вы попытались ответить на ANY, даже для имен, на которые вы уполномочены), поскольку здесь жертва может получить много трафика, в то время как злоумышленник будет Мне нужно очень немногое, чтобы послать вам.

Кроме того, ANY - это скорее (плохой) инструмент для устранения неполадок, предназначенный для рекурсивных серверов имен (например, «дайте мне текущее состояние вашего кеша для определенной метки»), а не для авторитетных. В настоящее время есть работы по его полной отмене: https://blog.cloudflare.com/what-happened-next-the-deprecation-of-any/

Теперь вы, кажется, больше говорите об операционных проблемах и DDOS-атаках. Это еще один случай, когда даже ответ может быть дорогостоящим. Текущие серверы имен реализуют механизм RRL для «ограничения скорости ответа», в основном за счет уменьшения скорости ответов. Взгляните на эту статью для Bind, в которой представлена ​​эта функция: https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Response-Rate-Limiting.html

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

person Patrick Mevzek    schedule 13.08.2018
comment
Спасибо, я расширил свой вопрос на основе вашего ответа. Не могли бы вы еще раз взглянуть на это? Речь идет о различии между получением запросов для моего домена и доменов, которые не находятся под моим контролем / владением. - person Daniel F; 13.08.2018
comment
@DanielF см. Обновление. TL; DR: возвращать NXDOMAIN (RCODE 3) для любого запроса по доменным именам, для которых вы не являетесь уполномоченным. Возврат только кода ошибки не открывает возможности для атак усиления. Обычно это происходит с рекурсивными серверами имен, которые отвечают на ЛЮБЫЕ запросы. - person Patrick Mevzek; 13.08.2018
comment
Спасибо. Итак, независимо от того, что я решу ответить: если я отвечу, возможно ли, что мой сервер имен будет задействован для участия в атаке на этот адрес в addr? Он исходит из data, addr = sock_dns.recvfrom(1024); Могу ли я гарантировать, что addr не имеет IP-адреса кого-либо, кто может стать целью, но это точно адрес отправителя запроса? - person Daniel F; 13.08.2018
comment
Смотрите мое обновление (мы пересекли биржи). DNS использует UDP: у вас НЕТ гарантии, что исходный IP-адрес является допустимым. Тебе нужно с этим жить. Контрмеры включают ограничение скорости (не стандарт, см. Ссылку в ответе) и файлы cookie DNS (см. thesecuritybuddy.com/securing-dns/) - person Patrick Mevzek; 13.08.2018
comment
Также помогает, если ваш вышестоящий интернет-провайдер действительно реализует BCP38 (см. bcp38.info/index.php/Main_Page), который в основном удостоверяется, что трафик с IP-адресов действительно поступает из соответствующей исходной сети (AS). Что, к сожалению, недостаточно широко распространено (как и вакцины, они помогают другим, а также вам, поэтому иногда люди не хотят этого делать). - person Patrick Mevzek; 13.08.2018