SRV ჩანაწერები Minecraft-ისთვის: ველები და როგორ შევამოწმოთ

SRV ჩანაწერი საშუალებას აძლევს მოთამაშეებს, მისამართისა და პორტის ნაცვლად play.example.com აკრიფონ. ეს ოთხი მნიშვნელობა და სამიზნეა, და თითქმის ყოველი წარუმატებელი მცდელობა ერთი და იმავე მცირე რაოდენობის შეცდომაა. აი მთელი ეს ამბავი zone ფაილის ერთ ხაზში:

_minecraft._tcp.play   300  IN  SRV  0  5  25571  node.example.com.node                   300  IN  A        203.0.113.10

ორი ჩანაწერი და არა ერთი. SRV ჩანაწერი ამბობს: "ამ სახელის Minecraft სერვისი ცხოვრობს node.example.com-ზე, პორტ 25571-ზე", ხოლო A ჩანაწერი ამბობს, სად არის node.example.com. მეორის დავიწყება SRV ჩანაწერის უმოქმედობის ყველაზე გავრცელებული მიზეზია, რადგან თავად SRV ჩანაწერში არცერთი მნიშვნელობა მისამართი არ არის.

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

როცა მოთამაშე hostname-ს პორტის გარეშე აკრეფს, Minecraft Java კლიენტი პირდაპირ A ძებნაზე არ გადადის. ის ჯერ _minecraft._tcp.<hostname>-ს ითხოვს. თუ SRV ჩანაწერი დაბრუნდა, კლიენტი მისგან სამიზნესა და პორტს იღებს და იქ უკავშირდება. თუ არაფერი დაბრუნდა, ის სახელზე ჩვეულებრივ A ან AAAA ძებნას უბრუნდება და პორტს 25565-ად თვლის.

აქედან პირდაპირ სამი შედეგი გამომდინარეობს და ისინი ხალხის გაუგებრობის უმეტესობას განმარტავს.

პორტის აკრეფა SRV ძებნას მთლიანად გამოტოვებს. მოთამაშე, რომელიც play.example.com:25565-ს შეიყვანს, იღებს A ძებნას და პორტ 25565-ს, შენი SRV ჩანაწერი რასაც არ უნდა ამბობდეს. ეს სასარგებლო დიაგნოსტიკაა და "ჩემთან მუშაობს"-ს გავრცელებული წყაროც: ვიღაცას მისამართი პორტით აქვს შენახული იმ დროიდან, სანამ ყველაფერს დააყენებდი.

იგივე ძებნა ხდება სერვერების სიის ping-ისთვისაც. MOTD, მოთამაშეთა რაოდენობა და მწვანე კავშირის ზოლები ყველა SRV ჩანაწერზეც გადის, ამიტომ თუ multiplayer სიის ჩანაწერი სერვერს მიუწვდომლად აჩვენებს, ეს უკვე SRV გზის წარუმატებლობაა და Join-ზე დაწკაპუნება არ გჭირდება, რომ ეს გაიგო.

Bedrock ყველაფერს ამას უგულებელყოფს. Bedrock კლიენტს ცალკე პორტის ველი აქვს და SRV ძებნას არ ასრულებს, ამიტომ Bedrock მოთამაშეები მისამართსაც აკრეფენ და პორტსაც. თუ Geyser-ს უშვებ, hostname და Bedrock-ის პორტი ორ რამედ გადაეცი.

ველები, ზუსტად#

Priority და weight არსებობს სერვისებისთვის, რომლებიც ნამდვილად რამდენიმე endpoint-ს უშვებენ, და Minecraft-ში არაფერი მათზეა დამოკიდებული. ნებისმიერი მნიშვნელობა გამოდგება; 0 და 5 ტრადიციულია და მათზე აღარასოდეს დაფიქრდები.

