zorun
/
kea


			
				
					
						
						
							123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817818819820821822823824825826827828829830831832833834835836837838839840841842843844845846847848849850851852853854855856857858859860861862863864865866867868869870871872873874875876877878879880881882883884885886887888889890891892893894895896897898899900901902903904905906907908909910911912913914915916917918919920921922923924925926927928929930931932933934935936937938939940941942943944945946947948949950951952953954955956957958959960961962963964965966967968969970971972973974975976977978979980981982983984985986987988989990991992993994995996997998999100010011002100310041005100610071008100910101011101210131014101510161017101810191020102110221023102410251026102710281029103010311032103310341035103610371038103910401041104210431044104510461047104810491050105110521053105410551056105710581059106010611062106310641065106610671068106910701071107210731074107510761077107810791080108110821083108410851086108710881089109010911092109310941095109610971098109911001101110211031104110511061107110811091110111111121113111411151116111711181119112011211122112311241125112611271128112911301131113211331134113511361137113811391140114111421143114411451146114711481149115011511152115311541155115611571158115911601161116211631164116511661167116811691170117111721173117411751176117711781179118011811182118311841185118611871188118911901191119211931194119511961197119811991200120112021203120412051206120712081209121012111212121312141215121612171218121912201221122212231224122512261227122812291230123112321233123412351236123712381239124012411242124312441245124612471248124912501251125212531254125512561257125812591260126112621263126412651266126712681269127012711272127312741275127612771278127912801281128212831284128512861287128812891290129112921293129412951296129712981299130013011302130313041305130613071308130913101311131213131314131513161317131813191320132113221323132413251326132713281329133013311332133313341335133613371338133913401341134213431344134513461347134813491350135113521353135413551356135713581359136013611362136313641365136613671368136913701371137213731374137513761377137813791380138113821383138413851386138713881389139013911392139313941395139613971398139914001401140214031404140514061407140814091410141114121413141414151416141714181419142014211422142314241425142614271428142914301431143214331434143514361437143814391440144114421443144414451446144714481449145014511452145314541455145614571458145914601461146214631464146514661467146814691470147114721473147414751476147714781479148014811482148314841485148614871488148914901491149214931494149514961497149814991500150115021503150415051506150715081509151015111512151315141515151615171518151915201521152215231524152515261527152815291530153115321533153415351536153715381539154015411542154315441545154615471548154915501551155215531554155515561557155815591560156115621563156415651566156715681569157015711572157315741575157615771578157915801581158215831584158515861587158815891590159115921593159415951596159715981599160016011602160316041605160616071608160916101611161216131614161516161617161816191620162116221623162416251626162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653165416551656165716581659166016611662166316641665166616671668166916701671167216731674167516761677167816791680168116821683168416851686168716881689169016911692169316941695169616971698169917001701170217031704170517061707170817091710171117121713171417151716171717181719172017211722172317241725172617271728172917301731173217331734173517361737173817391740174117421743174417451746174717481749175017511752175317541755175617571758175917601761176217631764176517661767176817691770177117721773177417751776177717781779178017811782178317841785178617871788178917901791179217931794179517961797179817991800180118021803180418051806180718081809181018111812181318141815181618171818181918201821182218231824182518261827182818291830183118321833183418351836183718381839184018411842184318441845184618471848184918501851185218531854185518561857185818591860186118621863186418651866186718681869187018711872187318741875187618771878187918801881188218831884188518861887188818891890189118921893189418951896189718981899190019011902190319041905190619071908190919101911191219131914191519161917191819191920192119221923192419251926192719281929193019311932193319341935193619371938193919401941194219431944194519461947194819491950195119521953195419551956195719581959196019611962196319641965196619671968196919701971197219731974197519761977197819791980198119821983198419851986198719881989199019911992199319941995199619971998199920002001200220032004200520062007200820092010201120122013201420152016201720182019202020212022202320242025202620272028202920302031203220332034203520362037203820392040204120422043204420452046204720482049205020512052205320542055205620572058205920602061206220632064206520662067206820692070207120722073207420752076207720782079208020812082208320842085208620872088208920902091209220932094209520962097209820992100210121022103210421052106210721082109211021112112211321142115211621172118211921202121212221232124212521262127212821292130213121322133213421352136213721382139214021412142214321442145214621472148214921502151215221532154215521562157215821592160216121622163216421652166216721682169217021712172217321742175217621772178217921802181218221832184218521862187218821892190219121922193219421952196219721982199220022012202220322042205220622072208220922102211221222132214221522162217221822192220222122222223222422252226222722282229223022312232223322342235223622372238223922402241224222432244224522462247224822492250225122522253225422552256225722582259226022612262226322642265226622672268226922702271227222732274227522762277227822792280228122822283228422852286228722882289229022912292229322942295229622972298229923002301230223032304230523062307230823092310231123122313231423152316231723182319232023212322232323242325232623272328232923302331233223332334233523362337233823392340234123422343234423452346234723482349235023512352235323542355235623572358235923602361236223632364236523662367236823692370237123722373237423752376237723782379238023812382238323842385238623872388238923902391239223932394239523962397239823992400240124022403240424052406240724082409241024112412241324142415241624172418241924202421242224232424242524262427242824292430243124322433243424352436243724382439244024412442244324442445244624472448244924502451245224532454245524562457245824592460246124622463246424652466246724682469247024712472247324742475247624772478247924802481248224832484248524862487248824892490249124922493249424952496249724982499250025012502250325042505250625072508250925102511251225132514251525162517251825192520252125222523252425252526252725282529253025312532253325342535253625372538253925402541254225432544254525462547254825492550255125522553255425552556255725582559256025612562256325642565256625672568256925702571257225732574257525762577257825792580258125822583258425852586258725882589259025912592259325942595259625972598259926002601260226032604260526062607260826092610261126122613261426152616261726182619262026212622262326242625262626272628262926302631263226332634263526362637263826392640264126422643264426452646264726482649265026512652265326542655265626572658265926602661266226632664266526662667266826692670267126722673267426752676267726782679268026812682268326842685268626872688268926902691269226932694269526962697269826992700270127022703270427052706270727082709271027112712271327142715271627172718271927202721272227232724272527262727272827292730273127322733273427352736273727382739274027412742274327442745274627472748274927502751275227532754275527562757275827592760276127622763276427652766276727682769277027712772277327742775277627772778277927802781278227832784278527862787278827892790279127922793279427952796279727982799280028012802280328042805280628072808280928102811281228132814281528162817281828192820282128222823282428252826282728282829283028312832283328342835283628372838283928402841284228432844284528462847284828492850285128522853285428552856285728582859286028612862286328642865286628672868286928702871287228732874287528762877287828792880288128822883288428852886288728882889289028912892289328942895289628972898289929002901290229032904290529062907290829092910291129122913291429152916291729182919292029212922292329242925292629272928292929302931293229332934293529362937293829392940294129422943294429452946294729482949295029512952295329542955295629572958295929602961296229632964296529662967296829692970297129722973297429752976297729782979298029812982298329842985298629872988298929902991299229932994299529962997299829993000300130023003300430053006300730083009301030113012301330143015301630173018301930203021302230233024302530263027302830293030303130323033303430353036303730383039304030413042304330443045304630473048304930503051305230533054305530563057305830593060306130623063306430653066306730683069307030713072307330743075307630773078307930803081308230833084308530863087308830893090309130923093309430953096309730983099310031013102310331043105310631073108310931103111311231133114311531163117311831193120312131223123312431253126312731283129313031313132313331343135313631373138313931403141314231433144314531463147314831493150315131523153315431553156315731583159316031613162316331643165316631673168316931703171317231733174317531763177317831793180318131823183318431853186318731883189319031913192319331943195319631973198319932003201320232033204320532063207320832093210321132123213321432153216321732183219322032213222322332243225322632273228322932303231323232333234323532363237323832393240324132423243324432453246324732483249325032513252325332543255325632573258325932603261326232633264326532663267326832693270327132723273327432753276327732783279328032813282328332843285328632873288328932903291329232933294329532963297329832993300330133023303
							<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>BIND 10 Messages Manual</title><link rel="stylesheet" href="./bind10-guide.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><meta name="description" content="BIND 10 is a Domain Name System (DNS) suite managed by Internet Systems Consortium (ISC). It includes DNS libraries and modular components for controlling authoritative and recursive DNS servers. This is the messages manual for BIND 10 version 20120712. The most up-to-date version of this document, along with other documents for BIND 10, can be found at ."></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" title="BIND 10 Messages Manual"><div class="titlepage"><div><div><h1 class="title"><a name="id1168229451102"></a>BIND 10 Messages Manual</h1></div><div><p class="releaseinfo">This is the messages manual for BIND 10 version
        20120712.</p></div><div><p class="copyright">Copyright © 2011-2012 Internet Systems Consortium, Inc.</p></div><div><div class="abstract" title="Abstract"><p class="title"><b>Abstract</b></p><p>BIND 10 is a Domain Name System (DNS) suite managed by
	  Internet Systems Consortium (ISC). It includes DNS libraries
	  and modular components for controlling authoritative and
	  recursive DNS servers.
      </p><p>
        This is the messages manual for BIND 10 version 20120712.
	    The most up-to-date version of this document, along with
	    other documents for BIND 10, can be found at
        <a class="ulink" href="http://bind10.isc.org/docs" target="_top">http://bind10.isc.org/docs</a>.
      </p></div></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#intro">1. Introduction</a></span></dt><dt><span class="chapter"><a href="#messages">2. BIND 10 Messages</a></span></dt></dl></div><div class="chapter" title="Chapter 1. Introduction"><div class="titlepage"><div><div><h2 class="title"><a name="intro"></a>Chapter 1. Introduction</h2></div></div></div><p>
      This document lists each message that can be logged by the
      programs in the BIND 10 package.  Each entry in this manual
      is of the form:
      </p><pre class="screen">IDENTIFICATION message-text</pre><p>
      ... where "IDENTIFICATION" is the message identification included
      in each message logged and "message-text" is the accompanying
      message text.  The "message-text" may include placeholders of the
      form "%1", "%2" etc.; these parameters are replaced by relevant
      values when the message is logged.
    </p><p>
      Each entry is also accompanied by a description giving more
      information about the circumstances that result in the message
      being logged.
    </p><p>
      For information on configuring and using BIND 10 logging,
      refer to the <a class="ulink" href="bind10-guide.html" target="_top">BIND 10 Guide</a>.
    </p></div><div class="chapter" title="Chapter 2. BIND 10 Messages"><div class="titlepage"><div><div><h2 class="title"><a name="messages"></a>Chapter 2. BIND 10 Messages</h2></div></div></div><p>
      </p><div class="variablelist"><dl><dt><a name="ASIODNS_FD_ADD_TCP"></a><span class="term">ASIODNS_FD_ADD_TCP adding a new TCP server by opened fd %1</span></dt><dd><p>
