Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is the DNS domain sufficiently generic to become js-dns and become useful for more generic DNS operations? #16

Open
1 task
CMCDragonkai opened this issue Sep 16, 2023 · 4 comments
Labels
r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices research Requires research

Comments

@CMCDragonkai
Copy link
Member

What is your research hypothesis/question?

I know you were using dns-packet before, and we changed to building our own DNS parser and generator.

I had a look at the code, it looks pretty extensive. I'm wondering how much work would need to be done on it to make it generic enough for generic DNS operations.

PKE will have some dns resolution related bootstrapping logic... and things like DNSSEC and other operations may be relevant.

Also I was wondering how come you have some functions that look like existing JS code can do:

function encodeUInt16BE(value: number): Uint8Array {
  const buffer = new Uint8Array(2);
  new DataView(buffer.buffer).setUint16(0, value, false);
  return buffer;
}

function encodeUInt32BE(value: number): Uint8Array {
  const buffer = new Uint8Array(4);
  new DataView(buffer.buffer).setUint32(0, value, false);
  return buffer;
}

Review existing ideas, literature and prior work

Research conclusion

Look at PKE's private network bootstrapping issue and figure out if we need a js-dns package.

Sub-Issues & Sub-PRs created

  1. ...
  2. ...
  3. ...
@CMCDragonkai CMCDragonkai added the research Requires research label Sep 16, 2023
@amydevs
Copy link
Collaborator

amydevs commented Oct 9, 2023

it should work out of the box with normal DNS packets, it's just there's some records types that i haven't added support yet

@CMCDragonkai
Copy link
Member Author

Would that mean factoring it out as something like @matrixai/dns?

@amydevs
Copy link
Collaborator

amydevs commented Oct 18, 2023

Would that mean factoring it out as something like @matrixai/dns?

yes, it would also mean some work to support more DNS packet types, but all in all i think the dns-packet library should be sufficient for now, and moving over to @matrixai/dns eventually should only be some small api changes

@CMCDragonkai
Copy link
Member Author

I'm confused, you're not using dns-packet anymore.

  "dependencies": {
    "@matrixai/async-cancellable": "^1.1.1",
    "@matrixai/async-init": "^1.10.0",
    "@matrixai/contexts": "^1.1.0",
    "@matrixai/errors": "^1.1.7",
    "@matrixai/events": "^3.2.0",
    "@matrixai/logger": "^3.1.0",
    "@matrixai/table": "^1.2.0",
    "@matrixai/timer": "^1.1.1",
    "canonicalize": "^2.0.0",
    "ip-num": "^1.5.1"
  },

Are you saying that dns-packet would be suitable if we wanted to do other kinds of DNS parsing.

But later down the line, we can factor out your DNS code, and bring in things from dns-packet and synthesise a @matrixai/dns package?

@CMCDragonkai CMCDragonkai added the r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices label Aug 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
r&d:polykey:core activity 4 End to End Networking behind Consumer NAT Devices research Requires research
Development

No branches or pull requests

2 participants