On 28 Jun 2010, at 13:42, Jed Smith wrote: > However, dns.zone.from_file chokes on this zone and complains: > >> Traceback (most recent call last): >> File "/opt/ingen/ingen", line 17, in <module> >> ret = infragen.main(path, len(sys.argv), sys.argv) >> File "/opt/ingen/InfraGen/infragen.py", line 128, in main >> mod.execute(config) >> File "/opt/ingen/InfraGen/reverse.py", line 26, in execute >> stub(config, cidr, rangeID, zone) >> File "/opt/ingen/InfraGen/reverse.py", line 77, in stub >> misc.bump_serial(escaped) >> File "/opt/ingen/InfraGen/misc.py", line 25, in bump_serial >> z = dns.zone.from_file(filename, filename + ".") >> File "/usr/lib/python2.6/dist-packages/dns/zone.py", line 826, in from_file >> filename, allow_include, check_origin) >> File "/usr/lib/python2.6/dist-packages/dns/zone.py", line 773, in from_text >> reader.read() >> File "/usr/lib/python2.6/dist-packages/dns/zone.py", line 731, in read >> self.zone.check_origin() >> File "/usr/lib/python2.6/dist-packages/dns/zone.py", line 520, in >> check_origin >> raise NoSOA >> dns.zone.NoSOA > > I can definitely see a SOA record, and named-checkzone considers the zone OK. > Is there a way to get DNSPython to accept the $ORIGIN containing '/' as BIND > does, without it complaining about a missing SOA?
Can you tell me exactly what the value of the 'filename' parameter is? It looks like you're setting the zone's origin to filename + '.', and if that's not '0/24.2.219.213.in-addr.arpa', then you're going to have the problem you're seeing. The $ORIGIN in your master file sets the current origin to apply to relative names in subsequent records, but it does not set the origin of the zone object. /Bob _______________________________________________ dnspython-users mailing list [email protected] http://howl.play-bow.org/mailman/listinfo.cgi/dnspython-users
