dnsviz-grok(1)

πŸ“¦
version 0.11.1 Β· 3 versions
, in debian trixie, epel 9, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu resolute, ubuntu stonking

πŸ’– dnsviz-grok β€” the group chat edition πŸ’–

okay bestie, listen up: this is the manual page for dnsviz-grok(1), part of the General Commands Manual lineup, and honestly? it's giving diagnostic queen. it reads the receipts from your DNS probes and tells you if your DNS deployment is slaying or flopping. let's get into it πŸ’…


✨ NAME ✨

dnsviz-grok β€” assess diagnostic DNS queries 🩺


πŸŽ€ SYNOPSIS πŸŽ€

dnsviz grok [ options ] [ domain_name... ]

πŸ¦‹ DESCRIPTION πŸ¦‹

so the whole vibe here is: you already ran some diagnostic DNS queries (like, say, with dnsviz-probe(1)), and now you want the tea. dnsviz grok takes those results and assesses the health of the DNS deployments for one or more domain names you point it at. 🫢 the processed results get serialized into JSON so other programs can do programmatic diagnostics or fire off alerts. it's giving automation main character energy.

where does the diagnostic query input come from? either a file you name with -r, or standard input. that's it, those are the options. 🌸

now, which domain names get processed? three ways, bestie:

  • pass them as command-line arguments,
  • drop them in a file and use the -f option,
  • or just imply them from the diagnostic query input.

that last one is the preferred methodology (and the simplest, no cap), and it's super useful β€” except when your input contains diagnostic queries for multiple domain names and you only want to process a subset of them. then you gotta be explicit. πŸ™ˆ

the rules, spelled out:

  • if -f is not used and no domain names are on the command line, the names to process are extracted from the diagnostic query input.
  • if -f is used, then you may not specify names on the command line. periodt.

the domain names you pass in are fully-qualified domain names, like example.com, www.example.com, _443._tcp.example.com, 1.2.0.192.in-addr.arpa, or 8.b.d.0.1.0.0.2.ip6.arpa. and because it's implied that they're fully qualified, you do not need a trailing dot. iconic, honestly. ⭐


πŸ‘‘ OPTIONS πŸ‘‘

  • -f, --names-file filename β€” read names from a file instead of from the command line. one name per line, bestie. πŸ’œ and heads up: if you use this option, you may not specify names on the command line. pick a lane.
  • -r, --input-file filename β€” read the diagnostic query input from the specified file instead of from standard input. πŸ“
  • -t, --trusted-keys-file filename β€” use trusted keys from this file when processing diagnostic queries. this overrides the default behavior of using the installed keys for the root zone. πŸ”₯ the format of this file is master zone file format, and it should contain DNSKEY records that correspond to one or more trusted keys for one or more DNS zones. this option may be used multiple times on the command line. go off.
  • -a, --algorithms alg[,alg...] β€” support only the DNSSEC algorithms specified. if you use this option, any algorithms not specified will appear as "unsupported." the status of any RRSIG records corresponding to unsupported algorithms will be unknown. additionally, when a zone has only DS records with unsupported algorithms, the zone is treated as "insecure", assuming the DS records are properly authenticated. 🧚
  • -d, --digest-algorithms digest_alg[,digest_alg...] β€” support only the DNSSEC digest algorithms specified. if you use this option, any digest algorithms not specified will appear as "unsupported." the status of any DS records corresponding to unsupported digest algorithms will be unknown. additionally, when a zone has only DS records with unsupported digest algorithms, the zone is treated as "insecure", assuming the DS records are properly authenticated. 🌈
  • --ignore-rfc8624 β€” ignore errors associated with RFC 8624, DNSSEC algorithm implementation requirements. RFC 8624 designates some DNSSEC signing algorithms and some DS digest algorithms as prohibited ("MUST NOT") or not recommended for validation and/or signing. if you use this option, then no warnings will be issued, and the code will still assess their cryptographic status, rather than ignoring them. πŸ’€ (yes, it still looks at the crypto, it's just not gonna yell at you about the RFC.)
  • --ignore-rfc9276 β€” ignore errors associated with RFC 9276, NSEC3 parameter settings. RFC 9276 specifies that if NSEC3 is used, the iterations count must be 0 and the salt length must be 0. if you use this option, then no warnings will be issued for NSEC3 records that violate this specification. 😌
  • -C, --enforce-cookies β€” enforce DNS cookies strictly. require a server to return a "BADCOOKIE" response when a query contains a COOKIE option with no server cookie or with an invalid server cookie. no half-steppin'. πŸͺ
  • -P, --allow-private β€” allow private IP addresses for authoritative DNS servers. by default, if the IP address corresponding to an authoritative server is in IP address space designated as "private", it gets flagged as an error. but there are some cases where this is allowed β€” like, for example, if the diagnostic queries are issued to servers in an experimental environment, that might be permissible. πŸ§ͺ
  • --trust-cdnskey-cds β€” trust all CDNSKEY and CDS records, even if they are not "signed with a key that is represented in both the current DNSKEY and DS RRsets" (RFC 7344). this is allowed if "the Parent uses the CDS or CDNSKEY RRset for initial enrollment; in that case, the Parent validates the CDS/CDNSKEY through some other means" (RFC 7344). and because there is no way for DNSViz to discover the out-of-band means with which the parent might have validated the CDNSKEY and/or CDS records, this trust is signaled with the use of the --trust-cdnskey-cds command-line option. 🫑
  • --multi-signer β€” don't issue errors for missing KSKs with DS RRs. typically an error is issued if a given DNSKEY is not found in the DNSKEY RRset returned by one or more servers. if --multi-signer is specified, then no error is issued, in the case that 1) the DNSKEY is not signing any non-DNSKEY RRsets (i.e., is a zone-signing key or ZSK) and 2) the DNSKEY corresponds to a DS record in the parent. this corresponds to the Model 2 use case in RFC 8901. 🀝
  • -o, --output-file filename β€” write the output to the specified file instead of to standard output, which is the default. πŸ“
  • -c, --minimize-output β€” format JSON output minimally instead of "pretty" (i.e., with indentation and newlines). tiny JSON, big energy. 🐜
  • -l, --log-level level β€” display only information at the specified log priority or higher. valid values (in increasing order of priority) are: "error", "warning", "info", and "debug". the default is "debug". πŸ”
  • -h, --help β€” display the usage and exit. the classic. πŸ’–

πŸšͺ EXIT CODES πŸšͺ

the exit codes are:

  1. 0 β€” program terminated normally. we love a clean exit. ✨
  2. 1 β€” incorrect usage. bestie, the syntax... 😭
  3. 2 β€” required package dependencies were not found. πŸ“¦βŒ
  4. 3 β€” there was an error processing the input or saving the output. πŸ’”
  5. 4 β€” program execution was interrupted, or an unknown error occurred. πŸ’€

πŸ”— SEE ALSO πŸ”—

dnsviz(1), dnsviz-probe(1), dnsviz-graph(1), dnsviz-print(1), dnsviz-query(1) β€” go read the whole fam, they're all iconic. πŸ‘‘


that's the whole page, bestie! you're officially grok-fluent πŸ’…

version 0.11.0, dated 26 September 2024 β€” shoutout to the dnsviz-grok(1) source, mwah, no notes πŸ«ΆπŸŽ€

πŸ“¦ where this page comes from