|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Evgeny Novikov 2:5020/400 24 Apr 2002 10:23:36
To : Rashid N. Achilov
Subject : Re: что происходит?
--------------------------------------------------------------------------------
> А не make-money ли это?
Такой вот лог пишет внутренний нэймд, если не прикрыть те сети
Apr 21 00:07:00 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.31].53
Apr 21 00:07:03 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.42].53
Apr 21 00:07:05 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.2].53
Apr 21 00:07:06 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.31].53
Apr 21 00:07:09 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.42].53
Apr 21 00:07:11 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.2].53
Apr 21 00:07:11 main named[123]: ns_resp: TCP truncated:
"42.220.218.216.in-addr
..arpa" IN PTR from [216.218.220.31].53
В Орелли на этот счет написано следующее:
[no]ignoretc
By default, nslookup doesn't ignore truncated packets. If a packet is
received that has the "truncated" bit set - indicating that the name server
couldn't fit all the important information in the UDP response packet -
nslookup doesn't ignore it; it retries the query using a TCP connection
instead of UDP. Again, this matches the BIND resolver behavior. The reason
for retrying the query using a TCP connection is that TCP responses can be
twice as large as UDP responses. TCP responses could be many times the size
of a UDP response (a TCP connection can carry much more data than a single
UDP packet), but the buffers BIND uses for a TCP query are only twice as
large as the UDP buffers.
Hо не может же TCP-трафик превышать UDP настолько? Чтобы за сутки 2Г
выходило?
Ситуация осложняется тем, что на внутреннем сервере стоят вместе нэймд и
сквид через который работают все юзера.
Таким образом, если включить лог DNS запросов, то нэймд пишет что запрос
инициируется сквидом, а не юзером. И поэтому , кто реально обращается к нэйм
ду с этим запросом непонятно. В логе же сквида на этот счет ничего нет.
Как вычислить, кто инициирует этот запрос, чтото я не пойму...
--- ifmail v.2.15dev5
* Origin: posted via PTT-Teleport ISP, AS6795 (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
