This method suggests that domain owners can choose which option to implement based on their capabilities, potentially using both options conditional on the user existence.

There are concerns regarding the centralization risks associated with DNS over HTTPS (DoH). It's suggested that DoH shifts away from the inherently redundant structure of DNS and that privacy-related issues should be addressed at the IP level through tunneling methods, rather than at the HTTPS level. It is proposed to leave the choice of DNS querying methods to clients' discretion and not include it in the specification.

Questions arise about the expiration times for paths/offers and DNS records. The goal is to set DNS record expirations shorter than path or offer expirations to mitigate latency issues in DNS propagation. Attention is drawn to potential discrepancies between when an offer is created and when it is fetched by a local computer, which could affect the relative expiration timings.

Concerns are also raised about the possible length restrictions of DNS records when incorporating blinded paths or offers. These need to be considered to ensure compatibility and avoid technical limitations.

For option 1, it is recommended to introduce variability in blinded paths for different users to enhance scalability and support diverse configurations, including personal lightning nodes separate from domain operators. A revision is suggested to eliminate the assumption that a Lightning Service Provider (LSP) is always involved. Instead, the verification of offers depends on whether Bob self-hosts or uses an LSP, with DNSSEC validation providing assurance if self-hosted and the honesty of root and TLD nameservers is presumed. Additionally, a QR code format is advised for easier validation by phone applications.

Option 2 is critiqued for its reliance on certificate authorities to affirm domain ownership, which does not align with their role and presents a significant vulnerability due to the potential faults within any trusted certificate authority. Moreover, this approach is deemed unscalable as it necessitates broadcasting all domain announcements, contrasting with the efficiency of a decentralized DNS model that could learn from the hierarchical elements of the traditional DNS.

Finally, option 3 is subject to the same verification challenges mentioned previously, where the inability to confirm the authenticity of Bob's offer without a reliable trust framework remains a concern.

Andy Schroder communicates these insights and considerations, seeking further reflection and development in the specifics of DNS usage and security for modern internet services. Bastien TEINTURIER contributes to the conversation, emphasizing the importance of these details in crafting a robust and effective specification.