Reverse DNS საფოსტო სერვერისთვის: PTR, FCrDNS და HELO

საფოსტო სერვერის IP მისამართს სჭირდება reverse DNS ჩანაწერი - PTR - რომელიც მისამართს ისევ hostname-ად აქცევს, და ეს hostname პირდაპირი ძებნით იმავე მისამართზე უნდა გადაწყდეს. დიდი მიმღებები ამას ყოველ კავშირზე ამოწმებენ, ხოლო Gmail-ის გამგზავნთა წესები ამას პირდაპირ მოითხოვს. იგივე სახელი უნდა იყოს ის, რომელსაც სერვერი თავის HELO/EHLO მისალმებაში აცხადებს. ეს სამი რამ ერთ ხაზზე დააყენე - PTR, პირდაპირი A ჩანაწერი და HELO სახელი - და მოხსნი ერთ-ერთ ყველაზე გავრცელებულ მიზეზს, რის გამოც საკუთარ სერვერზე გაშვებული ფოსტის წერილებს უარყოფენ ან სპამში აგდებენ. სირთულე ის არის, რომ PTR ჩანაწერი შენი დომენის ზონაში არ არის. ის IP მისამართის მფლობელს ეკუთვნის, ამიტომ მას ჰოსტინგის პროვაიდერის გავლით აყენებ, ან საერთოდ ვერ აყენებ.

რა არის PTR ჩანაწერი#

პირდაპირი DNS სახელებს მისამართებზე ასახავს: mail.example.com-ს აქვს A ჩანაწერი 203.0.113.25. Reverse DNS საპირისპირო მიმართულებით მუშაობს, და ის ჩვეულებრივი DNS ძებნით კეთდება ხის სპეციალურ ნაწილში.

IPv4-ისთვის მისამართი უკუღმა იწერება, ოქტეტ-ოქტეტ, in-addr.arpa-ს ქვეშ:

25.113.0.203.in-addr.arpa.   3600  IN  PTR  mail.example.com.

შებრუნება იმიტომ ხდება, რომ DNS სახელებს მარჯვნიდან მარცხნივ კითხულობს - ყველაზე ზოგადიდან ყველაზე კონკრეტულისკენ - ხოლო IP მისამართებში ყველაზე ზოგადი ნაწილი მარცხნივ წერია. შებრუნება საშუალებას აძლევს in-addr.arpa-ს ხეს, ქსელების საზღვრების გასწვრივ დელეგირდეს: რეგიონული რეესტრი დელეგირებს 203.in-addr.arpa-ს, შემდეგ ბლოკის მფლობელი იღებს 113.0.203.in-addr.arpa-ს და ასე შემდეგ.

IPv6-ისთვის მისამართი სრულ 32 თექვსმეტობით ციფრამდე იშლება, უკუღმა ლაგდება თითო nibble-ით და თავსდება ip6.arpa-ს ქვეშ. 2001:db8::25-ის PTR ცხოვრობს 32 ლეიბლის სიგრძის სახელზე, რომელიც მთავრდება ...8.b.d.0.1.0.0.2.ip6.arpa-ით. ამას ხელით არავინ კრეფს; მათ ხელსაწყოები და პროვაიდერის პანელები აგენერირებენ.

ვინ მართავს reverse DNS-ს#

ეს ის ნაწილია, რომელიც ხალხს აკვირვებს. მისამართის reverse ზონა ეკუთვნის იმას, ვისაც მისამართების ბლოკი გამოეყო - ჩვეულებრივ შენს ჰოსტინგის პროვაიდერს, ინტერნეტ პროვაიდერს ან ღრუბლოვან პლატფორმას. საკუთარი დომენის DNS-ში PTR ჩანაწერს ვერ შექმნი, რადგან in-addr.arpa-ს სახელები შენს დომენში არ არის.

როგორ დააყენებინებ მას, პროვაიდერზეა დამოკიდებული:

