Remaining tasks on resolver overhaul

Remaining tasks on resolver overhaul

[Rich Felker]

The vast majority of what I'd call the resolver overhaul is done now,
but a few things remain that don't have an impact on the architecture
and design, but which still might be a lot of work:

- Sorting results per RFC 3484 or at least a subset of its rules.

- AI_ADDRCONFIG -- but maybe the current implementation of it as a nop
  is actually best; see
  https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG

- IDN support.

- IPv6 scope-id parsing.

- One remaining legacy resolver function: dn_comp.

- And most importantly: REVIEW AND TESTING.

We're behind schedule for the roadmap, so of the above items, the ones
I'd really like to focus on for release are those which most impact
IPv6 usability.

Since we have some resolver items remaining to work on, as well as a
lot of secondary targets that don't look like they're going to make it
for 1.1.2, I may update the roadmap to insert an extra release cycle
before the next one.

I'd like comments on what should be prioritized at this point. And of
course any bug reports/regressions associated with the recent commits.

Rich

Re: Remaining tasks on resolver overhaul

[u-igbb]

On Mon, Jun 02, 2014 at 05:18:48AM -0400, Rich Felker wrote:
> - AI_ADDRCONFIG -- but maybe the current implementation of it as a nop
>   is actually best

+1
(nop is best, guessworks are harmful, code simplification is useful)

Rune

Re: Remaining tasks on resolver overhaul

[Laurent Bercot]

>> - AI_ADDRCONFIG -- but maybe the current implementation of it as a nop
>>    is actually best
>
> +1
> (nop is best, guessworks are harmful, code simplification is useful)

  +1. AI_ADDRCONFIG has always been a logical aberration: the underlying
DNS transport and capabilities of the machine have nothing to do with the
data transmitted via DNS. If a domain has an AAAA record, I expect
getaddrinfo() to return it, whether my machine is IPv6-capable or not.

-- 
  Laurent

Re: Remaining tasks on resolver overhaul

[Rich Felker]

On Mon, Jun 02, 2014 at 11:28:00AM +0100, Laurent Bercot wrote:
> >>- AI_ADDRCONFIG -- but maybe the current implementation of it as a nop
> >>   is actually best
> >
> >+1
> >(nop is best, guessworks are harmful, code simplification is useful)
> 
>  +1. AI_ADDRCONFIG has always been a logical aberration: the underlying
> DNS transport and capabilities of the machine have nothing to do with the
> data transmitted via DNS. If a domain has an AAAA record, I expect
> getaddrinfo() to return it, whether my machine is IPv6-capable or not.

So far all the comments I've heard on AI_ADDRCONFIG have been in favor
of leaving it a nop. IMO this is perfectly conforming as long as the
system has 127.0.0.1 and ::1 since "an IPv4 address is configured on
the local system" and "an IPv6 address is configured on the local
system".

Personally I'm not as strongly opposed to AI_ADDRCONFIG actually doing
something as some people are, since it's NOT the default; you have to
request it. Actually glibc sets it automatically when hints==NULL,
which is non-conforming (hints==NULL implies flags==0 per the
standard) so this may be why so many people hate it. If we added
support and followed the letter of the standard exactly (treating ::1
and 127.0.0.1 as configured addresses) it would behave as a nop on
basically all real-world systems except those where either IPv4 or IPv6
has been fully ripped out, where the admin/user actually may want to
be suppressing one or the other.

In any case I'm in no hurry to make changes on this item since there
seems to be no demand for such functionality.

Rich