Separate result between nameserver

[azzamsa]

I have a python script called digs that do multiple dig on specified nameservers.

Today I am trying dog, and I love its ability to accept multiple nameservers.

~
❯ dog example.com MX -n 1.1.1.1 -n 8.8.8.8
MX example.com.  23h57m48s   0 ""
MX example.com. 1d0h00m00s   0 ""

However I can't point which is wich. What if dog have a separator between them if we supply multiple nameservers ?

~
❯ dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -n x.x.x.x
[1.1.1.1]
MX example.com.  23h57m48s   0 ""
[8.8.8.8]
MX example.com. 1d0h00m00s   0 ""
[x.x.x.x]
MX example.com. 1d0h00m00s   0 ""

---

My current workaround is to use JSON output and filter the result:

dog on  master is 📦 v0.1.0 via 🦀 v1.48.0
❯ cargo r --  example.com MX -n 1.1.1.1 -n 8.8.8.8 -J |  jq .responses[0].answers[0]
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -J`
{
  "class": "IN",
  "exchange": "",
  "name": "example.com.",
  "preference": 0,
  "ttl": 86126,
  "type": "MX"
}

dog on  master is 📦 v0.1.0 via 🦀 v1.48.0
❯ cargo r --  example.com MX -n 1.1.1.1 -n 8.8.8.8 -J |  jq .responses[1].answers[0]
    Finished dev [unoptimized + debuginfo] target(s) in 0.03s
     Running `target/debug/dog example.com MX -n 1.1.1.1 -n 8.8.8.8 -J`
{
  "class": "IN",
  "exchange": "",
  "name": "example.com.",
  "preference": 0,
  "ttl": 86252,
  "type": "MX"
}

[nbkowalewski]

How about just adding the query and the server targeted into the reply structure, similar like other folks do?
and a brief/verbosity flag that allow to steer how much detail the user sees?

For debug you then could offer ever tiny little detail in the protocol stack section, including the protocol specific versions, packet/message size, headers, encryption algorithms, key length, session setup/expiry timestamps, etc.

{ 
"timestamp-log": "1606293878",
"timestamp-start": "1606293876.894513",
"timestamp-end": "1606293877.297837",
"protocol-stack": {
         "network": "ip",
         "address-family": "6",
         "transport": "tcp";
         "security": "ssl",
         "application": "http";
    },
"query": {
         "destination-address": "2001:db8:1000:1",
         "source-address-and-port": "2001:db8:1#443",
         "destination-address-and-port": "2001:db8:1000:1#443",
         "name": "example.com",
         "query-class": "IN",
         "query-type": "SOA",
         "query-id": "4711",
         "flags": ["RD", "EDNS", "AD"],
         "response-flags": ["RA", "RD"],
         "request-size": "52",
         "response-size": "96",
         "result-code": "noerror",
    "answer": [["example.com","3600","SOA","IN","ns.icann.org noc.dns.icann.org 2020111709 7200 3600 1209600 3600"]],
    "edns": {
        "payload-size": "512",
        "version": "0",
        "rcode": "0",
        "flags": "0x0000"
    },
"client": "dog",
"client-version": "1.0.0.0",
"node-id": some-host-id-or-uuid"
}

Proabably it would be a good if as many packages in the DNS toolchain could align on a more strictly typed and value
range constrained standard nomenclature and strucuture for DNS things than utilized in the past.

While the IANA DNS parameters registry is machine readable, but more than one of the parameter tables is obviously not very uniformly defined

• https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

There is promising work under way to represent the IANA dns-parameters registry in a more modern model based on YANG.
Some IETF drafts backed by authors from several of the leading FOSS DNS server and toolchain projects have surfaced in the surrounding of IETF Working Group DNSOP

• https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-02
• https://tools.ietf.org/html/draft-toorop-dnsop-dns-zone-provisioning-yang-01

It may also be useful to reuse other YANG defind models, for example for IP addressing, see

• https://tools.ietf.org/html/rfc8344

[azzamsa]

I decided to build my own: digs