I'm writing a simple golang application that needs to do some decoding of some DNS packets. I noticed that in the net library, there appears to be the perfect implementation in the form of net/dnsmsg.go which contains the right structs, pack / unpack functions etc.
However, the type is marked private (lower case dnsMsg). So it appears that I have no way of using this from within my app.
I'm quite new to golang, so don't know if my only option would be to reimplement net/dnsmsg.go myself, or if there's a better way around this.
My problem was solved by using a third party dns library, specifically miekg/dns (https://github.com/miekg/dns).
Another option would be to use Google's gopacket package which provides packets decoding for Go. In particular, the layers sub-package provides logic for decoding protocol packets, among which what is necessary to decode DNS packets.
Related
I've been working with a golang application lately that does network i/o using a bunch of protocols- HTTP (TCP), DNS and WHOIS (UDP) as well as a few others. Some make use of third-party APIs
The application is open-source so I would like to make changes allowing me to specify the network interface for the sockets to bind to, allowing me to use different interfaces depending on a runtime flag. The only way around this without writing code would be to modify the system-wide routing table each time I want to utilize a different interface, which isn't a very appealing solution
Before I go an modify every instance where a Dialer is used (or try to create a wrapper that they can all use) is there a golang feature that would allow setting the interface globally once, so that the various Dialer invocations would "Just Work"- and adhere to the interface I specified?
I did some searching and have only found ways to do this when each Dialer is created (using DialerContext.LocalAddr) but given I'm really a C programmer and not a golang programmer, I realize I may be totally missing a golang idiom for doing something like this
I currently have a primitive RPC setup relying on JSON transferred over secured sockets, but I would like to switch to gRPC. Unfortunately I also need access to AF_UNIX on windows (Which Microsoft recently started supporting, but gRPC has not implemented).
Since I have an existing working connection (managed with a different library), my preference would be to just use that in conjunction with GRPC to send/receive commands in place of my JSON parsing, but I am struggling to identify the best way to do that.
I have seen Plugging custom transport into gRPC but this question differs in the following ways (As well as my hope for a more recent answer)
I am wanting to avoid making changes to the core of gRPC. I'd prefer to extend it if possible from within my library, but the answer here implies adding a new transport to gRPC.If I did need to do this at the transport level, is there a mechanism to register it with gRPC after the core has been built?
I am unsure if I need to define this as a full custom transport, since I do already have an existing connection established and ready. I have seen some things that imply I could simply extend Channel, but I might be wrong.
I need to be able to support Windows, or at least modern versions of it (Which means that the from_fd options gRPC provides are not available since they are currently only implemented for POSIX)
Has anyone solved similar problems with gRPC?
I may have figured out my own answer. I seem to have been overly focused on gRPC, when the service definition component of Protobuf is not dependent on that.
How can i write my own RPC Implementation for Protocol Buffers utilizing ZeroMQ is very similar to my use case, with https://developers.google.com/protocol-buffers/docs/proto#services seeming to resolve my issue (And this also explains why I seem to have been mixing up the different kinds of "Channels" involved
I welcome any improvements/suggestions, and hope that maybe this can be found in future searches by people that had the same confusion.
I searched on the internet but couldn't find anything useful. First, I was thinking to use Protocol Buffers but it doesn't provide built in feature to track multiple messages (where one message finish and second starts) or message self delimiting, but I read about this feature in Thrift white paper and it seems good to me. Now I am thinking to use Thrift instead of Protocol Buffers.
I am working on custom protocol for that I don't require RPC, could someone suggest if I can use Thrift without RPC (as its in the Protocol Buffers, one simply use the streams function) and some starting point as thrift documentation is a bit cumbersome.
Thanks!
Yes, It is possible. A similar answer is given Here. Apache thrift can be used without RPC you can simply use transport and protocol layers related libraries as they are defined in the documentation.
Apache Thrift is indeed a RPC- and serialization framework. The serialization part is used as part of the RPC mechanism, but can be used standalone. For the various languages there are samples and/or supporting helper classes available. If this is not the case for your particular language, the necessary code pretty much boils down to this (pseudo code):
var data = InitializeMyDataStructure(...);
var trans = new TStreamTransport(...);
var prot = new TJSONProtocol(trans);
data.write(prot);
Both transport(s) and protocol are pluggable, so instead JSON and a stream you are free to use your own protocol, and (for example) a file transport. Or whatever else combination makes sense for your use case and is supported for your target language.
as thrift documentation is a bit cumbersome.
You are free to ask any question, be it here or in the mailing list. Furthermore, we have a nice tutorial and the Test server/client pairs are also good examples for typical use cases.
At my company, we've standardized on using Protocol Buffers over a message bus as a way to allow services to communicate.
This is fine, however I'm running into a problem in trying to figure out how to structure common definition files that I'd like to share amongst different teams. Is there a commonly accepted way to make collections of protocol buffer definitions available across teams?
Also, is it just a fact of life that all import headers have to refer to the directory in which the protocol buffer compiler executes? Frankly this seems a little silly since the protocol buffers allow for namespace definitions. Or is this just an artifact of the Java centric origins of Protocol Buffers?
I can only answer part of the question:
Also, is it just a fact of life that all import headers have to refer to the directory in which the protocol buffer compiler executes?
you can use --proto_path= option to specify where *.proto's exist + all the imbedded proto's
I want to create a test DNS server in ruby, but could not find anything suitable. I found pnet-dns(http://rubyforge.org/projects/pnet-dns/). This project is incomplete and buggy. Is there any alternative?
A language-agnostic alternative is to use PowerDNS pipe backend. Because it communicates with a name server across a simple pipe, it can be written in any language, including Ruby. (The simple example in the documentation uses Perl but it should be easy to translate.)
RubyDNS is what you're looking for.
Checkout an another approach of DNS server in ruby using celluloid: https://github.com/celluloid/celluloid-dns
The original celluloid-dns is horribly incomplete (v0.0.1). Recently, RubyDNS is being copied into celluloid-dns (I'm doing this as we speak). RubyDNS will be modified to work with the updated celluloid-dns since all core functions will be moved from RubyDNS to celluloid-dns.
If you want something that works right now, use RubyDNS. However, in the future, if you just want the low level APIs, use celluloid-dns.
Have you looked at Dnsruby?
It aims to be fully RFC compliant, although it focuses primarily on the client side. It is, however, possible to write your own server - use Dnsruby::Message#decode to decode incoming packets, and a zone of RRSets holding your test records. You can then encode your packets to send back to the client.