Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it safe to rely on Erlang "internal" DNS code? #53

Open
bortzmeyer opened this issue Aug 17, 2022 · 6 comments
Open

Is it safe to rely on Erlang "internal" DNS code? #53

bortzmeyer opened this issue Aug 17, 2022 · 6 comments

Comments

@bortzmeyer
Copy link

The library uses Erlang/OTP DNS code. I've been told that, if this Erlang code is undocumented, this is because it it no supposed to be used by external programs, but only by Erlang itself, for its internal use. Do you agree? Would it be better to develop specific code to be independent of Erlang?

@tungd
Copy link
Owner

tungd commented Aug 19, 2022

Yes that is the case, and it is mentioned explicitly in the README. However, I'd argue that un-documented and internal-use only is just the way the Erlang team telling us they are not interested to develop it/fixing its issue outside of their scopes.

This library, however, is publicly maintained and bug fix / additional extension will be addressed. It's on me and the contributors to fix bugs and maintain compatibility with :inet_dns. In that sense, at least to me, this library is as safe to use in production as Erlang/OTP itself (I do have production code that use this, but only on a small scale). The bottom line is that if you stick to a combination of versions of the library/Erlang/OTP that works, it won't break your code.

Hope that answers your question/concerns. I'm happy to discussing it further.

@Hermanverschooten
Copy link
Contributor

I just ran into an issue with livebook (livebook-dev/livebook#1976), due to this.

@josevalim
Copy link

In this case, maybe it makes sense to copy inet_dns.erl and inet_dns.hrl, rename the modules, and keep only the bits that make sense? This way there is no chance you can break in future versions, you don't need to install erlang sources, and it gives you more freedom to evolve over time?

@bortzmeyer
Copy link
Author

The elixir-dns library seems unmaintained (see the many open issues, even when this is clearly a bug and has a patch). So, I'm not sure there will be a solution. (Elixir badly needs a properly maintained DNS library.)

@josevalim
Copy link

14 open issues is not that many and the last commit was 1 year ago, so I would say the jury is not out there yet. In any case, Hex.pm does have a mechanism to transfer ownership of maintained packages. So I can see two possible options:

  1. Start a fork where those issues are solved and then reach out to Hex.pm
  2. Use an Erlang DNS library, such as https://github.com/dnsimple/dns_erlang (which is maintained by a DNS provider)

@bortzmeyer
Copy link
Author

dns_erlang is quite difficult to use for a purely Elixir programmer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants