DNS-записи домена: что такое A, AAAA, CNAME, MX, TXT, NS, SRV, CAA и как их проверить

DNS-записи домена: что такое A, AAAA, CNAME, MX, TXT, NS, SRV, CAA и как их проверить

SEO Title: DNS-записи домена: A, CNAME, MX, TXT, NS и TTL простыми словами

Meta Description: Объясняем DNS-записи для новичков: A, AAAA, CNAME, MX, TXT, NS, SRV, CAA, PTR и SOA. Практические примеры, TTL, распространение изменений, nslookup и dig.

Recommended Slug: dns-records-guide

Focus Keyphrase: DNS-записи домена

Дополнительные ключевые запросы:

• что такое DNS-записи;
• что такое A запись;
• что такое CNAME;
• что такое MX запись;
• что такое TXT запись;
• что такое TTL DNS;
• как проверить DNS через nslookup;
• как проверить DNS через dig.

Excerpt: Пошагово разбираем DNS-записи домена: куда указывает A, зачем нужен CNAME, как работает MX, где используются TXT, SPF, DKIM и DMARC, что делают NS, SRV, CAA и PTR. Показываем TTL и проверку через nslookup и dig.

Что такое DNS-записи

DNS-записи определяют, куда должен вести домен и какие сервисы с ним связаны. Именно через DNS браузер узнаёт IP-адрес сайта, почтовый сервер определяет, куда доставлять письмо, а сервисы Google, Microsoft, Яндекс и другие могут проверить владение доменом.

Если представить домен как адресную книгу, DNS-записи — это отдельные строки внутри этой книги.

Например:

example.com → 203.0.113.10

может означать, что сайт example.com находится на сервере с IP-адресом 203.0.113.10.

Для этого используется запись типа A.

Но DNS занимается не только сайтами. Разные типы записей отвечают за разные задачи:

Тип	Для чего нужен
A	Связывает имя с IPv4-адресом
AAAA	Связывает имя с IPv6-адресом
CNAME	Создаёт псевдоним другого DNS-имени
MX	Указывает почтовые серверы
TXT	Хранит текстовые данные, проверки и почтовые политики
NS	Указывает авторитетные DNS-серверы зоны
SRV	Описывает сервер и порт конкретной службы
CAA	Ограничивает удостоверяющие центры для выпуска сертификатов
PTR	Выполняет обратное сопоставление IP-адреса с именем
SOA	Содержит служебную информацию DNS-зоны

A и AAAA действительно используются для сопоставления имени с IPv4 и IPv6, а DNS-запись содержит тип, имя, значение и TTL.

Главное правило. Не создавайте DNS-записи «на всякий случай». Перед добавлением записи нужно понимать, какой сервис её требует и какое точное значение дал провайдер.

Где редактируются DNS-записи

Записи изменяются там, где находятся авторитетные DNS-серверы домена.

Это может быть:

• регистратор домена;
• хостинг;
• Cloudflare;
• отдельный DNS-провайдер;
• собственный DNS-сервер.

Не следует автоматически считать, что DNS управляется там же, где куплен домен.

Например, домен мог быть зарегистрирован у одного регистратора, сайт расположен у другого хостера, а DNS-зона обслуживаться Cloudflare.

Как понять, где находится DNS

Посмотрите NS-записи домена:

nslookup -type=NS example.com

или:

dig example.com NS

NS указывают авторитетные DNS-серверы зоны — именно они предоставляют окончательные ответы о DNS-записях домена.

Что означают поля Name, Type, Value и TTL

Интерфейс разных DNS-панелей отличается, но обычно встречаются четыре основных поля.

Type

Тип записи:

A
AAAA
CNAME
MX
TXT
NS
SRV
CAA

Name или Host

Имя, к которому относится запись.

Например:

www

может означать:

www.example.com

Символ:

@

во многих панелях означает корень домена:

example.com

Но обозначения зависят от DNS-провайдера. Некоторые панели требуют полное имя, другие автоматически дописывают домен.

Value, Content или Target

Основное значение записи.

Для A это IP:

203.0.113.10

Для CNAME — другое DNS-имя:

example.com

Для MX — имя почтового сервера:

mail.example.com

TTL

Количество времени, в течение которого DNS-ответ может храниться в кеше.

