[squid-dev] [RFC] dns_wait_for_all

[Amos Jeffries]

On 16/09/2016 3:35 a.m., Alex Rousskov wrote:
> On 09/15/2016 03:50 AM, Amos Jeffries wrote:
>> On 15/09/2016 5:11 p.m., Alex Rousskov wrote:
>>> On 09/14/2016 07:26 PM, Amos Jeffries wrote:
>>>> On 15/09/2016 8:15 a.m., Alex Rousskov wrote:
>>>>> Any better ideas or objections to adding dns_wait_for_all?
>>>
>>>
>>>> In principle okay. However, I was intending to redesign the object we
>>>> store DNS RR results in to achieve this is a more useful way. 
>>>
>>> If you are talking about Comm::ConnectionList/serverDestinations, then
>>> that object will have to be redesigned to support this proposal, of
>>> course. The object would also have to be safely shared across FwdState,
>>> peer selection code, and DNS code for the proposed feature to work.
>>
>> I mean Dns::LookupDetails, ipcache_addrs and rfc1035_rr.
> 
>> Something like:
>>
>> * ipcache_addrs::in_addrs becomes a list of rfc1035_rr instead of array
>> if IP address. (or an equivalent type storing the same details in easier
>> to access type than 'rdata' uses).
>>
>> * ipcache_addrs::bad_mask moved into rfc1035_rr for a mask on the
>> records in each RR separately.
>>
>> * ipcache_addrs merged into Dns::LookupDetails.
> 
> That sounds mostly unrelated to the problem at hand. If we need to alter
> Dns::LookupDetails, ipcache_addrs, or rfc1035_rr in some significant
> way, then we will come back to this discussion. Otherwise, it stays as a
> separate/independent not-yet-discussed project.
> 
> 
>> The serverDestinations not changing (yet).
> 
> I am pretty sure we have to change that field to implement
> dns_wait_for_all functionality correctly. For example:
> 
> * we need to make its updates (from different jobs!) safe, with
> easy-to-trace debugging.
> 
> * we need to support an EOF-like semantics to signal whether more
> destinations may still be provided.


I think you are mistaking serverDestinations as being part of the DNS
operations. It is not.

serverDestinations is state in the FwdStateData 'Job', the IP addresses
used by it have to go through the peer selection 'Job' processing and
related access controls applied to whatever comes out of an ipcache
lookup 'Job'.

DNS lookups are buried 3+ 'Job' layers away on the other side of
ipcache. All they do is feed that cache with data.

If you are intending to alter serveDestinations operations, then please
dont call the option dns_* . It is a tcp_outgoing_* thing.

Amos