Мне, кстати, когда пришлось нарисовать интерфейс юзера (довольно примитивный), найти неудобные, странные или двусмысленные для будущего пользователя места помог учебник по тестированию, в котором немало места было отведено под важность удобства междумордия.
Сказать по правде, я уже не вспомню за давностью. Сейчас я уже года полтора-два пользуюсь вимператором и пентадактиль проходит мимо меня. Я, собственно, про киллер-фичу поинтересовался чтобы узнать различия и могут ли они быть мне полезными.
А в чем киллер-фича Pentadactyl по сравнению с Vimperator? Лично для вас?
Я им пользовался только в то время, когда текущая версия вимператора не работала в текущей версии лисы и впечатления остались скорее негативные.
Я сразу перешел к «одно приложение на рабочий стол» с исключением для приложений, типа терминала, которым мои 1920*1200 только вредят. Наиболее простой и, как мне кажется, удобный вариант.
Ну да :) я рассказал почему rtt лучший показатель чем географическая близость. Отвечая на ваш: бОльшим простором для маневра.
А если пользователь пришел из Новой Зеландии, какой адрес ему отдать? Как вы можете быть уверены, что этот адрес будет для него актуален?
Кроме того, в драфте не указано, что у администратора DNS должна быть возможность явно указывать кому что отдавать. То есть, на данный момент это зависит от реализации. Соответственно, если выбор кому что отдать происходит автоматически, то могут быть очень неприятные и непредсказуемые казусы.
К примеру у меня есть два сервера, в Америке и России, как DNS сервер выберет какой адрес отдать, если оба проходят в GeoIP как российские?
На мой взгляд, гораздо полезней дать клиенту выбирать какой сервер ему ближе. Клиент сделает этот выбор эффективней.
И я тут еще касательно рекламы пообщался: у опенднс есть фича, что они показывают рекламу при, к примеру, NXDOMAIN. Вот тут есть простор для улучшения точности показа.
Вычислений он никаких не производит, а в кэше хранит помимо ответов еще и сети клиентов, которым эти ответы предназначались. То есть памяти будет жрать больше.
Где еще полезно применять описанное в драфте, кроме связки CDN + 3rd party DNS (типа OpenDNS, SkyDNS), я не знаю. Да и в такой связке, преимущества спорны.
Принципиально rtt — более объективная (в части скорости доступа) величина. В некотором роде rtt противоположно предлагаемому в драфте. Там DNS сервер говорит клиенту куда идти, rtt — клиент сам выбирает. Такой подход с точки зрения массового пользователя правильней.
Кроме этого к драфту есть еще некоторое кол-во претензий:
1) Никак не описано каким образом авторитетный сервер генерирует ответ, отдает он адрес только ближайшего сервера или нескольких ближайших? Если второе, то эффективность метода несколько падает.
2) Как фича из драфта коррелирует с DNSSEC? Если плюет на него, то достоверность данных проверить нельзя. Если не плюет, тогда в ответе авторитетный сервер должен указать все адреса, потому что подписывается набор записей, а не по одной, и смысл драфта в общем-то пропадает.
По поводу таргетирования я не буду спорить, потому как не осведомлен о технологиях.
Рекламу они хотят лучше таргетировать, а не интернет ускорить.
Чтобы ускорить доступ нужно не географически близкий сервер выбирать, а тот, до которого ртт меньше. Потому что географически сервер может в соседней комнате стоять, но если маршрут к нему пролегает через западное полушарие или он загружен «с горкой», то можно представить как будет «ускорен» доступ при использовании этой технологии.
а для отдельных зон: zone "example.com {
type master;
forwarders {};
file "/path/to/zonefile";
}
В результате такой сервер будет обрабатывать все запросы к зоне example.com, а остальное слать каким-нибудь, например провайдерским, резолверам.
Если же имеется белый ип, то все еще проще — достаточно просто рекурсию не запрещать.
На самом деле, сейчас RIPE внезапно опомнилась и начал проводить политику выдачи IPv6 PI лирам только для конечного пользователя. Все из-за того, что они не могут придумать как им по-человечески тарифицировать.
Форма подачи «а-ля хауту» — это плохо. очень плохо.
За информацию, что есть такая штука как pymorphy — спасибо.
И еще, может стоит упомянуть, что кодировка должна быть utf-8?
Это DNS серверы, авторитетный и рекурсивный, соответственно. Они не предоставляют средств управления ключами.
Ldns — это библиотека, в компании с ней идет несколько программ в качестве примеров. Конечно, если нет задачи автоматизировать ротацию, подписывание и не следить за временем жизни подписей, эти примеры можно использовать, но я надеюсь, Вы так делать не будете :).
Дело в том, что по сути софта для DNSSec не так много, основные программы — Opendnssec (от компании с аналогичным названием) и dnssec-* (ISC). У первых удобнее управлять ключами, у вторых выше скорость подписи. Однако при небольших зонах (примерно до ста тысяч записей) разница в скорости не сильно заметна. Соответственно очевидным выбором (если зона не содержит миллионы записей) является Opendnssec, тем более, что со следующим релизом они собираются это отставание убрать.
Как пользоваться соответствующей софтиной лучше прочитать в документации; про софт, DLV, ключи, их ротацию и рекомендации я, если интересно, расскажу в следующий раз; а вот писать подробное хау-ту я бы не хотел — хаутушки на мой взгляд крайне отрицательное явление и использования их стоит избегать.
Я им пользовался только в то время, когда текущая версия вимператора не работала в текущей версии лисы и впечатления остались скорее негативные.
А если пользователь пришел из Новой Зеландии, какой адрес ему отдать? Как вы можете быть уверены, что этот адрес будет для него актуален?
Кроме того, в драфте не указано, что у администратора DNS должна быть возможность явно указывать кому что отдавать. То есть, на данный момент это зависит от реализации. Соответственно, если выбор кому что отдать происходит автоматически, то могут быть очень неприятные и непредсказуемые казусы.
К примеру у меня есть два сервера, в Америке и России, как DNS сервер выберет какой адрес отдать, если оба проходят в GeoIP как российские?
На мой взгляд, гораздо полезней дать клиенту выбирать какой сервер ему ближе. Клиент сделает этот выбор эффективней.
И я тут еще касательно рекламы пообщался: у опенднс есть фича, что они показывают рекламу при, к примеру, NXDOMAIN. Вот тут есть простор для улучшения точности показа.
Где еще полезно применять описанное в драфте, кроме связки CDN + 3rd party DNS (типа OpenDNS, SkyDNS), я не знаю. Да и в такой связке, преимущества спорны.
Кроме этого к драфту есть еще некоторое кол-во претензий:
1) Никак не описано каким образом авторитетный сервер генерирует ответ, отдает он адрес только ближайшего сервера или нескольких ближайших? Если второе, то эффективность метода несколько падает.
2) Как фича из драфта коррелирует с DNSSEC? Если плюет на него, то достоверность данных проверить нельзя. Если не плюет, тогда в ответе авторитетный сервер должен указать все адреса, потому что подписывается набор записей, а не по одной, и смысл драфта в общем-то пропадает.
По поводу таргетирования я не буду спорить, потому как не осведомлен о технологиях.
Чтобы ускорить доступ нужно не географически близкий сервер выбирать, а тот, до которого ртт меньше. Потому что географически сервер может в соседней комнате стоять, но если маршрут к нему пролегает через западное полушарие или он загружен «с горкой», то можно представить как будет «ускорен» доступ при использовании этой технологии.
options {
forward only;
forwarders {
ip-addresses-of-resolvers;
};
а для отдельных зон:
zone "example.com {
type master;
forwarders {};
file "/path/to/zonefile";
}
В результате такой сервер будет обрабатывать все запросы к зоне example.com, а остальное слать каким-нибудь, например провайдерским, резолверам.
Если же имеется белый ип, то все еще проще — достаточно просто рекурсию не запрещать.
За информацию, что есть такая штука как pymorphy — спасибо.
И еще, может стоит упомянуть, что кодировка должна быть utf-8?
Ldns — это библиотека, в компании с ней идет несколько программ в качестве примеров. Конечно, если нет задачи автоматизировать ротацию, подписывание и не следить за временем жизни подписей, эти примеры можно использовать, но я надеюсь, Вы так делать не будете :).
Как пользоваться соответствующей софтиной лучше прочитать в документации; про софт, DLV, ключи, их ротацию и рекомендации я, если интересно, расскажу в следующий раз; а вот писать подробное хау-ту я бы не хотел — хаутушки на мой взгляд крайне отрицательное явление и использования их стоит избегать.