Repository navigation
Conversation
|
Personally I would rather go the other way and make from_text() work. dnspython is used a lot for testing and doing 'weird things' like manipulating bitmaps with TYPE0 in them. |
|
Heh, I noticed this behavior this weekend independently while looking at something else, though I haven't done the research yet to see why we try to block 0 in text form. We should either accept it always or reject it always, depending on what the RFC says and what we think about the testing utility of permitting it even if the RFC dislikes it. I haven't had time to research yet. |
|
Some research later... Dnspython's dislike of TYPE0 in text format probably goes back to RFC 3845 which calls out type 0 as MUST be clear, but also MUST be ignored if not clear. RFC 4035 doesn't call TYPE0 out specifically, but it arguably fits into the undefined term "pseudo-type" as TYPE0 is not supposed to appear in zonefiles. The RFC puts us in an awkward place too, as it says that you MUST ignore such types if you get them. That means that if you don't accept them in text format, you can't round trip an AXFR or otherwise be a secondary for a zone where the primary set TYPE0. And you can't clear them as they are signed! So in the name of round tripping, I'm inclined to close this PR, and just remove the ban on TYPE0 from the text parser. |
|
That would be my preference as well. |
|
I implemented the plan described above. |
Bitmap.from_text rejects TYPE0, but Bitmap.init, which the NSEC, NSEC3 and CSYNC wire parsers go through, accepted a window 0 bitmap with bit 0 set, so such a record received from the wire (for example in a zone transfer) printed as TYPE0 and its to_text() output, or a zone saved with to_file(), could not be read back. Bitmap.init now rejects bit 0 alongside the existing trailing zero octet check from #1306, which surfaces as FormError from from_wire; I added a test in tests/test_rdata.py and the full suite passes.