• ველი პროვაიდერის მართვის პანელში, ხშირია VPS და ღრუბლოვან პლატფორმებზე - შეიყვან hostname-ს და პროვაიდერი აქვეყნებს PTR-ს, ხშირად მას შემდეგ, რაც შეამოწმებს, რომ შენი პირდაპირი ჩანაწერი უკვე ამ მისამართზე მიუთითებს.
• მხარდაჭერის ტიკეტი, ხშირია dedicated სერვერებზე და პატარა ჰოსტინგებთან.
• reverse ზონის დელეგირება შენს nameserver-ებზე, იმ ორგანიზაციებისთვის, რომლებსაც საკუთარი მისამართების ბლოკები აქვთ. /24-ზე პატარა ბლოკებისთვის RFC 2317 აღწერს CNAME-ზე დაფუძნებულ ხრიკს reverse ზონის ნაწილის დელეგირებისთვის, რომელსაც პროვაიდერები ზოგჯერ იყენებენ.
• მიუწვდომელია სახლის კავშირებზე, გაზიარებულ მისამართებზე და ზოგიერთ კონტეინერულ პლატფორმაზე. მისამართის PTR რჩება ის, რაც მფლობელმა დააყენა, ჩვეულებრივ რაღაც ზოგადი, მაგალითად 203-0-113-25.static.provider.example.

პრაქტიკაში თითო მისამართს თითო PTR აქვს. ერთ მისამართზე რამდენიმე PTR ჩანაწერი ტექნიკურად შესაძლებელია და არათანმიმდევრულ შედეგებს იწვევს, ამიტომ ნუ ითხოვ მათ.

პირდაპირი ძებნით დადასტურებული reverse DNS#

PTR ჩანაწერი თავისთავად ცოტას ამტკიცებს: ნებისმიერს, ვინც reverse ზონას მართავს, შეუძლია ათქმევინოს მას mail.google.com. ამიტომ მიმღებები სრულ წრეს ამოწმებენ, რასაც forward-confirmed reverse DNS (FCrDNS) ან "სრული წრის" DNS ჰქვია:

1. მიმღები ხედავს კავშირს 203.0.113.25-დან.
2. ეძებს PTR-ს: mail.example.com.
3. ეძებს mail.example.com-ის A ჩანაწერს: 203.0.113.25.
4. პირდაპირი პასუხი შეიცავს თავდაპირველ მისამართს, ასე რომ სახელი დადასტურებულია.

თუ მე-3 ნაბიჯი სხვა მისამართს აბრუნებს, ან საერთოდ არაფერს, FCrDNS ვერ გადის. რადგან A ჩანაწერს შენ მართავ, PTR-ს კი პროვაიდერი, სრულ წრეს ორივე ნახევარი სჭირდება: შენს ზონაში შექმენი mail.example.com, რომელიც მისამართზე მიუთითებს, და პროვაიდერს PTR დააყენებინე mail.example.com-ზე. ბევრი პროვაიდერის პანელი სწორედ ამ მიზეზით უარს ამბობს PTR-ის დაყენებაზე, სანამ პირდაპირი ჩანაწერი უკვე არ არსებობს.

HELO სახელი#

როცა შენი სერვერი სხვა საფოსტო სერვერს უკავშირდება, ბანერის შემდეგ პირველი, რასაც ამბობს, არის EHLO (ან ძველი HELO) და მის შემდეგ საკუთარი სახელი:

220 mx.receiver.example ESMTPEHLO mail.example.com250-mx.receiver.example Hello mail.example.com [203.0.113.25]

RFC 5321 მოითხოვს, რომ ეს სახელი იყოს სრული დომენური სახელი (FQDN), ან მისამართის ლიტერალი კვადრატულ ფრჩხილებში, თუ ჰოსტს აზრიანი სახელი არ აქვს. პრაქტიკაში მიმღებები და სპამ-ფილტრები ამოწმებენ, რომ:

