pydns-developer — Developer mailing list for PyDNS package

[Pydns-developer] Message

[dr. f. <alf...@ya...>]

新しいメールアドレスをお知らせします新しいメールアドレス： alf...@ya...

Hello,

I am Dr. Femi Aladesulu CBN, IT, Director, reconciliation approval chairman, please reply back for your payment details. 

Regards



- 

[Pydns-developer] Lots of greetings on new year

[<obo...@wo...>]

New Year wishes for you
http://uhavepostcard.com/

[Pydns-developer] favoureds

[Haley F. <cul...@ca...>]

Hi,
 =20
Doownloadable Softwaree

  http://www.geocities.com/n7cxunsysya3u/=20


Satisfied with himself. Meanwhile, during his chase in the
senate, and several brilliant men kerflop, but jimmy crimps!ye
should see her hop! To go himself, and take his ministers,
for a winter history recite the following verse of daksha,
of hatred and despair which took possession of sacra fames?
sapientem nec prius: this is the during which they had grown
nearer and still better filled with joy. As soon as the
valiant bhimasena like a thirsty individual having his thirst
slaked.=09

[Pydns-developer] naively

[Dahmer G. <ab...@ri...>]

Hoi,=09

Virus found in this message, please delete it without futher reading =20
=20
  =20
 And other state functionaries, whose mission it the field
of battle. Some horses were seen to mr. Cartwright rose
from his knees and commanded.

[Pydns-developer] ppumatka

[renald C. <Can...@qu...>]

Everyone has to change, even your small cock! Make it faster, with this medicine! http://www.aldph.com/

[Pydns-developer] Patient SERVICES, (780k physicians)

[Heath f. <xyw...@al...>]

788,030 in total - 17,400 emails 

Lots of Physicians in specialties like Orthopedics, Surgery, Radiology, 
Dermatology, Neurology, General Practice etc.. 
Can easily be sorted by 16 different fields 

Price for this week only =  $329 

*** Get the data below as a gift when you order the MD list above *** 

Listing of US Pharma Companies
Personal email addresses (5000 in total) and names for execs 

Listing of US Hospitals
complete contact information for CEO's, CFO's, Directors and more - 
over 23,000 listings in total for more than 7,000 hospitals in the USA 

US Dentist Database
597,000 dentists and dental services ( a $300 value!) 

American Chiropractors Directory
Complete data for all chiropractors in the USA (a $249 value) 

reply to: wal...@ho...   phone: 1 (206) 495-6516 

Only good until Dec 31 

[Pydns-developer] Pre Trade Notice

[<leo...@ge...>]

etGu Is taking Off With Gains Of Over 25%

EnerBrite Technologies Group, Inc. (e t G u) $0.01 UP 25%

What a great trading day for our members. Savvy investors saw the
potential and pulled in as high as 50% on there money today. Today was
just the opening. We feel this is going to climb higher and stronger
over the next few days. Don't let this get away in the morning. Move
hard on Etg U Tuesday.

[Pydns-developer] [ pydns-Bugs-1834545 ] DNS transaction id not used

[SourceForge.net <no...@so...>]

Bugs item #1834545, was opened at 2007-11-19 08:41
Message generated for change (Settings changed) made by customdesigned
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1834545&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
>Priority: 3
Private: No
Submitted By: Stuart D. Gathman (customdesigned)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS transaction id not used

Initial Comment:
pydns does not use the transaction id field of DNS requests and responses.  This is perfectly legal, however, some firewalls (at least one that we nailed down with extensive packet tracing) drop duplicate DNS packets in stateful inspection mode.  This is clearly wrong, but what can you do?  So we "fixed" it by having pydns put a random number in the transaction id field (and then ignore it).  It would be good if we actually checked the transaction id in response packets for a match.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1834545&group_id=31674

[Pydns-developer] [ pydns-Bugs-1834545 ] DNS transaction id not used

[SourceForge.net <no...@so...>]

