Giter Site home page Giter Site logo

coredns / coredns Goto Github PK

View Code? Open in Web Editor NEW
11.8K 239.0 2.0K 98.4 MB

CoreDNS is a DNS server that chains plugins

Home Page: https://coredns.io

License: Apache License 2.0

Go 99.86% Makefile 0.10% Dockerfile 0.04%
dns-server go cncf coredns plugin service-discovery

coredns's Introduction

CoreDNS

Documentation CodeQL Go Tests CircleCI Code Coverage Docker Pulls Go Report Card CII Best Practices

CoreDNS is a DNS server/forwarder, written in Go, that chains plugins. Each plugin performs a (DNS) function.

CoreDNS is a Cloud Native Computing Foundation graduated project.

CoreDNS is a fast and flexible DNS server. The key word here is flexible: with CoreDNS you are able to do what you want with your DNS data by utilizing plugins. If some functionality is not provided out of the box you can add it by writing a plugin.

CoreDNS can listen for DNS requests coming in over:

Currently CoreDNS is able to:

  • Serve zone data from a file; both DNSSEC (NSEC only) and DNS are supported (file and auto).
  • 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 + transfer).
  • Automatically load zone files from disk (auto).
  • Caching of DNS responses (cache).
  • Use etcd as a backend (replacing SkyDNS) (etcd).
  • Use k8s (kubernetes) as a backend (kubernetes).
  • Serve as a proxy to forward queries to some other (recursive) nameserver (forward).
  • Provide metrics (by using Prometheus) (prometheus).
  • Provide query (log) and error (errors) logging.
  • Integrate with cloud providers (route53).
  • Support the CH class: version.bind and friends (chaos).
  • Support the RFC 5001 DNS name server identifier (NSID) option (nsid).
  • Profiling support (pprof).
  • Rewrite queries (qtype, qclass and qname) (rewrite and template).
  • Block ANY queries (any).
  • Provide DNS64 IPv6 Translation (dns64).

And more. Each of the plugins is documented. See coredns.io/plugins for all in-tree plugins, and coredns.io/explugins for all out-of-tree plugins.

Compilation from Source

To compile CoreDNS, we assume you have a working Go setup. See various tutorials if you don’t have that already configured.

First, make sure your golang version is 1.21 or higher as go mod support and other api is needed. See here for go mod details. Then, check out the project and run make to compile the binary:

$ git clone https://github.com/coredns/coredns
$ cd coredns
$ make

This should yield a coredns binary.

Compilation with Docker

CoreDNS requires Go to compile. However, if you already have docker installed and prefer not to setup a Go environment, you could build CoreDNS easily:

docker run --rm -i -t \
    -v $PWD:/go/src/github.com/coredns/coredns -w /go/src/github.com/coredns/coredns \
        golang:1.21 sh -c 'GOFLAGS="-buildvcs=false" make gen && GOFLAGS="-buildvcs=false" make'

The above command alone will have coredns binary generated.

Examples

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

.:53
CoreDNS-1.6.6
linux/amd64, go1.16.10, aa8c32

The following could be used to query the CoreDNS server that is running now:

dig @127.0.0.1 -p 53 www.example.com

Any query sent to port 53 should return some information; your sending address, port and protocol used. The query should also be logged to standard output.

The configuration of CoreDNS is done through a file named Corefile. When CoreDNS starts, it will look for the Corefile from the current working directory. A Corefile for CoreDNS server that listens on port 53 and enables whoami plugin is:

.:53 {
    whoami
}

Sometimes port number 53 is occupied by system processes. In that case you can start the CoreDNS server while modifying the Corefile as given below so that the CoreDNS server starts on port 1053.

.:1053 {
    whoami
}

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.

You may import other text files into the Corefile using the import directive. You can use globs to match multiple files with a single import directive.

.:53 {
    import example1.txt
}
import example2.txt

You can use environment variables in the Corefile with {$VARIABLE}. Note that each environment variable is inserted into the Corefile as a single token. For example, an environment variable with a space in it will be treated as a single token, not as two separate tokens.

.:53 {
    {$ENV_VAR}
}

A Corefile for a CoreDNS server that forward any queries to an upstream DNS (e.g., 8.8.8.8) is as follows:

.:53 {
    forward . 8.8.8.8:53
    log
}

Start CoreDNS and then 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 which is printed on standard output.

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

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

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.

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

. {
    any
    forward . 8.8.8.8:53
    errors
    log
}

IP addresses are also allowed. They are automatically converted to reverse zones:

10.0.0.0/24 {
    whoami
}

Means you are authoritative for 0.0.10.in-addr.arpa..

This also works for IPv6 addresses. If for some reason you want to serve a zone named 10.0.0.0/24 add the closing dot: 10.0.0.0/24. as this also stops the conversion.

This even works for CIDR (See RFC 1518 and 1519) addressing, i.e. 10.0.0.0/25, CoreDNS will then check if the in-addr request falls in the correct range.

Listening on TLS (DoT) and for gRPC? Use:

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

Similarly, for QUIC (DoQ):

quic://example.org {
    whoami
    tls mycert mykey
}

And for DNS over HTTP/2 (DoH) use:

https://example.org {
    whoami
    tls mycert mykey
}

in this setup, the CoreDNS will be responsible for TLS termination

you can also start DNS server serving DoH without TLS termination (plain HTTP), but beware that in such scenario there has to be some kind of TLS termination proxy before CoreDNS instance, which forwards DNS requests otherwise clients will not be able to communicate via DoH with the server

https://example.org {
    whoami
}

Specifying ports works in the same way:

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

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

Community

We're most active on Github (and Slack):

More resources can be found:

Contribution guidelines

If you want to contribute to CoreDNS, be sure to review the contribution guidelines.

Deployment

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

Deprecation Policy

When there is a backwards incompatible change in CoreDNS the following process is followed:

  • Release x.y.z: Announce that in the next release we will make backward incompatible changes.
  • Release x.y+1.0: Increase the minor version and set the patch version to 0. Make the changes, but allow the old configuration to be parsed. I.e. CoreDNS will start from an unchanged Corefile.
  • Release x.y+1.1: Increase the patch version to 1. Remove the lenient parsing, so CoreDNS will not start if those features are still used.

E.g. 1.3.1 announce a change. 1.4.0 a new release with the change but backward compatible config. And finally 1.4.1 that removes the config workarounds.

Security

Security Audits

Third party security audits have been performed by:

Reporting security vulnerabilities

If you find a security vulnerability or any security related issues, please DO NOT file a public issue, instead send your report privately to [email protected]. Security reports are greatly appreciated and we will publicly thank you for it.

Please consult security vulnerability disclosures and security fix and release process document

coredns's People

Contributors

aledbf avatar ameshkov avatar bradbeam avatar caniszczyk avatar chrisohaver avatar cricketliu avatar dependabot-preview[bot] avatar dependabot[bot] avatar dilyevsky avatar ekleiner avatar greenpau avatar grobie avatar ihac avatar jiachengxu avatar joewrightss avatar johnbelamaric avatar mariuskimmina avatar miekg avatar mrichmon avatar pmoroney avatar rajansandeep avatar rdrozhdzh avatar stp-ip avatar superq avatar tantalor93 avatar truongnh1992 avatar varyoo avatar victory460 avatar ykhr53 avatar yongtang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

coredns's Issues

middleware: file: uses RR for lookups

For looksups in the tree we use a dns.RR, but we only use the name and type wasting the rest of the header. We should just use qname and qtype for all lookups

Dedup and round_robin middleware

In SkyDNS I have to dedup message and correct the order, i.e. CNAMEs before A records and other fluff. This can of course be also handled as a middleware.

See #9 for etcd implementation.

middleware: file: deleting from the tree is wonky

Deleting stuff works, but you have to be careful when something is an empty non terminal, because then the node must be kept. Think the right check will soon be in place but I don't fully trust it yet. Needs more tests as well

xfr logs different size

When doing an xfr it logs:

127.0.0.1 - [28/Mar/2016:16:03:02 +0100] "AXFR miek.nl. tcp" NOERROR 821
127.0.0.1 - [28/Mar/2016:16:03:03 +0100] "AXFR miek.nl. tcp" NOERROR 917

Dig says 917 is the correct number of octets, there is no difference in the dig out. No clue....

Make it possible to run CoreDNS as my dns server

