[Twisted-Python] twisted.protocols.dns NAPTR extension question

Andrzej Leszczynski leszczynscy at yahoo.com
Thu Jan 19 11:25:07 EST 2006


Hi,

I have a question regarding extension
twisted.protocols.dns by NAPTR DNS Resource Record
(RFC 2915). Adding the new class Record_NAPTR and the
NAPTR (35) constant is trivial however when it comes
to decoding the names "flags", "service", "regexp" and
"replacement" I realized that "class Name" attempts to
read all the names in the byte stream and concatenate
them together with "." used as a separator.

I work on my copy of dns.py so I hacked it up a little
and the code looks like here:

    def decode(self,strio,length=None):
       
self.order=struct.unpack('!H',readPrecisely(strio,2))[0]
       
self.preference=struct.unpack('!H',readPrecisely(strio,2))[0]
        self.flags=Name()
        self.flags.decode(strio,concatenate=False)
        self.service=Name()
        self.service.decode(strio,concatenate=False)
        self.regexp=Name()
        self.regexp.decode(strio,concatenate=False)
        self.replacement=Name()
       
self.replacement.decode(strio,concatenate=False)

The new function "Name.decode" argument was added and
defaulted to True in the definition. I wanted to avoid
of using Name and then doing the split on its value
because there are many cases that "." is in the
content of those four names: "flags", "service",
"regexp" and "replacement". 

And the questions:
	-what is the reason in the "Name.decode" to
concatenate names, does any of RRs actually uses that
feature?
	-what would be recommended why to implement NAPTR?
	-I wish to avoid maintaining my own copy of dns.py,
is there any chance/plans that NAPTR would be
supported?


Thanks in advance,
AndyL

In theory, practice and theory are the same. In
practice, they are not.






More information about the Twisted-Python mailing list