[bind10-dev] Zone loading requirements, take 1

[Michal 'vorner' Vaner]

Hello

On Tue, Mar 06, 2012 at 11:49:48AM +0100, Shane Kerr wrote:
> > The section 3.4.5 ‒ should NSEC be allowed as well?
> 
> Good catch.
> 
> I also added NSEC3 since in principle I could have a label that happens
> to be the same as a NSEC3 RR, right?

Well, as I get it, NSEC3s live in parallel astral plane and even if they look
like they have the same name, they are at a different domain. Anyway, that
doesn't mean they should not be allowed to live in the same place, so I'm not
against O:-).

> > When loading bogus data to zone, what does „Correct operation“
> > mean? ;-)
> 
> I didn't want to specify that, and it will probably be something we
> need to discuss on this list on a case-by-case basis. What I mean is
> that we should have some sort of well-defined behavior that all data
> sources implement. Should I add that to the definitions section to make
> it more explicit?

Maybe. Because it looked too much like „DWIM“.

> > Bogus class values ‒ instead of listing the correct ones, I think it
> > should say that it should load whatever the library supports. If we
> > add a new class to the library, there should be no work needed for
> > the loader to handle it.
> 
> There hasn't been a new class, ever. I suspect that it is actually
> impossible to add a new class to the DNS now - or at least something on
> the order of difficulty of DNSSEC adoption.
> 
> By leaving it open, I suspect a lot of implementations will leave out
> support for HS and CH. Probably that is okay, but then one never knows
> which classes are supported by which data sources without having to
> check. I thought it was easier just to specify them.

I didn't mean the data source support. I meant the library support. What I meant
was to make sure we use something like Class::fromText(cl) instead of:

if (cl == "IN") {
  return (Class::IN());
} else if (cl == "CH") {
  …
}

The first has the advantage that if libdns++ starts supporting new DARKNET class,
it starts to load it. It doesn't really matter the wide internet won't adopt the
class (but who knows, wait after my world domination of uncensorable Internet
succeeds…), someone might want to create a private experimental network and use
completely different address family there, so defining a new class for private
use.

> > Should infinite loops really be errors by default? This seems like a
> > perfect candidate for warning for me, the server can provide them
> > without much problem.
> 
> Hm... I have no strong preference, it just seemed like something pretty
> broken. Opinions from others?

I mean, errors are usually for things we can't parse, or things explicitly
forbidden or ambiguous (like NS and DS together in the same domain). The loop is
not forbidden by anything and it has pretty well defined result how it should
behave. And an admin might want to create a trap for bad implementations on
purpose. It seems to be broken the same way as a delegation without glue, for
example ‒ it won't work, but it is what is asked for.

With regards

-- 
The difficult we do today; the impossible takes a little longer.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120306/68f89142/attachment.bin>