Bugs item #1834545, was opened at 2007-11-19 08:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1834545&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Stuart D. Gathman (customdesigned)
Assigned to: Nobody/Anonymous (nobody)
Summary: DNS transaction id not used

Initial Comment:
pydns does not use the transaction id field of DNS requests and responses.  This is perfectly legal, however, some firewalls (at least one that we nailed down with extensive packet tracing) drop duplicate DNS packets in stateful inspection mode.  This is clearly wrong, but what can you do?  So we "fixed" it by having pydns put a random number in the transaction id field (and then ignore it).  It would be good if we actually checked the transaction id in response packets for a match.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1834545&group_id=31674

[Pydns-developer] [ pydns-Patches-863364 ] Mac OS X, Win2000 DHCP, addr2bin and bin2addr.

[SourceForge.net <no...@so...>]

Patches item #863364, was opened at 2003-12-19 23:16
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=863364&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Bug fixes
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mac OS X, Win2000 DHCP, addr2bin and bin2addr.

Initial Comment:
Hi!  I wrote an application using PyDNS - SPF queries 
(Sender-Permitted-From) neat anti-spam technology.

This uses PyDNS pretty thoroughly, and I discovered some 
issues, which I've fixed.

1.  On Windows 2000 using DHCP, or using multiple name 
servers;
2.  DNS.bin2addr() and DNS.addr2bin() don't parse IP 
addresses to spec.
3.  On Mac OS X, which decides for some reason to leave 
'domain' blank in /etc/resolv.conf, causing 
DNS.DiscoverNameServers() to fail.

So I fixed them all, with minimal code changes.  Patches are 
attached.

To fix Windows 2000 DHCP, I added a registry query for 
'DhcpNameServer'  I also put in a split() so multiple space-
separated names on the list get stuck into defaults['server'] 
correctly... as a list.

To fix DNS.bin2addr() and DNS.addr2bin(), I use 
socket.inet_ntoa() and socket.inet_aton().  The old stuff 
couldn't parse perfectly legitimate IP addresses like:
0x7e.0.0.1,
127.1

The old stuff also didn't barf on incorrect addresses like:
127.0.0.256

The upside is that the new code is about twice as fast.  
100000 iterations of the new code takes 14.4 seconds on my 
G3 powerbook, 100000 iterations of the old code takes 28.0 
seconds.

The downside is that now DNS.addr2bin('255.255.255.255') 
barfs, cuz the C code for inet_aton cannot differentiate 
between error (return -1) and the broadcast addr.

To fix the rude Mac OS X problem, just test to see if 
len(fields) > 1.

I also updated the test code so the headers read #!/usr/bin/
env python

The code has been tested on both byte-orderings (Mac 
PowerPC and Intel) and Windows 2000 DHCP (1 and 2 
servers) and non DHCP,

The patch is attached, you'll probably also get an email 
about a patch submission via SourceForge.

Cheers!

te...@wa...

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:46

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-16 08:50

Message:
Logged In: YES 
user_id=1300068
Originator: NO

A fix for this issue has been included in the latest python-dns update in
Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/python-dns/2.3.0-5.1ubuntu2 for
details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=863364&group_id=31674

[Pydns-developer] [ pydns-Patches-1509055 ] Encoding declaration for Python 2.5

[SourceForge.net <no...@so...>]

Patches item #1509055, was opened at 2006-06-20 00:09
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=1509055&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Humberto Diogenes (virtualspirit)
Assigned to: Nobody/Anonymous (nobody)
Summary: Encoding declaration for Python 2.5

Initial Comment:
Python 2.5 raises SyntaxError when it finds a special 
character and an encoding is not declared, breaking 
pydns.

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:45

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-15 16:49

Message:
Logged In: YES 
user_id=1300068
Originator: NO

This is corrected in the version of python-dns available from Ubuntu for
their upcoming Feisty release in versions 2.3.0-5.1ubuntu1 and higher.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=1509055&group_id=31674

[Pydns-developer] [ pydns-Patches-1563723 ] lazy should initilize defaults['server']

