Re: Requirements for new dns backend, factoring considerations

[u-igbb@aetey.se]

Hello Rich,

On Sun, Jun 01, 2014 at 02:31:03AM -0400, Rich Felker wrote:
> process, and partly looking for feedback on some of these decisions

Here you are:

> As another alternative, we could drop the goal of doing search
> suffixes in parallel. This would have no bearing on lookups of fully
> qualified names using the default settings (ndots:1) since the
> presence of a dot suppresses search. Where it would negatively impact
> performance, though, is for users who want to have several search
> domains (think: home network, university network, department-specific
> university network, etc.) for quick shortcuts to machines on multiple
> different networks.

My experience is that such kind of shortcuts is dangerous and inconsistent.
They stir different namespaces, this can not give a reliable outcome
in a general case.

What a certain shortcut resolves to depends on too many things and among
others on which changes are made by third parties to the contents of
the name spaces which you short-circuit (a new host in one's department
can easily take the place of a desired host at a different department).

So I would not care less about efficiency of an uncertain and inconsistent
practice/tool :)

> Another option still is leaving search domains unimplemented (musl has
> not supported them up til now, and there hasn't been much request for

As I see this, spending your time on other things might be a better choice.

> them). But if there is, or will be, demand for them, I don't want the
> resolver overhaul design to preclude doing them

This is surely reasonable.

> (or preclude making
> them perform decently).

I guess it is very few people in rare situations who might be hit by
performance issues there, which would most probably also imply that they
have a badly thought-out setup.

So much for the feedback.

Thanks for your work Rich.

Rune