Чаму запіс SRV дапамагае толькі кліенту, які сам запытвае яго

Даданне запісу SRV у вашу зону не вучыць ніводнага кліента VPN шукаць яго. Кліент павінен ведаць этыкетку, вырашыць адправіць запыт і дзейнічаць паводле таго, што вернецца, а DNS не можа забяспечыць першыя два з гэтага. Таму большасць няўдалых планаў SRV — гэта праблемы кліента ў касцюме DNS. Спачатку прачытайце паводзіны кліента пры выяўленні, а затым публікуйце толькі тую этыкетку, якую ён сапраўды запытвае.

Запіс, якога ніхто не запытвае, нікому не дапаможа

SRV публікуе месцазнаходжанне паслугі; ён не абвяшчае пра яе. Нішто не штурхае запіс да кліента, і ніводны рэзалвер не прапануе імя, пра якое ніколі не пыталіся. Пошук пачынаецца з рашэння праграмы зрабіць яго, таму этыкетка павінна паходзіць з дакументацыі прадукту або з назірання за праграмай у сетцы. Там, дзе ў кліента няма кроку выяўлення, запіс змяняе зону і больш нічога.

Вось чаму адзін прадукт у сетцы можа пачаць працаваць, тады як іншы не закрануты той жа зменай. Пераменная — гэта праграма, а сервер DNS робіць менавіта тое, што яму сказалі. Пасля правак прачытайце зону яшчэ раз, бо няправільна набраная этыкетка лёгка хаваецца сярод запісаў, якія ўсе выглядаюць аднолькава.

Прачытайце палі, перш чым іх запісваць

Запіс нясе чатыры значэнні, і кожнае адказвае на іншае пытанне: прыярытэт упарадкоўвае мэты, якія кліент можа паспрабаваць, вага дзеліць нагрузку паміж мэтамі аднолькавага прыярытэту, порт называе транспартны порт, а мэта называе хаст. Спецыфікацыя таксама дазваляе мэце . азначаць, што паслуга наўмысна недаступная, і гэта карысны адказ, а не зламаны.

Ніводнае з гэтых палёў не нясе ўліковых даных, палітыкі сертыфікатаў або версіі праграмы, і кліент, які ігнаруе вагу, усё роўна падключаецца, проста без меркаванага балансу. Мэта павінна мець уласныя запісы адрасоў, і яна павінна быць кананічным імем, а не псеўданімам. Публікацыя запісу, які паказвае на хаст без слухача, стварае памылку злучэння, якая чытаецца як збой DNS, а гэта самы дарагі від увядзення ў зман. Публікуйце ўвесь ланцужок або нічога з яго.

Знайдзіце этыкетку, якую кліент сапраўды адпраўляе

Устанавіце этыкетку на падставе доказаў, а не здагадкі пра назву прадукту. Або дакументацыя паказвае назву паслугі, або запіс трафіку паказвае запыт, які пакідае кліент пры запуску. Абодва шляхі вядуць у адно месца: дакладнае імя і тып для праверкі супраць рэзалвера.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Параўнайце адказ з запісам, які вы апублікавалі, сімвал за сімвалам, бо падкрэсліванні і кропка ў канцы — частка імя. Пусты адказ на запыт, які сапраўды быў адпраўлены, паказвае на зону, а поўная адсутнасць запыту паказвае на кліента, і гэтыя высновы вядуць вас да розных каманд. Сапраўдны адказ выглядае як радок ніжэй, дзе прыярытэт 20 прайграе любому запісу з ніжэйшым прыярытэтам, а кліент набірае порт 8443 на названай мэце.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Мэта таксама павінна існаваць

Мэта, якая рэзалвіцца, — гэта не тое ж самае, што паслуга, якая адказвае. Праверце запісы адрасоў для мэты, затым праверце, што нешта слухае на апублікаваным порце і пратаколе. Запіс TCP, які паказвае на слухач толькі UDP, — гэта неадпаведнасць, якую не выправіць ніякае рэдагаванне зоны. Трымайце TTL кароткім, пакуль мэта нестабільная, і падоўжыце яго, калі імя перастане рухацца.

Кліенты, якія ўсё ж рэалізуюць выяўленне, адрозніваюцца ў тым, наколькі яны шануюць запіс. Некаторыя выкарыстоўваюць толькі прыярытэт, некаторыя лічаць вагу рэкамендацыяй, а некалькі ігнаруюць порт і мяркуюць значэнне па змаўчанні. Гэтыя адрозненні належаць у вашыя нататкі побач з этыкеткай, бо яны тлумачаць паводзіны, якія інакш выглядаюць як збой рэзалвера.

Выяўленне — гэта не аўтэнтыфікацыя

Адказ SRV кажа, куды падключацца, і нічога не кажа пра тое, каму давяраць, калі вы туды прыйшлі. Пакіньце праверку сертыфіката і ідэнтычнасці сервера ў кліента дакладна такімі, якімі яны былі, бо запіс, які хтосьці іншы можа падмануць, не павінен станавіцца рашэннем пра давер. Адказы DNS кэшуюцца і рэдагуюцца тым, хто кантралюе зону, што робіць іх дрэнным месцам для кадавання палітыкі.

Для кліента без падтрымкі выяўлення распаўсюдзіце профіль або URL шлюза, які ён прымае, і запішыце, які прадукт выкарыстоўвае які метад. Гэтая нататка не дазволіць наступнаму адміністратару дадаць запіс і чакаць, што ён будзе працаваць усюды. Спецыфікацыя SRV апісвае выбар паміж мэтамі, і чытанне яе як механізму аўтарызацыі — гэта шлях, якім карысны запіс ператвараецца ў меркаванне пра бяспеку. Публікуйце свядома, называйце этыкетку ў дакументацыі і стаўцеся да кліента як да кампанента, які вырашае, ці мае ўсё гэта значэнне.