This is a follow up to ticket #2733.
IPA DNS plugin now parses DNS records on its own and does no encoding of DNS records. Thus, when user pass an invalid character like "\n" to e.g. CERT record, 2 issues arise:
The situation could be improved with an integration of python-dns library to DNS plugin, it could be used for: 1. Parsing a raw DNS record, i.e. parse preference and exchanger from 1 mx.example.com. This would also introduce a better validation of the records 2. Encoding of DNS record when storing to LDAP. python-dns will automatically escape characters with an decimal form, i.e. "\n" becomes "\010" which is then understandable by BIND.
python-dns
preference
exchanger
1 mx.example.com
Few examples of python-dns in action:
>>> from dns.rdtypes.ANY.MX import MX >>> from dns.rdtypes.ANY.TXT import TXT >>> from dns import rdatatype >>> from dns import rdataclass >>> from dns.tokenizer import Tokenizer >>> # validation example >>> MX.from_text(rdataclass.IN, rdatatype.MX, Tokenizer('foo')) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/dns/rdtypes/mxbase.py", line 45, in from_text preference = tok.get_uint16() File "/usr/lib/python2.7/site-packages/dns/tokenizer.py", line 472, in get_uint16 value = self.get_int() File "/usr/lib/python2.7/site-packages/dns/tokenizer.py", line 448, in get_int raise dns.exception.SyntaxError('expecting an integer') dns.exception.SyntaxError: expecting an integer # parsing example >>> x = MX.from_text(rdataclass.IN, rdatatype.MX, Tokenizer('1 foo')) >>> x.preference 1 >>> x.exchange <DNS name foo> >>> # encoding example (UTF character) >>> print TXT(rdataclass.IN, rdatatype.TXT, u'čau'.encode('utf8')) "\196\141au" >>> # encoding example (special character) >>> TXT.from_text(rdataclass.IN, rdatatype.TXT, Tokenizer('123\x00')) <DNS IN TXT rdata: "123\000">
Please make sure that python-dns and BIND understand each other. There might be incompatible differences in how either of them decodes/encodes records. For example, BIND adds a space after every 60th character in SSHFP (and probably other) records (see #2642), does python-dns handle this well?
Moving my tickets back to free-to-take pool.
Very related ticket, maybe a duplicate: #3972.
Personally, I consider this to be a workaround for #3972. We should not need this if DNS syntax is used by LDAP server.
We need to parse the DNS records somehow so that we can enable structured composition and modification of more complex DNS records, like SSHFP or SRV.
Even with #3972 implemented, ldapsearch would still return for example SSHFP with space in the hash which is not correctly parsed in our framework, right? I.e. framework would not manipulate it unless python-dns is used.
Good point. I didn't consider record modification, only addition and deletion. So after all, #3205 is complementary to #3972.
Related: #4790
Metadata Update from @mkosek: - Issue assigned to mbasti - Issue set to the milestone: FreeIPA 4.5 backlog
Metadata Update from @mbasti: - Custom field blocking reset (from #2733) - Issue assigned to tkrizek (was: mbasti) - Issue close_status updated to: None
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.