Server types other than HTTP

Plugins
21

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
22

Hi,

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,
Jared

2 Likes
23

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
24

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.

25

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?)

26

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.

27

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.

28

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.)

29

But PacketConn is an interfaceā€¦ how do you wrap that?

30

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.

31

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!

32

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.)

33

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
34

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!

35

Ah wow. Coo!

36

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.

1 Like
37 
% ./coredns -type=dns
MakeServers()
NewServer
2016/07/14 13:46:29 listen tcp 139.162.196.78:2053: 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:
  dns

Caddyfile loaders:
  short
  flag
  default

Other plugins:
  dns.reflect

Also works.
But I canā€™t seem to start the thing.

38

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
    _ "github.com/miekg/caddy-coredns/caddydns"
)

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.

39

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
40 
ServeDNS()
checking for who.miek.nl.
checking for miek.nl.
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