[bind10-dev] b10-auth behaviour and builtin records and hot cache ...

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I won't be able to answer all your points, but here's a stab at some of them
(disclaimer, in some cases i will just explain what happens, not justify it ;))

On 06/21/2011 11:46 PM, Jeremy C. Reed wrote:
> 
> 1) notice some output is not using the new logging routines.
> 

yes afaik b10-auth has not had the new logging conversion yet


> 2) "DATASRC_META_ADD, adding a data source into meta data source"
> 
> This is generic, so I don't know why is repeated. Be more specific?
> 

Sounds like this is a pretty bad log message. Can we make it to at least print
what datasource is being added (if we leave this in)?


> 3) "[b10-auth] Xfrin session channel established."
> 
> I never started any b10-xfrin. Why or how established?
> 
> 4) "[b10-auth] Statistics session channel established."
>
> I never started any b10-stats. Why or how established?
>

It creates separate cc sessions for communication with xfrin and statistics
modules. It does not actually see if they are running (you can simply subscribe
to a channel whether or not someone is on there). A more general question would
be do we need that?

This does make me suspect that it'll show timeouts if you don't start xfrin and
you get a notify. Not that that is an option in bob at this point...


> 5) Some repeats:
> 
> Setting listen addresses:
>  10.53.0.1:53210
> Initialize TCP server at 10.53.0.1:53210
> Initialize UDP server at 10.53.0.1:53210
> 
> Why repeated?
> 

hmm, I suspect there is a call to handleconfigupdate too many.

(also for points 6 to 8)


> 
> 9) "[b10-auth] Loading TSIG keys"
> 
> What TSIG keys loaded?
> 
> I never configured any.
> 

empty list is also a list :p
(though indeed we might want to suppress this message, or show a different one
if there are none)


> 10)
> 
> 2011-06-21 16:54:27.q DEBUG [b10-auth.datasrc] DATASRC_QUERY_DELEGATION, 
> looking for delegation on the path to 'version.bind.'
> 
> Should it look at outside datasources before builtin?  Did we make this 
> decision? Where documented?
> 

That i do not know.

btw:
2011-06-21 16:54:27.q DEBUG [b10-auth.datasrc] DATASRC_QUERY_PROCESS, processing
query 'version.bind./CH' in the '%3' class

that log message is called wrong (or the message itself is wrong, note the CH in
query and %3 where it should be)


> 11) 
> 
> 2011-06-21 16:54:27.q DEBUG [b10-auth.datasrc] DATASRC_CACHE_NOT_FOUND, 
> the item 'version.bind.' was not found
> 2011-06-21 16:54:27.q DEBUG [b10-auth.datasrc] DATASRC_CACHE_NOT_FOUND, 
> the item 'version.bind.' was not found
> 
> Why repeated?
> 

I suspect that is an artifact of how the internals of the current data source
work, as it is searching for the right thing. This would suggest some cleanups
of logging points. Or a promise to do better in the refactors datasources


> 12)
> 
> 2011-06-21 16:54:27.q DEBUG [b10-auth.datasrc] DATASRC_CACHE_INSERT, 
> inserting item 'negative entry for version.bind. CH CNAME
> ' into the cache
> 
> Why insert a negative entry into hot cache for something that is built 
> in to the binary?
> 

Though i'm not completely sure, I suspect this is because in principle the
hotspot cache would not know what answers are 'built-in' or 'looked-up', or even
randomly generated depending on video captures of the neighbour's cat.


> 13) And why insert a CNAME?
> 

Now that is interesting, i would guess because there might have been one, and we
do need to check that.

The rest i don't know right now.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4B99wACgkQ4nZCKsdOncVJpACgr22ZFSIH0SI7zNuBkei0ZZhJ
g7gAoLqT5fPC/r/AyMyXGH9oXKIfCjW4
=q3BE
-----END PGP SIGNATURE-----