New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IRC server connections cannot be made to both IPv4 and IPv6 #433

Open
nomis opened this Issue Jul 27, 2017 · 17 comments

Comments

Projects
None yet
5 participants
@nomis
Contributor

nomis commented Jul 27, 2017

With a single server hostname that has one A and one AAAA resource record, eggdrop 1.8.2rc2 will only ever attempt to connect to one type of address. If this times out (no response to SYN packets) then it does not retry over the other address family.

The DNS resolution code only prefers IPv4 or IPv6. It also looks like it behaves differently depending on the order of the A and AAAA responses.

nomis added a commit to nomis/eggdrop that referenced this issue Jul 27, 2017

nomis added a commit to nomis/eggdrop that referenced this issue Jul 27, 2017

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Jul 28, 2017

Collaborator

Thanks so much for reporting this, and the associated PRs! We'll look at this shortly

Collaborator

vanosg commented Jul 28, 2017

Thanks so much for reporting this, and the associated PRs! We'll look at this shortly

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Aug 4, 2017

Collaborator

Is there currently a server with DNS entries for both records where you know that one is timing out on, so I can replicate this error for additional testing? You can stop in on freenode and let us know there if you prefer. Thank you

Collaborator

vanosg commented Aug 4, 2017

Is there currently a server with DNS entries for both records where you know that one is timing out on, so I can replicate this error for additional testing? You can stop in on freenode and let us know there if you prefer. Thank you

@nomis

This comment has been minimized.

Show comment
Hide comment
@nomis

nomis Aug 4, 2017

Contributor

You can use irctest4.uuid.uk and irctest6.uuid.uk. These will connect to a freenode server (that is currently working) and Google DNS (which doesn't respond to TCP port 6667 for me).

Contributor

nomis commented Aug 4, 2017

You can use irctest4.uuid.uk and irctest6.uuid.uk. These will connect to a freenode server (that is currently working) and Google DNS (which doesn't respond to TCP port 6667 for me).

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Aug 8, 2017

Collaborator

prefer-ipv6 0:

[01:37:11] Trying server [irctest4.uuid.uk]:6667
[01:37:11] DNS Resolver: Creating new record
[01:37:11] DNS Resolver: Sent domain lookup request for "irctest4.uuid.uk".
[01:37:11] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:37:11] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:37:11] DNS Resolver: TTL: 5s
[01:37:11] DNS Resolver: TYPE: AAAA: IP6 Address
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "d.ns.uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "c.ns.uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "p.ns.uuid.uk"
[01:37:11] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:4)
[01:37:11] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:37:11] DNS Resolver: TTL: 5s
[01:37:11] DNS Resolver: TYPE: A: host address
[01:37:11] DNS Resolver: Lookup successful: irctest4.uuid.uk
[01:37:11] DNS resolved irctest4.uuid.uk to 130.239.18.119
[01:36:40] Trying server [irctest6.uuid.uk]:6667
[01:36:40] DNS Resolver: Creating new record
[01:36:40] DNS Resolver: Sent domain lookup request for "irctest6.uuid.uk".
[01:36:40] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:36:40] DNS Resolver: answered domain query: "irctest6.uuid.uk"
[01:36:40] DNS Resolver: TTL: 5s
[01:36:40] DNS Resolver: TYPE: A: host address
[01:36:40] DNS Resolver: Lookup successful: irctest6.uuid.uk
[01:36:40] DNS resolved irctest6.uuid.uk to 8.8.8.8

prefer-ipv6 1

[01:38:43] Trying server [irctest4.uuid.uk]:6667
[01:38:43] DNS Resolver: Creating new record
[01:38:43] DNS Resolver: Sent domain lookup request for "irctest4.uuid.uk".
[01:38:43] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:38:43] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:38:43] DNS Resolver: TTL: 5s
[01:38:43] DNS Resolver: TYPE: AAAA: IP6 Address
[01:38:43] DNS Resolver: Lookup successful: irctest4.uuid.uk
[01:38:43] DNS resolved irctest4.uuid.uk to 2001:4860:4860::8888
[01:38:15] Trying server [irctest6.uuid.uk]:6667
[01:38:15] DNS Resolver: Creating new record
[01:38:15] DNS Resolver: Sent domain lookup request for "irctest6.uuid.uk".
[01:38:15] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:4)
[01:38:15] DNS Resolver: answered domain query: "irctest6.uuid.uk"
[01:38:15] DNS Resolver: TTL: 5s
[01:38:15] DNS Resolver: TYPE: AAAA: IP6 Address
[01:38:15] DNS Resolver: Lookup successful: irctest6.uuid.uk
[01:38:15] DNS resolved irctest6.uuid.uk to 2001:6b0:e:2a18::118
Collaborator

