[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