Home | History | Annotate | Download | only in doc
      1 # gRPC Name Resolution
      2 
      3 ## Overview
      4 
      5 gRPC supports DNS as the default name-system. A number of alternative
      6 name-systems are used in various deployments. We support an API that is
      7 general enough to support a range of name-systems and the corresponding
      8 syntax for names. The gRPC client library in various languages will
      9 provide a plugin mechanism so resolvers for different name-systems can
     10 be plugged in.
     11 
     12 ## Detailed Design
     13 
     14 ### Name Syntax
     15 
     16 A fully qualified, self contained name used for gRPC channel construction
     17 uses URI syntax as defined in [RFC 3986](https://tools.ietf.org/html/rfc3986).
     18 
     19 The URI scheme indicates what resolver plugin to use.  If no scheme
     20 prefix is specified or the scheme is unknown, the `dns` scheme is used
     21 by default.
     22 
     23 The URI path indicates the name to be resolved.
     24 
     25 Most gRPC implementations support the following URI schemes:
     26 
     27 - `dns:[//authority/]host[:port]` -- DNS (default)
     28   - `host` is the host to resolve via DNS.
     29   - `port` is the port to return for each address.  If not specified,
     30     443 is used (but some implementations default to 80 for insecure
     31     channels).
     32   - `authority` indicates the DNS server to use, although this is only
     33     supported by some implementations.  (In C-core, the default DNS
     34     resolver does not support this, but the c-ares based resolver
     35     supports specifying this in the form "IP:port".)
     36 
     37 - `unix:path` or `unix://absolute_path` -- Unix domain sockets (Unix systems only)
     38   - `path` indicates the location of the desired socket.
     39   - In the first form, the path may be relative or absolute; in the
     40     second form, the path must be absolute (i.e., there will actually be
     41     three slashes, two prior to the path and another to begin the
     42     absolute path).
     43 
     44 The following schemes are supported by the gRPC C-core implementation,
     45 but may not be supported in other languages:
     46 
     47 - `ipv4:address[:port][,address[:port],...]` -- IPv4 addresses
     48   - Can specify multiple comma-delimited addresses of the form `address[:port]`:
     49     - `address` is the IPv4 address to use.
     50     - `port` is the port to use.  If not specified, 443 is used.
     51 
     52 - `ipv6:address[:port][,address[:port],...]` -- IPv6 addresses
     53   - Can specify multiple comma-delimited addresses of the form `address[:port]`:
     54     - `address` is the IPv6 address to use.
     55     - `port` is the port to use.  If not specified, 443 is used.
     56 
     57 In the future, additional schemes such as `etcd` could be added.
     58 
     59 ### Resolver Plugins
     60 
     61 The gRPC client library will use the specified scheme to pick the right
     62 resolver plugin and pass it the fully qualified name string.
     63 
     64 Resolvers should be able to contact the authority and get a resolution
     65 that they return back to the gRPC client library. The returned contents
     66 include:
     67 
     68 - A list of resolved addresses, each of which has three attributes:
     69   - The address itself, including both IP address and port.
     70   - A boolean indicating whether the address is a backend address (i.e.,
     71     the address to use to contact the server directly) or a balancer
     72     address (for cases where [external load balancing](load-balancing.md)
     73     is in use).
     74   - The name of the balancer, if the address is a balancer address.
     75     This will be used to perform peer authorization.
     76 - A [service config](service_config.md).
     77 
     78 The plugin API allows the resolvers to continuously watch an endpoint
     79 and return updated resolutions as needed.
     80