К TTL мы ещё вернёмся отдельно, потому что именно с ним связано большинство вопросов о том, почему DNS «ещё не обновился».

A-запись — куда направить домен по IPv4

A-запись связывает DNS-имя с IPv4-адресом.

Практический пример

Допустим, вы арендовали VPS и получили IP:

203.0.113.10

Хотите, чтобы при открытии:

example.com

пользователь попадал на этот сервер.

Создаётся:

Type: A
Name: @
Value: 203.0.113.10

Теперь DNS сообщает:

example.com → 203.0.113.10

Для поддомена

Если административная панель находится на:

panel.example.com

и сервер имеет IP:

203.0.113.20

можно создать:

Type: A
Name: panel
Value: 203.0.113.20

Что произойдёт при неправильной A-записи

Если указать неверный IP:

• сайт может перестать открываться;
• откроется чужой или старый сервер;
• HTTPS может показывать ошибку сертификата;
• поддомен перестанет вести на нужный сервис.

AAAA-запись — IPv6

AAAA выполняет ту же задачу, что A, но для IPv6.

Например:

Type: AAAA
Name: @
Value: 2001:db8::10

Если сервер действительно принимает соединения по IPv6, пользователи с IPv6 смогут использовать этот адрес.

Не создавайте AAAA просто потому, что такая запись есть в панели. Если IPv6 на сервере не настроен, часть посетителей может пытаться подключаться по неработающему адресу.

CNAME — псевдоним другого имени

CNAME не указывает непосредственно на IP. Он говорит, что одно имя является псевдонимом другого.

Практический пример для www

Основной сайт:

example.com

Пусть www.example.com должен вести туда же.

Можно создать:

Type: CNAME
Name: www
Value: example.com

Получается:

www.example.com → example.com → 203.0.113.10

Другой пример

Сервис дал адрес:

myproject.hosting-provider.example

и просит подключить:

app.example.com

Тогда запись может выглядеть:

Type: CNAME
Name: app
Value: myproject.hosting-provider.example

A или CNAME?

Если сервис дал IP-адрес, обычно используется A или AAAA.

Если сервис дал доменное имя, часто используется CNAME.

Не подставляйте URL вместо DNS-имени. В CNAME не нужно писать https://example.com/page/. DNS не работает с протоколом HTTPS или путём страницы. Нужен именно hostname.

MX-запись — куда доставлять почту

MX определяет почтовые серверы, принимающие письма для домена.

Практический пример

Адрес:

admin@example.com

должен принимать письма через:

mail.example.com

Тогда может использоваться:

Type: MX
Name: @
Priority: 10
Value: mail.example.com

Что такое Priority

MX обычно имеет приоритет.

Например:

10 mail1.example.com
20 mail2.example.com

Меньшее число означает более высокий приоритет.

Отправляющий почтовый сервер сначала попробует сервер с приоритетом 10, а если тот недоступен — может перейти к следующему.

Важная ошибка

MX указывает на имя почтового сервера, а не на URL:

Правильно:

mail.example.com

Неправильно:

https://mail.example.com

Что сломается при неправильной MX

Ваш сайт может продолжать работать нормально, но входящая почта:

• перестанет приходить;
• начнёт возвращаться отправителям;
• будет доставляться не на тот почтовый сервис.

TXT-запись — текстовые данные и подтверждения

TXT — универсальная текстовая запись.

Её используют многие сервисы.

Подтверждение владения доменом

Например сервис просит добавить:

google-site-verification=abc123...

или другой проверочный токен.

После появления TXT сервис проверяет DNS и убеждается, что пользователь управляет доменом.

SPF

SPF обычно публикуется в TXT и определяет серверы, которым разрешено отправлять почту от имени домена.

Условный пример:

v=spf1 include:_spf.example-mail-provider.com ~all

Не копируйте этот SPF в свой домен. SPF должен быть сформирован именно вашим почтовым провайдером.

DKIM

DKIM позволяет подписывать исходящие письма криптографической подписью.

Публичная часть ключа публикуется в DNS, часто в TXT-записи с именем вида:

selector1._domainkey.example.com

DMARC

DMARC также обычно публикуется TXT-записью:

_dmarc.example.com

Она задаёт правила обработки писем, которые не проходят SPF/DKIM, а также параметры отчётности.

