zdns
zdns copied to clipboard
Published
20 hours ago •
zmap
zmap
--name-servers option issue
Hello,
When using the --name-servers option, the "--iterative" option does not work.
using option:
root$ echo "google.com" | zdns A --iterative -result-verbosity trace --name-servers=8.8.8.8 | jq
{
"class": "IN",
"data": {
"answers": [
{
"answer": "172.217.12.206",
"class": "IN",
"name": "google.com",
"ttl": 14,
"type": "A"
}
],
"flags": {
"authenticated": false,
"authoritative": false,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": true,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "8.8.8.8:53"
},
"name": "google.com",
"status": "NOERROR",
"timestamp": "2020-06-08T23:58:44Z",
"trace": [
{
"cached": false,
"class": 1,
"depth": 1,
"layer": ".",
"name": "google.com",
"name_server": "8.8.8.8:53",
"results": {
"answers": [
{
"answer": "172.217.12.206",
"class": "IN",
"name": "google.com",
"ttl": 14,
"type": "A"
}
],
"flags": {
"authenticated": false,
"authoritative": false,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": true,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "8.8.8.8:53"
},
"type": 1
}
]
}
unused:
root$ echo "google.com" | zdns A --iterative -result-verbosity trace | jq
{
"class": "IN",
"data": {
"answers": [
{
"answer": "142.250.64.78",
"class": "IN",
"name": "google.com",
"ttl": 300,
"type": "A"
}
],
"flags": {
"authenticated": false,
"authoritative": true,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": false,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "216.239.34.10:53"
},
"name": "google.com",
"status": "NOERROR",
"timestamp": "2020-06-08T23:58:21Z",
"trace": [
{
"cached": false,
"class": 1,
"depth": 1,
"layer": ".",
"name": "google.com",
"name_server": "199.7.83.42:53",
"results": {
"additionals": [
{
"answer": "192.5.6.30",
"class": "IN",
"name": "a.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.33.14.30",
"class": "IN",
"name": "b.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.26.92.30",
"class": "IN",
"name": "c.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.31.80.30",
"class": "IN",
"name": "d.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.12.94.30",
"class": "IN",
"name": "e.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.35.51.30",
"class": "IN",
"name": "f.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.42.93.30",
"class": "IN",
"name": "g.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.54.112.30",
"class": "IN",
"name": "h.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.43.172.30",
"class": "IN",
"name": "i.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.48.79.30",
"class": "IN",
"name": "j.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.52.178.30",
"class": "IN",
"name": "k.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.41.162.30",
"class": "IN",
"name": "l.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "192.55.83.30",
"class": "IN",
"name": "m.gtld-servers.net",
"ttl": 172800,
"type": "A"
},
{
"answer": "2001:503:a83e::2:30",
"class": "IN",
"name": "a.gtld-servers.net",
"ttl": 172800,
"type": "AAAA"
}
],
"authorities": [
{
"answer": "a.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "b.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "c.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "d.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "e.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "f.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "g.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "h.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "i.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "j.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "k.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "l.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "m.gtld-servers.net.",
"class": "IN",
"name": "com",
"ttl": 172800,
"type": "NS"
}
],
"flags": {
"authenticated": false,
"authoritative": false,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": false,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "199.7.83.42:53"
},
"type": 1
},
{
"cached": false,
"class": 1,
"depth": 2,
"layer": "com",
"name": "google.com",
"name_server": "192.5.6.30:53",
"results": {
"additionals": [
{
"answer": "2001:4860:4802:34::a",
"class": "IN",
"name": "ns2.google.com",
"ttl": 172800,
"type": "AAAA"
},
{
"answer": "216.239.34.10",
"class": "IN",
"name": "ns2.google.com",
"ttl": 172800,
"type": "A"
},
{
"answer": "2001:4860:4802:32::a",
"class": "IN",
"name": "ns1.google.com",
"ttl": 172800,
"type": "AAAA"
},
{
"answer": "216.239.32.10",
"class": "IN",
"name": "ns1.google.com",
"ttl": 172800,
"type": "A"
},
{
"answer": "2001:4860:4802:36::a",
"class": "IN",
"name": "ns3.google.com",
"ttl": 172800,
"type": "AAAA"
},
{
"answer": "216.239.36.10",
"class": "IN",
"name": "ns3.google.com",
"ttl": 172800,
"type": "A"
},
{
"answer": "2001:4860:4802:38::a",
"class": "IN",
"name": "ns4.google.com",
"ttl": 172800,
"type": "AAAA"
},
{
"answer": "216.239.38.10",
"class": "IN",
"name": "ns4.google.com",
"ttl": 172800,
"type": "A"
}
],
"authorities": [
{
"answer": "ns2.google.com.",
"class": "IN",
"name": "google.com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "ns1.google.com.",
"class": "IN",
"name": "google.com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "ns3.google.com.",
"class": "IN",
"name": "google.com",
"ttl": 172800,
"type": "NS"
},
{
"answer": "ns4.google.com.",
"class": "IN",
"name": "google.com",
"ttl": 172800,
"type": "NS"
}
],
"flags": {
"authenticated": false,
"authoritative": false,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": false,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "192.5.6.30:53"
},
"type": 1
},
{
"cached": false,
"class": 1,
"depth": 3,
"layer": "google.com",
"name": "google.com",
"name_server": "216.239.34.10:53",
"results": {
"answers": [
{
"answer": "142.250.64.78",
"class": "IN",
"name": "google.com",
"ttl": 300,
"type": "A"
}
],
"flags": {
"authenticated": false,
"authoritative": true,
"checking_disabled": false,
"error_code": 0,
"opcode": 0,
"recursion_available": false,
"recursion_desired": false,
"response": true,
"truncated": false
},
"protocol": "udp",
"resolver": "216.239.34.10:53"
},
"type": 1
}
]
}
Thanks.
What are you expecting to have happen here? It doesn't really make sense to try to do iterative resolution against a recursive resolver.
Thank you for your quick answer. @zakird
Why are the results different?
The latter includes "additionals" results.
I want to get the flow result as below.
If add the "--name-servers" option, it won't show.
root$ dig @8.8.8.8 google.com +trace
; <<>> DiG 9.11.3-1ubuntu1.9-Ubuntu <<>> @8.8.8.8 google.com +trace
; (1 server found)
;; global options: +cmd
. 84082 IN NS j.root-servers.net.
. 84082 IN NS d.root-servers.net.
. 84082 IN NS b.root-servers.net.
. 84082 IN NS h.root-servers.net.
. 84082 IN NS m.root-servers.net.
. 84082 IN NS e.root-servers.net.
. 84082 IN NS a.root-servers.net.
. 84082 IN NS g.root-servers.net.
. 84082 IN NS f.root-servers.net.
. 84082 IN NS l.root-servers.net.
. 84082 IN NS i.root-servers.net.
. 84082 IN NS k.root-servers.net.
. 84082 IN NS c.root-servers.net.
. 84082 IN RRSIG NS 8 0 518400 20200620170000 20200607160000 48903 . KsnmBr0KFKHtwPvKmGZ6v8rMVj8GNySkXIKPApbm/gutCo9FTIthAd/x a3kIxxVr8+3kSuI1Wmk5RFHVxumyUhiPYc1L2rTiG4RhdI9c6ZiXZCjF l9lpnpH7aI/V3u0GZ2rD1zoliY0p0jXDgt4LPIyq/8alCRQqatZn2mx6 +uiaPywpL+/tMdgaLv3r7NQs6xdHXotiD+DexfJlyY85KClEZ+unbSZO Zwak+yMwOl5beN5bkkwhcpmhBo8oG0yOTFr1vg93lN6P9z7O2QHGQsf7 hPn0ugXr1FHAymggBUySrnvz/IHmwVtrJ5L1X3ZK/WWOoYIabMvxxvC0 TKw/8Q==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 1 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20200621210000 20200608200000 48903 . VZO658wERj1B2gBnXnYBi2nSEVRIyJjKYdNvjweWk2bzw+zMvAmhZ1zk KKVlkcr0SPPOCg2cl4VJNqBay9lMHX++JBk7o/jAeft94nt+Bmdtoqbv II0ukgY8FmLsKcGu8kmWmzBj+a/NyWJEEWd17o+AEIOIsxZnOVEkRYZZ ZGlK8ALUf8d9qA7cq11i07egXuUrniqygYK1Q6aLyXrirZ/yMdK862Zm xBO6EHxAxu5xS0jnvbB03r4f5mmhvx56nA1t/cBRwspaJhoPLrmNpJfr NJe4eRPgqykTJ/fGNEY719hfV+wBPoYoKv+YICHqQTIab98yckh+nw+I UIwo3Q==
;; Received 1170 bytes from 199.7.91.13#53(d.root-servers.net) in 8 ms
google.com. 172800 IN NS ns2.google.com.
google.com. 172800 IN NS ns1.google.com.
google.com. 172800 IN NS ns3.google.com.
google.com. 172800 IN NS ns4.google.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20200614044937 20200607033937 39844 com. ed97/V1vPf6edoiwIutzHeBRE9XB6iZroZJoX53+unlq3ZiDt657ltA/ siEBaLJtAJWt8PYkmvnU3eD80V7jr51UokOFiUiF0JhZ8nDu3/Dp+68Z pi//9NEVH3rTXwC3RjL2UNOgeAJQketOMiUu8fgH/rGgw0+QosvooU5W ru5FGhn+32o10SQBvPeg48c+XW4pJfzVVwMPMvaW51BqJg==
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN NSEC3 1 1 0 - S84CDVS9VPREADFD6KK7PDADH0M6IO8H NS DS RRSIG
S84BDVKNH5AGDSI7F5J0O3NPRHU0G7JQ.com. 86400 IN RRSIG NSEC3 8 2 86400 20200615044804 20200608033804 39844 com. h+eCmfzGI7grfqr6AKdsLuE/W20yYdT0g09YPtSqskdwGc6187tJaFbu PzAo+VqWJSCbxhJ7sGvBJQtFDWq2oJRBO8kBVNF+hKQq210sB688rRjy IFv86yusnJinaNe/7qZFshvbYDJmda/m3Mryckow4cSVS+8BVGV6QW1b vQ86tpUYqmnj22YOc70A+edsjiMCE5NpRoGqelEqZ0SFOA==
;; Received 836 bytes from 192.48.79.30#53(j.gtld-servers.net) in 8 ms
google.com. 300 IN A 142.250.64.78
;; Received 55 bytes from 216.239.34.10#53(ns2.google.com) in 14 ms
The behavior shown above is intentional, I’d say.
--iterative Just enables iterative mode. By default this starts from the well-known root servers. If name servers are specified, they are used as starting points. This can be a specific root server, a specific subset of roots or some intermediate like a known TLD root to skip the first hop.
If this starting point is an authoritative server or a recursive resolver by itself, it returns after a single iteration and that’s it. Don’t know if there is any use case for that scenario. But the above outputs do reflect this behavior.
https://github.com/zmap/zdns/blob/6ea6c1388c8495a08aae7e3d6df19f3ba9687d27/zdns/main.go#L135-L140
The parameter description does not state anything about roots being enforced (they aren’t):
Perform own iteration instead of relying on recursive resolver
The result verbosity “trace“ has no impact on the resolver behavior. It just visualizes the steps performed.
dig has different behavior. It ignores the specified name server and always starts from the roots.
From man dig(1)
+[no]trace Toggle tracing of the delegation path from the root name servers for the name being looked up. Tracing is disabled by default. When tracing is enabled, dig makes iterative queries to resolve the name being looked up. It will follow referrals from the root servers, showing the answer from each server that was used to resolve the lookup.
I wouldn’t want the current behavior to change, because it allows slightly more flexibility.
Taking a second look at this, I agree. The behavior that ZDNS currently employs looks to be correct.