• ეს ნამდვილი FQDN-ია - არა localhost, არა შიშველი სიტყვა, როგორიცაა server1, არა კონტეინერის შემთხვევითი hostname.
• ის DNS-ში გადაწყდება, იდეალურ შემთხვევაში დამკავშირებელ მისამართზე.
• ის ემთხვევა PTR-ის სახელს, ან სულ მცირე მასთან თანხვედრაშია.

HELO-სა და PTR-ს შორის შეუსაბამობა თავისთავად მიმღებების უმეტესობაზე ფატალური არ არის, მაგრამ სპამის ქულას ზრდის, ზოგი ფილტრი კი უარყოფს EHLO სახელს, რომელიც საერთოდ არ გადაწყდება. სუფთა მოწყობა ისაა, როცა სამივე სახელი ერთი და იგივეა: HELO სახელი, PTR-ის სამიზნე და A ჩანაწერი, რომელიც IP-ზე უკან მიუთითებს. Stalwart-ში HELO სახელი სერვერის მორგებული hostname-იდან მოდის, და ეს კიდევ ერთი მიზეზია, რომ ის ერთხელ, სწორად, თავიდანვე დააყენო - იხილე Stalwart საფოსტო სერვერის დაყენება.

რას აკეთებენ მიმღებები ამით სინამდვილეში#

წესები განსხვავდება და დიდი პროვაიდერები მათ ცვლიან, მაგრამ ზოგადი სურათი თანმიმდევრულია.

Gmail-ის წესები ყველასთვის, ვინც პირად Gmail ანგარიშებზე აგზავნის, მოითხოვს, რომ გამგზავნ IP-ს ჰქონდეს ვალიდური PTR შესაბამისი პირდაპირი ჩანაწერით; IP-ებიდან, რომლებსაც ის არ აქვთ, წერილები უარიყოფა ან სიჩქარე ეზღუდება. IPv6-ზე Gmail ავთენტიკაციის მიმართ კიდევ უფრო მკაცრია, და სერვერი, რომელსაც IPv6 მისამართი აქვს, IPv6 PTR კი არა, იდუმალი უარყოფების ხშირი წყაროა. თუ შენს სერვერს IPv6 კავშირი აქვს და ამ მისამართისთვის PTR-ს ვერ აყენებ, მოარგე ისე, რომ მხოლოდ IPv4-ით აგზავნოს.

ზოგადი reverse სახელები ცალკე ხსენებას იმსახურებს. სპამ-ფილტრები PTR-ში ეძებენ ისეთ ნიმუშებს, როგორიცაა ციფრები და ტირეები, dyn, dhcp, pool ან cust, რადგან ისინი საცხოვრებელ და დინამიკურ დიაპაზონებს აღნიშნავს. PTR, რომელიც ტექნიკურად დადასტურებულია, მაგრამ ip-203-0-113-25.provider.example-ს ჰგავს, მაინც იკითხება როგორც "ეს საფოსტო სერვერი არ არის". SpamAssassin-ს, ფართოდ გამოყენებულ ფილტრებს შორის უძველესს, სწორედ ამ შემთხვევებისთვის აქვს წესები - RDNS_NONE კავშირისთვის, რომელსაც reverse სახელი არ აქვს, და RDNS_DYNAMIC ისეთისთვის, რომელიც დინამიკურს ჰგავს - და ყველა სხვა ფილტრს თავისი ეკვივალენტები აქვს. თითოეული ქულას ცოტას უმატებს, და წერილზე, რომელიც სხვა მიზეზებით ისედაც ზღვარზეა, ეს ცოტაც საკმარისია.