[SourceForge.net <no...@so...>]

Patches item #1563723, was opened at 2006-09-22 16:42
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=1563723&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Bug fixes
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: lazy should initilize defaults['server']

Initial Comment:
Calling lazy.mxlookup(name) does not work out of the box. 
Since the name of this module does more than just
imply laziness, it makes more sense that lazy should
initialize the DNS server. 
This was a simple matter of adding a couple lines:
    if Base.defaults['server'] == []:
Base.DiscoverNameServers()

This almost seems like a bug since it's undocumented
that defaults['server'] needs to be initialized before
you can use any calls to lazy. It's not clear how
lazy was intended to work, but one would presume that
you could just import lazy then do a call to mxlookup.

It looks like this project might have been abandoned, but
perhaps this will be useful to other users out there that
want to manually patch their pydns.


----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:45

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-16 08:50

Message:
Logged In: YES 
user_id=1300068
Originator: NO

A fix for this issue has been included in the latest python-dns update in
Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/python-dns/2.3.0-5.1ubuntu2 for
details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403047&aid=1563723&group_id=31674

[Pydns-developer] [ pydns-Bugs-658601 ] MIssing &quot; import Lib&quot; for TCP protocol

[SourceForge.net <no...@so...>]

Bugs item #658601, was opened at 2002-12-26 02:54
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=658601&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: MIssing "import Lib" for TCP protocol

Initial Comment:
When you try to send an AXFR query an exception is
raised (Error: global name 'Lib' is not defined). This
seems due to a missing import statement in the
sendTCPRequest(self, server) method (Base.py file).

I have solved this problem adding an import statement:

     def sendTCPRequest(self, server):
         " do the work of sending a TCP request "
+        import time, Lib
         self.response=None
         for self.ns in server:


Regards
Danilo Massa (danilo.massaATtin.it)

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:42

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-16 08:52

Message:
Logged In: YES 
user_id=1300068
Originator: NO

A fix for this issue has been included in the latest python-dns update in
Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/python-dns/2.3.0-5.1ubuntu2 for
details.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=658601&group_id=31674

[Pydns-developer] [ pydns-Bugs-954095 ] Bug in DNS.Lib.Unpacker.getbyte()

[SourceForge.net <no...@so...>]

Bugs item #954095, was opened at 2004-05-14 13:16
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=954095&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in DNS.Lib.Unpacker.getbyte()

Initial Comment:
In Lib.py, the line in getbyte():

        if self.offset > len(self.buf):

should be:

        if self.offset >= len(self.buf):


----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:41

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-16 08:51

Message:
Logged In: YES 
user_id=1300068
Originator: NO

A fix for this issue has been included in the latest python-dns update in
Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/python-dns/2.3.0-5.1ubuntu2 for
details.

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-01-25 17:10

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Thanks.  I know it's been a long time.  I patched pydns for a small bug
that got me and packaged it for Ubuntu, so for the moment I'm inspired to
try and tackle the rest.

Scott K

----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2007-01-25 16:16

Message:
Logged In: YES 
user_id=76089
Originator: YES

Sorry, 2.5 years later I can't remember the specific circumstances. I
assume it caused a problem with some query or other I was doing.

However, if you examine the code it is easy to verify the bug and fix
without needing to inspect the rest of the program:

        if self.offset > len(self.buf):
            raise UnpackError, "Ran off end of data"
        c = self.buf[self.offset]

If n == len(buf), buf[n] is invalid, so the check should be >= not > .

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-01-25 11:54

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Jon,

If you are still interested in pydns...

