search.com вместо этого 404 на CentOS
Каждой записью является RTT (круговая задержка) для конкретного датчика к конкретному хосту. Т.е. времена RTT для второго хоста транзитного участка (reserve.cableplus.com.cn) составляли 75 мс, 71 мс и 73 мс для первых, вторых, и третьих датчиков соответственно.
На Linux можно изменить количество запросов/датчиков к каждому хосту с-q.
Я уверен, что это не проблема CentOS.
На моем CentOS 5.6, если я dig sjdhfgjsdhfgs123123.com Я возвращаю ответ NXDOMAIN.
В любом случае Вы не должны получать 404.
404 средства, что сервер существует, достижимы, но страница, которую требуют, не найдена.
Необходимо получить что-то как сервер, не найденный.
И я высоко подозреваю Ваших поставщиков DNS, являющийся причиной.
Попробуйте другой DNS за тестирование. Изменение/etc/resolv.conf - удаляет весь othere сервер DNS и добавляет 8.8.8.8
8.8.8.8 общедоступный сервер DNS, управляемый Google, я не рекомендую использовать этого все время, но для тестирования он должен быть прекрасным.
править-
Вторая идея:
Что содержит Ваш/etc/resolv.conf?
Могло случиться так, что Ваш поисковый список содержит "search.com", который означал бы, что, если бы приложение пытается разрешить sjdhfgjsdhfgs123123.com, оно также попробовало бы sjdhfgjsdhfgs123123.com.search.com - и это перенаправило бы Вас на search.com
править-
Третья идея:
Добавьте в своем/etc/resolv.conf search local на вершине.
Если Вы не укажете поисковый список, то он примет значение по умолчанию к доменной части, в которой Ваш хост.
Если Ваш хост something.com это приняло бы значение по умолчанию к com в моем понимании.
Если Вы поиск idontexistfjsdhfsd.com это также попробует idontexistfjsdhfsd.com.com и com.com снова домен CNET, который мог перенаправить Вас где-нибудь.
Все еще это не объяснило бы почему a host idontexistfjsdhfsd.com отчеты NXDOMAIN также - но это стоит того, чтобы попытаться.