Кількість дозволених субдоменів у домені та електронній пошті


23

Скільки субдоменів у вашому домені може бути? І маючи на увазі, я маю на увазі рівні субдоменів.

Наприклад, у вас є домен example.com, я знаю, що його можна мати test.example.com, але скільки рівнів ви можете мати? Як test2.test.example.comі test3.test2.test.example.comт.д.

По-друге, мені було цікаво 2 речі про адреси електронної пошти. Перш за все, наскільки поширеним є використання субдоменів в електронній адресі (якщо це навіть можливо)? Я ніколи не бачив чогось, як test@test.example.comбути чесним, тому я не зовсім впевнений. І якщо це можливо, скільки рівнів (як і вище) ви можете мати?

І останнє, чи можуть вищезазначені питання залежати від реєстратора домену чи поштового сервера тощо? І від чого це могло залежати?


2
Це дуже часто в таких країнах, як Австралія та Великобританія, які мають .com.auі .co.ukмають три рівні імені хоста в електронних адресах.
Нахт - Відновлення Моніки

2
@Nacht: Дійсно, це може дуже легко навести вас на щось на кшталтsmith@foonly.maths.ox.ac.uk
Нейт Елдредж

Так, я про це забув. Як я міг забути. Я бачу, .comі .nlнадто багато я забув про інші розширення, такі як com.auі .co.ukт. Д.
Джошуа Бейкер

4
Для запису я використовував адресу електронної пошти @cgg.ms.mff.cuni.cz. Ієрархії глибоких доменів досить поширені в наукових колах.
Відновіть Моніку

@Angew О, ну, я ніколи не бачив чогось подібного, тому не знав, що це можливо.
Джошуа Баккер

Відповіді:


33

Немає прямих обмежень щодо кількості рівнів, тобто точок, які можна мати в імені хоста. Однак ім'я хоста, сумісне з RFC1034, може бути довжиною лише 255 байт, залишаючи 253 байти для повноцінного доменного імені FQDN в DNS. У деяких системах і TLS / SSL обмеження FQDN до 64 байт, а FQDN в електронних листах не повинно перевищувати (*) 245 або 221 байт, залежно від максимальної довжини імені користувача (8 або 32).

Оскільки TLD зазвичай .містить щонайменше 2 символи і кожна частина імені хоста повинна бути щонайменше одним символом, простір, залишений для додаткових крапок, тобто теоретично максимальних рівнів буде:

  • (253-3) / 2 = 125 рівнів після TLD для теоретично найдовшого (не настільки корисного) імені хоста
  • (221-3) / 2 = 109 рівнів після TLD, якщо ви хочете використовувати його для електронної пошти
  • (63-3) / 2 = 30 рівнів після TLD, якщо ви хочете використовувати SSL / TLS.

І так, user@subdomainof.subdomain.example.comу правильному форматі електронної адреси.


(*) Спеціальне обмеження на довжину адреси електронної пошти є результатом RFC 2821 4.5.3.1 та 4.1.2:

4.5.3.1 Size limits and minimums

   path
      The maximum total length of a reverse-path or forward-path is 256
      characters (including the punctuation and element separators).


4.1.2 Command Argument Syntax

      Path = "<" [ A-d-l ":" ] Mailbox ">"

Оскільки прямий шлях повинен містити кутові дужки, для адреси електронної пошти залишається лише 254 символи. Потім username@частина 8 (+1) або 32 (+1) повинна бути виключена, щоб отримати максимальну довжину FQDN.


2
RFC 1034 - це місце, де верхня межа як загальної довжини доменного імені (включаючи всі частини субдомену) 255 октетів походить від, так і максимальної довжини 63 октетів для імені хоста / піддомену. Більш довгі доменні імена повинні (а не повинні) підтримуватися також на RFC 1123, але AFAIK такі не реально помічені в дикій природі.
HBruijn

1
необхідне цитування: загальне обмеження довжини адреси електронної пошти.
Альнітак

Довжина не так важлива. Я знаю, що з кількома субдоменами довжина автоматично збільшується; єдине, що для мене важливо, - це кількість субдоменів, які ви можете мати, оскільки вони все одно не будуть надзвичайно довгими. Крім того, 30 рівнів - це не те, що я б навіть робив. Навіть 10. Можливо, лише 3/4 макс. Але це також було велике цікавість у мене (зауважте: я не знаю сервера та домена).
Джошуа Баккер

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