mattipv4 / dns-over-discord Goto Github PK

As the bot begins to grow, there will be a point where it needs to support sharding.

It'd be great if it was still a single executable to be run, that handled spawning all the required shards.

Recently the bot moved to using disgord and initially used a cache config disabling all caches within the bot, as it only needs to respond to messages on-demand without anything being held in the cache.

However, in the production environment, this cache config resulted in the bot panicking and exiting. Commenting out the cache config resolve this for now but results in more memory usage for the bot.

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x0 addr=0x0 pc=0x7789d7]

goroutine 52 [running]:
github.com/andersfylling/disgord.(*Cache).UpdateMemberAndUser(0xc000118330, 0x530f8633f820003, 0x8e2734314800029, 0xc0008062c0, 0x14f, 0x160)
        C:/Users/Administrator/go/pkg/mod/github.com/andersfylling/[email protected]/cache.go:783 +0x57
github.com/andersfylling/disgord.cacheEvent(0x9a71e0, 0xc000118330, 0xc0001503e0, 0x13, 0x879ae0, 0xc0000da230, 0xc0008062c0, 0x14f, 0x160, 0x0, ...)
        C:/Users/Administrator/go/pkg/mod/github.com/andersfylling/[email protected]/events.go:109 +0x184c
github.com/andersfylling/disgord.demultiplexer(0xc0000d2940, 0xc000108420, 0xc000118330)
        C:/Users/Administrator/go/pkg/mod/github.com/andersfylling/[email protected]/reactor.go:73 +0x207
created by github.com/andersfylling/disgord.(*Client).setupConnectEnv
        C:/Users/Administrator/go/pkg/mod/github.com/andersfylling/[email protected]/client.go:393 +0x216

(Yes, production is a Windows server environment, don't @ me)

Hi! I've tried to invite the bot several times but it doesn't show up on the server.
Is the bot still working?

When a DNS lookup is run, some resolvers (such as 1.1.1.1) return comments with additional information, such as warning about DNSSEC failures. We should expose these comments to the end user in the embed generated by the dig command.

curl -H "Accept: application/dns-json" https://cloudflare-dns.com/dns-query\?name\=yumi.dev

{"Status":2,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"yumi.dev","type":1}],"Comment":["EDE(9): DNSKEY Missing (no SEP matching the DS found for yumi.dev.)"]}

curl -H "Accept: application/dns-json" https://cloudflare-dns.com/dns-query\?name\=maven.yumi.dev\&cd\=true

{"Status":0,"TC":false,"RD":true,"RA":true,"AD":false,"CD":true,"Question":[{"name":"maven.yumi.dev","type":1}],"Answer":[{"name":"maven.yumi.dev","type":1,"TTL":300,"data":"104.21.73.112"},{"name":"maven.yumi.dev","type":1,"TTL":300,"data":"172.67.162.66"}],"Comment":["EDE(9): DNSKEY Missing (no SEP matching the DS found for yumi.dev.)"]}

curl -H "Accept: application/dns-json" https://dns.google/resolve\?name\=yumi.dev

{"Status":2,"TC":false,"RD":true,"RA":true,"AD":false,"CD":false,"Question":[{"name":"yumi.dev.","type":1}],"Comment":"DNSSEC validation failure. Check http://dnsviz.net/d/yumi.dev/dnssec/ and http://dnssec-debugger.verisignlabs.com/yumi.dev for errors"}

Note that Comment may be a string, or an array of strings, so the logic will need to handle both. Note that comments may be included even when a lookup is successful, such as if there was a DNSSEC error, but checking was disabled.

Add a GitHub Actions workflow that runs on every commit and PR, running npm test.

Blocked by #22

As the title suggests, add an eslint configuration to the project based on the existing code style present in the project.

This should be exposed as npm run test:eslint and npm run test:eslint:fix. npm run test & npm run test:fix should also be added, calling npm run test:eslint & npm run test:eslint:fix respectively .

In DNS, the TTL is a measure of time in seconds. The 1.1.1.1 bot incorrectly labels the TTL as milliseconds.