Reverse DNS არაპირდაპირ blocklist-ებსაც კვებავს. პოლიტიკის სიები, როგორიცაა Spamhaus-ის PBL, აღწერს მისამართების დიაპაზონებს, რომლებზეც მათი მფლობელები ამბობენ, რომ პირდაპირ ფოსტა არ უნდა გაიგზავნოს, და ზოგადი reverse სახელები იმის ნაწილია, თუ როგორ ხდება ამ დიაპაზონების ამოცნობა. სერვერს, რომელიც ასეთი დიაპაზონიდან აგზავნის, ექცევიან როგორც ვირუსით დაინფიცირებულ სახლის კომპიუტერს, რაც არ უნდა კარგად იყოს მისი DNS მორგებული.

რამდენიმე დომენი ერთ სერვერზე#

PTR-ს არ ევალება შენს From: მისამართში მყოფ დომენს დაემთხვეს. სერვერს, რომელიც ფოსტას example.com-ისთვის, example.org-ისთვის და კლიენტის shop.example-ისთვის მასპინძლობს, აქვს ერთი IP, ერთი PTR და ერთი HELO სახელი - ვთქვათ mail.example.com - და ეს ნორმალურია. მიმღებები ამოწმებენ, რომ გამგზავნი ჰოსტი სწორად მორგებული საფოსტო სერვერია, და არა იმას, რომ მას ყველა იმ დომენის სახელი ჰქვია, რომლის სახელითაც აგზავნის. SPF, DKIM და DMARC თითოეულ წერილს თავის დომენს უკავშირებს; ეს კავშირი აღწერილია პოსტში SPF, DKIM და DMARC ახსნილი.

რაც არ უნდა გააკეთო, ეს არის PTR-ის შეცვლის თხოვნა თითოეული დომენისთვის, ან რამდენიმეს დაყენების მცდელობა. ერთი მისამართი, ერთი სახელი, ყველგან თანმიმდევრული.

საპირისპირო სიტუაცია - რამდენიმე ერთმანეთთან დაუკავშირებელი სერვისი ერთ მისამართზე - სწორედ ის ადგილია, სადაც reverse DNS უხერხული ხდება. მისამართს, რომელიც სხვადასხვა კლიენტის ვებსაიტებს, გეიმ სერვერებს და საფოსტო სერვერს მასპინძლობს, მაინც მხოლოდ ერთი PTR შეიძლება ჰქონდეს, და მას მხოლოდ ერთი მათგანის დასახელება შეუძლია. ეს ნაწილობრივ იმის მიზეზია, რომ გაზიარებულ მისამართებზე ფოსტა ჩვეულებრივ relay-ით იგზავნება, და რომ საფოსტო სერვერისთვის უკეთესია, თავის მისამართიდან ფოსტას მხოლოდ ის აგზავნიდეს. თუ იმავე მისამართზე ვებ აპლიკაციაც პირდაპირ აგზავნის ფოსტას, ის საფოსტო სერვერის PTR-სა და რეპუტაციას იზიარებს, და ნებისმიერი სპამი, რომელსაც ის გაგზავნის, ორივეს ჩაეთვლება.

Reverse DNS-ის შემოწმება#

# The PTR for an address$ dig +short -x 203.0.113.25mail.example.com.# The forward record for that name: should include the same address$ dig +short A mail.example.com203.0.113.25# The same for IPv6$ dig +short -x 2001:db8::25# The short form, which prints both directions$ host 203.0.113.2525.113.0.203.in-addr.arpa domain name pointer mail.example.com.

Windows-ზე Resolve-DnsName 203.0.113.25 აბრუნებს PTR-ს, და nslookup 203.0.113.25 იგივეს აკეთებს.

იმის სანახავად, რას ამბობს შენი სერვერი HELO-ში, გაგზავნე სატესტო წერილი გარე საფოსტო ყუთზე და წაიკითხე მიმღების მიერ დამატებული ყველაზე ზედა Received: header - ის HELO სახელს და reverse ძებნის შედეგს გვერდიგვერდ იწერს:

Received: from mail.example.com (mail.example.com. [203.0.113.25])        by mx.google.com with ESMTPS id ...

