Skip Menu |

This queue is for tickets about the Net-DNS CPAN distribution.

Report information
The Basics
Id: 11931
Status: resolved
Priority: 0/
Queue: Net-DNS

People
Owner: OLAF [...] cpan.org
Requestors: risto.kankkunen [...] f-secure.com
Cc: hanno.stock [...] gmx.net
AdminCc:

Bug Information
Severity: Important
Broken in: 0.48
Fixed in: (no value)



Subject: Wrong nameserver list handling in Net::DNS::Resolver::Win32
I had problems getting SpamAssassin RBL queries working on a Windows 2003 server: all I got was timeouts. However, doing any of the queries manually with nslookup worked just fine. And I had SpamAssassin working OK in other Windows servers. It turned out that Net::DNS::Resolver was using a list of two nameservers, and the 2nd one was the one that should have been used. Since SpamAssassin issues asynchronous queries with bgsend(), only the first item was used, SpamAssassin could not get any replies from it and all the queries failed in a timeout. What I'm wondering now, is if the logic in Net::DNS::Resolver::Win32 is correct, when it builds the nameservers list default (see init(), especially lines 54-90). The unwanted entry was found from the registry branch [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DNSRegisteredAdapters\{184B6DCE-9C8B-4405-BDF4-40968CB59FAB}] and the correct one from [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{184B6DCE-9C8B-4405-BDF4-40968CB59FAB}] I wonder, whether you should look for DNSRegisteredAdapters branch at all. I didn't find too much documentation about this branch, but what there is seems to indicate that it is used for dynamic DNS to configure what server the adapter is registered to, not what server to query. See http://support.microsoft.com/default.aspx?scid=kb;en-us;254031 Furthermore, "ipconfig /all" and "netsh interface ip show dns" show only one entry in "DNS Servers", and that is the second one in Win32's list. There is no mention of the address of the first entry in ipconfig or netsh output. My hunch at the moment is that DNSRegisteredAdapters should not be used when building the nameserver list. An additional issue is that at the moment the code doesn't seem to pay any attention to the interface order. It seems that the keys in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage] control the order the interfaces should be looked up. At least changing the connections order in "Network Connections | Advanced | Advanced Settings..." affects these keys.
I found out that the problematic code comes from a fix to 2533. Initially there was just a small patch to add support for DhcpNameServer key. Then the fix expanded to include fix for 2465, too. The final fix includes the original fix, some support for Windows9x, fix to iterate all Interfaces (closing 2465) and then the problematic part of DNSServerAddresses value of the DNSRegisteredAdapters key. It is unclear to me, what prompted the inclusion of that new problematic logic, and it is definitely wrong in the server configuration I stumbled upon.
Show quoted text
> An additional issue is that at the moment the code doesn't seem to pay > any attention to the interface order. It seems that the keys in > [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage] > control the order the interfaces should be looked up. At least > changing the connections order in "Network Connections | Advanced | > Advanced Settings..." affects these keys.
Just to delve into this particular point. There are multiple keys in for the Linkage path. Which one to choose? What are the different meanings.
Win32.pm used the DNSRegisteredAdapters registry key to determine which local forwarders to send queries to. This is arguably the wrong key as it is used to identify the server which to send dynamic updates to. I have therefore commented out the "broken" code fragment. It has been committed to the trunk and will appaear in 0.48_03 shortly. This will prevent errournous nameservers in the list (as are the problem for Risto) but does not provide us with a reliable method to obtain the set of nameservers. As Michiel de Bruijn pointed out that the registry settings are not a reliable way of getting this information. They have a different layout for different Microsoft OS-es and the keys used differ between a DHCP and a static configured environment. Besides the configuration is interface based and one cannot determine which interfaces are in use so one might end up with a bunch of cruft. The reliable way to get the information is through the getNetworkParams() API call in IpHlpApi.dll. That call works as off 95-met-de-WINSOCK2-fix. (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getnetworkparams.asp) One could probably call this function through the use of Win32::API, the getNetworkParams function is similar to calls in Win32::IPhelper. Unfortunattelly this is where I get stuck. I cannot get Win32::API installed on Cygwin and I also do not have much success in with ActivePerl. That breaks portability pretty much. I'll stall this ticket in the hope Win32::API gets fixed or somebody has some spare time to provide an XS interface to getNetworParam that is portable.
From: Sidney
Here's a patch that fixes the most common version of the problem that I see that you can implement before getting the ideal fix describedd above. I am in the process of fixing SpamAssassin 3.1 trunk so it is not so vulnerable to these problems. While looking at it I found a small patch to Net::DNS::Resolver that will make a big difference. In Windows XP and later, the code is going through the list of network interfaces in the registry and gathering a list of nameservers. The biggest problem I'm seeing is registry entries for nameservers for inactive network interfaces. For example, when I unplug my laptop from the wired network and use a wireless card, Net::DNS::Resolver still sees the nameserver address that had been assigned by DHCP on the wired network and puts that first. The fix is simple: When getting the list of nameservers also get the IPAddress key for the interface and if it is equal to "0.0.0.0" do not add the nameserver to the list. In Cygwin.pm the patched code section looks like my $ns; my $ip; $ip = getregkey($regiface, "IPAddress"); $ns = getregkey($regiface, "NameServer") || getregkey($regiface, "DhcpNameServer") || '' unless !$ip || ($ip =~ /0\.0\.0\.0/); $nameservers .= " $ns" if $ns; In Win32.pm it looks like if ($regiface) { my $ns; my $type; my $ip; $regiface->QueryValueEx("IPAddress", $type, $ip); if ($ip && !($ip =~ /0\.0\.0\.0/)) { # NameServer overrides DhcpNameServer if both exist $regiface->QueryValueEx("NameServer", $type, $ns); $regiface->QueryValueEx("DhcpNameServer", $type, $ns) unless $ns; $nameservers .= " $ns" if $ns; } } My contact address is at my personal web site http://www.sidney.com
[guest - Thu Apr 28 06:00:17 2005]: Show quoted text
> In Windows XP and later, the code is going through the list of network > interfaces in the registry and gathering a list of nameservers.
How portable is your fix to older versions of MS OSs like Win2000? I have no way of testing... --Olaf
RT-Send-CC: sidney [...] sidney.com,
[guest - Thu Apr 28 06:00:17 2005]: Show quoted text
> Here's a patch that fixes the most common version of the problem that I > see that you can implement before getting the ideal fix describedd above.
After having concentrated on a few other things I am now about to launch 0.49_1 and have just applied this patch to the trunk on http://www.net-dns.org/svn/net-dns/trunk/ I would appreciate if you guys, that use Net::DNS in production on Win32 based systems would give it a go. Show quoted text
> I am in the process of fixing SpamAssassin 3.1 trunk so it is not so > vulnerable to these problems. While looking at it I found a small patch > to Net::DNS::Resolver that will make a big difference. >
What is the approach to fixing this in SpamAssassin? I reckon SpamAssassin will remain dependend on Net::DNS? Thanks for the contribution. --Olaf
From: Sidney Markowitz
[OLAF - Sat May 21 03:44:41 2005]: Show quoted text
> What is the approach to fixing this in SpamAssassin? I reckon > SpamAssassin will remain dependend on Net::DNS?
We're using bgsend to let DNS queries get sent off at the beginning of processing a message, then harvest the replies after all other processing is done. That made the code very vulnerable to the first nameserver in the list being wrong. This patch fixes one way it could be wrong, but SpamAssassin was still vulnerable if, for example, the first nameserver in the list happened to be really down. The approach I use is a test at initialization time that loops doing a background query, if it fails popping the first element off the nameservers list and trying the query again. This ensures that the first element of nameservers works, at least at the time of that initial test. If the nameservers list empties before any query succeeds, then we flag that DNS is disabled and don't do any more DNS stuff. The code is at http://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Dns.pm and search for the string 'nameservers' (without quotes). -- Sidney Markowitz http://www.sidney.com/
From: Sidney Markowitz
[OLAF - Thu Apr 28 09:02:56 2005]: Show quoted text
> How portable is your fix to older versions of MS OSs like Win2000? > I have no way of testing...
I don't have a convenient way of testing it, but the patch can't have any negative effect. It won't be executed unless the registry contains those entries. I think that's Windows XP or later. But in any case, all it is doing is ignoring an entry that has an ip address of 0.0.0.0. That can never be a valid active network connection, so if the code gets executed it will always be correct to ignore that entry. Sidney Markowitz http://www.sidney.com/
From: Sidney Markowitz
Olaf, I'm not sure if this should be in a separate bug report, but I found what I think is a bug in send_udp while looking at code related to this. In Net::DNS::Resolver::Base->send_udp the code contains nested loops, the outer one looping through all the nameservers, the inner loop processing replies from the nameserver, looking like this (in pseudo code): loop through all nameservers @ready = $sel->can_read($timeout) # wait for replies or timeout loop through the received packets skip over any packets with qr not set or wrong ID end inner loop end outer loop The problem I'm seeing is that it is not uncommon for a query to a nameserver to time out before the reply comes back, then there is another query from the same UDP port, then the first reply arrives. If, as is usually the case, the ID of the old reply doesn't match the ID of the second query, the reply packet is rejected (which is correct) but the inner loop exits never having received the real reply. That causes the real reply to be dropped. Actually it makes it more likely that the real reply will show up when there is a listener to yet another query, causing that one to be lost and the cycle continues. The symptom is that in a high volume situation some DNS queries are getting a 'query timed out' error before the timeout period has passed. My ISP is seeing that happen regularly, in perhaps 0.1% of the queries in something that they are running. The fix would be to keep running the inner loop until either a packet for the right query is received (as determined by the ID) or the timeout. In pseudocode that could be loop through all nameservers my $found_reply = FALSE; until ($found_reply || timed out) { @ready = $sel->can_read($timeout) # wait for replies or timeout loop through the received packets skip over any packets with qr not set or wrong ID $found_reply = TRUE; end inner loop } # end the until loop end outer loop Sidney Markowitz http://www.sidney.com/
From: Sidney Markowitz
Slight correction to my pseudocode: Since the inner loop either skips to the next iteration of the inner loop or skips to the next iteration of the outer loop, or returns from the function, there is no need to use the $found_reply variable. You will always exit out of there if a reply is found. So you can elminate the $found_reply variable completely and just wrap the can_read and the inner loop with until (timed out) { # inner loop exits this early if it finds an answer [...] } Sidney Markowitz http://www.sidney.com/
From: Sidney Markowitz
Sorry for the multiple posts, but I see that a patch would be really simple. In send_udp just insert two lines in between my @ready = $sel->can_read($timeout); SELECTOR: foreach my $ready (@ready) { so it says my @ready = $sel->can_read($timeout); my $now = time; until ($stop_time && ($stop_time < $now)) { SELECTOR: foreach my $ready (@ready) { and add a close brace after the one that matches the foreach.
From: Sidney Markowitz
[I wrote - Wed May 25 23:25:07 2005]: Show quoted text
> my @ready = $sel->can_read($timeout); > my $now = time; > until ($stop_time && ($stop_time < $now)) { > SELECTOR: foreach my $ready (@ready) {
And of course that is a recipe for an infinite loop and should be my $now = time; until ($stop_time && ($stop_time < $now)) { my @ready = $sel->can_read($timeout); SELECTOR: foreach my $ready (@ready) {
Date: Fri, 27 May 2005 23:44:02 +0200
From: "Olaf M. Kolkman" <olaf [...] dacht.net>
To: bug-Net-DNS [...] rt.cpan.org
CC: undisclosed-recipients: ;
Subject: Re: [cpan #11931] Wrong nameserver list handling in Net::DNS::Resolver::Win32
RT-Send-Cc:
Guest via RT wrote: Show quoted text
>This message about Net-DNS was sent to you by guest <> via rt.cpan.org > >Full context and any attached attachments can be found at: ><URL: https://rt.cpan.org/Ticket/Display.html?id=11931 > > >[I wrote - Wed May 25 23:25:07 2005]: > >
>> my @ready = $sel->can_read($timeout); >> my $now = time; >> until ($stop_time && ($stop_time < $now)) { >> SELECTOR: foreach my $ready (@ready) { >> >>
> >And of course that is a recipe for an infinite loop and should be > > my $now = time; > until ($stop_time && ($stop_time < $now)) { > my @ready = $sel->can_read($timeout); > SELECTOR: foreach my $ready (@ready) { > >
Still a recipy for infinity as $now is a constant after entering the loop :-) .... but that is easilly fixed by writing until ($stop_time && ($stop_time < time)) { Still this is not the perfect solution because if you use this you will wait untill you have completely timed out all your nameservers while essentially you will have to wait untill the "$timeout" that is allocated to this particular server (which is a fraction of the $stop_time in order to allow alternative servers to be contacted as well if one fails). I think this will do my $oldpacket_timeout=time+$timeout; until ( $oldpacket_timeout && ($oldpacket_timeout < time())) { This code now lives on the trunk... --Olaf
From: Orjan
Using Net-DNS 0.53 on Win XP, it is unable to retrieve the nameservers when the IP address of the interface is assigned by DHCP. This is due to the DHCP assigned IP address being stored in DhcpIPAddress rather than IPAddress (which is then 0.0.0.0). Adding a check of DhcpIPAddress existance and not being 0.0.0.0 fixes the problem. Replace the code: Show quoted text
> > In Win32.pm it looks like > > if ($regiface) { > my $ns; > my $type; > my $ip; > $regiface->QueryValueEx("IPAddress", $type, $ip); > if ($ip && !($ip =~ /0\.0\.0\.0/)) { > # NameServer overrides DhcpNameServer if both exist > $regiface->QueryValueEx("NameServer", $type, $ns); > $regiface->QueryValueEx("DhcpNameServer", $type, $ns) unless $ns; > $nameservers .= " $ns" if $ns; > } > } >
with: if ($regiface) { my $ns; my $type; my $ip; my $ipdhcp; $regiface->QueryValueEx("IPAddress", $type, $ip); $regiface->QueryValueEx("DhcpIPAddress", $type, $ipdhcp); if (($ip && !($ip =~ /0\.0\.0\.0/)) || ($ipdhcp && !($ipdhcp =~ /0\.0 \.0\.0/))) { # NameServer overrides DhcpNameServer if both exist $regiface->QueryValueEx("NameServer", $type, $ns); $regiface->QueryValueEx("DhcpNameServer", $type, $ns) unless $ns; $nameservers .= " $ns" if $ns; } } and it works with DHCP assigned addresses as well. I expect the corresponding fix would be needed for Cygwin.pm as well.
I applied the patch supplied by "Orjan" on Win32.pm. As long as there is no reliable and portable way to determine the IP I'm stalling this ticket again. --Olaf
I have attached a patch that makes bgsend query all nameservers. That resolves the issue for my situation but I feel that it might not be the best way to do it.
Index: Base.pm =================================================================== --- Base.pm (revision 7602) +++ Base.pm (working copy) @@ -981,65 +981,75 @@ my $srcport = $self->{'srcport'}; - my (@res, $sockfamily, $dst_sockaddr); - my $ns_address = ($self->nameservers())[0]; + # my (@res, $sockfamily, $dst_sockaddr); + my @destinations; + my @nameservers = $self->nameservers(); my $dstport = $self->{'port'}; - - # The logic below determines ther $dst_sockaddr. - # If getaddrinfo is available that is used for both INET4 and INET6 - # If getaddrinfo is not avialable (Socket6 failed to load) we revert - # to the 'classic mechanism - if ($has_inet6 && ! $self->force_v4()){ - - my ( $socktype_tmp, $proto_tmp, $canonname_tmp); - - no strict 'subs'; # Because of the eval statement in the BEGIN - # AI_NUMERICHOST is not available at compile time. - - # The AI_NUMERICHOST surpresses lookups. - my @res = getaddrinfo($ns_address, $dstport, AF_UNSPEC, SOCK_DGRAM, - 0 , AI_NUMERICHOST); - - use strict 'subs'; - - ($sockfamily, $socktype_tmp, - $proto_tmp, $dst_sockaddr, $canonname_tmp) = @res; - - if (scalar(@res) < 5) { - die ("can't resolve \"$ns_address\" to address (it could have been an IP address)"); - } - - }else{ - $sockfamily=AF_INET; - - if (! ip_is_ipv4($ns_address)){ - $self->errorstring("bgsend(ipv4 only):$ns_address does not seem to be a valid IPv4 address"); - return; - } - - $dst_sockaddr = sockaddr_in($dstport, inet_aton($ns_address)); - } + foreach my $ns_address (@nameservers){ + # The logic below determines ther $dst_sockaddr. + # If getaddrinfo is available that is used for both INET4 and INET6 + # If getaddrinfo is not avialable (Socket6 failed to load) we revert + # to the 'classic mechanism + if ($has_inet6 && ! $self->force_v4()){ + + my ( $socktype_tmp, $proto_tmp, $canonname_tmp); + + no strict 'subs'; # Because of the eval statement in the BEGIN + # AI_NUMERICHOST is not available at compile time. + + # The AI_NUMERICHOST surpresses lookups. + my @res = getaddrinfo($ns_address, $dstport, AF_UNSPEC, SOCK_DGRAM, + 0 , AI_NUMERICHOST); + + use strict 'subs'; + + my ($sockfamily, $socktype_tmp, + $proto_tmp, $dst_sockaddr, $canonname_tmp) = @res; + + push @destinations, {'ns_address' => $ns_address, + 'sockfamily' => $sockfamily, + 'dst_sockaddr' => $dst_sockaddr}; + + if (scalar(@res) < 5) { + die ("can't resolve \"$ns_address\" to address (it could have been an IP address)"); + } + + }else{ + my $sockfamily=AF_INET; + + if (! ip_is_ipv4($ns_address)){ + $self->errorstring("bgsend(ipv4 only):$ns_address does not seem to be a valid IPv4 address"); + return; + } + + push @destinations, {'dst_sockaddr' => scalar(sockaddr_in($dstport, inet_aton($ns_address))), + 'sockfamily' => $sockfamily, + 'ns_address' => $ns_address}; + } + } + + my @socket; - if ($sockfamily == AF_INET) { - $socket[$sockfamily] = IO::Socket::INET->new( + if ($destinations[0]{'sockfamily'} == AF_INET) { + $socket[$destinations[0]{'sockfamily'}] = IO::Socket::INET->new( Proto => 'udp', Type => SOCK_DGRAM, LocalAddr => $srcaddr, LocalPort => ($srcport || undef), ); - } elsif ($has_inet6 && $sockfamily == AF_INET6() ) { + } elsif ($has_inet6 && $destinations[0]{'sockfamily'} == AF_INET6() ) { # Otherwise the INET6 socket will just fail my $srcaddr6 = $srcaddr eq "0.0.0.0" ? '::' : $srcaddr; - $socket[$sockfamily] = IO::Socket::INET6->new( + $socket[$destinations[0]{'sockfamily'}] = IO::Socket::INET6->new( Proto => 'udp', Type => SOCK_DGRAM, LocalAddr => $srcaddr6, LocalPort => ($srcport || undef), ); } else { - die ref($self)." bgsend:Unsoported Socket Family: $sockfamily"; + die ref($self)." bgsend:Unsoported Socket Family: $destinations[0]{'sockfamily'}"; } unless (scalar(@socket)) { @@ -1047,17 +1057,23 @@ return; } - print ";; bgsend($ns_address : $dstport)\n" if $self->{'debug'} ; - foreach my $socket (@socket){ next if !defined $socket; - unless ($socket->send($packet_data,0,$dst_sockaddr)){ - my $err = $!; - print ";; send ERROR($ns_address): $err\n" if $self->{'debug'}; - - $self->errorstring("Send: ".$err); - return; + foreach my $destination (@destinations){ + + my $ns_address = $destination->{'ns_address'}; + print ";; bgsend($ns_address : $dstport)\n" if $self->{'debug'} ; + + if(@socket[$destination->{'sockfamily'}] == $socket){ + unless ($socket->send($packet_data,0,$destination->{'dst_sockaddr'})){ + my $err = $!; + print ";; send ERROR($ns_address): $err\n" if $self->{'debug'}; + + $self->errorstring("Send: ".$err); + return; + } + } } return $socket; }
From: Hanno Stock <hanno.stock [...] gmx.net>
Here is a patch that retrieves information about the DNS resolution order from the registry. Windows has a sorted list of the interfaces for seperate services. (Actually for DNS it is "Bind" in the registry.) With this patch, the nameservers are sorted according to this ordered list. AFAIR there is a UI option in Windows somewhere. This works only under Win2k/XP, AFAIK. If the registry key is not present it will fall back to the default (unsorted) behavior. (Previous patch is mine also - if you want to contact me) The issue came up when working on Slimserver (www.slimdevices.com)
Index: G:/Programme/SlimServer/server/CPAN/Net/DNS/Resolver/Win32.pm =================================================================== --- G:/Programme/SlimServer/server/CPAN/Net/DNS/Resolver/Win32.pm (revision 7602) +++ G:/Programme/SlimServer/server/CPAN/Net/DNS/Resolver/Win32.pm (revision 7605) @@ -14,10 +14,15 @@ use Win32::Registry; sub init { + my ($class) = @_; my $defaults = $class->defaults; + # my $self = bless({ %{$class->defaults} }, $class); + # + # $self->{'debug'} = 1; + my ($resobj, %keys); my $root = 'SYSTEM\CurrentControlSet\Services\Tcpip\Parameters'; @@ -83,13 +88,33 @@ # } + my $bind_linkage; + my @sorted_interfaces; + print ";; DNS: Getting sorted interface list\n" if $self->{'debug'}; + $main::HKEY_LOCAL_MACHINE->Open('SYSTEM\CurrentControlSet\Services\Tcpip\Linkage', + $bind_linkage); + if($bind_linkage){ + my $bind_linkage_list; + my $type; + $bind_linkage->QueryValueEx('Bind', $type, $bind_linkage_list); + if($bind_linkage_list){ + @sorted_interfaces = split(m/[^\w{}\\-]+/s, $bind_linkage_list); + } + foreach my $interface (@sorted_interfaces){ + $interface =~ s/^\\device\\//i; + print ";; DNS:Interface: $interface\n" if $self->{'debug'}; + } + } - my $interfaces; $resobj->Open("Interfaces", $interfaces); if ($interfaces) { my @ifacelist; - $interfaces->GetKeys(\@ifacelist); + if(@sorted_interfaces){ + @ifacelist = @sorted_interfaces; + }else{ + $interfaces->GetKeys(\@ifacelist); + } foreach my $iface (@ifacelist) { my $regiface; $interfaces->Open($iface, $regiface);
On Fri May 19 13:58:36 2006, guest wrote: Show quoted text
> I have attached a patch that makes bgsend query all nameservers. That > resolves the issue for my situation but I feel that it might not be the > best way to do it.
Would you be so kind to create a new ticket for this particular issue. I do not know how to split a single message with attachement from a thread and create a new ticket from it and preserve the e-mail of the sender within rt. As far as the substance goes. I have to study this patch a bit. --Olaf
On Fri May 19 16:01:17 2006, guest wrote: Show quoted text
> Here is a patch that retrieves information about the > DNS resolution order from the registry. > > Windows has a sorted list of the interfaces for seperate > services. (Actually for DNS it is "Bind" in the registry.) > > With this patch, the nameservers are sorted according to > this ordered list. > > AFAIR there is a UI option in Windows somewhere. > > This works only under Win2k/XP, AFAIK. If the registry key > is not present it will fall back to the default (unsorted) > behavior. > > (Previous patch is mine also - if you want to contact me) > > The issue came up when working on Slimserver (www.slimdevices.com)
For this part of the thread I applied the patch and did rudimentary testing. I basically have no clue about the XP registry. So I have a question, Except for the hex codes, that indicate the interfaces (what do these codes contain?) there is one entry NdisWANIP in the Interface list. Which one is that. I did apply the patch, it looked pretty solid and passed the rudimentary tests (and did not break the resolver). The patch now lives on the trunk. --Olaf
On Mo. 22. Mai 2006, 17:21:05, OLAF wrote: Show quoted text
> Except for the hex codes, that indicate the interfaces (what do these > codes contain?) there is > one entry NdisWANIP in the Interface list. Which one is that.
The codes are just genuine identifiers and hold no additional information. AFAIK the NdisWANIP interface is used for the "DialupNetworking" component of windows. BTW, I have submitted a wrapper for GetNetworkParams() to the author of Win32::IPHelper. The use of this function was discussed above. It's much more consistent between windows versions and might as well be more "future safe". For more information see: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getnetworkparams.asp
On Mo. 21. Mär. 2005, 08:45:24, OLAF wrote: Show quoted text
> The reliable way to get the information is through the > getNetworkParams() API call in IpHlpApi.dll. That call works as off > 95-met-de-WINSOCK2-fix. > (http://msdn.microsoft.com/library/default.asp?url=/library/en- > us/iphlp/iphlp/getnetworkparams.asp) > > One could probably call this function through the use of Win32::API, > the > getNetworkParams function is similar to calls in Win32::IPhelper.
getNetworkParams() is now included in Win32::IPHelper.
Subject: Re: [rt.cpan.org #11931] Wrong nameserver list handling in Net::DNS::Resolver::Win32
Date: Fri, 16 Jun 2006 16:38:35 +0200
To: bug-Net-DNS [...] rt.cpan.org
From: "Olaf M. Kolkman" <olaf [...] dacht.net>
Hanno Stock via RT wrote: Show quoted text
> Queue: Net-DNS > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=11931 > > > On Mo. 21. Mär. 2005, 08:45:24, OLAF wrote: >
>> The reliable way to get the information is through the >> getNetworkParams() API call in IpHlpApi.dll. That call works as off >> 95-met-de-WINSOCK2-fix. >> (http://msdn.microsoft.com/library/default.asp?url=/library/en- >> us/iphlp/iphlp/getnetworkparams.asp) >> >> One could probably call this function through the use of Win32::API, >> the >> getNetworkParams function is similar to calls in Win32::IPhelper. >>
> > getNetworkParams() is now included in Win32::IPHelper. >
Hmmm.... is that lib generally available on win32 perl installations? (The only perl for win32 I am aware off is active perl) --Olaf
Download signature.asc
application/pgp-signature 252b

Message body not shown because it is not plain text.

ActiveState contains Win32::IPhelper, however not yet the new version 0.05. As Win32::IPHelper is pure perl, the new version should be there soon.
On Fri Jun 16 14:17:33 2006, HANSTO wrote: Show quoted text
> ActiveState contains Win32::IPhelper, however not yet the new version > 0.05. As Win32::IPHelper is pure perl, the new version should be there > soon.
In that case I will not take any action yet. I'll stall this ticket. Will you poke me when the library is available in Active X, then I will look into this matter further? OK? --Olaf
Subject: Re: [cpan #11931] Wrong nameserver list handling in Net::DNS::Resolver::Win32
Date: Sun, 24 Feb 2008 19:13:11 +0500
To: bug-Net-DNS [...] rt.cpan.org
From: Oscar Basharov <obasharov [...] auragan.com>
Hello, I suggest to exclude the patch by Hanno Stock from Win32.pm becasue in some cases 'HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind' exists, but doesn't contain some of actual network interfaces (WinXP SP2, ppp interfaces), as result, some of the DNS server's addresses will not be obtained. Additionally, if first DNS server will report "NXDOMAIN" the resolve process will stop on this, even if other DNS servers can resolve the given domain name. I would suggest to remove '$ans->header->rcode ne "NXDOMAIN"' condition from send_tcp() and send_udp() in Base.pm, this would clear the issue.
From: hanno.stock [...] gmx.net
On So. 24. Feb. 2008, 09:15:20, obasharov@auragan.com wrote: Show quoted text
> Hello, > > I suggest to exclude the patch by Hanno Stock from Win32.pm becasue in > some cases > 'HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\Bind' exists, > but > doesn't contain some of actual network interfaces (WinXP SP2, ppp > interfaces), > as result, some of the DNS server's addresses will not be obtained.
As mentioned earlier a call to getNetworkParams() is a more reliable way to obtain the DNS servers. A wrapper using Win32::API is already in Win32::IPHelper as of version 0.05. This version is now also included in the ActiveState PPM repositories.
Subject: Re: [cpan #11931] Wrong nameserver list handling in Net::DNS::Resolver::Win32
Date: Mon, 25 Feb 2008 17:56:41 +0100
To: bug-Net-DNS [...] rt.cpan.org
From: Olaf Kolkman <olaf [...] dacht.net>
On Feb 24, 2008, at 3:15 PM, Oscar Basharov via RT wrote: Show quoted text
> > Additionally, if first DNS server will report "NXDOMAIN" the resolve > process will stop on this, > even if other DNS servers can resolve the given domain name.
NXDOMAIN is a perfectly valid response to a query. There is no reason to hunt for another answer. Show quoted text
> I would suggest to remove '$ans->header->rcode ne "NXDOMAIN"' > condition from send_tcp() and send_udp() in Base.pm, > this would clear the issue.
--Olaf
Download PGP.sig
application/pgp-signature 235b

Message body not shown because it is not plain text.

As of Revision 751, just checked in on the trunk, we use WIN32::IPHelper, the availability and functionality is available under ActivePerl and Strawberry perl. I've only tested on an XP environment. For the searchlist we still remain on the registry readings, but don't croak if we are not able to get them. Closing ticket...