სამიზნე ველია ის, რაც ყველას ებმევა. ის hostname უნდა იყოს და ეს hostname DNS-ში სადმე მისამართზე უნდა წყდებოდეს. Zone ფაილში მას ბოლოში წერტილი სჭირდება, რაც ნიშნავს: "ეს სრულად კვალიფიცირებულია, ჩემი დომენი არ მიამატო". ვებზე დაფუძნებული DNS რედაქტორების უმეტესობა წერტილს თავად ამატებს და ზოგი მას შემდეგ გიჩვენებს - node.example.com. ჩანაწერების სიაში სწორია და არა შეცდომა.

სპეციფიკაციის კიდევ ერთი წესი, რომელიც ხანდახან იჭერს: სამიზნე პირდაპირ A ან AAAA ჩანაწერზე უნდა მიუთითებდეს და არა CNAME-ზე. Resolver-ების უმეტესობა CNAME-ს მაინც გაჰყვება და ჩვეულებრივ მუშაობს, მაგრამ თუ ყველაფერი სწორად ჩანს და კავშირი მაინც ვარდება, CNAME-ის ნამდვილი A ჩანაწერით ჩანაცვლება პირველია, რაც უნდა სცადო.

სად განსხვავდება შენი რეგისტრატორის ფორმა#

ჩანაწერი სტანდარტულია; ფორმები - არა. ველურ ბუნებაში სამი ფორმაა და სწორი სტრიქონის არასწორ ფორმაში ჩაწერა ისეთი სახელის ჩანაწერს ქმნის, რომელსაც არავინ მოძებნის.

• ცალკე ველები. Cloudflare-ი და რამდენიმე სხვა Service-ს, Protocol-სა და Name-ს სამ ველად გაძლევს. Service არის _minecraft, Protocol არის _tcp, Name კი უბრალოდ play - ან @ შიშველი დომენისთვის.
• ერთი ფარდობითი სახელი. ბევრ რეგისტრატორს ერთი host ველი აქვს და ელის _minecraft._tcp.play-ს, ზონა ავტომატურად ემატება. აქ დომენს ნუ აკრეფ.
• ერთი აბსოლუტური სახელი. ზოგს მთელი სჭირდება: _minecraft._tcp.play.example.com.

გაარკვიე, რომელი გაქვს, უკვე შექმნილ A ჩანაწერზე დაკვირვებით. თუ შენი არსებული ჩანაწერი host სვეტში www-ს აჩვენებს, ფორმა ფარდობითია და შენი SRV სახელი _minecraft._tcp.play-ია. თუ www.example.com-ს აჩვენებს, სრული სახელი გამოიყენე. ამის არასწორად გაკეთება _minecraft._tcp.play.example.com.example.com-ს იძლევა, რაც სრულიად ვალიდური ჩანაწერია სახელისთვის, რომელიც არ არსებობს, და არცერთი შეცდომა არსად არ გეტყვის.

ზოგიერთი პროვაიდერი ასევე მოითხოვს გაერთიანებულ "data" ან "content" ველს, რომელიც შეიცავს 0 5 25571 node.example.com. - priority, weight, port და target, ინტერვალებით გამოყოფილი, ამ თანმიმდევრობით.

შეცდომები, რომლებიც ჩუმად ვარდება#

DNS თითქმის არასოდეს გეუბნება, რომ შეცდომა დაუშვი. ის გეუბნება, რომ სახელი არ არსებობს, რაც ისეთივე ჩანს, როგორც გათიშული სერვერი. დაახლოებით იმ თანმიმდევრობით, რამდენად ხშირად ხდება:

