Show quoted text> One of us has a problem with the experiment, but it is not obvious what
> it is.
I have repeated my experiment (perl 5.20.0, on FreeBSD 10.0), this time
with some additional checking for receiving a valid DNS answer, and
avoiding
to manually force a TCP query but relying on a long DNS reply with a TC
flag set and automatic failover by Net::DNS to re-do a query over TCP.
I have also specified a single IPv4 nameserver in my /etc/resolv.conf,
just in case (previously I had two IPv6 entries there). ...
... essentially all the same as previously, just avoiding some
potential traps.
# for j in Net-DNS-0.??.tar.gz; do
echo $j; tar xf $j;
( cd ${j%.tar.gz}; perl Makefile.PL; make; make install;
perl -T -MNet::DNS -MNet::DNS::Resolver -le '
$|=1; print "\n\n----- ",Net::DNS->VERSION;
$a=Net::DNS::Resolver->new->send("20120113._domainkey.gmail.com","TXT")
or die "Err: $!";
print "OK: ",$a->string'; make clean
); done 2>&1 | tee 0.log
# egrep '^----- |OK: ;; Answer received|Insecure' 0.log
(just manually inserting a newline before every version for clarity):
----- 0.49
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.53
----- 0.59
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.61
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.62
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.63
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.64
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.65
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.66
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.67
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.68
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.69
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.70
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.71
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.72
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.73
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.74
OK: ;; Answer received from 193.2.4.247 (605 bytes)
----- 0.75
Insecure dependency in connect while running with -T switch at
/usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115.
----- 0.76
Insecure dependency in connect while running with -T switch at
/usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115.
----- 0.77
Insecure dependency in connect while running with -T switch at
/usr/local/lib/perl5/5.20/mach/IO/Socket.pm line 115.
The version 0.53 didn't provide any answer (and didn't fail either), but
I didn't investigate, as it's nine years old anyway.
So the result matches my previous experiment, versions 0.49 to 0.74
are happy with a default setup, versions 0.75, 0.76 and 0.77 fail.
Show quoted text> However, perhaps we do not need to solve that problem in order to
> reach a conclusion.
>
> If your result is right, untainting /etc/resolv.conf is the right way
> to go.
I think it is the right thing to do.
Btw, there shouldn't be any differences between getting the
information from /etc/resolv.conf or from a Windows registry,
both sources hold trusted system's settings (unless system has been
compromised or seriously misconfigured, in which case anything
can happen anyway).
Show quoted text> Way forward:
> /etc/resolv.conf untainted
Ok.
Show quoted text> $HOME/.resolv.conf tainted
> ./.resolv.conf tainted
> Environment variables always tainted
I don't care much for these, although I think that if such a setup
is already known to fail eventually when an application happens to
stumble over a DNS reply with a TC flag set, then it would be better
to fail right away with some sensible diagnostic, or just disallow
$HOME/.resolv.conf and /.resolv.conf and document the change.
Leaving an application to its chances of eventually stumbling
over such DNS answer and failing at some 'random' time is not
polite.
Still, there shouldn't be a difference (regarding trustworthiness
of name server sources) between a DNS query over UDP vs. TCP.
Show quoted text> Security sensitive users provide their own config file.
Right, or just use a system default.