Моделирование DNS для тестирования?

Не уверенный, чего Вы хотите достигнуть точно. Самый тривиальный способ удостовериться, что определенное поле отвечает на определенный запрос DNS с определенным IP, состоит в том, чтобы отредактировать файл hosts. Если Вы хотите видеть, какие запросы DNS Ваша система делает, можно использовать wireshark или tcpdump. Если Вы на самом деле хотите моделировать нестабильность/задержку/причудливость DNS, Вам нужна тривиальная реализация сервера DNS, такая как http://code.activestate.com/recipes/491264-mini-fake-dns-server/.

Для местоположения файла hosts см. http://en.wikipedia.org/wiki/Hosts_%28file%29 (!).

Править: Это походит, для тестирования необходимо только обмануть машину, выполняющую тестирующий клиент (клиенты), что dev сервер является mywebsitedomain1.co.uk. Если клиенты тестирования не выполняют его собственный выделенный сопоставитель DNS (например, использование libadns), редактирование файлов hosts должно быть прекрасным. Отметьте следующий взлом в качестве примера, который я имею в своем/etc/hosts:

127.0.0.1       localhost repo.company.com
127.0.1.1       wonky.example.com     wonky

Вторая строка является стандартной в большинстве современных дистрибутивов Linux. В первой строке я притворяюсь, что мой localhost является нашим репозиторием Подверсии, так, чтобы я мог затем туннелировать что трафик к моей сети рабочего места. URL http://repo.company.com/projectsource будет на самом деле решать на http://127.0.0.1/projectsource, но все еще содержать Хост заголовка хоста HTTP: repo.company.com.

Это кажется, что обращается к Вашей потребности?

Не уверенный, что Вы имеете в виду для "одного шага вперед", но позволяете нам иметь удар в темноте. Asuming, которые Вы используете *, отклоняют поле для Вашего dev сервера и тестируют Ваш 'сайт копии' с Вашего dev сервера. Каждый компьютер имеет 127.0.0.1 адреса (он назвал петлевой сетевой адрес, которые означают, что никакой реальный трафик никогда не оставляет Ваш компьютер) Из Вашей первой апачской virtualhost конфигурации. Мы видим, что Ваш апач работает на петлевом IP-адресе. Так в основном необходимо перенаправить запрос DNS для mywebsitedomain1.co.uk к 127.0.0.1. Это достигается путем добавления одной строки на/etc/hosts файле как это: 127.0.0.1 mywebsitedomain1.co.uk И Вы установлены для тестирования Вашего сценария в этом dev сервере

Теперь, если Вы хотите взять это далее, я предлагаю, чтобы Вы использовали другой компьютер для тестирования сценария. Мы назовем этот компьютер как clientB и Ваш dev сервер как Дева.

Необходимо будет установить возможность соединения реальной сети между Девой и clientB. Мы будем придерживаться частного IP-адреса. Мое предложение похоже на этот IP Девы: 192.168.12.34 подсетей 255.255.255.0 и не устанавливают сервер clientB IP DNS или шлюз: 192168.12.56 подсетей 255.255.255.0 также не устанавливают шлюз, но устанавливают сервер DNS на IP Девы

Далее. Установите dnsmasq на своей Деве. Это - простой DNS, dhcp и tftp сервер. В конфигурации по умолчанию dnsmasq считает Ваш/etc/hosts файл и заполнит его базу данных DNS. Но можно настроить его, чтобы не считать/etc/hosts, но получить базу данных из другого файла, который Вы указываете. Порт udp 53 использования Dnsmasq на Вашем сервере Девы так не забывает разблокировать его от Вашего dev брандмауэра сервера (если существует). Необходимо также изменить апачскую конфигурацию для отражения изменения в IP-адресе к 192.168.12.34

Теперь необходимо протестировать разрешение DNS от clientB. При проверке с помощью ping-запросов mywebsitedomain1.co.uk, необходимо получить ответ от 192.168.12.34 вместо общедоступного IP-адреса.

Если все корректно, необходимо смочь протестировать сценарий с уверенностью, что он будет работать с 'живым' веб-сайтом

Удачи