geoip

Description

The geoip plugin add geo location data associated with the client IP, it allows you to configure a geoIP2 maxmind database to add the geo location data associated with the IP address.

The data is added leveraging the metadata plugin, values can then be retrieved using it as well, for example:

import (
    "strconv"
    "github.com/coredns/coredns/plugin/metadata"
)
// ...
if getLongitude := metadata.ValueFunc(ctx, "geoip/longitude"); getLongitude != nil {
    if longitude, err := strconv.ParseFloat(getLongitude(), 64); err == nil {
        // Do something useful with longitude.
    }
} else {
    // The metadata label geoip/longitude for some reason, was not set.
}
// ...

Databases

The supported databases use city schema such as City and Enterprise. Other databases types with different schemas are not supported yet.

You can download a free and public City database.

Syntax

geoip [DBFILE]

or

geoip [DBFILE] {
    [edns-subnet]
}

• DBFILE the mmdb database file path. We recommend updating your mmdb database periodically for more accurate results.

• edns-subnet: Optional. Use EDNS0 subnet (if present) for Geo IP instead of the source IP of the DNS request. This helps identifying the closest source IP address through intermediary DNS resolvers, and it also makes GeoIP testing easy: dig +subnet=1.2.3.4 @dns-server.example.com www.geo-aware.com.

  NOTE: due to security reasons, recursive DNS resolvers may mask a few bits off of the clients' IP address, which can cause inaccuracies in GeoIP resolution.

  There is no defined mask size in the standards, but there are examples: RFC 7871’s example conceals the last 72 bits of an IPv6 source address, and NS1 Help Center mentions that ECS-enabled DNS resolvers send only the first three octets (eg. /24) of the source IPv4 address.

Examples

The following configuration configures the City database, and looks up geolocation based on EDNS0 subnet if present.

. {
    geoip /opt/geoip2/db/GeoLite2-City.mmdb {
      edns-subnet
    }
    metadata # Note that metadata plugin must be enabled as well.
}

The view plugin can use geoip metadata as selection criteria to provide GSLB functionality. In this example, clients from the city “Exampleshire” will receive answers for example.com from the zone defined in example.com.exampleshire-db. All other clients will receive answers from the zone defined in example.com.db. Note that the order of the two example.com server blocks below is important; the default viewless server block must be last.

example.com {
    view exampleshire {
      expr metadata('geoip/city/name') == 'Exampleshire'
    }
    geoip /opt/geoip2/db/GeoLite2-City.mmdb
    metadata
    file example.com.exampleshire-db
}

example.com {
    file example.com.db
}

Metadata Labels

A limited set of fields will be exported as labels, all values are stored using strings regardless of their underlying value type, and therefore you may have to convert it back to its original type, note that numeric values are always represented in base 10.

Continent Codes