Почтовые TXT-записи нельзя придумывать. Значения SPF, DKIM и DMARC должны соответствовать реальной конфигурации вашей почты.

NS-записи — кто управляет DNS-зоной

NS определяют авторитетные серверы имён для зоны.

Например:

example.com NS ns1.dns-provider.example
example.com NS ns2.dns-provider.example

Когда вы меняете DNS-провайдера, обычно именно эти серверы изменяются у регистратора.

Авторитетный сервер хранит окончательные DNS-записи зоны и отвечает на запросы о них.

Что произойдёт при неправильных NS

Последствия могут быть намного серьёзнее, чем ошибка одной A-записи.

Могут одновременно перестать работать:

• сайт;
• почта;
• поддомены;
• проверки TXT;
• API;
• другие сервисы домена.

Перед сменой NS сначала перенесите всю DNS-зону к новому провайдеру. Только после проверки A, AAAA, MX, TXT, CNAME и остальных записей меняйте nameservers у регистратора.

SRV-запись — адрес и порт сервиса

SRV используется сервисами, которым недостаточно просто знать IP. В записи можно указать сервер, порт, приоритет и вес.

Структура обычно выглядит примерно так:

_service._protocol.example.com

Например сервис может попросить:

_sip._tcp.example.com

и указать:

Priority: 10
Weight: 5
Port: 5060
Target: sip.example.com

SRV широко применяется в корпоративных сервисах, телефонии, мессенджерах, Microsoft-средах и других сетевых приложениях.

Не создавайте SRV вручную по аналогии с чужим доменом — используйте точные значения из документации конкретного сервиса.

CAA — кто может выпускать SSL/TLS-сертификаты

CAA позволяет владельцу домена указать удостоверяющие центры, которым разрешено выдавать сертификаты для этого домена.

Например организация может ограничить выпуск сертификатов выбранным CA.

Эта запись полезна как дополнительный уровень контроля, но требует понимания текущей схемы выпуска и автоматического продления сертификатов.

Осторожно. Ошибочная CAA-запись может привести к тому, что Let's Encrypt или другой CA не сможет продлить сертификат сайта.

PTR — обратный DNS

Обычная A-запись отвечает на вопрос:

Какой IP у mail.example.com?

PTR работает в противоположную сторону:

Какое имя связано с IP 203.0.113.10?

PTR особенно важна для почтовых серверов.

Обычно владелец домена не создаёт PTR в обычной DNS-зоне. Обратную запись настраивает владелец IP-адреса — например VPS-провайдер или дата-центр.

Проверка

nslookup 203.0.113.10

или:

dig -x 203.0.113.10

dig -x предназначен именно для reverse lookup.

SOA — служебная информация DNS-зоны

SOA содержит основные технические параметры зоны.

В записи можно увидеть:

• основной сервер;
• контакт администратора;
• серийный номер зоны;
• таймеры обновления;
• параметры отрицательного кеширования.

Для обычного владельца сайта SOA редко приходится редактировать вручную: DNS-провайдер обычно управляет ей автоматически.

Что такое TTL

TTL (Time To Live) — время, в течение которого DNS-ответ разрешено хранить в кеше.

TTL обычно задаётся в секундах.

Например:

TTL: 300

означает:

300 секунд = 5 минут

А:

TTL: 3600

означает один час.

Чем больше TTL, тем дольше кеширующие DNS-резолверы могут использовать старый ответ до нового запроса к авторитетному серверу. Более короткий TTL ускоряет переход на новое значение, но увеличивает частоту DNS-запросов.

Почему DNS-изменения не появляются одновременно у всех

Вы часто встретите фразу:

DNS распространяется 24–48 часов

Для новичка это удобно, но технически слишком упрощённо.

DNS-запись не разлетается по всем серверам интернета по таймеру. Рекурсивные DNS-серверы кешируют старые ответы и продолжают использовать их до истечения TTL.

Пример

Допустим, текущая A-запись:

example.com → 203.0.113.10
TTL: 3600

В 14:00 DNS-сервер провайдера пользователя получил этот ответ.

В 14:10 вы меняете адрес:

example.com → 203.0.113.20

Но кешированный ответ может оставаться действительным до 15:00.