1. IP მისამართი სამიზნეში. არავალიდურია. კლიენტი 203.0.113.10-ის hostname-ად გადაწყვეტას ცდილობს, არაფერს იღებს და ატყობინებს, რომ სერვერამდე ვერ აღწევს. IP A ჩანაწერში ჩასვი და სამიზნე ამ ჩანაწერის სახელზე მიუთითე.
2. სამიზნეს A ჩანაწერი არ აქვს. SRV ჩანაწერს ნებისმიერ სახელზე შეუძლია მიუთითოს, ფორმის შევსებისას გამოგონილზეც კი. ჯერ A ჩანაწერი შექმენი, შემდეგ SRV ჩანაწერი, რომელიც მასზე მიმართავს.
3. ზონა ორჯერ მიეწერა. ზემოთ აღწერილი და პირველ რიგში შესამოწმებელია, რადგან ჩანაწერების სიაში უხილავია, თუ ყურადღებით არ წაიკითხავ.
4. სამიზნე A ჩანაწერი HTTP proxy-ს უკანაა. Cloudflare-ის ნარინჯისფერი ღრუბელი HTTP-სა და HTTPS-ს აპროქსირებს. Minecraft არცერთია, ამიტომ დაპროქსირებული ჩანაწერი კლიენტებს მისამართს აძლევს, რომელიც თამაშის კავშირს არასოდეს მიიღებს. ჩანაწერი, რომელზეც SRV სამიზნე მიუთითებს, DNS-only უნდა იყოს - რუხი ღრუბელი. Cloudflare ვებსაიტებისთვის და გეიმ სერვერებისთვის განმარტავს, რას გადაიტანს ნარინჯისფერი ღრუბელი და რას - არა.
5. არასწორი პორტი. თამაშის პორტი, არა query პორტი, არა RCON, არა ის პორტი, რაც გასულ თვეს გქონდა. პანელზე ის სერვერის მისამართიდან დააკოპირე და არა მეხსიერებიდან.
6. `_tcp` ჩაწერილია როგორც `tcp` ან როგორც `_udp`. ორივე ქვედა ტირე სახელის ნაწილია. Java Minecraft არის TCP.
7. მოძველებული ქეში. ჩანაწერი ათი წუთის წინ გაასწორე და შენი resolver ძველ პასუხს TTL-ის დანარჩენ ნაწილში აგრძელებს. გამოსცადე საჯარო resolver-თან, რომ სიმართლე ნახო.

მუშაობის დამტკიცება გამოცხადებამდე#

არასოდეს გამოაცხადო მისამართი, რომელიც თავად არ გადაგიწყვეტია. ორი ბრძანება ამას წყვეტს:

$ dig +short SRV _minecraft._tcp.play.example.com0 5 25571 node.example.com.$ dig +short A node.example.com203.0.113.10

თუ პირველი არაფერს აბრუნებს, ჩანაწერი აკლია, არასწორად არის დასახელებული ან ჯერ არ გამოქვეყნებულა. თუ პირველი მუშაობს და მეორე არაფერს აბრუნებს, კლასიკური დაკარგული A ჩანაწერის შემთხვევაა. Windows-ზე, სადაც dig დაყენებული არ არის:

nslookup -type=SRV _minecraft._tcp.play.example.com 1.1.1.1

Resolver-ის დასახელებას მნიშვნელობა აქვს. 1.1.1.1-ის ან 8.8.8.8-ის აშკარად კითხვა შენი როუტერისა და პროვაიდერის ქეშს არიდებს, და ამით არჩევ "არ არის გამოქვეყნებული" "არ არის გავრცელებულისგან". პირდაპირ ავტორიტეტულ სერვერებს dig +trace-ით ჰკითხე, თუ ყველა ქეშის გამორიცხვა გინდა.

შემდეგ შეამოწმე, რომ პორტი მართლა ღიაა, რადგან სწორი ჩანაწერი დახურულ პორტზე კლიენტისგან იდენტურად ჩანს:

