The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Открытые системы на сервере (DNS / Linux)
Изначальное сообщение [ Отслеживать ]

"Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Stranger03 (ok) on 17-Июн-17, 12:29 
Есть сервер на Ubuntu 5.4.0, версия ядра 4.4.0-79. Настраивал DNS+DHCP с динамическим обновлением записей в DNS зонах по вот это статье:

https://howitmake.ru/blog/ubuntu/96.html

Все вроде бы прекрасно работает. На сервере DHCP указано выдавать адрес на сутки. Вот пример лога:

lease 192.168.1.241 {
  starts 6 2017/06/17 08:32:52;
  ends 1 2017/06/19 08:32:52;
  cltt 6 2017/06/17 08:32:52;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet 28:e0:2c:3d:d6:81;
  uid "\001(\340,=\326\201";
  set ddns-fwd-name = "host-NB10.home.local";
  set ddns-txt = "31a8a8dfc924d2d084735ef275aa2b5c97";
  set ddns-rev-name = "241.1.168.192.in-addr.arpa.";
  client-hostname "host-NB10";
}

Основная и реверсная зоны создавались без записей о клиентах, прописывая только адрес сервера:

$TTL 86400      ;       1 day
home.local.     IN      SOA     4proxy.home.local. admin.home.local. (
                                20170615        ; Serial
                                10800           ; Refresh
                                7200            ; Retry
                                604800          ; Expire
                                86400           ; Minimum TTL
                        )

                IN      NS      4proxy.home.local.
                IN      A       192.168.1.5
localhost       IN      A       127.0.0.1
4proxy          IN      A       192.168.1.5

Запись в dhcpd.conf:

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.25 192.168.1.250;
  option domain-name-servers 77.88.8.8, 77.88.8.1, 8.8.8.8;
  option domain-name "home.local";
  option subnet-mask 255.255.255.0;
  option routers 192.168.1.5;
  option broadcast-address 192.168.1.255;
  option netbios-name-servers 192.168.1.5;
  option netbios-node-type 8;
  default-lease-time 86400;
  max-lease-time 172800;
}

Не могу понять одного. Во время регистрации записи клиента в прямой и обратной зоне по какой-то причине время жизни записи проставляется 1 час. Записи само собой обновляются автоматически при регистрации и обновления данных клиента.

Вот как сейчас выглядит запись прямой зоны в ddns сервере:

$ORIGIN .
$TTL 86400      ; 1 day
home.local              IN SOA  4proxy.home.local. admin.home.local. (
                                20170623   ; serial
                                10800      ; refresh (3 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)
                                )
                        NS      4proxy.home.local.
                        A       192.168.1.5
$ORIGIN home.local.
4proxy                  A       192.168.1.5
$TTL 3600       ; 1 hour
host-NB10           A       192.168.1.241
                        TXT     "31a8a8dfc924d2d084735ef275aa2b5c97"
$TTL 86400      ; 1 day
localhost               A       127.0.0.1

Вопрос: где надо указать, чтобы время записи в прямой и обратной зоне было скажем сутки? Собственно речь идет об этой записи. Где указать, чтобы время жизни записей было 86400 вместо 3600 (сутки вместо часа):

$TTL 3600       ; 1 hour
host-NB10           A       192.168.1.241
                        TXT     "31a8a8dfc924d2d084735ef275aa2b5c97"

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Аноним (??) on 17-Июн-17, 15:50 
забей, TTL это время в течении которого запись будет _кэшироваться_ на клиентах

представим что всё так как ты неправильно хочешь и TTL у нас сутки:
перед истечением лизы хостА хостB в локалке запрашивает A запись хостА и кэширует на сутки
а DHCPD по каким-то причинам (не важно каким) не продлевает лизу хостуA и выдаёт ему другой ипшник, ессно поправляя динамическую A
что получим?
правильно, у хостаВ целые сутки в кэше будет неправильная А записть хостаА

из чего делаем вывод
что высокий TTL для динамического DNS - ЗЛО
и что надо читать больше матчасти, чтоб разбираться в принципах работы базовых протоколов, чтоб не задавать идиотские вопросы на форумах

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Stranger03 (ok) on 17-Июн-17, 17:33 
> и что надо читать больше матчасти, чтоб разбираться в принципах работы базовых
> протоколов, чтоб не задавать идиотские вопросы на форумах

Дружище, а вместо того, чтобы оскорблять незнакомого тебе человека, есть что-то толковое ответить кроме "забей" и "учи матчасть"? Или твое высказывание попытка самовыразиться таким образом?

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Stranger03 (ok) on 17-Июн-17, 21:14 
Поясню, что я имею ввиду, и что меня смущает. Есть с десяток ноутбуков, которые перемещаются по разным сетям. Внутри моей сети они получают адрес на сутки с последующим продлением аренды. Как правило, в 99% этот адрес за ними сохраняется, поскольку из сети ноуты "пропадают" на 3-5-7 часов, потом опять возвращаются. На сервере стоит Squid + SARG, который соотв-но собирает статистику по трафику. Настроен прозрачный трафик на Squid.

Что происходит. Ноут получил адрес:

lease 192.168.1.31 {
  starts 6 2017/06/17 11:54:21;
  ends 0 2017/06/18 11:54:21;
  cltt 6 2017/06/17 17:35:47;
  binding state active;
  next binding state free;
  rewind binding state free;
  hardware ethernet e4:a7:a0:6f:09:f5;
  uid "\001\344\247\240o\011\365";
  set vendor-class-identifier = "MSFT 5.0";
  set ddns-fwd-name = "Host2-NB10.home.local";
  set ddns-txt = "31cd0c440101d97f1255aec1e5f9c78ba0";
  set ddns-rev-name = "31.1.168.192.in-addr.arpa.";
}

Запись в прямую и реверсную зоны были внесены. Все норм, пока ноуты в сети. Но, стоит ноуту "пропасть" из сети на пару часов, а потом вернуться, то увы, кеш DNS сервера куда-то пропадает. Соотв-но, если в это время запустится сбор статистики, то вместо имен там будут безликие IP адреса.

Ну ладно, допустим в прямой и реверсной зоне записи о ноутах не так нужны и не так важны. Но тогда дурацкий вопрос. А куда девается кеш DNS? И почему при возвращении ноута он не возвращается назад?

root@4proxy:/var/lib/bind# nslookup Host2-NB10
Server:         127.0.0.1
Address:        127.0.0.1#53

** server can't find Host2-NB10: NXDOMAIN

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от universite (ok) on 18-Июн-17, 19:18 
Смотрите версию named (bind) и читайте его документацию по поводу дефолтного значения TTL.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от ALex_hha (ok) on 20-Июн-17, 11:28 
А что мешает сделать резервацию для ноутов?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Stranger03 (ok) on 20-Июн-17, 12:24 
> А что мешает сделать резервацию для ноутов?

Ну видимо так и придется сделать. Но, гемор, есть же еще телефоны... Штук 20-ть, :(

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Ubuntu+dhcpd+bind9: откуда берется значение TTL для клиентов"  +/
Сообщение от Stranger03 (ok) on 21-Июн-17, 17:27 
Вообщем отвечу сам себе. Толком решения так и не нашел. Указал в dhcpd сервере привязку hard адресов к ip, в SARG-е вписал таблицу пользователей. Если имя резолвится по ip - добавляется полное. Если не резолвится - добавляется из таблицы SARG-а.

Криво конечно, но хотя бы так.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру