[DNSOP] Re: RFC for web3 wallet mapping using DNS
Greetings all. I have updated the ID with suggested changes to incorporate Paul Hoffman's WALLET RRtype, keeping the TXT record as a fallback. https://datatracker.ietf.org/doc/draft-chins-dnsop-web3-wallet-mapping/ I hope that this makes better sense as well as making sure its not contributing to root TXT namespace pollution, as David L's valid concern. Always open for comments, suggestions and criticism. Regards Shay ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
Agreed. I dislike overloaded TXT records. Proposed _w3addr as a prefix for namespacing purposes. On Wed, Sep 18, 2024, 1:31 PM John Levine wrote: > It appears that Dave Lawrence said: > >Joe Abley writes: > >> > Would it be recommended to do a proposal that use either RRtype > >> > (TXT or WALLET) or choose one? > >> > >> I haven't read your proposal and don't have an opinion on that. I > >> agree that it sounds like a good question for you to ask yourself. > > > >You don't have an opinion on using TXT? > > Using TXT works pretty well so long as there's a _prefix tag in the > name. Overloading the main name leads to absurd results. > > R's, > John > > $ dig stanford.edu txt +dnssec > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.10.6 <<>> stanford.edu txt +dnssec > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50649 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 64, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1232 > ;; QUESTION SECTION: > ;stanford.edu. IN TXT > > ;; ANSWER SECTION: > stanford.edu. 1791IN TXT > "Sendinblue-code:bde1f306529e82fd2ccf9857fc09aa98" > stanford.edu. 1791IN TXT "e2ma-verification=8z0eb" > stanford.edu. 1791IN TXT "e2ma-verification=fq1fb" > stanford.edu. 1791IN TXT "e2ma-verification=c00eb" > stanford.edu. 1791IN TXT "e2ma-verification=nw5fb" > stanford.edu. 1791IN TXT "e2ma-verification=n4agb" > stanford.edu. 1791IN TXT > "blitz=mu-0e24b17b-23dce65a-c0b14b75-e742cd66" > stanford.edu. 1791IN TXT > "e2ma-verification=fq1fb-remove" > stanford.edu. 1791IN TXT > "h1-domain-verification=aV4vQvSRHvQxGhvdz29L2ozsKDTReL7qKDgdjhPgzA5E7UC6" > stanford.edu. 1791IN TXT "e2ma-verification=dy8eb" > stanford.edu. 1791IN TXT > "airtable-verification=13ac52fb202035dbad35b0ab24e598b4" > stanford.edu. 1791IN TXT > > "pardot884873=1b7cebffc22a290049b6710c0620e741a3f4d3a720196287a95816f9afaa7695" > stanford.edu. 1791IN TXT > > "stripe-verification=984c5a4eb98ae34bbaf60c12403c1d8889d4ad02b2dc672232a89b21f905bc20" > stanford.edu. 1791IN TXT > "brevo-code:09357c2630559d902817770f34dbf0b1" > stanford.edu. 1791IN TXT "e2ma-verification=diffb" > stanford.edu. 1791IN TXT > > "wiz-domain-verification=2957e22f41cc73b19d44177ecf39bd1a1926a1e6362011b8f83e65aab5d6ef1a" > stanford.edu. 1791IN TXT > "google-site-verification=kyvps-t3mjXwz5HBQa7oO40qvObbV8z_B1IoySwe-GY" > stanford.edu. 1791IN TXT > > "atlassian-domain-verification=C9ho3V/RWWifTCqh8sF3L0PI7jVZWAL9dCxVL1gzJvr6SYJCKBQ8nCX38z50vRQ6" > stanford.edu. 1791IN TXT > "google-site-verification=n-cl_O68vbC-_UmufTZMmLLQb9wKnuUo-4FPom4m3iA" > stanford.edu. 1791IN TXT > "google-site-verification=p4uNfSaD7rr13xbA1Q1yW6I0DckXOv1ujjc0FQGjGEM" > stanford.edu. 1791IN TXT > "mgverify=c7c142ba8b95199619ad561a75f165ad285c322b3892f9621c083b0293fd0da0" > stanford.edu. 1791IN TXT "e2ma-verification=2i5eb" > stanford.edu. 1791IN TXT "e2ma-verification=gu1ab" > stanford.edu. 1791IN TXT > "airtable-verification=b8f5e3c2468d582f896b4a8f0839dd8a" > stanford.edu. 1791IN TXT "e2ma-verification=d1ueb" > stanford.edu. 1791IN TXT "e2ma-verification=4x8eb" > stanford.edu. 1791IN TXT > > "bwZknJMLNV1XuaJAyUmKlAFrdZo+p5yDlTNACmDUWhgtyihfJc8oWMnK7hWLreN+ozU3mX91yHHzZx0adJPPPg==" > stanford.edu. 1791IN TXT "e2ma-verification=a00eb" > stanford.edu. 1791IN TXT "e2ma-verification=1qjbb" > stanford.edu. 1791IN TXT > "airtable-verification=0a746053a028476f6d1671cbc9016585" > stanford.edu. 1791IN TXT "e2ma-verification=7z0eb" > stanford.edu. 1791IN TXT "e2ma-verification=2w2ab" > stanford.edu. 1791IN TXT "e2ma-verification=7uqeb" > stanford.edu. 1791IN TXT "e2ma-verification=cvnbb" > stanford.edu. 1791IN TXT > > "adobe-idp-site-verification=4c872117a60d5c3b7d132914730b3f3e2189c67a217450a2f3bc18a683a98f78" > stanford.edu. 1791IN TXT "e2ma-verification=b00eb" > stanford.edu. 1791IN TXT "e2ma-verification=vnjbb" > stanford.edu. 1791IN TXT "e2ma-verification=q57fb" > stanford.edu. 1791IN TXT > "google-site-verification=1HuKdQQTxv1R8v4dxihLzji-mH23d2KchIeaxsljN6Q" > stanford.edu. 1791IN TXT "e2ma-verification=nbxfb" > s
[DNSOP] RFC for web3 wallet mapping using DNS
confirm ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] RFC for web3 wallet mapping using DNS
Hello all, Here is the first submission https://datatracker.ietf.org/submit/status/145663/ I was hoping to get feedback on an RFC draft I have been working on for web3 wallet mapping using DNSSEC and the DNS system. I have tried to keep it very standard, just defining the mapping scheme without any extensions. Ideally I would like to consider this for standard track. A concern is the reference to SLIP-0044 which is an external standard that I am suggesting to use as chain tokenization. Thanks and regards, Shay ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
I think a WALLET RRtype extension would not change the need for some defining of the wallet mapping, as well as placing the requirement for authentication based on DNSSEC. There is an advantage of not overloading the TXT RRtype which has been used as a catch-all. Forgive me, but I'm not clear if the WALLET RRtype is a proposal or if it has been ratified. I see references to it in the IANA registry so I'm assuming it has been assigned and is currently usable? On Tue, Sep 17, 2024 at 11:30 PM Stephane Bortzmeyer wrote: > On Tue, Sep 17, 2024 at 11:09:12PM -0700, > Shay C wrote > a message of 53 lines which said: > > > I was hoping to get feedback on an RFC draft I have been working on for > > web3 wallet mapping using DNSSEC and the DNS system. > > It would be interesting to discuss the relationship with the existing > WALLET RRtype. > > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
The draft currently overloads the TXT record RRtype. WALLET record type would be appropriate but does have the issue that adoption isn't complete yet. Would it be recommended to do a proposal that use either RRtype (TXT or WALLET) or choose one? Will reach out to Paul Hoffman as well. Thanks On Wed, Sep 18, 2024 at 12:28 AM Joe Abley wrote: > On 18 Sep 2024, at 08:51, Shay C wrote: > > Forgive me, but I'm not clear if the WALLET RRtype is a proposal or if it > has been ratified. I see references to it in the IANA registry so I'm > assuming it has been assigned and is currently usable? > > > RRTypes are assigned by expert review and no specification is needed. > Here's the template that was used for WALLET: > > > https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template > > If your proposal requests a new RRType (I haven't read it, sorry), that > will also be subject to expert review and one of the things the expert will > consider is whether an existing RRType can be used instead. > > It is probably sensible to consider whether the existing WALLET RRType is > suitable for you to use. If so, your proposal could describe how that > existing RRType is used for your particular application. If not, be > prepared to show your working. > > I seem to remember Paul Hoffman was the one who applied for WALLET (and > somewhat recently) so it might be reasonable to get in touch with him and > compare notes. Paul is a frequent contributor to this working group and is > on this list. > > > Joe > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
Completed. On Wed, Sep 18, 2024 at 12:32 AM Mark Andrews wrote: > > The submission is incomplete. You need to complete it. You should have > email with a link to complete the submission. > > > On 18 Sep 2024, at 16:09, Shay C wrote: > > > > Hello all, > > > > Here is the first submission > > https://datatracker.ietf.org/submit/status/145663/ > > > > I was hoping to get feedback on an RFC draft I have been working on for > web3 wallet mapping using DNSSEC and the DNS system. I have tried to keep > it very standard, just defining the mapping scheme without any extensions. > Ideally I would like to consider this for standard track. > > > > A concern is the reference to SLIP-0044 which is an external standard > that I am suggesting to use as chain tokenization. > > > > Thanks and regards, > > Shay > > ___ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
The WALLET RRtype is already assigned as a DNS parameter https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template We are trying to get consensus on the operational usage of that RRtype. The TXT record fallback is also included as well as reverse lookup mechanisms. On Sun, Nov 17, 2024 at 6:20 AM Petr Menšík wrote: > Why don't we use URI instead? Maybe with prefix _wallet? Is introduction > of a new type necessary, when it seems like scheme:address format anyway? > > On 18/09/2024 17:44, Dave Lawrence wrote: > > Joe Abley writes: > >>> Would it be recommended to do a proposal that use either RRtype > >>> (TXT or WALLET) or choose one? > >> I haven't read your proposal and don't have an opinion on that. I > >> agree that it sounds like a good question for you to ask yourself. > > You don't have an opinion on using TXT? > > > > I'm somewhat surprised by this. > > > > ___ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > > -- > Petr Menšík > Software Engineer, RHEL > Red Hat, https://www.redhat.com/ > PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB > > ___ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
[DNSOP] Re: RFC for web3 wallet mapping using DNS
I have made a new draft https://datatracker.ietf.org/doc/draft-chins-dnsop-web3-wallet-mapping/ - Separated the forward mapping and reverse mapping. Will propose a ID for reverse mapping separately. - Removed DEFAULT record because it had the potential to return incorrect records Cheers Shay On Sun, Nov 17, 2024 at 9:49 PM Shay C wrote: > The WALLET RRtype is already assigned as a DNS parameter > > https://www.iana.org/assignments/dns-parameters/WALLET/wallet-completed-template > > We are trying to get consensus on the operational usage of that RRtype. > The TXT record fallback is also included as well as reverse lookup > mechanisms. > > On Sun, Nov 17, 2024 at 6:20 AM Petr Menšík wrote: > >> Why don't we use URI instead? Maybe with prefix _wallet? Is introduction >> of a new type necessary, when it seems like scheme:address format anyway? >> >> On 18/09/2024 17:44, Dave Lawrence wrote: >> > Joe Abley writes: >> >>> Would it be recommended to do a proposal that use either RRtype >> >>> (TXT or WALLET) or choose one? >> >> I haven't read your proposal and don't have an opinion on that. I >> >> agree that it sounds like a good question for you to ask yourself. >> > You don't have an opinion on using TXT? >> > >> > I'm somewhat surprised by this. >> > >> > ___ >> > DNSOP mailing list -- dnsop@ietf.org >> > To unsubscribe send an email to dnsop-le...@ietf.org >> >> -- >> Petr Menšík >> Software Engineer, RHEL >> Red Hat, https://www.redhat.com/ >> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB >> >> ___ >> DNSOP mailing list -- dnsop@ietf.org >> To unsubscribe send an email to dnsop-le...@ietf.org >> > ___ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
