AAAA support removes binary AAAA support

[Stuart Gathman]

The A record returned IP4 addresses as text in dotted quad notation. The AAAA support in 3.0.1 (and pydns) returned IP6 addresses as a 16 byte binary. The change to return text in 3.0.2 breaks code that depended on the binary notation for IP6 and converted text IP4 addresses back to binary. (Fortunately, such code is still using pydns AFAIK.)

Making A and AAAA consistent is a good thing. Losing binary support is a bad thing. What we need is new methods to get the binary notation, which I can port back to pydns as well. All code that uses the binary form ends up converting to int/long so it can do masking and such. So we really need 3 access methods: text form, int/long form, and raw bytes. Raw bytes is the most general, and should be done first and be available for all DNS record types.

[Scott Kitterman (kitterman)]

Right. We should extend the API so you can get whichever you want.

[Stuart Gathman (stuart-gathman)]

I think pyspf might be broken with this change. Does it pass the test suite with py3dns-3.0.2 and python3?

[Scott Kitterman (kitterman)]

No. It doesn't. Ugh.

[Stuart Gathman (stuart-gathman)]

I think we have to remove getAAAA, and think how to make accessing raw (bytes), cooked (int), and string forms convenient. Here is an idea to throw out: each RR is a dict. Make 'data' key the compatible value. Add 'rawValue' (bytes), 'strValue', and 'value' (most "convenient" form, e.g. int for IP4/IP6) keys. This would work in pydns as well. Comments?

[Scott Kitterman (kitterman)]

I'd like to use ipaddr for IP4/6 classes since it is going to be a part of the standard distribution in the future (probably python 3.3, certainly python 3.4). That should simplify some of this.

[Stuart Gathman (stuart-gathman)]

If ipaddr has a ctor taking either int or bytes, then there is no need for the dependency (in python2 and python3 < 3.3). That would be an argument for not including the 'strValue' key - it is conveniently obtained via ipaddr (not to mention socket module). That leaves 3 keys: 'data', 'rawValue', and 'value'. 'data' being the inconsistent compatible form.

[Stuart Gathman (stuart-gathman)]

Another idea: instead of a plain dict, how about a RR class for records? The dict keys are kind of hokey. I would prefer instance members, with dict protocol implemented for compatibility. That way, there would only be the 'data' key, and new semantics are accessed as members. Anyone see any compatibility problems with returning class RR (which emulates dict protocol) instead of dict ?

[Stuart Gathman (stuart-gathman)]

E.g. a snippet from pyspf:
 [((a['name'], a['typename']), a['data']) for a in resp.answers]

could become:
 [((a.name, a.typename), a.value) for a in resp.answers]

[Scott Kitterman (kitterman)]

Looks like pyspf is broken in python3 at the moment with either py3dns 3.0.1 or 3.0.2. Urgh. So it looks like I messed something up in 2.0.7 too.

[Scott Kitterman (kitterman)]

Released py3dns 3.0.3 which restores raw bytes as the IPv6 return type.

Working on a 3.1 that will have the API to select among the following choices for IP addresses:

default (match pydns - text for IPv4/raw bytes for IPv6)
binary (raw bytes (type bytes in python3 or a string of bytes in python (also default for IPv6))
text (human readable text representation of type string (also default for IPv4)
integer ( the integer value of the IP address)

txt rdata will default to text (same as pydns) with these options available:
binary
text

Are there more options that should go in?

[Scott Kitterman (kitterman)]

The actual bug as described is fixed in 3.0.3.