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. 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!
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.
@matt I think the current interface makes sense (enough). The
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).
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
Maybe leave it for as-is for now. I haven’t been able to make any progress.
UDPListener won’t work… This is only one of the available packet implementations. Take a look at the net package. It still has
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
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.)
PacketConn is an interface… how do you wrap that?
I’m leaning towards
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.
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. 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
If you are delaying 0.9 because of me, don’t (but do make clear this plugin stuff might change).
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!
OK. update: this new repo https://github.com/miekg/caddy-coredns 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 README.md 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.
% ./coredns -type=dns
2016/07/14 13:46:29 listen tcp 22.214.171.124:2053: bind: cannot assign requested address
Do I need to build my own binary still? Or just use caddy?
Also not sure (yet) where that IP comes from…
% ./coredns -plugins
But I can’t seem to start the thing.
Yay! That’s great news @miekg, glad to hear it.
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
// 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.
checking for who.miek.nl.
checking for miek.nl.
And I see an answer. So whoop whoop. Working
No let’s delete that coredns directory…
Update: also works
caddy directly now. As expected UDP does not work. Now I can finally make some head way there.