Feature: DNS TXT record support for PayID lookup

[RichardAH]

High Level Overview of Change

Add a secondary lookup path for PayIDs using JSON payloads held in TXT records in the global domain name system, signed using the public key of the cryptocurrency address to which the PayID points.

Context of Change

PayID currently relies on the provision of a http/s service which must be actively run and maintained to support lookups for what is often essentially a static address-book of cryptocurrency addresses. This has a couple of drawbacks for adoption:

Firstly: Cost. The net benefit of having a PayID is unlikely to be greater than the cost of running and maintaining a PayID server for the vast majority of users.

Secondly: Availability. If a PayID server is DDoS attacked or goes offline for any other reason a PayID becomes unusable. High availability is essential for adoption.

Providing a secondary lookup path for PayID addresses using the existing DNS system is therefore desirable.

However in order to protect against various long standing DNS attacks, such as cache poisoning, it is important to provide a way to verify information stored in a DNS TXT record. For this I have created a small library and command line utility for signing and verifying PayIDs using the public key of the crypto address the PayID points to: PayID-Sign Tool

To use simply create a JSON payload with the above tool and then place it on a TXT record according to the following schema:

<network>-<mainnet|testnet>.<payid-identifier>._payid.<payid-host>

For example: xrpl-mainnet.richard._payid.payid.link

Type of Change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Refactor (non-breaking change that only restructures code)
• [ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
• [ ] Documentation Updates
• [ ] Release

Before / After

Before: PayIDs could only be looked up using the RFC http/s protocol After: Resolving a PayID now first tries a DNS TXT record lookup, if one is found it attempts to cryptographically verify it, and if it is valid it is returned instead. If anything goes wrong revert to original protocol.

Test Plan

Use PayID-Sign Tool to create a JSON payload Set the JSON payload into TXT record on a domain you own according to the following schema:

<network>-<mainnet|testnet>.<payid-identifier>._payid.<your domain>

Run a lookup using this library on that PayID.

Future Tasks

Test suite using a fake DNS resolver. Similar updates to other PayID client libraries.

Other Notes

Please consider this contribution my entry into your hackathon

[RichardAH]

https://devpost.com/software/payid-dns

[codecov[bot]]

Codecov Report

Merging #589 into master will decrease coverage by 0.24%. The diff coverage is 64.70%.

@@            Coverage Diff             @@
##           master     #589      +/-   ##
==========================================
- Coverage   82.28%   82.04%   -0.25%     
==========================================
  Files          60       60              
  Lines        1214     1231      +17     
  Branches      287      289       +2     
==========================================
+ Hits          999     1010      +11     
- Misses        120      125       +5     
- Partials       95       96       +1     

Impacted Files	Coverage Δ
src/PayID/pay-id-client.ts	79.24% <64.70%> (-6.87%)	:arrow_down:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update 205f51e...c1e8cb1. Read the comment docs.

[WietseWind]

😎

[keefertaylor]

Super cool. Adding in a few folks from the PayID protocol team since I'm not sure where we're at with proposing new standards to the PayID protocol. That said, this makes a lot of sense to me, so I'm supportive.

An initial glance of the code makes me think this is reasonable and I'll get you a formal review after the weekend. If accepted, we'll ask you to write unit tests.

[keefertaylor]

We're definitely excited about this. We plan to address this proposal at the next PayID working group on Wednesday, 7/22. We invite you to participate and help the discussion. Can you email [email protected] to get invited to the working group?

We'd like to get community feedback before codifying a standard in our client side development toolchain.

[RichardAH]

We're definitely excited about this. We plan to address this proposal at the next PayID working group on Wednesday, 7/22. We invite you to participate and help the discussion. Can you email [email protected] to get invited to the working group?

We'd like to get community feedback before codifying a standard in our client side development toolchain.

I believe I'm already invited to that working group. Don't you think a community discussion on updates to the standard should be conducted in a more general forum than a zoom call?

[aanchal4]

We're definitely excited about this. We plan to address this proposal at the next PayID working group on Wednesday, 7/22. We invite you to participate and help the discussion. Can you email [email protected] to get invited to the working group? We'd like to get community feedback before codifying a standard in our client side development toolchain.

I believe I'm already invited to that working group. Don't you think a community discussion on updates to the standard should be conducted in a more general forum than a zoom call?

Definitely. Apart from WGs, we can discuss everything PayID in PayID Discord channel. Feel free to start a discussion thread there.