Skip to content
This repository has been archived by the owner on Jul 13, 2022. It is now read-only.

Feature: DNS TXT record support for PayID lookup #589

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

RichardAH
Copy link

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)
  • 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 RichardAH requested a review from a team July 12, 2020 06:09
@RichardAH
Copy link
Author

@codecov
Copy link

codecov bot commented Jul 12, 2020

Codecov Report

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

Impacted file tree graph

@@            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%) ⬇️

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
Copy link

😎

@keefertaylor
Copy link
Contributor

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.

Copy link
Contributor

@LoisRP LoisRP left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved, subject to fixing typo


This version of Xpring-JS will attempt to look up PayID information in a DNS TXT record before reverting to http/s protocol.

For example requesting PayID `richard$payid.link` for `xrpl-mainnet` will first attempt to retreive a TXT record at `xrpl-mainnet.richard._payid.payid.link`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

retrieve

@keefertaylor
Copy link
Contributor

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 warren@ripple.com 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
Copy link
Author

RichardAH commented Jul 14, 2020

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 warren@ripple.com 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
Copy link

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 warren@ripple.com 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants