tool: update kapinger to make random dns queries

[alexcastilio]

Description

Update kapinger to make random dns queries

Related Issue

If this pull request is related to any issue, please mention it here. Additionally, make sure that the issue is assigned to you before submitting this pull request.

Checklist

• I have read the contributing documentation.
• I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
• I have correctly attributed the author(s) of the code.
• I have tested the changes locally.
• I have followed the project's style guidelines.
• I have updated the documentation, if necessary.
• I have added tests, if applicable.

Screenshots (if applicable) or Testing Completed

Please add any relevant screenshots or GIFs to showcase the changes made.

Additional Notes

Add any additional notes or context about the pull request here.

---

Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.

[MikeZappa87]

What is the intention of this PR? This looks like it issues DNS queries for 'random' domain names? What is the scale? 1, 10, 100, 1000, 10000? After these queries are executed what is the consumer? Are we measuring something? This sounds like the consumer doesn't have a great means of testing.

[alexcastilio]

What is the intention of this PR? This looks like it issues DNS queries for 'random' domain names? What is the scale? 1, 10, 100, 1000, 10000? After these queries are executed what is the consumer? Are we measuring something? This sounds like the consumer doesn't have a great means of testing.

The idea is to generate random DNS queries. This will be used to scale test retina which will be generating metrics for traffic on the cluster (both these DNS queries and other traffic generated). This was requested as part of #1040

[timraymond]

@MikeZappa87 pursuant to our earlier concerns about the external DNS traffic this might generate, it looks like .test is configured to black hole requests. The SOA record lists localhost as the resolver for .test:

; <<>> DiG 9.18.28 <<>> @4.2.2.2 test SOA
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52782
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test.                          IN      SOA

;; ANSWER SECTION:
test.                   10800   IN      SOA     localhost. nobody.invalid. 1 3600 1200 604800 10800

;; Query time: 10 msec
;; SERVER: 4.2.2.2#53(4.2.2.2) (UDP)
;; WHEN: Mon Nov 25 15:17:24 EST 2024
;; MSG SIZE  rcvd: 92

[MikeZappa87]

What is the intention of this PR? This looks like it issues DNS queries for 'random' domain names? What is the scale? 1, 10, 100, 1000, 10000? After these queries are executed what is the consumer? Are we measuring something? This sounds like the consumer doesn't have a great means of testing.

The idea is to generate random DNS queries. This will be used to scale test retina which will be generating metrics for traffic on the cluster (both these DNS queries and other traffic generated). This was requested as part of #1040

The concern is that this could be hitting DNS servers that we don't own nor do we have an agreement to do this. It probably makes more sense to stand up a DNS server we control to do this or come up with a design change to test retina without doing this.

[timraymond]

@MikeZappa87 I did some more research, and it depends very much on the resolver you ask. Cloudflare (1.1.1.1) and Google (8.8.8.8) both forward the request to the root servers, and they are the ones that respond with NXDOMAIN. Needless to say, flooding the root servers is A Very Bad Thing for the reasons you outline.

On the other hand, Level 3 (4.2.2.2) and Quad 9 (9.9.9.9) black hole the .test TLD in the way that I showed earlier (that request was to Level 3).

I agree though... even though this is the TLD to use, it's clear that resolvers handle it inconsistently (and probably shouldn't be trusted to consistently handle it). We should just stick BIND or CoreDNS in there to field all this traffic.