vanosg commented Aug 8, 2017

prefer-ipv6 0:

[01:37:11] Trying server [irctest4.uuid.uk]:6667
[01:37:11] DNS Resolver: Creating new record
[01:37:11] DNS Resolver: Sent domain lookup request for "irctest4.uuid.uk".
[01:37:11] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:37:11] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:37:11] DNS Resolver: TTL: 5s
[01:37:11] DNS Resolver: TYPE: AAAA: IP6 Address
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "d.ns.uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "c.ns.uuid.uk"
[01:37:11] DNS Resolver: answered domain query: "p.ns.uuid.uk"
[01:37:11] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:4)
[01:37:11] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:37:11] DNS Resolver: TTL: 5s
[01:37:11] DNS Resolver: TYPE: A: host address
[01:37:11] DNS Resolver: Lookup successful: irctest4.uuid.uk
[01:37:11] DNS resolved irctest4.uuid.uk to 130.239.18.119
[01:36:40] Trying server [irctest6.uuid.uk]:6667
[01:36:40] DNS Resolver: Creating new record
[01:36:40] DNS Resolver: Sent domain lookup request for "irctest6.uuid.uk".
[01:36:40] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:36:40] DNS Resolver: answered domain query: "irctest6.uuid.uk"
[01:36:40] DNS Resolver: TTL: 5s
[01:36:40] DNS Resolver: TYPE: A: host address
[01:36:40] DNS Resolver: Lookup successful: irctest6.uuid.uk
[01:36:40] DNS resolved irctest6.uuid.uk to 8.8.8.8

prefer-ipv6 1

[01:38:43] Trying server [irctest4.uuid.uk]:6667
[01:38:43] DNS Resolver: Creating new record
[01:38:43] DNS Resolver: Sent domain lookup request for "irctest4.uuid.uk".
[01:38:43] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:3)
[01:38:43] DNS Resolver: answered domain query: "irctest4.uuid.uk"
[01:38:43] DNS Resolver: TTL: 5s
[01:38:43] DNS Resolver: TYPE: AAAA: IP6 Address
[01:38:43] DNS Resolver: Lookup successful: irctest4.uuid.uk
[01:38:43] DNS resolved irctest4.uuid.uk to 2001:4860:4860::8888
[01:38:15] Trying server [irctest6.uuid.uk]:6667
[01:38:15] DNS Resolver: Creating new record
[01:38:15] DNS Resolver: Sent domain lookup request for "irctest6.uuid.uk".
[01:38:15] DNS Resolver: Received nameserver reply. (qd:1 an:1 ns:4 ar:4)
[01:38:15] DNS Resolver: answered domain query: "irctest6.uuid.uk"
[01:38:15] DNS Resolver: TTL: 5s
[01:38:15] DNS Resolver: TYPE: AAAA: IP6 Address
[01:38:15] DNS Resolver: Lookup successful: irctest6.uuid.uk
[01:38:15] DNS resolved irctest6.uuid.uk to 2001:6b0:e:2a18::118
@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Aug 8, 2017

Collaborator

Thanks for setting up those DNS records to use, very smart approach for testing! You also forced me to figure out how to enable ipv6 in my vmware instances, which I'd been putting off far too long...

So now for the philosophy discussion for @thommey and @Cizzle ... let's say I have a list of IPv6 servers in my server list, some of which have dual A and AAAA records, and I have prefer-ipv6 set to 1. If connecting to the IP returned by a AAAA record fails, is it better to try the A record, or just roll to the next server in the list that has a functional IP? Now, what happens if there are multiple IPs associated with a single AAAA record? Am I supposed to iterate through all of them before moving to the next server? We don't do that now on the IPv4 side of the house, we just hit the next server in the list, which is basically what this functionality is already doing.

I think my current take on this is, the current functionality of Eggdrop is the desired functionality. I'm open to hearing otherwise, and I'm also open to seeing if there some additional setting that could be added (maybe a setting to try one IP from both records if two are returned?)... but I'm just not seeing this use case as sufficient to override current functionality of 'try one, then move on to the next entry'.

Collaborator

vanosg commented Aug 8, 2017

