Установка DNS записывает для общего хоста

Обращение 1 и 2: В большинстве случаев я рекомендовал бы делать единственную запись "A" для фактического IP, связанного с полем и CNAME все, в чем Вы нуждаетесь к этому. Если бы Вы собираетесь иметь много somethings.example.com, я использовал бы подстановочную запись

example.com     A      192.168.0.1
*.example.com   CNAME  example.com

Так как преимущество - это, Вы не должны делать большого обслуживания DNS как безотносительно .example.com, который Вы используете, будет уже соответствовать. Вы просто позволяете апачской фигуре, что сделать с нею на основе данного имени. Это привело бы к 2 поискам, и я только сделаю много CNAMEs к одному A и не попытаюсь делать CNAME-> CNAME. Дополнительно записи MX должны только указать на рекордное имя.

Если когда-нибудь необходимо отламывать vhost к его собственному адресу IP, можно затем просто добавить запись "A" для того одного хоста и большинства - определенный ответ победит.

example.com     A      192.168.0.1
*.example.com   CNAME  example.com
new.example.com A      192.168.0.2

Любой данный IP-адрес может иметь как много RR, указывающих на него, как Вы хотите. Вы можете иметь затем:

server.example.com. IN A 192.168.0.1
www.example1.com. IN A 192.168.0.1 
:
www.exampleN.com. IN A 192.168.0.1

Вам только нужен один PTR для 192.168.0.1. В данном случае самое соответствующее, кажется:

1.0.168.192.in-addr.arpa. IN PTR server.example.com.

Однако любой другой выбор был бы одинаково корректен, пока это - то.

Это происходит, потому что, когда машина (A) соединяется с сервером (B), она не знает название A, только его IP-адрес. Путем изложения PTR запрашивают на DNS, это получает имя как ответ. Таким образом, теперь B знает, что, кто бы ни соединился на нем (вероятно), назван A. Для проверки это, спрашивает снова DNS, "каков IP-адрес A?" и ожидает, что ответ будет содержать IP-адрес, который он уже знает об от данных о соединении. То, что происходит, когда ответ не соответствует тому, что ожидается, является вопросом политики администрирования сервера.

Можно создать CNAMEs вместо нескольких записей, если Вы желаете. Это означает, что, когда кто-то хочет узнать IP-адрес B (чтобы соединиться с ним) это спрашивает DNS дважды: Во-первых, "каково настоящее имя B?" и затем, "каков IP-адрес того имени?".

Отметьте, хотя это, у Вас не может быть CNAMEs, объединенного с записями MX, и поэтому если по некоторой конкретной причине необходимо принять электронную почту, направленную к user@www.example3.com, затем www.example3.com, должно быть записью.

1. Необходимо указать на PTR на host.example.com для предотвращения ошибок доставки почты, как adamo объясняет. Можно указать на CNAME на любой хост, я предпочел бы host.example.com.
2. Вы могли использовать или CNAME или записи для Ваших виртуальных хостов, но возможно рекордное разрешение будет более эффективным.
3. Необходимо установить рекорд SPF для предотвращения ошибок доставки почты с некоторых серверов, "v=spf1 mx - все" являются хорошей начальной точкой и позволят только MX поставлять для домена.

Здесь у Вас есть очень хороший и бесплатный инструмент для проверки конфигурации:

http://clez.net/net.dns?ip=example.com#graph

Для каждого домена необходимо создать отдельный зональный файл, например, для example.com Вы создадите названный файл db.com.example.

Затем настройте свою запись SOA:

$TTL 86400
@ IN SOA ns.example.com. hostmaster.example.com. (
    2010102601 ; Serial
    7200       ; Refresh (how often slave nameservers check with master for changes)
    1200       ; Retry (how often slaves contact the master if XFER fails)
    2419200    ; Expire
    86400      ; Negative Cache TTL
    )
    NS ns ; inet of our nameserver
    NS ns.secondary.com. ; secondary dns
    MX 50 mail ; smtp server

; nameserver
ns A 192.168.0.1

; mail
mail A 192.168.0.1

; canonical names
www CNAME ns

В основном ваше дело, используете ли Вы a www CNAME или www A запись. Что-то для знания - то, что крупные организации иногда испытывают затруднения, когда существует слишком много цепочек CNAME. Это вряд ли будет проблемой для Вас, как бы то ни было.

Запись PTR (обратный поиск) не будет существовать в этом зональном файле. Это будет, вероятно, расположено в зональном файле, управляемом Вашим интернет-провайдером.

См. http://tldp.org/HOWTO/DNS-HOWTO-5.html

Установка записей как теоретически должна быть быстрее как в сценарии CNAME необходимы, два запроса DNS.