чи можливо сервер знати, який клієнт (IP) виконував запит DNS для свого доменного імені?


2

Припустимо, я маю доменне ім'я, наприклад, myproxy.com. Тоді я маю багато сайтів, як kitty.myproxy.com , wow.myproxy.com Я хочу налаштувати авторитетний DNS-сервер для доменного імені.

Сподіваюся, якщо користувач захоче відвідати ці веб-сайти, коли браузер надсилає запит DNS, запит DNS нарешті прибуде до авторитетного DNS-сервера. і таким чином, авторитетний може отримати IP хоста, який виконав запит DNS.

Мої очікування: всі запити DNS для цих веб-сайтів повинні бути надіслані до авторитетного DNS-сервера, щоб я міг знати всі хости, які виконували запити DNS. Чи це можливо чи ні?

Я боюся, що деякі інші DNS-сервери, які кешують записами DNS, так що цей DNS-сервер відповідатиме DNS-запитам, то ці запити не будуть переадресовані до авторитетного DNS-сервера. Чи можна запобігти цьому?

Примітка: я займаюся дослідницькою роботою. Моя мета - зробити проксі. Є багато веб-серверів, які реєструються на проксі. Тільки проксі знає IP цих веб-серверів. Коли браузер хоче відвідати один з цих веб-серверів, він може отримати IP-адресу проксі-сервера від запиту DNS. А потім він підключається до проксі. Я сподіваюся, що проксі може точно знати, який веб-сервер цей браузер хоче відвідати, коли приходить TCP SYN (до HTTP-запиту, насправді, розбираючи HTTP-запит, проксі може дізнатися, який веб-сервер хоче відвідати веб-переглядач) . Отже, якщо веб-браузер робить запит DNS і цей запит відомий проксі-серверу, проксі-сервер може кешувати відображення між веб-сервером і IP-адресою браузера. Коли приходить TCP SYN, проксі-сервер негайно перевіряє відображення і дізнається, який веб-сервер браузер дійсно хоче відвідати. Дякую!


2
Яка ваша реальна мета? Це звучить багато, як Проблема XY .
Darth Android

Можливо, ви можете встановити TTL 0, щоб запобігти кешуванню. zytrax.com/books/dns/apa/ttl.html
Der Hochstapler

Більшість нормальних DNS-серверів в інтернеті не зважатимуть на TTL нижче певного мінімального значення.
Shadur

Відповіді:


7

Що ви намагаєтеся зробити? Я думаю, ви намагаєтеся щось зробити, і ви думаєте, що "моніторинг DNS - це відповідь", коли він не працюватиме.

Якщо ви хочете бачити хіт від клієнтського IP-адреси на кожному запиті DNS, це ніколи не станеться. DNS є багаторівневим, і клієнти налаштовані на попадання на локальний DNS-сервер, який згодом вдарить ваш DNS-сервер.

Якщо ви хочете побачити запит (від когось) на кожен запит DNS, ви можете спробувати налаштувати TTL на щось невелике, наприклад, на секунду. Тоді ви побачите хіт від когось, десь. Це не може бути 100% - це залежить від кожного, хто поважає ваш TTL, який не є даним.

UPDATE

Якщо я прочитав правильно, ви намагаєтеся пов'язати запит DNS з майбутнім HTTP-запитом. Це не вдасться з кількох причин.

  1. Кешування. DNS - IP-відображення дуже кешуються, і тому вони сильно кешуються. Навіть налаштування TTL не допоможуть багато чого, оскільки деякі провайдери ігнорують TTL і кеш за годину / день або близько того незалежно від налаштувань. Браузери також мають свій власний кеш DNS. У вас є занадто багато рівнів, щоб контролювати всі.

  2. Кілька користувачів - одна IP-адреса. Між NAT (і Носій класу NAT на горизонті) і звичайних кількох користувачів на машину, ви більше не можете відобразити IP-адресу в браузер (не те, що ви дійсно могли коли-небудь). Навіть кілька браузерів на користувача або кілька вкладок можуть вимкнути цю систему.

  3. Люди можуть використовувати DNS з інших причин. Що робити, якщо хтось просто робить nslookup на одному домені, а потім переходить в інший (з IP в кеші). Ви б відправили не той сайт.

  4. Кілька точок виходу. Незважаючи на те, що в даний час вона є менш поширеною, для провайдерів-провайдерів часто використовувалися проксі-запити, а іноді один абонент міг обертатися на вихідних пунктах (те, що ви бачите як їх IP) навіть на одній сесії. AOL робив це багато, і, як вони знизилися популярність, я бачив інші інструменти (мобільний Opera) використовувати проксі, а також.

  5. Переадресація DNS не працює таким чином . Якщо хтось намагається шукати ім'я хоста на вашому сайті, то більшу частину часу вони займуть, запитуючи сервер Google 8.8.8.8 або рекурсивний сервер DNS свого провайдера. У будь-якому випадку, IP-адреса, яка запитує ваш DNS-сервер для імені хосту, буде ні бути такою ж, як і вихідна IP-адреса веб-переглядача, який з'являється через хвилину.

Коротше кажучи, ви не можете дістатися туди. IP-адреси не є (не є) унікальними ідентифікаторами 1-1 для користувача. Ви б зламали HTTP. Ви застрягли, дивлячись на потік HTTP і синтаксичний аналіз. Переконайтеся, що ваш проксі-сервер підтримує функцію Keep-Alive, і ви трохи зменшите удар.


Налаштування TTL на невелике значення звучить добре. Шкода це не 100%! який відсоток ви оцінюєте? вище 80% або близько 50% або блабла? Я знаю, що комп'ютер може мати локальний кеш DNS, чи буде цей кеш поважати TTL? Дякую!
misteryes

@misteryes неможливо визначити відсоток, оскільки провайдери часто кешують значення, тобто це може бути один клієнт або тисяча. Знову ж таки, що ви хочете зробити? Конкретні дії, про які ви просите, не можуть бути зроблені (через кешування), але ви можете робити те, що ви хочете іншим способом.
Rich Homolka

те, що я хочу зробити, оновлюється в моєму питанні
misteryes

@misteryes Те, що ви хочете зробити, називається "Віртуальний хостинг на основі імені" і вже виконується неодноразово ні Страшні ідеї.
Shadur

1

Як браузер / користувач знає, який запит http потрібно зробити, щоб дозволити своєму проксі-серверу визначити фактичний запитаний сервер?

Якщо ви плануєте мати портал, з якого користувач повинен вибрати сервер, який він хоче, ви можете генерувати випадкові піддомени для вашого проксі-сервера в залежності від вибору користувача / доступності.

Можна побачити подібну реалізацію на демонстрацію нападу на повторну атаку де користувач буде переходити на сервер і оскільки сервер знає ip користувача, сервер створює нову генеровану довільну підпрограму, що визначає бажану IP-адресу сервера на записі DNS і перенаправляє користувача на цей субдомен.

Ви не можете знайти IP-адресу користувача на DNS-сервері.

Як інші писали раніше, ви не повинні покладатися на TTL, оскільки не всі розробники DNS це поважають.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.