Thanks for setting up those DNS records to use, very smart approach for testing! You also forced me to figure out how to enable ipv6 in my vmware instances, which I'd been putting off far too long...

So now for the philosophy discussion for @thommey and @Cizzle ... let's say I have a list of IPv6 servers in my server list, some of which have dual A and AAAA records, and I have prefer-ipv6 set to 1. If connecting to the IP returned by a AAAA record fails, is it better to try the A record, or just roll to the next server in the list that has a functional IP? Now, what happens if there are multiple IPs associated with a single AAAA record? Am I supposed to iterate through all of them before moving to the next server? We don't do that now on the IPv4 side of the house, we just hit the next server in the list, which is basically what this functionality is already doing.

I think my current take on this is, the current functionality of Eggdrop is the desired functionality. I'm open to hearing otherwise, and I'm also open to seeing if there some additional setting that could be added (maybe a setting to try one IP from both records if two are returned?)... but I'm just not seeing this use case as sufficient to override current functionality of 'try one, then move on to the next entry'.

@orkim

This comment has been minimized.

Show comment
Hide comment
@orkim

orkim Aug 8, 2017

In the case of multiple IPv4/IPv6 entries and 'prefer-ipv6' set: I would vote for trying the servers first IPv6 address and then rolling to the next server entry in the server list. Each entry should try the first IPv6 address returned. In the case only IPv4 entries are returned it should fall back to using the IPv4 entry.

In the case of multiple IPv4/IPv6 entries and 'prefer-ipv6' not set: I would vote for trying the servers first IPv4 address and then rolling to the next server entry in the server list.

If there is only IPv4 or IPv6 addresses returned then the choice is already made for you, just try the first address.

I believe this would be in the spirit of multiple entries for doing round-robin DNS entries. Whoever maintains the DNS should probably pay more attention and keep their DNS entries updated.

Just my $0.02

orkim commented Aug 8, 2017

In the case of multiple IPv4/IPv6 entries and 'prefer-ipv6' set: I would vote for trying the servers first IPv6 address and then rolling to the next server entry in the server list. Each entry should try the first IPv6 address returned. In the case only IPv4 entries are returned it should fall back to using the IPv4 entry.

In the case of multiple IPv4/IPv6 entries and 'prefer-ipv6' not set: I would vote for trying the servers first IPv4 address and then rolling to the next server entry in the server list.

If there is only IPv4 or IPv6 addresses returned then the choice is already made for you, just try the first address.

I believe this would be in the spirit of multiple entries for doing round-robin DNS entries. Whoever maintains the DNS should probably pay more attention and keep their DNS entries updated.

Just my $0.02

@nomis

This comment has been minimized.

Show comment
Hide comment
@nomis

nomis Aug 8, 2017

Contributor

Regardless of the order, it must attempt to use all of the A/AAAA responses for each hostname.

One way to do that would be to retain a cache of most recently attempted IP addresses and prefer ones that have not been attempted recently.

Contributor

nomis commented Aug 8, 2017

Regardless of the order, it must attempt to use all of the A/AAAA responses for each hostname.

One way to do that would be to retain a cache of most recently attempted IP addresses and prefer ones that have not been attempted recently.

@thommey

This comment has been minimized.

Show comment
Hide comment
@thommey

thommey Aug 8, 2017

Member

