Created attachment 717736 [details] zone generator Description of problem: BIND9 test suite contains a script for generating zone files. Zones from this script are valid (BIND is able to load and serve them correctly), but python-dns blows up. Version-Release number of selected component (if applicable): python-dns-1.10.0-1.fc17.noarch How reproducible: 100 % Steps to Reproduce: 1. Generate a zone with attached script (script came from BIND 9 test suite): $ genzone.sh 2 3 4 > master2.db 2. Try to load the zone with following Python snippet: import dns.zone dns.zone.from_file('master2.db', origin='master2.') Actual results: Traceback (most recent call last): File "test.py", line 2, in <module> dns.zone.from_file('master2.db', origin='master2.') File "/usr/lib/python2.7/site-packages/dns/zone.py", line 814, in from_file filename, allow_include, check_origin) File "/usr/lib/python2.7/site-packages/dns/zone.py", line 761, in from_text reader.read() File "/usr/lib/python2.7/site-packages/dns/zone.py", line 715, in read raise dns.exception.SyntaxError("%s:%d: %s" % (filename, line_number, detail)) dns.exception.SyntaxError: master2.db:41: generic rdata does not start with \# Expected results: Zone is parsed correctly. Additional info: line 41 from generated zone: mb02 MG .
Created attachment 717738 [details] unparsable zone file with MG record
Created attachment 717750 [details] unparsable zone file with KEY record I hit exactly same problem with KEY records. Attached zone was generated by BIND scripts in bind-9.9.2-P1/bin/tests/system/tsiggss/ns1.
This is definitely something that you should work with upstream to fix. Once they have released a new version, I'd be happy to update the package.