[Lightning-dev] DNS Seed query semantics clarification

Thomas Steenholdt TSteenholdt at cascadetechnologypartners.com
Tue Mar 20 11:26:58 UTC 2018


Cool,

Since we're trying to clarify some of the things that may not be entirely clear, there are a few other things it may be relevant to address or define at the same time:

  1.  What's the intended direction of interpreting the conditions?
  2.  What's the result of the conflict if a condition is specified multiple times?

So using the thought-up case of r0.a2.n5.a4.n10.seed.example.com:

  1.  Should the DNS seed process the conditions from the seed root and "up the tree" or in the opposite direction?

For the sake of argument, I'm going to assume we want to take a (DNS-wise) logical approach, i.e. interpreting from the seed root and "up the tree", so in the order: n10, a4, n5, a2, r0.

  1.  What happens to a2 when we meet a4? Should a4 replace any current a condition or simply be ignored (or in the case of a perhaps even merged through a bitwise or)? Same question for n5when we meet n10.

Personally I think it would make sense to always replace currently set conditions, when we hit new conditions with the same key. This would allow us to easily add a condition to a query programmatically, without having to interpret any conditions that may be set already. Prepending a current query string with a6. would then guarantee that an earlier condition does not limit my results to either IPv4 or IPv6 nodes. As long as the length of the query string does not exceed a total of 253 chars (standard DNS limitation, not counting the root .).

Any thoughts on this?


/Thomas

________________________________
From: Christian Decker <decker.christian at gmail.com>
Sent: Friday, March 16, 2018 10:44:01 AM
To: Thomas Steenholdt
Cc: lightning-dev at lists.linuxfoundation.org
Subject: Re: DNS Seed query semantics clarification

Thomas Steenholdt <TSteenholdt at cascadetechnologypartners.com> writes:
> Thanks for the explanation - This was exactly the the piece of the
> puzzle I was missing. 😊
>
> I'd be happy to help clarify this in the BOLT10 specification, if that
> makes any type of sense? I can make a pull request for revie

Absolutely, improvements are always welcome :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180320/6629603d/attachment.html>


More information about the Lightning-dev mailing list