Server types other than HTTP

If I do implement a different server type, it would be merely for a proof of concept or example, or a very bare-bones implementation for others to build on. HTTP and Caddy core keep me busy enough. :wink: I do strongly encourage anyone interested to write other server types for Caddy.

One user of CoreDNS and Caddy @Jared_Folkins in fact) just told me this week that he loves the consistency in configuring a DNS server and an HTTP server; and looks forward to other server types benefitting from that workflow and automatic, managed TLS.

The Caddy website will be updated in the future to reflect these new capabilities!

1 Like


Go continues to eat the stack I’m involved with. I have about 15 virtual servers for this one project with Caddy, Coredns, and Boltdb being a big part of that.

Thanks to @matt, @miekg, @abiosoft, and everyone else involved. I very much appreciate the effort and spirit Caddy (& Coredns) are built with.

Take care,


Thanks! :slight_smile:

@matt I think the current interface makes sense (enough). The MakeServers() and Context looks sane. I just need to port stuff over. Looks like I can drop a gazillion things - which is always good.

One thing I missed was some kind of logging frameworks that works within Caddy. The log.Printf("WARN") stuff lacks features (like ratelimiting 'n stuff).

1 Like

Awesome, yeah, you should be able to lose all the stuff that Caddy’s internals take care of.

Well if there are any that replace the standard logger (I’ve heard of some), you can use those. Or you can specify your own for DNS stuff specifically, but the rest of Caddy will still use the standard logger.

Oh, and @miekg, should I make that UDPListener interface a real thing in the caddy package so that other UDP servers can use it? (Is it helpful to you at all?)

I think that would help, yes. I’m still not sure I will then do a type assertion and use the UDP functions (prolly) or use the fake Accept().

Maybe leave it for as-is for now. I haven’t been able to make any progress.

The UDPListener won’t work… This is only one of the available packet implementations. Take a look at the net package. It still has Listen and ListenPacket which uses net.PacketConn. This would lead to a werid split where the TCP servers can use a versatile net.Listener and the UDP server are limited to a *UDPConn.

Ah, dang. Would a similar wrapper type work for net.PacketConn instead of for a net.UDPConn? (In other words, we just switch the wrapper type to be for PacketConn.)

But PacketConn is an interface… how do you wrap that?

I’m leaning towards ServePacket and ListenPacket to be added as well to the interface. I can prolly glue stuff back together in ServerNew or MakeServers.

Oops, forgot about that when I wrote my reply! Hmm. :thinking:

Okay, I’m open to exploring this. Let me know what you come up with!

Hey @miekg, just wanted to check up and see if there was anything else that needed to change to make the DNS plugin work before I release 0.9. :slight_smile: I know you’re busy but I just thought I’d check in anyway, since there were still one or two unanswered questions. (I haven’t had a chance to look into PacketConn.)

Busy and travelling, lost week Boston, now in Zurich. Haven’t touched the code once :frowning:
If you are delaying 0.9 because of me, don’t (but do make clear this plugin stuff might change).

1 Like

Sounds good. Good luck with your travels!

I’m showing off CoreDNS tomorrow at a conference as part of my talk. Thanks for working on it!

Ah wow. Coo!

OK. update: this new repo contains the current work. I needed to start afresh - doing this as a branch in coredns meant I needed to port too many things at once - hence a new start.

This has one middleware: reflect, that will be hardcoded as there is no config parsing. The lists the next steps. The first ones for me will be: get a binary that calls my new code, make the server start up and listen to TCP, get a reply from the reflect middleware.
Only then I can check the whole UDP vs TCP story.

1 Like
% ./coredns -type=dns
2016/07/14 13:46:29 listen tcp bind: cannot assign requested address

Runs :slight_smile:
Do I need to build my own binary still? Or just use caddy?
Also not sure (yet) where that IP comes from…

% ./coredns -plugins
Server types:

Caddyfile loaders:

Other plugins:

Also works.
But I can’t seem to start the thing.

Yay! That’s great news @miekg, glad to hear it. :slight_smile:

Just use Caddy! No need for your own main; you can nuke your whole coredns folder I think. All you have to do is import your caddydns package from run.go:

import (
    // ...

    // this imports the DNS server type and default plugins/directives
    _ ""

Then run Caddy:

$ caddy -type=dns

Where the Caddyfile in that directory is for CoreDNS.

As for the IP address that it’s binding to, it probably comes from this line here.

Ah thanks! More code to delete.

Yes, found my IP address. I’m also fixing 1 other bug after that my reflect middleware should do something.

1 Like
checking for
checking for
middleware/reflect: called!

And I see an answer. So whoop whoop. Working :slight_smile:

No let’s delete that coredns directory…

Update: also works :slight_smile:
Calling caddy directly now. As expected UDP does not work. Now I can finally make some head way there.

1 Like