initial version of dnsdig model and input

[aschaber1]

I added a feature for saving DNS Zones. It works, but it's not ready, but I'm looking for feedback.

[codecov-io]

Codecov Report

Merging #1669 into master will increase coverage by 0.69%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1669      +/-   ##
==========================================
+ Coverage   62.62%   63.32%   +0.69%     
==========================================
  Files          30       30              
  Lines        1493     1475      -18     
==========================================
- Hits          935      934       -1     
+ Misses        558      541      -17

Impacted Files	Coverage Δ
lib/oxidized/node.rb	71.12% <0%> (-0.41%)	:arrow_down:
lib/oxidized/jobs.rb	31.25% <0%> (ø)	:arrow_up:
lib/oxidized/nodes.rb	49.51% <0%> (ø)	:arrow_up:
lib/oxidized/string.rb	66.66% <0%> (ø)	:arrow_up:
lib/oxidized/hook.rb	47.61% <0%> (ø)	:arrow_up:
lib/oxidized/input/cli.rb	48.78% <0%> (ø)	:arrow_up:
lib/oxidized/input/ssh.rb	55.78% <0%> (+0.58%)	:arrow_up:
lib/oxidized/output/git.rb	19% <0%> (+0.75%)	:arrow_up:
lib/oxidized/cli.rb	40.29% <0%> (+1.49%)	:arrow_up:
lib/oxidized/model/model.rb	85.85% <0%> (+1.54%)	:arrow_up:
... and 4 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update ff4a6b7...c6670c3. Read the comment docs.

[wk]

Thanks for this! It is a pretty cool and somewhat quirky use case; cool since it's always fun to see a use case that wasn't explicitly foreseen within the scope of the project, and quirky because at least initially, it appears so far out of the intended scope that it isn't immediately obvious how common the use case is, and if it should be accommodated.

A few questions that immediately come to mind:

• Why is dig in this use case preferable to simply storing zone data from the original name server as zone files, a database dump, or otherwise?
• Is there a guarantee that the output of dig in this use case will always return data in the same order, preventing revision churn due to ordering?
• How do we express the dependency on dig, avoid hard-coding the path to the executable, or perhaps use a pure Ruby dns library to accomplish the same result without relying on forking out to the command line? (Alternatively, do we include dnsutil in the installation instructions? In the docker container?)

Could you describe in a few words the environment and use case in which this model is being used?

[aschaber1]

Hello @wk, thanks for your interest.

Q. Why is dig in this use case preferable to simply storing zone data from the original name server as zone files, a database dump, or otherwise? A: We use a Cloud DNS Service, therefore we do not have access to the Zone Files. There is an API we could also use, but I preferred zone transfers, since they would work with any standard DNS Server/Service that supports AXFR.

Q. Is there a guarantee that the output of dig in this use case will always return data in the same order, preventing revision churn due to ordering? A. Unfortunately there is no guarantee, all I can say is, that from what we have seen running it for a few months is that it did not happen to us, but there's no guarantee. AFAIK there's no ordering requirement in zone files and all entries are single lines, therefore we should be able to sort it, to guarantee a specific order. But I have not thought this through.

Q. How do we express the dependency on dig, avoid hard-coding the path to the executable, or perhaps use a pure Ruby dns library to accomplish the same result without relying on forking out to the command line? (Alternatively, do we include dnsutil in the installation instructions? In the docker container?) A. I thought about using some ruby library rather than calling dig, I actually would have preferred to use a lib. But my ruby skills are limited and I did not get any results. So I went ahead and used dig.

Q. Could you describe in a few words the environment and use case in which this model is being used? A. We use a Cloud DNS Service, which provides us with DNS Servers and Zone Management aaS (https://www.internetx.com/en/domains/). I wanted to have way of tracking and reviewing changes. But I assume this might be working/interesting in any Cloud based DNS Service (AWS/Azure/GCP etc.).

I hope I was able to give you a better picture of what I was looking at.

[aschaber1]

@wk, are you interested in this? I'd like to see this merged, but I don't know how to proceed. :)

[davama]

@aschaber1 Would this be of interest to you? https://github.com/ytti/oxidized/pull/1820

We also do a dig axfr output to get the latest zone records and other crazy output

[mortzu]

Please add to documentation and CHANGELOG