[bind10-dev] Zone loading requirements, take 1

[Shane Kerr]

Michal,

On Saturday, 2012-03-03 14:45:38 +0100, 
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:
> Hello
> 
> On Fri, Mar 02, 2012 at 11:40:23AM +0100, Shane Kerr wrote:
> > In the spirit of old-style waterfall software engineering, we are
> > going to be doing more requirements documents. We know we need work
> > on our zone loader, so I've taken the liberty of typing some
> > requirements up. Here's a link to the current draft:
> > 
> > http://bind10.isc.org/wiki/ZoneLoadingRequirements
> 
> I've read through it and I'd have few questions about it.
> 
> Why do we need to load _into_ a data source? I mean, we could want to
> have an in-memory loaded from zone file, but the xfrout would want to
> send the data directly from the zone file. That way, there's no need
> to put it into intermediate data source, it would be more convenient
> if the loader itself could act as a datasource with the whole-zone
> iterator. Maybe we could have two levels, one would be just such
> loader with RR-level checks and then there'd be a copier from one
> data source to another, that'd to the zone-level checks? Also, it
> could be used to load sqlite3 to inmemory, or migrate from one
> database to another.

The reason that I specified that we have to load into a data source is
that the current problem BIND 10 is facing is that we need to load
zone files into our data sources. ;)

Remember that this is our REQUIREMENTS document. What you are proposing
sounds like it might be reasonable as far as the design goes.
 
> Would the profile be visible to user for modification, or would that
> be just a preset map<issue, bool> or something?

Good question. I was envisioning that an administrator might have to
support loading buggy zones that she cannot control, so may want to
allow specific errors to become warnings, or silence specific warnings.
Or on the other hand, she might want to make zone checking completely
strict, except for one specific behavior that she wants to be warned
about.

But this can be considered feature creep, and perhaps left for future
work.

> Why would be $INCLUDE forbidden when loading a stream? A stream might
> be a pipe from local program that'd generate the zone, but it could
> want to insert common parts from a file, or something.

Hm... well, I was basically thinking that streams would come from
sources that were disconnected from the file system, but I suppose you
are right - there is no special reason to disallow this.

If there are no objections I'll remove this (commented for now).

> I think our sqlite3/database backends don't handle literal dot in
> label correctly. Also, user can't really type them into the browser.
> Should we warn about it?

Hm... we used to say "DNS is more than e-mail", now I suppose it is
"DNS is more than the web". :-P 

I think that since you need to go out of your way to create a literal
dot in a label, we don't need to warn about it in the general case.

We discussed the issue about labels in the SQLite backend before:

https://lists.isc.org/pipermail/bind10-dev/2011-September/002630.html

I think we need to do two things:

1. Add a ticket to insure that we can store all ownernames, if we don't
   already have that (I don't see one, so I created #1761).
2. Add a requirement to the loader so that we do give a warning if the
   data source does not fully support any particular label. I've added
   that as requirement 3.6.7.
 
> 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?

> When loading bogus data to zone, what does „Correct operation“
> mean? ;-)

Yeah... not sure. :)

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?

> I looked into the RFC and it indeed does forbid for CNAME and DNAME
> to coexist in the same node. But is there a reason for this? DNAME
> redirects the things below the node, CNAME the things in the node, so
> there doesn't seem to be a place for confusion.

Not sure. CNAME/DNAME were before my time in the strange world of
DNS. :(

> 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.

> 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?

Thanks for the thorough review.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20120306/8c937443/attachment.bin>