Hi Andy, > Also, we might want to make it explicit in the spec that you can't > have duplicate records? Many DNS records allow multiple for > redundancy. Is that desired here?
Agreed, this should be made explicit in the bLIP. I don't see a reason to allow duplicate records, so we should require uniqueness. > Is there any problem allowing a different user to have a different > blinded path? This not only helps with scalability, but say someone > want's to have a domain that is shared by say 5 users, but all those > users want to run their own node. I'm not sure which option you're commenting on here. In option 1, you can't have different blinded paths per user, since you have a single DNS record that just points to the domain owner's node. In option 3, there is already one record per user, and the user chose the blinded path themselves. If the end user (payment recipient) wants to handle this with their own node and control the blinded path, I think they'll need to have their own domain and use option 3. I may be misunderstanding your point though, let me know if that seems to be the case. Thanks, Bastien Le lun. 20 nov. 2023 à 17:32, Matt Corallo <lf-li...@mattcorallo.com> a écrit : > > > On 11/20/23 6:53 AM, Andy Schroder wrote: > >> > >>> - I would omit suggesting to use DoH from the spec. DoH seems a bit > centralized to me and that's > >>> up to the client to decide what to do. DNS itself is a hierarchically > distributed system, so > >>> there is redundancy built into it (which has its flaw at the root > nameserver / ICANN level) and > >>> it seems to me like DoH is taking much of that distributed design > away. It seems like if you are > >>> concerned about your ISP snooping your traffic, you should use a > tunnel so that your traffic is > >>> obfuscated that way, that way things are done at the IP level and not > way up at the HTTPS level. > >>> Are you resorting to DoH because many ISP block traffic for DNSSEC > records traffic through their > >>> networks? Either way, how you query DNS seems like that should be left > up to the client and not > >>> really part of the spec. > >> > >> It is, but its worth mentioning in large part because almost certainly > ~all implementations will > >> use it. While I agree that it'd be very nice to not use it, in order to > do so clients would need > >> to (a) actually be able to query TXT records, which isn't in standard > operating system libraries, > >> so would probably mean DoH to 127.0.0.53 or so, (b) trust the > resolver's DNSSEC validation, which > >> means having some confidence its local, and not a coffee shop/etc. > >> > >> Given the level of trust you have to have here in the DNS resolution, > its almost certainly best to > >> cross-validate with at least multiple DoH services, unless you are > validating the DNSSEC chain > >> yourself (which I'd really strongly prefer as the best solution here, > but I'm unaware of any open > >> source code to do so). > > > > delv, part of bind9, does recursive DNSSEC validation locally: > > https://manpages.ubuntu.com/manpages/jammy/en/man1/delv.1.html > > Sadly this doesn't really solve the issue. Lightning nodes need to be able > to get a DNSSEC tree in a > cross-platform way (which "just call delv" is not) ideally without relying > on sending UDP directly > at all. What this really means is that we'll eventually want to use the > RFC 9102 CHAIN serialization > format and put that in the node_announcement, but to do that we need some > kind of (cross-platform > library) client software which can take a serialized CHAIN and validate > it. I'm unaware of any such > software, though in theory it shouldn't be that hard to write. > > Matt > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
