Комментарии 18
А чем вам bind и вьюшки по геобазе не подошли?
Главная фича — возможность довольно просто впиливать логику, которая не ограничивается одной только geo-привязкой.
Допустим, отправить часть поддоменов вообще на динамический бекэнд и отвечать на часть запросов (напр. SRV ) динамически или рандомно.
Описано не конкретное решение, описан метода создания некой «кастомной» логики, как мне кажется, довольно простыми средствами.
Допустим, отправить часть поддоменов вообще на динамический бекэнд и отвечать на часть запросов (напр. SRV ) динамически или рандомно.
Описано не конкретное решение, описан метода создания некой «кастомной» логики, как мне кажется, довольно простыми средствами.
Вы бы конкретные примеры написали.
Всё что понапридумывали до 2005го года — есть в bind9. Всё что понапридумали потом — реализовали (или можно реализовать самостоятельно модулем) в bind10. При том я могу сказать, что фантазия до 2005-го у людей бушевала будь-будь — много фич bind9 отвались за пределами популярных мануалов.
Всё что понапридумывали до 2005го года — есть в bind9. Всё что понапридумали потом — реализовали (или можно реализовать самостоятельно модулем) в bind10. При том я могу сказать, что фантазия до 2005-го у людей бушевала будь-будь — много фич bind9 отвались за пределами популярных мануалов.
bind ресурсы жрет немеряно. PowerDNS в этом смысле экономичнее
Зачем же так извращаться то?
Если просто чисто для «чтоб было», то нормально, иначе, я бы назвал это кошмаром.
Если просто чисто для «чтоб было», то нормально, иначе, я бы назвал это кошмаром.
Как я уже ответил выше, реализован механизм кастомной логики внутри DNS-сервера. Данный пример с geo и wildcard довольно простой и м.б. реализован другими средствами, не спорю.
Ситуаций, когда такая логика понадобится, множество. Например, что-то вида a(\d{3,5}).domain.com обрабатывать иначе, чем остальные.
Ситуаций, когда такая логика понадобится, множество. Например, что-то вида a(\d{3,5}).domain.com обрабатывать иначе, чем остальные.
Самое интересное, что в последнее время, сильная тенденция использовать открытые DNS-сервера, как то OpenDNS или от гугла 8.8...., очень многие их используют, в связи с этим, гео-ДНС на сегодняшний день всё менее актуален. То есть, при таком раскладе, тяжко определить откуда на самом деле обращения. А вот GEO на уровне самих запросов к демонам, web и т.д. — это уже более правильный подход.
Открытые резолверы используют те, кто знает, что это такое.
Ну или кому настраивали те, кто знает, что это такое.
Не думаю, что этот процент очень уж большой.
Ну или кому настраивали те, кто знает, что это такое.
Не думаю, что этот процент очень уж большой.
ну, если будем считать, что 30% админов в небольших огранизациях настраивают именно так — то может и не большой, и в общем не наберется и 2%.
Но если примем во внимание, что для нас критично определить откуда запрос (такой сервис), то определять локацию на уровне ДНС не правильно и не оптимально.
Вообще, этот мой комментарий не конкретно к Вашему посту относиться, так, мысли вслух.
Но если примем во внимание, что для нас критично определить откуда запрос (такой сервис), то определять локацию на уровне ДНС не правильно и не оптимально.
Вообще, этот мой комментарий не конкретно к Вашему посту относиться, так, мысли вслух.
Идея геотаргета вот в чем:
У вас сервер static.superservice.zone или download.superservice.zone важно чтобы пользователь из России качал статику из России, пользователь из США из США и т.д. А если у вас вообще сервер со статикой под ногами стоит, то вам туда =)
Понятно, что если у вас апликейшн, то он может сам подставлять нужную локацию сервера со статикой (http_sub, кстати, может это делать красиво), проблемы начинаются в районе хайлоада, где считать это всё на лету становится проблематично. Уж при первом заходе на сайт точно.
У вас сервер static.superservice.zone или download.superservice.zone важно чтобы пользователь из России качал статику из России, пользователь из США из США и т.д. А если у вас вообще сервер со статикой под ногами стоит, то вам туда =)
Понятно, что если у вас апликейшн, то он может сам подставлять нужную локацию сервера со статикой (http_sub, кстати, может это делать красиво), проблемы начинаются в районе хайлоада, где считать это всё на лету становится проблематично. Уж при первом заходе на сайт точно.
НЛО прилетело и опубликовало эту надпись здесь
Динамика не должна отрабатывать при каждом запросе к html в нагруженных проектах. Ну или вы просто держите ваших заказчиков за идиотов.
НЛО прилетело и опубликовало эту надпись здесь
Чаше всего geo нужен для очень быстрой первой загрузки.
Если мы статику уже отдали, то «доотдача» каких-то мелочей с более близкого сервера не очень спасает.
Спасибо за интересное направление, ваш комментарий довёл до интересной мысли:
Решение всё-таки есть: при первом запросе (статика/динамика — не важно) можно на уровне nginx ставить куку с кодом региона и потом в зависимости о неё как-то это обрабатывать или http_sub-ом или как-то по-другому (302 на статику).
Что из этого больший костыль, сами понимаете, сказать сложно и сильно зависит от инфраструктуры.
Если мы статику уже отдали, то «доотдача» каких-то мелочей с более близкого сервера не очень спасает.
Спасибо за интересное направление, ваш комментарий довёл до интересной мысли:
Решение всё-таки есть: при первом запросе (статика/динамика — не важно) можно на уровне nginx ставить куку с кодом региона и потом в зависимости о неё как-то это обрабатывать или http_sub-ом или как-то по-другому (302 на статику).
Что из этого больший костыль, сами понимаете, сказать сложно и сильно зависит от инфраструктуры.
8.8 и даже, вроде, opendns отдают оригинальный ИП, того, кто запросил.
tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
На сайте developers.google.com
In addition, Google Public DNS engineers have proposed a technical solution to the issue in an IETF draft, Client subnet information in DNS requests. This proposal defines an EDNS0 extension which allows resolvers to pass in part of the client's IP address as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver.
tools.ietf.org/html/draft-vandergaast-edns-client-ip-01
На сайте developers.google.com
In addition, Google Public DNS engineers have proposed a technical solution to the issue in an IETF draft, Client subnet information in DNS requests. This proposal defines an EDNS0 extension which allows resolvers to pass in part of the client's IP address as the source IP in the DNS message, so that nameservers can return optimized results based on the user's location rather than that of the resolver.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
geoDNS с помощью Powerdns и nginx