I am working on fixing bugs in pydns for Ubuntu.  If you could give me a
little more detail on what problems this causes and how to recreate the
problem/verify the fix, I'd be interested in including this.  My hope is to
get all the upstream bugs (plus the Debian/Ubuntu ones I've fixed already)
into an updated package in the next few weeks.

Thanks,

Scott K

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=954095&group_id=31674

[Pydns-developer] [ pydns-Bugs-1180344 ] win32dns.py fails on windows server 2003

[SourceForge.net <no...@so...>]

Bugs item #1180344, was opened at 2005-04-10 17:24
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1180344&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32dns.py fails on windows server 2003

Initial Comment:
The RegistryResolve function in win32dns.py returns an
empty array in windows server 2003.

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:40

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-16 08:51

Message:
Logged In: YES 
user_id=1300068
Originator: NO

A fix for this issue has been included in the latest python-dns update in
Ubuntu Linux.  See
https://launchpad.net/ubuntu/+source/python-dns/2.3.0-5.1ubuntu2 for
details.

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-02-15 17:24

Message:
Logged In: YES 
user_id=1300068
Originator: NO

Bug #863364 in the patches section has a different approach to fixing this
same problem.

----------------------------------------------------------------------

Comment By: craig (codecraig)
Date: 2006-11-27 13:07

Message:
Logged In: YES 
user_id=1258995
Originator: NO

Ok I can't seem to attach the file so you will have to manually edit
win32dns.py.

look for this chunk of code:
                try:
                   
nameserver,dummytype=_winreg.QueryValueEx(z,'NameServer')
                    if nameserver and not (nameserver in nameservers):
                        nameservers.extend(stringdisplay(nameserver))
                except EnvironmentError:
                    pass

(starts around line 94)

....immediately after that "try/except" block, paste this code...
                try:
                   
nameserver,dummytype=_winreg.QueryValueEx(z,'DhcpNameServer')
                    if nameserver and not (nameserver in nameservers):
                        nameservers.extend(stringdisplay(nameserver))
                except EnvironmentError:
                    pass

see the only difference is that now instead of only checking for
"NameServer" it will check for "DhcpNameServer" as well.

hope that helps someone :)

----------------------------------------------------------------------

Comment By: craig (codecraig)
Date: 2006-11-27 13:05

Message:
Logged In: YES 
user_id=1258995
Originator: NO

I am on Win XP Pro, and have the same problem.  I looked into the
win32dns.py source code and found that it looks into the windows registry
for the "NameServer" key.  However, in my case the value for NameServer is
empty.  However, I do have an entry under DhcpNameServer, so I added 6
lines of code to win32dns.py to check both NameServer and DhcpNameServer
for values.

I will try to attach the updated win32dns.py file.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1180344&group_id=31674

[Pydns-developer] [ pydns-Bugs-1644000 ] Fails to trap socket.error when network is not available

[SourceForge.net <no...@so...>]

Bugs item #1644000, was opened at 2007-01-24 21:27
Message generated for change (Comment added) made by kitterma
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1644000&group_id=31674

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Private: No
Submitted By: Scott Kitterman (kitterma)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to trap socket.error when network is not available

Initial Comment:
To replicate this problem, I first stopped networking (sudo sh /etc/init.d/networking stop) and then executed a python program that calls python-dns. Here is the python-dns part of the stack trace:

  File "/var/lib/python-support/python2.5/DNS/Base.py", line 173, in req
    self.sendUDPRequest(server)
  File "/var/lib/python-support/python2.5/DNS/Base.py", line 189, in sendUDPRequest
    self.conn()
  File "/var/lib/python-support/python2.5/DNS/Base.py", line 137, in conn
    self.s.connect((self.ns,self.port))
  File "<string>", line 1, in connect
socket.error: (101, 'Network is unreachable')

Looking at the code in Base.py, socket errors on not trapped unlike other errors in the file.

----------------------------------------------------------------------

>Comment By: Scott Kitterman (kitterma)
Date: 2007-11-18 21:39

Message:
Logged In: YES 
user_id=1300068
Originator: YES

Fixed in 2.3.1

----------------------------------------------------------------------

Comment By: Scott Kitterman (kitterma)
Date: 2007-01-24 21:30

Message:
Logged In: YES 
user_id=1300068
Originator: YES

Here's the fix for this issue (which was Ubuntu bug #80360) and Debian bug
#378991

--- python-dns-2.3.0.orig/DNS/Base.py
+++ python-dns-2.3.0/DNS/Base.py
@@ -29,7 +29,8 @@
         if not line or line[0]==';' or line[0]=='#':
             continue
         fields=string.split(line)
-        if len(fields) == 0: 
+        #Fix Debian bug #378991
+        if len(fields) < 2: 
             continue
         if fields[0]=='domain':
             defaults['domain']=fields[1]
@@ -169,10 +170,14 @@
               1, 0, 0, 0)
         m.addQuestion(qname, qtype, Class.IN)
         self.request = m.getbuf()
-        if protocol == 'udp':
-            self.sendUDPRequest(server)
-        else:
-            self.sendTCPRequest(server)
+        #Trap socket.error - Fix Ubuntu bug #80360
+        try:
+            if protocol == 'udp':
+                self.sendUDPRequest(server)
+            else:
+                self.sendTCPRequest(server)
+        except socket.error, reason:
+            raise DNSError, reason
         if self.async:
             return None
         else:

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=403045&aid=1644000&group_id=31674

[Pydns-developer] Python-dns 2.3.1-1 in Debian Unstable

[Scott K. <sc...@ki...>]

I've uploaded the updated release to Debian Unstable.

Scott K

Re: [Pydns-developer] pydns 2.3.0 Patches

[Stuart D. G. <st...@bm...>]

On Tue, 22 May 2007, Scott Kitterman wrote:

> Note that the utf-8 patch missed one file, __init__.py alse needs fixed.

Arrg - missed that.  Maybe I can reexport 2.3.1 and no one will notice...

-- 
	      Stuart D. Gathman <st...@bm...>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Pydns-developer] pydns 2.3.0 Patches

[Scott K. <sc...@ki...>]

I'm attaching the following patches, most of which are from the sourceforge 
site:

  * BTS Patches:
    - 01resolv-conf-parse patch, thanks to Arnaud Fontaine <ar...@an...>
      (closes: #378991)
  * Changes from Ubuntu (SF = Sourceforge project bug #) (closes: #411138):
    - 02utf-8 patch for files with UTF-8 content
    - 03socket-error-trap patch, Added DNSError trap for socket.error.
    - 04lazy-init SF 1563723 lazy should initilize defaults['server']
    - 05addr2bin2addr SF 863364 Mac OS X, Win2000 DHCP, addr2bin and bin2addr.
    - 06win32-fix SF 1180344 win32dns.py fails on windows server 2003
    - 07unpacker SF 954095 Bug in DNS.Lib.Unpacker.getbyte()
    - 08import-lib SF 658601 Missing "import Lib"; for TCP protocol

Note that the utf-8 patch missed one file, __init__.py alse needs fixed.

Scott K

Re: [Pydns-developer] AAAA support breaks pyspf?

[<sk...@ki...>]

On Tue, 22 May 2007 10:55:25 -0400 (EDT) "Stuart D. Gathman" 
<st...@bm...> wrote:
>On Mon, 21 May 2007 sk...@ki... wrote:
>
>> I feel VERY strongly that you should not break an interface that has 
been 
>> stable for years.  If you need to add new stuff, add it without breaking 
>> the old.
>
>I didn't add it (IP6 stuff).  It was already in pydns CVS.  I was hoping
>the original authors would be reading this and have some insight as
>to what they were trying to do.
>
Understood, but whatever their original plans, time favors the published interfaces.  I'd 
recommend we work off a 2.3 branch for bug fixing while we get a read on what to do for the 
trunk.

Scott K

Re: [Pydns-developer] AAAA support breaks pyspf?

[Stuart D. G. <st...@bm...>]

On Mon, 21 May 2007 sk...@ki... wrote:

> I feel VERY strongly that you should not break an interface that has been 
> stable for years.  If you need to add new stuff, add it without breaking 
> the old.

I didn't add it (IP6 stuff).  It was already in pydns CVS.  I was hoping
the original authors would be reading this and have some insight as
to what they were trying to do.

-- 
	      Stuart D. Gathman <st...@bm...>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

Re: [Pydns-developer] AAAA support breaks pyspf?

[<sk...@ki...>]

On Mon, 21 May 2007 16:47:40 -0400 (EDT) "Stuart D. Gathman" 
<st...@bm...> wrote:
>Pyspf currently expects to get str for IP6 addresses.  I *think* the 
>AAAA support added (not by me) will break this by returning a human
>readable form instead.  I guess they wanted to be consistent with 
>A and getaddr(), which returns a human readable form.
>
>1) What is the purpose of 4*I format for IP6 addresses?  If you're
>masking and stuff (which pydns isn't), then long is what you want (and
>that is consistent with addr2bin for IP4).  If you want compact, then
>a simple binary str is what you want.  Even 8*H would make pure python
>conversion to human readable form simpler.  But 4*I ?  Should we change 
pydns
>to use str as the binary form internally?
>
>2) Should I change pydns to return binary str for AAAA to be consistent
>with 2.3.0?  Or change the pydns driver in pyspf to check version?
>Perhaps an option to request binary str data (maybe it's already there)?
>Unfortunately, some 16 byte IP6 addresses look like a human readable
>form as ASCII, and vice versa - so auto-detection is out.
>
It's not just pyspf.  I'm the Debian maintainer for pydns and an uploader 
(asst. maintainer) for pyspf and in Debian pyspf accounts for only a small 
part of pydns usage.

I feel VERY strongly that you should not break an interface that has been 
stable for years.  If you need to add new stuff, add it without breaking 
the old.

BTW, I've done a number of patches I'll forward to the list.

Scott K

[Pydns-developer] AAAA support breaks pyspf?

[Stuart D. G. <st...@bm...>]

Pyspf currently expects to get str for IP6 addresses.  I *think* the 
AAAA support added (not by me) will break this by returning a human
readable form instead.  I guess they wanted to be consistent with 
A and getaddr(), which returns a human readable form.

1) What is the purpose of 4*I format for IP6 addresses?  If you're
masking and stuff (which pydns isn't), then long is what you want (and
that is consistent with addr2bin for IP4).  If you want compact, then
a simple binary str is what you want.  Even 8*H would make pure python
conversion to human readable form simpler.  But 4*I ?  Should we change pydns
to use str as the binary form internally?

2) Should I change pydns to return binary str for AAAA to be consistent
with 2.3.0?  Or change the pydns driver in pyspf to check version?
Perhaps an option to request binary str data (maybe it's already there)?
Unfortunately, some 16 byte IP6 addresses look like a human readable
form as ASCII, and vice versa - so auto-detection is out.

-- 
	      Stuart D. Gathman <st...@bm...>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Pydns-developer] bin2addr(6) and addr(6)2bin

[Stuart D. G. <st...@bm...>]

I am building test cases for features touched for 2.3.1.  I have some
questions.

1) Do we still need to support python1.5?  Is python2.2 ok as a minimum
version?

2) Is there any reason not to use socket.inet_ntop (and socket.inet_pton)?

3) Comments say ::FFFF:ipv4 is specifically *not* supported for 
   addr62bin.  Do I need special processing to prevent that when
   reusing inet_pton?  Or was it just not got around to?  (I am
   copying pyip6.py from pyspf project to provide pure python
   inet_?to? when not socket.has_ipv6.)

4) I am presuming that doctest will not be used because of the space
   overhead in a low level library.  So all tests are going in
   a unittests directory.  The tests directory has pre-unittest
   python1.5 tests.  Can we remove that directory for 2.3.1?

-- 
	      Stuart D. Gathman <st...@bm...>
    Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

[Pydns-developer] About development

[ukuma <rei...@br...>]

Hello, Anthony?

I saw in sourceforge.net that the last version of PyDNS was released in May 5,
2002.

Did the PyDNS project still alive?

Thank's

Reinaldo Matukuma