Changes between Initial Version and Version 1 of April2013MeetingDNSWednesday20130417

Apr 26, 2013, 6:47:37 AM (5 years ago)

Added page for meetings on April 17 from my notes


  • April2013MeetingDNSWednesday20130417

    v1 v1  
     1= DNS meetings on Wednesday, April 17 2013 =
     3== BIND 10 logging ==
     4'''@1303 hrs'''
     7* Review of existing situation
     9Stephen explained the various log levels:
     10(README in logging directory describes FATAL errors result in termination. etc.)
     12Stephen: What do we do with suspect queries? We should maybe be warning about them, but at the moment, all of that is going out as a debug message
     13If someone can cause a query to BIND and cause a message to be logged, they can cause a DDoS attack.
     14Shane: Good example is unexpected NOTIFY messages. Right now these are INFO?
     15Jinmei: We changed to DEBUG.
     16Jinmei: This topic itself has lot of issues. Better to separate it from other low-level issues (which level of debug we're using)
     17Stephen: OK. Because of DDoS messages, everything can go down with DEBUG.
     18Shane: Talked about example of a message that should be DEBUG.
     19Tomek: What level should I log protocol violations?
     20Jinmei: What policy do we use for incoming messages in general? That itself is a big issue in the entire loglevel issues.
     22Stephen: So what level do we log protocol violations like?
     23Michal: We use a separate logger?
     24Tomek: I was thinking of a mechanism that would rate-limit log messages on a per-message basis (using the message id)
     25Stephen: We can have different logger for protocol violations
     26Tomek: If we go with one logger for protocol violations,
     27Michal: One feature I'm missing is a logger that can log into multiple destinations with different log levels
     28Stephen: We can log to multiple destinations with log4cplus, but it's not possible with our wrapper
     29Michal: We cannot specify different log levels for them
     31Shane: I want to address tomek's point. We have to strike a balance. We have to make a decision of what stuff we keep and what we throw away.
     32Tomek: We can have a knob provided to the administrator to rate limit
     33Michal: We should be able to filter specific log messages (log this one and don't log this one)
     34Shane: I like the idea of enabling rate limiting to solve DoS attacks
     35Jeremy: syslog has some rate limiting built into it
     36Stephen: So it logs the last message, remembers it and keeps a count of how many times it's been repeated
     37Mukund: Do we keep track of last timestamps on a per-message-id basis?
     38All: Yeah
     40Jeremy: We should be able to ask bindctl about NOTICEs
     41Michal: If we reload a zone for example, it's async and we never know it failed until we look into the logs
     43ACTION: We need to design and implement rate limiting
     45Tomek: Which level should I log "this client got this address" ?
     46Michal: DEBUG
     48More logging examples are shown:
     52: This get used for legal reasons. It can't be DEBUG 0.
     53Stephen: It can go to INFO, and if there's too much of it, it can go to a different logger. If there's still too much of it, we can disable that specific message.
     54Jinmei: Very frequent ones aren't considered INFO.
     55Tomek: When there's a protocol violation, do we use WARNING?
     56Tomek: Either there's an attack in progress, or some broken device on your network.
     57Mukund: We can't log every type of protocol violation as WARNINGs.
     59Tomek: For DHCPREQUEST and DHCPACK, what do we do?
     60Stephen: Log to a different logger, and enable it by default
     62Jinmei: I think we should log protocol violations at INFO level.
     63Stephen: Where we have reasonable control of clients, it is at WARNING. Otherwise it is DEBUG.
     64: We can have different categories of protocol violations.
     65Stephen: If it is recoverable, it can be at a DEBUG level.
     67Mukund: Will separate loggers log to different files?
     68Stephen: It may or may not. There is a lot of flexibility.
     70* Exceptions and logging
     72Stephen: Wherever we use exceptions, the text of the message is hardcoded into the program.
     73Stephen: Should we log where the exception is generated or someplace else?
     74Michal: I don't think we should log exception by default. It may be worth coupling exceptions with errors.
     76Stephen: Look at "Parameter not found" for example. It doesn't give you any clue as to what was wrong.
     78Shane: Stephen put some principles for logging, that all messages happen at one place in the code.
     79Jinmei: I don't understand what exactly is wrong.
     80Stephen: We can log line numbers and filenames where the exception happens, in the isc_throw() macro itself
     81Jinmei: We can provide some more context in the log messages describing the log message, etc. We can help admins that way.
     83* Local message files
     85Stephen: You can change the message text of the log messages (translations, etc.) by providing a new message file
     86Michal: You load auth server, override the log messages, then load the datasrc data source: that overwrites your localized messages
     87Stephen: Yes you would have to load them again.
     89* Should message files contain severity and debug level?
     91Shane, Stephen: No, because when you read the code, you can follow the severity.
     92Jinmei: Don't mention the log level in the description.
     93Jeremy: We log the debug level every time we log. That way an admin will know what log level to set when updating config.
     94ACTION: Create a ticket for this ^^
     100== Phone home ==
     102'''@1419 hrs'''
     105Shane: We don't know who's using our software. We are talking about making the software better, but we don't know who our users are and what their problems are.
     106Shane: Proposal is to add some way for our software to tell us that it's being used.
     107Shane: One previous proposal was to do a version check (by Michael Graff).
     108Shane: We want to get info about how people use our software without being sneaky about it. People are more comfortable allowing phone home now.
     109Michal: This is for something for marketing to figure out, and we just implement it.
     110Evan: Why is Michael Graff's way not good enough?
     111Shane: We can get more info such as OS information, etc.
     112Michal: We should have a way to turn it off.
     113Shane: We send the information upstream periodically.
     115Discussion about what the default setting should be happened. Concern that distros will turn it off by default.
     117Jinmei: What did Stephen mean by anonymization?
     118Shane: There are questions about how long to save the data, where we store the data collected, etc.
     119Stephen: We use a UUID, but we cannot find the IP address.
     121How do we send the data?
     122Shane: Michael suggested DNS, but we can use HTTP
     123Michal: we should send our data encrypted
     124Stephen: What info do we want to gather?
     125Mark: OS, architecture, OS version number, the output of uname -a with the hostname string
     126Jeremy: That gives my personal home directory info
     127Stephen: What are we going to use the info for?
     128Mark: What versions of BIND are being used, platforms and versions are using this, and what features are being used, configure options
     129Tomek: What about prefixes where things are installed?
     130Michal: What use is that?
     132Jeremy: We have some things collect and send things to us automatically, and have another program that sends us opt-in data by asking the user directly.
     133Jinmei: Do we know what kind of info that Firefox sends?
     134about:telemetry lists a lot of performance related data that is sent by a browser to Mozilla Corporation.
     136Shane: So we have a list of possible info. Initially we'll have 3 levels: completely off, version-only, version + some other info (features, arch, distro, compiler info, etc.)
     137Evan: Knowing someone is not using some feature may be useful, so we can deprecate it
     138Jinmei: I think we can simply list the compiler version too
     140Discussion on data retention. What if an attacker feeds us a lot of junk data if there's no way to uniquely identify a person?
     142Shane: We need a policy on storing this information.
     144More discussion on collection of data.
     146Shane: One idea that may reduce the negative feedback may be if we make the data open.
     150Mark: We can give summary information.
     151Stephen: People will not have problems with aggregate information being published.
     153Mark: If we want to track trends over time, we'll need data captured weekly to monthly.
     155What process sends this information?
     156Stephen: b10-init can send it
     158Shane: We should design this thing properly. We should ask our customers first, and if we get a really negative feedback...
     159Shane: We can write a blog article, post it to bind-users, try to get some interest and feel for what people want
     163== Databases ==
     165'''@1557 hrs'''
     168Stephen: DHCP uses MySQL. We need a common database update utility that will work on multiple database types.
     169Stephen: We want to increase the number of backends available. It seems logical to have common database update code.
     170Stephen: Do we want binary data in the database?
     171Shane: No as a lot of our users want to see text data.
     172Evan: We have both, and keep a hook to keep the blob/text synchronized.
     174Evan: Storing text and converting to binary has a big overhead. No hard numbers.
     175Stephen: Should we be thinking about using triggers/stored procedures?
     176Evan: Ultimately, yes it should be a part of our architecture
     178Some discussion on PowerDNS and its use of a database.
     180Jinmei: It may make sense to use binary data for DHCP, and not for DNS. What exactly are we discussing?
     181Stephen: It's on a per-application basis. Do what you want.
     183Stephen: Do we want to generalize dbutil?
     184All: Yes
     186Some discussion on differences between databases (SQL syntax and performance). Using the same SQL
     187statement may not be the best approach.
     189Stephen: Another point is versioning guidelines. At what point does the change in schema be significant?
     190Michal explained about minor and major versions in our current schema.
     195== Configuration improvements ==
     197'''@1622 hrs'''
     200Shane: Jelte did a braindump of configuration improvements right before he left.
     201Michal: I don't think there's more messy code than bindctl.
     203Shane: Had a discussion with Scott about user interface problems. Discusssed hiring a contractor for the UI.
     204Jinmei: The problem with bindctl is not at the UI layer, but the internal representation
     206Michal: The RESTful API may be the same, even though we change the internals.
     207Jinmei: At the interface level, we should think about organization of configuration, like the proposal from a few years ago.
     208Shane: Like the one from Jerry Scharf.
     210Shane: offline config: I like the plugin idea.
     211Shane: For custom types, IP addresses would be nice, but I don't think we need extensible types.
     212Stephen: What's the minimum work that we should do to bring bindctl to an acceptable level?
     213Shane: We probably want to fix most open bindctl bugs
     214Michal: If we are going for the minimum, then we get this quality of code because we are rushing.
     216Discussion that bindctl has a very verbose UI. We need some kind of a front-end.