BIND 10 #1667: dns::masterLoad should accept comment at EOL
BIND 10 Development
do-not-reply at isc.org
Thu Feb 23 18:21:44 UTC 2012
#1667: dns::masterLoad should accept comment at EOL
-------------------------------------+-------------------------------------
Reporter: | Owner: jinmei
jinmei | Status: reviewing
Type: | Milestone:
defect | Sprint-20120306
Priority: | Resolution:
critical | Sensitive: 0
Component: | Sub-Project: DNS
libdns++ | Estimated Difficulty: 4
Keywords: | Total Hours: 0
Defect Severity: N/A |
Feature Depending on Ticket: |
Add Hours to Ticket: 0 |
Internal?: 0 |
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:11 haikuo]:
> I reviewed your changes in this ticket,and it works for the RDATA
formats you mentioned.
> but I have a question about the method you defined(stripComment), why
you find the last semicolon but not the first one? As I know, the
semicolon means that the later words after it should be treated as the
comments. If you find the first semicolon and then erase all the later
words, do you think it will be better than your method? Of cause no body
want to modify the zonefile which was signed firstly,but I think our
software will be robust if we do that.
The first semicolon could be in the middle of RDATA, not at the start
of a comment like the one I used in the test:
example.com. 3600 IN TXT "aaa;bbb" ; this part is a comment
To handle such cases correctly we need a more complete parser with a
more complete "tokenizer", which would correctly extract '"aaa;bbb"'
as a quoted string. But we don't have time for that right now, so the
purpose of the ticket is a quickest (though incomplete, and sometimes
even incorrect) workaround that can handle a specific form of EOL
comment:
example.com. 3600 IN DNSKEY 256 3 7 <base64> ; key id = 40430
> For the function "masterLoad" you modified,you deal with the semicolon
by using an exception, I think it is good for the performance although it
looks like weird.
Yeah I know. Please consider this one also a short term workaround.
When we support more complete parser, this hack will be gone.
--
Ticket URL: <http://bind10.isc.org/ticket/1667#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list