View Issue Details

IDProjectCategoryView StatusLast Update
0002481unrealircdpublic2006-04-09 18:03
Reporteryoann Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
OSFreeBSD/Linux 
Product Version3.2.3 
Fixed in Version3.2.4 
Summary0002481: IPv4 and IPv6 addresses for same DNS don't get resolved properly
DescriptionWhen, from a dual stack machine (IPv4 and IPv6), two clients connect to the same server, one over IPv4 and the other one over IPv6, only the first one gets properly reverse resolved, if the reverse DNS is the same for both the IPv4 and IPv6 address.
Steps To ReproduceExample:
Client:
DNS: foo.zone.org
IPv4 address: 10.0.0.2
IPv6 address: 2002::dead:beef:2

Server: ircd.zone.org

Client side: /connect -4 ircd.zone.org
Server side: Client connecting [...]: [email protected]
Client side: /connect -6 ircd.zone.org
Server side: Client connecting [...]: user@2002::dead:beef:2

and vice versa (first /connect -6 then -4)
TagsNo tags attached.
3rd party modules

Activities

yoann

2005-04-19 06:02

reporter   ~0009781

I just tried to understand how the dns cache was filled in.
For this I also tried with 2 IPv4 and 2 IPv6 addresses for the same DNS.

As far as I understood when I connect with my first IPv4 address:
- this IP gets first reverse resolved (gethost_byaddr, do_query_number),
- then the DNS found gets resolved too (do_revquery_name) (with a A query)
- and the 2 IPv4 addresses found for this DNS are stored in the dns cache
Then, when I connect to the same server with my second IPv4 address, this latter is already in the cache, associated with the right DNS, so it is properly resolved.

(The scenario is the same with my 2 IPv6 addresses, except a AAAA query is used instead of the A query)

Now, when I first connect with my IPv4 address and then with my IPv6 address, for the latter connection (the scenario is the same as above for the first IPv4 connection):
- the IPv6 address gets reverse resolved (gethost_byaddr, do_query_number),
- the DNS found is already in the dns cache (find_cache_name) (but the DNS is only associated in the cache with the IPv4 addresses found during the first connection with my IPv4 address),
- so nothing else is done
But then user->realhost does not contain the DNS as it should, since my IPv6 address is not in the cache.

I hope I am not mistaking and this makes my problem clearer.
Thank you for your attention.
Cordially,
yoann

yoann

2005-04-19 06:59

reporter   ~0009782

I mean (if I am not mistaking), once we get the DNS, couldn't we look for both IPv4 and IPv6 addresses and put them all in the DNS cache?

aquanight

2005-04-19 11:26

reporter   ~0009784

There's a way to find it out if what you suggest (DNS cache) is indeed the cause: connect with IPv4, then /quote DNS c (as an IRCop) to clear the DNS cache, then connect with IPv6.

yoann

2005-04-19 11:51

reporter   ~0009785

Indeed, as expected, when I first connect with IPv4, then clear the DNS cache (with /quote DNS c), and finally connect with IPv6, my IPv6 address gets properly resolved.
I hope that gets you any further.

RegisGautier

2005-12-13 13:06

reporter   ~0010864

I'm having exactly the same problem and as all the users on my network have
an ipv4 and an ipv6 resolving to the same DNS, it's very annoying.

Is there any plan to fix that ?

adn

2005-12-13 13:22

reporter   ~0010865

Last edited: 2005-12-24 15:01

My 100+ users are very annoyed by this bug, some of my hubs being on a fully functionnal ipv6 network. There is no way to work with bots, to become oper with an unresolved reverse!

Please fix it as soon as possible, you're the best!

syzop

2006-04-09 18:03

administrator   ~0011501

Hm, I forgot to close this. This was resolved in 3.2.4 a few months ago when we switched to the c-ares resolver (well, it was fixed earlier in CVS of course).

Issue History

Date Modified Username Field Change
2005-04-13 13:08 yoann New Issue
2005-04-19 06:02 yoann Note Added: 0009781
2005-04-19 06:59 yoann Note Added: 0009782
2005-04-19 11:26 aquanight Note Added: 0009784
2005-04-19 11:51 yoann Note Added: 0009785
2005-12-13 13:06 RegisGautier Note Added: 0010864
2005-12-13 13:22 adn Note Added: 0010865
2005-12-24 15:01 adn Note Edited: 0010865
2006-04-09 18:03 syzop Status new => resolved
2006-04-09 18:03 syzop Fixed in Version => 3.2.4
2006-04-09 18:03 syzop Resolution open => fixed
2006-04-09 18:03 syzop Assigned To => syzop
2006-04-09 18:03 syzop Note Added: 0011501