Төңкерілген DNS (FCrDNS): IP-адресінің DNS жазбаларының сәйкестігі – қауіпсіздік пен электрондық поштаны сақтау үшін маңызды. Стандарттар мен артықшылықтары.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Кіріспе
Forward confirmed reverse DNS (FCrDNS), сондай-ақ толық шеңберлі кері DNS, қос кері DNS немесе iprev деп аталады, бұл белгілі бір IP-адрестің бір-біріне сәйкес келетін Domain Name System (DNS) жазбалары бар (атауынан мекенжайына) және кері (мекенжайынан аты) бар желілік параметрлерді конфигурациялау болып табылады. Бұл көптеген DNS-ке тәуелді протоколдарды қолдайтын Интернет стандарттары күтетін стандартты конфигурация. Дэвид Барр RFC 1912 (Ақпараттық) құжатында оны DNS әкімшілері үшін ең жақсы тәжірибе ретінде ұсынатын пікір жариялады, бірақ DNS стандартының өзінде осы талаптар ресми түрде кодификацияланбаған. FCrDNS тексеруі домендік атаудың иесі мен IP-адресті алған желінің иесі арасындағы жарамды байланыс бар екенін растаудың әлсіз түрін жасауы мүмкін. Бұл аутентификация әлсіз болғанымен, спамшылар мен фишерлер электрондық пошта адрестарын жалғандау үшін зомби-компьютерлерді қолданғанда осы тексеруден өте алмайтындықтан, оны ақ тізімге енгізу үшін жеткілікті күшті. Яғни, кері DNS расталуы мүмкін, бірақ әдетте ол талап етілген домендік атаудан өзге доменнің бөлігі болады. ISP-нің пошта серверін реле ретінде пайдалану кері DNS мәселесін шеше алады, себебі жіберу релесі үшін алға және кері іздеу сәйкес келуі керек, бірақ ол ретрансляцияланатын хабарламалардың "From" өрісіне немесе жіберу доменіне байланысты болуы міндетті емес. Электрондық поштада IP-адресті және доменді байланыстырудың басқа әдістері – Sender Policy Framework (SPF) және MX жазбасы. Кері DNS-ді конфигурациялай алмайтын немесе конфигурациялауға құзыретсіз ISP-лер өз желілеріндегі хосттар үшін мәселелер тудырады, себебі олар кері DNS-ті тиісті A (немесе AAAA) жазбасымен сәйкес келуді талап ететін қосымшаларды немесе протоколдарды қолдауға қабілетсіз болады. Кері DNS-ді ұсына алмайтын немесе ұсынудан бас тартатын ISP-лер, нәтижесінде өз клиенттеріне ұсынатын интернет-қызметтерді тиімді және қауіпсіз пайдалану мүмкіндігін шектейді.
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 тексеруін қолданады және егер жарамды домендік атау болса, оны "Қабылданды:" іздеу баслығының өрісіне қосады. Кейбір электрондық поштаны жіберу агенттері SMTP HELO және EHLO командаларында берілген домендік атау бойынша FCrDNS тексеруін жүргізеді. Бұл RFC 2821 талаптарын бұзуы мүмкін, сондықтан электрондық пошта әдетте автоматты түрде қабылданбайды. Sender Policy Framework электрондық поштаның жалғандығына қарсы жүйесі өзінің "ptr:" механизмінде FCrDNS тексеруін пайдаланады. Дегенмен, SPF-тің 2006 жылғы алғашқы стандартталуынан (RFC 4408) бері осы "ptr:" механизмін пайдалану ұсынылмайды. Кейбір электрондық пошта спам сүзгілері 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.