პირველი mail.example.com შენი HELO-ა; ფრჩხილებში მყოფი ის არის, რაც მიმღებმა reverse DNS-ში იპოვა. თუ ისინი ემთხვევა და მისამართი სწორია, მზად ხარ. თუ ფრჩხილებში ჩანს რაღაც unknown-ის მსგავსი ან პროვაიდერის ზოგადი სახელი, PTR აკლია ან შენს ჰოსტზე არ არის დაყენებული.

PTR-ის მოთხოვნა და ტიპური შეცდომების გასწორება#

როცა შენი პროვაიდერი reverse DNS-ს გთავაზობს, მოთხოვნა მოკლეა, მაგრამ თანმიმდევრობას მნიშვნელობა აქვს.

1. აირჩიე hostname. გამოიყენე სახელი, რომელსაც შენი საფოსტო სერვერი გამოაცხადებს, ჩვეულებრივ mail.example.com. არა შიშველი დომენი და არა სახელი, რომელიც უკვე სადმე სხვაგან მიუთითებს.
2. ჯერ პირდაპირი ჩანაწერი შექმენი. დაამატე mail.example.com როგორც A ჩანაწერი (და AAAA, თუ IPv6-ით აგზავნი), რომელიც სერვერის მისამართზე მიუთითებს, და შეამოწმე გარედან dig @1.1.1.1 +short A mail.example.com-ით. პროვაიდერები, რომლებიც მოთხოვნებს ამოწმებენ, უარს იტყვიან PTR-ზე, რომლის პირდაპირი ჩანაწერიც ჯერ არ არსებობს.
3. მოითხოვე PTR, პანელის ველში ან ტიკეტით, და დაასახელე ზუსტი მისამართი და ზუსტი hostname. IPv6-ისთვის მიუთითე სრული მისამართი, საიდანაც სერვერი აგზავნის - სერვერს შეიძლება მთელი დიაპაზონი ჰქონდეს და მხოლოდ ერთს იყენებდეს.
4. საფოსტო სერვერის hostname იმავე სახელზე დააყენე, რომ HELO დაემთხვეს.
5. დაელოდე TTL-ის ამოწურვას და შეამოწმე dig -x-ით, შემდეგ გაგზავნე სატესტო წერილი გარე საფოსტო ყუთზე და წაიკითხე Received: header.

შეცდომები, რომლებიც ამის შემდეგ ჩნდება, ცოტაა და მუდმივად მეორდება:

• ბოლო წერტილი ან ბეჭდვითი შეცდომა. PTR, როგორიცაა mail.example.com.example.com ან mial.example.com, არაფერს ადასტურებს. dig -x-ის პასუხი ასო-ასო წაიკითხე.
• პირდაპირი ჩანაწერი მოგვიანებით შეიცვალა. ვიღაც მიგრაციისთვის mail.example.com-ს ახალ მისამართზე გადაიტანს და ავიწყდება, რომ ძველი სერვერი ჯერ კიდევ აგზავნის. ძველზე FCrDNS ჩუმად ფუჭდება.
• სერვერი მოსალოდნელისგან განსხვავებული მისამართიდან აგზავნის. მანქანა რამდენიმე მისამართით, ან NAT კონტეინერის წინ, შეიძლება გარეთ სხვა მისამართიდან უკავშირდებოდეს, ვიდრე ის, რომელზეც იკითხე. მიმღებთან Received: header აჩვენებს, რომელი მისამართი დაუკავშირდა სინამდვილეში; PTR სწორედ მასზე დააყენე.
• IPv6 დავიწყებულია. IPv4-ის მოწყობა იდეალურია, სერვერი IPv6-ს ამჯობინებს, როცა მიმღები მას სთავაზობს, და IPv6 მისამართს PTR არ აქვს. ან დაამატე, ან გამავალი ფოსტა IPv4-ით შეზღუდე.
• HELO სახელი კონტეინერის hostname-ია. ზოგი პროგრამა ნაგულისხმევად სისტემის hostname-ს იყენებს, რომელიც კონტეინერში შემთხვევითი სტრიქონია. ის ცალსახად დააყენე.

