# PTR запис: как от име на хост става фирма

> PTR записът свързва IP адрес с име на хост. Как да го четете, да разпознавате събирателни имена и да стигате от домейна до фирмата.

Quelle: https://whovisit.app/bg/blog/ptr-zapis-ot-ime-na-hosta-kam-firma
Veröffentlicht: 2026-11-07
Herausgeber: Whovisit (ARAVILO, Innsbruck)

Който иска да знае на кого принадлежи един IP адрес, обикновено поглежда в мрежовия регистър, при европейските адреси тоест в базата данни на RIPE. Има втори път, който често се пренебрегва: обратното търсене в DNS. Тогава не питате „На кого е мрежата?“, а „Как се казва хостът зад този адрес?“. Ако в името стои домейнът на една фирма, имате използваема следа.

Тази статия обяснява какво е PTR запис (PTR-Record), кой го задава, по какво различавате използваемите от безполезните записи и къде методът среща граници. Пътя през мрежовия регистър описва [Reverse IP Lookup, обяснен просто](https://whovisit.app/blog/reverse-ip-lookup-erklaert).

## Какво е PTR запис

DNS познава две посоки. Обикновено питате за име и получавате адрес (A или AAAA запис). PTR записът (на английски *pointer record*) е обратната посока: към един адрес връща име.

Технически за целта адресът се обръща и се снабдява със специално окончание. От `203.0.113.25` се получава заявката `25.113.0.203.in-addr.arpa`. При IPv6 окончанието е `ip6.arpa`. Адресът се обръща знак по знак. Отговорът е име на хост, например `mail.beispiel-firma.example`.

Важно: PTR записът е доброволен. Има адреси без запис. Записът не е нужно да съвпада с прекия запис. Той е указание, а не доказателство.

## Кой го задава

PTR записа поддържа този, който управлява адресния блок:

- **Доставчиците** задават за клиентските си връзки обикновено автоматично генерирани събирателни имена.
- **Фирмите със собствен адресен блок** поддържат записите сами и често вписват собствения си домейн.
- **Бизнес връзките** получават при някои доставчици по желание запис с домейна на клиента. Това се случва най-вече при пощенски сървъри, защото много получатели отхвърлят имейли от адреси без подходящо име на хост.

От това следва: запис със собствен домейн е знак, че някой съзнателно се е погрижил за адреса. Автоматично генерирано име казва нещо само за доставчика.

## Разпознаване на модела: събирателно име или собствен домейн

Името на хоста се състои от две части: предна част (`mail`, `pool-1-2-3-4`) и регистрируемия домейн накрая (`beispiel-firma.example`). Домейнът Ви издава оператора, предната част Ви издава дали името е зададено на ръка или автоматично.

Типични признаци за **събирателно име**, което не издава фирма:

- части от адреса стоят в името: `203-0-113-25.provider.example` или `25.113.0.203.provider.example`
- думи като `dyn`, `dynamic`, `dial`, `pool`, `dsl`, `adsl`, `cable`, `cust`, `customer`, `mobile`, `lte`, `static`, `nat`, `cgn`, `client`
- домейн, който очевидно принадлежи на доставчик, хостинг компания или център за данни

Типични признаци за **използваемо име**:

- говореща предна част като `mail`, `gw`, `fw`, `vpn`, `proxy` или `smtp`
- няма части от адреса в името
- домейн, който очевидно принадлежи на предприятие, а не на доставчика

| Име на хост (измислен пример) | Оценка |
|---|---|
| `dyn-203-0-113-25.dsl.provider.example` | Събирателно име на доставчика, без твърдение за притежателя на връзката |
| `pool-25.cust.provider.example` | Събирателно име, клиентска връзка |
| `mail.beispiel-firma.example` | Собствен домейн, кандидат за причисляване към фирма |
| `vpn.beispiel-firma.example` | Собствен домейн, кандидат за причисляване към фирма |
| `ec2-203-0-113-25.compute.cloud.example` | Център за данни, клиент на хостинга, а не самият хостинг |

Таблицата показва и един капан: ако домейнът идва от доставчика или от хостинга, името не Ви върши работа, дори да изглежда добре. Използваемата оценка изисква затова списък с известни домейни на доставчици и хостинги, които се изключват.

## От домейна до фирмата

Домейнът още не е фирма. Обичайният път към фирмата минава през уебсайта зад домейна:

1. Определете регистрируемия домейн. От `mail.beispiel-firma.example` става `beispiel-firma.example`. При окончания като `co.uk` се броят три части.
2. Отворете импресума. В Германия, Австрия и Швейцария търговските уебсайтове трябва да назовават оператора, най-често с правна форма (GmbH, AG, KG и така нататък).
3. Прочетете правното име и проверете дали принадлежи на юридическо лице, а не на частно лице.

Текстовото търсене има граници. Импресумите не са изградени еднакво, някои страници зареждат съдържанието едва чрез скрипт. Понякога в импресума стои агенция или компания майка. Автоматичното причисляване затова остава предложение, което човек при съмнение проверява. Алтернативно фирмените бази данни връщат към един домейн името на фирмата, и това никога не е пълно.

## Опитайте сами

Не се нуждаете от специален софтуер. Под macOS и Linux има `dig`, под Windows `nslookup`. Примерите използват `203.0.113.25`, адрес от областта за документация (RFC 5737). Той не принадлежи на никого и затова няма истински запис. За собствени опити въведете адреса на Вашата собствена връзка или на сървър.

```bash
# Обратно търсене, само отговорът
dig -x 203.0.113.25 +short

# Подробно, с обърнатата заявка
dig -x 203.0.113.25

# Windows, macOS и Linux
nslookup 203.0.113.25
```

Така четете изхода:

- При `+short` в отговора стои само името на хоста, например `mail.beispiel-firma.example.` (точката накрая е нарочна). Ако не се върне нищо, няма запис.
- Без `+short` dig показва в раздела `QUESTION` обърнатата заявка с `in-addr.arpa`. В раздела `ANSWER` стои редът с `PTR` и името.
- Статусът `NXDOMAIN` означава: за този адрес няма запис. `SERVFAIL` или изтичане на времето означава: отговорният сървър за имена не отговаря.
- `nslookup` показва `name =`, следвано от името на хоста, или съобщението, че името не е намерено.

Като контролна проверка попитайте името в права посока (`dig beispiel-firma.example +short`). Ако името отново сочи към същия адрес, записът е по-достоверен. Ако правата и обратната посока не съвпадат, е уместна предпазливост.

## Граници на метода

- **Остарели записи.** Адресите сменят собственика си, записите остават. Име, което е било вярно преди години, днес може да води към друга фирма или вече към никоя.
- **Пощенски сървъри на доставчици на услуги.** Много фирми изпращат имейли през хостинг или маркетингов инструмент. Името на хоста тогава сочи към доставчика на услуги, а не към фирмата.
- **Споделени адреси.** Зад адрес с име на фирма могат да седят няколко наематели на офис сграда или коуъркинг пространство. Името тогава принадлежи на наемодателя.
- **Времеви ограничения.** DNS заявките могат да увисват. Който ги оценява във фонов режим, трябва да се откаже след кратко време и не бива да изисква отговора на всяка цена.
- **Домашен офис и мобилна мрежа.** Тук почти винаги има само събирателни имена. Защо е така, е описано в [Домашен офис, VPN и мобилна мрежа: кого не виждате](https://whovisit.app/blog/homeoffice-vpn-mobilfunk-besuchererkennung).

Как PTR, мрежовият регистър и оценката заедно образуват разпознаване на посетители, показва прегледът [Как работи разпознаването на фирми? Технологията в 6 стъпки](https://whovisit.app/blog/firmenerkennung-website-technik). Там е обяснено и защо попаденията се колебаят силно според целевата група.

Пример от практиката: Whovisit използва обратното търсене само при адреси от мрежи на доставчици, отхвърля събирателните имена и известните домейни на доставчици, чака най-много две секунди за отговора и запомня само съпоставката на домейн с фирма, никога IP адреса. Какви класове посетители има и какво означават, е описано в помощта под [Класове посетители: фирма, интернет доставчик, център за данни](https://whovisit.app/hilfe/besucherklassen-verstehen).

## Накратко

PTR записът е доброволно указание за името на хоста зад един адрес. Ценен става, когато името съдържа собствен фирмен домейн и не показва модели на доставчик. От домейна до фирмата по правило води импресумът. Всяко причисляване остава предположение с процент грешки. Липсата на запис е по-добра от грешния.