BIND 10 #2905: buggy zone should result in SERVFAIL, not REFUSED
BIND 10 Development
do-not-reply at isc.org
Thu May 23 08:24:57 UTC 2013
#2905: buggy zone should result in SERVFAIL, not REFUSED
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: defect | jinmei
Priority: medium | Status:
Component: data source | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20130528
Sub-Project: DNS | Resolution:
Estimated Difficulty: 5 | CVSS Scoring:
Total Hours: 1.32 | Defect Severity: N/A
| Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
* totalhours: 0 => 1.32
Comment:
Hello
Replying to [comment:9 jinmei]:
> Hmm, not sure exactly which part of th code you meant, but I've tried
> to make some clarification in zone_table.h.
Yes, I think it was this one.
> > The exception text „Zone content must not be NULL or empty“ is
understandable, but only with some thinking about what it means. Should it
better be „nor“?
>
> (Readability aside) in my understanding "not A or B" is the
> grammatically correct form while "not A nor B" isn't. But in any case
> I've revised it more fundamentally. Hopefully that one is clearer.
But I believe such would translate to `(!A) || B`, which is wrong. It
should AFAIK be „Neither A nor B“.
Anyway, the revised version looks good.
> It checks that by confirming finder_ is NULL and `dsrc_client_` isn't.
> I considered introducing some more explicitly interface that indicates
> the zone is empty/broken, but adding another boolean didn't seem to be
> a good idea because that one and finder_ and dsrc_client_ are related
> and we'll need to be careful not to break the integrity. Adding a
> method like `isZoneEmpty()` (return true iff both finder_ and
> dsrc_client_ are non NULL) would be a possible idea, but for the user
> like auth query.cc it didn't seem to be very useful anyway.
Hmm. I just got the impression that something like 5 different places got
the flags, so this variable must have gotten them too. But I was wrong,
obviously. In such case, this is OK.
> It's at least implicitly tested as NULL is the default parameter
> value. I clarified that point in a comment. We might test the case
> of passing NULL explicitly too, but for now I've only made the comment
> clarification, preferring conciseness.
Ah, OK then.
It looks good to be merged.
--
Ticket URL: <http://bind10.isc.org/ticket/2905#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list