Полная обратная проверка DNS: настройка и применение
Forward-confirmed reverse DNS
Проверка FCrDNS: что это, зачем нужна и как работает обратная DNS-запись. Важный параметр для безопасности почты и борьбы со спамом. Соответствие IP и домена.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Forward confirmed reverse DNS (FCrDNS), также известный как full circle reverse DNS, double reverse DNS или iprev, – это конфигурация сетевых параметров, при которой для данного IP-адреса существуют как прямые (имя в адрес), так и обратные (адрес в имя) записи системы доменных имен (DNS), соответствующие друг другу. Это стандартная конфигурация, ожидаемая интернет-стандартами, поддерживающими множество протоколов, зависящих от DNS. Дэвид Барр опубликовал рекомендацию в RFC 1912 (Informational), советуя администраторам DNS считать это передовой практикой, однако в самом стандарте DNS формальных требований к этому нет. Проверка FCrDNS может обеспечить слабую форму аутентификации, подтверждающую наличие действительной связи между владельцем доменного имени и владельцем сети, которой назначен IP-адрес. Хотя эта аутентификация и слаба, она достаточно надежна для использования в целях создания белых списков, поскольку спамерам и фишерам обычно не удается обойти эту проверку при использовании зараженных компьютеров для спуфинга электронной почты. То есть обратная DNS-запись может быть подтверждена, но обычно она будет принадлежать домену, отличному от заявленного. Использование почтового сервера интернет-провайдера в качестве ретранслятора может решить проблему с обратной DNS, поскольку требуется лишь соответствие прямой и обратной записи для отправляющего ретранслятора, без привязки к полю "От" или домену отправителя пересылаемых сообщений. Другими методами установления связи между IP-адресом и доменом в электронной почте являются Sender Policy Framework (SPF) и запись MX. Интернет-провайдеры, которые не могут или не хотят настроить обратную DNS, создают проблемы для хостов в своих сетях, поскольку не могут поддерживать приложения или протоколы, требующие соответствия обратной DNS соответствующей записи A (или AAAA). Интернет-провайдеры, которые не могут или не хотят предоставлять обратную DNS, в конечном итоге ограничивают возможности своих клиентов эффективно и безопасно использовать предоставляемые ими интернет-услуги.
Forward confirmed reverse DNS (FCrDNS), also known as full circle reverse DNS, double reverse DNS, or iprev, is a networking parameter configuration in which a given IP address has both forward (name to address) and reverse (address to name) Domain Name System (DNS) entries that match each other. This is the standard configuration expected by the Internet standards supporting many DNS reliant protocols. David Barr published an opinion in RFC 1912 (Informational) recommending it as best practice for DNS administrators, but there are no formal requirements for it codified within the DNS standard itself. A FCrDNS verification can create a weak form of authentication that there is a valid relationship between the owner of a domain name and the owner of the network that has been given an IP address. While weak, this authentication is strong enough that it can be used for whitelisting purposes because spammers and phishers cannot usually by pass this verification when they use zombie computers for email spoofing. That is, the reverse DNS might verify, but it will usually be part of another domain than the claimed domain name. Using an ISP's mail server as a relay may solve the reverse DNS problem, because the requirement is the forward and reverse lookup for the sending relay have to match, it does not have to be related to the from field or sending domain of messages it relays. Other methods for establishing a relation between an IP address and a domain in email are the Sender Policy Framework (SPF) and the MX record. ISPs that will not or cannot configure reverse DNS will generate problems for hosts on their networks, by virtue of being unable to support applications or protocols that require reverse DNS agree with the corresponding A (or AAAA) record. ISPs that cannot or will not provide reverse DNS ultimately will be limiting the ability of their client base to use Internet services they provide effectively and securely.
Приложения
Большинство почтовых агентов передачи (серверное программное обеспечение) используют проверку FCrDNS и, если обнаружено допустимое доменное имя, добавляют его в поле заголовка "Received:". Некоторые почтовые агенты передачи выполняют проверку FCrDNS для доменного имени, указанного в командах SMTP HELO и EHLO. Это может нарушать RFC 2821, поэтому электронная почта обычно не отклоняется по умолчанию. Система защиты от подделки электронной почты Sender Policy Framework использует проверку FCrDNS в своем механизме "ptr:". Однако использование этого механизма "ptr:" не рекомендуется с момента первой стандартизации SPF в 2006 году (в RFC 4408). Некоторые спам-фильтры для электронной почты используют проверки FCrDNS как метод аутентификации доменных имен или для целей включения в белый список, как указано, например, в RFC 8601. SpamCop использует проверку FCrDNS, что иногда вызывает проблемы у пользователей SpamCop, которые также являются клиентами интернет-провайдеров, не предоставляющих корректно совпадающие записи DNS и rDNS для почтовых серверов. Некоторые FTP, Telnet и TCP Wrapper серверы выполняют проверки FCrDNS. Некоторые IRC-серверы выполняют проверки FCrDNS для предотвращения злоупотреблений.
Most e mail mail transfer agents (server software) use a FCrDNS verification and if there is a valid domain name, put it into the "Received:" trace header field. Some e mail mail transfer agents will perform FCrDNS verification on the domain name given on the SMTP HELO and EHLO commands. This can violate RFC 2821 and so e mail is usually not rejected by default. The Sender Policy Framework email anti forgery system uses a FCrDNS check in its "ptr:" mechanism. However, the use of this "ptr:" mechanism is discouraged since the first standardization of SPF in 2006 (in RFC 4408). Some e mail spam filters use FCrDNS checks as an authentication method for domain names or for whitelisting purposes, according to RFC 8601, for example. SpamCop uses the FCrDNS check, which sometimes causes problems for SpamCop users who are also customers of Internet service providers who do not provide properly matching DNS and rDNS records for mail servers. Some FTP, Telnet and TCP Wrapper servers perform FCrDNS checks. Some IRC Servers perform FCrDNS checks to prevent abuse.