$ nc -vz node.example.com 25571Connection to node.example.com 25571 port [tcp/*] succeeded!

PowerShell-ს იგივე საქმისთვის Test-NetConnection node.example.com -Port 25571 აქვს. გეიმ სერვერის პორტები განმარტებული განმარტავს, რატომ შეიძლება თამაში უსმენდეს და მაინც მიუწვდომელი იყოს.

ბოლო ტესტი ნამდვილია: დაამატე play.example.com Minecraft-ის კლიენტში პორტის გარეშე და ნახე, გამოჩნდება თუ არა MOTD და მოთამაშეთა რაოდენობა სერვერების სიაში. ეს ზუსტად იმ გზას ამოწმებს, რომელსაც შენი მოთამაშეები გამოიყენებენ.

რას ვერ აკეთებს SRV ჩანაწერი#

ის შენი სერვერის მისამართს არ მალავს. სამიზნეს საჯარო A ჩანაწერი აქვს და ნებისმიერს შეუძლია მისი dig ორ წამში. SRV ჩანაწერი კომფორტია და არა დაცვის ფენა. რაც სინამდვილეში შენს სერვერსა და ფლუდს შორის დგას, არის upstream ფილტრაცია, და ისიც მხოლოდ აშკარა მოცულობით ტრაფიკს აგდებს - იხილე რას ვაკეთებთ თავდასხმების წინააღმდეგ იმის პატიოსანი ვერსიისთვის, რას იჭერს და რას - არა ფილტრაცია.

ის დატვირთვას არ ანაწილებს. DNS SRV-ს priority და weight ველები სწორედ ამისთვის აქვს, მაგრამ Minecraft-ის კლიენტი შეწონილ არჩევანს ისე არ ახორციელებს, რომ მასზე დაგეგმვა შეგეძლოს. რამდენიმე SRV ჩანაწერის გამოქვეყნება და მოთამაშეების მათ შორის გადანაწილების მოლოდინი რაღაცას მოგცემს და ეს არ იქნება ის, რაც დააპროექტე. თუ ერთზე მეტი backend გჭირდება, წინ proxy დააყენე.

ის არ ეხმარება ვინც პორტს აკრეფს. არც RCON-ზე ვრცელდება, არც query პორტზე, არც ვებ რუკაზე და არც მანქანაზე არსებულ სხვა სერვისზე. ისინი ცალკე სახელები და ცალკე პორტებია, ხოლო query პორტს კერძოდ საკუთარი ჩანაწერის ტიპი აქვს, რომელსაც Minecraft არ იყენებს.

ის Bedrock კლიენტებს არაფერს აძლევს. ისინი არ ეკითხებიან.

SRV, proxy-ები და forced hosts#

თუ რამდენიმე backend-ის წინ proxy-ს უშვებ, მაგალითად Velocity-ს, SRV ჩანაწერი შესაძლოა საერთოდ არ გჭირდებოდეს. Proxy 25565-ს უსმენს და play.example.com-ზე ჩვეულებრივი A ჩანაწერი საკმარისია, რაც ერთით ნაკლებ რამეს ნიშნავს, რომელიც შეიძლება არასწორად გაკეთდეს. პორტები შიდა საქმე ხდება და საჯარო მხოლოდ proxy-ს პორტია.

საინტერესო ნაწილი სახელით მარშრუტიზაციაა. Proxy-ს შეუძლია hostname კონკრეტულ backend-ს დაუკავშიროს - creative.example.com ხალხს პირდაპირ creative სერვერზე აყენებს, play.example.com - lobby-ში - იმ hostname-ით, რომელიც კლიენტმა თავის handshake-ში გაგზავნა. ეს კარგი გზაა სხვადასხვა თემისთვის განსხვავებული შესასვლელების მისაცემად, ერთზე მეტი საჯარო პორტის გარეშე. გამოსცადე და ნუ დაუშვებ: handshake ატარებს თუ არა სახელს, რომელიც მოთამაშემ აკრიფა, თუ SRV სამიზნეს, კლიენტებსა და proxy-ს ვერსიებს შორის განსხვავდება, და forced hosts მხოლოდ პირველ შემთხვევაში მუშაობს. რას აკეთებს reverse proxy იდეის ზოგად ფორმას შეიცავს.

ერთი სერვერისთვის ნაგულისხმევ პორტზე ყველაზე მარტივი, რაც მუშაობს, A ჩანაწერია და SRV საერთოდ არა. დომენის მიბმა გეიმ სერვერზე ამ საქმის ასეთი ვერსიაა, ხოლო ქვედომენები სერვერებისთვის ყოველ შენს სერვერს საკუთარი სახელის მიცემას განიხილავს. SRV ადგილს ზუსტად მაშინ იმსახურებს, როცა პორტი 25565 არ არის და არ გინდა, რომ მოთამაშეებმა ეს იცოდნენ.

TTL და სერვერის გადატანა#

TTL არის, რამდენ ხანს აქვს resolver-ს უფლება, პასუხი შეინახოს. 3600-იან ჩანაწერს შეცვლის შემდეგ საათით შეიძლება მოძველებული პასუხი ჰქონდეს, რაც კარგია იმ დღემდე, როცა მიგრაციას აკეთებ.

გადატანის რუტინა მოსაწყენია და საიმედო:

1. ერთი დღით ადრე დააწიე TTL როგორც SRV ჩანაწერზე, ისე მის სამიზნე A ჩანაწერზე 300-მდე.
2. დაელოდე ძველის ამოწურვას, რომ მსოფლიოში ყველა ქეშმა მოკლე აიღოს.
3. გადაიტანე, შეცვალე A ჩანაწერი და თვალი ადევნე.
4. ძველი სერვერი ერთი-ორი საათი ჩართული და მისაწვდომი დატოვე. მოთამაშეები, რომლებიც სესიის შუაში არიან, არაფერს თავიდან არ წყვეტენ და მოძველებული ქეშის მქონე კლიენტები მაინც იქ მივლენ.
5. დაამშვიდებისას TTL უკან აწიე.

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

FAQ#

მჭირდება SRV ჩანაწერი, თუ ჩემი სერვერი პორტ 25565-ს იყენებს?

არა. SRV ჩანაწერის არარსებობისას კლიენტები 25565-ს ვარაუდობენ, ამიტომ სახელზე ჩვეულებრივი A ჩანაწერი საკმარისია და გამართვა უფრო მარტივია. SRV არსებობს სერვერებისთვის ნებისმიერ სხვა პორტზე.

რატომ მუშაობს მისამართი ჩემთვის და ჩემი მეგობრებისთვის - არა?

ჩვეულებრივ იმიტომ, რომ შენ ის პორტთან ერთად შეინახე, რაც SRV ძებნას მთლიანად გამოტოვებს, ან იმიტომ, რომ შენს resolver-ს სხვა პასუხი აქვს ქეშში, ვიდრე მათ. ამოიღე პორტი შენახული ჩანაწერიდან და ისევ სცადე, შემდეგ შეამოწმე ჩანაწერი 1.1.1.1-თან და არა შენს საკუთარ DNS-თან.

შემიძლია SRV სამიზნე პირდაპირ IP მისამართზე მივუთითო?

არა. სამიზნე ველი hostname უნდა იყოს. შექმენი A ჩანაწერი რაიმე node.example.com-ისთვის, რომელიც IP-ს შეიცავს, და შემდეგ SRV სამიზნე ამ სახელზე მიუთითე. ეს მომავალ გადატანებსაც ერთი რედაქტირებით ხდის.

რამდენ ხანს სჭირდება SRV ჩანაწერს მუშაობის დასაწყებად?

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

მალავს SRV ჩანაწერი ჩემი სერვერის IP მისამართს?

საერთოდ არა. სამიზნე საჯარო A ჩანაწერად წყდება, რომელსაც ნებისმიერს შეუძლია დაუძახოს. თუ მისამართის დამალვა მნიშვნელოვანია, ეს სერვერის წინ მდგარი proxy-ის საქმეა და არა DNS-ის.

შემიძლია ერთი დომენი რამდენიმე Minecraft სერვერისთვის გამოვიყენო?

დიახ. თითოეულს საკუთარი სახელი მიეცი - smp.example.com, creative.example.com - საკუთარი SRV ჩანაწერით, რომელიც იმავე ჰოსტზე სწორ პორტზე მიუთითებს. ყველა მათგანს შეუძლია მანქანის ერთი A ჩანაწერის გაზიარება.