We have an open issue to use round robins properly -> #204
I think that requires a more extensive rewrite of dns.mod (it should really store all responses, not just lookup again and rely on it rotating to something it didn't already try)

Member

thommey commented Aug 8, 2017

We have an open issue to use round robins properly -> #204
I think that requires a more extensive rewrite of dns.mod (it should really store all responses, not just lookup again and rely on it rotating to something it didn't already try)

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Aug 8, 2017

Collaborator

"Regardless of the order, it must attempt to use all of the A/AAAA responses for each hostname."

Why "must" it attempt to use all responses for each hostname?

Collaborator

vanosg commented Aug 8, 2017

"Regardless of the order, it must attempt to use all of the A/AAAA responses for each hostname."

Why "must" it attempt to use all responses for each hostname?

@thommey

This comment has been minimized.

Show comment
Hide comment
@thommey

thommey Aug 8, 2017

Member

because most ircds have a single irc.network.org round robin containing all server IPs and it makes sense to go through all of them if the bot is k-lined on only a few of them, or exceeds the local connection limit on that server (IRCnet has a ton of servers that simply don't allow countries other than their own, etc.)

Member

thommey commented Aug 8, 2017

because most ircds have a single irc.network.org round robin containing all server IPs and it makes sense to go through all of them if the bot is k-lined on only a few of them, or exceeds the local connection limit on that server (IRCnet has a ton of servers that simply don't allow countries other than their own, etc.)

@vanosg

This comment has been minimized.

Show comment
Hide comment
@vanosg

vanosg Aug 8, 2017

Collaborator
Collaborator

vanosg commented Aug 8, 2017

@nomis

This comment has been minimized.

Show comment
Hide comment
@nomis

nomis Aug 8, 2017

Contributor

It is a "must" but there are a lot of ways to implement that behaviour, including randomly picking one IP from all responses for a hostname (which I think it currently does as long as the responses from the resolver aren't always in the same order). It will eventually try all of them.

Contributor

nomis commented Aug 8, 2017

It is a "must" but there are a lot of ways to implement that behaviour, including randomly picking one IP from all responses for a hostname (which I think it currently does as long as the responses from the resolver aren't always in the same order). It will eventually try all of them.

@Pixelz

This comment has been minimized.

Show comment
Hide comment
@Pixelz

Pixelz Aug 9, 2017

Collaborator

The problem with trying both A and AAAA records is that it only applies in situations where both addresses resolve to the same hostname. Most commercial shell account providers for instance have different sets of vhosts for v4 and v6. Users need to be able to bind Eggdrop to either of them and have it show up on IRC with the expected vhost.

Arbitrarily picking IP versions to use based on DNS responses might be a desirable in most situations but for IRC my feeling is that it would confuse people more than it would help.

Collaborator

Pixelz commented Aug 9, 2017

The problem with trying both A and AAAA records is that it only applies in situations where both addresses resolve to the same hostname. Most commercial shell account providers for instance have different sets of vhosts for v4 and v6. Users need to be able to bind Eggdrop to either of them and have it show up on IRC with the expected vhost.

Arbitrarily picking IP versions to use based on DNS responses might be a desirable in most situations but for IRC my feeling is that it would confuse people more than it would help.

@nomis

This comment has been minimized.

Show comment
Hide comment
@nomis

nomis Aug 9, 2017

Contributor

That just means that you need to have two bind addresses for outgoing connections, one for IPv4 and one for IPv6. If you can't supply both then you can't use both address families.

Contributor

nomis commented Aug 9, 2017

That just means that you need to have two bind addresses for outgoing connections, one for IPv4 and one for IPv6. If you can't supply both then you can't use both address families.

@Pixelz

This comment has been minimized.

Show comment
Hide comment
@Pixelz

Pixelz Aug 9, 2017

Collaborator

Consider this scenario; you're on a system with multiple v4 and v6 hosts. All of them unique. You configure Eggdrop with vhost4/vhost6 unset but you enable prefer-ipv6. Eggdrop would pick the first available v6 address and use that. Some time later Eggdrop reconnects to IRC. It can't connect to the v6 address for one of the servers in the server list and falls back to v4. Resulting in Eggdrop joining IRC with a different vhost.

Collaborator

Pixelz commented Aug 9, 2017

Consider this scenario; you're on a system with multiple v4 and v6 hosts. All of them unique. You configure Eggdrop with vhost4/vhost6 unset but you enable prefer-ipv6. Eggdrop would pick the first available v6 address and use that. Some time later Eggdrop reconnects to IRC. It can't connect to the v6 address for one of the servers in the server list and falls back to v4. Resulting in Eggdrop joining IRC with a different vhost.

@nomis

This comment has been minimized.

Show comment
Hide comment
@nomis

nomis Aug 9, 2017

Contributor

So add a new setting for people who want to use DNS properly by removing the restriction on one address family. I can't imagine anyone using eggdrop who would not want to take advantage of both IPv4 and IPv6 connectivity to IRC networks.

Contributor

nomis commented Aug 9, 2017

So add a new setting for people who want to use DNS properly by removing the restriction on one address family. I can't imagine anyone using eggdrop who would not want to take advantage of both IPv4 and IPv6 connectivity to IRC networks.

@Pixelz

This comment has been minimized.

Show comment
Hide comment
@Pixelz

Pixelz Aug 9, 2017

Collaborator

Sounds good to me. If Eggdrop ever moves to try connecting to v6 by default it should probably fall back to v4 automatically by default as well.

Collaborator

Pixelz commented Aug 9, 2017

Sounds good to me. If Eggdrop ever moves to try connecting to v6 by default it should probably fall back to v4 automatically by default as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment