Re: [Lightning-dev] DNS Seed query semantics clarification

[Thomas Steenholdt]

Hi guys,


I have proposed an update to BOLT #10 in pull request #396, in an attempt to 
address these things.


Any feedback is welcome.


/Thomas


From: lightning-dev-boun...@lists.linuxfoundation.org 
<lightning-dev-boun...@lists.linuxfoundation.org> on behalf of Thomas 
Steenholdt <tsteenho...@cascadetechnologypartners.com>
Sent: Tuesday, March 20, 2018 8:26:58 AM
To: Christian Decker
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: [Lightning-dev] DNS Seed query semantics clarification


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.christ...@gmail.com>
Sent: Friday, March 16, 2018 10:44:01 AM
To: Thomas Steenholdt
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: DNS Seed query semantics clarification

Thomas Steenholdt <tsteenho...@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 :-)

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DNS Seed query semantics clarification

[Thomas Steenholdt]

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 
Sent: Friday, March 16, 2018 10:44:01 AM
To: Thomas Steenholdt
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: DNS Seed query semantics clarification

Thomas Steenholdt  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 :-)

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DNS Seed query semantics clarification

[Christian Decker]

Thomas Steenholdt  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 :-)
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DNS Seed query semantics clarification

[Thomas Steenholdt]

Hi Christian,

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 review?

/Thomas



From: Christian Decker 
Sent: Friday, March 16, 2018 9:37:17 AM
To: Thomas Steenholdt
Cc: lightning-dev@lists.linuxfoundation.org
Subject: Re: DNS Seed query semantics clarification

Hi Thomas,

indeed the spec is a bit vague on the flags. The intent is to use them
as subdomains. For example if you want to query for only realm IPv4
nodes then you'd use the following:

  dig a2.seed.bitcoinstats.com

while IPv4 or IPv6 nodes, but only nodes with realm 0, should be
returned to the following:

  dig r0.a6.seed.bitcoinstats.com

Notice however that I haven't implemented the query filtering itself
just yet.

Cheers,
Christian

Thomas Steenholdt  writes:
> Hi there,
>
>
> I'm trying to understand the DNS seeds described by BOLT10, but seem to be 
> missing something regarding the query semantics.
>
>
> The BOLT states that the DNS seed must support a list of key-value pairs, but 
> it's unclear to me how these pairs are used in a query. Are they encoded into 
> the fqdn used in the query or something entirely different?
>
>
> Any pointers?
>
>
> /Thomas

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] DNS Seed query semantics clarification

[Christian Decker]

Hi Thomas,

indeed the spec is a bit vague on the flags. The intent is to use them
as subdomains. For example if you want to query for only realm IPv4
nodes then you'd use the following:

  dig a2.seed.bitcoinstats.com

while IPv4 or IPv6 nodes, but only nodes with realm 0, should be
returned to the following:

  dig r0.a6.seed.bitcoinstats.com

Notice however that I haven't implemented the query filtering itself
just yet.

Cheers,
Christian

Thomas Steenholdt  writes:
> Hi there,
>
>
> I'm trying to understand the DNS seeds described by BOLT10, but seem to be 
> missing something regarding the query semantics.
>
>
> The BOLT states that the DNS seed must support a list of key-value pairs, but 
> it's unclear to me how these pairs are used in a query. Are they encoded into 
> the fqdn used in the query or something entirely different?
>
>
> Any pointers?
>
>
> /Thomas
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev