Eric Yan d2268d3030 middleware/file: add DNAME support (#651)
* Test DNAME handling

If the DNAME itself matches the QTYPE, and the owner name matches QNAME,
the relevant DNAME RR should be included in the answer section.

Other parts of RFC 6672 are not implemented yet and hence left untested.

* Implement the DNAME substitution

As specified in RFC 6672, a DNAME substitution is performed by replacing
the suffix labels of the name being sought matching the owner name of
the DNAME resource record with the string of labels in the RDATA field.
The matching labels end with the root label in all cases. Only whole
labels are replaced.

* Handle DNAME redirection

A CNAME RR is created on-the-fly for the DNAME redirection. Be aware
that we do not have all the edge cases covered yet.

* Test DNAME owner name matching the QNAME

A DNAME RR redirects DNS names subordinate to its owner name; the owner
name of a DNAME is NOT redirected itself.

* Ignore names next to and below a DNAME record

According to RFC 6672, resource records MUST NOT exist at any subdomain
of the owner of a DNAME RR. When loading a zone, those names below the
DNAME RR will be quietly ignored.

* Streamline DNAME processing

Instead of checking DNAMEs during lookup, we use a preloaded list of
DNAME RRs to streamline the process without any runtime performance
penalty:

 * When loading the zone, keep a record of any DNAME RRs.
 * If there aren't any DNAMEs in the zone, just do the lookup as usual.
 * Only when the zone has one or more DNAME records, we look for the
   matching DNAME and ignore confronting subdomain(s) in the process.

* Make it easier to trace back through test errors

* Make DNAME handling part of lookup routine

DNAME processing is invoked only if the zone has at least one DNAME RR.

* Put DNAME resolution inside the searching of a hit

We can drop some of the other ideas; we don't need to track if we
have DNAMEs in the zone it just follows naturally from the current
lookup code.

See also: #664
2017-05-26 10:37:06 +01:00
2017-05-25 20:08:34 +01:00
2017-03-13 20:24:37 +00:00
2017-04-28 09:14:54 -07:00
2017-03-19 09:12:18 +00:00
2017-02-22 07:25:58 +00:00
2016-04-13 20:14:13 +01:00
2017-04-28 09:14:10 -07:00
2017-04-28 09:14:10 -07:00
2017-05-23 14:43:58 -04:00
2017-05-25 07:28:12 +01:00
2017-05-08 15:31:26 +01:00

CoreDNS

Documentation Build Status Code Coverage Go Report Card FOSSA Status

CoreDNS is a DNS server that started as a fork of Caddy. It has the same model: it chains middleware. In fact it's so similar that CoreDNS is now a server type plugin for Caddy.

CoreDNS is also a Cloud Native Computing Foundation inception level project.

CoreDNS is the successor to SkyDNS. SkyDNS is a thin layer that exposes services in etcd in the DNS. CoreDNS builds on this idea and is a generic DNS server that can talk to multiple backends (etcd, kubernetes, etc.).

CoreDNS aims to be a fast and flexible DNS server. The keyword here is flexible: with CoreDNS you are able to do what you want with your DNS data. And if not: write some middleware!

CoreDNS can listen for DNS request coming in over UDP/TCP (go'old DNS), TLS (RFC 7858) and gRPC (not a standard).

Currently CoreDNS is able to:

  • Serve zone data from a file; both DNSSEC (NSEC only) and DNS are supported (file).
  • Retrieve zone data from primaries, i.e., act as a secondary server (AXFR only) (secondary).
  • Sign zone data on-the-fly (dnssec).
  • Load balancing of responses (loadbalance).
  • Allow for zone transfers, i.e., act as a primary server (file).
  • Automatically load zone files from disk (auto).
  • Caching (cache).
  • Health checking endpoint (health).
  • Use etcd as a backend, i.e., a 101.5% replacement for SkyDNS (etcd).
  • Use k8s (kubernetes) as a backend (kubernetes).
  • Serve as a proxy to forward queries to some other (recursive) nameserver (proxy).
  • Provide metrics (by using Prometheus) (metrics).
  • Provide query (log) and error (error) logging.
  • Support the CH class: version.bind and friends (chaos).
  • Profiling support (pprof).
  • Rewrite queries (qtype, qclass and qname) (rewrite).
  • Echo back the IP address, transport and port number used (whoami).

Each of the middlewares has a README.md of its own.

Status

CoreDNS can be used as an authoritative nameserver for your domains, and should be stable enough to provide you with good DNS(SEC) service.

There are still a few known issues, and work is ongoing on making things fast and to reduce the memory usage.

All in all, CoreDNS should be able to provide you with enough functionality to replace parts of BIND 9, Knot, NSD or PowerDNS and SkyDNS. Most documentation is in the source and some blog articles can be found here. If you do want to use CoreDNS in production, please let us know and how we can help.

https://caddyserver.com/ is also full of examples on how to structure a Corefile (renamed from Caddyfile when forked).

Compilation

CoreDNS (as a servertype plugin for Caddy) has a dependency on Caddy, but this is not different than any other Go dependency. If you have the source of CoreDNS, get all dependencies:

go get ./...

And then go build as you would normally do:

go build

This should yield a coredns binary.

Examples

When starting CoreDNS without any configuration, it loads the whoami middleware and starts listening on port 53 (override with -dns.port), it should show the following:

.:53
2016/09/18 09:20:50 [INFO] CoreDNS-001
CoreDNS-001

Any query send to port 53 should return some information; your sending address, port and protocol used.

If you have a Corefile without a port number specified it will, by default, use port 53, but you can override the port with the -dns.port flag:

./coredns -dns.port 1053, runs the server on port 1053.

Start a simple proxy, you'll need to be root to start listening on port 53.

Corefile contains:

.:53 {
    proxy . 8.8.8.8:53
    log stdout
}

Just start CoreDNS: ./coredns. And then just query on that port (53). The query should be forwarded to 8.8.8.8 and the response will be returned. Each query should also show up in the log.

Serve the (NSEC) DNSSEC-signed example.org on port 1053, with errors and logging sent to stdout. Allow zone transfers to everybody, but specically mention 1 IP address so that CoreDNS can send notifies to it.

example.org:1053 {
    file /var/lib/coredns/example.org.signed {
        transfer to *
        transfer to 2001:500:8f::53
    }
    errors stdout
    log stdout
}

Serve example.org on port 1053, but forward everything that does not match example.org to a recursive nameserver and rewrite ANY queries to HINFO.

.:1053 {
    rewrite ANY HINFO
    proxy . 8.8.8.8:53

    file /var/lib/coredns/example.org.signed example.org {
        transfer to *
        transfer to 2001:500:8f::53
    }
    errors stdout
    log stdout
}

Zone Specification

The following Corefile fragment is legal, but does not explicitly define a zone to listen on:

{
   # ...
}

This defaults to .:53 (or whatever -dns.port is).

The next one only defines a port:

:123 {
    # ...
}

This defaults to the root zone ., but can't be overruled with the -dns.port flag.

Just specifying a zone, default to listening on port 53 (can still be overridden with -dns.port):

example.org {
    # ...
}

Listening on TLS and for gRPC? Use:

tls://example.org grpc://example.org {
    # ...
}

Specifying ports works in the same way:

grpc://example.org:1443 {
    # ...
}

When no transport protocol is specified the default dns:// is assumed.

Community

Deployment

Examples for deployment via systemd and other use cases can be found in the deployment repository.

Description
CoreDNS is a DNS server that chains plugins
Readme Apache-2.0 152 MiB
Languages
Go 99.9%