- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Тренды маркетинга в 2024 году: мобильные продажи, углубленная аналитика и ИИ
Экспертная оценка Адмитад
Оксана Мамчуева
В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
dig: couldn't get address for 'ns1.domain2.com': not found
И что я сделал не так?
Не создал дочерний DNS в домене
Не в каждой панели доменов есть опция дочернего днс. В панели для этого домена таковой нет.
Как выкрутиться в такой ситуации?
А что без дочерних никак не обойтись?
Наши действия
Млять, второй домен Вы размещали через панель? На кой хрен тогда руками бинд рестартили?
Или таки руками куда-то лезли и в конфиги бинда/файлы зон?
А я что неправильно проверяю?
То, что Вы не удосужились прочитать man dig, прежде чем демонстрировать нам "умения" диагностировать им проблемы. На кой хрен присутствующим нужна информация о корневых ДНС-серверах, которую Вы с гордостью продемонстрировали в первом посте.
Почему Вы показываете сериал для domen2 вначале один - а в третьем посте - он совершенно другой (2010080906)?
Покажите сейчас что в файлах зон. Что говорит:
service named restart
Что пишет при этом в логи named (в /var/log/syslog)?
А что без дочерних никак не обойтись?
Слушать поменьше Андрейку. Сейчас он пургу несет.
хух, а я вот думаю что для начала вот эту пургу нужно с конфига named убрать, а потом уже проверить откликаются по dig записи A на вновь созданных ns-aх:
forward first;
forwarders {64.191.100.53;};
Не в каждой панели доменов есть опция дочернего днс. В панели для этого домена таковой нет.
Как выкрутиться в такой ситуации?
А что без дочерних никак не обойтись?
В любой есть
Советую начать с азов: http://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
хух, а я вот думаю что для начала вот эту пургу
Это не пурга. Я думаю - Вы не думали... ;-)
controls how they are used. The default setting is "forward first",
which first asks each of the forwarders, and then tries the normal
approach of doing the legwork itself if that fails.
переводить не буду. А так как forwarders указаный у BasePelleta в конфиге знает о его зоне, то до обработки локальной зоны со свежими данными у него и не доходит. Надеюсь мысль понятна?
Зона domain1.com (здесь все работает, ip немного изменил)
$TTL 3600
domain1.com. IN SOA ns1.domain1.com. domain1.com.gmail.com. (2010073001 10800 3600 604800 86400)
domain1.com. IN NS ns1.domain1.com.
domain1.com. IN NS ns2.domain1.com.
domain1.com. IN MX 10 mail
domain1.com. IN MX 20 mail
domain1.com. IN A 193.169.215.109
www IN A 193.169.215.109
ftp IN A 193.169.215.109
mail IN A 193.169.215.109
smtp IN A 193.169.215.109
pop IN A 193.169.215.109
domain1.com. IN TXT "v=spf1 ip4:193.169.215.109 a mx ~all"
ns1 IN A 193.169.215.109
ns2 IN A 193.169.211.183
Зона domain2.com
$TTL 3600
domain2.com. IN SOA ns1.domain2.com. domain2.com.gmail.com. (2010080907 10800 3600 604800 86400)
domain2.com. IN NS ns1.domain2.com.
domain2.com. IN NS ns2.domain2.com.
domain2.com. IN MX 10 mail
domain2.com. IN MX 20 mail
domain2.com. IN A 193.169.211.183
www IN A 193.169.211.183
ftp IN A 193.169.211.183
mail IN A 193.169.211.183
smtp IN A 193.169.211.183
pop IN A 193.169.211.183
domain2.com. IN TXT "v=spf1 ip4:193.169.215.109 a mx ~all"
service named restart
Stopping named: . [ OK ]
Starting named: [ OK ]
в/var/log/messages
Jan 23 23:01:43 vps2019 named[3577]: starting BIND 9.3.6-P1-RedHat-9.3.6-4.P1.el5 -u named
Jan 23 23:01:43 vps2019 named[3577]: adjusted limit on open files from 1024 to 1048576
Jan 23 23:01:43 vps2019 named[3577]: found 4 CPUs, using 4 worker threads
Jan 23 23:01:43 vps2019 named[3577]: using up to 4096 sockets
Jan 23 23:01:43 vps2019 named[3577]: loading configuration from '/etc/named.conf'
Jan 23 23:01:43 vps2019 named[3577]: using default UDP/IPv4 port range: [1024, 65535]
Jan 23 23:01:43 vps2019 named[3577]: using default UDP/IPv6 port range: [1024, 65535]
Jan 23 23:01:43 vps2019 named[3577]: listening on IPv4 interface lo, 127.0.0.1#53
Jan 23 23:01:43 vps2019 named[3577]: listening on IPv4 interface venet0:0, 193.169.215.109#53
Jan 23 23:01:43 vps2019 named[3577]: listening on IPv4 interface venet0:1, 193.169.211.183#53
Jan 23 23:01:43 vps2019 named[3577]: listening on IPv4 interface venet0:2, 193.169.215.118#53
Jan 23 23:01:43 vps2019 named[3577]: command channel listening on 127.0.0.1#953
Jan 23 23:01:43 vps2019 named[3577]: command channel listening on ::1#953
Jan 23 23:01:43 vps2019 named[3577]: the working directory is not writable
Jan 23 23:01:43 vps2019 named[3577]: zone domain2.com/IN: sending notifies (serial 2010080907)
Jan 23 23:01:43 vps2019 named[3577]: zone domain1.com/IN: sending notifies (serial 2010073001)
Jan 23 23:01:44 vps2019 named[3577]: client 193.169.211.183#40531: received notify for zone 'domain1.com'
delicate,
Так пургу убирать?
forward first;
forwarders {64.191.100.53;};
Советую начать с азов
Прочитал
Так пургу убирать?
попробуй, не поможет вернешь обратно. Но как по мне, если не использовать bind как рекурсор, то эти строчки вообще не нужны.
переводить не буду. А так как forwarders указаный у BasePelleta в конфиге знает о его зоне, то до обработки локальной зоны со свежими данными у него и не доходит. Надеюсь мысль понятна?
А Вы попробуйте :-) Заодно и переведите текст, т.к. создалось впечатление что Вы его не поняли.
Разжую. Особенно в случае когда forwarders вообще ничего о зоне не знают (домен даже не делегирован) - логика совсем проста... Работаем дальше, в частности смотрим зоны, для которых мы авторитативны.
BasePelleta, покажите что сейчас говорит bind про вашу зону:
dig @193.169.215.109 domain2.com
dig @193.169.215.109 ns1.domain2.com