A debug message informing about installing a file descriptor as a server.
The file descriptor number is noted.
</p></dd><dt><a name="ASIODNS_FD_ADD_UDP"></a><span class="term">ASIODNS_FD_ADD_UDP adding a new UDP server by opened fd %1</span></dt><dd><p>
A debug message informing about installing a file descriptor as a server.
The file descriptor number is noted.
</p></dd><dt><a name="ASIODNS_FETCH_COMPLETED"></a><span class="term">ASIODNS_FETCH_COMPLETED upstream fetch to %1(%2) has now completed</span></dt><dd><p>
A debug message, this records that the upstream fetch (a query made by the
resolver on behalf of its client) to the specified address has completed.
</p></dd><dt><a name="ASIODNS_FETCH_STOPPED"></a><span class="term">ASIODNS_FETCH_STOPPED upstream fetch to %1(%2) has been stopped</span></dt><dd><p>
An external component has requested the halting of an upstream fetch.  This
is an allowed operation, and the message should only appear if debug is
enabled.
</p></dd><dt><a name="ASIODNS_OPEN_SOCKET"></a><span class="term">ASIODNS_OPEN_SOCKET error %1 opening %2 socket to %3(%4)</span></dt><dd><p>
The asynchronous I/O code encountered an error when trying to open a socket
of the specified protocol in order to send a message to the target address.
The number of the system error that caused the problem is given in the
message.
</p></dd><dt><a name="ASIODNS_READ_DATA"></a><span class="term">ASIODNS_READ_DATA error %1 reading %2 data from %3(%4)</span></dt><dd><p>
The asynchronous I/O code encountered an error when trying to read data from
the specified address on the given protocol.  The number of the system
error that caused the problem is given in the message.
</p></dd><dt><a name="ASIODNS_READ_TIMEOUT"></a><span class="term">ASIODNS_READ_TIMEOUT receive timeout while waiting for data from %1(%2)</span></dt><dd><p>
An upstream fetch from the specified address timed out.  This may happen for
any number of reasons and is most probably a problem at the remote server
or a problem on the network.  The message will only appear if debug is
enabled.
</p></dd><dt><a name="ASIODNS_SEND_DATA"></a><span class="term">ASIODNS_SEND_DATA error %1 sending data using %2 to %3(%4)</span></dt><dd><p>
The asynchronous I/O code encountered an error when trying to send data to
the specified address on the given protocol.  The number of the system
error that caused the problem is given in the message.
</p></dd><dt><a name="ASIODNS_UNKNOWN_ORIGIN"></a><span class="term">ASIODNS_UNKNOWN_ORIGIN unknown origin for ASIO error code %1 (protocol: %2, address %3)</span></dt><dd><p>
An internal consistency check on the origin of a message from the
asynchronous I/O module failed. This may indicate an internal error;
please submit a bug report.
</p></dd><dt><a name="ASIODNS_UNKNOWN_RESULT"></a><span class="term">ASIODNS_UNKNOWN_RESULT unknown result (%1) when IOFetch::stop() was executed for I/O to %2(%3)</span></dt><dd><p>
An internal error indicating that the termination method of the resolver's
upstream fetch class was called with an unknown result code (which is
given in the message).  Please submit a bug report.
</p></dd><dt><a name="AUTH_AXFR_ERROR"></a><span class="term">AUTH_AXFR_ERROR error handling AXFR request: %1</span></dt><dd><p>
This is a debug message produced by the authoritative server when it
has encountered an error processing an AXFR request. The message gives
the reason for the error, and the server will return a SERVFAIL code to
the sender.
</p></dd><dt><a name="AUTH_AXFR_UDP"></a><span class="term">AUTH_AXFR_UDP AXFR query received over UDP</span></dt><dd><p>
This is a debug message output when the authoritative server has received
an AXFR query over UDP. Use of UDP for AXFRs is not permitted by the
protocol, so the server will return a FORMERR error to the sender.
</p></dd><dt><a name="AUTH_COMMAND_FAILED"></a><span class="term">AUTH_COMMAND_FAILED execution of command channel instruction '%1' failed: %2</span></dt><dd><p>
Execution of the specified command by the authoritative server failed. The
message contains the reason for the failure.
</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_CREATED"></a><span class="term">AUTH_CONFIG_CHANNEL_CREATED configuration session channel created</span></dt><dd><p>
This is a debug message indicating that authoritative server has created
the channel to the configuration manager.  It is issued during server
startup is an indication that the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_CONFIG_CHANNEL_ESTABLISHED configuration session channel established</span></dt><dd><p>
This is a debug message indicating that authoritative server
has established communication the configuration manager over the
previously-created channel. It is issued during server startup is an
indication that the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_CONFIG_CHANNEL_STARTED"></a><span class="term">AUTH_CONFIG_CHANNEL_STARTED configuration session channel started</span></dt><dd><p>
This is a debug message, issued when the authoritative server has
posted a request to be notified when new configuration information is
available. It is issued during server startup is an indication that
the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_CONFIG_LOAD_FAIL"></a><span class="term">AUTH_CONFIG_LOAD_FAIL load of configuration failed: %1</span></dt><dd><p>
An attempt to configure the server with information from the configuration
database during the startup sequence has failed. (The reason for
the failure is given in the message.) The server will continue its
initialization although it may not be configured in the desired way.
</p></dd><dt><a name="AUTH_CONFIG_UPDATE_FAIL"></a><span class="term">AUTH_CONFIG_UPDATE_FAIL update of configuration failed: %1</span></dt><dd><p>
At attempt to update the configuration the server with information
from the configuration database has failed, the reason being given in
the message.
</p></dd><dt><a name="AUTH_DATA_SOURCE"></a><span class="term">AUTH_DATA_SOURCE data source database file: %1</span></dt><dd><p>
This is a debug message produced by the authoritative server when it accesses a
datebase data source, listing the file that is being accessed.
</p></dd><dt><a name="AUTH_DNS_SERVICES_CREATED"></a><span class="term">AUTH_DNS_SERVICES_CREATED DNS services created</span></dt><dd><p>
This is a debug message indicating that the component that will handling
incoming queries for the authoritative server (DNSServices) has been
successfully created. It is issued during server startup is an indication
that the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_HEADER_PARSE_FAIL"></a><span class="term">AUTH_HEADER_PARSE_FAIL unable to parse header in received DNS packet: %1</span></dt><dd><p>
This is a debug message, generated by the authoritative server when an
attempt to parse the header of a received DNS packet has failed. (The
reason for the failure is given in the message.) The server will drop the
packet.
</p></dd><dt><a name="AUTH_INVALID_STATISTICS_DATA"></a><span class="term">AUTH_INVALID_STATISTICS_DATA invalid specification of statistics data specified</span></dt><dd><p>
An error was encountered when the authoritiative server specified
statistics data which is invalid for the auth specification file.
</p></dd><dt><a name="AUTH_LOAD_TSIG"></a><span class="term">AUTH_LOAD_TSIG loading TSIG keys</span></dt><dd><p>
This is a debug message indicating that the authoritative server
has requested the keyring holding TSIG keys from the configuration
database. It is issued during server startup is an indication that the
initialization is proceeding normally.
</p></dd><dt><a name="AUTH_LOAD_ZONE"></a><span class="term">AUTH_LOAD_ZONE loaded zone %1/%2</span></dt><dd><p>
This debug message is issued during the processing of the 'loadzone' command
when the authoritative server has successfully loaded the named zone of the
named class.
</p></dd><dt><a name="AUTH_MEM_DATASRC_DISABLED"></a><span class="term">AUTH_MEM_DATASRC_DISABLED memory data source is disabled for class %1</span></dt><dd><p>
This is a debug message reporting that the authoritative server has
discovered that the memory data source is disabled for the given class.
</p></dd><dt><a name="AUTH_MEM_DATASRC_ENABLED"></a><span class="term">AUTH_MEM_DATASRC_ENABLED memory data source is enabled for class %1</span></dt><dd><p>
This is a debug message reporting that the authoritative server has
discovered that the memory data source is enabled for the given class.
</p></dd><dt><a name="AUTH_MESSAGE_FORWARD_ERROR"></a><span class="term">AUTH_MESSAGE_FORWARD_ERROR failed to forward %1 request from %2: %3</span></dt><dd><p>
The authoritative server tried to forward some type DNS request
message to a separate process (e.g., forwarding dynamic update
requests to b10-ddns) to handle it, but it failed.  The authoritative
server returns SERVFAIL to the client on behalf of the separate
process.  The error could be configuration mismatch between b10-auth
and the recipient component, or it may be because the requests are
coming too fast and the receipient process cannot keep up with the
rate, or some system level failure.  In either case this means the
BIND 10 system is not working as expected, so the administrator should
look into the cause and address the issue.  The log message includes
the client's address (and port), and the error message sent from the
lower layer that detects the failure.
</p></dd><dt><a name="AUTH_NOTIFY_QUESTIONS"></a><span class="term">AUTH_NOTIFY_QUESTIONS invalid number of questions (%1) in incoming NOTIFY</span></dt><dd><p>
This debug message is logged by the authoritative server when it receives
a NOTIFY packet that contains zero or more than one question. (A valid
NOTIFY packet contains one question.) The server will return a FORMERR
error to the sender.
</p></dd><dt><a name="AUTH_NOTIFY_RRTYPE"></a><span class="term">AUTH_NOTIFY_RRTYPE invalid question RR type (%1) in incoming NOTIFY</span></dt><dd><p>
This debug message is logged by the authoritative server when it receives
a NOTIFY packet that an RR type of something other than SOA in the
question section. (The RR type received is included in the message.) The
server will return a FORMERR error to the sender.
</p></dd><dt><a name="AUTH_NO_STATS_SESSION"></a><span class="term">AUTH_NO_STATS_SESSION session interface for statistics is not available</span></dt><dd><p>
The authoritative server had no session with the statistics module at the
time it attempted to send it data: the attempt has been abandoned. This
could be an error in configuration.
</p></dd><dt><a name="AUTH_NO_XFRIN"></a><span class="term">AUTH_NO_XFRIN received NOTIFY but XFRIN session is not running</span></dt><dd><p>
This is a debug message produced by the authoritative server when it receives
a NOTIFY packet but the XFRIN process is not running. The packet will be
dropped and nothing returned to the sender.
</p></dd><dt><a name="AUTH_PACKET_PARSE_ERROR"></a><span class="term">AUTH_PACKET_PARSE_ERROR unable to parse received DNS packet: %1</span></dt><dd><p>
This is a debug message, generated by the authoritative server when an
attempt to parse a received DNS packet has failed due to something other
than a protocol error. The reason for the failure is given in the message;
the server will return a SERVFAIL error code to the sender.
</p></dd><dt><a name="AUTH_PACKET_PROTOCOL_ERROR"></a><span class="term">AUTH_PACKET_PROTOCOL_ERROR DNS packet protocol error: %1. Returning %2</span></dt><dd><p>
This is a debug message, generated by the authoritative server when an
attempt to parse a received DNS packet has failed due to a protocol error.
The reason for the failure is given in the message, as is the error code
that will be returned to the sender.
</p></dd><dt><a name="AUTH_PACKET_RECEIVED"></a><span class="term">AUTH_PACKET_RECEIVED message received:\n%1</span></dt><dd><p>
This is a debug message output by the authoritative server when it
receives a valid DNS packet.
</p><p>
Note: This message includes the packet received, rendered in the form of
multiple lines of text. For this reason, it is suggested that this log message
not be routed to the syslog file, where the multiple lines could confuse
programs that expect a format of one message per line.
</p></dd><dt><a name="AUTH_PROCESS_FAIL"></a><span class="term">AUTH_PROCESS_FAIL message processing failure: %1</span></dt><dd><p>
This message is generated by the authoritative server when it has
encountered an internal error whilst processing a received packet:
the cause of the error is included in the message.
</p><p>
The server will return a SERVFAIL error code to the sender of the packet.
This message indicates a potential error in the server.  Please open a
bug ticket for this issue.
</p></dd><dt><a name="AUTH_RECEIVED_COMMAND"></a><span class="term">AUTH_RECEIVED_COMMAND command '%1' received</span></dt><dd><p>
This is a debug message issued when the authoritative server has received
a command on the command channel.
</p></dd><dt><a name="AUTH_RECEIVED_NOTIFY"></a><span class="term">AUTH_RECEIVED_NOTIFY received incoming NOTIFY for zone name %1, zone class %2</span></dt><dd><p>
This is a debug message reporting that an incoming NOTIFY was received.
</p></dd><dt><a name="AUTH_RECEIVED_SENDSTATS"></a><span class="term">AUTH_RECEIVED_SENDSTATS command 'sendstats' received</span></dt><dd><p>
This is a debug message issued when the authoritative server has received
a command from the statistics module to send it data. The 'sendstats'
command is handled differently to other commands, which is why the debug
message associated with it has its own code.
</p></dd><dt><a name="AUTH_RESPONSE_FAILURE"></a><span class="term">AUTH_RESPONSE_FAILURE exception while building response to query: %1</span></dt><dd><p>
This is a debug message, generated by the authoritative server when an
attempt to create a response to a received DNS packet has failed. The
reason for the failure is given in the log message. A SERVFAIL response
is sent back. The most likely cause of this is an error in the data
source implementation; it is either creating bad responses or raising
exceptions itself.
</p></dd><dt><a name="AUTH_RESPONSE_FAILURE_UNKNOWN"></a><span class="term">AUTH_RESPONSE_FAILURE_UNKNOWN unknown exception while building response to query</span></dt><dd><p>
This debug message is similar to AUTH_RESPONSE_FAILURE, but further
details about the error are unknown, because it was signaled by something
which is not an exception. This is definitely a bug.
</p></dd><dt><a name="AUTH_RESPONSE_RECEIVED"></a><span class="term">AUTH_RESPONSE_RECEIVED received response message, ignoring</span></dt><dd><p>
This is a debug message, this is output if the authoritative server
receives a DNS packet with the QR bit set, i.e. a DNS response. The
server ignores the packet as it only responds to question packets.
</p></dd><dt><a name="AUTH_SEND_ERROR_RESPONSE"></a><span class="term">AUTH_SEND_ERROR_RESPONSE sending an error response (%1 bytes):\n%2</span></dt><dd><p>
This is a debug message recording that the authoritative server is sending
an error response to the originator of the query. A previous message will
have recorded details of the failure.
</p><p>
Note: This message includes the packet sent, rendered in the form of
multiple lines of text. For this reason, it is suggested that this log message
not be routed to the syslog file, where the multiple lines could confuse
programs that expect a format of one message per line.
</p></dd><dt><a name="AUTH_SEND_NORMAL_RESPONSE"></a><span class="term">AUTH_SEND_NORMAL_RESPONSE sending an error response (%1 bytes):\n%2</span></dt><dd><p>
This is a debug message recording that the authoritative server is sending
a response to the originator of a query.
</p><p>
Note: This message includes the packet sent, rendered in the form of
multiple lines of text. For this reason, it is suggested that this log message
not be routed to the syslog file, where the multiple lines could confuse
programs that expect a format of one message per line.
</p></dd><dt><a name="AUTH_SERVER_CREATED"></a><span class="term">AUTH_SERVER_CREATED server created</span></dt><dd><p>
An informational message indicating that the authoritative server process has
been created and is initializing. The AUTH_SERVER_STARTED message will be
output when initialization has successfully completed and the server starts
accepting queries.
</p></dd><dt><a name="AUTH_SERVER_FAILED"></a><span class="term">AUTH_SERVER_FAILED server failed: %1</span></dt><dd><p>
The authoritative server has encountered a fatal error and is terminating. The
reason for the failure is included in the message.
</p></dd><dt><a name="AUTH_SERVER_STARTED"></a><span class="term">AUTH_SERVER_STARTED server started</span></dt><dd><p>
Initialization of the authoritative server has completed successfully
and it is entering the main loop, waiting for queries to arrive.
</p></dd><dt><a name="AUTH_SHUTDOWN"></a><span class="term">AUTH_SHUTDOWN asked to stop, doing so</span></dt><dd><p>
This is a debug message indicating the server was asked to shut down and it is
complying to the request.
</p></dd><dt><a name="AUTH_SQLITE3"></a><span class="term">AUTH_SQLITE3 nothing to do for loading sqlite3</span></dt><dd><p>
This is a debug message indicating that the authoritative server has
found that the data source it is loading is an SQLite3 data source,
so no further validation is needed.
</p></dd><dt><a name="AUTH_START_DDNS_FORWARDER"></a><span class="term">AUTH_START_DDNS_FORWARDER DDNS UPDATE handling started</span></dt><dd><p>
This is a debug message indicating that b10-auth has received a message
that it should internally forward UPDATE message to b10-ddns. When b10-ddns
is not running, b10-auth will respond to UPDATE requests with rcode NOTIMP.
When b10-ddns is running, b10-ddns will handle and respond to the UPDATE
message.
</p></dd><dt><a name="AUTH_STATS_CHANNEL_CREATED"></a><span class="term">AUTH_STATS_CHANNEL_CREATED STATS session channel created</span></dt><dd><p>
This is a debug message indicating that the authoritative server has
created a channel to the statistics process.  It is issued during server
startup is an indication that the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_STATS_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_STATS_CHANNEL_ESTABLISHED STATS session channel established</span></dt><dd><p>
This is a debug message indicating that the authoritative server
has established communication over the previously created statistics
channel.  It is issued during server startup is an indication that the
initialization is proceeding normally.
</p></dd><dt><a name="AUTH_STATS_COMMS"></a><span class="term">AUTH_STATS_COMMS communication error in sending statistics data: %1</span></dt><dd><p>
An error was encountered when the authoritative server tried to send data
to the statistics daemon. The message includes additional information
describing the reason for the failure.
</p></dd><dt><a name="AUTH_STATS_TIMEOUT"></a><span class="term">AUTH_STATS_TIMEOUT timeout while sending statistics data: %1</span></dt><dd><p>
The authoritative server sent data to the statistics daemon but received
no acknowledgement within the specified time. The message includes
additional information describing the reason for the failure.
</p></dd><dt><a name="AUTH_STATS_TIMER_DISABLED"></a><span class="term">AUTH_STATS_TIMER_DISABLED statistics timer has been disabled</span></dt><dd><p>
This is a debug message indicating that the statistics timer has been
disabled in the authoritative server and no statistics information is
being produced.
</p></dd><dt><a name="AUTH_STATS_TIMER_SET"></a><span class="term">AUTH_STATS_TIMER_SET statistics timer set to %1 second(s)</span></dt><dd><p>
This is a debug message indicating that the statistics timer has been
enabled and that the authoritative server will produce statistics data
at the specified interval.
</p></dd><dt><a name="AUTH_STOP_DDNS_FORWARDER"></a><span class="term">AUTH_STOP_DDNS_FORWARDER DDNS UPDATE handling stopped</span></dt><dd><p>
This is a debug message indicating that b10-auth has received a message
that it should stop internally forwarding UPDATE message to b10-ddns.
b10-auth will no longer forward UPDATE messages to b10-ddns, but will
respond itself with error code NOTIMP.
This message is also logged when the forwarding is restarted (for instance
if b10-ddns is restarted and the internal connection needs to be created
again), in which case it should be followed by AUTH_START_DDNS_FORWARDER.
</p></dd><dt><a name="AUTH_UNSUPPORTED_OPCODE"></a><span class="term">AUTH_UNSUPPORTED_OPCODE unsupported opcode: %1</span></dt><dd><p>
This is a debug message, produced when a received DNS packet being
processed by the authoritative server has been found to contain an
unsupported opcode. (The opcode is included in the message.) The server
will return an error code of NOTIMPL to the sender.
</p></dd><dt><a name="AUTH_XFRIN_CHANNEL_CREATED"></a><span class="term">AUTH_XFRIN_CHANNEL_CREATED XFRIN session channel created</span></dt><dd><p>
This is a debug message indicating that the authoritative server has
created a channel to the XFRIN (Transfer-in) process.  It is issued
during server startup is an indication that the initialization is
proceeding normally.
</p></dd><dt><a name="AUTH_XFRIN_CHANNEL_ESTABLISHED"></a><span class="term">AUTH_XFRIN_CHANNEL_ESTABLISHED XFRIN session channel established</span></dt><dd><p>
This is a debug message indicating that the authoritative server has
established communication over the previously-created channel to the
XFRIN (Transfer-in) process.  It is issued during server startup is an
indication that the initialization is proceeding normally.
</p></dd><dt><a name="AUTH_ZONEMGR_COMMS"></a><span class="term">AUTH_ZONEMGR_COMMS error communicating with zone manager: %1</span></dt><dd><p>
This is a debug message output during the processing of a NOTIFY request.
An error (listed in the message) has been encountered whilst communicating
with the zone manager. The NOTIFY request will not be honored.
</p></dd><dt><a name="AUTH_ZONEMGR_ERROR"></a><span class="term">AUTH_ZONEMGR_ERROR received error response from zone manager: %1</span></dt><dd><p>
This is a debug message output during the processing of a NOTIFY
request. The zone manager component has been informed of the request,
but has returned an error response (which is included in the message). The
NOTIFY request will not be honored.
</p></dd><dt><a name="BIND10_CHECK_MSGQ_ALREADY_RUNNING"></a><span class="term">BIND10_CHECK_MSGQ_ALREADY_RUNNING checking if msgq is already running</span></dt><dd><p>
The boss process is starting up and will now check if the message bus
daemon is already running. If so, it will not be able to start, as it
needs a dedicated message bus.
</p></dd><dt><a name="BIND10_COMPONENT_FAILED"></a><span class="term">BIND10_COMPONENT_FAILED component %1 (pid %2) failed: %3</span></dt><dd><p>
The process terminated, but the bind10 boss didn't expect it to, which means
it must have failed.
</p></dd><dt><a name="BIND10_COMPONENT_RESTART"></a><span class="term">BIND10_COMPONENT_RESTART component %1 is about to restart</span></dt><dd><p>
The named component failed previously and we will try to restart it to provide
as flawless service as possible, but it should be investigated what happened,
as it could happen again.
</p></dd><dt><a name="BIND10_COMPONENT_START"></a><span class="term">BIND10_COMPONENT_START component %1 is starting</span></dt><dd><p>
The named component is about to be started by the boss process.
</p></dd><dt><a name="BIND10_COMPONENT_START_EXCEPTION"></a><span class="term">BIND10_COMPONENT_START_EXCEPTION component %1 failed to start: %2</span></dt><dd><p>
An exception (mentioned in the message) happened during the startup of the
named component. The componet is not considered started and further actions
will be taken about it.
</p></dd><dt><a name="BIND10_COMPONENT_STOP"></a><span class="term">BIND10_COMPONENT_STOP component %1 is being stopped</span></dt><dd><p>
A component is about to be asked to stop willingly by the boss.
</p></dd><dt><a name="BIND10_COMPONENT_UNSATISFIED"></a><span class="term">BIND10_COMPONENT_UNSATISFIED component %1 is required to run and failed</span></dt><dd><p>
A component failed for some reason (see previous messages). It is either a core
component or needed component that was just started. In any case, the system
can't continue without it and will terminate.
</p></dd><dt><a name="BIND10_CONFIGURATOR_BUILD"></a><span class="term">BIND10_CONFIGURATOR_BUILD building plan '%1' -&gt; '%2'</span></dt><dd><p>
A debug message. This indicates that the configurator is building a plan
how to change configuration from the older one to newer one. This does no
real work yet, it just does the planning what needs to be done.
</p></dd><dt><a name="BIND10_CONFIGURATOR_PLAN_INTERRUPTED"></a><span class="term">BIND10_CONFIGURATOR_PLAN_INTERRUPTED configurator plan interrupted, only %1 of %2 done</span></dt><dd><p>
There was an exception during some planned task. The plan will not continue and
only some tasks of the plan were completed. The rest is aborted. The exception
will be propagated.
</p></dd><dt><a name="BIND10_CONFIGURATOR_RECONFIGURE"></a><span class="term">BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components</span></dt><dd><p>
A different configuration of which components should be running is being
installed. All components that are no longer needed will be stopped and
newly introduced ones started. This happens at startup, when the configuration
is read the first time, or when an operator changes configuration of the boss.
</p></dd><dt><a name="BIND10_CONFIGURATOR_RUN"></a><span class="term">BIND10_CONFIGURATOR_RUN running plan of %1 tasks</span></dt><dd><p>
A debug message. The configurator is about to execute a plan of actions it
computed previously.
</p></dd><dt><a name="BIND10_CONFIGURATOR_START"></a><span class="term">BIND10_CONFIGURATOR_START bind10 component configurator is starting up</span></dt><dd><p>
The part that cares about starting and stopping the right component from the
boss process is starting up. This happens only once at the startup of the
boss process. It will start the basic set of processes now (the ones boss
needs to read the configuration), the rest will be started after the
configuration is known.
</p></dd><dt><a name="BIND10_CONFIGURATOR_STOP"></a><span class="term">BIND10_CONFIGURATOR_STOP bind10 component configurator is shutting down</span></dt><dd><p>
The part that cares about starting and stopping processes in the boss is
shutting down. All started components will be shut down now (more precisely,
asked to terminate by their own, if they fail to comply, other parts of
the boss process will try to force them).
</p></dd><dt><a name="BIND10_CONFIGURATOR_TASK"></a><span class="term">BIND10_CONFIGURATOR_TASK performing task %1 on %2</span></dt><dd><p>
A debug message. The configurator is about to perform one task of the plan it
is currently executing on the named component.
</p></dd><dt><a name="BIND10_INVALID_STATISTICS_DATA"></a><span class="term">BIND10_INVALID_STATISTICS_DATA invalid specification of statistics data specified</span></dt><dd><p>
An error was encountered when the boss module specified
statistics data which is invalid for the boss specification file.
</p></dd><dt><a name="BIND10_INVALID_USER"></a><span class="term">BIND10_INVALID_USER invalid user: %1</span></dt><dd><p>
The boss process was started with the -u option, to drop root privileges
and continue running as the specified user, but the user is unknown.
</p></dd><dt><a name="BIND10_KILLING_ALL_PROCESSES"></a><span class="term">BIND10_KILLING_ALL_PROCESSES killing all started processes</span></dt><dd><p>
The boss module was not able to start every process it needed to start
during startup, and will now kill the processes that did get started.
</p></dd><dt><a name="BIND10_KILL_PROCESS"></a><span class="term">BIND10_KILL_PROCESS killing process %1</span></dt><dd><p>
The boss module is sending a kill signal to process with the given name,
as part of the process of killing all started processes during a failed
startup, as described for BIND10_KILLING_ALL_PROCESSES
</p></dd><dt><a name="BIND10_LOST_SOCKET_CONSUMER"></a><span class="term">BIND10_LOST_SOCKET_CONSUMER consumer %1 of sockets disconnected, considering all its sockets closed</span></dt><dd><p>
A connection from one of the applications which requested a socket was
closed. This means the application has terminated, so all the sockets it was
using are now closed and bind10 process can release them as well, unless the
same sockets are used by yet another application.
</p></dd><dt><a name="BIND10_MSGQ_ALREADY_RUNNING"></a><span class="term">BIND10_MSGQ_ALREADY_RUNNING msgq daemon already running, cannot start</span></dt><dd><p>
There already appears to be a message bus daemon running. Either an
old process was not shut down correctly, and needs to be killed, or
another instance of BIND10, with the same msgq domain socket, is
running, which needs to be stopped.
</p></dd><dt><a name="BIND10_MSGQ_DISAPPEARED"></a><span class="term">BIND10_MSGQ_DISAPPEARED msgq channel disappeared</span></dt><dd><p>
While listening on the message bus channel for messages, it suddenly
disappeared. The msgq daemon may have died. This might lead to an
inconsistent state of the system, and BIND 10 will now shut down.
</p></dd><dt><a name="BIND10_NO_SOCKET"></a><span class="term">BIND10_NO_SOCKET couldn't send a socket for token %1 because of error: %2</span></dt><dd><p>
An error occurred when the bind10 process was asked to send a socket file
descriptor. The error is mentioned, most common reason is that the request
is invalid and may not come from bind10 process at all.
</p></dd><dt><a name="BIND10_PROCESS_ENDED"></a><span class="term">BIND10_PROCESS_ENDED process %2 of %1 ended with status %3</span></dt><dd><p>
This indicates a process started previously terminated. The process id
and component owning the process are indicated, as well as the exit code.
This doesn't distinguish if the process was supposed to terminate or not.
</p></dd><dt><a name="BIND10_READING_BOSS_CONFIGURATION"></a><span class="term">BIND10_READING_BOSS_CONFIGURATION reading boss configuration</span></dt><dd><p>
The boss process is starting up, and will now process the initial
configuration, as received from the configuration manager.
</p></dd><dt><a name="BIND10_RECEIVED_COMMAND"></a><span class="term">BIND10_RECEIVED_COMMAND received command: %1</span></dt><dd><p>
The boss module received a command and shall now process it. The command
is printed.
</p></dd><dt><a name="BIND10_RECEIVED_NEW_CONFIGURATION"></a><span class="term">BIND10_RECEIVED_NEW_CONFIGURATION received new configuration: %1</span></dt><dd><p>
The boss module received a configuration update and is going to apply
it now. The new configuration is printed.
</p></dd><dt><a name="BIND10_RECEIVED_SIGNAL"></a><span class="term">BIND10_RECEIVED_SIGNAL received signal %1</span></dt><dd><p>
The boss module received the given signal.
</p></dd><dt><a name="BIND10_RESURRECTED_PROCESS"></a><span class="term">BIND10_RESURRECTED_PROCESS resurrected %1 (PID %2)</span></dt><dd><p>
The given process has been restarted successfully, and is now running
with the given process id.
</p></dd><dt><a name="BIND10_RESURRECTING_PROCESS"></a><span class="term">BIND10_RESURRECTING_PROCESS resurrecting dead %1 process...</span></dt><dd><p>
The given process has ended unexpectedly, and is now restarted.
</p></dd><dt><a name="BIND10_SELECT_ERROR"></a><span class="term">BIND10_SELECT_ERROR error in select() call: %1</span></dt><dd><p>
There was a fatal error in the call to select(), used to see if a child
process has ended or if there is a message on the message bus. This
should not happen under normal circumstances and is considered fatal,
so BIND 10 will now shut down. The specific error is printed.
</p></dd><dt><a name="BIND10_SEND_SIGKILL"></a><span class="term">BIND10_SEND_SIGKILL sending SIGKILL to %1 (PID %2)</span></dt><dd><p>
The boss module is sending a SIGKILL signal to the given process.
</p></dd><dt><a name="BIND10_SEND_SIGTERM"></a><span class="term">BIND10_SEND_SIGTERM sending SIGTERM to %1 (PID %2)</span></dt><dd><p>
The boss module is sending a SIGTERM signal to the given process.
</p></dd><dt><a name="BIND10_SETGID"></a><span class="term">BIND10_SETGID setting GID to %1</span></dt><dd><p>
The boss switches the process group ID to the given value.  This happens
when BIND 10 starts with the -u option, and the group ID will be set to
that of the specified user.
</p></dd><dt><a name="BIND10_SETUID"></a><span class="term">BIND10_SETUID setting UID to %1</span></dt><dd><p>
The boss switches the user it runs as to the given UID.
</p></dd><dt><a name="BIND10_SHUTDOWN"></a><span class="term">BIND10_SHUTDOWN stopping the server</span></dt><dd><p>
The boss process received a command or signal telling it to shut down.
It will send a shutdown command to each process. The processes that do
not shut down will then receive a SIGTERM signal. If that doesn't work,
it shall send SIGKILL signals to the processes still alive.
</p></dd><dt><a name="BIND10_SHUTDOWN_COMPLETE"></a><span class="term">BIND10_SHUTDOWN_COMPLETE all processes ended, shutdown complete</span></dt><dd><p>
All child processes have been stopped, and the boss process will now
stop itself.
</p></dd><dt><a name="BIND10_SOCKCREATOR_BAD_CAUSE"></a><span class="term">BIND10_SOCKCREATOR_BAD_CAUSE unknown error cause from socket creator: %1</span></dt><dd><p>
The socket creator reported an error when creating a socket. But the function
which failed is unknown (not one of 'S' for socket or 'B' for bind).
</p></dd><dt><a name="BIND10_SOCKCREATOR_BAD_RESPONSE"></a><span class="term">BIND10_SOCKCREATOR_BAD_RESPONSE unknown response for socket request: %1</span></dt><dd><p>
The boss requested a socket from the creator, but the answer is unknown. This
looks like a programmer error.
</p></dd><dt><a name="BIND10_SOCKCREATOR_EOF"></a><span class="term">BIND10_SOCKCREATOR_EOF eof while expecting data from socket creator</span></dt><dd><p>
There should be more data from the socket creator, but it closed the socket.
It probably crashed.
</p></dd><dt><a name="BIND10_SOCKCREATOR_INIT"></a><span class="term">BIND10_SOCKCREATOR_INIT initializing socket creator parser</span></dt><dd><p>
The boss module initializes routines for parsing the socket creator
protocol.
</p></dd><dt><a name="BIND10_SOCKCREATOR_KILL"></a><span class="term">BIND10_SOCKCREATOR_KILL killing the socket creator</span></dt><dd><p>
The socket creator is being terminated the aggressive way, by sending it
sigkill. This should not happen usually.
</p></dd><dt><a name="BIND10_SOCKCREATOR_TERMINATE"></a><span class="term">BIND10_SOCKCREATOR_TERMINATE terminating socket creator</span></dt><dd><p>
The boss module sends a request to terminate to the socket creator.
</p></dd><dt><a name="BIND10_SOCKCREATOR_TRANSPORT_ERROR"></a><span class="term">BIND10_SOCKCREATOR_TRANSPORT_ERROR transport error when talking to the socket creator: %1</span></dt><dd><p>
Either sending or receiving data from the socket creator failed with the given
error. The creator probably crashed or some serious OS-level problem happened,
as the communication happens only on local host.
</p></dd><dt><a name="BIND10_SOCKET_CREATED"></a><span class="term">BIND10_SOCKET_CREATED successfully created socket %1</span></dt><dd><p>
The socket creator successfully created and sent a requested socket, it has
the given file number.
</p></dd><dt><a name="BIND10_SOCKET_ERROR"></a><span class="term">BIND10_SOCKET_ERROR error on %1 call in the creator: %2/%3</span></dt><dd><p>
The socket creator failed to create the requested socket. It failed on the
indicated OS API function with given error.
</p></dd><dt><a name="BIND10_SOCKET_GET"></a><span class="term">BIND10_SOCKET_GET requesting socket [%1]:%2 of type %3 from the creator</span></dt><dd><p>
The boss forwards a request for a socket to the socket creator.
</p></dd><dt><a name="BIND10_STARTED_CC"></a><span class="term">BIND10_STARTED_CC started configuration/command session</span></dt><dd><p>
Debug message given when BIND 10 has successfull started the object that
handles configuration and commands.
</p></dd><dt><a name="BIND10_STARTED_PROCESS"></a><span class="term">BIND10_STARTED_PROCESS started %1</span></dt><dd><p>
The given process has successfully been started.
</p></dd><dt><a name="BIND10_STARTED_PROCESS_PID"></a><span class="term">BIND10_STARTED_PROCESS_PID started %1 (PID %2)</span></dt><dd><p>
The given process has successfully been started, and has the given PID.
</p></dd><dt><a name="BIND10_STARTING"></a><span class="term">BIND10_STARTING starting BIND10: %1</span></dt><dd><p>
Informational message on startup that shows the full version.
</p></dd><dt><a name="BIND10_STARTING_CC"></a><span class="term">BIND10_STARTING_CC starting configuration/command session</span></dt><dd><p>
Informational message given when BIND 10 is starting the session object
that handles configuration and commands.
</p></dd><dt><a name="BIND10_STARTING_PROCESS"></a><span class="term">BIND10_STARTING_PROCESS starting process %1</span></dt><dd><p>
The boss module is starting the given process.
</p></dd><dt><a name="BIND10_STARTING_PROCESS_PORT"></a><span class="term">BIND10_STARTING_PROCESS_PORT starting process %1 (to listen on port %2)</span></dt><dd><p>
The boss module is starting the given process, which will listen on the
given port number.
</p></dd><dt><a name="BIND10_STARTING_PROCESS_PORT_ADDRESS"></a><span class="term">BIND10_STARTING_PROCESS_PORT_ADDRESS starting process %1 (to listen on %2#%3)</span></dt><dd><p>
The boss module is starting the given process, which will listen on the
given address and port number (written as &lt;address&gt;#&lt;port&gt;).
</p></dd><dt><a name="BIND10_STARTUP_COMPLETE"></a><span class="term">BIND10_STARTUP_COMPLETE BIND 10 started</span></dt><dd><p>
All modules have been successfully started, and BIND 10 is now running.
</p></dd><dt><a name="BIND10_STARTUP_ERROR"></a><span class="term">BIND10_STARTUP_ERROR error during startup: %1</span></dt><dd><p>
There was a fatal error when BIND10 was trying to start. The error is
shown, and BIND10 will now shut down.
</p></dd><dt><a name="BIND10_STARTUP_UNEXPECTED_MESSAGE"></a><span class="term">BIND10_STARTUP_UNEXPECTED_MESSAGE unrecognised startup message %1</span></dt><dd><p>
During the startup process, a number of messages are exchanged between the
Boss process and the processes it starts.  This error is output when a
message received by the Boss process is recognised as being of the
correct format but is unexpected.  It may be that processes are starting
of sequence.
</p></dd><dt><a name="BIND10_STARTUP_UNRECOGNISED_MESSAGE"></a><span class="term">BIND10_STARTUP_UNRECOGNISED_MESSAGE unrecognised startup message %1</span></dt><dd><p>
During the startup process, a number of messages are exchanged between the
Boss process and the processes it starts.  This error is output when a
message received by the Boss process is not recognised.
</p></dd><dt><a name="BIND10_START_AS_NON_ROOT_AUTH"></a><span class="term">BIND10_START_AS_NON_ROOT_AUTH starting b10-auth as a user, not root. This might fail.</span></dt><dd><p>
The authoritative server is being started or restarted without root privileges.
If the module needs these privileges, it may have problems starting.
Note that this issue should be resolved by the pending 'socket-creator'
process; once that has been implemented, modules should not need root
privileges anymore. See tickets #800 and #801 for more information.
</p></dd><dt><a name="BIND10_START_AS_NON_ROOT_RESOLVER"></a><span class="term">BIND10_START_AS_NON_ROOT_RESOLVER starting b10-resolver as a user, not root. This might fail.</span></dt><dd><p>
The resolver is being started or restarted without root privileges.
If the module needs these privileges, it may have problems starting.
Note that this issue should be resolved by the pending 'socket-creator'
process; once that has been implemented, modules should not need root
privileges anymore. See tickets #800 and #801 for more information.
</p></dd><dt><a name="BIND10_STOP_PROCESS"></a><span class="term">BIND10_STOP_PROCESS asking %1 to shut down</span></dt><dd><p>
The boss module is sending a shutdown command to the given module over
the message channel.
</p></dd><dt><a name="BIND10_UNKNOWN_CHILD_PROCESS_ENDED"></a><span class="term">BIND10_UNKNOWN_CHILD_PROCESS_ENDED unknown child pid %1 exited</span></dt><dd><p>
An unknown child process has exited. The PID is printed, but no further
action will be taken by the boss process.
</p></dd><dt><a name="BIND10_WAIT_CFGMGR"></a><span class="term">BIND10_WAIT_CFGMGR waiting for configuration manager process to initialize</span></dt><dd><p>
The configuration manager process is so critical to operation of BIND 10
that after starting it, the Boss module will wait for it to initialize
itself before continuing.  This debug message is produced during the
wait and may be output zero or more times depending on how long it takes
the configuration manager to start up.  The total length of time Boss
will wait for the configuration manager before reporting an error is
set with the command line --wait switch, which has a default value of
ten seconds.
</p></dd><dt><a name="CACHE_ENTRY_MISSING_RRSET"></a><span class="term">CACHE_ENTRY_MISSING_RRSET missing RRset to generate message for %1</span></dt><dd><p>
The cache tried to generate the complete answer message. It knows the structure
of the message, but some of the RRsets to be put there are not in cache (they
probably expired already). Therefore it pretends the message was not found.
</p></dd><dt><a name="CACHE_LOCALZONE_FOUND"></a><span class="term">CACHE_LOCALZONE_FOUND found entry with key %1 in local zone data</span></dt><dd><p>
Debug message, noting that the requested data was successfully found in the
local zone data of the cache.
</p></dd><dt><a name="CACHE_LOCALZONE_UNKNOWN"></a><span class="term">CACHE_LOCALZONE_UNKNOWN entry with key %1 not found in local zone data</span></dt><dd><p>
Debug message. The requested data was not found in the local zone data.
</p></dd><dt><a name="CACHE_LOCALZONE_UPDATE"></a><span class="term">CACHE_LOCALZONE_UPDATE updating local zone element at key %1</span></dt><dd><p>
Debug message issued when there's update to the local zone section of cache.
</p></dd><dt><a name="CACHE_MESSAGES_DEINIT"></a><span class="term">CACHE_MESSAGES_DEINIT deinitialized message cache</span></dt><dd><p>
Debug message. It is issued when the server deinitializes the message cache.
</p></dd><dt><a name="CACHE_MESSAGES_EXPIRED"></a><span class="term">CACHE_MESSAGES_EXPIRED found an expired message entry for %1 in the message cache</span></dt><dd><p>
Debug message. The requested data was found in the message cache, but it
already expired. Therefore the cache removes the entry and pretends it found
nothing.
</p></dd><dt><a name="CACHE_MESSAGES_FOUND"></a><span class="term">CACHE_MESSAGES_FOUND found a message entry for %1 in the message cache</span></dt><dd><p>
Debug message. We found the whole message in the cache, so it can be returned
to user without any other lookups.
</p></dd><dt><a name="CACHE_MESSAGES_INIT"></a><span class="term">CACHE_MESSAGES_INIT initialized message cache for %1 messages of class %2</span></dt><dd><p>
Debug message issued when a new message cache is issued. It lists the class
of messages it can hold and the maximum size of the cache.
</p></dd><dt><a name="CACHE_MESSAGES_REMOVE"></a><span class="term">CACHE_MESSAGES_REMOVE removing old instance of %1/%2/%3 first</span></dt><dd><p>
Debug message. This may follow CACHE_MESSAGES_UPDATE and indicates that, while
updating, the old instance is being removed prior of inserting a new one.
</p></dd><dt><a name="CACHE_MESSAGES_UNCACHEABLE"></a><span class="term">CACHE_MESSAGES_UNCACHEABLE not inserting uncacheable message %1/%2/%3</span></dt><dd><p>
Debug message, noting that the given message can not be cached. This is because
there's no SOA record in the message. See RFC 2308 section 5 for more
information.
</p></dd><dt><a name="CACHE_MESSAGES_UNKNOWN"></a><span class="term">CACHE_MESSAGES_UNKNOWN no entry for %1 found in the message cache</span></dt><dd><p>
Debug message. The message cache didn't find any entry for the given key.
</p></dd><dt><a name="CACHE_MESSAGES_UPDATE"></a><span class="term">CACHE_MESSAGES_UPDATE updating message entry %1/%2/%3</span></dt><dd><p>
Debug message issued when the message cache is being updated with a new
message. Either the old instance is removed or, if none is found, new one
is created.
</p></dd><dt><a name="CACHE_RESOLVER_DEEPEST"></a><span class="term">CACHE_RESOLVER_DEEPEST looking up deepest NS for %1/%2</span></dt><dd><p>
Debug message. The resolver cache is looking up the deepest known nameserver,
so the resolution doesn't have to start from the root.
</p></dd><dt><a name="CACHE_RESOLVER_INIT"></a><span class="term">CACHE_RESOLVER_INIT initializing resolver cache for class %1</span></dt><dd><p>
Debug message. The resolver cache is being created for this given class.
</p></dd><dt><a name="CACHE_RESOLVER_INIT_INFO"></a><span class="term">CACHE_RESOLVER_INIT_INFO initializing resolver cache for class %1</span></dt><dd><p>
Debug message, the resolver cache is being created for this given class. The
difference from CACHE_RESOLVER_INIT is only in different format of passed
information, otherwise it does the same.
</p></dd><dt><a name="CACHE_RESOLVER_LOCAL_MSG"></a><span class="term">CACHE_RESOLVER_LOCAL_MSG message for %1/%2 found in local zone data</span></dt><dd><p>
Debug message. The resolver cache found a complete message for the user query
in the zone data.
</p></dd><dt><a name="CACHE_RESOLVER_LOCAL_RRSET"></a><span class="term">CACHE_RESOLVER_LOCAL_RRSET RRset for %1/%2 found in local zone data</span></dt><dd><p>
Debug message. The resolver cache found a requested RRset in the local zone
data.
</p></dd><dt><a name="CACHE_RESOLVER_LOOKUP_MSG"></a><span class="term">CACHE_RESOLVER_LOOKUP_MSG looking up message in resolver cache for %1/%2</span></dt><dd><p>
Debug message. The resolver cache is trying to find a message to answer the
user query.
</p></dd><dt><a name="CACHE_RESOLVER_LOOKUP_RRSET"></a><span class="term">CACHE_RESOLVER_LOOKUP_RRSET looking up RRset in resolver cache for %1/%2</span></dt><dd><p>
Debug message. The resolver cache is trying to find an RRset (which usually
originates as internally from resolver).
</p></dd><dt><a name="CACHE_RESOLVER_NO_QUESTION"></a><span class="term">CACHE_RESOLVER_NO_QUESTION answer message for %1/%2 has empty question section</span></dt><dd><p>
The cache tried to fill in found data into the response message. But it
discovered the message contains no question section, which is invalid.
This is likely a programmer error, please submit a bug report.
</p></dd><dt><a name="CACHE_RESOLVER_UNKNOWN_CLASS_MSG"></a><span class="term">CACHE_RESOLVER_UNKNOWN_CLASS_MSG no cache for class %1</span></dt><dd><p>
Debug message. While trying to lookup a message in the resolver cache, it was
discovered there's no cache for this class at all. Therefore no message is
found.
</p></dd><dt><a name="CACHE_RESOLVER_UNKNOWN_CLASS_RRSET"></a><span class="term">CACHE_RESOLVER_UNKNOWN_CLASS_RRSET no cache for class %1</span></dt><dd><p>
Debug message. While trying to lookup an RRset in the resolver cache, it was
discovered there's no cache for this class at all. Therefore no data is found.
</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_MSG"></a><span class="term">CACHE_RESOLVER_UPDATE_MSG updating message for %1/%2/%3</span></dt><dd><p>
Debug message. The resolver is updating a message in the cache.
</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_RRSET"></a><span class="term">CACHE_RESOLVER_UPDATE_RRSET updating RRset for %1/%2/%3</span></dt><dd><p>
Debug message. The resolver is updating an RRset in the cache.
</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG"></a><span class="term">CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_MSG no cache for class %1</span></dt><dd><p>
Debug message. While trying to insert a message into the cache, it was
discovered that there's no cache for the class of message. Therefore
the message will not be cached.
</p></dd><dt><a name="CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET"></a><span class="term">CACHE_RESOLVER_UPDATE_UNKNOWN_CLASS_RRSET no cache for class %1</span></dt><dd><p>
Debug message. While trying to insert an RRset into the cache, it was
discovered that there's no cache for the class of the RRset. Therefore
the message will not be cached.
</p></dd><dt><a name="CACHE_RRSET_EXPIRED"></a><span class="term">CACHE_RRSET_EXPIRED found expired RRset %1/%2/%3</span></dt><dd><p>
Debug message. The requested data was found in the RRset cache. However, it is
expired, so the cache removed it and is going to pretend nothing was found.
</p></dd><dt><a name="CACHE_RRSET_INIT"></a><span class="term">CACHE_RRSET_INIT initializing RRset cache for %1 RRsets of class %2</span></dt><dd><p>
Debug message. The RRset cache to hold at most this many RRsets for the given
class is being created.
</p></dd><dt><a name="CACHE_RRSET_LOOKUP"></a><span class="term">CACHE_RRSET_LOOKUP looking up %1/%2/%3 in RRset cache</span></dt><dd><p>
Debug message. The resolver is trying to look up data in the RRset cache.
</p></dd><dt><a name="CACHE_RRSET_NOT_FOUND"></a><span class="term">CACHE_RRSET_NOT_FOUND no RRset found for %1/%2/%3 in cache</span></dt><dd><p>
Debug message which can follow CACHE_RRSET_LOOKUP. This means the data is not
in the cache.
</p></dd><dt><a name="CACHE_RRSET_REMOVE_OLD"></a><span class="term">CACHE_RRSET_REMOVE_OLD removing old RRset for %1/%2/%3 to make space for new one</span></dt><dd><p>
Debug message which can follow CACHE_RRSET_UPDATE. During the update, the cache
removed an old instance of the RRset to replace it with the new one.
</p></dd><dt><a name="CACHE_RRSET_UNTRUSTED"></a><span class="term">CACHE_RRSET_UNTRUSTED not replacing old RRset for %1/%2/%3, it has higher trust level</span></dt><dd><p>
Debug message which can follow CACHE_RRSET_UPDATE. The cache already holds the
same RRset, but from more trusted source, so the old one is kept and new one
ignored.
</p></dd><dt><a name="CACHE_RRSET_UPDATE"></a><span class="term">CACHE_RRSET_UPDATE updating RRset %1/%2/%3 in the cache</span></dt><dd><p>
Debug message. The RRset is updating its data with this given RRset.
</p></dd><dt><a name="CC_ASYNC_READ_FAILED"></a><span class="term">CC_ASYNC_READ_FAILED asynchronous read failed (error code = %1)</span></dt><dd><p>
This marks a low level error, we tried to read data from the message queue
daemon asynchronously, but the ASIO library returned an error.
</p></dd><dt><a name="CC_CONN_ERROR"></a><span class="term">CC_CONN_ERROR error connecting to message queue (%1)</span></dt><dd><p>
It is impossible to reach the message queue daemon for the reason given. It
is unlikely there'll be reason for whatever program this currently is to
continue running, as the communication with the rest of BIND 10 is vital
for the components.
</p></dd><dt><a name="CC_DISCONNECT"></a><span class="term">CC_DISCONNECT disconnecting from message queue daemon</span></dt><dd><p>
The library is disconnecting from the message queue daemon. This debug message
indicates that the program is trying to shut down gracefully.
</p></dd><dt><a name="CC_ESTABLISH"></a><span class="term">CC_ESTABLISH trying to establish connection with message queue daemon at %1</span></dt><dd><p>
This debug message indicates that the command channel library is about to
connect to the message queue daemon, which should be listening on the UNIX-domain
socket listed in the output.
</p></dd><dt><a name="CC_ESTABLISHED"></a><span class="term">CC_ESTABLISHED successfully connected to message queue daemon</span></dt><dd><p>
This debug message indicates that the connection was successfully made, this
should follow CC_ESTABLISH.
</p></dd><dt><a name="CC_GROUP_RECEIVE"></a><span class="term">CC_GROUP_RECEIVE trying to receive a message</span></dt><dd><p>
Debug message, noting that a message is expected to come over the command
channel.
</p></dd><dt><a name="CC_GROUP_RECEIVED"></a><span class="term">CC_GROUP_RECEIVED message arrived ('%1', '%2')</span></dt><dd><p>
Debug message, noting that we successfully received a message (its envelope and
payload listed). This follows CC_GROUP_RECEIVE, but might happen some time
later, depending if we waited for it or just polled.
</p></dd><dt><a name="CC_GROUP_SEND"></a><span class="term">CC_GROUP_SEND sending message '%1' to group '%2'</span></dt><dd><p>
Debug message, we're about to send a message over the command channel.
</p></dd><dt><a name="CC_INVALID_LENGTHS"></a><span class="term">CC_INVALID_LENGTHS invalid length parameters (%1, %2)</span></dt><dd><p>
This happens when garbage comes over the command channel or some kind of
confusion happens in the program. The data received from the socket make no
sense if we interpret it as lengths of message. The first one is total length
of the message; the second is the length of the header. The header
and its length (2 bytes) is counted in the total length.
</p></dd><dt><a name="CC_LENGTH_NOT_READY"></a><span class="term">CC_LENGTH_NOT_READY length not ready</span></dt><dd><p>
There should be data representing the length of message on the socket, but it
is not there.
</p></dd><dt><a name="CC_NO_MESSAGE"></a><span class="term">CC_NO_MESSAGE no message ready to be received yet</span></dt><dd><p>
The program polled for incoming messages, but there was no message waiting.
This is a debug message which may happen only after CC_GROUP_RECEIVE.
</p></dd><dt><a name="CC_NO_MSGQ"></a><span class="term">CC_NO_MSGQ unable to connect to message queue (%1)</span></dt><dd><p>
It isn't possible to connect to the message queue daemon, for reason listed.
It is unlikely any program will be able continue without the communication.
</p></dd><dt><a name="CC_READ_ERROR"></a><span class="term">CC_READ_ERROR error reading data from command channel (%1)</span></dt><dd><p>
A low level error happened when the library tried to read data from the
command channel socket. The reason is listed.
</p></dd><dt><a name="CC_READ_EXCEPTION"></a><span class="term">CC_READ_EXCEPTION error reading data from command channel (%1)</span></dt><dd><p>
We received an exception while trying to read data from the command
channel socket. The reason is listed.
</p></dd><dt><a name="CC_REPLY"></a><span class="term">CC_REPLY replying to message from '%1' with '%2'</span></dt><dd><p>
Debug message, noting we're sending a response to the original message
with the given envelope.
</p></dd><dt><a name="CC_SET_TIMEOUT"></a><span class="term">CC_SET_TIMEOUT setting timeout to %1ms</span></dt><dd><p>
Debug message. A timeout for which the program is willing to wait for a reply
is being set.
</p></dd><dt><a name="CC_START_READ"></a><span class="term">CC_START_READ starting asynchronous read</span></dt><dd><p>
Debug message. From now on, when a message (or command) comes, it'll wake the
program and the library will automatically pass it over to correct place.
</p></dd><dt><a name="CC_SUBSCRIBE"></a><span class="term">CC_SUBSCRIBE subscribing to communication group %1</span></dt><dd><p>
Debug message. The program wants to receive messages addressed to this group.
</p></dd><dt><a name="CC_TIMEOUT"></a><span class="term">CC_TIMEOUT timeout reading data from command channel</span></dt><dd><p>
The program waited too long for data from the command channel (usually when it
sent a query to different program and it didn't answer for whatever reason).
</p></dd><dt><a name="CC_UNSUBSCRIBE"></a><span class="term">CC_UNSUBSCRIBE unsubscribing from communication group %1</span></dt><dd><p>
Debug message. The program no longer wants to receive messages addressed to
this group.
</p></dd><dt><a name="CC_WRITE_ERROR"></a><span class="term">CC_WRITE_ERROR error writing data to command channel (%1)</span></dt><dd><p>
A low level error happened when the library tried to write data to the command
channel socket.
</p></dd><dt><a name="CC_ZERO_LENGTH"></a><span class="term">CC_ZERO_LENGTH invalid message length (0)</span></dt><dd><p>
The library received a message length being zero, which makes no sense, since
all messages must contain at least the envelope.
</p></dd><dt><a name="CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE"></a><span class="term">CFGMGR_AUTOMATIC_CONFIG_DATABASE_UPDATE Updating configuration database from version %1 to %2</span></dt><dd><p>
An older version of the configuration database has been found, from which
there was an automatic upgrade path to the current version. These changes
are now applied, and no action from the administrator is necessary.
</p></dd><dt><a name="CFGMGR_BACKED_UP_CONFIG_FILE"></a><span class="term">CFGMGR_BACKED_UP_CONFIG_FILE Config file %1 was removed; a backup was made at %2</span></dt><dd><p>
BIND 10 has been started with the command to clear the configuration
file.  The existing file has been backed up (moved) to the given file
name. A new configuration file will be created in the original location
when necessary.
</p></dd><dt><a name="CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE"></a><span class="term">CFGMGR_BAD_UPDATE_RESPONSE_FROM_MODULE Unable to parse response from module %1: %2</span></dt><dd><p>
The configuration manager sent a configuration update to a module, but
the module responded with an answer that could not be parsed. The answer
message appears to be invalid JSON data, or not decodable to a string.
This is likely to be a problem in the module in question. The update is
assumed to have failed, and will not be stored.
</p></dd><dt><a name="CFGMGR_CC_SESSION_ERROR"></a><span class="term">CFGMGR_CC_SESSION_ERROR Error connecting to command channel: %1</span></dt><dd><p>
The configuration manager daemon was unable to connect to the messaging
system. The most likely cause is that msgq is not running.
</p></dd><dt><a name="CFGMGR_CONFIG_FILE"></a><span class="term">CFGMGR_CONFIG_FILE Configuration manager starting with configuration file: %1</span></dt><dd><p>
The configuration manager is starting, reading and saving the configuration
settings to the shown file.
</p></dd><dt><a name="CFGMGR_DATA_READ_ERROR"></a><span class="term">CFGMGR_DATA_READ_ERROR error reading configuration database from disk: %1</span></dt><dd><p>
There was a problem reading the persistent configuration data as stored
on disk. The file may be corrupted, or it is of a version from where
there is no automatic upgrade path. The file needs to be repaired or
removed. The configuration manager daemon will now shut down.
</p></dd><dt><a name="CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION"></a><span class="term">CFGMGR_IOERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</span></dt><dd><p>
There was an IO error from the system while the configuration manager
was trying to write the configuration database to disk. The specific
error is given. The most likely cause is that the directory where
the file is stored does not exist, or is not writable. The updated
configuration is not stored.
</p></dd><dt><a name="CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION"></a><span class="term">CFGMGR_OSERROR_WHILE_WRITING_CONFIGURATION Unable to write configuration file; configuration not stored: %1</span></dt><dd><p>
There was an OS error from the system while the configuration manager
was trying to write the configuration database to disk. The specific
error is given. The most likely cause is that the system does not have
write access to the configuration database file. The updated
configuration is not stored.
</p></dd><dt><a name="CFGMGR_STOPPED_BY_KEYBOARD"></a><span class="term">CFGMGR_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the cfgmgr daemon. The
daemon will now shut down.
</p></dd><dt><a name="CMDCTL_BAD_CONFIG_DATA"></a><span class="term">CMDCTL_BAD_CONFIG_DATA error in config data: %1</span></dt><dd><p>
There was an error reading the updated configuration data. The specific
error is printed.
</p></dd><dt><a name="CMDCTL_BAD_PASSWORD"></a><span class="term">CMDCTL_BAD_PASSWORD bad password for user: %1</span></dt><dd><p>
A login attempt was made to b10-cmdctl, but the password was wrong.
Users can be managed with the tool b10-cmdctl-usermgr.
</p></dd><dt><a name="CMDCTL_CC_SESSION_ERROR"></a><span class="term">CMDCTL_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
There was a problem reading from the command and control channel. The
most likely cause is that the message bus daemon is not running.
</p></dd><dt><a name="CMDCTL_CC_SESSION_TIMEOUT"></a><span class="term">CMDCTL_CC_SESSION_TIMEOUT timeout on cc channel</span></dt><dd><p>
A timeout occurred when waiting for essential data from the cc session.
This usually occurs when b10-cfgmgr is not running or not responding.
Since we are waiting for essential information, this is a fatal error,
and the cmdctl daemon will now shut down.
</p></dd><dt><a name="CMDCTL_COMMAND_ERROR"></a><span class="term">CMDCTL_COMMAND_ERROR error in command %1 to module %2: %3</span></dt><dd><p>
An error was encountered sending the given command to the given module.
Either there was a communication problem with the module, or the module
was not able to process the command, and sent back an error. The
specific error is printed in the message.
</p></dd><dt><a name="CMDCTL_COMMAND_SENT"></a><span class="term">CMDCTL_COMMAND_SENT command '%1' to module '%2' was sent</span></dt><dd><p>
This debug message indicates that the given command has been sent to
the given module.
</p></dd><dt><a name="CMDCTL_NO_SUCH_USER"></a><span class="term">CMDCTL_NO_SUCH_USER username not found in user database: %1</span></dt><dd><p>
A login attempt was made to b10-cmdctl, but the username was not known.
Users can be added with the tool b10-cmdctl-usermgr.
</p></dd><dt><a name="CMDCTL_NO_USER_ENTRIES_READ"></a><span class="term">CMDCTL_NO_USER_ENTRIES_READ failed to read user information, all users will be denied</span></dt><dd><p>
The b10-cmdctl daemon was unable to find any user data in the user
database file. Either it was unable to read the file (in which case
this message follows a message CMDCTL_USER_DATABASE_READ_ERROR
containing a specific error), or the file was empty. Users can be added
with the tool b10-cmdctl-usermgr.
</p></dd><dt><a name="CMDCTL_SEND_COMMAND"></a><span class="term">CMDCTL_SEND_COMMAND sending command %1 to module %2</span></dt><dd><p>
This debug message indicates that the given command is being sent to
the given module.
</p></dd><dt><a name="CMDCTL_SSL_SETUP_FAILURE_USER_DENIED"></a><span class="term">CMDCTL_SSL_SETUP_FAILURE_USER_DENIED failed to create an SSL connection (user denied): %1</span></dt><dd><p>
The user was denied because the SSL connection could not successfully
be set up. The specific error is given in the log message. Possible
causes may be that the ssl request itself was bad, or the local key or
certificate file could not be read.
</p></dd><dt><a name="CMDCTL_STARTED"></a><span class="term">CMDCTL_STARTED cmdctl is listening for connections on %1:%2</span></dt><dd><p>
The cmdctl daemon has started and is now listening for connections.
</p></dd><dt><a name="CMDCTL_STOPPED_BY_KEYBOARD"></a><span class="term">CMDCTL_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the cmdctl daemon. The
daemon will now shut down.
</p></dd><dt><a name="CMDCTL_UNCAUGHT_EXCEPTION"></a><span class="term">CMDCTL_UNCAUGHT_EXCEPTION uncaught exception: %1</span></dt><dd><p>
The b10-cmdctl daemon encountered an uncaught exception and
will now shut down. This is indicative of a programming error and
should not happen under normal circumstances. The exception message
is printed.
</p></dd><dt><a name="CMDCTL_USER_DATABASE_READ_ERROR"></a><span class="term">CMDCTL_USER_DATABASE_READ_ERROR failed to read user database file %1: %2</span></dt><dd><p>
The b10-cmdctl daemon was unable to read the user database file. The
file may be unreadable for the daemon, or it may be corrupted. In the
latter case, it can be recreated with b10-cmdctl-usermgr. The specific
error is printed in the log message.
</p></dd><dt><a name="CONFIG_CCSESSION_MSG"></a><span class="term">CONFIG_CCSESSION_MSG error in CC session message: %1</span></dt><dd><p>
There was a problem with an incoming message on the command and control
channel. The message does not appear to be a valid command, and is
missing a required element or contains an unknown data format. This
most likely means that another BIND10 module is sending a bad message.
The message itself is ignored by this module.
</p></dd><dt><a name="CONFIG_CCSESSION_MSG_INTERNAL"></a><span class="term">CONFIG_CCSESSION_MSG_INTERNAL error handling CC session message: %1</span></dt><dd><p>
There was an internal problem handling an incoming message on the command
and control channel. An unexpected exception was thrown, details of
which are appended to the message. The module will continue to run,
but will not send back an answer.
</p><p>
The most likely cause of this error is a programming error.  Please raise
a bug report.
</p></dd><dt><a name="CONFIG_CCSESSION_STOPPING"></a><span class="term">CONFIG_CCSESSION_STOPPING error sending stopping message: %1</span></dt><dd><p>
There was a problem when sending a message signaling that the module using
this CCSession is stopping. This message is sent so that the rest of the
system is aware that the module is no longer running. Apart from logging
this message, the error itself is ignored, and the ModuleCCSession is
still stopped. The specific exception message is printed.
</p></dd><dt><a name="CONFIG_CCSESSION_STOPPING_UNKNOWN"></a><span class="term">CONFIG_CCSESSION_STOPPING_UNKNOWN unknown error sending stopping message</span></dt><dd><p>
Similar to CONFIG_CCSESSION_STOPPING, but in this case the exception that
is seen is not a standard exception, and further information is unknown.
This is a bug.
</p></dd><dt><a name="CONFIG_GET_FAIL"></a><span class="term">CONFIG_GET_FAIL error getting configuration from cfgmgr: %1</span></dt><dd><p>
The configuration manager returned an error when this module requested
the configuration. The full error message answer from the configuration
manager is appended to the log error. The most likely cause is that
the module is of a different (command specification) version than the
running configuration manager.
</p></dd><dt><a name="CONFIG_GET_FAILED"></a><span class="term">CONFIG_GET_FAILED error getting configuration from cfgmgr: %1</span></dt><dd><p>
The configuration manager returned an error response when the module
requested its configuration. The full error message answer from the
configuration manager is appended to the log error.
</p></dd><dt><a name="CONFIG_JSON_PARSE"></a><span class="term">CONFIG_JSON_PARSE JSON parse error in %1: %2</span></dt><dd><p>
There was an error parsing the JSON file. The given file does not appear
to be in valid JSON format. Please verify that the filename is correct
and that the contents are valid JSON.
</p></dd><dt><a name="CONFIG_LOG_CONFIG_ERRORS"></a><span class="term">CONFIG_LOG_CONFIG_ERRORS error(s) in logging configuration: %1</span></dt><dd><p>
There was a logging configuration update, but the internal validator
for logging configuration found that it contained errors. The errors
are shown, and the update is ignored.
</p></dd><dt><a name="CONFIG_LOG_EXPLICIT"></a><span class="term">CONFIG_LOG_EXPLICIT will use logging configuration for explicitly-named logger %1</span></dt><dd><p>
This is a debug message.  When processing the "loggers" part of the
configuration file, the configuration library found an entry for the named
logger that matches the logger specification for the program.  The logging
configuration for the program will be updated with the information.
</p></dd><dt><a name="CONFIG_LOG_IGNORE_EXPLICIT"></a><span class="term">CONFIG_LOG_IGNORE_EXPLICIT ignoring logging configuration for explicitly-named logger %1</span></dt><dd><p>
This is a debug message.  When processing the "loggers" part of the
configuration file, the configuration library found an entry for the
named logger.  As this does not match the logger specification for the
program, it has been ignored.
</p></dd><dt><a name="CONFIG_LOG_IGNORE_WILD"></a><span class="term">CONFIG_LOG_IGNORE_WILD ignoring logging configuration for wildcard logger %1</span></dt><dd><p>
This is a debug message.  When processing the "loggers" part of the
configuration file, the configuration library found the named wildcard
entry (one containing the "*" character) that matched a logger already
matched by an explicitly named entry.  The configuration is ignored.
</p></dd><dt><a name="CONFIG_LOG_WILD_MATCH"></a><span class="term">CONFIG_LOG_WILD_MATCH will use logging configuration for wildcard logger %1</span></dt><dd><p>
This is a debug message.  When processing the "loggers" part of
the configuration file, the configuration library found the named
wildcard entry (one containing the "*" character) that matches a logger
specification in the program. The logging configuration for the program
will be updated with the information.
</p></dd><dt><a name="CONFIG_MOD_SPEC_FORMAT"></a><span class="term">CONFIG_MOD_SPEC_FORMAT module specification error in %1: %2</span></dt><dd><p>
The given file does not appear to be a valid specification file: details
are included in the message. Please verify that the filename is correct
and that its contents are a valid BIND10 module specification.
</p></dd><dt><a name="CONFIG_MOD_SPEC_REJECT"></a><span class="term">CONFIG_MOD_SPEC_REJECT module specification rejected by cfgmgr: %1</span></dt><dd><p>
The specification file for this module was rejected by the configuration
manager. The full error message answer from the configuration manager is
appended to the log error. The most likely cause is that the module is of
a different (specification file) version than the running configuration
manager.
</p></dd><dt><a name="CONFIG_OPEN_FAIL"></a><span class="term">CONFIG_OPEN_FAIL error opening %1: %2</span></dt><dd><p>
There was an error opening the given file. The reason for the failure
is included in the message.
</p></dd><dt><a name="CONFIG_SESSION_STOPPING_FAILED"></a><span class="term">CONFIG_SESSION_STOPPING_FAILED error sending stopping message: %1</span></dt><dd><p>
There was a problem when sending a message signaling that the module using
this CCSession is stopping. This message is sent so that the rest of the
system is aware that the module is no longer running. Apart from logging
this message, the error itself is ignored, and the ModuleCCSession is
still stopped. The specific exception message is printed.
</p></dd><dt><a name="DATASRC_BAD_NSEC3_NAME"></a><span class="term">DATASRC_BAD_NSEC3_NAME NSEC3 record has a bad owner name '%1'</span></dt><dd><p>
The software refuses to load NSEC3 records into a wildcard domain or
the owner name has two or more labels below the zone origin.
It isn't explicitly forbidden, but no sane zone wouldn have such names
for NSEC3.  BIND 9 also refuses NSEC3 at wildcard, so this behavior is
compatible with BIND 9.
</p></dd><dt><a name="DATASRC_CACHE_CREATE"></a><span class="term">DATASRC_CACHE_CREATE creating the hotspot cache</span></dt><dd><p>
This is a debug message issued during startup when the hotspot cache
is created.
</p></dd><dt><a name="DATASRC_CACHE_DESTROY"></a><span class="term">DATASRC_CACHE_DESTROY destroying the hotspot cache</span></dt><dd><p>
Debug information. The hotspot cache is being destroyed.
</p></dd><dt><a name="DATASRC_CACHE_DISABLE"></a><span class="term">DATASRC_CACHE_DISABLE disabling the hotspot cache</span></dt><dd><p>
A debug message issued when the hotspot cache is disabled.
</p></dd><dt><a name="DATASRC_CACHE_ENABLE"></a><span class="term">DATASRC_CACHE_ENABLE enabling the hotspot cache</span></dt><dd><p>
A debug message issued when the hotspot cache is enabled.
</p></dd><dt><a name="DATASRC_CACHE_EXPIRED"></a><span class="term">DATASRC_CACHE_EXPIRED item '%1' in the hotspot cache has expired</span></dt><dd><p>
A debug message issued when a hotspot cache lookup located the item but it
had expired.  The item was removed and the program proceeded as if the item
had not been found.
</p></dd><dt><a name="DATASRC_CACHE_FOUND"></a><span class="term">DATASRC_CACHE_FOUND the item '%1' was found</span></dt><dd><p>
Debug information. An item was successfully located in the hotspot cache.
</p></dd><dt><a name="DATASRC_CACHE_FULL"></a><span class="term">DATASRC_CACHE_FULL hotspot cache is full, dropping oldest</span></dt><dd><p>
Debug information. After inserting an item into the hotspot cache, the
maximum number of items was exceeded, so the least recently used item will
be dropped. This should be directly followed by CACHE_REMOVE.
</p></dd><dt><a name="DATASRC_CACHE_INSERT"></a><span class="term">DATASRC_CACHE_INSERT inserting item '%1' into the hotspot cache</span></dt><dd><p>
A debug message indicating that a new item is being inserted into the hotspot
cache.
</p></dd><dt><a name="DATASRC_CACHE_NOT_FOUND"></a><span class="term">DATASRC_CACHE_NOT_FOUND the item '%1' was not found in the hotspot cache</span></dt><dd><p>
A debug message issued when hotspot cache was searched for the specified
item but it was not found.
</p></dd><dt><a name="DATASRC_CACHE_OLD_FOUND"></a><span class="term">DATASRC_CACHE_OLD_FOUND older instance of hotspot cache item '%1' found, replacing</span></dt><dd><p>
Debug information. While inserting an item into the hotspot cache, an older
instance of an item with the same name was found; the old instance will be
removed. This will be directly followed by CACHE_REMOVE.
</p></dd><dt><a name="DATASRC_CACHE_REMOVE"></a><span class="term">DATASRC_CACHE_REMOVE removing '%1' from the hotspot cache</span></dt><dd><p>
Debug information. An item is being removed from the hotspot cache.
</p></dd><dt><a name="DATASRC_CACHE_SLOTS"></a><span class="term">DATASRC_CACHE_SLOTS setting the hotspot cache size to '%1', dropping '%2' items</span></dt><dd><p>
The maximum allowed number of items of the hotspot cache is set to the given
number. If there are too many, some of them will be dropped. The size of 0
means no limit.
</p></dd><dt><a name="DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED"></a><span class="term">DATASRC_DATABASE_COVER_NSEC_UNSUPPORTED %1 doesn't support DNSSEC when asked for NSEC data covering %2</span></dt><dd><p>
The datasource tried to provide an NSEC proof that the named domain does not
exist, but the database backend doesn't support DNSSEC. No proof is included
in the answer as a result.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3"></a><span class="term">DATASRC_DATABASE_FINDNSEC3 Looking for NSEC3 for %1 in %2 mode</span></dt><dd><p>
Debug information. A search in an database data source for NSEC3 that
matches or covers the given name is being started.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_COVER"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_COVER found a covering NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
Debug information. An NSEC3 that covers the given name is found and
being returned.  The found NSEC3 RRset is also displayed. When the shown label
count is smaller than that of the given name, the matching NSEC3 is for a
superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH).  The
found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_MATCH"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
Debug information. An NSEC3 that matches (a possibly superdomain of)
the given name is found and being returned.  When the shown label
count is smaller than that of the given name, the matching NSEC3 is
for a superdomain of the given name (see DATASRC_DATABSE_FINDNSEC3_TRYHASH).
The found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_TRYHASH"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_TRYHASH looking for NSEC3 for %1 at label count %2 (hash %3)</span></dt><dd><p>
Debug information. In an attempt of finding an NSEC3 for the give name,
(a possibly superdomain of) the name is hashed and searched for in the
NSEC3 name space.  When the shown label count is smaller than that of the
shown name, the search tries the superdomain name that share the shown
(higher) label count of the shown name (e.g., for
www.example.com. with shown label count of 3, example.com. is being
tried, as "." is 1 label long).
</p></dd><dt><a name="DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV"></a><span class="term">DATASRC_DATABASE_FINDNSEC3_TRYHASH_PREV looking for previous NSEC3 for %1 at label count %2 (hash %3)</span></dt><dd><p>
Debug information. An exact match on hash (see
DATASRC_DATABASE_FINDNSEC3_TRYHASH) was unsuccessful. We get the previous hash
to that one instead.
</p></dd><dt><a name="DATASRC_DATABASE_FIND_RECORDS"></a><span class="term">DATASRC_DATABASE_FIND_RECORDS looking in datasource %1 for record %2/%3/%4</span></dt><dd><p>
Debug information. The database data source is looking up records with the given
name and type in the database.
</p></dd><dt><a name="DATASRC_DATABASE_FIND_TTL_MISMATCH"></a><span class="term">DATASRC_DATABASE_FIND_TTL_MISMATCH TTL values differ in %1 for elements of %2/%3/%4, setting to %5</span></dt><dd><p>
The datasource backend provided resource records for the given RRset with
different TTL values. This isn't allowed on the wire and is considered
an error, so we set it to the lowest value we found (but we don't modify the
database). The data in database should be checked and fixed.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_ANY"></a><span class="term">DATASRC_DATABASE_FOUND_ANY search in datasource %1 resulted in returning all records of %2</span></dt><dd><p>
The data returned by the database backend contained data for the given domain
name, so all the RRsets of the domain are returned.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_CNAME"></a><span class="term">DATASRC_DATABASE_FOUND_CNAME search in datasource %1 for %2/%3/%4 found CNAME, resulting in %5</span></dt><dd><p>
When searching the domain for a name a CNAME was found at that name.
Even though it was not the RR type being sought, it is returned.  (The
caller may want to continue the lookup by replacing the query name with
the canonical name and restarting the query with the original RR type.)
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DELEGATION"></a><span class="term">DATASRC_DATABASE_FOUND_DELEGATION Found delegation at %2 in %1</span></dt><dd><p>
When searching for a domain, the program met a delegation to a different zone
at the given domain name. It will return that one instead.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DELEGATION_EXACT"></a><span class="term">DATASRC_DATABASE_FOUND_DELEGATION_EXACT search in datasource %1 for %2/%3/%4 found delegation at %5</span></dt><dd><p>
The program found the domain requested, but it is a delegation point to a
different zone, therefore it is not authoritative for this domain name.
It will return the NS record instead.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_DNAME"></a><span class="term">DATASRC_DATABASE_FOUND_DNAME Found DNAME at %2 in %1</span></dt><dd><p>
When searching for a domain, the program met a DNAME redirection to a different
place in the domain space at the given domain name. It will return that one
instead.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL"></a><span class="term">DATASRC_DATABASE_FOUND_EMPTY_NONTERMINAL empty non-terminal %2 in %1</span></dt><dd><p>
The domain name does not have any RRs associated with it, so it doesn't
exist in the database.  However, it has a subdomain, so it does exist
in the DNS address space. This type of domain is known an an "empty
non-terminal" and so we return NXRRSET instead of NXDOMAIN.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXDOMAIN"></a><span class="term">DATASRC_DATABASE_FOUND_NXDOMAIN search in datasource %1 resulted in NXDOMAIN for %2/%3/%4</span></dt><dd><p>
The data returned by the database backend did not contain any data for the given
domain name, class and type.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXRRSET"></a><span class="term">DATASRC_DATABASE_FOUND_NXRRSET search in datasource %1 for %2/%3/%4 resulted in NXRRSET</span></dt><dd><p>
The data returned by the database backend contained data for the given domain
name and class, but not for the given type.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_NXRRSET_NSEC"></a><span class="term">DATASRC_DATABASE_FOUND_NXRRSET_NSEC search in datasource %1 for %2/%3/%4 resulted in RRset %5</span></dt><dd><p>
A search in the database for RRs for the specified name, type and class has
located RRs that match the name and class but not the type.  DNSSEC information
has been requested and returned.
</p></dd><dt><a name="DATASRC_DATABASE_FOUND_RRSET"></a><span class="term">DATASRC_DATABASE_FOUND_RRSET search in datasource %1 resulted in RRset %2</span></dt><dd><p>
The data returned by the database backend contained data for the given domain
name, and it either matches the type or has a relevant type. The RRset that is
returned is printed.
</p></dd><dt><a name="DATASRC_DATABASE_ITERATE"></a><span class="term">DATASRC_DATABASE_ITERATE iterating zone %1</span></dt><dd><p>
The program is reading the whole zone, eg. not searching for data, but going
through each of the RRsets there.
</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_END"></a><span class="term">DATASRC_DATABASE_ITERATE_END iterating zone finished</span></dt><dd><p>
While iterating through the zone, the program reached end of the data.
</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_NEXT"></a><span class="term">DATASRC_DATABASE_ITERATE_NEXT next RRset in zone is %1/%2</span></dt><dd><p>
While iterating through the zone, the program extracted next RRset from it.
The name and RRtype of the RRset is indicated in the message.
</p></dd><dt><a name="DATASRC_DATABASE_ITERATE_TTL_MISMATCH"></a><span class="term">DATASRC_DATABASE_ITERATE_TTL_MISMATCH TTL values differ for RRs of %1/%2/%3, setting to %4</span></dt><dd><p>
While iterating through the zone, the time to live for RRs of the
given RRset were found to be different. Since an RRset cannot have
multiple TTLs, we set it to the lowest value we found (but we don't
modify the database). This is what the client would do when such RRs
were given in a DNS response according to RFC2181. The data in
database should be checked and fixed.
</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_END"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_END %1/%2 on %3 from %4 to %5</span></dt><dd><p>
This is a debug message indicating that the program (successfully)
reaches the end of sequences of a zone's differences.  The zone's name
and class, database name, and the start and end serials are shown in
the message.
</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_NEXT"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_NEXT %1/%2 in %3/%4 on %5</span></dt><dd><p>
This is a debug message indicating that the program retrieves one
difference in difference sequences of a zone and successfully converts
it to an RRset.  The zone's name and class, database name, and the
name and RR type of the retrieved diff are shown in the message.
</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADER_START"></a><span class="term">DATASRC_DATABASE_JOURNALREADER_START %1/%2 on %3 from %4 to %5</span></dt><dd><p>
This is a debug message indicating that the program starts reading
a zone's difference sequences from a database-based data source.  The
zone's name and class, database name, and the start and end serials
are shown in the message.
</p></dd><dt><a name="DATASRC_DATABASE_JOURNALREADR_BADDATA"></a><span class="term">DATASRC_DATABASE_JOURNALREADR_BADDATA failed to convert a diff to RRset in %1/%2 on %3 between %4 and %5: %6</span></dt><dd><p>
This is an error message indicating that a zone's diff is broken and
the data source library failed to convert it to a valid RRset.  The
most likely cause of this is that someone has manually modified the
zone's diff in the database and inserted invalid data as a result.
The zone's name and class, database name, and the start and end
serials, and an additional detail of the error are shown in the
message.  The administrator should examine the diff in the database
to find any invalid data and fix it.
</p></dd><dt><a name="DATASRC_DATABASE_NO_MATCH"></a><span class="term">DATASRC_DATABASE_NO_MATCH not match for %2/%3/%4 in %1</span></dt><dd><p>
No match (not even a wildcard) was found in the named data source for the given
name/type/class in the data source.
</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_COMMIT"></a><span class="term">DATASRC_DATABASE_UPDATER_COMMIT updates committed for '%1/%2' on %3</span></dt><dd><p>
Debug information.  A set of updates to a zone has been successfully
committed to the corresponding database backend.  The zone name,
its class and the database name are printed.
</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_CREATED"></a><span class="term">DATASRC_DATABASE_UPDATER_CREATED zone updater created for '%1/%2' on %3</span></dt><dd><p>
Debug information.  A zone updater object is created to make updates to
the shown zone on the shown backend database.
</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_DESTROYED"></a><span class="term">DATASRC_DATABASE_UPDATER_DESTROYED zone updater destroyed for '%1/%2' on %3</span></dt><dd><p>
Debug information.  A zone updater object is destroyed, either successfully
or after failure of, making updates to the shown zone on the shown backend
database.
</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACK"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACK zone updates roll-backed for '%1/%2' on %3</span></dt><dd><p>
A zone updater is being destroyed without committing the changes.
This would typically mean the update attempt was aborted due to some
error, but may also be a bug of the application that forgets committing
the changes.  The intermediate changes made through the updater won't
be applied to the underlying database.  The zone name, its class, and
the underlying database name are shown in the log message.
</p></dd><dt><a name="DATASRC_DATABASE_UPDATER_ROLLBACKFAIL"></a><span class="term">DATASRC_DATABASE_UPDATER_ROLLBACKFAIL failed to roll back zone updates for '%1/%2' on %3: %4</span></dt><dd><p>
A zone updater is being destroyed without committing the changes to
the database, and attempts to rollback incomplete updates, but it
unexpectedly fails.  The higher level implementation does not expect
it to fail, so this means either a serious operational error in the
underlying data source (such as a system failure of a database) or
software bug in the underlying data source implementation.  In either
case if this message is logged the administrator should carefully
examine the underlying data source to see what exactly happens and
whether the data is still valid.  The zone name, its class, and the
underlying database name as well as the error message thrown from the
database module are shown in the log message.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_ANY"></a><span class="term">DATASRC_DATABASE_WILDCARD_ANY search in datasource %1 resulted in wildcard match type ANY on %2</span></dt><dd><p>
The database doesn't contain directly matching name.  When searching
for a wildcard match, a wildcard record matching the name of the query
containing some RRsets was found. All the RRsets of the node are returned.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CANCEL_NS"></a><span class="term">DATASRC_DATABASE_WILDCARD_CANCEL_NS canceled wildcard match on %3 because %2 contains NS (data source %1)</span></dt><dd><p>
The database was queried to provide glue data and it didn't find direct match.
It could create it from given wildcard, but matching wildcards is forbidden
under a zone cut, which was found. Therefore the delegation will be returned
instead.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CANCEL_SUB"></a><span class="term">DATASRC_DATABASE_WILDCARD_CANCEL_SUB wildcard %2 can't be used to construct %3 because %4 exists in %1</span></dt><dd><p>
The answer could be constructed using the wildcard, but the given subdomain
exists, therefore this name is something like empty non-terminal (actually,
from the protocol point of view, it is empty non-terminal, but the code
discovers it differently).
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_CNAME"></a><span class="term">DATASRC_DATABASE_WILDCARD_CNAME search in datasource %1 for %2/%3/%4 found wildcard CNAME at %5, resulting in %6</span></dt><dd><p>
The database doesn't contain directly matching name.  When searching
for a wildcard match, a CNAME RR was found at a wildcard record
matching the name.  This is returned as the result of the search.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_EMPTY"></a><span class="term">DATASRC_DATABASE_WILDCARD_EMPTY found subdomains of %2 which is a wildcard match for %3 in %1</span></dt><dd><p>
The given wildcard matches the name being sough but it as an empty
nonterminal (e.g. there's nothing at *.example.com but something like
subdomain.*.example.org, do exist: so *.example.org exists in the
namespace but has no RRs assopciated with it). This will produce NXRRSET.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_MATCH"></a><span class="term">DATASRC_DATABASE_WILDCARD_MATCH search in datasource %1 resulted in wildcard match at %2 with RRset %3</span></dt><dd><p>
The database doesn't contain directly matching name.  When searching
for a wildcard match, a wildcard record matching the name and type of
the query was found. The data at this point is returned.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_NS"></a><span class="term">DATASRC_DATABASE_WILDCARD_NS search in datasource %1 for %2/%3/%4 found wildcard delegation at %5, resulting in %6</span></dt><dd><p>
The database doesn't contain directly matching name.  When searching
for a wildcard match, an NS RR was found at a wildcard record matching
the name.  This is returned as the result of the search.
</p></dd><dt><a name="DATASRC_DATABASE_WILDCARD_NXRRSET"></a><span class="term">DATASRC_DATABASE_WILDCARD_NXRRSET search in datasource %1 for %2/%3/%4 resulted in wildcard NXRRSET at %5</span></dt><dd><p>
The database doesn't contain directly matching name.  When searching
for a wildcard match, a matching wildcard entry was found but it did
not contain RRs the requested type.  AN NXRRSET indication is returned.
</p></dd><dt><a name="DATASRC_DO_QUERY"></a><span class="term">DATASRC_DO_QUERY handling query for '%1/%2'</span></dt><dd><p>
A debug message indicating that a query for the given name and RR type is being
processed.
</p></dd><dt><a name="DATASRC_LIST_NOT_CACHED"></a><span class="term">DATASRC_LIST_NOT_CACHED zone %1/%2 not cached, cache disabled globally. Will not be available.</span></dt><dd><p>
The process disabled caching of RR data completely. However, the given zone
is provided as a master file and it can be served from memory cache only.
Therefore, the zone will not be available for this process. If this is
a problem, you should move the zone to some database backend (sqlite3, for
example) and use it from there.
</p></dd><dt><a name="DATASRC_MEM_ADD_RRSET"></a><span class="term">DATASRC_MEM_ADD_RRSET adding RRset '%1/%2' into zone '%3'</span></dt><dd><p>
Debug information. An RRset is being added to the in-memory data source.
</p></dd><dt><a name="DATASRC_MEM_ADD_WILDCARD"></a><span class="term">DATASRC_MEM_ADD_WILDCARD adding wildcards for '%1'</span></dt><dd><p>
This is a debug message issued during the processing of a wildcard
name. The internal domain name tree is scanned and some nodes are
specially marked to allow the wildcard lookup to succeed.
</p></dd><dt><a name="DATASRC_MEM_ADD_ZONE"></a><span class="term">DATASRC_MEM_ADD_ZONE adding zone '%1/%2'</span></dt><dd><p>
Debug information. A zone is being added into the in-memory data source.
</p></dd><dt><a name="DATASRC_MEM_ANY_SUCCESS"></a><span class="term">DATASRC_MEM_ANY_SUCCESS ANY query for '%1' successful</span></dt><dd><p>
Debug information. The domain was found and an ANY type query is being answered
by providing everything found inside the domain.
</p></dd><dt><a name="DATASRC_MEM_CNAME"></a><span class="term">DATASRC_MEM_CNAME CNAME at the domain '%1'</span></dt><dd><p>
Debug information. The requested domain is an alias to a different domain,
returning the CNAME instead.
</p></dd><dt><a name="DATASRC_MEM_CNAME_COEXIST"></a><span class="term">DATASRC_MEM_CNAME_COEXIST can't add data to CNAME in domain '%1'</span></dt><dd><p>
This is the same problem as in MEM_CNAME_TO_NONEMPTY, but it happened the
other way around -- adding some other data to CNAME.
</p></dd><dt><a name="DATASRC_MEM_CNAME_TO_NONEMPTY"></a><span class="term">DATASRC_MEM_CNAME_TO_NONEMPTY can't add CNAME to domain with other data in '%1'</span></dt><dd><p>
Someone or something tried to add a CNAME into a domain that already contains
some other data. But the protocol forbids coexistence of CNAME with anything
(RFC 1034, section 3.6.2). This indicates a problem with provided data.
</p></dd><dt><a name="DATASRC_MEM_CREATE"></a><span class="term">DATASRC_MEM_CREATE creating zone '%1' in '%2' class</span></dt><dd><p>
Debug information. A representation of a zone for the in-memory data source is
being created.
</p></dd><dt><a name="DATASRC_MEM_DELEG_FOUND"></a><span class="term">DATASRC_MEM_DELEG_FOUND delegation found at '%1'</span></dt><dd><p>
Debug information. A delegation point was found above the requested record.
</p></dd><dt><a name="DATASRC_MEM_DESTROY"></a><span class="term">DATASRC_MEM_DESTROY destroying zone '%1' in '%2' class</span></dt><dd><p>
Debug information. A zone from in-memory data source is being destroyed.
</p></dd><dt><a name="DATASRC_MEM_DNAME_ENCOUNTERED"></a><span class="term">DATASRC_MEM_DNAME_ENCOUNTERED encountered a DNAME</span></dt><dd><p>
Debug information. While searching for the requested domain, a DNAME was
encountered on the way.  This may lead to redirection to a different domain and
stop the search.
</p></dd><dt><a name="DATASRC_MEM_DNAME_FOUND"></a><span class="term">DATASRC_MEM_DNAME_FOUND DNAME found at '%1'</span></dt><dd><p>
Debug information. A DNAME was found instead of the requested information.
</p></dd><dt><a name="DATASRC_MEM_DNAME_NS"></a><span class="term">DATASRC_MEM_DNAME_NS DNAME and NS can't coexist in non-apex domain '%1'</span></dt><dd><p>
A request was made for DNAME and NS records to be put into the same
domain which is not the apex (the top of the zone). This is forbidden
by RFC 2672 (section 3) and indicates a problem with provided data.
</p></dd><dt><a name="DATASRC_MEM_DOMAIN_EMPTY"></a><span class="term">DATASRC_MEM_DOMAIN_EMPTY requested domain '%1' is empty</span></dt><dd><p>
Debug information. The requested domain exists in the tree of domains, but
it is empty. Therefore it doesn't contain the requested resource type.
</p></dd><dt><a name="DATASRC_MEM_DUP_RRSET"></a><span class="term">DATASRC_MEM_DUP_RRSET duplicate RRset '%1/%2'</span></dt><dd><p>
An RRset is being inserted into in-memory data source for a second time.  The
original version must be removed first. Note that loading master files where an
RRset is split into multiple locations is not supported yet.
</p></dd><dt><a name="DATASRC_MEM_EXACT_DELEGATION"></a><span class="term">DATASRC_MEM_EXACT_DELEGATION delegation at the exact domain '%1'</span></dt><dd><p>
Debug information. There's a NS record at the requested domain. This means
this zone is not authoritative for the requested domain, but a delegation
should be followed. The requested domain is an apex of some zone.
</p></dd><dt><a name="DATASRC_MEM_FIND"></a><span class="term">DATASRC_MEM_FIND find '%1/%2'</span></dt><dd><p>
Debug information. A search for the requested RRset is being started.
</p></dd><dt><a name="DATASRC_MEM_FINDNSEC3"></a><span class="term">DATASRC_MEM_FINDNSEC3 finding NSEC3 for %1, mode %2</span></dt><dd><p>
Debug information. A search in an in-memory data source for NSEC3 that
matches or covers the given name is being started.
</p></dd><dt><a name="DATASRC_MEM_FINDNSEC3_COVER"></a><span class="term">DATASRC_MEM_FINDNSEC3_COVER found a covering NSEC3 for %1: %2</span></dt><dd><p>
Debug information. An NSEC3 that covers the given name is found and
being returned.  The found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_MEM_FINDNSEC3_MATCH"></a><span class="term">DATASRC_MEM_FINDNSEC3_MATCH found a matching NSEC3 for %1 at label count %2: %3</span></dt><dd><p>
Debug information. An NSEC3 that matches (a possibly superdomain of)
the given name is found and being returned.  When the shown label
count is smaller than that of the given name, the matching NSEC3 is
for a superdomain of the given name (see DATASRC_MEM_FINDNSEC3_TRYHASH).
The found NSEC3 RRset is also displayed.
</p></dd><dt><a name="DATASRC_MEM_FINDNSEC3_TRYHASH"></a><span class="term">DATASRC_MEM_FINDNSEC3_TRYHASH looking for NSEC3 for %1 at label count %2 (hash %3)</span></dt><dd><p>
Debug information. In an attempt of finding an NSEC3 for the give name,
(a possibly superdomain of) the name is hashed and searched for in the
NSEC3 name space.  When the shown label count is smaller than that of the
shown name, the search tries the superdomain name that share the shown
(higher) label count of the shown name (e.g., for
www.example.com. with shown label count of 3, example.com. is being
tried).
</p></dd><dt><a name="DATASRC_MEM_FIND_ZONE"></a><span class="term">DATASRC_MEM_FIND_ZONE looking for zone '%1'</span></dt><dd><p>
Debug information. A zone object for this zone is being searched for in the
in-memory data source.
</p></dd><dt><a name="DATASRC_MEM_LOAD"></a><span class="term">DATASRC_MEM_LOAD loading zone '%1' from file '%2'</span></dt><dd><p>
Debug information. The content of master file is being loaded into the memory.
</p></dd><dt><a name="DATASRC_MEM_NOT_FOUND"></a><span class="term">DATASRC_MEM_NOT_FOUND requested domain '%1' not found</span></dt><dd><p>
Debug information. The requested domain does not exist.
</p></dd><dt><a name="DATASRC_MEM_NO_NSEC3PARAM"></a><span class="term">DATASRC_MEM_NO_NSEC3PARAM NSEC3PARAM is missing for NSEC3-signed zone %1/%2</span></dt><dd><p>
The in-memory data source has loaded a zone signed with NSEC3 RRs,
but it doesn't have a NSEC3PARAM RR at the zone origin.  It's likely that
the zone is somehow broken, but this RR is not necessarily needed for
handling lookups with NSEC3 in this data source, so it accepts the given
content of the zone.  Nevertheless the administrator should look into
the integrity of the zone data.
</p></dd><dt><a name="DATASRC_MEM_NS_ENCOUNTERED"></a><span class="term">DATASRC_MEM_NS_ENCOUNTERED encountered a NS</span></dt><dd><p>
Debug information. While searching for the requested domain, a NS was
encountered on the way (a delegation). This may lead to stop of the search.
</p></dd><dt><a name="DATASRC_MEM_NXRRSET"></a><span class="term">DATASRC_MEM_NXRRSET no such type '%1' at '%2'</span></dt><dd><p>
Debug information. The domain exists, but it doesn't hold any record of the
requested type.
</p></dd><dt><a name="DATASRC_MEM_OUT_OF_ZONE"></a><span class="term">DATASRC_MEM_OUT_OF_ZONE domain '%1' doesn't belong to zone '%2'</span></dt><dd><p>
It was attempted to add the domain into a zone that shouldn't have it
(eg. the domain is not subdomain of the zone origin). This indicates a
problem with provided data.
</p></dd><dt><a name="DATASRC_MEM_RENAME"></a><span class="term">DATASRC_MEM_RENAME renaming RRset from '%1' to '%2'</span></dt><dd><p>
Debug information. A RRset is being generated from a different RRset (most
probably a wildcard). So it must be renamed to whatever the user asked for. In
fact, it's impossible to rename RRsets with our libraries, so a new one is
created and all resource records are copied over.
</p></dd><dt><a name="DATASRC_MEM_SINGLETON"></a><span class="term">DATASRC_MEM_SINGLETON trying to add multiple RRs for domain '%1' and type '%2'</span></dt><dd><p>
Some resource types are singletons -- only one is allowed in a domain
(for example CNAME or SOA). This indicates a problem with provided data.
</p></dd><dt><a name="DATASRC_MEM_SUCCESS"></a><span class="term">DATASRC_MEM_SUCCESS query for '%1/%2' successful</span></dt><dd><p>
Debug information. The requested record was found.
</p></dd><dt><a name="DATASRC_MEM_SUPER_STOP"></a><span class="term">DATASRC_MEM_SUPER_STOP stopped as '%1' is superdomain of a zone node, meaning it's empty</span></dt><dd><p>
Debug information. The search stopped because the requested domain was
detected to be a superdomain of some existing node of zone (while there
was no exact match).  This means that the domain is an empty nonterminal,
therefore it is treated  as NXRRSET case (eg. the domain exists, but it
doesn't have the requested record type).
</p></dd><dt><a name="DATASRC_MEM_SWAP"></a><span class="term">DATASRC_MEM_SWAP swapping contents of two zone representations ('%1' and '%2')</span></dt><dd><p>
Debug information. The contents of two in-memory zones are being exchanged.
This is usual practice to do some manipulation in exception-safe manner -- the
new data are prepared in a different zone object and when it works, they are
swapped. The old one contains the new data and the other one can be safely
destroyed.
</p></dd><dt><a name="DATASRC_MEM_WILDCARD_CANCEL"></a><span class="term">DATASRC_MEM_WILDCARD_CANCEL wildcard match canceled for '%1'</span></dt><dd><p>
Debug information. A domain above wildcard was reached, but there's something
below the requested domain. Therefore the wildcard doesn't apply here.  This
behaviour is specified by RFC 1034, section 4.3.3
</p></dd><dt><a name="DATASRC_MEM_WILDCARD_DNAME"></a><span class="term">DATASRC_MEM_WILDCARD_DNAME DNAME record in wildcard domain '%1'</span></dt><dd><p>
The software refuses to load DNAME records into a wildcard domain.  It isn't
explicitly forbidden, but the protocol is ambiguous about how this should
behave and BIND 9 refuses that as well. Please describe your intention using
different tools.
</p></dd><dt><a name="DATASRC_MEM_WILDCARD_NS"></a><span class="term">DATASRC_MEM_WILDCARD_NS NS record in wildcard domain '%1'</span></dt><dd><p>
The software refuses to load NS records into a wildcard domain.  It isn't
explicitly forbidden, but the protocol is ambiguous about how this should
behave and BIND 9 refuses that as well. Please describe your intention using
different tools.
</p></dd><dt><a name="DATASRC_META_ADD"></a><span class="term">DATASRC_META_ADD adding a data source into meta data source</span></dt><dd><p>
This is a debug message issued during startup or reconfiguration.
Another data source is being added into the meta data source.
</p></dd><dt><a name="DATASRC_META_ADD_CLASS_MISMATCH"></a><span class="term">DATASRC_META_ADD_CLASS_MISMATCH mismatch between classes '%1' and '%2'</span></dt><dd><p>
It was attempted to add a data source into a meta data source, but their
classes do not match.
</p></dd><dt><a name="DATASRC_META_REMOVE"></a><span class="term">DATASRC_META_REMOVE removing data source from meta data source</span></dt><dd><p>
Debug information. A data source is being removed from meta data source.
</p></dd><dt><a name="DATASRC_QUERY_ADD_NSEC"></a><span class="term">DATASRC_QUERY_ADD_NSEC adding NSEC record for '%1'</span></dt><dd><p>
Debug information. A NSEC record covering this zone is being added.
</p></dd><dt><a name="DATASRC_QUERY_ADD_NSEC3"></a><span class="term">DATASRC_QUERY_ADD_NSEC3 adding NSEC3 record of zone '%1'</span></dt><dd><p>
Debug information. A NSEC3 record for the given zone is being added to the
response message.
</p></dd><dt><a name="DATASRC_QUERY_ADD_RRSET"></a><span class="term">DATASRC_QUERY_ADD_RRSET adding RRset '%1/%2' to message</span></dt><dd><p>
Debug information. An RRset is being added to the response message.
</p></dd><dt><a name="DATASRC_QUERY_ADD_SOA"></a><span class="term">DATASRC_QUERY_ADD_SOA adding SOA of '%1'</span></dt><dd><p>
Debug information. A SOA record of the given zone is being added to the
authority section of the response message.
</p></dd><dt><a name="DATASRC_QUERY_AUTH_FAIL"></a><span class="term">DATASRC_QUERY_AUTH_FAIL the underlying data source failed with %1</span></dt><dd><p>
The underlying data source failed to answer the authoritative query. 1 means
some error, 2 is not implemented. The data source should have logged the
specific error already.
</p></dd><dt><a name="DATASRC_QUERY_BAD_REFERRAL"></a><span class="term">DATASRC_QUERY_BAD_REFERRAL bad referral to '%1'</span></dt><dd><p>
The domain lives in another zone. But it is not possible to generate referral
information for it.
</p></dd><dt><a name="DATASRC_QUERY_CACHED"></a><span class="term">DATASRC_QUERY_CACHED data for %1/%2 found in hotspot cache</span></dt><dd><p>
Debug information. The requested data were found in the hotspot cache, so
no query is sent to the real data source.
</p></dd><dt><a name="DATASRC_QUERY_CHECK_CACHE"></a><span class="term">DATASRC_QUERY_CHECK_CACHE checking hotspot cache for '%1/%2'</span></dt><dd><p>
Debug information. While processing a query, lookup to the hotspot cache
is being made.
</p></dd><dt><a name="DATASRC_QUERY_COPY_AUTH"></a><span class="term">DATASRC_QUERY_COPY_AUTH copying authoritative section into message</span></dt><dd><p>
Debug information. The whole referral information is being copied into the
response message.
</p></dd><dt><a name="DATASRC_QUERY_DELEGATION"></a><span class="term">DATASRC_QUERY_DELEGATION looking for delegation on the path to '%1'</span></dt><dd><p>
Debug information. The software is trying to identify delegation points on the
way down to the given domain.
</p></dd><dt><a name="DATASRC_QUERY_EMPTY_CNAME"></a><span class="term">DATASRC_QUERY_EMPTY_CNAME CNAME at '%1' is empty</span></dt><dd><p>
A CNAME chain was being followed and an entry was found that pointed
to a domain name that had no RRsets associated with it. As a result,
the query cannot be answered. This indicates a problem with supplied data.
</p></dd><dt><a name="DATASRC_QUERY_EMPTY_DNAME"></a><span class="term">DATASRC_QUERY_EMPTY_DNAME the DNAME on '%1' is empty</span></dt><dd><p>
During an attempt to synthesize CNAME from this DNAME it was discovered the
DNAME is empty (it has no records). This indicates problem with supplied data.
</p></dd><dt><a name="DATASRC_QUERY_FAIL"></a><span class="term">DATASRC_QUERY_FAIL query failed</span></dt><dd><p>
Some subtask of query processing failed. The reason should have been reported
already and a SERVFAIL will be returned to the querying system.
</p></dd><dt><a name="DATASRC_QUERY_FOLLOW_CNAME"></a><span class="term">DATASRC_QUERY_FOLLOW_CNAME following CNAME at '%1'</span></dt><dd><p>
Debug information. The domain is a CNAME (or a DNAME and a CNAME for it
has already been created) and the search is following this chain.
</p></dd><dt><a name="DATASRC_QUERY_GET_MX_ADDITIONAL"></a><span class="term">DATASRC_QUERY_GET_MX_ADDITIONAL addition of A/AAAA for '%1' requested by MX '%2'</span></dt><dd><p>
Debug information. While processing a query, a MX record was met. It
references the mentioned address, so A/AAAA records for it are looked up
and put it into the additional section.
</p></dd><dt><a name="DATASRC_QUERY_GET_NS_ADDITIONAL"></a><span class="term">DATASRC_QUERY_GET_NS_ADDITIONAL addition of A/AAAA for '%1' requested by NS '%2'</span></dt><dd><p>
Debug information. While processing a query, a NS record was met. It
references the mentioned address, so A/AAAA records for it are looked up
and put it into the additional section.
</p></dd><dt><a name="DATASRC_QUERY_GLUE_FAIL"></a><span class="term">DATASRC_QUERY_GLUE_FAIL the underlying data source failed with %1</span></dt><dd><p>
The underlying data source failed to answer the glue query. 1 means some error,
2 is not implemented. The data source should have logged the specific error
already.
</p></dd><dt><a name="DATASRC_QUERY_INVALID_OP"></a><span class="term">DATASRC_QUERY_INVALID_OP invalid query operation requested</span></dt><dd><p>
This indicates a programmer error. The DO_QUERY was called with unknown
operation code.
</p></dd><dt><a name="DATASRC_QUERY_IS_AUTH"></a><span class="term">DATASRC_QUERY_IS_AUTH auth query (%1/%2)</span></dt><dd><p>
Debug information. The last DO_QUERY is an auth query.
</p></dd><dt><a name="DATASRC_QUERY_IS_GLUE"></a><span class="term">DATASRC_QUERY_IS_GLUE glue query (%1/%2)</span></dt><dd><p>
Debug information. The last DO_QUERY is a query for glue addresses.
</p></dd><dt><a name="DATASRC_QUERY_IS_NOGLUE"></a><span class="term">DATASRC_QUERY_IS_NOGLUE query for non-glue addresses (%1/%2)</span></dt><dd><p>
Debug information. The last DO_QUERY is a query for addresses that are not
glue.
</p></dd><dt><a name="DATASRC_QUERY_IS_REF"></a><span class="term">DATASRC_QUERY_IS_REF query for referral (%1/%2)</span></dt><dd><p>
Debug information. The last DO_QUERY is a query for referral information.
</p></dd><dt><a name="DATASRC_QUERY_IS_SIMPLE"></a><span class="term">DATASRC_QUERY_IS_SIMPLE simple query (%1/%2)</span></dt><dd><p>
Debug information. The last DO_QUERY is a simple query.
</p></dd><dt><a name="DATASRC_QUERY_MISPLACED_TASK"></a><span class="term">DATASRC_QUERY_MISPLACED_TASK task of this type should not be here</span></dt><dd><p>
This indicates a programming error. A task was found in the internal task
queue, but this kind of task wasn't designed to be inside the queue (it should
be handled right away, not queued).
</p></dd><dt><a name="DATASRC_QUERY_MISSING_NS"></a><span class="term">DATASRC_QUERY_MISSING_NS missing NS records for '%1'</span></dt><dd><p>
NS records should have been put into the authority section. However, this zone
has none. This indicates problem with provided data.
</p></dd><dt><a name="DATASRC_QUERY_MISSING_SOA"></a><span class="term">DATASRC_QUERY_MISSING_SOA the zone '%1' has no SOA</span></dt><dd><p>
The answer should have been a negative one (eg. of nonexistence of something).
To do so, a SOA record should be put into the authority section, but the zone
does not have one. This indicates problem with provided data.
</p></dd><dt><a name="DATASRC_QUERY_NOGLUE_FAIL"></a><span class="term">DATASRC_QUERY_NOGLUE_FAIL the underlying data source failed with %1</span></dt><dd><p>
The underlying data source failed to answer the no-glue query. 1 means some
error, 2 is not implemented. The data source should have logged the specific
error already.
</p></dd><dt><a name="DATASRC_QUERY_NO_CACHE_ANY_AUTH"></a><span class="term">DATASRC_QUERY_NO_CACHE_ANY_AUTH ignoring hotspot cache for ANY query (%1/%2 in %3 class)</span></dt><dd><p>
Debug information. The hotspot cache is ignored for authoritative ANY queries
for consistency reasons.
</p></dd><dt><a name="DATASRC_QUERY_NO_CACHE_ANY_SIMPLE"></a><span class="term">DATASRC_QUERY_NO_CACHE_ANY_SIMPLE ignoring hotspot cache for ANY query (%1/%2 in %3 class)</span></dt><dd><p>
Debug information. The hotspot cache is ignored for ANY queries for consistency
reasons.
</p></dd><dt><a name="DATASRC_QUERY_NO_DS_NSEC"></a><span class="term">DATASRC_QUERY_NO_DS_NSEC there's no DS record in the '%1' zone</span></dt><dd><p>
An attempt to add a NSEC record into the message failed, because the zone does
not have any DS record. This indicates problem with the provided data.
</p></dd><dt><a name="DATASRC_QUERY_NO_DS_NSEC3"></a><span class="term">DATASRC_QUERY_NO_DS_NSEC3 there's no DS record in the '%1' zone</span></dt><dd><p>
An attempt to add a NSEC3 record into the message failed, because the zone does
not have any DS record. This indicates problem with the provided data.
</p></dd><dt><a name="DATASRC_QUERY_NO_ZONE"></a><span class="term">DATASRC_QUERY_NO_ZONE no zone containing '%1' in class '%2'</span></dt><dd><p>
Debug information. Lookup of domain failed because the datasource
has no zone that contains the domain. Maybe someone sent a query
to the wrong server for some reason. This may also happen when
looking in the datasource for addresses for NS records.
</p></dd><dt><a name="DATASRC_QUERY_PROCESS"></a><span class="term">DATASRC_QUERY_PROCESS processing query '%1/%2' in the '%3' class</span></dt><dd><p>
Debug information. A sure query is being processed now.
</p></dd><dt><a name="DATASRC_QUERY_PROVE_NX_FAIL"></a><span class="term">DATASRC_QUERY_PROVE_NX_FAIL unable to prove nonexistence of '%1'</span></dt><dd><p>
The user wants DNSSEC and we discovered the entity doesn't exist (either
domain or the record). But there was an error getting NSEC/NSEC3 record
to prove the nonexistence.
</p></dd><dt><a name="DATASRC_QUERY_REF_FAIL"></a><span class="term">DATASRC_QUERY_REF_FAIL the underlying data source failed with %1</span></dt><dd><p>
The underlying data source failed to answer the query for referral information.
1 means some error, 2 is not implemented. The data source should have logged
the specific error already.
</p></dd><dt><a name="DATASRC_QUERY_RRSIG"></a><span class="term">DATASRC_QUERY_RRSIG unable to answer RRSIG query for %1</span></dt><dd><p>
The server is unable to answer a direct query for RRSIG type, but was asked
to do so.
</p></dd><dt><a name="DATASRC_QUERY_SIMPLE_FAIL"></a><span class="term">DATASRC_QUERY_SIMPLE_FAIL the underlying data source failed with %1</span></dt><dd><p>
The underlying data source failed to answer the simple query. 1 means some
error, 2 is not implemented. The data source should have logged the specific
error already.
</p></dd><dt><a name="DATASRC_QUERY_SYNTH_CNAME"></a><span class="term">DATASRC_QUERY_SYNTH_CNAME synthesizing CNAME from DNAME on '%1'</span></dt><dd><p>
This is a debug message. While answering a query, a DNAME was encountered. The
DNAME itself will be returned, along with a synthesized CNAME for clients that
do not understand the DNAME RR.
</p></dd><dt><a name="DATASRC_QUERY_TASK_FAIL"></a><span class="term">DATASRC_QUERY_TASK_FAIL task failed with %1</span></dt><dd><p>
The query subtask failed. The reason should have been reported by the subtask
already. The code is 1 for error, 2 for not implemented.
</p></dd><dt><a name="DATASRC_QUERY_TOO_MANY_CNAMES"></a><span class="term">DATASRC_QUERY_TOO_MANY_CNAMES CNAME chain limit exceeded at '%1'</span></dt><dd><p>
A CNAME led to another CNAME and it led to another, and so on. After 16
CNAMEs, the software gave up. Long CNAME chains are discouraged, and this
might possibly be a loop as well. Note that some of the CNAMEs might have
been synthesized from DNAMEs. This indicates problem with supplied data.
</p></dd><dt><a name="DATASRC_QUERY_UNKNOWN_RESULT"></a><span class="term">DATASRC_QUERY_UNKNOWN_RESULT unknown result of subtask</span></dt><dd><p>
This indicates a programmer error. The answer of subtask doesn't look like
anything known.
</p></dd><dt><a name="DATASRC_QUERY_WILDCARD"></a><span class="term">DATASRC_QUERY_WILDCARD looking for a wildcard covering '%1'</span></dt><dd><p>
Debug information. A direct match wasn't found, so a wildcard covering the
domain is being looked for now.
</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_FAIL"></a><span class="term">DATASRC_QUERY_WILDCARD_FAIL error processing wildcard for '%1'</span></dt><dd><p>
During an attempt to cover the domain by a wildcard an error happened. The
exact kind was hopefully already reported.
</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL"></a><span class="term">DATASRC_QUERY_WILDCARD_PROVE_NX_FAIL unable to prove nonexistence of '%1' (%2)</span></dt><dd><p>
While processing a wildcard, it wasn't possible to prove nonexistence of the
given domain or record.  The code is 1 for error and 2 for not implemented.
</p></dd><dt><a name="DATASRC_QUERY_WILDCARD_REFERRAL"></a><span class="term">DATASRC_QUERY_WILDCARD_REFERRAL unable to find referral info for '%1' (%2)</span></dt><dd><p>
While processing a wildcard, a referral was met. But it wasn't possible to get
enough information for it.  The code is 1 for error, 2 for not implemented.
</p></dd><dt><a name="DATASRC_SQLITE_CLOSE"></a><span class="term">DATASRC_SQLITE_CLOSE closing SQLite database</span></dt><dd><p>
Debug information. The SQLite data source is closing the database file.
</p></dd><dt><a name="DATASRC_SQLITE_COMPATIBLE_VERSION"></a><span class="term">DATASRC_SQLITE_COMPATIBLE_VERSION database schema V%1.%2 not up to date (expecting V%3.%4) but is compatible</span></dt><dd><p>
The version of the SQLite3 database schema used to hold the zone data
is not the latest one - the current version of BIND 10 was written
with a later schema version in mind.  However, the database is
compatible with the current version of BIND 10, and BIND 10 will run
without any problems.
</p><p>
Consult the release notes for your version of BIND 10.  Depending on
the changes made to the database schema, it is possible that improved
performance could result if the database were upgraded.
</p></dd><dt><a name="DATASRC_SQLITE_CONNCLOSE"></a><span class="term">DATASRC_SQLITE_CONNCLOSE Closing sqlite database</span></dt><dd><p>
The database file is no longer needed and is being closed.
</p></dd><dt><a name="DATASRC_SQLITE_CONNOPEN"></a><span class="term">DATASRC_SQLITE_CONNOPEN Opening sqlite database file '%1'</span></dt><dd><p>
The database file is being opened so it can start providing data.
</p></dd><dt><a name="DATASRC_SQLITE_CREATE"></a><span class="term">DATASRC_SQLITE_CREATE SQLite data source created</span></dt><dd><p>
Debug information. An instance of SQLite data source is being created.
</p></dd><dt><a name="DATASRC_SQLITE_DESTROY"></a><span class="term">DATASRC_SQLITE_DESTROY SQLite data source destroyed</span></dt><dd><p>
Debug information. An instance of SQLite data source is being destroyed.
</p></dd><dt><a name="DATASRC_SQLITE_DROPCONN"></a><span class="term">DATASRC_SQLITE_DROPCONN SQLite3Database is being deinitialized</span></dt><dd><p>
The object around a database connection is being destroyed.
</p></dd><dt><a name="DATASRC_SQLITE_ENCLOSURE"></a><span class="term">DATASRC_SQLITE_ENCLOSURE looking for zone containing '%1'</span></dt><dd><p>
Debug information. The SQLite data source is trying to identify which zone
should hold this domain.
</p></dd><dt><a name="DATASRC_SQLITE_ENCLOSURE_NOT_FOUND"></a><span class="term">DATASRC_SQLITE_ENCLOSURE_NOT_FOUND no zone contains '%1'</span></dt><dd><p>
Debug information. The last SQLITE_ENCLOSURE query was unsuccessful; there's
no such zone in our data.
</p></dd><dt><a name="DATASRC_SQLITE_FIND"></a><span class="term">DATASRC_SQLITE_FIND looking for RRset '%1/%2'</span></dt><dd><p>
Debug information. The SQLite data source is looking up a resource record
set.
</p></dd><dt><a name="DATASRC_SQLITE_FINDADDRS"></a><span class="term">DATASRC_SQLITE_FINDADDRS looking for A/AAAA addresses for '%1'</span></dt><dd><p>
Debug information. The data source is looking up the addresses for given
domain name.
</p></dd><dt><a name="DATASRC_SQLITE_FINDADDRS_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDADDRS_BAD_CLASS class mismatch looking for addresses ('%1' and '%2')</span></dt><dd><p>
The SQLite data source was looking up A/AAAA addresses, but the data source
contains different class than the query was for.
</p></dd><dt><a name="DATASRC_SQLITE_FINDEXACT"></a><span class="term">DATASRC_SQLITE_FINDEXACT looking for exact RRset '%1/%2'</span></dt><dd><p>
Debug information. The SQLite data source is looking up an exact resource
record.
</p></dd><dt><a name="DATASRC_SQLITE_FINDEXACT_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDEXACT_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</span></dt><dd><p>
The SQLite data source was looking up an exact RRset, but the data source
contains different class than the query was for.
</p></dd><dt><a name="DATASRC_SQLITE_FINDREC"></a><span class="term">DATASRC_SQLITE_FINDREC looking for record '%1/%2'</span></dt><dd><p>
Debug information. The SQLite data source is looking up records of given name
and type in the database.
</p></dd><dt><a name="DATASRC_SQLITE_FINDREF"></a><span class="term">DATASRC_SQLITE_FINDREF looking for referral at '%1'</span></dt><dd><p>
Debug information. The SQLite data source is identifying if this domain is
a referral and where it goes.
</p></dd><dt><a name="DATASRC_SQLITE_FINDREF_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FINDREF_BAD_CLASS class mismatch looking for referral ('%1' and '%2')</span></dt><dd><p>
The SQLite data source was trying to identify if there's a referral. But
it contains different class than the query was for.
</p></dd><dt><a name="DATASRC_SQLITE_FIND_BAD_CLASS"></a><span class="term">DATASRC_SQLITE_FIND_BAD_CLASS class mismatch looking for an RRset ('%1' and '%2')</span></dt><dd><p>
The SQLite data source was looking up an RRset, but the data source contains
different class than the query was for.
</p></dd><dt><a name="DATASRC_SQLITE_FIND_NSEC3"></a><span class="term">DATASRC_SQLITE_FIND_NSEC3 looking for NSEC3 in zone '%1' for hash '%2'</span></dt><dd><p>
Debug information. We're trying to look up a NSEC3 record in the SQLite data
source.
</p></dd><dt><a name="DATASRC_SQLITE_FIND_NSEC3_NO_ZONE"></a><span class="term">DATASRC_SQLITE_FIND_NSEC3_NO_ZONE no such zone '%1'</span></dt><dd><p>
The SQLite data source was asked to provide a NSEC3 record for given zone.
But it doesn't contain that zone.
</p></dd><dt><a name="DATASRC_SQLITE_INCOMPATIBLE_VERSION"></a><span class="term">DATASRC_SQLITE_INCOMPATIBLE_VERSION database schema V%1.%2 incompatible with version (V%3.%4) expected</span></dt><dd><p>
The version of the SQLite3 database schema used to hold the zone data
is incompatible with the version expected by BIND 10.  As a result,
BIND 10 is unable to run using the database file as the data source.
</p><p>
The database should be updated using the means described in the BIND
10 documentation.
</p></dd><dt><a name="DATASRC_SQLITE_NEWCONN"></a><span class="term">DATASRC_SQLITE_NEWCONN SQLite3Database is being initialized</span></dt><dd><p>
A wrapper object to hold database connection is being initialized.
</p></dd><dt><a name="DATASRC_SQLITE_OPEN"></a><span class="term">DATASRC_SQLITE_OPEN opening SQLite database '%1'</span></dt><dd><p>
Debug information. The SQLite data source is loading an SQLite database in
the provided file.
</p></dd><dt><a name="DATASRC_SQLITE_PREVIOUS"></a><span class="term">DATASRC_SQLITE_PREVIOUS looking for name previous to '%1'</span></dt><dd><p>
This is a debug message.  The name given was not found, so the program
is searching for the next name higher up the hierarchy (e.g. if
www.example.com were queried for and not found, the software searches
for the "previous" name, example.com).
</p></dd><dt><a name="DATASRC_SQLITE_PREVIOUS_NO_ZONE"></a><span class="term">DATASRC_SQLITE_PREVIOUS_NO_ZONE no zone containing '%1'</span></dt><dd><p>
The name given was not found, so the program is searching for the next
name higher up the hierarchy (e.g. if www.example.com were queried
for and not found, the software searches for the "previous" name,
example.com). However, this name is not contained in any zone in the
data source. This is an error since it indicates a problem in the earlier
processing of the query.
</p></dd><dt><a name="DATASRC_SQLITE_SETUP"></a><span class="term">DATASRC_SQLITE_SETUP setting up SQLite database</span></dt><dd><p>
The database for SQLite data source was found empty. It is assumed this is the
first run and it is being initialized with current schema.  It'll still contain
no data, but it will be ready for use.
</p></dd><dt><a name="DATASRC_STATIC_CLASS_NOT_CH"></a><span class="term">DATASRC_STATIC_CLASS_NOT_CH static data source can handle CH class only</span></dt><dd><p>
An error message indicating that a query requesting a RR for a class other
that CH was sent to the static data source (which only handles CH queries).
</p></dd><dt><a name="DATASRC_STATIC_CREATE"></a><span class="term">DATASRC_STATIC_CREATE creating the static datasource</span></dt><dd><p>
Debug information. The static data source (the one holding stuff like
version.bind) is being created.
</p></dd><dt><a name="DATASRC_STATIC_FIND"></a><span class="term">DATASRC_STATIC_FIND looking for '%1/%2'</span></dt><dd><p>
Debug information. This resource record set is being looked up in the static
data source.
</p></dd><dt><a name="DATASRC_UNEXPECTED_QUERY_STATE"></a><span class="term">DATASRC_UNEXPECTED_QUERY_STATE unexpected query state</span></dt><dd><p>
This indicates a programming error. An internal task of unknown type was
generated.
</p></dd><dt><a name="DBUTIL_BACKUP"></a><span class="term">DBUTIL_BACKUP created backup of %1 in %2</span></dt><dd><p>
A backup for the given database file was created. Same of original file and
backup are given in the output message.
</p></dd><dt><a name="DBUTIL_CHECK_ERROR"></a><span class="term">DBUTIL_CHECK_ERROR unable to check database version: %1</span></dt><dd><p>
There was an error while trying to check the current version of the database
schema. The error is shown in the message.
</p></dd><dt><a name="DBUTIL_CHECK_NOCONFIRM"></a><span class="term">DBUTIL_CHECK_NOCONFIRM --noconfirm is not compatible with --check</span></dt><dd><p>
b10-dbutil was called with --check and --noconfirm. --noconfirm only has
meaning with --upgrade, so this is considered an error.
</p></dd><dt><a name="DBUTIL_CHECK_OK"></a><span class="term">DBUTIL_CHECK_OK this is the latest version of the database schema. No upgrade is required</span></dt><dd><p>
The database schema version has been checked, and is up to date.
No action is required.
</p></dd><dt><a name="DBUTIL_CHECK_UPGRADE_NEEDED"></a><span class="term">DBUTIL_CHECK_UPGRADE_NEEDED re-run this program with the --upgrade switch to upgrade</span></dt><dd><p>
The database schema version is not up to date, and an update is required.
Please run the dbutil tool again, with the --upgrade argument.
</p></dd><dt><a name="DBUTIL_COMMAND_NONE"></a><span class="term">DBUTIL_COMMAND_NONE must select one of --check or --upgrade</span></dt><dd><p>
b10-dbutil was called with neither --check nor --upgrade. One action must be
provided.
</p></dd><dt><a name="DBUTIL_COMMAND_UPGRADE_CHECK"></a><span class="term">DBUTIL_COMMAND_UPGRADE_CHECK --upgrade is not compatible with --check</span></dt><dd><p>
b10-dbutil was called with both the commands --upgrade and --check. Only one
action can be performed at a time.
</p></dd><dt><a name="DBUTIL_DATABASE_MAY_BE_CORRUPT"></a><span class="term">DBUTIL_DATABASE_MAY_BE_CORRUPT database file %1 may be corrupt, restore it from backup (%2)</span></dt><dd><p>
The upgrade failed while it was in progress; the database may now be in an
inconsistent state, and it is advised to restore it from the backup that was
created when b10-dbutil started.
</p></dd><dt><a name="DBUTIL_EXECUTE"></a><span class="term">DBUTIL_EXECUTE Executing SQL statement: %1</span></dt><dd><p>
Debug message; the given SQL statement is executed
</p></dd><dt><a name="DBUTIL_FILE"></a><span class="term">DBUTIL_FILE Database file: %1</span></dt><dd><p>
The database file that is being checked.
</p></dd><dt><a name="DBUTIL_NO_FILE"></a><span class="term">DBUTIL_NO_FILE must supply name of the database file to upgrade</span></dt><dd><p>
b10-dbutil was called without a database file. Currently, it cannot find this
file on its own, and it must be provided.
</p></dd><dt><a name="DBUTIL_STATEMENT_ERROR"></a><span class="term">DBUTIL_STATEMENT_ERROR failed to execute %1: %2</span></dt><dd><p>
The given database statement failed to execute. The error is shown in the
message.
</p></dd><dt><a name="DBUTIL_TOO_MANY_ARGUMENTS"></a><span class="term">DBUTIL_TOO_MANY_ARGUMENTS too many arguments to the command, maximum of one expected</span></dt><dd><p>
There were too many command-line arguments to b10-dbutil
</p></dd><dt><a name="DBUTIL_UPGRADE_CANCELED"></a><span class="term">DBUTIL_UPGRADE_CANCELED upgrade canceled; database has not been changed</span></dt><dd><p>
The user aborted the upgrade, and b10-dbutil will now exit.
</p></dd><dt><a name="DBUTIL_UPGRADE_DBUTIL"></a><span class="term">DBUTIL_UPGRADE_DBUTIL please get the latest version of b10-dbutil and re-run</span></dt><dd><p>
A database schema was found that was newer than this version of dbutil, which
is apparently out of date and should be upgraded itself.
</p></dd><dt><a name="DBUTIL_UPGRADE_FAILED"></a><span class="term">DBUTIL_UPGRADE_FAILED upgrade failed: %1</span></dt><dd><p>
While the upgrade was in progress, an unexpected error occurred. The error
is shown in the message.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_ATTEMPTED"></a><span class="term">DBUTIL_UPGRADE_NOT_ATTEMPTED database upgrade was not attempted</span></dt><dd><p>
Due to the earlier failure, the database schema upgrade was not attempted,
and b10-dbutil will now exit.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_NEEDED"></a><span class="term">DBUTIL_UPGRADE_NOT_NEEDED database already at latest version, no upgrade necessary</span></dt><dd><p>
b10-dbutil was told to upgrade the database schema, but it is already at the
latest version.
</p></dd><dt><a name="DBUTIL_UPGRADE_NOT_POSSIBLE"></a><span class="term">DBUTIL_UPGRADE_NOT_POSSIBLE database at a later version than this utility can support</span></dt><dd><p>
b10-dbutil was told to upgrade the database schema, but it is at a higher
version than this tool currently supports. Please update b10-dbutil and try
again.
</p></dd><dt><a name="DBUTIL_UPGRADE_PREPARATION_FAILED"></a><span class="term">DBUTIL_UPGRADE_PREPARATION_FAILED upgrade preparation failed: %1</span></dt><dd><p>
An unexpected error occurred while b10-dbutil was preparing to upgrade the
database schema. The error is shown in the message
</p></dd><dt><a name="DBUTIL_UPGRADE_SUCCESFUL"></a><span class="term">DBUTIL_UPGRADE_SUCCESFUL database upgrade successfully completed</span></dt><dd><p>
The database schema update was completed successfully.
</p></dd><dt><a name="DBUTIL_UPGRADING"></a><span class="term">DBUTIL_UPGRADING upgrading database from %1 to %2</span></dt><dd><p>
An upgrade is in progress, the versions of the current upgrade action are shown.
</p></dd><dt><a name="DBUTIL_VERSION_CURRENT"></a><span class="term">DBUTIL_VERSION_CURRENT database version %1</span></dt><dd><p>
The current version of the database schema.
</p></dd><dt><a name="DBUTIL_VERSION_HIGH"></a><span class="term">DBUTIL_VERSION_HIGH database is at a later version (%1) than this program can cope with (%2)</span></dt><dd><p>
The database schema is at a higher version than b10-dbutil knows about.
</p></dd><dt><a name="DBUTIL_VERSION_LOW"></a><span class="term">DBUTIL_VERSION_LOW database version %1, latest version is %2.</span></dt><dd><p>
The database schema is not up to date, the current version and the latest
version are in the message.
</p></dd><dt><a name="DDNS_ACCEPT_FAILURE"></a><span class="term">DDNS_ACCEPT_FAILURE error accepting a connection: %1</span></dt><dd><p>
There was a low-level error when we tried to accept an incoming connection
(probably coming from b10-auth). We continue serving on whatever other
connections we already have, but this connection is dropped. The reason
is logged.
</p></dd><dt><a name="DDNS_AUTH_DBFILE_UPDATE"></a><span class="term">DDNS_AUTH_DBFILE_UPDATE updated auth DB file to %1</span></dt><dd><p>
b10-ddns was notified of updates to the SQLite3 DB file that b10-auth
uses for the underlying data source and on which b10-ddns needs to
make updates.  b10-ddns then updated its internal setup so further
updates would be made on the new DB.
</p></dd><dt><a name="DDNS_CC_SESSION_ERROR"></a><span class="term">DDNS_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
There was a problem reading from the command and control channel. The
most likely cause is that the msgq process is not running.
</p></dd><dt><a name="DDNS_CC_SESSION_TIMEOUT_ERROR"></a><span class="term">DDNS_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</span></dt><dd><p>
There was a problem reading a response from another module over the
command and control channel. The most likely cause is that the
configuration manager b10-cfgmgr is not running.
</p></dd><dt><a name="DDNS_CONFIG_ERROR"></a><span class="term">DDNS_CONFIG_ERROR error found in configuration data: %1</span></dt><dd><p>
The ddns process encountered an error when installing the configuration at
startup time.  Details of the error are included in the log message.
</p></dd><dt><a name="DDNS_CONFIG_HANDLER_ERROR"></a><span class="term">DDNS_CONFIG_HANDLER_ERROR failed to update ddns configuration: %1</span></dt><dd><p>
An update to b10-ddns configuration was delivered but an error was
found while applying them.  None of the delivered updates were applied
to the running b10-ddns system, and the server will keep running with
the existing configuration.  If this happened in the initial
configuration setup, the server will be running with the default
configurations.
</p></dd><dt><a name="DDNS_DROP_CONN"></a><span class="term">DDNS_DROP_CONN dropping connection on file descriptor %1 because of error %2</span></dt><dd><p>
There was an error on a connection with the b10-auth server (or whatever
connects to the ddns daemon). This might be OK, for example when the
authoritative server shuts down, the connection would get closed. It also
can mean the system is busy and can't keep up or that the other side got
confused and sent bad data.
</p></dd><dt><a name="DDNS_GET_REMOTE_CONFIG_FAIL"></a><span class="term">DDNS_GET_REMOTE_CONFIG_FAIL failed to get %1 module configuration %2 times: %3</span></dt><dd><p>
b10-ddns tried to get configuration of some remote modules for its
operation, but it failed.  The most likely cause of this is that the
remote module has not fully started up and b10-ddns couldn't get the
configuration in a timely fashion.  b10-ddns attempts to retry it a
few times, imposing a short delay, hoping it eventually succeeds if
it's just a timing issue.  The number of total failed attempts is also
logged.  If it reaches an internal threshold b10-ddns considers it a
fatal error and terminates.  Even in that case, if b10-ddns is
configured as a "dispensable" component (which is the default), the
parent bind10 process will restart it, and there will be another
chance of getting the remote configuration successfully.  These are
not the optimal behavior, but it's believed to be sufficient in
practice (there would normally be no failure in the first place).  If
it really causes an operational trouble other than having a few of
these log messages, please submit a bug report; there can be several
ways to make it more sophisticated.  Another, less likely reason for
having this error is because the remote modules are not actually
configured to run.  If that's the case fixing the configuration should
solve the problem - either by making sure the remote module will run
or by not running b10-ddns (without these remote modules b10-ddns is
not functional, so there's no point in running it in this case).
</p></dd><dt><a name="DDNS_MODULECC_SESSION_ERROR"></a><span class="term">DDNS_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</span></dt><dd><p>
There was a problem in the lower level module handling configuration and
control commands.  This could happen for various reasons, but the most likely
cause is that the configuration database contains a syntax error and ddns
failed to start at initialization.  A detailed error message from the module
will also be displayed.
</p></dd><dt><a name="DDNS_NEW_CONN"></a><span class="term">DDNS_NEW_CONN new connection on file descriptor %1 from %2</span></dt><dd><p>
Debug message. We received a connection and we are going to start handling
requests from it. The file descriptor number and the address where the request
comes from is logged. The connection is over a unix domain socket and is likely
coming from a b10-auth process.
</p></dd><dt><a name="DDNS_RECEIVED_AUTH_UPDATE"></a><span class="term">DDNS_RECEIVED_AUTH_UPDATE received configuration updates from auth server</span></dt><dd><p>
b10-ddns is notified of updates to b10-auth configuration
(including a report of the initial configuration) that b10-ddns might
be interested in.
</p></dd><dt><a name="DDNS_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">DDNS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
The ddns process received a shutdown command from the command channel
and will now shut down.
</p></dd><dt><a name="DDNS_RECEIVED_ZONEMGR_UPDATE"></a><span class="term">DDNS_RECEIVED_ZONEMGR_UPDATE received configuration updates from zonemgr</span></dt><dd><p>
b10-ddns is notified of updates to b10-zonemgr's configuration
(including a report of the initial configuration).  It may possibly
contain changes to the secondary zones, in which case b10-ddns will
update its internal copy of that configuration.
</p></dd><dt><a name="DDNS_REQUEST_PARSE_FAIL"></a><span class="term">DDNS_REQUEST_PARSE_FAIL failed to parse update request: %1</span></dt><dd><p>
b10-ddns received an update request via b10-auth, but the received
data failed to pass minimum validation: it was either broken wire
format data for a valid DNS message (e.g. it's shorter than the
fixed-length header), or the opcode is not update, or TSIG is included
in the request but it fails to validate.  Since b10-auth should have
performed this level of checks, such an error shouldn't be detected at
this stage and should rather be considered an internal bug.  This
event is therefore logged at the error level, and the request is
simply dropped.  Additional information of the error is also logged.
</p></dd><dt><a name="DDNS_REQUEST_TCP_QUOTA"></a><span class="term">DDNS_REQUEST_TCP_QUOTA reject TCP update client %1 (%2 running)</span></dt><dd><p>
b10-ddns received a new update request from a client over TCP, but
the number of TCP clients being handled by the server already reached
the configured quota, so the latest client was rejected by closing
the connection.  The administrator may want to check the status of
b10-ddns, and if this happens even if the server is not very busy,
the quota may have to be increased.  Or, if it's more likely to be
malicious or simply bogus clients that somehow keep the TCP connection
open for a long period, maybe they should be rejected with an
appropriate ACL configuration or some lower layer filtering.  The
number of existing TCP clients are shown in the log, which should be
identical to the current quota.
</p></dd><dt><a name="DDNS_RESPONSE_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_SOCKET_ERROR failed to send update response to %1: %2</span></dt><dd><p>
Network I/O error happens in sending an update response.  The
client's address that caused the error and error details are also
logged.
</p></dd><dt><a name="DDNS_RESPONSE_TCP_SOCKET_ERROR"></a><span class="term">DDNS_RESPONSE_TCP_SOCKET_ERROR failed to complete sending update response to %1 over TCP</span></dt><dd><p>
b10-ddns had tried to send an update response over TCP, and it hadn't
been completed at that time, and a followup attempt to complete the
send operation failed due to some network I/O error.  While a network
error can happen any time, this event is quite unexpected for two
reasons.  First, since the size of a response to an update request
should be generally small, it's unlikely that the initial attempt
didn't fail but wasn't completed.  Second, since the first attempt
succeeded and the TCP connection had been established in the first
place, it's more likely for the subsequent attempt to succeed.  In any
case, there may not be able to do anything to fix it at the server
side, but the administrator may want to check the general reachability
with the client address.
</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE updated secondary zone list (%1 zones are listed)</span></dt><dd><p>
b10-ddns has successfully updated the internal copy of secondary zones
obtained from b10-zonemgr, based on a latest update to zonemgr's
configuration.  The number of newly configured (unique) secondary
zones is logged.
</p></dd><dt><a name="DDNS_SECONDARY_ZONES_UPDATE_FAIL"></a><span class="term">DDNS_SECONDARY_ZONES_UPDATE_FAIL failed to update secondary zone list: %1</span></dt><dd><p>
An error message.  b10-ddns was notified of updates to a list of
secondary zones from b10-zonemgr and tried to update its own internal
copy of the list, but it failed.  This can happen if the configuration
contains an error, and b10-zonemgr should also reject that update.
Unfortunately, in the current implementation there is no way to ensure
that both zonemgr and ddns have consistent information when an update
contains an error; further, as of this writing zonemgr has a bug that
it could partially update the list of secondary zones if part of the
list has an error (see Trac ticket #2038).  b10-ddns still keeps
running with the previous configuration, but it's strongly advisable
to check log messages from zonemgr, and if it indicates there can be
inconsistent state, it's better to restart the entire BIND 10 system
(just restarting b10-ddns wouldn't be enough, because zonemgr can have
partially updated configuration due to bug #2038).  The log message
contains an error description, but it's intentionally kept simple as
it's primarily a matter of zonemgr.  To know the details of the error,
log messages of zonemgr should be consulted.
</p></dd><dt><a name="DDNS_SESSION"></a><span class="term">DDNS_SESSION session arrived on file descriptor %1</span></dt><dd><p>
A debug message, informing there's some activity on the given file descriptor.
It will be either a request or the file descriptor will be closed. See
following log messages to see what of it.
</p></dd><dt><a name="DDNS_SHUTDOWN"></a><span class="term">DDNS_SHUTDOWN ddns server shutting down</span></dt><dd><p>
The ddns process is shutting down. It will no longer listen for new commands
or updates. Any command or update that is being addressed at this moment will
be completed, after which the process will exit.
</p></dd><dt><a name="DDNS_STARTED"></a><span class="term">DDNS_STARTED ddns server is running and listening for updates</span></dt><dd><p>
The ddns process has successfully started and is now ready to receive commands
and updates.
</p></dd><dt><a name="DDNS_START_FORWARDER_ERROR"></a><span class="term">DDNS_START_FORWARDER_ERROR Error from b10-auth when requesting DDNS UPDATE forwarding: %1</span></dt><dd><p>
There was an error response from b10-auth to the command to start
forwarding DDNS UPDATE messages to b10-ddns.
It is almost certain that DDNS UPDATE messages are not handled now, and that
they will be responded to with a NOTIMP error code, even though b10-ddns is
running.
The error message is printed, and additional information may be found in
the b10-auth log output. Since this is an error that is sent by the
b10-auth module, it should have more information as to what the actual
problem was.
</p></dd><dt><a name="DDNS_START_FORWARDER_FAIL"></a><span class="term">DDNS_START_FORWARDER_FAIL Error sending request for DDNS UPDATE forwarding to b10-auth: %1</span></dt><dd><p>
There was an error when attempting to send b10-auth the request to forward
DDNS UPDATE messages to the b10-ddns module. This points to an internal
problem using the inter-module messaging system.
This needs to be inspected, as it is almost certain that DDNS UPDATE messages
are not handled now.
The specific error is printed in the log message.
</p></dd><dt><a name="DDNS_STOPPED"></a><span class="term">DDNS_STOPPED ddns server has stopped</span></dt><dd><p>
The ddns process has successfully stopped and is no longer listening for or
handling commands or updates, and will now exit.
</p></dd><dt><a name="DDNS_STOPPED_BY_KEYBOARD"></a><span class="term">DDNS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the ddns process. The
process will now shut down.
</p></dd><dt><a name="DDNS_STOP_FORWARDER_ERROR"></a><span class="term">DDNS_STOP_FORWARDER_ERROR Error from b10-auth when requesting to stop DDNS UPDATE forwarding: %1</span></dt><dd><p>
There was an error response from b10-auth to the command to stop
forwarding DDNS UPDATE messages to b10-ddns.
This specific error may not be fatal; instead of returning NOTIMP for future
DDNS UPDATE messages, it will return SERVFAIL. However, this does point to
an underlying problem in the messaging system, and should be inspected.
The error message is printed, and additional information may be found in
the b10-auth log output.
</p></dd><dt><a name="DDNS_STOP_FORWARDER_FAIL"></a><span class="term">DDNS_STOP_FORWARDER_FAIL Error sending request to stop DDNS UPDATE forwarding to b10-auth: %1</span></dt><dd><p>
There was an error when attempting to send b10-auth the request to stop
forwarding DDNS UPDATE messages to the b10-ddns module. This points to an
internal problem using the inter-module messaging system.
This specific error may not be fatal; instead of returning NOTIMP for future
DDNS UPDATE messages, it will return SERVFAIL. However, this does point to
an underlying problem in the messaging system, and should be inspected.
The specific error is printed in the log message.
</p></dd><dt><a name="DDNS_UNCAUGHT_EXCEPTION"></a><span class="term">DDNS_UNCAUGHT_EXCEPTION uncaught exception of type %1: %2</span></dt><dd><p>
The b10-ddns process encountered an uncaught exception and will now shut
down. This is indicative of a programming error and should not happen under
normal circumstances. The exception type and message are printed.
</p></dd><dt><a name="DDNS_UPDATE_NOTIFY"></a><span class="term">DDNS_UPDATE_NOTIFY notified %1 of updates to %2</span></dt><dd><p>
Debug message.  b10-ddns has made updates to a zone based on an update
request and has successfully notified an external module of the updates.
The notified module will use that information for updating its own
state or any necessary protocol action such as zone reloading or sending
notify messages to secondary servers.
</p></dd><dt><a name="DDNS_UPDATE_NOTIFY_FAIL"></a><span class="term">DDNS_UPDATE_NOTIFY_FAIL failed to notify %1 of updates to %2: %3</span></dt><dd><p>
b10-ddns has made updates to a zone based on an update request and
tried to notify an external component of the updates, but the
notification fails.  One possible cause of this is that the external
component is not really running and it times out in waiting for the
response, although it will be less likely to happen in practice
because these components will normally be configured to run when the
server provides the authoritative DNS service; ddns is rather optional
among them.  If this happens, however, it will suspend b10-ddns for a
few seconds during which it cannot handle new requests (some may be
delayed, some may be dropped, depending on the volume of the incoming
requests).  This is obviously bad, and if this error happens due to
this reason, the administrator should make sure the component in
question should be configured to run.  For a longer term, b10-ddns
should be more robust about this case such as by making this
notification asynchronously and/or detecting the existence of the
external components to avoid hopeless notification in the first place.
Severity of this error for the receiving components depends on the
type of the component.  If it's b10-xfrout, this means DNS notify
messages won't be sent to secondary servers of the zone.  It's
suboptimal, but not necessarily critical as the secondary servers will
try to check the zone's status periodically.  If it's b10-auth and the
notification was needed to have it reload the corresponding zone, it's
more serious because b10-auth won't be able to serve the new version
of the zone unless some explicit recovery action is taken.  So the
administrator needs to examine this message and takes an appropriate
action.  In either case, this notification is generally expected to
succeed; so the fact it fails itself means there's something wrong in
the BIND 10 system, and it would be advisable to check other log
messages.
</p></dd><dt><a name="LIBDDNS_DATASRC_ERROR"></a><span class="term">LIBDDNS_DATASRC_ERROR update client %1 failed due to data source error: %2</span></dt><dd><p>
An update attempt failed due to some error in the corresponding data
source.  This is generally an unexpected event, but can still happen
for various reasons such as DB lock contention or a failure of the
backend DB server.  The cause of the error is also logged.  It's
advisable to check the message, and, if necessary, take an appropriate
action (e.g., restarting the DB server if it dies).  If this message
is logged the data source isn't modified due to the
corresponding update request.  When used by the b10-ddns, the server
will return a response with an RCODE of SERVFAIL.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR"></a><span class="term">LIBDDNS_PREREQ_FORMERR update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it has a non-zero TTL value.
A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_ANY"></a><span class="term">LIBDDNS_PREREQ_FORMERR_ANY update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_CLASS"></a><span class="term">LIBDDNS_PREREQ_FORMERR_CLASS update client %1 for zone %2: Format error in prerequisite (%3). Bad class.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, the class of the
prerequisite should either match the class of the zone in the Zone Section,
or it should be ANY or NONE, and it is not. A FORMERR error response is sent
to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_FORMERR_NONE"></a><span class="term">LIBDDNS_PREREQ_FORMERR_NONE update client %1 for zone %2: Format error in prerequisite (%3). Non-zero TTL or rdata found.</span></dt><dd><p>
The prerequisite with the given name, class and type is not well-formed.
The specific prerequisite is shown. In this case, it either has a non-zero
TTL value, or has rdata fields. A FORMERR error response is sent to the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_IN_USE_FAILED update client %1 for zone %2: 'Name is in use' prerequisite not satisfied (%3), rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is in use'. From RFC2136:
Name is in use.  At least one RR with a specified NAME (in
the zone and class specified by the Zone Section) must exist.
Note that this prerequisite is NOT satisfied by empty
nonterminals.
</p></dd><dt><a name="LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED"></a><span class="term">LIBDDNS_PREREQ_NAME_NOT_IN_USE_FAILED update client %1 for zone %2: 'Name is not in use' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'Name is not in use'.
From RFC2136:
Name is not in use.  No RR of any type is owned by a
specified NAME.  Note that this prerequisite IS satisfied by
empty nonterminals.
</p></dd><dt><a name="LIBDDNS_PREREQ_NOTZONE"></a><span class="term">LIBDDNS_PREREQ_NOTZONE update client %1 for zone %2: prerequisite not in zone (%3)</span></dt><dd><p>
A DDNS UPDATE prerequisite has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific prerequisite is shown. A NOTZONE error response is sent to
the client.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_DOES_NOT_EXIST_FAILED update client %1 for zone %2: 'RRset does not exist' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset does not exist'.
From RFC2136:
RRset does not exist.  No RRs with a specified NAME and TYPE
(in the zone and class denoted by the Zone Section) can exist.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_FAILED update client %1 for zone %2: 'RRset exists (value independent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value independent)'.
From RFC2136:
RRset exists (value dependent).  A set of RRs with a
specified NAME and TYPE exists and has the same members
with the same RDATAs as the RRset specified here in this
Section.
</p></dd><dt><a name="LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED"></a><span class="term">LIBDDNS_PREREQ_RRSET_EXISTS_VAL_FAILED update client %1 for zone %2: 'RRset exists (value dependent)' (%3) prerequisite not satisfied, rcode: %4</span></dt><dd><p>
A DNS UPDATE prerequisite was not satisfied. The specific prerequisite that
was not satisfied is shown. The client is sent an error response with the
given rcode.
In this case, the specific prerequisite is 'RRset exists (value dependent)'.
From RFC2136:
RRset exists (value independent).  At least one RR with a
specified NAME and TYPE (in the zone and class specified by
the Zone Section) must exist.
</p></dd><dt><a name="LIBDDNS_UPDATE_ADD_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_ADD_BAD_TYPE update client %1 for zone %2: update addition RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to add a record of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_APPROVED"></a><span class="term">LIBDDNS_UPDATE_APPROVED update client %1 for zone %2 approved</span></dt><dd><p>
Debug message.  An update request was approved in terms of the zone's
update ACL.
</p></dd><dt><a name="LIBDDNS_UPDATE_BAD_CLASS"></a><span class="term">LIBDDNS_UPDATE_BAD_CLASS update client %1 for zone %2: bad class in update RR: %3</span></dt><dd><p>
The Update section of a DDNS update message contains an RRset with
a bad class. The class of the update RRset must be either the same
as the class in the Zone Section, ANY, or NONE.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DATASRC_ERROR"></a><span class="term">LIBDDNS_UPDATE_DATASRC_ERROR error in datasource during DDNS update: %1</span></dt><dd><p>
An error occured while committing the DDNS update changes to the
datasource. The specific error is printed. A SERVFAIL response is sent
back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to delete an rrset of an invalid type. Most likely the
record has an RRType that is considered a 'meta' type, which
cannot be zone content data. The specific record is shown.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY"></a><span class="term">LIBDDNS_UPDATE_DELETE_RRSET_NOT_EMPTY update client %1 for zone %2: update deletion RR contains data %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrset'
statement with a non-empty RRset. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_BAD_TYPE update client %1 for zone %2: update deletion RR bad type: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a statement
that tries to delete one or more rrs of an invalid type. Most
likely the records have an RRType that is considered a 'meta'
type, which cannot be zone content data. The specific record is
shown. A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL"></a><span class="term">LIBDDNS_UPDATE_DELETE_RR_NONZERO_TTL update client %1 for zone %2: update deletion RR has non-zero TTL: %3</span></dt><dd><p>
The Update section of a DDNS update message contains a 'delete rrs'
statement with a non-zero TTL. This is not allowed by the protocol.
A FORMERR response is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_DENIED"></a><span class="term">LIBDDNS_UPDATE_DENIED update client %1 for zone %2 denied</span></dt><dd><p>
Informational message.  An update request was denied because it was
rejected by the zone's update ACL.  When this library is used by
b10-ddns, the server will respond to the request with an RCODE of
REFUSED as described in Section 3.3 of RFC2136.
</p></dd><dt><a name="LIBDDNS_UPDATE_DROPPED"></a><span class="term">LIBDDNS_UPDATE_DROPPED update client %1 for zone %2 dropped</span></dt><dd><p>
Informational message.  An update request was denied because it was
rejected by the zone's update ACL.  When this library is used by
b10-ddns, the server will then completely ignore the request; no
response will be sent.
</p></dd><dt><a name="LIBDDNS_UPDATE_ERROR"></a><span class="term">LIBDDNS_UPDATE_ERROR update client %1 for zone %2: %3</span></dt><dd><p>
Debug message.  An error is found in processing a dynamic update
request.  This log message is used for general errors that are not
normally expected to happen.  So, in general, it would mean some
problem in the client implementation or an interoperability issue
with this implementation.  The client's address, the zone name and
class, and description of the error are logged.
</p></dd><dt><a name="LIBDDNS_UPDATE_FORWARD_FAIL"></a><span class="term">LIBDDNS_UPDATE_FORWARD_FAIL update client %1 for zone %2: update forwarding not supported</span></dt><dd><p>
Debug message.  An update request is sent to a secondary server.  This
is not necessarily invalid, but this implementation does not yet
support update forwarding as specified in Section 6 of RFC2136 and it
will simply return a response with an RCODE of NOTIMP to the client.
The client's address and the zone name/class are logged.
</p></dd><dt><a name="LIBDDNS_UPDATE_NOTAUTH"></a><span class="term">LIBDDNS_UPDATE_NOTAUTH update client %1 for zone %2: not authoritative for update zone</span></dt><dd><p>
Debug message.  An update request was received for a zone for which
the receiving server doesn't have authority.  In theory this is an
unexpected event, but there are client implementations that could send
update requests carelessly, so it may not necessarily be so uncommon
in practice.  If possible, you may want to check the implementation or
configuration of those clients to suppress the requests.  As specified
in Section 3.1 of RFC2136, the receiving server will return a response
with an RCODE of NOTAUTH.
</p></dd><dt><a name="LIBDDNS_UPDATE_NOTZONE"></a><span class="term">LIBDDNS_UPDATE_NOTZONE update client %1 for zone %2: update RR out of zone %3</span></dt><dd><p>
A DDNS UPDATE record has a name that does not appear to be inside
the zone specified in the Zone section of the UPDATE message.
The specific update record is shown. A NOTZONE error response is
sent to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_PREREQUISITE_FAILED"></a><span class="term">LIBDDNS_UPDATE_PREREQUISITE_FAILED prerequisite failed in update client %1 for zone %2: result code %3</span></dt><dd><p>
The handling of the prerequisite section (RFC2136 Section 3.2) found
that one of the prerequisites was not satisfied. The result code
should give more information on what prerequisite type failed.
If the result code is FORMERR, the prerequisite section was not well-formed.
An error response with the given result code is sent back to the client.
</p></dd><dt><a name="LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION"></a><span class="term">LIBDDNS_UPDATE_UNCAUGHT_EXCEPTION update client %1 for zone %2: uncaught exception while processing update section: %3</span></dt><dd><p>
An uncaught exception was encountered while processing the Update
section of a DDNS message. The specific exception is shown in the log message.
To make sure DDNS service is not interrupted, this problem is caught instead
of reraised; The update is aborted, and a SERVFAIL is sent back to the client.
This is most probably a bug in the DDNS code, but *could* be caused by
the data source.
</p></dd><dt><a name="LIBXFRIN_DIFFERENT_TTL"></a><span class="term">LIBXFRIN_DIFFERENT_TTL multiple data with different TTLs (%1, %2) on %3/%4/%5. Adjusting %2 -&gt; %1.</span></dt><dd><p>
The xfrin module received an update containing multiple rdata changes for the
same RRset. But the TTLs of these don't match each other. As we combine them
together, the latter one gets overwritten to the earlier one in the sequence.
</p></dd><dt><a name="LIBXFRIN_NO_JOURNAL"></a><span class="term">LIBXFRIN_NO_JOURNAL disabled journaling for updates to %1 on %2</span></dt><dd><p>
An attempt was made to create a Diff object with journaling enabled, but
the underlying data source didn't support journaling (while still allowing
updates) and so the created object has it disabled.  At a higher level this
means that the updates will be applied to the zone but subsequent IXFR requests
will result in a full zone transfer (i.e., an AXFR-style IXFR).  Unless the
overhead of the full transfer is an issue this message can be ignored;
otherwise you may want to check why the journaling wasn't allowed on the
data source and either fix the issue or use a different type of data source.
</p></dd><dt><a name="LOGIMPL_ABOVE_MAX_DEBUG"></a><span class="term">LOGIMPL_ABOVE_MAX_DEBUG debug level of %1 is too high and will be set to the maximum of %2</span></dt><dd><p>
A message from the interface to the underlying logger implementation reporting
that the debug level (as set by an internally-created string DEBUGn, where n
is an integer, e.g. DEBUG22) is above the maximum allowed value and has
been reduced to that value.  The appearance of this message may indicate
a programming error - please submit a bug report.
</p></dd><dt><a name="LOGIMPL_BAD_DEBUG_STRING"></a><span class="term">LOGIMPL_BAD_DEBUG_STRING debug string '%1' has invalid format</span></dt><dd><p>
A message from the interface to the underlying logger implementation
reporting that an internally-created string used to set the debug level
is not of the correct format (it should be of the form DEBUGn, where n
is an integer, e.g. DEBUG22).  The appearance of this message indicates
a programming error - please submit a bug report.
</p></dd><dt><a name="LOGIMPL_BELOW_MIN_DEBUG"></a><span class="term">LOGIMPL_BELOW_MIN_DEBUG debug level of %1 is too low and will be set to the minimum of %2</span></dt><dd><p>
A message from the interface to the underlying logger implementation reporting
that the debug level (as set by an internally-created string DEBUGn, where n
is an integer, e.g. DEBUG22) is below the minimum allowed value and has
been increased to that value.  The appearance of this message may indicate
a programming error - please submit a bug report.
</p></dd><dt><a name="LOG_BAD_DESTINATION"></a><span class="term">LOG_BAD_DESTINATION unrecognized log destination: %1</span></dt><dd><p>
A logger destination value was given that was not recognized. The
destination should be one of "console", "file", or "syslog".
</p></dd><dt><a name="LOG_BAD_SEVERITY"></a><span class="term">LOG_BAD_SEVERITY unrecognized log severity: %1</span></dt><dd><p>
A logger severity value was given that was not recognized. The severity
should be one of "DEBUG", "INFO", "WARN", "ERROR", "FATAL" or "NONE".
</p></dd><dt><a name="LOG_BAD_STREAM"></a><span class="term">LOG_BAD_STREAM bad log console output stream: %1</span></dt><dd><p>
Logging has been configured so that output is written to the terminal
(console) but the stream on which it is to be written is not recognised.
Allowed values are "stdout" and "stderr".
</p></dd><dt><a name="LOG_DUPLICATE_MESSAGE_ID"></a><span class="term">LOG_DUPLICATE_MESSAGE_ID duplicate message ID (%1) in compiled code</span></dt><dd><p>
During start-up, BIND 10 detected that the given message identification
had been defined multiple times in the BIND 10 code.  This indicates a
programming error; please submit a bug report.
</p></dd><dt><a name="LOG_DUPLICATE_NAMESPACE"></a><span class="term">LOG_DUPLICATE_NAMESPACE line %1: duplicate $NAMESPACE directive found</span></dt><dd><p>
When reading a message file, more than one $NAMESPACE directive was found.
(This directive is used to set a C++ namespace when generating header
files during software development.)  Such a condition is regarded as an
error and the read will be abandoned.
</p></dd><dt><a name="LOG_INPUT_OPEN_FAIL"></a><span class="term">LOG_INPUT_OPEN_FAIL unable to open message file %1 for input: %2</span></dt><dd><p>
The program was not able to open the specified input message file for
the reason given.
</p></dd><dt><a name="LOG_INVALID_MESSAGE_ID"></a><span class="term">LOG_INVALID_MESSAGE_ID line %1: invalid message identification '%2'</span></dt><dd><p>
An invalid message identification (ID) has been found during the read of
a message file.  Message IDs should comprise only alphanumeric characters
and the underscore, and should not start with a digit.
</p></dd><dt><a name="LOG_LOCK_TEST_MESSAGE"></a><span class="term">LOG_LOCK_TEST_MESSAGE this is a test message.</span></dt><dd><p>
This is a log message used in testing.
</p></dd><dt><a name="LOG_NAMESPACE_EXTRA_ARGS"></a><span class="term">LOG_NAMESPACE_EXTRA_ARGS line %1: $NAMESPACE directive has too many arguments</span></dt><dd><p>
The $NAMESPACE directive in a message file takes a single argument, a
namespace in which all the generated symbol names are placed.  This error
is generated when the compiler finds a $NAMESPACE directive with more
than one argument.
</p></dd><dt><a name="LOG_NAMESPACE_INVALID_ARG"></a><span class="term">LOG_NAMESPACE_INVALID_ARG line %1: $NAMESPACE directive has an invalid argument ('%2')</span></dt><dd><p>
The $NAMESPACE argument in a message file should be a valid C++ namespace.
This message is output if the simple check on the syntax of the string
carried out by the reader fails.
</p></dd><dt><a name="LOG_NAMESPACE_NO_ARGS"></a><span class="term">LOG_NAMESPACE_NO_ARGS line %1: no arguments were given to the $NAMESPACE directive</span></dt><dd><p>
The $NAMESPACE directive in a message file takes a single argument,
a C++ namespace in which all the generated symbol names are placed.
This error is generated when the compiler finds a $NAMESPACE directive
with no arguments.
</p></dd><dt><a name="LOG_NO_MESSAGE_ID"></a><span class="term">LOG_NO_MESSAGE_ID line %1: message definition line found without a message ID</span></dt><dd><p>
Within a message file, message are defined by lines starting with a "%".
The rest of the line should comprise the message ID and text describing
the message.  This error indicates the message compiler found a line in
the message file comprising just the "%" and nothing else.
</p></dd><dt><a name="LOG_NO_MESSAGE_TEXT"></a><span class="term">LOG_NO_MESSAGE_TEXT line %1: line found containing a message ID ('%2') and no text</span></dt><dd><p>
Within a message file, message are defined by lines starting with a "%".
The rest of the line should comprise the message ID and text describing
the message.  This error indicates the message compiler found a line
in the message file comprising just the "%" and message identification,
but no text.
</p></dd><dt><a name="LOG_NO_SUCH_MESSAGE"></a><span class="term">LOG_NO_SUCH_MESSAGE could not replace message text for '%1': no such message</span></dt><dd><p>
During start-up a local message file was read.  A line with the listed
message identification was found in the file, but the identification is
not one contained in the compiled-in message dictionary.  This message
may appear a number of times in the file, once for every such unknown
message identification.
</p><p>
There may be several reasons why this message may appear:
</p><p>
- The message ID has been mis-spelled in the local message file.
</p><p>
- The program outputting the message may not use that particular message
(e.g. it originates in a module not used by the program.)
</p><p>
- The local file was written for an earlier version of the BIND 10 software
and the later version no longer generates that message.
</p><p>
Whatever the reason, there is no impact on the operation of BIND 10.
</p></dd><dt><a name="LOG_OPEN_OUTPUT_FAIL"></a><span class="term">LOG_OPEN_OUTPUT_FAIL unable to open %1 for output: %2</span></dt><dd><p>
Originating within the logging code, the program was not able to open
the specified output file for the reason given.
</p></dd><dt><a name="LOG_PREFIX_EXTRA_ARGS"></a><span class="term">LOG_PREFIX_EXTRA_ARGS line %1: $PREFIX directive has too many arguments</span></dt><dd><p>
Within a message file, the $PREFIX directive takes a single argument,
a prefix to be added to the symbol names when a C++ file is created.
This error is generated when the compiler finds a $PREFIX directive with
more than one argument.
</p><p>
Note: the $PREFIX directive is deprecated and will be removed in a future
version of BIND 10.
</p></dd><dt><a name="LOG_PREFIX_INVALID_ARG"></a><span class="term">LOG_PREFIX_INVALID_ARG line %1: $PREFIX directive has an invalid argument ('%2')</span></dt><dd><p>
Within a message file, the $PREFIX directive takes a single argument,
a prefix to be added to the symbol names when a C++ file is created.
As such, it must adhere to restrictions on C++ symbol names (e.g. may
only contain alphanumeric characters or underscores, and may nor start
with a digit).  A $PREFIX directive was found with an argument (given
in the message) that violates those restrictions.
</p><p>
Note: the $PREFIX directive is deprecated and will be removed in a future
version of BIND 10.
</p></dd><dt><a name="LOG_READING_LOCAL_FILE"></a><span class="term">LOG_READING_LOCAL_FILE reading local message file %1</span></dt><dd><p>
This is an informational message output by BIND 10 when it starts to read
a local message file.  (A local message file may replace the text of
one of more messages; the ID of the message will not be changed though.)
</p></dd><dt><a name="LOG_READ_ERROR"></a><span class="term">LOG_READ_ERROR error reading from message file %1: %2</span></dt><dd><p>
The specified error was encountered reading from the named message file.
</p></dd><dt><a name="LOG_UNRECOGNISED_DIRECTIVE"></a><span class="term">LOG_UNRECOGNISED_DIRECTIVE line %1: unrecognised directive '%2'</span></dt><dd><p>
Within a message file, a line starting with a dollar symbol was found
(indicating the presence of a directive) but the first word on the line
(shown in the message) was not recognised.
</p></dd><dt><a name="LOG_WRITE_ERROR"></a><span class="term">LOG_WRITE_ERROR error writing to %1: %2</span></dt><dd><p>
The specified error was encountered by the message compiler when writing
to the named output file.
</p></dd><dt><a name="NOTIFY_OUT_DATASRC_ACCESS_FAILURE"></a><span class="term">NOTIFY_OUT_DATASRC_ACCESS_FAILURE failed to get access to data source: %1</span></dt><dd><p>
notify_out failed to get access to one of configured data sources.
Detailed error is shown in the log message.  This can be either a
configuration error or installation setup failure.
</p></dd><dt><a name="NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND"></a><span class="term">NOTIFY_OUT_DATASRC_ZONE_NOT_FOUND Zone %1 is not found</span></dt><dd><p>
notify_out attempted to get slave information of a zone but the zone
isn't found in the expected data source.  This shouldn't happen,
because notify_out first identifies a list of available zones before
this process.  So this means some critical inconsistency in the data
source or software bug.
</p></dd><dt><a name="NOTIFY_OUT_INVALID_ADDRESS"></a><span class="term">NOTIFY_OUT_INVALID_ADDRESS invalid address %1#%2: %3</span></dt><dd><p>
The notify_out library tried to send a notify message to the given
address, but it appears to be an invalid address. The configuration
for secondary nameservers might contain a typographic error, or a
different BIND 10 module has forgotten to validate its data before
sending this module a notify command. As such, this should normally
not happen, and points to an oversight in a different module.
</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_OPCODE"></a><span class="term">NOTIFY_OUT_REPLY_BAD_OPCODE bad opcode in notify reply from %1#%2: %3</span></dt><dd><p>
The notify_out library sent a notify message to the nameserver at
the given address, but the response did not have the opcode set to
NOTIFY. The opcode in the response is printed. Since there was a
response, no more notifies will be sent to this server for this
notification event.
</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_QID"></a><span class="term">NOTIFY_OUT_REPLY_BAD_QID bad QID in notify reply from %1#%2: got %3, should be %4</span></dt><dd><p>
The notify_out library sent a notify message to the nameserver at
the given address, but the query id in the response does not match
the one we sent. Since there was a response, no more notifies will
be sent to this server for this notification event.
</p></dd><dt><a name="NOTIFY_OUT_REPLY_BAD_QUERY_NAME"></a><span class="term">NOTIFY_OUT_REPLY_BAD_QUERY_NAME bad query name in notify reply from %1#%2: got %3, should be %4</span></dt><dd><p>
The notify_out library sent a notify message to the nameserver at
the given address, but the query name in the response does not match
the one we sent. Since there was a response, no more notifies will
be sent to this server for this notification event.
</p></dd><dt><a name="NOTIFY_OUT_REPLY_QR_NOT_SET"></a><span class="term">NOTIFY_OUT_REPLY_QR_NOT_SET QR flags set to 0 in reply to notify from %1#%2</span></dt><dd><p>
The notify_out library sent a notify message to the namesever at the
given address, but the reply did not have the QR bit set to one.
Since there was a response, no more notifies will be sent to this
server for this notification event.
</p></dd><dt><a name="NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION"></a><span class="term">NOTIFY_OUT_REPLY_UNCAUGHT_EXCEPTION uncaught exception: %1</span></dt><dd><p>
There was an uncaught exception in the handling of a notify reply
message, either in the message parser, or while trying to extract data
from the parsed message. The error is printed, and notify_out will
treat the response as a bad message, but this does point to a
programming error, since all exceptions should have been caught
explicitly. Please file a bug report. Since there was a response,
no more notifies will be sent to this server for this notification
event.
</p></dd><dt><a name="NOTIFY_OUT_RETRY_EXCEEDED"></a><span class="term">NOTIFY_OUT_RETRY_EXCEEDED notify to %1#%2: number of retries (%3) exceeded</span></dt><dd><p>
The maximum number of retries for the notify target has been exceeded.
Either the address of the secondary nameserver is wrong, or it is not
responding.
</p></dd><dt><a name="NOTIFY_OUT_SENDING_NOTIFY"></a><span class="term">NOTIFY_OUT_SENDING_NOTIFY sending notify to %1#%2</span></dt><dd><p>
A notify message is sent to the secondary nameserver at the given
address.
</p></dd><dt><a name="NOTIFY_OUT_SOCKET_ERROR"></a><span class="term">NOTIFY_OUT_SOCKET_ERROR socket error sending notify to %1#%2: %3</span></dt><dd><p>
There was a network error while trying to send a notify message to
the given address. The address might be unreachable. The socket
error is printed and should provide more information.
</p></dd><dt><a name="NOTIFY_OUT_SOCKET_RECV_ERROR"></a><span class="term">NOTIFY_OUT_SOCKET_RECV_ERROR socket error reading notify reply from %1#%2: %3</span></dt><dd><p>
There was a network error while trying to read a notify reply
message from the given address. The socket error is printed and should
provide more information.
</p></dd><dt><a name="NOTIFY_OUT_TIMEOUT"></a><span class="term">NOTIFY_OUT_TIMEOUT retry notify to %1#%2</span></dt><dd><p>
The notify message to the given address (noted as address#port) has
timed out, and the message will be resent until the max retry limit
is reached.
</p></dd><dt><a name="NOTIFY_OUT_ZONE_BAD_SOA"></a><span class="term">NOTIFY_OUT_ZONE_BAD_SOA Zone %1 is invalid in terms of SOA</span></dt><dd><p>
This is a warning issued when the notify_out module finds a zone that
doesn't have an SOA RR or has multiple SOA RRs.  Notify message won't
be sent to such a zone.
</p></dd><dt><a name="NOTIFY_OUT_ZONE_NO_NS"></a><span class="term">NOTIFY_OUT_ZONE_NO_NS Zone %1 doesn't have NS RR</span></dt><dd><p>
This is a warning issued when the notify_out module finds a zone that
doesn't have an NS RR.  Notify message won't be sent to such a zone.
</p></dd><dt><a name="NSAS_EMPTY_RESPONSE"></a><span class="term">NSAS_EMPTY_RESPONSE response to query for %1 returned an empty answer section</span></dt><dd><p>
The NSAS (nameserver address store - part of the resolver) made a query
for information it needed.  The query completed successfully but the
answer section in the response was empty.
</p></dd><dt><a name="NSAS_ERROR_RESPONSE"></a><span class="term">NSAS_ERROR_RESPONSE error response of %1 returned in query for %2</span></dt><dd><p>
The NSAS (nameserver address store - part of the resolver) made a query
for information it needed.  The query completed successfully but the
RCODE in the response was something other than NOERROR.
</p></dd><dt><a name="NSAS_FIND_NS_ADDRESS"></a><span class="term">NSAS_FIND_NS_ADDRESS asking resolver to obtain A and AAAA records for %1</span></dt><dd><p>
A debug message issued when the NSAS (nameserver address store - part
of the resolver) is making a callback into the resolver to retrieve the
address records for the specified nameserver.
</p></dd><dt><a name="NSAS_FOUND_ADDRESS"></a><span class="term">NSAS_FOUND_ADDRESS found address %1 for %2</span></dt><dd><p>
A debug message issued when the NSAS (nameserver address store - part
of the resolver) has retrieved the given address for the specified
nameserver through an external query.
</p></dd><dt><a name="NSAS_LOOKUP_CANCEL"></a><span class="term">NSAS_LOOKUP_CANCEL lookup for zone %1 has been canceled</span></dt><dd><p>
A debug message issued when an NSAS (nameserver address store - part of
the resolver) lookup for a zone has been canceled.
</p></dd><dt><a name="NSAS_NS_LOOKUP_FAIL"></a><span class="term">NSAS_NS_LOOKUP_FAIL failed to lookup any %1 for %2</span></dt><dd><p>
A debug message issued when the NSAS (nameserver address store - part of
the resolver) has been unable to retrieve the specified resource record
for the specified nameserver.  This is not necessarily a problem - the
nameserver may be unreachable, in which case the NSAS will try other
nameservers in the zone.
</p></dd><dt><a name="NSAS_NULL_RESPONSE"></a><span class="term">NSAS_NULL_RESPONSE got null message in success callback for query for %1</span></dt><dd><p>
The NSAS (nameserver address store - part of the resolver) made a query
for information it needed.  The query completed successfully, but the
message passed to the callback was null.
</p><p>
This message indicates an internal error in the NSAS.  Please raise a
bug report.
</p></dd><dt><a name="NSAS_SEARCH_ZONE_NS"></a><span class="term">NSAS_SEARCH_ZONE_NS searching NSAS for nameservers for zone %1</span></dt><dd><p>
A debug message output when a call is made to the NSAS (nameserver
address store - part of the resolver) to obtain the nameservers for
the specified zone.
</p></dd><dt><a name="NSAS_UPDATE_RTT"></a><span class="term">NSAS_UPDATE_RTT update RTT for %1: was %2 ms, is now %3 ms</span></dt><dd><p>
A NSAS (nameserver address store - part of the resolver) debug message
reporting the update of a round-trip time (RTT) for a query made to the
specified nameserver.  The RTT has been updated using the value given
and the new RTT is displayed.  (The RTT is subject to a calculation that
damps out sudden changes.  As a result, the new RTT used by the NSAS in
future decisions of which nameserver to use is not necessarily equal to
the RTT reported.)
</p></dd><dt><a name="NSAS_WRONG_ANSWER"></a><span class="term">NSAS_WRONG_ANSWER queried for %1 RR of type/class %2/%3, received response %4/%5</span></dt><dd><p>
A NSAS (nameserver address store - part of the resolver) made a query for
a resource record of a particular type and class, but instead received
an answer with a different given type and class.
</p><p>
This message indicates an internal error in the NSAS.  Please raise a
bug report.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_DONE"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_DONE completed sending TCP message to %1 (%2 bytes in total)</span></dt><dd><p>
Debug message.  A complete DNS message has been successfully
transmitted over a TCP connection, possibly after multiple send
operations.  The destination address and the total size of the message
(including the 2-byte length field) are shown in the log message.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_ERROR"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_ERROR failed to send TCP message to %1 (%2/%3 bytes sent): %4</span></dt><dd><p>
A DNS message has been attempted to be sent out over a TCP connection,
but it failed due to some network error.  Although it's not expected
to happen too often, it can still happen for various reasons.  The
administrator may want to examine the cause of the failure, which is
included in the log message, to see if it requires some action to
be taken at the server side.  When this message is logged, the
corresponding  TCP connection was closed immediately after the error
was detected.
</p></dd><dt><a name="PYSERVER_COMMON_DNS_TCP_SEND_PENDING"></a><span class="term">PYSERVER_COMMON_DNS_TCP_SEND_PENDING sent part TCP message to %1 (up to %2/%3 bytes)</span></dt><dd><p>
Debug message.  A part of DNS message has been transmitted over a TCP
connection, and it's suspended because further attempt would block.
The destination address and the total size of the message that has
been transmitted so far (including the 2-byte length field) are shown
in the log message.
</p></dd><dt><a name="PYSERVER_COMMON_TSIG_KEYRING_DEINIT"></a><span class="term">PYSERVER_COMMON_TSIG_KEYRING_DEINIT Deinitializing global TSIG keyring</span></dt><dd><p>
A debug message noting that the global TSIG keyring is being removed from
memory. Most programs don't do that, they just exit, which is OK.
</p></dd><dt><a name="PYSERVER_COMMON_TSIG_KEYRING_INIT"></a><span class="term">PYSERVER_COMMON_TSIG_KEYRING_INIT Initializing global TSIG keyring</span></dt><dd><p>
A debug message noting the TSIG keyring storage is being prepared. It should
appear at most once in the lifetime of a program. The keyring still needs
to be loaded from configuration.
</p></dd><dt><a name="PYSERVER_COMMON_TSIG_KEYRING_UPDATE"></a><span class="term">PYSERVER_COMMON_TSIG_KEYRING_UPDATE Updating global TSIG keyring</span></dt><dd><p>
A debug message. The TSIG keyring is being (re)loaded from configuration.
This happens at startup or when the configuration changes. The old keyring
is removed and new one created with all the keys.
</p></dd><dt><a name="RESLIB_ANSWER"></a><span class="term">RESLIB_ANSWER answer received in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message reporting that an answer has been received to an upstream
query for the specified question.  Previous debug messages will have
indicated the server to which the question was sent.
</p></dd><dt><a name="RESLIB_CNAME"></a><span class="term">RESLIB_CNAME CNAME received in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message recording that CNAME response has been received to an
upstream query for the specified question.  Previous debug messages will
have indicated the server to which the question was sent.
</p></dd><dt><a name="RESLIB_DEEPEST"></a><span class="term">RESLIB_DEEPEST did not find &lt;%1&gt; in cache, deepest delegation found is %2</span></dt><dd><p>
A debug message, a cache lookup did not find the specified &lt;name,
class, type&gt; tuple in the cache; instead, the deepest delegation found
is indicated.
</p></dd><dt><a name="RESLIB_EMPTY_RESPONSE"></a><span class="term">RESLIB_EMPTY_RESPONSE empty response received to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver did not contain anything in the answer or authority sections,
although in all other respects it was a valid response.  A SERVFAIL will
be returned to the system making the original query.
</p></dd><dt><a name="RESLIB_ERROR_RESPONSE"></a><span class="term">RESLIB_ERROR_RESPONSE unspecified error received in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query to an upstream
nameserver indicated that the response was classified as an erroneous
response, but that the nature of the error cannot be identified.
A SERVFAIL will be returned to the system making the original query.
</p></dd><dt><a name="RESLIB_EXTRADATA_RESPONSE"></a><span class="term">RESLIB_EXTRADATA_RESPONSE extra data in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message indicating that the response to the specified query
from an upstream nameserver contained too much data.  This can happen if
an ANY query was sent and the answer section in the response contained
multiple RRs with different names.  A SERVFAIL will be returned to the
system making the original query.
</p></dd><dt><a name="RESLIB_FOLLOW_CNAME"></a><span class="term">RESLIB_FOLLOW_CNAME following CNAME chain to &lt;%1&gt;</span></dt><dd><p>
A debug message, a CNAME response was received and another query is
being issued for the &lt;name, class, type&gt; tuple.
</p></dd><dt><a name="RESLIB_INVALID_NAMECLASS_RESPONSE"></a><span class="term">RESLIB_INVALID_NAMECLASS_RESPONSE invalid name or class in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver (as identified by the ID of the response) contained either
an answer not matching the query name or an answer having a different
class to that queried for.  A SERVFAIL will be returned to the system
making the original query.
</p></dd><dt><a name="RESLIB_INVALID_QNAME_RESPONSE"></a><span class="term">RESLIB_INVALID_QNAME_RESPONSE invalid name or class in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver (as identified by the ID of the response) contained a name
in the question section that did not match that of the query. A SERVFAIL
will be returned to the system making the original query.
</p></dd><dt><a name="RESLIB_INVALID_TYPE_RESPONSE"></a><span class="term">RESLIB_INVALID_TYPE_RESPONSE invalid name or class in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver (as identified by the ID of the response) contained an
invalid type field. A SERVFAIL will be returned to the system making
the original query.
</p></dd><dt><a name="RESLIB_LONG_CHAIN"></a><span class="term">RESLIB_LONG_CHAIN CNAME received in response to query for &lt;%1&gt;: CNAME chain length exceeded</span></dt><dd><p>
A debug message recording that a CNAME response has been received to an upstream
query for the specified question (Previous debug messages will have indicated
the server to which the question was sent).  However, receipt of this CNAME
has meant that the resolver has exceeded the CNAME chain limit (a CNAME chain
is where on CNAME points to another) and so an error is being returned.
</p></dd><dt><a name="RESLIB_MULTIPLE_CLASS_RESPONSE"></a><span class="term">RESLIB_MULTIPLE_CLASS_RESPONSE response to query for &lt;%1&gt; contained multiple RRsets with different classes</span></dt><dd><p>
A debug message reporting that the response to an upstream query for
the specified name contained multiple RRsets in the answer and not all
were of the same class.  This is a violation of the standard and so a
SERVFAIL will be returned.
</p></dd><dt><a name="RESLIB_NOTSINGLE_RESPONSE"></a><span class="term">RESLIB_NOTSINGLE_RESPONSE response to query for &lt;%1&gt; was not a response</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver was a CNAME that had mutiple RRs in the RRset.  This is
an invalid response according to the standards so a SERVFAIL will be
returned to the system making the original query.
</p></dd><dt><a name="RESLIB_NOT_ONE_QNAME_RESPONSE"></a><span class="term">RESLIB_NOT_ONE_QNAME_RESPONSE not one question in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver (as identified by the ID of the response) did not contain
one name in the question section as required by the standard. A SERVFAIL
will be returned to the system making the original query.
</p></dd><dt><a name="RESLIB_NOT_RESPONSE"></a><span class="term">RESLIB_NOT_RESPONSE response to query for &lt;%1&gt; was not a response</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver (as identified by the ID of the response) did not have the QR
bit set (thus indicating that the packet was a query, not a response).
A SERVFAIL will be returned to the system making the original query.
</p></dd><dt><a name="RESLIB_NO_NS_RRSET"></a><span class="term">RESLIB_NO_NS_RRSET no NS RRSet in referral response received to query for &lt;%1&gt;</span></dt><dd><p>
A debug message, this indicates that a response was received for the specified
query and was categorized as a referral.  However, the received message did
not contain any NS RRsets.  This may indicate a programming error in the
response classification code.
</p></dd><dt><a name="RESLIB_NSAS_LOOKUP"></a><span class="term">RESLIB_NSAS_LOOKUP looking up nameserver for zone %1 in the NSAS</span></dt><dd><p>
A debug message, the RunningQuery object is querying the NSAS for the
nameservers for the specified zone.
</p></dd><dt><a name="RESLIB_NXDOM_NXRR"></a><span class="term">RESLIB_NXDOM_NXRR NXDOMAIN/NXRRSET received in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message recording that either a NXDOMAIN or an NXRRSET response has
been received to an upstream query for the specified question.  Previous debug
messages will have indicated the server to which the question was sent.
</p></dd><dt><a name="RESLIB_OPCODE_RESPONSE"></a><span class="term">RESLIB_OPCODE_RESPONSE response to query for &lt;%1&gt; did not have query opcode</span></dt><dd><p>
A debug message, the response to the specified query from an upstream
nameserver was a response that did not have the opcode set to that of
a query.  According to the standards, this is an invalid response to
the query that was made, so a SERVFAIL will be returned to the system
making the original query.
</p></dd><dt><a name="RESLIB_PROTOCOL"></a><span class="term">RESLIB_PROTOCOL protocol error in answer for %1:  %3</span></dt><dd><p>
A debug message indicating that a protocol error was received.  As there
are no retries left, an error will be reported.
</p></dd><dt><a name="RESLIB_PROTOCOL_RETRY"></a><span class="term">RESLIB_PROTOCOL_RETRY protocol error in answer for %1: %2 (retries left: %3)</span></dt><dd><p>
A debug message indicating that a protocol error was received and that
the resolver is repeating the query to the same nameserver.  After this
repeated query, there will be the indicated number of retries left.
</p></dd><dt><a name="RESLIB_RCODE_ERROR"></a><span class="term">RESLIB_RCODE_ERROR response to query for &lt;%1&gt; returns RCODE of %2</span></dt><dd><p>
A debug message, the response to the specified query indicated an error
that is not covered by a specific code path.  A SERVFAIL will be returned.
</p></dd><dt><a name="RESLIB_RECQ_CACHE_FIND"></a><span class="term">RESLIB_RECQ_CACHE_FIND found &lt;%1&gt; in the cache (resolve() instance %2)</span></dt><dd><p>
This is a debug message and indicates that a RecursiveQuery object found the
the specified &lt;name, class, type&gt; tuple in the cache.  The instance number
at the end of the message indicates which of the two resolve() methods has
been called.
</p></dd><dt><a name="RESLIB_RECQ_CACHE_NO_FIND"></a><span class="term">RESLIB_RECQ_CACHE_NO_FIND did not find &lt;%1&gt; in the cache, starting RunningQuery (resolve() instance %2)</span></dt><dd><p>
This is a debug message and indicates that the look in the cache made by the
RecursiveQuery::resolve() method did not find an answer, so a new RunningQuery
object has been created to resolve the question.  The instance number at
the end of the message indicates which of the two resolve() methods has
been called.
</p></dd><dt><a name="RESLIB_REFERRAL"></a><span class="term">RESLIB_REFERRAL referral received in response to query for &lt;%1&gt;</span></dt><dd><p>
A debug message recording that a referral response has been received to an
upstream query for the specified question.  Previous debug messages will
have indicated the server to which the question was sent.
</p></dd><dt><a name="RESLIB_REFER_ZONE"></a><span class="term">RESLIB_REFER_ZONE referred to zone %1</span></dt><dd><p>
A debug message indicating that the last referral message was to the specified
zone.
</p></dd><dt><a name="RESLIB_RESOLVE"></a><span class="term">RESLIB_RESOLVE asked to resolve &lt;%1&gt; (resolve() instance %2)</span></dt><dd><p>
A debug message, the RecursiveQuery::resolve method has been called to resolve
the specified &lt;name, class, type&gt; tuple.  The first action will be to lookup
the specified tuple in the cache.  The instance number at the end of the
message indicates which of the two resolve() methods has been called.
</p></dd><dt><a name="RESLIB_RRSET_FOUND"></a><span class="term">RESLIB_RRSET_FOUND found single RRset in the cache when querying for &lt;%1&gt; (resolve() instance %2)</span></dt><dd><p>
A debug message, indicating that when RecursiveQuery::resolve queried the
cache, a single RRset was found which was put in the answer.  The instance
number at the end of the message indicates which of the two resolve()
methods has been called.
</p></dd><dt><a name="RESLIB_RTT"></a><span class="term">RESLIB_RTT round-trip time of last query calculated as %1 ms</span></dt><dd><p>
A debug message giving the round-trip time of the last query and response.
</p></dd><dt><a name="RESLIB_RUNQ_CACHE_FIND"></a><span class="term">RESLIB_RUNQ_CACHE_FIND found &lt;%1&gt; in the cache</span></dt><dd><p>
This is a debug message and indicates that a RunningQuery object found
the specified &lt;name, class, type&gt; tuple in the cache.
</p></dd><dt><a name="RESLIB_RUNQ_CACHE_LOOKUP"></a><span class="term">RESLIB_RUNQ_CACHE_LOOKUP looking up up &lt;%1&gt; in the cache</span></dt><dd><p>
This is a debug message and indicates that a RunningQuery object has made
a call to its doLookup() method to look up the specified &lt;name, class, type&gt;
tuple, the first action of which will be to examine the cache.
</p></dd><dt><a name="RESLIB_RUNQ_FAIL"></a><span class="term">RESLIB_RUNQ_FAIL failure callback - nameservers are unreachable</span></dt><dd><p>
A debug message indicating that a RunningQuery's failure callback has been
called because all nameservers for the zone in question are unreachable.
</p></dd><dt><a name="RESLIB_RUNQ_SUCCESS"></a><span class="term">RESLIB_RUNQ_SUCCESS success callback - sending query to %1</span></dt><dd><p>
A debug message indicating that a RunningQuery's success callback has been
called because a nameserver has been found, and that a query is being sent
to the specified nameserver.
</p></dd><dt><a name="RESLIB_TCP_TRUNCATED"></a><span class="term">RESLIB_TCP_TRUNCATED TCP response to query for %1 was truncated</span></dt><dd><p>
This is a debug message logged when a response to the specified  query to an
upstream nameserver returned a response with the TC (truncation) bit set.  This
is treated as an error by the code.
</p></dd><dt><a name="RESLIB_TEST_SERVER"></a><span class="term">RESLIB_TEST_SERVER setting test server to %1(%2)</span></dt><dd><p>
This is a warning message only generated in unit tests.  It indicates
that all upstream queries from the resolver are being routed to the
specified server, regardless of the address of the nameserver to which
the query would normally be routed.  If seen during normal operation,
please submit a bug report.
</p></dd><dt><a name="RESLIB_TEST_UPSTREAM"></a><span class="term">RESLIB_TEST_UPSTREAM sending upstream query for &lt;%1&gt; to test server at %2</span></dt><dd><p>
This is a debug message and should only be seen in unit tests.  A query for
the specified &lt;name, class, type&gt; tuple is being sent to a test nameserver
whose address is given in the message.
</p></dd><dt><a name="RESLIB_TIMEOUT"></a><span class="term">RESLIB_TIMEOUT query &lt;%1&gt; to %2 timed out</span></dt><dd><p>
A debug message indicating that the specified upstream query has timed out and
there are no retries left.
</p></dd><dt><a name="RESLIB_TIMEOUT_RETRY"></a><span class="term">RESLIB_TIMEOUT_RETRY query &lt;%1&gt; to %2 timed out, re-trying (retries left: %3)</span></dt><dd><p>
A debug message indicating that the specified query has timed out and that
the resolver is repeating the query to the same nameserver.  After this
repeated query, there will be the indicated number of retries left.
</p></dd><dt><a name="RESLIB_TRUNCATED"></a><span class="term">RESLIB_TRUNCATED response to query for &lt;%1&gt; was truncated, re-querying over TCP</span></dt><dd><p>
A debug message, this indicates that the response to the specified query was
truncated and that the resolver will be re-querying over TCP.  There are
various reasons why responses may be truncated, so this message is normal and
gives no cause for concern.
</p></dd><dt><a name="RESLIB_UPSTREAM"></a><span class="term">RESLIB_UPSTREAM sending upstream query for &lt;%1&gt; to %2</span></dt><dd><p>
A debug message indicating that a query for the specified &lt;name, class, type&gt;
tuple is being sent to a nameserver whose address is given in the message.
</p></dd><dt><a name="RESOLVER_AXFR_TCP"></a><span class="term">RESOLVER_AXFR_TCP AXFR request received over TCP</span></dt><dd><p>
This is a debug message output when the resolver received a request for
an AXFR (full transfer of a zone) over TCP.  Only authoritative servers
are able to handle AXFR requests, so the resolver will return an error
message to the sender with the RCODE set to NOTIMP.
</p></dd><dt><a name="RESOLVER_AXFR_UDP"></a><span class="term">RESOLVER_AXFR_UDP AXFR request received over UDP</span></dt><dd><p>
This is a debug message output when the resolver received a request for
an AXFR (full transfer of a zone) over UDP.  Only authoritative servers
are able to handle AXFR requests (and in any case, an AXFR request should
be sent over TCP), so the resolver will return an error message to the
sender with the RCODE set to NOTIMP.
</p></dd><dt><a name="RESOLVER_CLIENT_TIME_SMALL"></a><span class="term">RESOLVER_CLIENT_TIME_SMALL client timeout of %1 is too small</span></dt><dd><p>
During the update of the resolver's configuration parameters, the value
of the client timeout was found to be too small.  The configuration
update was abandoned and the parameters were not changed.
</p></dd><dt><a name="RESOLVER_CONFIG_CHANNEL"></a><span class="term">RESOLVER_CONFIG_CHANNEL configuration channel created</span></dt><dd><p>
This is a debug message output when the resolver has successfully
established a connection to the configuration channel.
</p></dd><dt><a name="RESOLVER_CONFIG_ERROR"></a><span class="term">RESOLVER_CONFIG_ERROR error in configuration: %1</span></dt><dd><p>
An error was detected in a configuration update received by the
resolver. This may be in the format of the configuration message (in
which case this is a programming error) or it may be in the data supplied
(in which case it is a user error).  The reason for the error, included
in the message, will give more details.  The configuration update is
not applied and the resolver parameters were not changed.
</p></dd><dt><a name="RESOLVER_CONFIG_LOADED"></a><span class="term">RESOLVER_CONFIG_LOADED configuration loaded</span></dt><dd><p>
This is a debug message output when the resolver configuration has been
successfully loaded.
</p></dd><dt><a name="RESOLVER_CONFIG_UPDATED"></a><span class="term">RESOLVER_CONFIG_UPDATED configuration updated: %1</span></dt><dd><p>
This is a debug message output when the resolver configuration is being
updated with the specified information.
</p></dd><dt><a name="RESOLVER_CREATED"></a><span class="term">RESOLVER_CREATED main resolver object created</span></dt><dd><p>
This is a debug message indicating that the main resolver object has
been created.
</p></dd><dt><a name="RESOLVER_DNS_MESSAGE_RECEIVED"></a><span class="term">RESOLVER_DNS_MESSAGE_RECEIVED DNS message received: %1</span></dt><dd><p>
This is a debug message from the resolver listing the contents of a
received DNS message.
</p></dd><dt><a name="RESOLVER_DNS_MESSAGE_SENT"></a><span class="term">RESOLVER_DNS_MESSAGE_SENT DNS message of %1 bytes sent: %2</span></dt><dd><p>
This is a debug message containing details of the response returned by
the resolver to the querying system.
</p></dd><dt><a name="RESOLVER_FAILED"></a><span class="term">RESOLVER_FAILED resolver failed, reason: %1</span></dt><dd><p>
This is an error message output when an unhandled exception is caught
by the resolver.  After this, the resolver will shut itself down.
Please submit a bug report.
</p></dd><dt><a name="RESOLVER_FORWARD_ADDRESS"></a><span class="term">RESOLVER_FORWARD_ADDRESS setting forward address %1(%2)</span></dt><dd><p>
If the resolver is running in forward mode, this message will appear
during startup to list the forward address.  If multiple addresses are
specified, it will appear once for each address.
</p></dd><dt><a name="RESOLVER_FORWARD_QUERY"></a><span class="term">RESOLVER_FORWARD_QUERY processing forward query</span></dt><dd><p>
This is a debug message indicating that a query received by the resolver
has passed a set of checks (message is well-formed, it is allowed by the
ACL, it is a supported opcode, etc.) and is being forwarded to upstream
servers.
</p></dd><dt><a name="RESOLVER_HEADER_ERROR"></a><span class="term">RESOLVER_HEADER_ERROR message received, exception when processing header: %1</span></dt><dd><p>
This is a debug message from the resolver noting that an exception
occurred during the processing of a received packet.  The packet has
been dropped.
</p></dd><dt><a name="RESOLVER_IXFR"></a><span class="term">RESOLVER_IXFR IXFR request received</span></dt><dd><p>
This is a debug message indicating that the resolver received a request
for an IXFR (incremental transfer of a zone).  Only authoritative servers
are able to handle IXFR requests, so the resolver will return an error
message to the sender with the RCODE set to NOTIMP.
</p></dd><dt><a name="RESOLVER_LOOKUP_TIME_SMALL"></a><span class="term">RESOLVER_LOOKUP_TIME_SMALL lookup timeout of %1 is too small</span></dt><dd><p>
During the update of the resolver's configuration parameters, the value
of the lookup timeout was found to be too small.  The configuration
update will not be applied.
</p></dd><dt><a name="RESOLVER_MESSAGE_ERROR"></a><span class="term">RESOLVER_MESSAGE_ERROR error parsing received message: %1 - returning %2</span></dt><dd><p>
This is a debug message noting that parsing of the body of a received
message by the resolver failed due to some error (although the parsing of
the header succeeded).  The message parameters give a textual description
of the problem and the RCODE returned.
</p></dd><dt><a name="RESOLVER_NEGATIVE_RETRIES"></a><span class="term">RESOLVER_NEGATIVE_RETRIES negative number of retries (%1) specified in the configuration</span></dt><dd><p>
This error is issued when a resolver configuration update has specified
a negative retry count: only zero or positive values are valid.  The
configuration update was abandoned and the parameters were not changed.
</p></dd><dt><a name="RESOLVER_NON_IN_PACKET"></a><span class="term">RESOLVER_NON_IN_PACKET non-IN class request received, returning REFUSED message</span></dt><dd><p>
This debug message is issued when resolver has received a DNS packet that
was not IN (Internet) class.  The resolver cannot handle such packets,
so is returning a REFUSED response to the sender.
</p></dd><dt><a name="RESOLVER_NORMAL_QUERY"></a><span class="term">RESOLVER_NORMAL_QUERY processing normal query</span></dt><dd><p>
This is a debug message indicating that the query received by the resolver
has passed a set of checks (message is well-formed, it is allowed by the
ACL, it is a supported opcode, etc.) and is being processed by the resolver.
</p></dd><dt><a name="RESOLVER_NOTIFY_RECEIVED"></a><span class="term">RESOLVER_NOTIFY_RECEIVED NOTIFY arrived but server is not authoritative</span></dt><dd><p>
The resolver has received a NOTIFY message.  As the server is not
authoritative it cannot process it, so it returns an error message to
the sender with the RCODE set to NOTAUTH.
</p></dd><dt><a name="RESOLVER_NOT_ONE_QUESTION"></a><span class="term">RESOLVER_NOT_ONE_QUESTION query contained %1 questions, exactly one question was expected</span></dt><dd><p>
This debug message indicates that the resolver received a query that
contained the number of entries in the question section detailed in
the message.  This is a malformed message, as a DNS query must contain
only one question.  The resolver will return a message to the sender
with the RCODE set to FORMERR.
</p></dd><dt><a name="RESOLVER_NO_ROOT_ADDRESS"></a><span class="term">RESOLVER_NO_ROOT_ADDRESS no root addresses available</span></dt><dd><p>
A warning message issued during resolver startup, this indicates that
no root addresses have been set.  This may be because the resolver will
get them from a priming query.
</p></dd><dt><a name="RESOLVER_PARSE_ERROR"></a><span class="term">RESOLVER_PARSE_ERROR error parsing received message: %1 - returning %2</span></dt><dd><p>
This is a debug message noting that the resolver received a message and
the parsing of the body of the message failed due to some non-protocol
related reason (although the parsing of the header succeeded).
The message parameters give a textual description of the problem and
the RCODE returned.
</p></dd><dt><a name="RESOLVER_PRINT_COMMAND"></a><span class="term">RESOLVER_PRINT_COMMAND print message command, arguments are: %1</span></dt><dd><p>
This debug message is logged when a "print_message" command is received
by the resolver over the command channel.
</p></dd><dt><a name="RESOLVER_PROTOCOL_ERROR"></a><span class="term">RESOLVER_PROTOCOL_ERROR protocol error parsing received message: %1 - returning %2</span></dt><dd><p>
This is a debug message noting that the resolver received a message and
the parsing of the body of the message failed due to some protocol error
(although the parsing of the header succeeded).  The message parameters
give a textual description of the problem and the RCODE returned.
</p></dd><dt><a name="RESOLVER_QUERY_ACCEPTED"></a><span class="term">RESOLVER_QUERY_ACCEPTED query accepted: '%1/%2/%3' from %4</span></dt><dd><p>
This debug message is produced by the resolver when an incoming query
is accepted in terms of the query ACL.  The log message shows the query
in the form of &lt;query name&gt;/&lt;query type&gt;/&lt;query class&gt;, and the client
that sends the query in the form of &lt;Source IP address&gt;#&lt;source port&gt;.
</p></dd><dt><a name="RESOLVER_QUERY_DROPPED"></a><span class="term">RESOLVER_QUERY_DROPPED query dropped: '%1/%2/%3' from %4</span></dt><dd><p>
This is an informational message that indicates an incoming query has
been dropped by the resolver because of the query ACL.  Unlike the
RESOLVER_QUERY_REJECTED case, the server does not return any response.
The log message shows the query in the form of &lt;query name&gt;/&lt;query
type&gt;/&lt;query class&gt;, and the client that sends the query in the form of
&lt;Source IP address&gt;#&lt;source port&gt;.
</p></dd><dt><a name="RESOLVER_QUERY_REJECTED"></a><span class="term">RESOLVER_QUERY_REJECTED query rejected: '%1/%2/%3' from %4</span></dt><dd><p>
This is an informational message that indicates an incoming query has
been rejected by the resolver because of the query ACL.  This results
in a response with an RCODE of REFUSED. The log message shows the query
in the form of &lt;query name&gt;/&lt;query type&gt;/&lt;query class&gt;, and the client
that sends the query in the form of &lt;Source IP address&gt;#&lt;source port&gt;.
</p></dd><dt><a name="RESOLVER_QUERY_SETUP"></a><span class="term">RESOLVER_QUERY_SETUP query setup</span></dt><dd><p>
This is a debug message noting that the resolver is creating a
RecursiveQuery object.
</p></dd><dt><a name="RESOLVER_QUERY_SHUTDOWN"></a><span class="term">RESOLVER_QUERY_SHUTDOWN query shutdown</span></dt><dd><p>
This is a debug message noting that the resolver is destroying a
RecursiveQuery object.
</p></dd><dt><a name="RESOLVER_QUERY_TIME_SMALL"></a><span class="term">RESOLVER_QUERY_TIME_SMALL query timeout of %1 is too small</span></dt><dd><p>
During the update of the resolver's configuration parameters, the value
of the query timeout was found to be too small.  The configuration
parameters were not changed.
</p></dd><dt><a name="RESOLVER_RECEIVED_MESSAGE"></a><span class="term">RESOLVER_RECEIVED_MESSAGE resolver has received a DNS message</span></dt><dd><p>
This is a debug message indicating that the resolver has received a
DNS message.  Depending on the debug settings, subsequent log output
will indicate the nature of the message.
</p></dd><dt><a name="RESOLVER_RECURSIVE"></a><span class="term">RESOLVER_RECURSIVE running in recursive mode</span></dt><dd><p>
This is an informational message that appears at startup noting that
the resolver is running in recursive mode.
</p></dd><dt><a name="RESOLVER_SERVICE_CREATED"></a><span class="term">RESOLVER_SERVICE_CREATED service object created</span></dt><dd><p>
This debug message is output when resolver creates the main service object
(which handles the received queries).
</p></dd><dt><a name="RESOLVER_SET_PARAMS"></a><span class="term">RESOLVER_SET_PARAMS query timeout: %1, client timeout: %2, lookup timeout: %3, retry count: %4</span></dt><dd><p>
This debug message lists the parameters being set for the resolver.  These are:
query timeout: the timeout (in ms) used for queries originated by the resolver
to upstream servers.  Client timeout: the interval to resolve a query by
a client: after this time, the resolver sends back a SERVFAIL to the client
whilst continuing to resolve the query. Lookup timeout: the time at which the
resolver gives up trying to resolve a query.  Retry count: the number of times
the resolver will retry a query to an upstream server if it gets a timeout.
</p><p>
The client and lookup timeouts require a bit more explanation. The
resolution of the client query might require a large number of queries to
upstream nameservers.  Even if none of these queries timeout, the total time
taken to perform all the queries may exceed the client timeout.  When this
happens, a SERVFAIL is returned to the client, but the resolver continues
with the resolution process; data received is added to the cache.  However,
there comes a time - the lookup timeout - when even the resolver gives up.
At this point it will wait for pending upstream queries to complete or
timeout and drop the query.
</p></dd><dt><a name="RESOLVER_SET_QUERY_ACL"></a><span class="term">RESOLVER_SET_QUERY_ACL query ACL is configured</span></dt><dd><p>
This debug message is generated when a new query ACL is configured for
the resolver.
</p></dd><dt><a name="RESOLVER_SET_ROOT_ADDRESS"></a><span class="term">RESOLVER_SET_ROOT_ADDRESS setting root address %1(%2)</span></dt><dd><p>
This message gives the address of one of the root servers used by the
resolver.  It is output during startup and may appear multiple times,
once for each root server address.
</p></dd><dt><a name="RESOLVER_SHUTDOWN"></a><span class="term">RESOLVER_SHUTDOWN resolver shutdown complete</span></dt><dd><p>
This informational message is output when the resolver has shut down.
</p></dd><dt><a name="RESOLVER_SHUTDOWN_RECEIVED"></a><span class="term">RESOLVER_SHUTDOWN_RECEIVED received command to shut down</span></dt><dd><p>
A debug message noting that the server was asked to terminate and is
complying to the request.
</p></dd><dt><a name="RESOLVER_STARTED"></a><span class="term">RESOLVER_STARTED resolver started</span></dt><dd><p>
This informational message is output by the resolver when all initialization
has been completed and it is entering its main loop.
</p></dd><dt><a name="RESOLVER_STARTING"></a><span class="term">RESOLVER_STARTING starting resolver with command line '%1'</span></dt><dd><p>
An informational message, this is output when the resolver starts up.
</p></dd><dt><a name="RESOLVER_UNEXPECTED_RESPONSE"></a><span class="term">RESOLVER_UNEXPECTED_RESPONSE received unexpected response, ignoring</span></dt><dd><p>
This is a debug message noting that the resolver received a DNS response
packet on the port on which is it listening for queries.  The packet
has been ignored.
</p></dd><dt><a name="RESOLVER_UNSUPPORTED_OPCODE"></a><span class="term">RESOLVER_UNSUPPORTED_OPCODE opcode %1 not supported by the resolver</span></dt><dd><p>
This is debug message output when the resolver received a message with an
unsupported opcode (it can only process QUERY opcodes).  It will return
a message to the sender with the RCODE set to NOTIMP.
</p></dd><dt><a name="SOCKETREQUESTOR_CREATED"></a><span class="term">SOCKETREQUESTOR_CREATED Socket requestor created for application %1</span></dt><dd><p>
Debug message.  A socket requesor (client of the socket creator) is created
for the corresponding application.  Normally this should happen at most
one time throughout the lifetime of the application.
</p></dd><dt><a name="SOCKETREQUESTOR_DESTROYED"></a><span class="term">SOCKETREQUESTOR_DESTROYED Socket requestor destoryed</span></dt><dd><p>
Debug message.  The socket requestor created at SOCKETREQUESTOR_CREATED
has been destroyed.  This event is generally unexpected other than in
test cases.
</p></dd><dt><a name="SOCKETREQUESTOR_GETSOCKET"></a><span class="term">SOCKETREQUESTOR_GETSOCKET Received a %1 socket for [%2]:%3, FD=%4, token=%5, path=%6</span></dt><dd><p>
Debug message. The socket requestor for the corresponding application
has requested a socket for a set of address, port and protocol (shown
in the log message) and successfully got it from the creator.  The
corresponding file descriptor and the associated "token" (an internal
ID used between the creator and requestor) are shown in the log
message.
</p></dd><dt><a name="SOCKETREQUESTOR_RELEASESOCKET"></a><span class="term">SOCKETREQUESTOR_RELEASESOCKET Released a socket of token %1</span></dt><dd><p>
Debug message.  The socket requestor has released a socket passed by
the creator.  The associated token of the socket is shown in the
log message.  If the corresponding SOCKETREQUESTOR_GETSOCKET was logged
more detailed information of the socket can be identified by matching
the token.
</p></dd><dt><a name="SRVCOMM_ADDRESSES_NOT_LIST"></a><span class="term">SRVCOMM_ADDRESSES_NOT_LIST the address and port specification is not a list in %1</span></dt><dd><p>
This points to an error in configuration. What was supposed to be a list of
IP address - port pairs isn't a list at all but something else.
</p></dd><dt><a name="SRVCOMM_ADDRESS_FAIL"></a><span class="term">SRVCOMM_ADDRESS_FAIL failed to listen on addresses (%1)</span></dt><dd><p>
The server failed to bind to one of the address/port pair it should according
to configuration, for reason listed in the message (usually because that pair
is already used by other service or missing privileges). The server will try
to recover and bind the address/port pairs it was listening to before (if any).
</p></dd><dt><a name="SRVCOMM_ADDRESS_MISSING"></a><span class="term">SRVCOMM_ADDRESS_MISSING address specification is missing "address" or "port" element in %1</span></dt><dd><p>
This points to an error in configuration. An address specification in the
configuration is missing either an address or port and so cannot be used. The
specification causing the error is given in the message.
</p></dd><dt><a name="SRVCOMM_ADDRESS_TYPE"></a><span class="term">SRVCOMM_ADDRESS_TYPE address specification type is invalid in %1</span></dt><dd><p>
This points to an error in configuration. An address specification in the
configuration malformed. The specification causing the error is given in the
message. A valid specification contains an address part (which must be a string
and must represent a valid IPv4 or IPv6 address) and port (which must be an
integer in the range valid for TCP/UDP ports on your system).
</p></dd><dt><a name="SRVCOMM_ADDRESS_UNRECOVERABLE"></a><span class="term">SRVCOMM_ADDRESS_UNRECOVERABLE failed to recover original addresses also (%1)</span></dt><dd><p>
The recovery of old addresses after SRVCOMM_ADDRESS_FAIL also failed for
the reason listed.
</p><p>
The condition indicates problems with the server and/or the system on
which it is running.  The server will continue running to allow
reconfiguration, but will not be listening on any address or port until
an administrator does so.
</p></dd><dt><a name="SRVCOMM_ADDRESS_VALUE"></a><span class="term">SRVCOMM_ADDRESS_VALUE address to set: %1#%2</span></dt><dd><p>
Debug message. This lists one address and port value of the set of
addresses we are going to listen on (eg. there will be one log message
per pair). This appears only after SRVCOMM_SET_LISTEN, but might
be hidden, as it has higher debug level.
</p></dd><dt><a name="SRVCOMM_EXCEPTION_ALLOC"></a><span class="term">SRVCOMM_EXCEPTION_ALLOC exception when allocating a socket: %1</span></dt><dd><p>
The process tried to allocate a socket using the socket creator, but an error
occurred. But it is not one of the errors we are sure are "safe". In this case
it is unclear if the unsuccessful communication left the process and the bind10
process in inconsistent state, so the process is going to abort to prevent
further problems in that area.
</p><p>
This is probably a bug in the code, but it could be caused by other unusual
conditions (like insufficient memory, deleted socket file used for
communication).
</p></dd><dt><a name="SRVCOMM_KEYS_DEINIT"></a><span class="term">SRVCOMM_KEYS_DEINIT deinitializing TSIG keyring</span></dt><dd><p>
Debug message indicating that the server is deinitializing the TSIG keyring.
</p></dd><dt><a name="SRVCOMM_KEYS_INIT"></a><span class="term">SRVCOMM_KEYS_INIT initializing TSIG keyring</span></dt><dd><p>
Debug message indicating that the server is initializing the global TSIG
keyring. This should be seen only at server start.
</p></dd><dt><a name="SRVCOMM_KEYS_UPDATE"></a><span class="term">SRVCOMM_KEYS_UPDATE updating TSIG keyring</span></dt><dd><p>
Debug message indicating new keyring is being loaded from configuration (either
on startup or as a result of configuration update).
</p></dd><dt><a name="SRVCOMM_PORT_RANGE"></a><span class="term">SRVCOMM_PORT_RANGE port out of valid range (%1 in %2)</span></dt><dd><p>
This points to an error in configuration. The port in an address
specification is outside the valid range of 0 to 65535.
</p></dd><dt><a name="SRVCOMM_SET_LISTEN"></a><span class="term">SRVCOMM_SET_LISTEN setting addresses to listen to</span></dt><dd><p>
Debug message, noting that the server is about to start listening on a
different set of IP addresses and ports than before.
</p></dd><dt><a name="SRVCOMM_UNKNOWN_EXCEPTION_ALLOC"></a><span class="term">SRVCOMM_UNKNOWN_EXCEPTION_ALLOC unknown exception when allocating a socket</span></dt><dd><p>
The situation is the same as in the SRVCOMM_EXCEPTION_ALLOC case, but further
details about the error are unknown, because it was signaled by throwing
something not being an exception. This is definitely a bug.
</p></dd><dt><a name="STATHTTPD_BAD_OPTION_VALUE"></a><span class="term">STATHTTPD_BAD_OPTION_VALUE bad command line argument: %1</span></dt><dd><p>
The stats-httpd module was called with a bad command-line argument
and will not start.
</p></dd><dt><a name="STATHTTPD_CC_SESSION_ERROR"></a><span class="term">STATHTTPD_CC_SESSION_ERROR error connecting to message bus: %1</span></dt><dd><p>
The stats-httpd module was unable to connect to the BIND 10 command
and control bus. A likely problem is that the message bus daemon
(b10-msgq) is not running. The stats-httpd module will now shut down.
</p></dd><dt><a name="STATHTTPD_CLOSING"></a><span class="term">STATHTTPD_CLOSING closing %1#%2</span></dt><dd><p>
The stats-httpd daemon will stop listening for requests on the given
address and port number.
</p></dd><dt><a name="STATHTTPD_CLOSING_CC_SESSION"></a><span class="term">STATHTTPD_CLOSING_CC_SESSION stopping cc session</span></dt><dd><p>
Debug message indicating that the stats-httpd module is disconnecting
from the command and control bus.
</p></dd><dt><a name="STATHTTPD_HANDLE_CONFIG"></a><span class="term">STATHTTPD_HANDLE_CONFIG reading configuration: %1</span></dt><dd><p>
The stats-httpd daemon has received new configuration data and will now
process it. The (changed) data is printed.
</p></dd><dt><a name="STATHTTPD_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
A shutdown command was sent to the stats-httpd module, and it will
now shut down.
</p></dd><dt><a name="STATHTTPD_RECEIVED_STATUS_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_STATUS_COMMAND received command to return status</span></dt><dd><p>
A status command was sent to the stats-httpd module, and it will
respond with 'Stats Httpd is up.' and its PID.
</p></dd><dt><a name="STATHTTPD_RECEIVED_UNKNOWN_COMMAND"></a><span class="term">STATHTTPD_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</span></dt><dd><p>
An unknown command has been sent to the stats-httpd module. The
stats-httpd module will respond with an error, and the command will
be ignored.
</p></dd><dt><a name="STATHTTPD_SERVER_DATAERROR"></a><span class="term">STATHTTPD_SERVER_DATAERROR HTTP server data error: %1</span></dt><dd><p>
An internal error occurred while handling an HTTP request. An HTTP 404
response will be sent back, and the specific error is printed. This
is an error condition that likely points the specified data
corresponding to the requested URI is incorrect.
</p></dd><dt><a name="STATHTTPD_SERVER_ERROR"></a><span class="term">STATHTTPD_SERVER_ERROR HTTP server error: %1</span></dt><dd><p>
An internal error occurred while handling an HTTP request. An HTTP 500
response will be sent back, and the specific error is printed. This
is an error condition that likely points to a module that is not
responding correctly to statistic requests.
</p></dd><dt><a name="STATHTTPD_SERVER_INIT_ERROR"></a><span class="term">STATHTTPD_SERVER_INIT_ERROR HTTP server initialization error: %1</span></dt><dd><p>
There was a problem initializing the HTTP server in the stats-httpd
module upon receiving its configuration data. The most likely cause
is a port binding problem or a bad configuration value. The specific
error is printed in the message. The new configuration is ignored,
and an error is sent back.
</p></dd><dt><a name="STATHTTPD_SHUTDOWN"></a><span class="term">STATHTTPD_SHUTDOWN shutting down</span></dt><dd><p>
The stats-httpd daemon is shutting down.
</p></dd><dt><a name="STATHTTPD_STARTED"></a><span class="term">STATHTTPD_STARTED listening on %1#%2</span></dt><dd><p>
The stats-httpd daemon will now start listening for requests on the
given address and port number.
</p></dd><dt><a name="STATHTTPD_STARTING_CC_SESSION"></a><span class="term">STATHTTPD_STARTING_CC_SESSION starting cc session</span></dt><dd><p>
Debug message indicating that the stats-httpd module is connecting to
the command and control bus.
</p></dd><dt><a name="STATHTTPD_START_SERVER_INIT_ERROR"></a><span class="term">STATHTTPD_START_SERVER_INIT_ERROR HTTP server initialization error: %1</span></dt><dd><p>
There was a problem initializing the HTTP server in the stats-httpd
module upon startup. The most likely cause is that it was not able
to bind to the listening port. The specific error is printed, and the
module will shut down.
</p></dd><dt><a name="STATHTTPD_STOPPED_BY_KEYBOARD"></a><span class="term">STATHTTPD_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the stats-httpd
daemon. The daemon will now shut down.
</p></dd><dt><a name="STATHTTPD_UNKNOWN_CONFIG_ITEM"></a><span class="term">STATHTTPD_UNKNOWN_CONFIG_ITEM unknown configuration item: %1</span></dt><dd><p>
The stats-httpd daemon received a configuration update from the
configuration manager. However, one of the items in the
configuration is unknown. The new configuration is ignored, and an
error is sent back. As possible cause is that there was an upgrade
problem, and the stats-httpd version is out of sync with the rest of
the system.
</p></dd><dt><a name="STATS_BAD_OPTION_VALUE"></a><span class="term">STATS_BAD_OPTION_VALUE bad command line argument: %1</span></dt><dd><p>
The stats module was called with a bad command-line argument and will
not start.
</p></dd><dt><a name="STATS_CC_SESSION_ERROR"></a><span class="term">STATS_CC_SESSION_ERROR error connecting to message bus: %1</span></dt><dd><p>
The stats module was unable to connect to the BIND 10 command and
control bus. A likely problem is that the message bus daemon
(b10-msgq) is not running. The stats module will now shut down.
</p></dd><dt><a name="STATS_RECEIVED_NEW_CONFIG"></a><span class="term">STATS_RECEIVED_NEW_CONFIG received new configuration: %1</span></dt><dd><p>
This debug message is printed when the stats module has received a
configuration update from the configuration manager.
</p></dd><dt><a name="STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND"></a><span class="term">STATS_RECEIVED_SHOWSCHEMA_ALL_COMMAND received command to show all statistics schema</span></dt><dd><p>
The stats module received a command to show all statistics schemas of all modules.
</p></dd><dt><a name="STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND"></a><span class="term">STATS_RECEIVED_SHOWSCHEMA_NAME_COMMAND received command to show statistics schema for %1</span></dt><dd><p>
The stats module received a command to show the specified statistics schema of the specified module.
</p></dd><dt><a name="STATS_RECEIVED_SHOW_ALL_COMMAND"></a><span class="term">STATS_RECEIVED_SHOW_ALL_COMMAND received command to show all statistics</span></dt><dd><p>
The stats module received a command to show all statistics that it has
collected.
</p></dd><dt><a name="STATS_RECEIVED_SHOW_NAME_COMMAND"></a><span class="term">STATS_RECEIVED_SHOW_NAME_COMMAND received command to show statistics for %1</span></dt><dd><p>
The stats module received a command to show the statistics that it has
collected for the given item.
</p></dd><dt><a name="STATS_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">STATS_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
A shutdown command was sent to the stats module and it will now shut down.
</p></dd><dt><a name="STATS_RECEIVED_STATUS_COMMAND"></a><span class="term">STATS_RECEIVED_STATUS_COMMAND received command to return status</span></dt><dd><p>
A status command was sent to the stats module. It will return a
response indicating that it is running normally.
</p></dd><dt><a name="STATS_RECEIVED_UNKNOWN_COMMAND"></a><span class="term">STATS_RECEIVED_UNKNOWN_COMMAND received unknown command: %1</span></dt><dd><p>
An unknown command has been sent to the stats module. The stats module
will respond with an error and the command will be ignored.
</p></dd><dt><a name="STATS_SEND_REQUEST_BOSS"></a><span class="term">STATS_SEND_REQUEST_BOSS requesting boss to send statistics</span></dt><dd><p>
This debug message is printed when a request is sent to the boss module
to send its data to the stats module.
</p></dd><dt><a name="STATS_STARTING"></a><span class="term">STATS_STARTING starting</span></dt><dd><p>
The stats module will be now starting.
</p></dd><dt><a name="STATS_START_ERROR"></a><span class="term">STATS_START_ERROR stats module error: %1</span></dt><dd><p>
An internal error occurred while starting the stats module. The stats
module will be now shutting down.
</p></dd><dt><a name="STATS_STOPPED_BY_KEYBOARD"></a><span class="term">STATS_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the stats module. The
daemon will now shut down.
</p></dd><dt><a name="STATS_UNKNOWN_COMMAND_IN_SPEC"></a><span class="term">STATS_UNKNOWN_COMMAND_IN_SPEC unknown command in specification file: %1</span></dt><dd><p>
The specification file for the stats module contains a command that
is unknown in the implementation. The most likely cause is an
installation problem, where the specification file stats.spec is
from a different version of BIND 10 than the stats module itself.
Please check your installation.
</p></dd><dt><a name="XFRIN_AUTH_LOADZONE"></a><span class="term">XFRIN_AUTH_LOADZONE sending Auth loadzone for origin=%1, class=%2</span></dt><dd><p>
There was a successful zone transfer.  We send the "loadzone" command for the
zone to b10-auth.
</p></dd><dt><a name="XFRIN_AXFR_INCONSISTENT_SOA"></a><span class="term">XFRIN_AXFR_INCONSISTENT_SOA AXFR SOAs are inconsistent for %1: %2 expected, %3 received</span></dt><dd><p>
The serial fields of the first and last SOAs of AXFR (including AXFR-style
IXFR) are not the same.  According to RFC 5936 these two SOAs must be the
"same" (not only for the serial), but it is still not clear what the
receiver should do if this condition does not hold.  There was a discussion
about this at the IETF dnsext wg:
http://www.ietf.org/mail-archive/web/dnsext/current/msg07908.html
and the general feeling seems that it would be better to reject the
transfer if a mismatch is detected.  On the other hand, also as noted
in that email thread, neither BIND 9 nor NSD performs any comparison
on the SOAs.  For now, we only check the serials (ignoring other fields)
and only leave a warning log message when a mismatch is found.  If it
turns out to happen with a real world primary server implementation
and that server actually feeds broken data (e.g. mixed versions of
zone), we can consider a stricter action.
</p></dd><dt><a name="XFRIN_BAD_MASTER_ADDR_FORMAT"></a><span class="term">XFRIN_BAD_MASTER_ADDR_FORMAT bad format for master address: %1</span></dt><dd><p>
The given master address is not a valid IP address.
</p></dd><dt><a name="XFRIN_BAD_MASTER_PORT_FORMAT"></a><span class="term">XFRIN_BAD_MASTER_PORT_FORMAT bad format for master port: %1</span></dt><dd><p>
The master port as read from the configuration is not a valid port number.
</p></dd><dt><a name="XFRIN_BAD_TSIG_KEY_STRING"></a><span class="term">XFRIN_BAD_TSIG_KEY_STRING bad TSIG key string: %1</span></dt><dd><p>
The TSIG key string as read from the configuration does not represent
a valid TSIG key.
</p></dd><dt><a name="XFRIN_BAD_ZONE_CLASS"></a><span class="term">XFRIN_BAD_ZONE_CLASS Invalid zone class: %1</span></dt><dd><p>
The zone class as read from the configuration is not a valid DNS class.
</p></dd><dt><a name="XFRIN_CC_SESSION_ERROR"></a><span class="term">XFRIN_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
There was a problem reading from the command and control channel. The
most likely cause is that xfrin the msgq daemon is not running.
</p></dd><dt><a name="XFRIN_COMMAND_ERROR"></a><span class="term">XFRIN_COMMAND_ERROR error while executing command '%1': %2</span></dt><dd><p>
There was an error while the given command was being processed. The
error is given in the log message.
</p></dd><dt><a name="XFRIN_CONNECT_MASTER"></a><span class="term">XFRIN_CONNECT_MASTER error connecting to master at %1: %2</span></dt><dd><p>
There was an error opening a connection to the master. The error is
shown in the log message.
</p></dd><dt><a name="XFRIN_GOT_INCREMENTAL_RESP"></a><span class="term">XFRIN_GOT_INCREMENTAL_RESP got incremental response for %1</span></dt><dd><p>
In an attempt of IXFR processing, the begenning SOA of the first difference
(following the initial SOA that specified the final SOA for all the
differences) was found.  This means a connection for xfrin tried IXFR
and really aot a response for incremental updates.
</p></dd><dt><a name="XFRIN_GOT_NONINCREMENTAL_RESP"></a><span class="term">XFRIN_GOT_NONINCREMENTAL_RESP got nonincremental response for %1</span></dt><dd><p>
Non incremental transfer was detected at the "first data" of a transfer,
which is the RR following the initial SOA.  Non incremental transfer is
either AXFR or AXFR-style IXFR.  In the latter case, it means that
in a response to IXFR query the first data is not SOA or its SOA serial
is not equal to the requested SOA serial.
</p></dd><dt><a name="XFRIN_IMPORT_DNS"></a><span class="term">XFRIN_IMPORT_DNS error importing python DNS module: %1</span></dt><dd><p>
There was an error importing the python DNS module pydnspp. The most
likely cause is a PYTHONPATH problem.
</p></dd><dt><a name="XFRIN_IXFR_TRANSFER_SUCCESS"></a><span class="term">XFRIN_IXFR_TRANSFER_SUCCESS incremental IXFR transfer of zone %1 succeeded (messages: %2, changesets: %3, deletions: %4, additions: %5, bytes: %6, run time: %7 seconds, %8 bytes/second)</span></dt><dd><p>
The IXFR transfer for the given zone was successful.
The provided information contains the following values:
</p><p>
messages: Number of overhead DNS messages in the transfer.
</p><p>
changesets: Number of difference sequences.
</p><p>
deletions: Number of Resource Records deleted by all the changesets combined,
including the SOA records.
</p><p>
additions: Number of Resource Records added by all the changesets combined,
including the SOA records.
</p><p>
bytes: Full size of the transfer data on the wire.
</p><p>
run time: Time (in seconds) the complete ixfr took.
</p><p>
bytes/second: Transfer speed.
</p><p>
Note that there is no cross-checking of additions and deletions; if the same
RR gets added and deleted in multiple changesets, it is counted each time;
therefore, for each changeset, there should at least be 1 deletion and 1
addition (the updated SOA record).
</p></dd><dt><a name="XFRIN_IXFR_UPTODATE"></a><span class="term">XFRIN_IXFR_UPTODATE IXFR requested serial for %1 is %2, master has %3, not updating</span></dt><dd><p>
The first SOA record in an IXFR response indicates the zone's serial
at the primary server is not newer than the client's.  This is
basically unexpected event because normally the client first checks
the SOA serial by an SOA query, but can still happen if the transfer
is manually invoked or (although unlikely) there is a rapid change at
the primary server between the SOA and IXFR queries.  The client
implementation confirms the whole response is this single SOA, and
aborts the transfer just like a successful case.
</p></dd><dt><a name="XFRIN_MSGQ_SEND_ERROR"></a><span class="term">XFRIN_MSGQ_SEND_ERROR error while contacting %1 and %2</span></dt><dd><p>
There was a problem sending a message to the xfrout module or the
zone manager. This most likely means that the msgq daemon has quit or
was killed.
</p></dd><dt><a name="XFRIN_MSGQ_SEND_ERROR_AUTH"></a><span class="term">XFRIN_MSGQ_SEND_ERROR_AUTH error while contacting %1</span></dt><dd><p>
There was a problem sending a message to b10-auth. This most likely
means that the msgq daemon has quit or was killed.
</p></dd><dt><a name="XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER"></a><span class="term">XFRIN_MSGQ_SEND_ERROR_ZONE_MANAGER error while contacting %1</span></dt><dd><p>
There was a problem sending a message to the zone manager. This most
likely means that the msgq daemon has quit or was killed.
</p></dd><dt><a name="XFRIN_NOTIFY_UNKNOWN_MASTER"></a><span class="term">XFRIN_NOTIFY_UNKNOWN_MASTER got notification to retransfer zone %1 from %2, expected %3</span></dt><dd><p>
The system received a notify for the given zone, but the address it came
from does not match the master address in the Xfrin configuration. The notify
is ignored. This may indicate that the configuration for the master is wrong,
that a wrong machine is sending notifies, or that fake notifies are being sent.
</p></dd><dt><a name="XFRIN_RETRANSFER_UNKNOWN_ZONE"></a><span class="term">XFRIN_RETRANSFER_UNKNOWN_ZONE got notification to retransfer unknown zone %1</span></dt><dd><p>
There was an internal command to retransfer the given zone, but the
zone is not known to the system. This may indicate that the configuration
for xfrin is incomplete, or there was a typographical error in the
zone name in the configuration.
</p></dd><dt><a name="XFRIN_STARTED"></a><span class="term">XFRIN_STARTED xfrin started</span></dt><dd><p>
This informational message is output by xfrin when all initialization
has been completed and it is entering its main loop.
</p></dd><dt><a name="XFRIN_STOPPED_BY_KEYBOARD"></a><span class="term">XFRIN_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the xfrin daemon. The
daemon will now shut down.
</p></dd><dt><a name="XFRIN_TRANSFER_SUCCESS"></a><span class="term">XFRIN_TRANSFER_SUCCESS full %1 transfer of zone %2 succeeded (messages: %3, records: %4, bytes: %5, run time: %6 seconds, %7 bytes/second)</span></dt><dd><p>
The AXFR transfer of the given zone was successful.
The provided information contains the following values:
</p><p>
messages: Number of overhead DNS messages in the transfer
</p><p>
records: Number of Resource Records in the full transfer, excluding the
final SOA record that marks the end of the AXFR.
</p><p>
bytes: Full size of the transfer data on the wire.
</p><p>
run time: Time (in seconds) the complete axfr took
</p><p>
bytes/second: Transfer speed
</p></dd><dt><a name="XFRIN_UNKNOWN_ERROR"></a><span class="term">XFRIN_UNKNOWN_ERROR unknown error: %1</span></dt><dd><p>
An uncaught exception was raised while running the xfrin daemon. The
exception message is printed in the log message.
</p></dd><dt><a name="XFRIN_XFR_OTHER_FAILURE"></a><span class="term">XFRIN_XFR_OTHER_FAILURE %1 transfer of zone %2 failed: %3</span></dt><dd><p>
The XFR transfer for the given zone has failed due to a problem outside
of the xfrin module.  Possible reasons are a broken DNS message or failure
in database connection.  The error is shown in the log message.
</p></dd><dt><a name="XFRIN_XFR_PROCESS_FAILURE"></a><span class="term">XFRIN_XFR_PROCESS_FAILURE %1 transfer of zone %2/%3 failed: %4</span></dt><dd><p>
An XFR session failed outside the main protocol handling.  This
includes an error at the data source level at the initialization
phase, unexpected failure in the network connection setup to the
master server, or even more unexpected failure due to unlikely events
such as memory allocation failure.  Details of the error are shown in
the log message.  In general, these errors are not really expected
ones, and indicate an installation error or a program bug.  The
session handler thread tries to clean up all intermediate resources
even on these errors, but it may be incomplete.  So, if this log
message continuously appears, system resource consumption should be
checked, and you may even want to disable the corresponding transfers.
You may also want to file a bug report if this message appears so
often.
</p></dd><dt><a name="XFRIN_XFR_TRANSFER_FAILURE"></a><span class="term">XFRIN_XFR_TRANSFER_FAILURE %1 transfer of zone %2 with %3 failed: %4</span></dt><dd><p>
The XFR transfer for the given zone has failed due to an internal error.
The error is shown in the log message.
</p></dd><dt><a name="XFRIN_XFR_TRANSFER_FALLBACK"></a><span class="term">XFRIN_XFR_TRANSFER_FALLBACK falling back from IXFR to AXFR for %1</span></dt><dd><p>
The IXFR transfer of the given zone failed. This might happen in many cases,
such that the remote server doesn't support IXFR, we don't have the SOA record
(or the zone at all), we are out of sync, etc. In many of these situations,
AXFR could still work. Therefore we try that one in case it helps.
</p></dd><dt><a name="XFRIN_XFR_TRANSFER_PROTOCOL_ERROR"></a><span class="term">XFRIN_XFR_TRANSFER_PROTOCOL_ERROR %1 transfer of zone %2 with %3 failed: %4</span></dt><dd><p>
The XFR transfer for the given zone has failed due to a protocol
error, such as an unexpected response from the primary server.  The
error is shown in the log message.  It may be because the primary
server implementation is broken or (although less likely) there was
some attack attempt, but it can also happen due to configuration
mismatch such as the remote server does not have authority for the
zone any more but the local configuration hasn't been updated.  So it
is recommended to check the primary server configuration.
</p></dd><dt><a name="XFRIN_XFR_TRANSFER_STARTED"></a><span class="term">XFRIN_XFR_TRANSFER_STARTED %1 transfer of zone %2 started</span></dt><dd><p>
A connection to the master server has been made, the serial value in
the SOA record has been checked, and a zone transfer has been started.
</p></dd><dt><a name="XFRIN_ZONE_CREATED"></a><span class="term">XFRIN_ZONE_CREATED Zone %1 not found in the given data source, newly created</span></dt><dd><p>
On starting an xfrin session, it is identified that the zone to be
transferred is not found in the data source.  This can happen if a
secondary DNS server first tries to perform AXFR from a primary server
without creating the zone image beforehand (e.g. by b10-loadzone).  As
of this writing the xfrin process provides backward compatible
behavior to previous versions: creating a new one in the data source
not to surprise existing users too much.  This is probably not a good
idea, however, in terms of who should be responsible for managing
zones at a higher level.  In future it is more likely that a separate
zone management framework is provided, and the situation where the
given zone isn't found in xfrout will be treated as an error.
</p></dd><dt><a name="XFRIN_ZONE_MULTIPLE_SOA"></a><span class="term">XFRIN_ZONE_MULTIPLE_SOA Zone %1 has %2 SOA RRs</span></dt><dd><p>
On starting an xfrin session, it is identified that the zone to be
transferred has multiple SOA RRs.  Such a zone is broken, but could be
accidentally configured especially in a data source using "non
captive" backend database.  The implementation ignores entire SOA RRs
and tries to continue processing as if the zone were empty.  This
means subsequent AXFR can succeed and possibly replace the zone with
valid content, but an IXFR attempt will fail.
</p></dd><dt><a name="XFRIN_ZONE_NO_SOA"></a><span class="term">XFRIN_ZONE_NO_SOA Zone %1 does not have SOA</span></dt><dd><p>
On starting an xfrin session, it is identified that the zone to be
transferred does not have an SOA RR in the data source.  This is not
necessarily an error; if a secondary DNS server first tries to perform
transfer from a primary server, the zone can be empty, and therefore
doesn't have an SOA.  Subsequent AXFR will fill in the zone; if the
attempt is IXFR it will fail in query creation.
</p></dd><dt><a name="XFRIN_ZONE_SERIAL_AHEAD"></a><span class="term">XFRIN_ZONE_SERIAL_AHEAD Serial number (%1) for %2 received from master %3 &lt; ours (%4)</span></dt><dd><p>
The response to an SOA query prior to xfr indicated that the zone's
SOA serial at the primary server is smaller than that of the xfrin
client.  This is not necessarily an error especially if that
particular primary server is another secondary server which hasn't got
the latest version of the zone.  But if the primary server is known to
be the real source of the zone, some unexpected inconsistency may have
happened, and you may want to take a closer look.  In this case xfrin
doesn't perform subsequent zone transfer.
</p></dd><dt><a name="XFROUT_BAD_TSIG_KEY_STRING"></a><span class="term">XFROUT_BAD_TSIG_KEY_STRING bad TSIG key string: %1</span></dt><dd><p>
The TSIG key string as read from the configuration does not represent
a valid TSIG key.
</p></dd><dt><a name="XFROUT_CC_SESSION_ERROR"></a><span class="term">XFROUT_CC_SESSION_ERROR error reading from cc channel: %1</span></dt><dd><p>
There was a problem reading from the command and control channel. The
most likely cause is that the msgq daemon is not running.
</p></dd><dt><a name="XFROUT_CC_SESSION_TIMEOUT_ERROR"></a><span class="term">XFROUT_CC_SESSION_TIMEOUT_ERROR timeout waiting for cc response</span></dt><dd><p>
There was a problem reading a response from another module over the
command and control channel. The most likely cause is that the
configuration manager b10-cfgmgr is not running.
</p></dd><dt><a name="XFROUT_CONFIG_ERROR"></a><span class="term">XFROUT_CONFIG_ERROR error found in configuration data: %1</span></dt><dd><p>
The xfrout process encountered an error when installing the configuration at
startup time.  Details of the error are included in the log message.
</p></dd><dt><a name="XFROUT_FETCH_REQUEST_ERROR"></a><span class="term">XFROUT_FETCH_REQUEST_ERROR socket error while fetching a request from the auth daemon</span></dt><dd><p>
There was a socket error while contacting the b10-auth daemon to
fetch a transfer request. The auth daemon may have shutdown.
</p></dd><dt><a name="XFROUT_HANDLE_QUERY_ERROR"></a><span class="term">XFROUT_HANDLE_QUERY_ERROR error while handling query: %1</span></dt><dd><p>
There was a general error handling an xfrout query. The error is shown
in the message. In principle this error should not appear, and points
to an oversight catching exceptions in the right place. However, to
ensure the daemon keeps running, this error is caught and reported.
</p></dd><dt><a name="XFROUT_IMPORT"></a><span class="term">XFROUT_IMPORT error importing python module: %1</span></dt><dd><p>
There was an error importing a python module. One of the modules needed
by xfrout could not be found. This suggests that either some libraries
are missing on the system, or the PYTHONPATH variable is not correct.
The specific place where this library needs to be depends on your
system and your specific installation.
</p></dd><dt><a name="XFROUT_IXFR_MULTIPLE_SOA"></a><span class="term">XFROUT_IXFR_MULTIPLE_SOA IXFR client %1: authority section has multiple SOAs</span></dt><dd><p>
An IXFR request was received with more than one SOA RRs in the authority
section.  The xfrout daemon rejects the request with an RCODE of
FORMERR.
</p></dd><dt><a name="XFROUT_IXFR_NO_JOURNAL_SUPPORT"></a><span class="term">XFROUT_IXFR_NO_JOURNAL_SUPPORT IXFR client %1, %2: journaling not supported in the data source, falling back to AXFR</span></dt><dd><p>
An IXFR request was received but the underlying data source did
not support journaling.  The xfrout daemon fell back to AXFR-style
IXFR.
</p></dd><dt><a name="XFROUT_IXFR_NO_SOA"></a><span class="term">XFROUT_IXFR_NO_SOA IXFR client %1: missing SOA</span></dt><dd><p>
An IXFR request was received with no SOA RR in the authority section.
The xfrout daemon rejects the request with an RCODE of FORMERR.
</p></dd><dt><a name="XFROUT_IXFR_NO_VERSION"></a><span class="term">XFROUT_IXFR_NO_VERSION IXFR client %1, %2: version (%3 to %4) not in journal, falling back to AXFR</span></dt><dd><p>
An IXFR request was received, but the requested range of differences
were not found in the data source.  The xfrout daemon fell back to
AXFR-style IXFR.
</p></dd><dt><a name="XFROUT_IXFR_NO_ZONE"></a><span class="term">XFROUT_IXFR_NO_ZONE IXFR client %1, %2: zone not found with journal</span></dt><dd><p>
The requested zone in IXFR was not found in the data source
even though the xfrout daemon sucessfully found the SOA RR of the zone
in the data source.  This can happen if the administrator removed the
zone from the data source within the small duration between these
operations, but it's more likely to be a bug or broken data source.
Unless you know why this message was logged, and especially if it
happens often, it's advisable to check whether the data source is
valid for this zone.  The xfrout daemon considers it a possible,
though unlikely, event, and returns a response with an RCODE of
NOTAUTH.
</p></dd><dt><a name="XFROUT_IXFR_UPTODATE"></a><span class="term">XFROUT_IXFR_UPTODATE IXFR client %1, %2: client version is new enough (theirs=%3, ours=%4)</span></dt><dd><p>
An IXFR request was received, but the client's SOA version is the same as
or newer than that of the server.  The xfrout server responds to the
request with the answer section being just one SOA of that version.
Note: as of this wrting the 'newer version' cannot be identified due to
the lack of support for the serial number arithmetic.  This will soon
be implemented.
</p></dd><dt><a name="XFROUT_MODULECC_SESSION_ERROR"></a><span class="term">XFROUT_MODULECC_SESSION_ERROR error encountered by configuration/command module: %1</span></dt><dd><p>
There was a problem in the lower level module handling configuration and
control commands.  This could happen for various reasons, but the most likely
cause is that the configuration database contains a syntax error and xfrout
failed to start at initialization.  A detailed error message from the module
will also be displayed.
</p></dd><dt><a name="XFROUT_NEW_CONFIG"></a><span class="term">XFROUT_NEW_CONFIG Update xfrout configuration</span></dt><dd><p>
New configuration settings have been sent from the configuration
manager. The xfrout daemon will now apply them.
</p></dd><dt><a name="XFROUT_NEW_CONFIG_DONE"></a><span class="term">XFROUT_NEW_CONFIG_DONE Update xfrout configuration done</span></dt><dd><p>
The xfrout daemon is now done reading the new configuration settings
received from the configuration manager.
</p></dd><dt><a name="XFROUT_NOTIFY_COMMAND"></a><span class="term">XFROUT_NOTIFY_COMMAND received command to send notifies for %1/%2</span></dt><dd><p>
The xfrout daemon received a command on the command channel that
NOTIFY packets should be sent for the given zone.
</p></dd><dt><a name="XFROUT_PARSE_QUERY_ERROR"></a><span class="term">XFROUT_PARSE_QUERY_ERROR error parsing query: %1</span></dt><dd><p>
There was a parse error while reading an incoming query. The parse
error is shown in the log message. A remote client sent a packet we
do not understand or support. The xfrout request will be ignored.
In general, this should only occur for unexpected problems like
memory allocation failures, as the query should already have been
parsed by the b10-auth daemon, before it was passed here.
</p></dd><dt><a name="XFROUT_PROCESS_REQUEST_ERROR"></a><span class="term">XFROUT_PROCESS_REQUEST_ERROR error processing transfer request: %1</span></dt><dd><p>
There was an error in receiving a transfer request from b10-auth.
This is generally an unexpected event, but is possible when, for
example, b10-auth terminates in the middle of forwarding the request.
When this happens it's unlikely to be recoverable with the same
communication session with b10-auth, so b10-xfrout drops it and
waits for a new session.  In any case, this error indicates that
there's something very wrong in the system, so it's advisable to check
the over all status of the BIND 10 system.
</p></dd><dt><a name="XFROUT_QUERY_DROPPED"></a><span class="term">XFROUT_QUERY_DROPPED %1 client %2: request to transfer %3 dropped</span></dt><dd><p>
The xfrout process silently dropped a request to transfer zone to
given host.  This is required by the ACLs.  The %2 represents the IP
address and port of the peer requesting the transfer, and the %3
represents the zone name and class.
</p></dd><dt><a name="XFROUT_QUERY_QUOTA_EXCCEEDED"></a><span class="term">XFROUT_QUERY_QUOTA_EXCCEEDED %1 client %2: request denied due to quota (%3)</span></dt><dd><p>
The xfr request was rejected because the server was already handling
the maximum number of allowable transfers as specified in the transfers_out
configuration parameter, which is also shown in the log message.  The
request was immediately responded and terminated with an RCODE of REFUSED.
This can happen for a busy xfrout server, and you may want to increase
this parameter; if the server is being too busy due to requests from
unexpected clients you may want to restrict the legitimate clients
with ACL.
</p></dd><dt><a name="XFROUT_QUERY_REJECTED"></a><span class="term">XFROUT_QUERY_REJECTED %1 client %2: request to transfer %3 rejected</span></dt><dd><p>
The xfrout process rejected (by REFUSED rcode) a request to transfer zone to
given host. This is because of ACLs.  The %2 represents the IP
address and port of the peer requesting the transfer, and the %3
represents the zone name and class.
</p></dd><dt><a name="XFROUT_RECEIVED_SHUTDOWN_COMMAND"></a><span class="term">XFROUT_RECEIVED_SHUTDOWN_COMMAND shutdown command received</span></dt><dd><p>
The xfrout daemon received a shutdown command from the command channel
and will now shut down.
</p></dd><dt><a name="XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR"></a><span class="term">XFROUT_RECEIVE_FILE_DESCRIPTOR_ERROR error receiving the file descriptor for an XFR connection</span></dt><dd><p>
There was an error receiving the file descriptor for the transfer
request from b10-auth.  There can be several reasons for this, but
the most likely cause is that b10-auth terminates for some reason
(maybe it's a bug of b10-auth, maybe it's an intentional restart by
the administrator), so depending on how this happens it may or may not
be a serious error.  But in any case this is not expected to happen
frequently, and it's advisable to figure out how this happened if
this message is logged.  Even if this error happens xfrout will reset
its internal state and will keep receiving further requests.  So
if it's just a temporary restart of b10-auth the administrator does
not have to do anything.
</p></dd><dt><a name="XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR"></a><span class="term">XFROUT_REMOVE_OLD_UNIX_SOCKET_FILE_ERROR error removing unix socket file %1: %2</span></dt><dd><p>
The unix socket file xfrout needs for contact with the auth daemon
already exists, and needs to be removed first, but there is a problem
removing it. It is likely that we do not have permission to remove
this file. The specific error is show in the log message. The xfrout
daemon will shut down.
</p></dd><dt><a name="XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR"></a><span class="term">XFROUT_REMOVE_UNIX_SOCKET_FILE_ERROR error clearing unix socket file %1: %2</span></dt><dd><p>
When shutting down, the xfrout daemon tried to clear the unix socket
file used for communication with the auth daemon. It failed to remove
the file. The reason for the failure is given in the error message.
</p></dd><dt><a name="XFROUT_SOCKET_SELECT_ERROR"></a><span class="term">XFROUT_SOCKET_SELECT_ERROR error while calling select() on request socket: %1</span></dt><dd><p>
There was an error while calling select() on the socket that informs
the xfrout daemon that a new xfrout request has arrived. This should
be a result of rare local error such as memory allocation failure and
shouldn't happen under normal conditions. The error is included in the
log message.
</p></dd><dt><a name="XFROUT_STARTED"></a><span class="term">XFROUT_STARTED xfrout started</span></dt><dd><p>
This informational message is output by xfrout when all initialization
has been completed and it is entering its main loop.
</p></dd><dt><a name="XFROUT_STOPPED_BY_KEYBOARD"></a><span class="term">XFROUT_STOPPED_BY_KEYBOARD keyboard interrupt, shutting down</span></dt><dd><p>
There was a keyboard interrupt signal to stop the xfrout daemon. The
daemon will now shut down.
</p></dd><dt><a name="XFROUT_STOPPING"></a><span class="term">XFROUT_STOPPING the xfrout daemon is shutting down</span></dt><dd><p>
The current transfer is aborted, as the xfrout daemon is shutting down.
</p></dd><dt><a name="XFROUT_UNIX_SOCKET_FILE_IN_USE"></a><span class="term">XFROUT_UNIX_SOCKET_FILE_IN_USE another xfrout process seems to be using the unix socket file %1</span></dt><dd><p>
While starting up, the xfrout daemon tried to clear the unix domain
socket needed for contacting the b10-auth daemon to pass requests
on, but the file is in use. The most likely cause is that another
xfrout daemon process is still running. This xfrout daemon (the one
printing this message) will not start.
</p></dd><dt><a name="XFROUT_XFR_TRANSFER_CHECK_ERROR"></a><span class="term">XFROUT_XFR_TRANSFER_CHECK_ERROR %1 client %2: check for transfer of %3 failed: %4</span></dt><dd><p>
Pre-response check for an incomding XFR request failed unexpectedly.
The most likely cause of this is that some low level error in the data
source, but it may also be other general (more unlikely) errors such
as memory shortage.  Some detail of the error is also included in the
message.  The xfrout server tries to return a SERVFAIL response in this case.
</p></dd><dt><a name="XFROUT_XFR_TRANSFER_DONE"></a><span class="term">XFROUT_XFR_TRANSFER_DONE %1 client %2: transfer of %3 complete</span></dt><dd><p>
The transfer of the given zone has been completed successfully, or was
aborted due to a shutdown event.
</p></dd><dt><a name="XFROUT_XFR_TRANSFER_ERROR"></a><span class="term">XFROUT_XFR_TRANSFER_ERROR %1 client %2: error transferring zone %3: %4</span></dt><dd><p>
An uncaught exception was encountered while sending the response to
an AXFR query. The error message of the exception is included in the
log message, but this error most likely points to incomplete exception
handling in the code.
</p></dd><dt><a name="XFROUT_XFR_TRANSFER_FAILED"></a><span class="term">XFROUT_XFR_TRANSFER_FAILED %1 client %2: transfer of %3 failed, rcode: %4</span></dt><dd><p>
A transfer out for the given zone failed. An error response is sent
to the client. The given rcode is the rcode that is set in the error
response. This is either NOTAUTH (we are not authoritative for the
zone), SERVFAIL (our internal database is missing the SOA record for
the zone), or REFUSED (the limit of simultaneous outgoing AXFR
transfers, as specified by the configuration value
Xfrout/max_transfers_out, has been reached).
</p></dd><dt><a name="XFROUT_XFR_TRANSFER_STARTED"></a><span class="term">XFROUT_XFR_TRANSFER_STARTED %1 client %2: transfer of zone %3 has started</span></dt><dd><p>
A transfer out of the given zone has started.
</p></dd><dt><a name="ZONEMGR_CCSESSION_ERROR"></a><span class="term">ZONEMGR_CCSESSION_ERROR command channel session error: %1</span></dt><dd><p>
An error was encountered on the command channel.  The message indicates
the nature of the error.
</p></dd><dt><a name="ZONEMGR_JITTER_TOO_BIG"></a><span class="term">ZONEMGR_JITTER_TOO_BIG refresh_jitter is too big, setting to 0.5</span></dt><dd><p>
The value specified in the configuration for the refresh jitter is too large
so its value has been set to the maximum of 0.5.
</p></dd><dt><a name="ZONEMGR_KEYBOARD_INTERRUPT"></a><span class="term">ZONEMGR_KEYBOARD_INTERRUPT exiting zonemgr process as result of keyboard interrupt</span></dt><dd><p>
An informational message output when the zone manager was being run at a
terminal and it was terminated via a keyboard interrupt signal.
</p></dd><dt><a name="ZONEMGR_LOAD_ZONE"></a><span class="term">ZONEMGR_LOAD_ZONE loading zone %1 (class %2)</span></dt><dd><p>
This is a debug message indicating that the zone of the specified class
is being loaded.
</p></dd><dt><a name="ZONEMGR_NO_MASTER_ADDRESS"></a><span class="term">ZONEMGR_NO_MASTER_ADDRESS internal BIND 10 command did not contain address of master</span></dt><dd><p>
A command received by the zone manager from the Auth module did not
contain the address of the master server from which a NOTIFY message
was received.  This may be due to an internal programming error; please
submit a bug report.
</p></dd><dt><a name="ZONEMGR_NO_SOA"></a><span class="term">ZONEMGR_NO_SOA zone %1 (class %2) does not have an SOA record</span></dt><dd><p>
When loading the named zone of the specified class the zone manager
discovered that the data did not contain an SOA record.  The load has
been abandoned.
</p></dd><dt><a name="ZONEMGR_NO_TIMER_THREAD"></a><span class="term">ZONEMGR_NO_TIMER_THREAD trying to stop zone timer thread but it is not running</span></dt><dd><p>
An attempt was made to stop the timer thread (used to track when zones
should be refreshed) but it was not running.  This may indicate an
internal program error.  Please submit a bug report.
</p></dd><dt><a name="ZONEMGR_NO_ZONE_CLASS"></a><span class="term">ZONEMGR_NO_ZONE_CLASS internal BIND 10 command did not contain class of zone</span></dt><dd><p>
A command received by the zone manager from another BIND 10 module did
not contain the class of the zone on which the zone manager should act.
This may be due to an internal programming error; please submit a
bug report.
</p></dd><dt><a name="ZONEMGR_NO_ZONE_NAME"></a><span class="term">ZONEMGR_NO_ZONE_NAME internal BIND 10 command did not contain name of zone</span></dt><dd><p>
A command received by the zone manager from another BIND 10 module did
not contain the name of the zone on which the zone manager should act.
This may be due to an internal programming error; please submit a
bug report.
</p></dd><dt><a name="ZONEMGR_RECEIVE_NOTIFY"></a><span class="term">ZONEMGR_RECEIVE_NOTIFY received NOTIFY command for zone %1 (class %2)</span></dt><dd><p>
This is a debug message indicating that the zone manager has received a
NOTIFY command over the command channel.  The command is sent by the Auth
process when it is acting as a slave server for the zone and causes the
zone manager to record the master server for the zone and start a timer;
when the timer expires, the master will be polled to see if it contains
new data.
</p></dd><dt><a name="ZONEMGR_RECEIVE_SHUTDOWN"></a><span class="term">ZONEMGR_RECEIVE_SHUTDOWN received SHUTDOWN command</span></dt><dd><p>
This is a debug message indicating that the zone manager has received
a SHUTDOWN command over the command channel from the Boss process.
It will act on this command and shut down.
</p></dd><dt><a name="ZONEMGR_RECEIVE_UNKNOWN"></a><span class="term">ZONEMGR_RECEIVE_UNKNOWN received unknown command '%1'</span></dt><dd><p>
This is a warning message indicating that the zone manager has received
the stated command over the command channel.  The command is not known
to the zone manager and although the command is ignored, its receipt
may indicate an internal error.  Please submit a bug report.
</p></dd><dt><a name="ZONEMGR_RECEIVE_XFRIN_FAILED"></a><span class="term">ZONEMGR_RECEIVE_XFRIN_FAILED received XFRIN FAILED command for zone %1 (class %2)</span></dt><dd><p>
This is a debug message indicating that the zone manager has received
an XFRIN FAILED command over the command channel.  The command is sent
by the Xfrin process when a transfer of zone data into the system has
failed, and causes the zone manager to schedule another transfer attempt.
</p></dd><dt><a name="ZONEMGR_RECEIVE_XFRIN_SUCCESS"></a><span class="term">ZONEMGR_RECEIVE_XFRIN_SUCCESS received XFRIN SUCCESS command for zone %1 (class %2)</span></dt><dd><p>
This is a debug message indicating that the zone manager has received
an XFRIN SUCCESS command over the command channel.  The command is sent
by the Xfrin process when the transfer of zone data into the system has
succeeded, and causes the data to be loaded and served by BIND 10.
</p></dd><dt><a name="ZONEMGR_REFRESH_ZONE"></a><span class="term">ZONEMGR_REFRESH_ZONE refreshing zone %1 (class %2)</span></dt><dd><p>
The zone manager is refreshing the named zone of the specified class
with updated information.
</p></dd><dt><a name="ZONEMGR_SELECT_ERROR"></a><span class="term">ZONEMGR_SELECT_ERROR error with select(): %1</span></dt><dd><p>
An attempt to wait for input from a socket failed.  The failing operation
is a call to the operating system's select() function, which failed for
the given reason.
</p></dd><dt><a name="ZONEMGR_SEND_FAIL"></a><span class="term">ZONEMGR_SEND_FAIL failed to send command to %1, session has been closed</span></dt><dd><p>
The zone manager attempted to send a command to the named BIND 10 module,
but the send failed.  The session between the modules has been closed.
</p></dd><dt><a name="ZONEMGR_SESSION_ERROR"></a><span class="term">ZONEMGR_SESSION_ERROR unable to establish session to command channel daemon</span></dt><dd><p>
The zonemgr process was not able to be started because it could not
connect to the command channel daemon.  The most usual cause of this
problem is that the daemon is not running.
</p></dd><dt><a name="ZONEMGR_SESSION_TIMEOUT"></a><span class="term">ZONEMGR_SESSION_TIMEOUT timeout on session to command channel daemon</span></dt><dd><p>
The zonemgr process was not able to be started because it timed out when
connecting to the command channel daemon.  The most usual cause of this
problem is that the daemon is not running.
</p></dd><dt><a name="ZONEMGR_SHUTDOWN"></a><span class="term">ZONEMGR_SHUTDOWN zone manager has shut down</span></dt><dd><p>
A debug message, output when the zone manager has shut down completely.
</p></dd><dt><a name="ZONEMGR_STARTED"></a><span class="term">ZONEMGR_STARTED zonemgr started</span></dt><dd><p>
This informational message is output by zonemgr when all initialization
has been completed and it is entering its main loop.
</p></dd><dt><a name="ZONEMGR_STARTING"></a><span class="term">ZONEMGR_STARTING zone manager starting</span></dt><dd><p>
A debug message output when the zone manager starts up.
</p></dd><dt><a name="ZONEMGR_TIMER_THREAD_RUNNING"></a><span class="term">ZONEMGR_TIMER_THREAD_RUNNING trying to start timer thread but one is already running</span></dt><dd><p>
This message is issued when an attempt is made to start the timer
thread (which keeps track of when zones need a refresh) but one is
already running.  It indicates either an error in the program logic or
a problem with stopping a previous instance of the timer.  Please submit
a bug report.
</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_FAIL"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_FAIL zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
An XFRIN operation has failed but the zone that was the subject of the
operation is not being managed by the zone manager. This can be either the
result of a bindctl command to transfer in a currently unknown (or mistyped)
zone, or, if this error appears without the administrator giving transfer
commands, it can indicate an error in the program, as it should not have
initiated transfers of unknown zones on its own.
</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_NOTIFIED"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_NOTIFIED notified zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
A NOTIFY was received but the zone that was the subject of the operation
is not being managed by the zone manager.  This may indicate an error
in the program (as the operation should not have been initiated if this
were the case).  Please submit a bug report.
</p></dd><dt><a name="ZONEMGR_UNKNOWN_ZONE_SUCCESS"></a><span class="term">ZONEMGR_UNKNOWN_ZONE_SUCCESS zone %1 (class %2) is not known to the zone manager</span></dt><dd><p>
An XFRIN operation has succeeded but the zone received is not being
managed by the zone manager.  This may indicate an error in the program
(as the operation should not have been initiated if this were the case).
Please submit a bug report.
</p></dd></dl></div><p>
    </p></div></div></body></html>