Summary

TLDs should be considered valid domain names because they are able to have DNS records. For example, the ai TLD does in fact have A and MX records.

Examples

Bot doesn't consider TLDs a valid domain

ai TLD does have DNS records

If a user makes an invalid whois request, such as /whois 127.0.0.1, or /whois aaaa, the bot sits in the thinking state forever and does not return an error message.

Add WHOIS support for domains and IP addresses to the bot.

We should use the rdap.cloud service, specifically https://rdap.cloud/api/v1/xxx, which appears to provide a far more in-depth parsed whois object for both domains and IP addresses. The bot should then be able to return a formatted set of information when the domain whois command is used.

Hey, I just signed up for cloudflare thing that you told me to do, NPM is not available and nodejs is not available too, can I have a tutorial on the setting the bot up?

Add an option to set your API key from cloudflare and that you can manage records for your zones.

Hey.

tried installing the bot myself and failed when doing npm run dev.

here is the full error log:

(node:47656) UnhandledPromiseRejectionWarning: TypeError: discordCommands is not iterable
at module.exports.registerCommands (C:\Users\CENSORED\Desktop\DNS-over-Discord-2\src\build\commands.js:77:27)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async module.exports (C:\Users\CENSORED\Desktop\DNS-over-Discord-2\src\build\index.js:20:29)
(Use node.EXE --trace-warnings ... to show where the warning was created)
(node:47656) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:47656) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
thread 'main' panicked at 'could not parse wranglerjs output: Error("EOF while parsing a value", line: 1, column: 0)', src\wranglerjs\mod.rs:49:43
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
Note: This command was run via npm module 'win-node-env'
npm ERR! code ELIFECYCLE
npm ERR! errno 3221226505
npm ERR! [email protected] dev: NODE_ENV=development wrangler dev
npm ERR! Exit status 3221226505
npm ERR!
npm ERR! Failed at the [email protected] dev script.

Look at the following screenshot:

Here's the root cause (I think so):

When an uncached lookup is executed, it is cached and returned (without using JSON.stringify) here. As a result, these dates are displayed in a valid format (here). But when the result is cached (as a result of JSON.stringify), the date loses its type and therefore being toString()'d here (well, I'm not sure, I personally don't like JS btw).

Similar to how one can currently set the +short flag for requests, allow the user to set the +cdflag option to disable DNSSEC checking.

This should be exposed as an optional option on both the dig and multi-dig commands. It should map to +cdflag in dig command that is rendered/parsed, similar to how short maps to +short.

README documentation should be updated to explain using the checking disabled option and what it does.

When checking is disabled for a query, a warning should be appended to the embed, indicating that checking was disabled for the query. :warning: cd bit set for request, DNSSEC validation disabled..

Using https://github.com/dollarshaveclub/cloudworker, unit tests should be implemented for all the HTTP routes in the worker.

For interactions, there should be unit tests to ensure that the verification middleware works as expected, and then unit tests should be provided for each command in the interactions app.

I suggest enabling the "User Install" authorization method for the bot (at Discord Developer Portal)

For now, I'm only worried about testing the dig command. This will lay the ground-work for testing other commands down the road.

Implement end-to-end testing that simulates a valid interaction call from Discord to the worker (likely using wrangler in the dry-run mode and miniflare to run it in a simulated Workers environment), and ensure that the expected response is received. This will also need network calls mocked so that we can ensure the correct follow-up API calls are made to Discord, as the dig command handles responding asynchronously after the request.

To be clear, this is a pretty complex issue that involves setting up all the ground-work for testing in this repo, as well as fully mocking the Discord API calls involved in the interactions flow.

The end goal here is to have a test suite that can call the dig command (with any domain, any types, any options) as if it were a Discord user running a command, and we can validate that the bot will respond as we expect.

Create a GitHub Actions workflow the runs on pushes to a branch named production. This workflow should deploy the production environment of the worker to Cloudflare.

As a follow-up, once this initial workflow has been created, duplicate it for a branch named staging, and have it deploy the staging environment of the worker to Cloudflare.