როცა PTR-ს ვერ აყენებ#

ეს ხშირია, და ეს საკუთარი ფოსტის ჰოსტინგის დასასრული არ არის.

1. გააგზავნე relay-ით. შენი სერვერი გამავალ ფოსტას smarthost-ს გადასცემს 587 ან 465 პორტზე, და მიმღები relay-ის IP-ებს ხედავს, რომლებსაც სწორი reverse DNS და დამკვიდრებული რეპუტაცია აქვთ. შენი DKIM ხელმოწერა კვლავ შენს დომენს ასახელებს. დაყენება აღწერილია პოსტში SMTP relay გამავალი ფოსტისთვის.
2. მიღება მაინც პირდაპირ. Reverse DNS გამგზავნი მხარისთვის აქვს მნიშვნელობა. ფოსტა, რომელიც შენთან მოდის, შენი სერვერის PTR-ზე არ არის დამოკიდებული, ამიტომ შემომავალი 25 პორტზე ნებისმიერ შემთხვევაში მუშაობს.
3. HELO სახელი დააყენე ისეთზე, რომელიც გადაწყდება, მაშინაც კი, თუ PTR ზოგადია. FCrDNS-ს ეს ვერ გაასწორებს, მაგრამ მეორე ჯარიმას მოხსნის.

პირველი ვარიანტი სტანდარტული პასუხია, და ის ერთდროულად გამავალი პორტის ბლოკებსაც აგვარებს - იხილე 25-ე პორტი და გამავალი ფოსტის ბლოკები.

FAQ#

PTR ჩანაწერს ჩემი დომენის DNS-ში ვქმნი?

არა. მისამართის reverse DNS მისამართის მფლობელს ეკუთვნის, ჩვეულებრივ შენს ჰოსტინგის პროვაიდერს. შენ შენს ზონაში პირდაპირ A ჩანაწერს ქმნი და პროვაიდერს სთხოვ, IP-სთვის PTR დააყენოს.

PTR ჩემს ელფოსტის დომენს უნდა ემთხვეოდეს?

არა. ის უნდა იყოს ნამდვილი hostname, რომელიც იმავე IP-ზე უკან გადაწყდება. ერთ სერვერს შეუძლია ბევრი დომენის სახელით აგზავნოს ერთი PTR-ის ქვეშ, მაგალითად mail.example.com.

რამდენ ხანში ამოქმედდება PTR-ის ცვლილება?

როგორც ნებისმიერი DNS ცვლილება - ძველი ჩანაწერის TTL-ის ხანგრძლივობით, რომელსაც პროვაიდერები ხშირად ერთ დღეზე აყენებენ. მოითხოვე ის გაგზავნის დაწყებამდე კარგა ხნით ადრე, და არა იმავე დღეს.

ჩემი PTR სწორია, მაგრამ Gmail მაინც უარყოფს ფოსტას. რატომ?

შეამოწმე IPv6. თუ სერვერს IPv6 მისამართი აქვს და მისით აგზავნის, ამ მისამართს საკუთარი PTR და შესაბამისი AAAA ჩანაწერი სჭირდება. შემდეგ შეამოწმე SPF, DKIM და DMARC - reverse DNS მოთხოვნებიდან მხოლოდ ერთ-ერთია. სრული სია არის პოსტში რატომ ხვდება ელფოსტა სპამში.

საჭიროა reverse DNS ფოსტის მისაღებად?

შენი სერვერის მიერ მიღებისთვის - არა. გამგზავნები შენს MX-ზე აწვდიან ფოსტას შენი PTR-ის მიუხედავად. Reverse DNS ეხება იმას, თუ როგორ აფასებენ მიმღებები შენ მიერ გაგზავნილ ფოსტას.