Поэтому один пользователь уже увидит новый сервер, а другой временно попадёт на старый.

Cloudflare также отмечает, что старая запись может оставаться в кеше до истечения прежнего TTL.

Почему уменьшать TTL нужно заранее

Представим, что завтра в 12:00 вы переносите сайт на новый сервер.

Сейчас TTL равен:

86400

то есть 24 часа.

Если уменьшить TTL непосредственно в момент переезда, часть резолверов уже может хранить старое значение ещё до суток.

Поэтому TTL снижают заранее — до того, как начнётся миграция.

Например:

старый TTL: 86400
временный TTL перед миграцией: 300

После того как старый TTL гарантированно истечёт, выполняется изменение IP.

Когда миграция завершена и всё стабильно, TTL можно снова увеличить.

Ключевой момент. Новый TTL не может заставить исчезнуть запись, которая уже находится в чужом кеше со старым TTL.

Что такое отрицательный DNS-кеш

Кешируются не только найденные записи, но и ответы о том, что имя не существует.

Например вы проверили:

new.example.com

ещё до создания записи.

DNS ответил:

NXDOMAIN

После этого вы создаёте A-запись. Некоторые резолверы всё ещё могут временно помнить старый отрицательный ответ.

Поэтому новая запись иногда не появляется мгновенно даже при маленьком TTL самой новой записи. Отрицательное кеширование связано с параметрами SOA зоны.

Как проверить DNS в Windows через nslookup

nslookup встроен в Windows 10 и Windows 11 и предназначен для диагностики DNS. Он поддерживает запросы разных типов записей через параметр -type.

Проверка A-записи

nslookup example.com

Только A

nslookup -type=A example.com

AAAA

nslookup -type=AAAA example.com

MX

nslookup -type=MX example.com

TXT

nslookup -type=TXT example.com

NS

nslookup -type=NS example.com

CNAME

nslookup -type=CNAME www.example.com

Использование конкретного DNS-сервера

Например запрос через Google Public DNS:

nslookup example.com 8.8.8.8

Или через Cloudflare:

nslookup example.com 1.1.1.1

Если второй сервер не указан, nslookup использует DNS-сервер, настроенный в системе.

Практический пример nslookup

Команда:

nslookup example.com

может вернуть:

Server:  dns.example
Address:  192.0.2.53

Name:    example.com
Address: 203.0.113.10

Server

DNS-сервер, у которого спросили информацию.

Address возле Server

IP этого DNS-сервера.

Name

Имя, которое запрашивалось.

Address в ответе

Полученный IP домена.

Как проверить DNS через dig

dig — удобный инструмент для подробных DNS-запросов. Он широко используется администраторами благодаря подробному и предсказуемому выводу.

В Linux и многих Unix-подобных системах он доступен после установки DNS/BIND utilities. В Windows наличие dig зависит от установленного окружения — штатно Windows ориентирована на nslookup и PowerShell-инструменты.

Проверка A

dig example.com A

AAAA

dig example.com AAAA

MX

dig example.com MX

TXT

dig example.com TXT

NS

dig example.com NS

CAA

dig example.com CAA

Короткий ответ

dig +short example.com

Только полезная часть ответа с TTL

dig +noall +answer example.com

Документация BIND приводит +short для вывода только адреса и +noall +answer для краткого вывода имени, типа, TTL и значения.

Как читать вывод dig

Пример:

example.com.    300    IN    A    203.0.113.10

Значение	Что означает
example.com.	Полное DNS-имя
300	Оставшийся TTL в секундах
IN	DNS-класс Internet
A	Тип записи
203.0.113.10	Значение записи

Как проверить, обновилась ли запись на авторитетном сервере

Это один из самых полезных приёмов при диагностике.

Сначала получите NS домена:

dig example.com NS +short

Допустим, ответ:

ns1.provider.example.
ns2.provider.example.

Теперь спросите авторитетный сервер напрямую:

dig @ns1.provider.example example.com A

Если авторитетный DNS уже возвращает новый IP, значит запись на стороне DNS-провайдера изменена правильно.

Если Google DNS, Cloudflare или DNS вашего провайдера ещё показывают старое значение, причина, скорее всего, в кеше.

Именно прямой запрос к авторитетному серверу рекомендуется как способ отделить ошибку конфигурации от кеширования.

