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

    Так что это за «грозная» точка на конце доменного имени? — возник у некоторых вопрос, после недавнего поста.
    Кто не знает и хочет узнать — добро пожаловать под хабракат — смахнём пыль с 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

    Вот тут, видимо, точка и потерялась…
    Метки:
    Поделиться публикацией
    Комментарии 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.

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