rsync прекрасно подходит начальному резервному копированию также. Если Вы имеете два NICs и замедляете Ethernet-коммутаторы (или те серверы находятся в различных сетях), используйте перекрестные кабели и rsync. Кроме того, если у Вас есть что-то производительность, критическое продолжение, с помощью перекрестного кабеля на вторичном NIC является хорошей идеей, поскольку это разгружает трафик на отдельную плату.
Если у Вас есть 1Gbit/s сетевые платы, то это на самом деле намного быстрее для использования rsync, чем покупка внешнего диска.
Уже упомянутое решение с tar - если существует незначительный сбой, он перестанет работать, и необходимо запустить с начала.
Я действительно, действительно рекомендуйте использовать rsync,
rsync -avz --progress /srv/source -e ssh username@destination.server:/srv/destination
Даже если у Вас есть 100Mbit/s сеть, использование дисков USB является плохим решением - это - что-то как 30MB/s и для записи и для чтения - 15MB/s в среднем, плюс Вы должны вручную переместить его и выполнить те же команды снова. 100Mbit/s о 10MB/s (некоторая сеть, наверху включенная).
Для этой конкретной цели нет запроса, но есть несколько косвенных методов.
AXFR
). Большинство операторов серверов блокируют передачу зон на определенные IP-адреса, чтобы предотвратить отслеживание посторонними сторонами. NSEC
могут использоваться для обхода зоны . NSEC3
был реализован, чтобы сделать обход зоны более ресурсоемким. Также есть уловка, которая позволит кому-нибудь узнать, существует ли произвольный субдомен.
example.com. IN A 198.51.100.1
www.sub.example.com. IN A 198.51.100.2
В приведенном выше примере www
находится в подпункте
. Запрос для sub.example.com IN A
не вернет раздел ANSWER, но код результата будет NOERROR вместо NXDOMAIN, что свидетельствует о существовании записей ниже по дереву. (просто не так, как называются эти записи)
Нет. Единственный способ надежно скрыть данные от клиента - убедиться, что он никогда не сможет получить данные с самого начала. Предположим, что существование ваших записей DNS будет распространяться среди всех, у кого есть доступ к ним, из уст в уста или путем наблюдения за пакетами.
Если вы пытаетесь скрыть записи от маршрутизируемого клиента DNS, Вы » re Doing It Wrong ™ . Убедитесь, что данные доступны только для тех сред, которые в них нуждаются. (т. е. используйте домены с частной маршрутизацией для частных IP-адресов). Даже если у вас настроено такое разделение, предполагайте, что сведения об IP-адресах все равно будут распространяться.
В центре внимания безопасности должно быть то, что происходит, когда кто-то получает IP-адрес, потому что это произойдет.
Я знаю, что список причин того, что секретность IP-адреса является несбыточной мечтой, можно было бы расширить. . Сканирование IP, социальная инженерия ... список бесконечен, и я в основном сосредоточиваюсь на аспектах протокола DNS в этом вопросе. В конце концов, все это под одной крышей: кто-то собирается получить ваш IP-адрес .
Это зависит от обстоятельств.
Ответ Эндрю Б точен, когда вы регистрируете поддомен в публичной зоне DNS, в которой, например, размещаются записи MX вашей компании и публичный веб-сайт.
У большинства компаний есть внутренний DNS-сервер, недоступный публично, на котором вы можете зарегистрировать имена хостов для своих внутренних ( секретных ) хостов.
Рекомендуемый метод - зарегистрировать выделенный домен для внутреннего использования или, альтернативно, создать субдомен в основном домене для внутреннего использования.
Но технически вы также используете свой основной домен, создавая внутреннее представление своего домена, где в зависимости от происхождения клиента DNS будет видна альтернативная версия зоны DNS.
Дополнительно к Andrew anwser
AXFR
запросы могут быть выполнены с помощью одной из следующих команд:
dig @8.8.8.8 mydomain.com. AXFR
nslookup -query=AXFR mydomain.com 8.8.8.8
host -l mydomain.com
Существуют также некоторые скрипты грубой силы (например, WS-DNS-BFX), использующие словарь для угадывания других записей DNS