[bind10-dev] NS/NSEC3/DNAME at wildcard

[Michal 'vorner' Vaner]

Hello

On Fri, Feb 04, 2011 at 01:51:49AM -0800, JINMEI Tatuya / 神明達哉 wrote:
> On the other hand, BIND 9 accepts DNAME RR at a wildcard name.  Both
> RFC4592 and draft-ietf-dnsext-rfc2672bis-dname-21 discourage such
> usage as strongly as they do so for NS at a wildcard.  So, if the
> reason BIND 9 rejects NS+wildcard was "because it's harmful even if
> it's not prohibited", it seems to me the same argument should apply to
> the DNAME case.
> 
> Now, what should we do for BIND 10?  My initial feeling is to keep the
> same behavior as BIND 9 for NS and NSEC 3 based on the least
> astonishment principle (even though it's "too strict" according to the
> protocol standards).  I'm not so sure about the case of DNAME and
> empty non terminal NSEC3, but I'm inclined to reject them as a natural
> extension of the (seeming) BIND 9 policy.
> 
> In any event, these are very minor cases and users probably just don't
> care.  But if someone has a specific opinion or suggestion (with
> reasons), please let me know (on this list).

I guess that it is probably minor enough to go with the easiest way to implement
it (so we wouldn't spend much time implementing something noone would use at
all). If we add a note that this is omitted simply because we don't think it is
useful and if someone needs it, to drop a mail, it should be OK I guess.

So, if rejecting it means less work and worrying about corner-cases, then I'm
for rejecting it.

Have a nice day

-- 
Einstein argued that there must be simplified explanations of nature, because
God is not capricious or arbitrary.  No such faith comforts the software
engineer.
                -- Fred Brooks

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110204/6c584927/attachment.bin>