Чи колись записи SRV стануть корисними?

У DNS запис SRV насправді є досить загальною формою повідомлення віддаленому клієнту, де розміщується певна послуга. На даний момент я використовую це для того, щоб люди могли телефонувати мені за допомогою SIP-клієнта через Інтернет (працює досить непогано).

Однією з переваг запису SRV є те, що ви можете вказати інший порт для послуги і у вас може бути кілька систем для однієї і тієї ж (або одна і та ж система і кілька примірників на іншому порту). Таким чином, IFF працює, ви можете мати кілька веб-серверів в одній системі без будь-яких втручань.

Отже, ви могли мати це у своєму DNS:

_http._tcp SRV 10 50 8080 myserver.basjes.nl
_http._tcp SRV 10 50 8081 myserver.basjes.nl

Однак є один тонкий корч у всьому цьому доброті ... Я не зміг знайти жодного HTTP, FTP, SMTP, ... клієнтів, які це підтримують.

Тож крім SIP та кількох інших протоколів, згаданих на сторінці Вікіпедії : Чи стане запис SRV колись справді корисним?

Або я щось пропустив?

Чи є щось краще там, що працює?

Я думаю, ви побачите це лише для нових протоколів.

Записи MX, які використовується SMTP, еквівалентні записам SRV з фіксованим портом і без ваги. Іншими словами, вони вже адекватно вирішили ту саму проблему.

Оскільки, наприклад, HTTP повинен зберігати зворотну сумісність із поточними механізмами, будь-хто, хто почав використовувати SRV для HTTP, все одно повинен був би забезпечити альтернативний механізм, і ніхто не хоче підтримувати два способи робити те саме. (скажімо, деякі балансири навантаження та деякі записи SRV DNS ...) І якщо сайти не збираються публікувати записи SRV (тому що це просто створює непотрібну роботу), клієнтів немає мотивації підтримувати записи SRV, ніхто не публікує.

Вони досить корисні в домені Active Directory .

Записи SRV також використовуються багатьма послугами та клієнтами з підтримкою Kerberos. Особливо це стосується певної машини, де /etc/krb5.conf (або її еквівалент) або не читається, або відсутня; буде здійснено пошук запису SRV для пошуку KDC.

Технологія Bonjour від Apple (також zeroconf) широко використовує це. Якщо ви ще не бачили його в дії - перевірте це. Це дозволяє автоматично знаходити принтери, маршрутизатори, веб-сторінки з підтримкою bonjour тощо.

Існує ліцензований BSD модуль Apache під назвою mod_bonjour, який дозволяє рекламувати веб-сайти через багатоадресний DNS. Ви також можете рекламувати сайти через записи SRV та звичайний DNS, але я вірю, що лише Safari зможе їх виявити.

На веб-сторінці Zeroconf є досить хороше пояснення того, як це працює - я б рекомендував переглянути книгу, також якщо ви зацікавлені в технології.

Однією з найбільших проблем із цим загалом є те, що люди DNS не вважають себе учасниками служб пошуку служб, а параноїчні люди з безпеки вважають можливість виявлення служб ризиком для безпеки.

Дійсно, більшість додатків поки не підтримують це.

Це ті, у яких домен у ідентифікації цільового користувача звичайно відрізняється від імені хоста, до якого має підключитися клієнтське програмне забезпечення. Отже, чому він використовується в SIP, а також у Jabber (XMPP).

SMTP не потрібен, тому що в ньому завжди були записи MX з самого початку.

Користь від використання іншого порту порівняно незначна, тому інші протоколи не почали його багато використовувати.

Існує Інтернет-проект, який пропонує http+srv:схему URI, але зауважте, що немає поточних пропозицій щодо додавання пошукових http:запитів SRV до стандартних запитів URI.

Outlook 2007 та Exchange 2007 використовують записи SRV http://technet.microsoft.com/en-us/library/bb332063.aspx

Я вважаю, що записи SRV є однією з основних структур у відкритті служби DNS (DNS-SD), тому вони ставатимуть все більш важливими.

Також немає причин, що їх не можна використовувати в існуючих технологіях спільно з клієнтами, відомими DNS-SD, наприклад, мережевими браузерами, такими як iStumbler for mac, які можуть знайти ресурси ресурсу bonjour / zeroconf у мережі.

На мою думку, записи SRV ставатимуть частіше, коли динамічне оновлення DNS стане доступнішим. MS-DNS увімкнено динамічне оновлення за замовчуванням у великій частині завдяки вимогам Active Directory. Протягом багатьох років там було багато каталогів реклами ресурсів, включаючи протокол розташування служби, протокол рекламної послуги (мережі IPX), Bonjour / Avahi і навіть певною мірою DHCP.

З них лише DNS має справжній потенціал для каталогу ресурсів, що охоплює Інтернет. Публічні сервери DNS чомусь статичні речі. Прийняття записів SRV відбудеться тоді, коли в них буде визначена потреба, подібно до прийняття TXT-записів для протоколу SPF. SIP з використанням SRV може бути першим кроком у відкритті дверей для більш широкого прийняття, що не стосується МС.

Записи SRV використовуються для направлення серверів Windows Vista / 2008 на ваш сервер KMS для активації в Enterprise.

XMPP використовує їх.

Але існуючі протоколи не зміняться для їх підтримки, особливо перенаправлення запиту на інший порт. Це було б несподівано і, безсумнівно, порушило б деякі припущення щодо безпеки.

Записи SRV пропонують механізм реалізації комунікаційних послуг, не вимагаючи від усіх тих самих постачальників. Іншими словами, те, що записи A і MX роблять для Інтернету та електронної пошти, записи SRV роблять для будь-якої служби.

Ця ідея викладена у публікації в блозі "Сила вільного адресації" http://e-caller.com/?p=4

Зростання Twitter та Facebook пояснюється відсутністю альтернатив, що підтримуються SRV.

Проект Fedora / Red Hat freeipa використовує їх, а також лялькових лабораторій для врівноваження навантаження та масштабування. чим більше я дізнаюся про випадки його використання та про те, як вони широко використовуються, тим більше я закоханий у нього. це найкраще, що траплялося з dns та інфраструктурою. перевірте, як спотифікує, використовує їх https://labs.spotify.com/2013/02/25/in-praise-of-boring-technology/

Вони дуже корисні для стеків додатків, для яких потрібен сервіс-локатор, оскільки DNS не потрібно реалізовувати з нуля і набагато легший за вагу, ніж щось на зразок зоокетера чи тощо. Також є додаткова зручність, яку можна зробити досить безпечною. Я не впевнений, чому навряд чи хтось, крім Spotify, використовує його таким чином, я підозрюю просто незнання. Я бачив, як багато людей розгортають власне програмне розташування спеціальних службових служб. DNS - це швидке, надійне сховище ключових значень і вже впорядковує свої ключі по зонах. Велика проблема полягає в тому, що дуже мало DNS-серверів мають будь-який API, тому автоматизація створення / оновлення RR недоцільна, хоча це і хмарні реалізації DNS.

Записи SRV є ЧАСОВОЮ для хостингової галузі, оскільки вони дозволяють економити простір IPv4.

Ми використовуємо їх для прозорого переходу наших клієнтів до IPv6.