Защо 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 описва избора между цели и четенето ѝ като механизъм за оторизация е начинът, по който полезен запис се превръща в предположение за сигурност. Публикувайте съзнателно, назовете етикета в документацията си и третирайте клиента като компонента, който решава дали нещо от това има значение.