GDNSD Public Testing

The authoritative DNS servers for these domains are usually running the very latest development release of gdnsd, and serve as the author's primary public testbed during development cycles.

For cut and paste convenience, the nameserver/webserver IPs:

ns1 (aka dallas)

```
69.164.198.85
```
```
2600:3c00::f03c:91ff:fe96:6a4f
```

ns2 (aka newark)

```
69.164.220.36
```
```
2600:3c03::f03c:91ff:fe96:1282
```

These domains are also testing gdnsd's IPv6 DNS support as well, thanks to linode.com's Native IPv6 support. All hosts and services here are v6-enabled, and gdnsd is serving proper IPv6 data over IPv6 itself (including reverse DNS for some ipv6.he.net tunnels I use at home). These domains also both have proper IPv6 glue at the GTLD servers upstream.

Within the test domains standard hostnames like "www" exist, as well as a wildcard "*.wild" which contains a few different RRs, for you to use for testing.

Direct access to the server instances' internal stats (normally, you probably wouldn't expose these in production) can be found here:

gdnsd-plugin-geoip testing

gdnsd-plugin-geoip is now being tested here as well, using the publicly available GeoLiteCityv6 database from Maxmind, and fully supporting optimized edns-client-subnet queries.

The hostname "www" uses it for dynamic address resolution. Assuming no current outages at either site, client addresses in North and South America, Oceania, Antarctica, and a few major countries along the East and SouthEast edges of Asia should receive the "dallas" addresses noted above, and clients in Europe, Africa and the rest of Asia should receive the "newark" addresses.

The hostname "search" is also set up to test dynamic CNAME resolution. The split is as above, but with the "dallas" group of locations resolving to "www.google.com", and the "newark" group of locations resolving to "www.yahoo.com".

For reference, this is the plugin config used for the geoip plugin:

geoip => {
  maps => { my_map => {
    geoip_db => /usr/local/var/gdnsd/GeoLiteCityv6.dat,
    datacenters => [ DAL, EWR ],
    map => {
      EU => [ EWR, DAL ]
      AF => [ EWR, DAL ]
      AS => {
        default => [ EWR, DAL ],
        SG => [ DAL, EWR ],
        JP => [ DAL, EWR ],
        KR => [ DAL, EWR ],
        PH => [ DAL, EWR ],
        TW => [ DAL, EWR ],
        HK => [ DAL, EWR ],
      }
    }
  }}
  resources => {
    asdf => {
      map => my_map,
      dcmap => {
        DAL => {
          addrs_v4 => 69.164.198.85
          addrs_v6 => 2600:3c00::f03c:91ff:fe96:6a4f
        },
        EWR => {
          addrs_v4 => 69.164.220.36
          addrs_v6 => 2600:3c03::f03c:91ff:fe96:1282
        },
      }
    }
    cnsearch => {
      map => my_map,
      dcmap => {
        DAL => www.google.com.
        EWR => www.yahoo.com.
      }
    }
  }
}

And these are the relevant RRs in the zonefiles that use the named resources above:

www      600 DYNA geoip!asdf
search   600 DYNC geoip!cnsearch

There's not much else to see here via HTTP, but feel free to explore the domain via DNS and test for interop (or other) bugs. Please direct any feedback to the gdnsd Google Group, the Issue Tracker @ Github, and/or my personal email.