Как сравнить несколько DNS-серверов

Через nslookup:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Через dig:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Если ответы различаются сразу после изменения записи, это часто объясняется тем, что один resolver ещё хранит старое значение.

Как проверить MX

В Windows:

nslookup -type=MX example.com

Через dig:

dig example.com MX +short

Можно увидеть:

10 mail1.example.com.
20 mail2.example.com.

Проверьте не только имена, но и приоритеты.

Как проверить SPF, DKIM и DMARC

SPF

nslookup -type=TXT example.com

или:

dig example.com TXT

DKIM

Нужно знать selector, который выдал почтовый сервис:

dig selector1._domainkey.example.com TXT

DMARC

dig _dmarc.example.com TXT

Если запись не находится, сначала проверьте точное имя, указанное вашим почтовым провайдером.

Как проверить CNAME

nslookup -type=CNAME www.example.com

или:

dig www.example.com CNAME

Обратите внимание: если resolver автоматически следует по цепочке CNAME, обычный запрос A может показывать конечный IP. Поэтому при проверке самого alias лучше явно запрашивать CNAME.

Как проверить NS после переноса DNS

nslookup -type=NS example.com

или:

dig example.com NS

Если вы только что сменили DNS-серверы у регистратора, переход может занимать больше времени, чем изменение обычной A-записи. Делегация также кешируется, и TTL NS может быть достаточно большим.

Почему запись правильная в панели, но сайт не работает

DNS — только первый уровень.

Даже если:

example.com → правильный IP

сайт может не открываться из-за:

• неправильной конфигурации Apache или Nginx;
• закрытого порта 80 или 443;
• ошибки SSL-сертификата;
• неправильного virtual host;
• CDN или reverse proxy;
• ошибок приложения;
• проблем на самом сервере.

DNS отвечает только на вопрос «куда идти». Он не гарантирует, что сервис на этом адресе действительно работает.

Почему сайт работает у меня, но не у другого человека

После DNS-изменений это обычная ситуация.

Причинами могут быть:

• разный DNS-кеш;
• разные рекурсивные резолверы;
• кеш операционной системы;
• кеш роутера;
• старое значение у интернет-провайдера;
• различия IPv4 и IPv6.

Для диагностики сравните ответы:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

и авторитетный DNS.

Нужно ли очищать DNS-кеш Windows

Если вы только что изменили DNS и компьютер продолжает показывать старое значение, можно очистить локальный кеш Windows:

ipconfig /flushdns

Но это очищает кеш только на вашем компьютере.

Если старую запись хранит рекурсивный DNS-сервер провайдера, локальная очистка не заставит его немедленно забыть запись.

На это ограничение также указывает документация Cloudflare при разборе отрицательного кеширования.

Как подготовиться к переносу сайта на другой сервер

Практическая схема:

1. Посмотрите текущий TTL A/AAAA.
2. Заранее уменьшите TTL, например до 300 секунд, если DNS-провайдер это позволяет.
3. Дождитесь истечения старого TTL.
4. Подготовьте новый сервер.
5. Проверьте сайт на новом сервере до переключения.
6. Измените A/AAAA.
7. Проверьте авторитетные NS напрямую.
8. Проверьте несколько публичных резолверов.
9. Не выключайте старый сервер мгновенно.
10. После завершения миграции верните подходящий TTL.

Частые ошибки новичков

Ошибка	Почему это проблема
Указать URL в CNAME или MX	DNS ожидает имя, а не https://...
Создать AAAA без IPv6	Часть клиентов может идти по неработающему IPv6
Удалить MX при переносе сайта	Перестанет работать почта
Перенести только A при смене DNS-провайдера	TXT, MX, CNAME и другие записи могут потеряться
Сменить NS до переноса зоны	Можно одновременно потерять сайт и почту
Уменьшить TTL после изменения IP	Старые ответы уже могут находиться в кеше
Считать 24–48 часов обязательным сроком	Основной фактор — TTL и состояние кешей
Проверять только браузером	Непонятно, проблема в DNS или веб-сервере
Придумывать SPF/DKIM/DMARC	Можно ухудшить доставку почты

Краткая памятка по DNS-записям

