[ldns-users] pyLDNS Problems

[Paul Wouters]

Christopher Olah <christopherolah.co at gmail.com> wrote:

> (1) ldns_resolver stops responding
> 
> Creating reproducible errors here is tricky, because things are so
> dependent on the state of things outside my control. However, the
> following code has been demonstrating it quite reliability on centos6
> with pyLDNS 1.3.40

He meant ldns-1.6.10

> import ldns
> 
> ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf")
> #Drop nameservers
> while self._ldns_resolver.pop_nameserver():
>    pass
> #Set nameserver to xelerance's to aid repropducability
> address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65")
> ldns_resolver.push_nameserver(address)
> #Make queries. The first will work OK, but the next two will break.
> print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )
> print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )
> print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY,
> ldns.LDNS_RR_CLASS_IN )

I can confirm this problem on centos6. I did not see it on another machine running
centos5, though both machines show a VERY long query time for "xelerance.com"
against 76.10.157.65, prob due to that machine being an embedded dnsmasq like
forwarding proxy (stock openwrt setup)

Running tcpdump, I see:

17:58:17.573349 IP 193.110.157.68.49261 > 76.10.157.65.domain: 39418+ ANY? google.com. (28)
17:58:17.701311 IP 76.10.157.65.domain > 193.110.157.68.49261: 39418 15/4/4 MX aspmx.l.google.com. 10, MX alt1.aspmx.l.google.com. 20, MX alt2.aspmx.l.google.com. 30, MX alt3.aspmx.l.google.com. 40, MX alt4.aspmx.l.google.com. 50, TXT "v=spf1 include:_netblocks.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31 ~all", A 74.125.226.82, A 74.125.226.83, A 74.125.226.84, A 74.125.226.80, A 74.125.226.81, NS ns3.google.com., NS ns4.google.com., NS ns2.google.com., NS ns1.google.com. (502)
17:58:17.702464 IP 193.110.157.68.57555 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31)
17:58:22.708357 IP 193.110.157.68.41786 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31)
17:58:27.713547 IP 193.110.157.68.46401 > 76.10.157.65.domain: 9877+ ANY? xelerance.com. (31)
17:58:27.900993 IP 76.10.157.65.domain > 193.110.157.68.46401: 9877| 2/0/0 RRSIG, RRSIG (377)
17:58:27.901165 IP 193.110.157.68.34584 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42)
17:58:27.906896 IP 76.10.157.65.domain > 193.110.157.68.57555: 9877| 2/0/0 RRSIG, RRSIG (377)
17:58:27.912989 IP 76.10.157.65.domain > 193.110.157.68.41786: 9877| 2/0/0 RRSIG, RRSIG (377)
17:58:32.906321 IP 193.110.157.68.44629 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42)
17:58:37.911606 IP 193.110.157.68.60266 > 76.10.157.65.domain: 9877+ [1au] ANY? xelerance.com. (42)

Note that the last call to ldns_resolver.query() using "google.com" does NOT generate a DNS
packet at all. It seems the resolver object is left in some broken state due to the previous
TC packet.

> It just returns Nones. Contrast this with dig ANY xelerance.com @76.10.157.65
> 
> Some observations: This bug seems to be associated with truncated packets. Using

I've attached the test program,

Paul
-------------- next part --------------
#!/usr/bin/python

import ldns
ldns_resolver = ldns.ldns_resolver.new_frm_file("/etc/resolv.conf")
while ldns_resolver.pop_nameserver():
	pass

address = ldns.ldns_rdf_new_frm_str(ldns.LDNS_RDF_TYPE_A,"76.10.157.65")
ldns_resolver.push_nameserver(address)
print "doing google"
print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN )
print "doing xelerance"
print ldns_resolver.query("xelerance.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN )
print "doing google"
print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN )
print "doing google again"
print ldns_resolver.query("google.com", ldns.LDNS_RR_TYPE_ANY, ldns.LDNS_RR_CLASS_IN )