Dogfood time! I want to run CoreDNS as my DNS server. For this it needs to be able:

  • Server DNS requests from db files (#5)
  • Do DNSSEC query resolution
  • Be able to slave zones (#8)
  • Listen and send notifies, prolly related to (#8)

http.FileSystem

http.FileSystem is half used, half not used. It's a nice abstraction for finding (zone) files, maybe we should just use it.

middleware: fix rewrite complex rules

Right now only simple rules are implemented in middleware/rewrite/*, look at complex rules and what they can add.
SimpleRules at the moment only rewrite qtypes.

coreDNS's middleware is diff. than caddy

The middleware in caddy sets the return code to something else than 0 and then the error handler takes over.

With DNS this is more tricky because some responses require state (NXDOMAIN) and cannot be handled by a generic error handler.

Need to clarify when, and when not the middleware has written to the client and how errors middleware can help here.

use context.Context in the middleware

Add an extra parameters: ctx which will be a context.Context{} for communicating between middleware, i.e. a caching middleware reports a cache miss and the prometheus middleware can then report it by examining what's in the context.

Means remaining the current context.go Context to something else.

middleware/file: abstract backend away

Basically do the same thing as in SkyDNS and abstract away the access to the datasource. This will probably mean renaming the file to ... data? or something.

It would be something like this:

type Backend interface {
    Insert(rr dns.RR)
    Delete(rr dns.RR)
    Get(rr dns.RR) *Elem
    Len() int
    Next(rr dns.RR) *Elem // for nsec
    Prev(rr dns.RR) *Elem
// nsec3 foo as well? Or just give up on that?
}

And Elem is defined as:

type Elem struct {
    m map[uint16][]dns.RR
}

And also has some methods on it.

https

There is a https/acme let's encrypt implementation in the code, the only use would prolly be DNS over TLS; this needs to happen (i.e. implemented)

middleware comms via context.Context

With the added param of context.Context in the middleware we can communicate between them. The first use-case for this would be: monitoring.

I.e. middleware proxy sets some vars in the context and the prometheus middleware picks this up from the context and sets the vars. This way we can get middleware monitoring without meddling with prometheus outside of the prometheus middleware.

This needs a key naming policy, i.e. middleware/proxy/counter-name

middleware: slaving zones

Figure out how to implement and use a slave zone middleware that retrieves zones over AXFR, IXFR or rsync?

middleware: proxy

Fix proxy to work with all the features.

I'll probable leave adding EDNS0 "headers" out of the picture.

malformed msg and wrong class

% dig @x64.atoom.net -p 1053 miek.nl A CH                                                                                            ~
;; Warning: Message parser reports malformed message packet.

; <<>> DiG 9.8.3-P1 <<>> @x64.atoom.net -p 1053 miek.nl A CH
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34243
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;miek.nl.           CH  A

;; AUTHORITY SECTION:
miek.nl.        1800    IN  SOA linode.atoom.net. miek.miek.nl. 1459743181 14400 3600 604800 14400

;; Query time: 34 msec
;; SERVER: 2a01:7e00::f03c:91ff:fef1:6735#1053(2a01:7e00::f03c:91ff:fef1:6735)
;; WHEN: Mon Apr  4 11:32:50 2016
;; MSG SIZE  rcvd: 82

Should not answer in the IN class, and dig should not complain about the message...

graceful restart broke

Haven't tested it, but I am pretty sure graceful restart does work anymore. We need
a) tests if this is the case
b) fix it

add common testing package

add testing subdir in middleware and factor out some common test infrastructure, newA and friends, and checking for the returned sections.

middleware: dnssec

So, a signing middleware could be implemented. Question becomes what about the keys...
Should the middleware also intercept queries for DNSKEY/RRSIG and friends? Proobaaablly 'yes', but I am not sure at this point if that will work.

Filed bug to put ideas in.

middleware: resolver

Diff. than a proxy. A middleware to implements a full recursive (dnssec) resolver.

standard compliant errors on EDNS0

Support NSID (middleware thingy?)

And correctly return an EDNS0 error when we don't understand the OPT RR. Google for some ravings of marka on this subject.

IsDomainName

There are few checks (right now) if a name that is used is a proper domain name, i.e. names like
.miek.nl when used in the config will be deemed OK.

Needs fixing.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.