Atn/ips implementation guidance development dns support

Дата канвертавання22.04.2016
Памер11.13 Kb.

ACP WG I/17 - WP/07

Agenda Item 8



DNS Support

(Presented by Secretariat)


This Information Paper presents an alternate set of views on how Directory Service should be supported by the ATN/IPS. .
It is based on the views of Terry L. Davis of MicroSystems Automation Group acting as an advisor to the FAA. .


    1. At WG-I/10 Japan proposed a scheme for the support of Domain Name Servers (DNS). This was rejected on the basis that ICAO could not operate DNSs. At WG-I/11 an alternate approach to support this capability without the need for actual DNSs (or Root Servers) was proposed.

    2. Since then an additional call for DNS support has been made to the Secretary. The rationale for this has been captured in this IP for consideration by ACP WG-I/17. Should the use of actual DNSs be rejected, Japan has requested that a definition for DNS functionality be included in Doc 9896.


    1. As mentioned the use of DNSs was rejected as ICAO would not have the capability to operate these. It was however agreed that the use of DNSs proves benefits. In order to make this possible the following options for DNS operation have been proposed.

    1. A few options that ICAO should consider in the DNS area could include:

      1. An aviation-only root name server operation does not mean that ICAO has to operate it. The Internet Corporation for Assigned Names and Numbers (ICANN), which governs the Internet, does not run root servers itself. Its Internet Assigned Numbers Authority (IANA) serves as a top level regulator and registrar for domain names, addresses, and the global root server infrastructure.

      2. ICAO should consider an “aviation only” root name server infrastructure. An aviation-only root name operation does not mean that ICAO has to operate it. ICANN, which governs the Internet, does not run root servers itself. It serves as a top level registrar for domain names and the global root server infrastructure. ICAO could assume a similar role for itself.

      3. ICAO could register its own “top level domain” name with ICANN. (i.e. “.IATN” -- International ATN) or if it chooses to run a “private aviation Internet” it could potentially set all its own domain names.

      4. An aviation DNS root server can be run completely separate for the global DNS root infrastructure with neither interfering with the other if properly designed. This separate infrastructure would also minimize the ability of the general Internet population to communicate with aircraft or ANSP infrastructure.

      5. ICAO could adopt that model and assign "air navigation service providers" (ANSP) responsibility to run the aviation root servers. In essence, ICAO would operate this model just as it does the current OSI ATN aircraft addressing. Its role would be setting top-level policies, top and second level DNS names, and the addressing policy and allocation.

      6. ICAO could then assign the ANSP responsibility for their "flag carrier" aircraft naming and addressing and national ground infrastructure under an ICAO defined aircraft naming and addressing policy to ensure global aircraft interoperability.


    1. The meeting is invited to:

                1. Consider the information presented in this paper and decide on this issue.

                2. If the decision to not use DNSs remains, then include a definition for DNS capability in Doc 9896.

База данных защищена авторским правом © 2016
звярнуцца да адміністрацыі

    Галоўная старонка