Нужно сделать	Обычно используется
Направить домен на IPv4 сервера	A
Направить домен на IPv6	AAAA
Создать alias поддомена	CNAME
Подключить почту	MX + TXT и другие записи провайдера
Подтвердить владение доменом	TXT или CNAME — зависит от сервиса
Настроить SPF	TXT
Настроить DKIM	TXT или CNAME — зависит от почтового сервиса
Настроить DMARC	TXT
Сменить DNS-провайдера	NS
Указать порт сервиса	SRV
Ограничить CA для сертификатов	CAA
Настроить reverse DNS	PTR у владельца IP

FAQ

Сколько обновляются DNS-записи?

Единого фиксированного срока нет. Изменение у авторитетного DNS-провайдера может появиться быстро, но старые ответы могут храниться у рекурсивных DNS-серверов до истечения TTL.

Почему говорят про 24–48 часов?

Это безопасное упрощение для пользователей. На практике время зависит от TTL, кеширования, типа изменения и конкретных DNS-серверов.

Какой TTL поставить?

Универсального значения нет. Для стабильной записи можно использовать более длинный TTL. Перед плановой миграцией его полезно временно снизить заранее.

TTL 300 — это сколько?

300 секунд, то есть 5 минут.

TTL 3600 — это сколько?

3600 секунд, то есть 1 час.

Можно ли поставить TTL 0?

Это зависит от DNS-провайдера и практически не является типичной настройкой для обычного сайта. Используйте значения, которые поддерживает конкретный DNS-сервис.

Что лучше использовать в Windows: dig или nslookup?

Для большинства простых проверок достаточно встроенного nslookup. dig удобнее для глубокой диагностики и просмотра TTL, секций ответа и запросов к конкретным серверам.

Почему nslookup показывает старый IP?

Возможно, DNS-сервер, к которому обращается компьютер, ещё хранит старую запись в кеше.

Как понять, уже ли обновился мой DNS-провайдер?

Запросите запись непосредственно у авторитетного nameserver через dig @server. Если там новое значение, а публичный resolver показывает старое, проблема обычно в кеше.

Нужно ли удалять старый сервер сразу после смены A?

Нет. Лучше некоторое время оставить его доступным, пока кеши с предыдущим IP не истекут.

Почему почта перестала работать после переноса сайта?

Частая причина — были изменены NS, но MX и TXT-записи почты не перенесли в новую DNS-зону.

Можно ли иметь несколько A-записей?

Да, одно имя может иметь несколько A-записей. Но это не является полноценной заменой балансировщику с проверкой доступности серверов: DNS может возвращать несколько адресов, не гарантируя состояние каждого сервера.

Заключение

Для управления обычным сайтом необязательно знать DNS на уровне администратора крупных сетей. Но важно понимать назначение основных записей.

A и AAAA связывают домен с IP-адресами. CNAME создаёт псевдоним другого имени. MX отвечает за получение почты. TXT используется для подтверждений и почтовых политик. NS определяет, какие серверы управляют DNS-зоной. SRV помогает находить сетевые службы, CAA управляет разрешёнными удостоверяющими центрами, а PTR используется для обратного DNS.

Перед изменением записи всегда фиксируйте её старое значение и TTL. При плановом переносе уменьшайте TTL заранее, а после изменения проверяйте не только браузер, но и DNS напрямую.

В Windows для большинства задач достаточно nslookup. Для более подробной диагностики удобно использовать dig, особенно запрос непосредственно к авторитетному DNS-серверу. Такой подход позволяет быстро понять, действительно ли DNS настроен неправильно или вы просто видите старый ответ из кеша.

:::writing{}

Проверил определения типов DNS, поведение TTL и примеры команд по актуальной документации Cloudflare, Microsoft и BIND. В частности, Microsoft подтверждает поддержку запросов A, CNAME, MX, NS, PTR, SOA и TXT через nslookup, а BIND — синтаксис dig, +short, +noall +answer и reverse lookup.

Обсуждение

Комментарии

Только для участников

Обсуждение доступно после входа

Авторизуйтесь через VK ID, чтобы читать комментарии, отвечать, ставить лайки и сохранять статьи.

Войти через VK ID

Автор статьи

Кудашев Дмитрий Витальевич

IT-специалист из Ростова-на-Дону. Делюсь практическим опытом, объясняю технологии понятным языком

Об авторе →