AF_INET6 link-local addresses in getaddrinfo

[Petr Menšík]

I think the whole problem is somewhere else. We should not be asking for 
IPv6 addresses, when we are only on IPv4 only network, and have only 
link-local addresses on interfaces and one ::1 on localhost. It does not 
make any sense to ask AAAA even with AF_UNSPEC, because most 
applications will fail when trying it first. And very similar if we are 
on IPv6 only network and have no IPv4 route except localhost, why are we 
asking for A records even?

I think putting mapped IPv4 addresses into AAAA record is a trick to 
make negative answers for AAAA records small(er). It obviously does not 
try to provide working IPv6 address, but replies with *smaller* response 
than DNSSEC enabled response saying no such record exist. Because on 
NSEC3 signed zone it contains 3 signatures, not just one positive bogus 
response gets. I think instead we should send queries only when they 
make sense to reduce unnecessary traffic. But that is long term goal.

I filled https://sourceware.org/bugzilla/show_bug.cgi?id=30544 bug for 
that and even made some initial attempt, but haven't got very far. I 
think long term solution is to make DNS queries only when global route 
of that address family exists and is not localhost. Because DNS packet 
AAAA record cannot contain scope_id anyway, it does not work with link 
local addresses. Without strong relation to interface dns plugin cannot 
reasonably use link-local addresses in DNS responses, especially not 
service listening on localhost.

My idea is that AF_UNSPEC would be by default used by nss-dns plugin 
only for families with non-localhost global addresses. Even typical ping 
has to fail first time in strace, if you are pinging dual-stack name on 
single stack IPv4 machine. Daemons like Network Manager could indicate 
in /etc/resolv.conf, what families are available on the host. That would 
allow omitting AI_ADDRCONFIG extra work per each resolution. Just 
monitoring of changing /etc/resolv.conf would be needed and I think that 
is already implemented.

But of course for mDNS or LLMNR multicast scopes are very important and 
should be possible on any AF used in hint. Would it be possible as a 
workaround to use nss_gethostbyname4_r and just filter out IPv4 
addresses from the result?

BTW: fe80::b2f:65c5:d743:524b%enp9s0u1 eth.local store in /etc/hosts is 
not supported also. Could it be expanded in nss-files module too, 
eventually?

But for my idea described, I think I would need also gaih_addrtuple 
structure result *and* single AF specified. Therefore 
nss_gethostbyname5_r probably? It would be useful if the updated call 
could be used also on unix domain sockets. Since it does not use struct 
sockaddr directy, this interface would not work well with AF_LOCAL 
sockets, right?

I think domain sockets would be quite useful for local caching service, 
because it would be able to apply rules on network access. It could know 
which program and which user is asking some query. It could refuse 
access to some zones to selected users or services. SO_PEERCRED and 
SO_PEERSEC would be quite useful from cache side. Can the new interface 
be generic enough to store also sockaddr_un? Probably with explicitly 
given size of a real socket address size, which might not be large enough?

struct addrinfo has already ai_addrlen and ai_addr. Why is not worked 
with that from in plugin calls directly? Why does it define own 
gaih_addrtuple structure?

Maybe higher complexity response, allowing canonical name, would be 
better. Especially for adding libc support for HTTPS RR query, which has 
generic key=val arguments. And we have extra information omitted from 
user even now. User cannot get TTL from API for example. If he wants to 
cache in application (like browsers do), needs to implement every 
protocol separately. More generic API could include more information, if 
requested. Protocol independent.

Regards, Petr

On 19. 11. 24 21:08, Ronan Pigott wrote:
> This has come up again recently

-- 
Petr Menšík
Senior Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241121/fdec26fa/attachment-0001.htm>