Пользователь
0,0
рейтинг
17 марта 2013 в 00:07

Администрирование → Так что это за «грозная» точка на конце доменного имени?

Так что это за «грозная» точка на конце доменного имени? — возник у некоторых вопрос, после недавнего поста.
Кто не знает и хочет узнать — добро пожаловать под хабракат — смахнём пыль с RFC четвертьвековой давности и проведём маленькое собственное расследование.


На самом деле с этой точкой всё просто.
Согласно RFC 1034 (см. $3.1 стр.7)
 ...Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot.  We use this property to distinguish between:

   - a character string which represents a complete domain name
     (often called "absolute").  For example, "poneria.ISI.EDU."

   - a character string that represents the starting labels of a
     domain name which is incomplete, and should be completed by
     local software using knowledge of the local domain (often
     called "relative").  For example, "poneria" used in the
     ISI.EDU domain.</blockquote>


То есть точка в конце доменного имени указывает, что это полное доменное имя (FQDN). Если точки нет — значит имя относительное. Кому приходилось конфигурировать DNS сервера — видел эту точку в файлах зон.

Так почему же в адресных строках браузеров мы всюду наблюдаем доменные имена без точки на конце?
Формат Uniform Resource Locators (URL) документирован в 1994г. в RFC 1738 (см. $3.1 стр.5 )
 
host
        The fully qualified domain name of a network host, or its IP
        address as a set of four decimal digit groups separated by
        ".". Fully qualified domain names take the form as described
        in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
        [5]: a sequence of domain labels separated by ".", each domain
        label starting and ending with an alphanumerical character and
        possibly also containing "-" characters. The rightmost domain
        label will never start with a digit, though, which
        syntactically distinguishes all domain names from the IP
        addresses.


То есть host — всегда либо FQDN либо ip — другого стандарт не предусматривает.

Как видите тут идёт ссылка на секцию 3.5 RFC 1034, но в секции 3.5 описывается предпочтительный синтаксис DNS имён
RFC 1034 3.5 Preferred name syntax
3.5. Preferred name syntax

The DNS specifications attempt to be as general as possible in the rules
for constructing domain names.  The idea is that the name of any
existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.

For example, when naming a mail domain, the user should satisfy both the
rules of this memo and those in RFC-822.  When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.

The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case.  That is, two names with
the same spelling but different case are to be treated as if identical.

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

For example, the following strings identify hosts in the Internet:

A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA


и нет ни строчки про финальную точку в fqdn

Вот тут, видимо, точка и потерялась…
@Slipeer
карма
27,2
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (25)

  • +1
    Моё мнение — это серьёзный баг в браузерах, которые должны были бы воспринимать эти две формы одинаково.
    • +5
      Думаю дело не только в браузерах.
      Как минимум тут причастны ещё и web-сервера в плане интерпретации параметра host из URL.
      Если стандартом предусмотрено, что в URL либо FQDN либо IP, значит
      "http://example.com/"
      должно быть равно для всех (стандарт ведь один для всех)
      "http://example.com./"
      Потому, что обе эти записи указывают на полное доменное имя домена example.com.
      Впринципе на данную тему можно очень долго спорить, но главный итог этой статьи: мы имеем недостаточно формализованные стандарты, что влечёт за собой некоторые последствия.
      Причём последствия не такие уж «страшные» для администратора, который о них знает и учитывает их при необходимости.

  • +13
    Если браузеры будут воспринимать эти адреса как идентичные — возникнут проблемы с интранетом: «server.» (с точкой) — это домен верхнего уровня. А «server» (без точки) — это относительный адрес (например в рабочей группе, домене), тут будет учитываться днс суффикс.
    • +7
      Некоторые браузеры (не будем показывать пальцами) уже объявили имена типа «server» запросами к Гуглу, а не доменами. Писать нужно как «server/»…
      • 0
        Что не мешает написать «server./»
      • +6
        Это раньше адресная строка была простой адресной строкой (а браузер не обнаружив указания протокола тупо дописывал http://), теперь она подросла и поумнела:
        «server» — это поисковый запрос,
        «http :// server» — это локальный сервак, а
        «http :// server.» — домен верхнего уровня
        • +11
          В Google Chrome домен tomsk.ru, несмотря на то, что это нормальный портал, воспринимается как поисковый запрос, а потом предлагает перейти на сайт. Вот сейчас проверил и перешел на сайт, но раньше много раз было так, как я описал.
          • +2
            Это восхитительно.
          • +3
            Проверил тоже — перешло в поиск
          • +3
            проверочный URL для ленивых хабраюзеров
            tomsk.ru
          • +1
            Тоже перешло в поиск. А почему Томск.ру то? Избранный?
            • 0
              Не знаю почему именно tomsk.ru, но на этом домене очень много поддоменов, типа site.tomsk.ru, и с некоторых пор они даже платные. Может это как-то влияет?
    • –2
      Не возникнут. DNS же.
  • +1
    Попробовал открыть ./ — почему-то открывается сайт фонда wikimedia.
    • +1
      В каком браузере, если не секрет? У меня этот эфект в Crome/Iceweasel/Konqueror не повторился…
      • 0
        Очень странно, вчера было именно так, а сейчас совсем иначе.
      • 0
        Хром свежий.
    • +1
      В Firefox открылся file:///
    • +3
      А в Опере можно открыть /.
    • +3
      в опере "/." открывает slashdot :)
  • +1
    Кстати, редирект с SSL так просто не подсунешь, т.к. браузер сначала выдаст сообщение об ошибке, а потом уже предложит совершить редирект.
    • 0
      Если собрались заморачиваться с SSL придётся добавить FQDN с точкой в Subject Alternate Name — иначе клиент не будет принимать сертификата при обращении к серверу по FQDN с точкой через HTTPS.
      • 0
        В том и проблема, что сертификат уже стоит, а перевыпустить не дают.

        И кроме того, разве его пропустят (с subjaltname)? Я просто не знаю, не пытался еще.
        • 0
          И кроме того, разве его пропустят (с subjaltname)? Я просто не знаю, не пытался еще.


          Ну это зависит от центра сертификации. Если CA свой, то можно и заморочиться, только вот ИМХО нет смысла. Как часто на Ваши сервера приходят по FQDN с точкой в URL? Всем не угодишь.

          Другое дело — если использование в URL FQDN открывает уязвимость, которую может эксплуатировать злоумышленник — это проблема и её надо решать.
          • 0
            Проблем с безопасностью нет (у нас).
            Просто единственное рабочее решение из предыдущего топика (редирект) — не сработает на 99% сайтов с https.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.