----- Original Message -----
From: "Nick Jones" <nick.fa.jones(a)gmail.com>
In the summary of this Fedora feature for fixing name resolution is
this snippet: "Fedora could be seen as the leader in linux networking"
Yep. My intention to improve the overall networking features is not limited to what is
described in FixNetworkNameResolution.
getaddrinfo is important for Linux systems, and the existing issues
with it's implementation are well worth fixing, but when it comes to
DNS, getaddrinfo is holding Fedora and Linux back.
When it comes to DNS, it's absolutely necessary to run a local resolver like dnsmasq
or unbound (the latter supporting DNSSEC) to achieve some of the advanced features like
split lists of DNS name servers (e.g. for VPNs). But at least dnsmasq is already supported
by NetworkManager.
Even though DNS is not the only source of 'names' that
getaddrinfo
can return, it is the most important, and in the context of DNS,
getaddrinfo will not let Fedora reach the above stated goal.
I'd be happy to discuss the details, probably in a separate discussion from this
feature. Maybe IRC some time?
It's not just the lack of support for asynchronous usage,
getaddrinfo
is a very feature poor resolver:
- No support for alternative DNS record types: mx, txt ((ab)used for
a lot of things)
True enough. I was thinking about implementing at least SRV records.
- No support for DNSSEC
True enough. And also no support for DNS lifetimes. There probably should be a more
coprehensive API for that while getaddrinfo would work on top of it.
- No TCP fallback for that matter, which is essential for the above
This should be handled in the DNS daemon (or supplementary tools) anyway.
- Probably lot more, I'm no expert on dns
Possibly.
What is needed for networking leadership is:
- a feature rich resolver, supporting the above as well as query
and response filtering, ala AI_ADDRCONF
Agreed.
- an implementation of an IPv6 migration strategy along the lines
of Happy Eyeballs
I'm afraid this is not limited to DNS.
- can be used both asynchronously or synchronously
That would be nice. Communication with a daemon over sockets works asynchronously for
free.
- ideally pulls in no dependencies outside libc, except perhaps
libidn
That would require a custom communication protocol for the async part.
- ideally the DNS packet parsing routines use only ANSI C
- can be used by both C and C++ applications, and is easily
bound to other scripting languages, even in the async case
That again suggests a daemon with IPC.
- provides reverse lookup
Sure.
- more I can't think of right now but I hope others will add more
It would be better to maintain such information on a wiki page or something. Nobody will
come back to the e-mails now and then.
The question is does this all get added into glibc?
1) Yes:
- glibc getaddrinfo gets updated to support this through
the addition of new hints flags and return values, or a new
function interface is created instead of shoehorning into the
old interface, in any case the old getaddrinfo interface will
always be callable using traditional, existing semantics and
run time linking to existing apps will not be broken
- the nss layer gets rewritten to support asynchronous usage
(and decent error reporting and additional lookup domains
maybe samba?)
- perhaps the resulting work gets packaged into a proposed
extension to POSIX
Even if this could be done, it looks like a very-long-term project and needs more than
just dropping suggestions to a mailing list.
2) No:
- simply say: forget it, lets do proper DNS outside of libc
We already can do proper DNS outside libc. There's no problem with that. The more
complicated part is getting all sorts of resolution methods together.
I say 1) could be possible over the course of a few years but
for now, 2) is more realistic.
As a quick summary: I would suggest, in addition to addressing
the outstanding bugs and issues covered by the Fedora feature,
a flag be added to the set of getaddrinfo parameters that
instructs it NOT to do DNS lookups, only perform alternative
resource lookups supported by nss. This flag would be something
like: AI_NODNS
I'm not in favor of adding this flag, as DNS is not IMO as specific.
This will allow application developers to make use of
getaddrinfo for resolving names using non dns sources
What for?
(hosts file is DNS,
This is a huge mistake. Many of the bugs are results of treating the /etc/hosts the same
way as DNS resolution. While the /etc/hosts file often overrides the information that
would otherwise be recieved through DNS, it is no DNS at all, just a way to specify static
mapping between names and addresses.
so this means ldap and others), then perform
internet domain lookups using an alternative DNS library that
is standardised in Fedora.
I don't think this is a good solution.
Given that in most systems, the nss alternatives are local file
based,
Not at all. And even less in the future.
and given the option of using nsscache, these lookups
could be considered reasonably constrained therefore NOT in
need of asynchronous implementations.
Over time, the alternative DNS library could be considered for
inclusion in the core c library, and could replace the DNS
lookup aspect of getaddrinfo, at least for A and AAAA lookups,
and more if additional query flags are defined for getaddrinfo
or if an alternative function interface is defined.
Spliting out DNS from other host name resolution more than it is now, would IMO be a huge
mistake. There's not just DNS out there.
In addition, work can be done to make the nss layer
asynchronous, or at least constrain it to local file resources and
standardise on the use of nsscache.
This is something that could be discussed after fixing up the current synchronous API.
Or use this effort to re implement a switched name service
lookup library, including DNS aspect, outside of glibc.
Also worth discussing later.
Cheers,
Pavel