[Twisted-Python] Problem with twisted.names.client.lookupPointer

[Jean-Paul Calderone]

On Sun, 19 Jul 2009 06:34:21 +0100, Kieran Simkin <kieran at digital-crocus.com> wrote:
>Hi there,
>I'm trying to do some reverse DNS lookups with twisted and I don't seem to 
>be able to get even the most simple of test cases to work. I've tried it on 
>a couple of different installations with the same results, perhaps someone 
>can help me?

lookupPointer is a pretty low-level interface.  It's just going to give you
back the records that the DNS server it talks to gives back.  This also means
that its behavior can very based on which DNS servers it ends up using.  You
are probably interested in a higher level API that does the additional
sorting-out that's required to get the value you're actually asking for.
Unfortunately, this API isn't provided by Twisted Names (yet! :).

That said, you might be encountering a problem not related to this.

>My test case is this:
>----------------------------------------------------------------------------------
>from twisted.names import client
>from twisted.internet import reactor
>def callback(a):
>    print repr(a)
>
>client.lookupPointer('128.244.209.91.in-addr.arpa').addCallback(callback)
>reactor.run()
>----------------------------------------------------------------------------------
>
>The output I'm getting from this program is as follows:
>([<RR name=128.244.209.91.in-addr.arpa type=PTR class=IN ttl=9777s 
>auth=False>], [<RR name=244.209.91.in-addr.arpa type=NS class=IN ttl=8348s 
>auth=False>, <RR name=244.209.91.in-addr.arpa type=NS class=IN ttl=8348s 
>auth=False>], [<RR name=ns1.solsticehosting.net type=A class=IN ttl=8348s 
>auth=False>, <RR name=ns2.solsticehosting.net type=A class=IN ttl=8348s 
>auth=False>])
>
>Nowhere in this output is the actual PTR record - the first entry looks like 
>it should be the PTR record, but the name is '128.244.209.91.in-addr.arpa' - 
>I'm expecting it to be node2.digital-crocus.com. Can anyone clarify whether 
>I'm doing something wrong or if this is in fact a bug?

What you get back from the lookup methods are "RR" objects.  These are the
generic wrapping layer around any record-specific data.  If you look at the
first entry's "payload" attribute, I think you'll find a Record_PTR instance
which has the information you're after.

Jean-Paul