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

ar-dns integration #47

Open
mcdermj opened this Issue May 31, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@mcdermj
Owner

mcdermj commented May 31, 2017

The first stages of ar-dns.net integration are committed in f428fbb and 986199a. This is just a basic downloading of the preprocessed files that @johnhays provides. There are a few things to note about the entire system.

  1. Buster's typedown functionality needs to have a complete list of at least reflector names so that it will work correctly. This can't really happen via DNS without AXFRs, which would be a pain to implement compared to the relatively painless implementation currently.

  2. We may want to refresh those destination addresses periodically so that we get new information. I'm not exactly sure how to make this happen.

I have thoughts about using the plist files just to seed the dropdown lists, and then not updating them at runtime. Note with the current implementation, the new data is not saved to the disk. I think this is the right thing to do. Buster is inherently an Internet program, and I'm not going to pander to the edge cases where someone wants to use their ThumbDV non-Internet connected.

We could just refresh the information at some X time period and re-import the plist file. This would be relatively easy to do with GCD and the various timers available. We already do that with the various keepalives in the system, this wouldn't be that hard either. That being said, I think the right thing to do would be to do the DNS lookup for the address at link time not at startup time. When we get a link request, we know that the user intends to use the link, therefore refreshing the information is probably important. If the repeater or reflector has changed addresses since launch time, we should at least try to reflect that.

Moving forward, I'd really like to encode more information in ar-dns.net about things. Right now, I only really get name to DNS mappings and some crude idea of what protocols are supported. What I'd kinda like is to use SRV and TXT records to convey some more data. Maybe something like:

_dextra._udp.kf7ldg.ar-dns.net 86400 IN SRV 10 10 30001 kf7ldg.ar-dns.net.
_dplus._udp.kf7ldg.ar-dns.net  86400 IN SRV 10 10 20001 kf7ldg.ar-dns.net.
kf7ldg.ar-dns.net              86400 IN TXT "v=dstar1 proto_order=dplus,dextra,dcs"

Anyhow, these are ideas and I'd love to hear from @johnhays especially on what he things, but input might also be useful from @richark and @DonaldHays as well.

@mcdermj mcdermj added the enhancement label May 31, 2017

@mcdermj mcdermj self-assigned this May 31, 2017

@johnhays

This comment has been minimized.

Collaborator

johnhays commented Jun 14, 2018

Anna - I am more than happy to support srv and txt records on ar-dns.net, but would need support from the reflector/gateway operators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment