#getaddrinfo — Public Fediverse posts

Как Linux врет вам про DNS

Однажды ты запускаешь dig домен_нейм , видишь исчерпывающий ответ, идешь дальше, а твой процесс резолвит что-то другое. Не таймаут, не сеть, не кэш. Просто твой процесс и твой dig живут в двух параллельных вселенных, и обе называются “резолвинг имени”. В статье разберем шесть конкретных мест, где система нагло и молча врет: от /etc/hosts до RFC 6724 и gai.conf, из-за которых прод стучится в мертвый IPv6. Узнаем почему статический Go-бинарник живёт в отдельной резолвинг-реальности, и посмотрим на тулзу, которую пришлось написать, чтобы больше не собирать все это руками из dig + getent + resolvectl. Полюбопытствовать

https://habr.com/ru/articles/1069476/

#dns #nsswitchconf #getaddrinfo #linux #systemdresolved #mdns #nss #rust #cli #open_source

@josephholsten The IMHO interesting bit about #getaddrinfo is, you can still run into other problems, like I did with my own socket and resolving code.

When trying to use it for #IRC, I found #libera always gives me a random subset of 3 records. The structure returned by getaddrinfo is a linked list, so it's easiest to walk the list and just use the first result matching what you want. Now, some of these servers seem to be "flaky" and just e.g. stall before completing the IRC protocol handshake. Trying again, you will get the *same* list again (same entries because of caching, same ordering) and end up connecting to the same flaky host.

I therefore added a blacklisting feature to my code, so I can mark a result broken in order to skip it the next time I iterate over the getaddrinfo results. 🙈

@josephholsten The IMHO interesting bit about #getaddrinfo is, you can still run into other problems, like I did with my own socket and resolving code.

When trying to use it for #IRC, I found #libera always gives me a random subset of 3 records. The structure returned by getaddrinfo is a linked list, so it's easiest to walk the list and just use the first result matching what you want. Now, some of these servers seem to be "flaky" and just e.g. stall before completing the IRC protocol handshake. Trying again, you will get the *same* list again (same entries because of caching, same ordering) and end up connecting to the same flaky host.

I therefore added a blacklisting feature to my code, so I can mark a result broken in order to skip it the next time I iterate over the getaddrinfo results. 🙈

@josephholsten This is talking conflicting goals that can't be fulfilled both at the same time. With #IPv6 being introduced in dual-stack configurations, there was the need to *at least* offer configuration for the preferred address family, so #getaddrinfo orders the results by preference/quality. It can't be random at the same time, #DNS round robin relying on the client side is dead. Regarding docs, I'm used to excellent docs on #FreeBSD, so I guess someone should add the info about ordering to its man page 😉

The way to do DNS round robin these days is to have the *server* only serve a random subset of the A and AAAA records. Sure they will be cached, but it's still giving some balancing.

@josephholsten This is talking conflicting goals that can't be fulfilled both at the same time. With #IPv6 being introduced in dual-stack configurations, there was the need to *at least* offer configuration for the preferred address family, so #getaddrinfo orders the results by preference/quality. It can't be random at the same time, #DNS round robin relying on the client side is dead. Regarding docs, I'm used to excellent docs on #FreeBSD, so I guess someone should add the info about ordering to its man page 😉

The way to do DNS round robin these days is to have the *server* only serve a random subset of the A and AAAA records. Sure they will be cached, but it's still giving some balancing.