DNS lookup only chooses the first IP address in list. [$10 awarded] #71

New Issue

2026-10-05T03:57:06+02:00

adam commented

2026-10-05 03:57:06 +02:00

When connecting to irc.efnet.org, it has many IP addresses. Some which works, some that don't work. Because I have IPv6, it only looked at the available IPv6 Addresses and only connected to the top one in the list which does not respond. It takes about 1 minute, and than times out and tries again with the same IP Address. This is not good, because it always picks that one IP at the top and doesn't continue down the list to find a working IP Address or switch back to IPv4 in-case there is a problem with IPv6. I have manually fixed this for me by grabbing the second IP Address list and putting it in-place of the domain.

The $10 bounty on this issue has been claimed at Bountysource.

When connecting to irc.efnet.org, it has many IP addresses. Some which works, some that don't work. Because I have IPv6, it only looked at the available IPv6 Addresses and only connected to the top one in the list which does not respond. It takes about 1 minute, and than times out and tries again with the same IP Address. This is not good, because it always picks that one IP at the top and doesn't continue down the list to find a working IP Address or switch back to IPv4 in-case there is a problem with IPv6. I have manually fixed this for me by grabbing the second IP Address list and putting it in-place of the domain. ## <bountysource-plugin> The **[$10 bounty](https://www.bountysource.com/issues/686-dns-lookup-only-chooses-the-first-ip-address-in-list?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** on this issue has been claimed at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github). </bountysource-plugin>

adam closed this issue

2026-10-05 03:57:06 +02:00

adam commented

2026-10-05 03:57:07 +02:00

Which znc version are you using? Does it use c-ares for resolving? (Can be figured out via '/msg *status version')

Latest git might not have this issue since it stopped using c-ares for DNS.

Which znc version are you using? Does it use c-ares for resolving? (Can be figured out via '/msg *status version') Latest git might not have this issue since it stopped using c-ares for DNS.

adam commented

2026-10-05 03:57:08 +02:00

<_status> ZNC 0.205 - http://znc.in
<_status> IPv6: yes, SSL: yes, dns: threads

I have revision 140d83e.

<_status> ZNC 0.205 - http://znc.in <_status> IPv6: yes, SSL: yes, dns: threads I have revision 140d83e.

adam commented

2026-10-05 03:57:09 +02:00

+1, i am seeing this as well.

ZNC 1.0+deb5 - http://znc.in
IPv6: yes, SSL: yes, DNS: threads

+1, i am seeing this as well. <status> ZNC 1.0+deb5 - http://znc.in <status> IPv6: yes, SSL: yes, DNS: threads

adam commented

2026-10-05 03:57:09 +02:00

This bit me HARD today

This bit me HARD today

adam commented

2026-10-05 03:57:10 +02:00

my ZNC build is from the past 3 months. I
ZNC 1.2 - http://znc.in IPv6: yes, SSL: yes, DNS: threads

my ZNC build is from the past 3 months. I ` ZNC 1.2 - http://znc.in IPv6: yes, SSL: yes, DNS: threads `

adam commented

2026-10-05 03:57:10 +02:00

That one did bite me today too. I updated to the latest version but that did not solve the problem apparently.
znc -v:
ZNC 1.4 - http://znc.in
IPv6: yes, SSL: yes, DNS: threads

This is especially bad when using a network which has multiple domains resolving to the same, multiple, IPv6 addresses. This renders the whole server-jumping useless because ZNC always picks the same, non-working, IPs instead of a bunch of other ones.
I now had to manually set an IP as the connect host, what can not be a solution.

That one did bite me today too. I updated to the latest version but that did not solve the problem apparently. znc -v: ZNC 1.4 - http://znc.in IPv6: yes, SSL: yes, DNS: threads This is especially bad when using a network which has multiple domains resolving to the same, multiple, IPv6 addresses. This renders the whole server-jumping useless because ZNC always picks the same, non-working, IPs instead of a bunch of other ones. I now had to manually set an IP as the connect host, what can not be a solution.

adam commented

2026-10-05 03:57:11 +02:00

[09:30:33] <Mikaela> I got affected by the DNS issue by the way. I had specified two round-robins without thinking that ZNC would resolve them both to same IP and when th at went down, I was also down for some time.

> `[09:30:33] <Mikaela> I got affected by the DNS issue by the way. I had specified two round-robins without thinking that ZNC would resolve them both to same IP and when th > at went down, I was also down for some time.`

adam commented

2026-10-05 03:57:12 +02:00

:/ i'm going to me-too this.

:/ i'm going to me-too this.

adam commented

2026-10-05 03:57:12 +02:00

This issue should probably be fixed soon as 1.5 which will be 1.6 checks SSL certificates and this bug forces people to connect IP addresses instead of domain names which makes the certificates invalid (by being for domains names instead of IP addresses) which in turn makes all networks which have valid certificates require adding the certificate SHA-256 by hand.

This issue should probably be fixed soon as 1.5 which will be 1.6 checks SSL certificates and this bug forces people to connect IP addresses instead of domain names which makes the certificates invalid (by being for domains names instead of IP addresses) which in turn makes all networks which have valid certificates require adding the certificate SHA-256 by hand.

adam commented

2026-10-05 03:57:13 +02:00

The issue descriped in my previous comment happened to me with irc.yolo-swag.com +6697. They apparently have valid self-signed certificate, but ZNC thought it as invalid as I am forced to connect to IP addresses directly when ZNC fails to connect to working server using the round robin. This will most likely affect many other people too as the current recommended workaround to this issue is to use IP addresses directly. irc.yolo-swag.com operators don't recognize the difference between valid and self-signed certificates.

@DarthGandalf said something at IRC earlier about temporary fix by resolving to fully random address if I recall correctly.

~~The issue descriped in my previous comment happened to me with `irc.yolo-swag.com +6697`. They apparently have valid self-signed certificate, but ZNC thought it as invalid as I am forced to connect to IP addresses directly when ZNC fails to connect to working server using the round robin. This will most likely affect many other people too as the current recommended workaround to this issue is to use IP addresses directly.~~ `irc.yolo-swag.com` operators don't recognize the difference between valid and self-signed certificates. @DarthGandalf said something at IRC earlier about temporary fix by resolving to fully random address if I recall correctly.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/znc#71