1*00b67f09SDavid van Moolenbroek<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 2*00b67f09SDavid van Moolenbroek "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" []> 3*00b67f09SDavid van Moolenbroek<!-- 4*00b67f09SDavid van Moolenbroek - Copyright (C) 2004-2010, 2013, 2014 Internet Systems Consortium, Inc. ("ISC") 5*00b67f09SDavid van Moolenbroek - Copyright (C) 2000-2003 Internet Software Consortium. 6*00b67f09SDavid van Moolenbroek - 7*00b67f09SDavid van Moolenbroek - Permission to use, copy, modify, and/or distribute this software for any 8*00b67f09SDavid van Moolenbroek - purpose with or without fee is hereby granted, provided that the above 9*00b67f09SDavid van Moolenbroek - copyright notice and this permission notice appear in all copies. 10*00b67f09SDavid van Moolenbroek - 11*00b67f09SDavid van Moolenbroek - THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH 12*00b67f09SDavid van Moolenbroek - REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 13*00b67f09SDavid van Moolenbroek - AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY SPECIAL, DIRECT, 14*00b67f09SDavid van Moolenbroek - INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM 15*00b67f09SDavid van Moolenbroek - LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE 16*00b67f09SDavid van Moolenbroek - OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR 17*00b67f09SDavid van Moolenbroek - PERFORMANCE OF THIS SOFTWARE. 18*00b67f09SDavid van Moolenbroek--> 19*00b67f09SDavid van Moolenbroek 20*00b67f09SDavid van Moolenbroek<!-- Id: FAQ.xml,v 1.54 2010/01/19 23:48:55 tbox Exp --> 21*00b67f09SDavid van Moolenbroek 22*00b67f09SDavid van Moolenbroek<article class="faq"> 23*00b67f09SDavid van Moolenbroek <title>Frequently Asked Questions about BIND 9</title> 24*00b67f09SDavid van Moolenbroek <articleinfo> 25*00b67f09SDavid van Moolenbroek <copyright> 26*00b67f09SDavid van Moolenbroek <year>2004</year> 27*00b67f09SDavid van Moolenbroek <year>2005</year> 28*00b67f09SDavid van Moolenbroek <year>2006</year> 29*00b67f09SDavid van Moolenbroek <year>2007</year> 30*00b67f09SDavid van Moolenbroek <year>2008</year> 31*00b67f09SDavid van Moolenbroek <year>2009</year> 32*00b67f09SDavid van Moolenbroek <year>2010</year> 33*00b67f09SDavid van Moolenbroek <year>2013</year> 34*00b67f09SDavid van Moolenbroek <year>2014</year> 35*00b67f09SDavid van Moolenbroek <holder>Internet Systems Consortium, Inc. ("ISC")</holder> 36*00b67f09SDavid van Moolenbroek </copyright> 37*00b67f09SDavid van Moolenbroek <copyright> 38*00b67f09SDavid van Moolenbroek <year>2000</year> 39*00b67f09SDavid van Moolenbroek <year>2001</year> 40*00b67f09SDavid van Moolenbroek <year>2002</year> 41*00b67f09SDavid van Moolenbroek <year>2003</year> 42*00b67f09SDavid van Moolenbroek <holder>Internet Software Consortium.</holder> 43*00b67f09SDavid van Moolenbroek </copyright> 44*00b67f09SDavid van Moolenbroek </articleinfo> 45*00b67f09SDavid van Moolenbroek <qandaset defaultlabel='qanda'> 46*00b67f09SDavid van Moolenbroek 47*00b67f09SDavid van Moolenbroek <qandadiv><title>Compilation and Installation Questions</title> 48*00b67f09SDavid van Moolenbroek 49*00b67f09SDavid van Moolenbroek <qandaentry> 50*00b67f09SDavid van Moolenbroek <question> 51*00b67f09SDavid van Moolenbroek <para> 52*00b67f09SDavid van Moolenbroek I'm trying to compile BIND 9, and "make" is failing due to 53*00b67f09SDavid van Moolenbroek files not being found. Why? 54*00b67f09SDavid van Moolenbroek </para> 55*00b67f09SDavid van Moolenbroek </question> 56*00b67f09SDavid van Moolenbroek <answer> 57*00b67f09SDavid van Moolenbroek <para> 58*00b67f09SDavid van Moolenbroek Using a parallel or distributed "make" to build BIND 9 is 59*00b67f09SDavid van Moolenbroek not supported, and doesn't work. If you are using one of 60*00b67f09SDavid van Moolenbroek these, use normal make or gmake instead. 61*00b67f09SDavid van Moolenbroek </para> 62*00b67f09SDavid van Moolenbroek </answer> 63*00b67f09SDavid van Moolenbroek </qandaentry> 64*00b67f09SDavid van Moolenbroek 65*00b67f09SDavid van Moolenbroek <qandaentry> 66*00b67f09SDavid van Moolenbroek <question> 67*00b67f09SDavid van Moolenbroek <para> 68*00b67f09SDavid van Moolenbroek Isn't "make install" supposed to generate a default named.conf? 69*00b67f09SDavid van Moolenbroek </para> 70*00b67f09SDavid van Moolenbroek </question> 71*00b67f09SDavid van Moolenbroek <answer> 72*00b67f09SDavid van Moolenbroek <para> 73*00b67f09SDavid van Moolenbroek Short Answer: No. 74*00b67f09SDavid van Moolenbroek </para> 75*00b67f09SDavid van Moolenbroek <para> 76*00b67f09SDavid van Moolenbroek Long Answer: There really isn't a default configuration which fits 77*00b67f09SDavid van Moolenbroek any site perfectly. There are lots of decisions that need to 78*00b67f09SDavid van Moolenbroek be made and there is no consensus on what the defaults should be. 79*00b67f09SDavid van Moolenbroek For example FreeBSD uses /etc/namedb as the location where the 80*00b67f09SDavid van Moolenbroek configuration files for named are stored. Others use /var/named. 81*00b67f09SDavid van Moolenbroek </para> 82*00b67f09SDavid van Moolenbroek <para> 83*00b67f09SDavid van Moolenbroek What addresses to listen on? For a laptop on the move a lot 84*00b67f09SDavid van Moolenbroek you may only want to listen on the loop back interfaces. 85*00b67f09SDavid van Moolenbroek </para> 86*00b67f09SDavid van Moolenbroek <para> 87*00b67f09SDavid van Moolenbroek To whom do you offer recursive service? Is there a firewall 88*00b67f09SDavid van Moolenbroek to consider? If so, is it stateless or stateful? Are you 89*00b67f09SDavid van Moolenbroek directly on the Internet? Are you on a private network? Are 90*00b67f09SDavid van Moolenbroek you on a NAT'd network? The answers 91*00b67f09SDavid van Moolenbroek to all these questions change how you configure even a 92*00b67f09SDavid van Moolenbroek caching name server. 93*00b67f09SDavid van Moolenbroek </para> 94*00b67f09SDavid van Moolenbroek </answer> 95*00b67f09SDavid van Moolenbroek </qandaentry> 96*00b67f09SDavid van Moolenbroek 97*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Compilation and Installation Questions --> 98*00b67f09SDavid van Moolenbroek 99*00b67f09SDavid van Moolenbroek <qandadiv><title>Configuration and Setup Questions</title> 100*00b67f09SDavid van Moolenbroek 101*00b67f09SDavid van Moolenbroek <qandaentry> 102*00b67f09SDavid van Moolenbroek <!-- configuration, log --> 103*00b67f09SDavid van Moolenbroek <question> 104*00b67f09SDavid van Moolenbroek <para> 105*00b67f09SDavid van Moolenbroek Why does named log the warning message <quote>no TTL specified - 106*00b67f09SDavid van Moolenbroek using SOA MINTTL instead</quote>? 107*00b67f09SDavid van Moolenbroek </para> 108*00b67f09SDavid van Moolenbroek </question> 109*00b67f09SDavid van Moolenbroek <answer> 110*00b67f09SDavid van Moolenbroek <para> 111*00b67f09SDavid van Moolenbroek Your zone file is illegal according to RFC1035. It must either 112*00b67f09SDavid van Moolenbroek have a line like: 113*00b67f09SDavid van Moolenbroek </para> 114*00b67f09SDavid van Moolenbroek <informalexample> 115*00b67f09SDavid van Moolenbroek <programlisting> 116*00b67f09SDavid van Moolenbroek$TTL 86400</programlisting> 117*00b67f09SDavid van Moolenbroek </informalexample> 118*00b67f09SDavid van Moolenbroek <para> 119*00b67f09SDavid van Moolenbroek at the beginning, or the first record in it must have a TTL field, 120*00b67f09SDavid van Moolenbroek like the "84600" in this example: 121*00b67f09SDavid van Moolenbroek </para> 122*00b67f09SDavid van Moolenbroek <informalexample> 123*00b67f09SDavid van Moolenbroek <programlisting> 124*00b67f09SDavid van Moolenbroekexample.com. 86400 IN SOA ns hostmaster ( 1 3600 1800 1814400 3600 )</programlisting> 125*00b67f09SDavid van Moolenbroek </informalexample> 126*00b67f09SDavid van Moolenbroek </answer> 127*00b67f09SDavid van Moolenbroek </qandaentry> 128*00b67f09SDavid van Moolenbroek 129*00b67f09SDavid van Moolenbroek <qandaentry> 130*00b67f09SDavid van Moolenbroek <!-- configuration --> 131*00b67f09SDavid van Moolenbroek <question> 132*00b67f09SDavid van Moolenbroek <para> 133*00b67f09SDavid van Moolenbroek Why do I get errors like <quote>dns_zone_load: zone foo/IN: loading 134*00b67f09SDavid van Moolenbroek master file bar: ran out of space</quote>? 135*00b67f09SDavid van Moolenbroek </para> 136*00b67f09SDavid van Moolenbroek </question> 137*00b67f09SDavid van Moolenbroek <answer> 138*00b67f09SDavid van Moolenbroek <para> 139*00b67f09SDavid van Moolenbroek This is often caused by TXT records with missing close 140*00b67f09SDavid van Moolenbroek quotes. Check that all TXT records containing quoted strings 141*00b67f09SDavid van Moolenbroek have both open and close quotes. 142*00b67f09SDavid van Moolenbroek </para> 143*00b67f09SDavid van Moolenbroek </answer> 144*00b67f09SDavid van Moolenbroek </qandaentry> 145*00b67f09SDavid van Moolenbroek 146*00b67f09SDavid van Moolenbroek <qandaentry> 147*00b67f09SDavid van Moolenbroek <!-- security --> 148*00b67f09SDavid van Moolenbroek <question> 149*00b67f09SDavid van Moolenbroek <para> 150*00b67f09SDavid van Moolenbroek How do I restrict people from looking up the server version? 151*00b67f09SDavid van Moolenbroek </para> 152*00b67f09SDavid van Moolenbroek </question> 153*00b67f09SDavid van Moolenbroek <answer> 154*00b67f09SDavid van Moolenbroek <para> 155*00b67f09SDavid van Moolenbroek Put a "version" option containing something other than the 156*00b67f09SDavid van Moolenbroek real version in the "options" section of named.conf. Note 157*00b67f09SDavid van Moolenbroek doing this will not prevent attacks and may impede people 158*00b67f09SDavid van Moolenbroek trying to diagnose problems with your server. Also it is 159*00b67f09SDavid van Moolenbroek possible to "fingerprint" nameservers to determine their 160*00b67f09SDavid van Moolenbroek version. 161*00b67f09SDavid van Moolenbroek </para> 162*00b67f09SDavid van Moolenbroek </answer> 163*00b67f09SDavid van Moolenbroek </qandaentry> 164*00b67f09SDavid van Moolenbroek 165*00b67f09SDavid van Moolenbroek <qandaentry> 166*00b67f09SDavid van Moolenbroek <!-- security --> 167*00b67f09SDavid van Moolenbroek <question> 168*00b67f09SDavid van Moolenbroek <para> 169*00b67f09SDavid van Moolenbroek How do I restrict only remote users from looking up the 170*00b67f09SDavid van Moolenbroek server version? 171*00b67f09SDavid van Moolenbroek </para> 172*00b67f09SDavid van Moolenbroek </question> 173*00b67f09SDavid van Moolenbroek <answer> 174*00b67f09SDavid van Moolenbroek <para> 175*00b67f09SDavid van Moolenbroek The following view statement will intercept lookups as the 176*00b67f09SDavid van Moolenbroek internal view that holds the version information will be 177*00b67f09SDavid van Moolenbroek matched last. The caveats of the previous answer still 178*00b67f09SDavid van Moolenbroek apply, of course. 179*00b67f09SDavid van Moolenbroek </para> 180*00b67f09SDavid van Moolenbroek <informalexample> 181*00b67f09SDavid van Moolenbroek <programlisting> 182*00b67f09SDavid van Moolenbroekview "chaos" chaos { 183*00b67f09SDavid van Moolenbroek match-clients { <those to be refused>; }; 184*00b67f09SDavid van Moolenbroek allow-query { none; }; 185*00b67f09SDavid van Moolenbroek zone "." { 186*00b67f09SDavid van Moolenbroek type hint; 187*00b67f09SDavid van Moolenbroek file "/dev/null"; // or any empty file 188*00b67f09SDavid van Moolenbroek }; 189*00b67f09SDavid van Moolenbroek};</programlisting> 190*00b67f09SDavid van Moolenbroek </informalexample> 191*00b67f09SDavid van Moolenbroek </answer> 192*00b67f09SDavid van Moolenbroek </qandaentry> 193*00b67f09SDavid van Moolenbroek 194*00b67f09SDavid van Moolenbroek <qandaentry> 195*00b67f09SDavid van Moolenbroek <!-- configuration --> 196*00b67f09SDavid van Moolenbroek <question> 197*00b67f09SDavid van Moolenbroek <para> 198*00b67f09SDavid van Moolenbroek What do <quote>no source of entropy found</quote> or <quote>could not 199*00b67f09SDavid van Moolenbroek open entropy source foo</quote> mean? 200*00b67f09SDavid van Moolenbroek </para> 201*00b67f09SDavid van Moolenbroek </question> 202*00b67f09SDavid van Moolenbroek <answer> 203*00b67f09SDavid van Moolenbroek <para> 204*00b67f09SDavid van Moolenbroek The server requires a source of entropy to perform certain 205*00b67f09SDavid van Moolenbroek operations, mostly DNSSEC related. These messages indicate 206*00b67f09SDavid van Moolenbroek that you have no source of entropy. On systems with 207*00b67f09SDavid van Moolenbroek /dev/random or an equivalent, it is used by default. A 208*00b67f09SDavid van Moolenbroek source of entropy can also be defined using the random-device 209*00b67f09SDavid van Moolenbroek option in named.conf. 210*00b67f09SDavid van Moolenbroek </para> 211*00b67f09SDavid van Moolenbroek </answer> 212*00b67f09SDavid van Moolenbroek </qandaentry> 213*00b67f09SDavid van Moolenbroek 214*00b67f09SDavid van Moolenbroek <qandaentry> 215*00b67f09SDavid van Moolenbroek <!-- configuration --> 216*00b67f09SDavid van Moolenbroek <question> 217*00b67f09SDavid van Moolenbroek <para> 218*00b67f09SDavid van Moolenbroek I'm trying to use TSIG to authenticate dynamic updates or 219*00b67f09SDavid van Moolenbroek zone transfers. I'm sure I have the keys set up correctly, 220*00b67f09SDavid van Moolenbroek but the server is rejecting the TSIG. Why? 221*00b67f09SDavid van Moolenbroek </para> 222*00b67f09SDavid van Moolenbroek </question> 223*00b67f09SDavid van Moolenbroek <answer> 224*00b67f09SDavid van Moolenbroek <para> 225*00b67f09SDavid van Moolenbroek This may be a clock skew problem. Check that the the clocks 226*00b67f09SDavid van Moolenbroek on the client and server are properly synchronised (e.g., 227*00b67f09SDavid van Moolenbroek using ntp). 228*00b67f09SDavid van Moolenbroek </para> 229*00b67f09SDavid van Moolenbroek </answer> 230*00b67f09SDavid van Moolenbroek </qandaentry> 231*00b67f09SDavid van Moolenbroek 232*00b67f09SDavid van Moolenbroek <qandaentry> 233*00b67f09SDavid van Moolenbroek <question> 234*00b67f09SDavid van Moolenbroek <para> 235*00b67f09SDavid van Moolenbroek I see a log message like the following. Why? 236*00b67f09SDavid van Moolenbroek </para> 237*00b67f09SDavid van Moolenbroek <para> 238*00b67f09SDavid van Moolenbroek couldn't open pid file '/var/run/named.pid': Permission denied 239*00b67f09SDavid van Moolenbroek </para> 240*00b67f09SDavid van Moolenbroek </question> 241*00b67f09SDavid van Moolenbroek <answer> 242*00b67f09SDavid van Moolenbroek <para> 243*00b67f09SDavid van Moolenbroek You are most likely running named as a non-root user, and 244*00b67f09SDavid van Moolenbroek that user does not have permission to write in /var/run. 245*00b67f09SDavid van Moolenbroek The common ways of fixing this are to create a /var/run/named 246*00b67f09SDavid van Moolenbroek directory owned by the named user and set pid-file to 247*00b67f09SDavid van Moolenbroek "/var/run/named/named.pid", or set pid-file to "named.pid", 248*00b67f09SDavid van Moolenbroek which will put the file in the directory specified by the 249*00b67f09SDavid van Moolenbroek directory option (which, in this case, must be writable by 250*00b67f09SDavid van Moolenbroek the user named is running as). 251*00b67f09SDavid van Moolenbroek </para> 252*00b67f09SDavid van Moolenbroek </answer> 253*00b67f09SDavid van Moolenbroek </qandaentry> 254*00b67f09SDavid van Moolenbroek 255*00b67f09SDavid van Moolenbroek <qandaentry> 256*00b67f09SDavid van Moolenbroek <question> 257*00b67f09SDavid van Moolenbroek <para> 258*00b67f09SDavid van Moolenbroek I can query the nameserver from the nameserver but not from other 259*00b67f09SDavid van Moolenbroek machines. Why? 260*00b67f09SDavid van Moolenbroek </para> 261*00b67f09SDavid van Moolenbroek </question> 262*00b67f09SDavid van Moolenbroek <answer> 263*00b67f09SDavid van Moolenbroek <para> 264*00b67f09SDavid van Moolenbroek This is usually the result of the firewall configuration stopping 265*00b67f09SDavid van Moolenbroek the queries and / or the replies. 266*00b67f09SDavid van Moolenbroek </para> 267*00b67f09SDavid van Moolenbroek </answer> 268*00b67f09SDavid van Moolenbroek </qandaentry> 269*00b67f09SDavid van Moolenbroek 270*00b67f09SDavid van Moolenbroek <qandaentry> 271*00b67f09SDavid van Moolenbroek <question> 272*00b67f09SDavid van Moolenbroek <para> 273*00b67f09SDavid van Moolenbroek How can I make a server a slave for both an internal and 274*00b67f09SDavid van Moolenbroek an external view at the same time? When I tried, both views 275*00b67f09SDavid van Moolenbroek on the slave were transferred from the same view on the master. 276*00b67f09SDavid van Moolenbroek </para> 277*00b67f09SDavid van Moolenbroek </question> 278*00b67f09SDavid van Moolenbroek <answer> 279*00b67f09SDavid van Moolenbroek <para> 280*00b67f09SDavid van Moolenbroek You will need to give the master and slave multiple IP 281*00b67f09SDavid van Moolenbroek addresses and use those to make sure you reach the correct 282*00b67f09SDavid van Moolenbroek view on the other machine. 283*00b67f09SDavid van Moolenbroek </para> 284*00b67f09SDavid van Moolenbroek <informalexample> 285*00b67f09SDavid van Moolenbroek <programlisting> 286*00b67f09SDavid van MoolenbroekMaster: 10.0.1.1 (internal), 10.0.1.2 (external, IP alias) 287*00b67f09SDavid van Moolenbroek internal: 288*00b67f09SDavid van Moolenbroek match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; 289*00b67f09SDavid van Moolenbroek notify-source 10.0.1.1; 290*00b67f09SDavid van Moolenbroek transfer-source 10.0.1.1; 291*00b67f09SDavid van Moolenbroek query-source address 10.0.1.1; 292*00b67f09SDavid van Moolenbroek external: 293*00b67f09SDavid van Moolenbroek match-clients { any; }; 294*00b67f09SDavid van Moolenbroek recursion no; // don't offer recursion to the world 295*00b67f09SDavid van Moolenbroek notify-source 10.0.1.2; 296*00b67f09SDavid van Moolenbroek transfer-source 10.0.1.2; 297*00b67f09SDavid van Moolenbroek query-source address 10.0.1.2; 298*00b67f09SDavid van Moolenbroek 299*00b67f09SDavid van MoolenbroekSlave: 10.0.1.3 (internal), 10.0.1.4 (external, IP alias) 300*00b67f09SDavid van Moolenbroek internal: 301*00b67f09SDavid van Moolenbroek match-clients { !10.0.1.2; !10.0.1.4; 10.0.1/24; }; 302*00b67f09SDavid van Moolenbroek notify-source 10.0.1.3; 303*00b67f09SDavid van Moolenbroek transfer-source 10.0.1.3; 304*00b67f09SDavid van Moolenbroek query-source address 10.0.1.3; 305*00b67f09SDavid van Moolenbroek external: 306*00b67f09SDavid van Moolenbroek match-clients { any; }; 307*00b67f09SDavid van Moolenbroek recursion no; // don't offer recursion to the world 308*00b67f09SDavid van Moolenbroek notify-source 10.0.1.4; 309*00b67f09SDavid van Moolenbroek transfer-source 10.0.1.4; 310*00b67f09SDavid van Moolenbroek query-source address 10.0.1.4;</programlisting> 311*00b67f09SDavid van Moolenbroek </informalexample> 312*00b67f09SDavid van Moolenbroek <para> 313*00b67f09SDavid van Moolenbroek You put the external address on the alias so that all the other 314*00b67f09SDavid van Moolenbroek dns clients on these boxes see the internal view by default. 315*00b67f09SDavid van Moolenbroek </para> 316*00b67f09SDavid van Moolenbroek </answer> 317*00b67f09SDavid van Moolenbroek <answer> 318*00b67f09SDavid van Moolenbroek <para> 319*00b67f09SDavid van Moolenbroek BIND 9.3 and later: Use TSIG to select the appropriate view. 320*00b67f09SDavid van Moolenbroek </para> 321*00b67f09SDavid van Moolenbroek <informalexample> 322*00b67f09SDavid van Moolenbroek <programlisting> 323*00b67f09SDavid van MoolenbroekMaster 10.0.1.1: 324*00b67f09SDavid van Moolenbroek key "external" { 325*00b67f09SDavid van Moolenbroek algorithm hmac-sha256; 326*00b67f09SDavid van Moolenbroek secret "xxxxxxxxxxxxxxxxxxxxxxxx"; 327*00b67f09SDavid van Moolenbroek }; 328*00b67f09SDavid van Moolenbroek view "internal" { 329*00b67f09SDavid van Moolenbroek match-clients { !key external; // reject message ment for the 330*00b67f09SDavid van Moolenbroek // external view. 331*00b67f09SDavid van Moolenbroek 10.0.1/24; }; // accept from these addresses. 332*00b67f09SDavid van Moolenbroek ... 333*00b67f09SDavid van Moolenbroek }; 334*00b67f09SDavid van Moolenbroek view "external" { 335*00b67f09SDavid van Moolenbroek match-clients { key external; any; }; 336*00b67f09SDavid van Moolenbroek server 10.0.1.2 { keys external; }; // tag messages from the 337*00b67f09SDavid van Moolenbroek // external view to the 338*00b67f09SDavid van Moolenbroek // other servers for the 339*00b67f09SDavid van Moolenbroek // view. 340*00b67f09SDavid van Moolenbroek recursion no; 341*00b67f09SDavid van Moolenbroek ... 342*00b67f09SDavid van Moolenbroek }; 343*00b67f09SDavid van Moolenbroek 344*00b67f09SDavid van MoolenbroekSlave 10.0.1.2: 345*00b67f09SDavid van Moolenbroek key "external" { 346*00b67f09SDavid van Moolenbroek algorithm hmac-sha256; 347*00b67f09SDavid van Moolenbroek secret "xxxxxxxxxxxxxxxxxxxxxxxx"; 348*00b67f09SDavid van Moolenbroek }; 349*00b67f09SDavid van Moolenbroek view "internal" { 350*00b67f09SDavid van Moolenbroek match-clients { !key external; 10.0.1/24; }; 351*00b67f09SDavid van Moolenbroek ... 352*00b67f09SDavid van Moolenbroek }; 353*00b67f09SDavid van Moolenbroek view "external" { 354*00b67f09SDavid van Moolenbroek match-clients { key external; any; }; 355*00b67f09SDavid van Moolenbroek server 10.0.1.1 { keys external; }; 356*00b67f09SDavid van Moolenbroek recursion no; 357*00b67f09SDavid van Moolenbroek ... 358*00b67f09SDavid van Moolenbroek };</programlisting> 359*00b67f09SDavid van Moolenbroek </informalexample> 360*00b67f09SDavid van Moolenbroek </answer> 361*00b67f09SDavid van Moolenbroek </qandaentry> 362*00b67f09SDavid van Moolenbroek 363*00b67f09SDavid van Moolenbroek <qandaentry> 364*00b67f09SDavid van Moolenbroek <question> 365*00b67f09SDavid van Moolenbroek <para> 366*00b67f09SDavid van Moolenbroek I get error messages like <quote>multiple RRs of singleton type</quote> 367*00b67f09SDavid van Moolenbroek and <quote>CNAME and other data</quote> when transferring a zone. What 368*00b67f09SDavid van Moolenbroek does this mean? 369*00b67f09SDavid van Moolenbroek </para> 370*00b67f09SDavid van Moolenbroek </question> 371*00b67f09SDavid van Moolenbroek <answer> 372*00b67f09SDavid van Moolenbroek <para> 373*00b67f09SDavid van Moolenbroek These indicate a malformed master zone. You can identify 374*00b67f09SDavid van Moolenbroek the exact records involved by transferring the zone using 375*00b67f09SDavid van Moolenbroek dig then running named-checkzone on it. 376*00b67f09SDavid van Moolenbroek </para> 377*00b67f09SDavid van Moolenbroek <informalexample> 378*00b67f09SDavid van Moolenbroek <programlisting> 379*00b67f09SDavid van Moolenbroekdig axfr example.com @master-server > tmp 380*00b67f09SDavid van Moolenbroeknamed-checkzone example.com tmp</programlisting> 381*00b67f09SDavid van Moolenbroek </informalexample> 382*00b67f09SDavid van Moolenbroek <para> 383*00b67f09SDavid van Moolenbroek A CNAME record cannot exist with the same name as another record 384*00b67f09SDavid van Moolenbroek except for the DNSSEC records which prove its existence (NSEC). 385*00b67f09SDavid van Moolenbroek </para> 386*00b67f09SDavid van Moolenbroek <para> 387*00b67f09SDavid van Moolenbroek RFC 1034, Section 3.6.2: <quote>If a CNAME RR is present at a node, 388*00b67f09SDavid van Moolenbroek no other data should be present; this ensures that the data for a 389*00b67f09SDavid van Moolenbroek canonical name and its aliases cannot be different. This rule also 390*00b67f09SDavid van Moolenbroek insures that a cached CNAME can be used without checking with an 391*00b67f09SDavid van Moolenbroek authoritative server for other RR types.</quote> 392*00b67f09SDavid van Moolenbroek </para> 393*00b67f09SDavid van Moolenbroek </answer> 394*00b67f09SDavid van Moolenbroek </qandaentry> 395*00b67f09SDavid van Moolenbroek 396*00b67f09SDavid van Moolenbroek <qandaentry> 397*00b67f09SDavid van Moolenbroek <question> 398*00b67f09SDavid van Moolenbroek <para> 399*00b67f09SDavid van Moolenbroek I get error messages like <quote>named.conf:99: unexpected end 400*00b67f09SDavid van Moolenbroek of input</quote> where 99 is the last line of named.conf. 401*00b67f09SDavid van Moolenbroek </para> 402*00b67f09SDavid van Moolenbroek </question> 403*00b67f09SDavid van Moolenbroek <answer> 404*00b67f09SDavid van Moolenbroek <para> 405*00b67f09SDavid van Moolenbroek There are unbalanced quotes in named.conf. 406*00b67f09SDavid van Moolenbroek </para> 407*00b67f09SDavid van Moolenbroek </answer> 408*00b67f09SDavid van Moolenbroek <answer> 409*00b67f09SDavid van Moolenbroek <para> 410*00b67f09SDavid van Moolenbroek Some text editors (notepad and wordpad) fail to put a line 411*00b67f09SDavid van Moolenbroek title indication (e.g. CR/LF) on the last line of a 412*00b67f09SDavid van Moolenbroek text file. This can be fixed by "adding" a blank line to 413*00b67f09SDavid van Moolenbroek the end of the file. Named expects to see EOF immediately 414*00b67f09SDavid van Moolenbroek after EOL and treats text files where this is not met as 415*00b67f09SDavid van Moolenbroek truncated. 416*00b67f09SDavid van Moolenbroek </para> 417*00b67f09SDavid van Moolenbroek </answer> 418*00b67f09SDavid van Moolenbroek </qandaentry> 419*00b67f09SDavid van Moolenbroek 420*00b67f09SDavid van Moolenbroek <qandaentry> 421*00b67f09SDavid van Moolenbroek <question> 422*00b67f09SDavid van Moolenbroek <para> 423*00b67f09SDavid van Moolenbroek How do I share a dynamic zone between multiple views? 424*00b67f09SDavid van Moolenbroek </para> 425*00b67f09SDavid van Moolenbroek </question> 426*00b67f09SDavid van Moolenbroek <answer> 427*00b67f09SDavid van Moolenbroek <para> 428*00b67f09SDavid van Moolenbroek You choose one view to be master and the second a slave and 429*00b67f09SDavid van Moolenbroek transfer the zone between views. 430*00b67f09SDavid van Moolenbroek </para> 431*00b67f09SDavid van Moolenbroek <informalexample> 432*00b67f09SDavid van Moolenbroek <programlisting> 433*00b67f09SDavid van MoolenbroekMaster 10.0.1.1: 434*00b67f09SDavid van Moolenbroek key "external" { 435*00b67f09SDavid van Moolenbroek algorithm hmac-sha256; 436*00b67f09SDavid van Moolenbroek secret "xxxxxxxxxxxxxxxxxxxxxxxx"; 437*00b67f09SDavid van Moolenbroek }; 438*00b67f09SDavid van Moolenbroek 439*00b67f09SDavid van Moolenbroek key "mykey" { 440*00b67f09SDavid van Moolenbroek algorithm hmac-sha256; 441*00b67f09SDavid van Moolenbroek secret "yyyyyyyyyyyyyyyyyyyyyyyy"; 442*00b67f09SDavid van Moolenbroek }; 443*00b67f09SDavid van Moolenbroek 444*00b67f09SDavid van Moolenbroek view "internal" { 445*00b67f09SDavid van Moolenbroek match-clients { !key external; 10.0.1/24; }; 446*00b67f09SDavid van Moolenbroek server 10.0.1.1 { 447*00b67f09SDavid van Moolenbroek /* Deliver notify messages to external view. */ 448*00b67f09SDavid van Moolenbroek keys { external; }; 449*00b67f09SDavid van Moolenbroek }; 450*00b67f09SDavid van Moolenbroek zone "example.com" { 451*00b67f09SDavid van Moolenbroek type master; 452*00b67f09SDavid van Moolenbroek file "internal/example.db"; 453*00b67f09SDavid van Moolenbroek allow-update { key mykey; }; 454*00b67f09SDavid van Moolenbroek also-notify { 10.0.1.1; }; 455*00b67f09SDavid van Moolenbroek }; 456*00b67f09SDavid van Moolenbroek }; 457*00b67f09SDavid van Moolenbroek 458*00b67f09SDavid van Moolenbroek view "external" { 459*00b67f09SDavid van Moolenbroek match-clients { key external; any; }; 460*00b67f09SDavid van Moolenbroek zone "example.com" { 461*00b67f09SDavid van Moolenbroek type slave; 462*00b67f09SDavid van Moolenbroek file "external/example.db"; 463*00b67f09SDavid van Moolenbroek masters { 10.0.1.1; }; 464*00b67f09SDavid van Moolenbroek transfer-source 10.0.1.1; 465*00b67f09SDavid van Moolenbroek // allow-update-forwarding { any; }; 466*00b67f09SDavid van Moolenbroek // allow-notify { ... }; 467*00b67f09SDavid van Moolenbroek }; 468*00b67f09SDavid van Moolenbroek };</programlisting> 469*00b67f09SDavid van Moolenbroek </informalexample> 470*00b67f09SDavid van Moolenbroek </answer> 471*00b67f09SDavid van Moolenbroek </qandaentry> 472*00b67f09SDavid van Moolenbroek 473*00b67f09SDavid van Moolenbroek <qandaentry> 474*00b67f09SDavid van Moolenbroek <question> 475*00b67f09SDavid van Moolenbroek <para> 476*00b67f09SDavid van Moolenbroek I get a error message like <quote>zone wireless.ietf56.ietf.org/IN: 477*00b67f09SDavid van Moolenbroek loading master file primaries/wireless.ietf56.ietf.org: no 478*00b67f09SDavid van Moolenbroek owner</quote>. 479*00b67f09SDavid van Moolenbroek </para> 480*00b67f09SDavid van Moolenbroek </question> 481*00b67f09SDavid van Moolenbroek <answer> 482*00b67f09SDavid van Moolenbroek <para> 483*00b67f09SDavid van Moolenbroek This error is produced when a line in the master file 484*00b67f09SDavid van Moolenbroek contains leading white space (tab/space) but there is no 485*00b67f09SDavid van Moolenbroek current record owner name to inherit the name from. Usually 486*00b67f09SDavid van Moolenbroek this is the result of putting white space before a comment, 487*00b67f09SDavid van Moolenbroek forgetting the "@" for the SOA record, or indenting the master 488*00b67f09SDavid van Moolenbroek file. 489*00b67f09SDavid van Moolenbroek </para> 490*00b67f09SDavid van Moolenbroek </answer> 491*00b67f09SDavid van Moolenbroek </qandaentry> 492*00b67f09SDavid van Moolenbroek 493*00b67f09SDavid van Moolenbroek <qandaentry> 494*00b67f09SDavid van Moolenbroek <question> 495*00b67f09SDavid van Moolenbroek <para> 496*00b67f09SDavid van Moolenbroek Why are my logs in GMT (UTC). 497*00b67f09SDavid van Moolenbroek </para> 498*00b67f09SDavid van Moolenbroek </question> 499*00b67f09SDavid van Moolenbroek <answer> 500*00b67f09SDavid van Moolenbroek <para> 501*00b67f09SDavid van Moolenbroek You are running chrooted (-t) and have not supplied local timezone 502*00b67f09SDavid van Moolenbroek information in the chroot area. 503*00b67f09SDavid van Moolenbroek </para> 504*00b67f09SDavid van Moolenbroek <simplelist> 505*00b67f09SDavid van Moolenbroek <member>FreeBSD: /etc/localtime</member> 506*00b67f09SDavid van Moolenbroek <member>Solaris: /etc/TIMEZONE and /usr/share/lib/zoneinfo</member> 507*00b67f09SDavid van Moolenbroek <member>OSF: /etc/zoneinfo/localtime</member> 508*00b67f09SDavid van Moolenbroek </simplelist> 509*00b67f09SDavid van Moolenbroek <para> 510*00b67f09SDavid van Moolenbroek See also tzset(3) and zic(8). 511*00b67f09SDavid van Moolenbroek </para> 512*00b67f09SDavid van Moolenbroek </answer> 513*00b67f09SDavid van Moolenbroek </qandaentry> 514*00b67f09SDavid van Moolenbroek 515*00b67f09SDavid van Moolenbroek <qandaentry> 516*00b67f09SDavid van Moolenbroek <question> 517*00b67f09SDavid van Moolenbroek <para> 518*00b67f09SDavid van Moolenbroek I get <quote>rndc: connect failed: connection refused</quote> when 519*00b67f09SDavid van Moolenbroek I try to run rndc. 520*00b67f09SDavid van Moolenbroek </para> 521*00b67f09SDavid van Moolenbroek </question> 522*00b67f09SDavid van Moolenbroek <answer> 523*00b67f09SDavid van Moolenbroek <para> 524*00b67f09SDavid van Moolenbroek This is usually a configuration error. 525*00b67f09SDavid van Moolenbroek </para> 526*00b67f09SDavid van Moolenbroek <para> 527*00b67f09SDavid van Moolenbroek First ensure that named is running and no errors are being 528*00b67f09SDavid van Moolenbroek reported at startup (/var/log/messages or equivalent). 529*00b67f09SDavid van Moolenbroek Running "named -g <usual arguments>" from a title 530*00b67f09SDavid van Moolenbroek can help at this point. 531*00b67f09SDavid van Moolenbroek </para> 532*00b67f09SDavid van Moolenbroek <para> 533*00b67f09SDavid van Moolenbroek Secondly ensure that named is configured to use rndc either 534*00b67f09SDavid van Moolenbroek by "rndc-confgen -a", rndc-confgen or manually. The 535*00b67f09SDavid van Moolenbroek Administrators Reference manual has details on how to do 536*00b67f09SDavid van Moolenbroek this. 537*00b67f09SDavid van Moolenbroek </para> 538*00b67f09SDavid van Moolenbroek <para> 539*00b67f09SDavid van Moolenbroek Old versions of rndc-confgen used localhost rather than 540*00b67f09SDavid van Moolenbroek 127.0.0.1 in /etc/rndc.conf for the default server. Update 541*00b67f09SDavid van Moolenbroek /etc/rndc.conf if necessary so that the default server 542*00b67f09SDavid van Moolenbroek listed in /etc/rndc.conf matches the addresses used in 543*00b67f09SDavid van Moolenbroek named.conf. "localhost" has two address (127.0.0.1 and 544*00b67f09SDavid van Moolenbroek ::1). 545*00b67f09SDavid van Moolenbroek </para> 546*00b67f09SDavid van Moolenbroek <para> 547*00b67f09SDavid van Moolenbroek If you use "rndc-confgen -a" and named is running with -t or -u 548*00b67f09SDavid van Moolenbroek ensure that /etc/rndc.conf has the correct ownership and that 549*00b67f09SDavid van Moolenbroek a copy is in the chroot area. You can do this by re-running 550*00b67f09SDavid van Moolenbroek "rndc-confgen -a" with appropriate -t and -u arguments. 551*00b67f09SDavid van Moolenbroek </para> 552*00b67f09SDavid van Moolenbroek </answer> 553*00b67f09SDavid van Moolenbroek </qandaentry> 554*00b67f09SDavid van Moolenbroek 555*00b67f09SDavid van Moolenbroek <qandaentry> 556*00b67f09SDavid van Moolenbroek <question> 557*00b67f09SDavid van Moolenbroek <para> 558*00b67f09SDavid van Moolenbroek I get <quote>transfer of 'example.net/IN' from 192.168.4.12#53: 559*00b67f09SDavid van Moolenbroek failed while receiving responses: permission denied</quote> error 560*00b67f09SDavid van Moolenbroek messages. 561*00b67f09SDavid van Moolenbroek </para> 562*00b67f09SDavid van Moolenbroek </question> 563*00b67f09SDavid van Moolenbroek <answer> 564*00b67f09SDavid van Moolenbroek <para> 565*00b67f09SDavid van Moolenbroek These indicate a filesystem permission error preventing 566*00b67f09SDavid van Moolenbroek named creating / renaming the temporary file. These will 567*00b67f09SDavid van Moolenbroek usually also have other associated error messages like 568*00b67f09SDavid van Moolenbroek </para> 569*00b67f09SDavid van Moolenbroek <informalexample> 570*00b67f09SDavid van Moolenbroek <programlisting> 571*00b67f09SDavid van Moolenbroek"dumping master file: sl/tmp-XXXX5il3sQ: open: permission denied"</programlisting> 572*00b67f09SDavid van Moolenbroek </informalexample> 573*00b67f09SDavid van Moolenbroek <para> 574*00b67f09SDavid van Moolenbroek Named needs write permission on the directory containing 575*00b67f09SDavid van Moolenbroek the file. Named writes the new cache file to a temporary 576*00b67f09SDavid van Moolenbroek file then renames it to the name specified in named.conf 577*00b67f09SDavid van Moolenbroek to ensure that the contents are always complete. This is 578*00b67f09SDavid van Moolenbroek to prevent named loading a partial zone in the event of 579*00b67f09SDavid van Moolenbroek power failure or similar interrupting the write of the 580*00b67f09SDavid van Moolenbroek master file. 581*00b67f09SDavid van Moolenbroek </para> 582*00b67f09SDavid van Moolenbroek <para> 583*00b67f09SDavid van Moolenbroek Note file names are relative to the directory specified in 584*00b67f09SDavid van Moolenbroek options and any chroot directory ([<chroot 585*00b67f09SDavid van Moolenbroek dir>/][<options dir>]). 586*00b67f09SDavid van Moolenbroek </para> 587*00b67f09SDavid van Moolenbroek <informalexample> 588*00b67f09SDavid van Moolenbroek <para> 589*00b67f09SDavid van Moolenbroek If named is invoked as "named -t /chroot/DNS" with 590*00b67f09SDavid van Moolenbroek the following named.conf then "/chroot/DNS/var/named/sl" 591*00b67f09SDavid van Moolenbroek needs to be writable by the user named is running as. 592*00b67f09SDavid van Moolenbroek </para> 593*00b67f09SDavid van Moolenbroek <programlisting> 594*00b67f09SDavid van Moolenbroekoptions { 595*00b67f09SDavid van Moolenbroek directory "/var/named"; 596*00b67f09SDavid van Moolenbroek}; 597*00b67f09SDavid van Moolenbroek 598*00b67f09SDavid van Moolenbroekzone "example.net" { 599*00b67f09SDavid van Moolenbroek type slave; 600*00b67f09SDavid van Moolenbroek file "sl/example.net"; 601*00b67f09SDavid van Moolenbroek masters { 192.168.4.12; }; 602*00b67f09SDavid van Moolenbroek};</programlisting> 603*00b67f09SDavid van Moolenbroek </informalexample> 604*00b67f09SDavid van Moolenbroek </answer> 605*00b67f09SDavid van Moolenbroek </qandaentry> 606*00b67f09SDavid van Moolenbroek 607*00b67f09SDavid van Moolenbroek <qandaentry> 608*00b67f09SDavid van Moolenbroek <question> 609*00b67f09SDavid van Moolenbroek <para> 610*00b67f09SDavid van Moolenbroek I want to forward all DNS queries from my caching nameserver to 611*00b67f09SDavid van Moolenbroek another server. But there are some domains which have to be 612*00b67f09SDavid van Moolenbroek served locally, via rbldnsd. 613*00b67f09SDavid van Moolenbroek </para> 614*00b67f09SDavid van Moolenbroek <para> 615*00b67f09SDavid van Moolenbroek How do I achieve this ? 616*00b67f09SDavid van Moolenbroek </para> 617*00b67f09SDavid van Moolenbroek </question> 618*00b67f09SDavid van Moolenbroek <answer> 619*00b67f09SDavid van Moolenbroek <programlisting> 620*00b67f09SDavid van Moolenbroekoptions { 621*00b67f09SDavid van Moolenbroek forward only; 622*00b67f09SDavid van Moolenbroek forwarders { <ip.of.primary.nameserver>; }; 623*00b67f09SDavid van Moolenbroek}; 624*00b67f09SDavid van Moolenbroek 625*00b67f09SDavid van Moolenbroekzone "sbl-xbl.spamhaus.org" { 626*00b67f09SDavid van Moolenbroek type forward; forward only; 627*00b67f09SDavid van Moolenbroek forwarders { <ip.of.rbldns.server> port 530; }; 628*00b67f09SDavid van Moolenbroek}; 629*00b67f09SDavid van Moolenbroek 630*00b67f09SDavid van Moolenbroekzone "list.dsbl.org" { 631*00b67f09SDavid van Moolenbroek type forward; forward only; 632*00b67f09SDavid van Moolenbroek forwarders { <ip.of.rbldns.server> port 530; }; 633*00b67f09SDavid van Moolenbroek}; 634*00b67f09SDavid van Moolenbroek </programlisting> 635*00b67f09SDavid van Moolenbroek </answer> 636*00b67f09SDavid van Moolenbroek </qandaentry> 637*00b67f09SDavid van Moolenbroek 638*00b67f09SDavid van Moolenbroek <qandaentry> 639*00b67f09SDavid van Moolenbroek <question> 640*00b67f09SDavid van Moolenbroek <para> 641*00b67f09SDavid van Moolenbroek Can you help me understand how BIND 9 uses memory to store 642*00b67f09SDavid van Moolenbroek DNS zones? 643*00b67f09SDavid van Moolenbroek </para> 644*00b67f09SDavid van Moolenbroek <para> 645*00b67f09SDavid van Moolenbroek Some times it seems to take several times the amount of 646*00b67f09SDavid van Moolenbroek memory it needs to store the zone. 647*00b67f09SDavid van Moolenbroek </para> 648*00b67f09SDavid van Moolenbroek </question> 649*00b67f09SDavid van Moolenbroek <answer> 650*00b67f09SDavid van Moolenbroek <para> 651*00b67f09SDavid van Moolenbroek When reloading a zone named my have multiple copies of 652*00b67f09SDavid van Moolenbroek the zone in memory at one time. The zone it is serving 653*00b67f09SDavid van Moolenbroek and the one it is loading. If reloads are ultra fast it 654*00b67f09SDavid van Moolenbroek can have more still. 655*00b67f09SDavid van Moolenbroek </para> 656*00b67f09SDavid van Moolenbroek <para> 657*00b67f09SDavid van Moolenbroek e.g. Ones that are transferring out, the one that it is 658*00b67f09SDavid van Moolenbroek serving and the one that is loading. 659*00b67f09SDavid van Moolenbroek </para> 660*00b67f09SDavid van Moolenbroek <para> 661*00b67f09SDavid van Moolenbroek BIND 8 destroyed the zone before loading and also killed 662*00b67f09SDavid van Moolenbroek off outgoing transfers of the zone. 663*00b67f09SDavid van Moolenbroek </para> 664*00b67f09SDavid van Moolenbroek <para> 665*00b67f09SDavid van Moolenbroek The new strategy allows slaves to get copies of the new 666*00b67f09SDavid van Moolenbroek zone regardless of how often the master is loaded compared 667*00b67f09SDavid van Moolenbroek to the transfer time. The slave might skip some intermediate 668*00b67f09SDavid van Moolenbroek versions but the transfers will complete and it will keep 669*00b67f09SDavid van Moolenbroek reasonably in sync with the master. 670*00b67f09SDavid van Moolenbroek </para> 671*00b67f09SDavid van Moolenbroek <para> 672*00b67f09SDavid van Moolenbroek The new strategy also allows the master to recover from 673*00b67f09SDavid van Moolenbroek syntax and other errors in the master file as it still 674*00b67f09SDavid van Moolenbroek has an in-core copy of the old contents. 675*00b67f09SDavid van Moolenbroek </para> 676*00b67f09SDavid van Moolenbroek </answer> 677*00b67f09SDavid van Moolenbroek </qandaentry> 678*00b67f09SDavid van Moolenbroek 679*00b67f09SDavid van Moolenbroek <qandaentry> 680*00b67f09SDavid van Moolenbroek <question> 681*00b67f09SDavid van Moolenbroek <para> 682*00b67f09SDavid van Moolenbroek I want to use IPv6 locally but I don't have a external IPv6 683*00b67f09SDavid van Moolenbroek connection. External lookups are slow. 684*00b67f09SDavid van Moolenbroek </para> 685*00b67f09SDavid van Moolenbroek </question> 686*00b67f09SDavid van Moolenbroek <answer> 687*00b67f09SDavid van Moolenbroek <para> 688*00b67f09SDavid van Moolenbroek You can use server clauses to stop named making external lookups 689*00b67f09SDavid van Moolenbroek over IPv6. 690*00b67f09SDavid van Moolenbroek </para> 691*00b67f09SDavid van Moolenbroek <programlisting> 692*00b67f09SDavid van Moolenbroekserver fd81:ec6c:bd62::/48 { bogus no; }; // site ULA prefix 693*00b67f09SDavid van Moolenbroekserver ::/0 { bogus yes; }; 694*00b67f09SDavid van Moolenbroek</programlisting> 695*00b67f09SDavid van Moolenbroek </answer> 696*00b67f09SDavid van Moolenbroek </qandaentry> 697*00b67f09SDavid van Moolenbroek 698*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Configuration and Setup Questions --> 699*00b67f09SDavid van Moolenbroek 700*00b67f09SDavid van Moolenbroek <qandadiv><title>Operations Questions</title> 701*00b67f09SDavid van Moolenbroek 702*00b67f09SDavid van Moolenbroek <qandaentry> 703*00b67f09SDavid van Moolenbroek <question> 704*00b67f09SDavid van Moolenbroek <para> 705*00b67f09SDavid van Moolenbroek How to change the nameservers for a zone? 706*00b67f09SDavid van Moolenbroek </para> 707*00b67f09SDavid van Moolenbroek </question> 708*00b67f09SDavid van Moolenbroek <answer> 709*00b67f09SDavid van Moolenbroek <para> 710*00b67f09SDavid van Moolenbroek Step 1: Ensure all nameservers, new and old, are serving the 711*00b67f09SDavid van Moolenbroek same zone content. 712*00b67f09SDavid van Moolenbroek </para> 713*00b67f09SDavid van Moolenbroek <para> 714*00b67f09SDavid van Moolenbroek Step 2: Work out the maximum TTL of the NS RRset in the parent and child 715*00b67f09SDavid van Moolenbroek zones. This is the time it will take caches to be clear of a 716*00b67f09SDavid van Moolenbroek particular version of the NS RRset. 717*00b67f09SDavid van Moolenbroek If you are just removing nameservers you can skip to Step 6. 718*00b67f09SDavid van Moolenbroek </para> 719*00b67f09SDavid van Moolenbroek <para> 720*00b67f09SDavid van Moolenbroek Step 3: Add new nameservers to the NS RRset for the zone and 721*00b67f09SDavid van Moolenbroek wait until all the servers for the zone are answering with this 722*00b67f09SDavid van Moolenbroek new NS RRset. 723*00b67f09SDavid van Moolenbroek </para> 724*00b67f09SDavid van Moolenbroek <para> 725*00b67f09SDavid van Moolenbroek Step 4: Inform the parent zone of the new NS RRset then wait for all the 726*00b67f09SDavid van Moolenbroek parent servers to be answering with the new NS RRset. 727*00b67f09SDavid van Moolenbroek </para> 728*00b67f09SDavid van Moolenbroek <para> 729*00b67f09SDavid van Moolenbroek Step 5: Wait for cache to be clear of the old NS RRset. 730*00b67f09SDavid van Moolenbroek See Step 2 for how long. 731*00b67f09SDavid van Moolenbroek If you are just adding nameservers you are done. 732*00b67f09SDavid van Moolenbroek </para> 733*00b67f09SDavid van Moolenbroek <para> 734*00b67f09SDavid van Moolenbroek Step 6: Remove any old nameservers from the zones NS RRset and 735*00b67f09SDavid van Moolenbroek wait for all the servers for the zone to be serving the new NS RRset. 736*00b67f09SDavid van Moolenbroek </para> 737*00b67f09SDavid van Moolenbroek <para> 738*00b67f09SDavid van Moolenbroek Step 7: Inform the parent zone of the new NS RRset then wait for all the 739*00b67f09SDavid van Moolenbroek parent servers to be answering with the new NS RRset. 740*00b67f09SDavid van Moolenbroek </para> 741*00b67f09SDavid van Moolenbroek <para> 742*00b67f09SDavid van Moolenbroek Step 8: Wait for cache to be clear of the old NS RRset. 743*00b67f09SDavid van Moolenbroek See Step 2 for how long. 744*00b67f09SDavid van Moolenbroek </para> 745*00b67f09SDavid van Moolenbroek <para> 746*00b67f09SDavid van Moolenbroek Step 9: Turn off the old nameservers or remove the zone entry from 747*00b67f09SDavid van Moolenbroek the configuration of the old nameservers. 748*00b67f09SDavid van Moolenbroek </para> 749*00b67f09SDavid van Moolenbroek <para> 750*00b67f09SDavid van Moolenbroek Step 10: Increment the serial number and wait for the change to 751*00b67f09SDavid van Moolenbroek be visible in all nameservers for the zone. This ensures that 752*00b67f09SDavid van Moolenbroek zone transfers are still working after the old servers are 753*00b67f09SDavid van Moolenbroek decommissioned. 754*00b67f09SDavid van Moolenbroek </para> 755*00b67f09SDavid van Moolenbroek <para> 756*00b67f09SDavid van Moolenbroek Note: the above procedure is designed to be transparent 757*00b67f09SDavid van Moolenbroek to dns clients. Decommissioning the old servers too early 758*00b67f09SDavid van Moolenbroek will result in some clients not being able to look up 759*00b67f09SDavid van Moolenbroek answers in the zone. 760*00b67f09SDavid van Moolenbroek </para> 761*00b67f09SDavid van Moolenbroek <para> 762*00b67f09SDavid van Moolenbroek Note: while it is possible to run the addition and removal 763*00b67f09SDavid van Moolenbroek stages together it is not recommended. 764*00b67f09SDavid van Moolenbroek </para> 765*00b67f09SDavid van Moolenbroek </answer> 766*00b67f09SDavid van Moolenbroek </qandaentry> 767*00b67f09SDavid van Moolenbroek 768*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Operations Questions --> 769*00b67f09SDavid van Moolenbroek 770*00b67f09SDavid van Moolenbroek <qandadiv><title>General Questions</title> 771*00b67f09SDavid van Moolenbroek 772*00b67f09SDavid van Moolenbroek <qandaentry> 773*00b67f09SDavid van Moolenbroek <question> 774*00b67f09SDavid van Moolenbroek <para> 775*00b67f09SDavid van Moolenbroek I keep getting log messages like the following. Why? 776*00b67f09SDavid van Moolenbroek </para> 777*00b67f09SDavid van Moolenbroek <para> 778*00b67f09SDavid van Moolenbroek Dec 4 23:47:59 client 10.0.0.1#1355: updating zone 779*00b67f09SDavid van Moolenbroek 'example.com/IN': update failed: 'RRset exists (value 780*00b67f09SDavid van Moolenbroek dependent)' prerequisite not satisfied (NXRRSET) 781*00b67f09SDavid van Moolenbroek </para> 782*00b67f09SDavid van Moolenbroek </question> 783*00b67f09SDavid van Moolenbroek <answer> 784*00b67f09SDavid van Moolenbroek <para> 785*00b67f09SDavid van Moolenbroek DNS updates allow the update request to test to see if 786*00b67f09SDavid van Moolenbroek certain conditions are met prior to proceeding with the 787*00b67f09SDavid van Moolenbroek update. The message above is saying that conditions were 788*00b67f09SDavid van Moolenbroek not met and the update is not proceeding. See doc/rfc/rfc2136.txt 789*00b67f09SDavid van Moolenbroek for more details on prerequisites. 790*00b67f09SDavid van Moolenbroek </para> 791*00b67f09SDavid van Moolenbroek </answer> 792*00b67f09SDavid van Moolenbroek </qandaentry> 793*00b67f09SDavid van Moolenbroek 794*00b67f09SDavid van Moolenbroek <qandaentry> 795*00b67f09SDavid van Moolenbroek <question> 796*00b67f09SDavid van Moolenbroek <para> 797*00b67f09SDavid van Moolenbroek I keep getting log messages like the following. Why? 798*00b67f09SDavid van Moolenbroek </para> 799*00b67f09SDavid van Moolenbroek <para> 800*00b67f09SDavid van Moolenbroek Jun 21 12:00:00.000 client 10.0.0.1#1234: update denied 801*00b67f09SDavid van Moolenbroek </para> 802*00b67f09SDavid van Moolenbroek </question> 803*00b67f09SDavid van Moolenbroek <answer> 804*00b67f09SDavid van Moolenbroek <para> 805*00b67f09SDavid van Moolenbroek Someone is trying to update your DNS data using the RFC2136 806*00b67f09SDavid van Moolenbroek Dynamic Update protocol. Windows 2000 machines have a habit 807*00b67f09SDavid van Moolenbroek of sending dynamic update requests to DNS servers without 808*00b67f09SDavid van Moolenbroek being specifically configured to do so. If the update 809*00b67f09SDavid van Moolenbroek requests are coming from a Windows 2000 machine, see 810*00b67f09SDavid van Moolenbroek <ulink 811*00b67f09SDavid van Moolenbroek url="http://support.microsoft.com/support/kb/articles/q246/8/04.asp"> 812*00b67f09SDavid van Moolenbroek <http://support.microsoft.com/support/kb/articles/q246/8/04.asp></ulink> 813*00b67f09SDavid van Moolenbroek for information about how to turn them off. 814*00b67f09SDavid van Moolenbroek </para> 815*00b67f09SDavid van Moolenbroek </answer> 816*00b67f09SDavid van Moolenbroek </qandaentry> 817*00b67f09SDavid van Moolenbroek 818*00b67f09SDavid van Moolenbroek <qandaentry> 819*00b67f09SDavid van Moolenbroek <question> 820*00b67f09SDavid van Moolenbroek <para> 821*00b67f09SDavid van Moolenbroek When I do a "dig . ns", many of the A records for the root 822*00b67f09SDavid van Moolenbroek servers are missing. Why? 823*00b67f09SDavid van Moolenbroek </para> 824*00b67f09SDavid van Moolenbroek </question> 825*00b67f09SDavid van Moolenbroek <answer> 826*00b67f09SDavid van Moolenbroek <para> 827*00b67f09SDavid van Moolenbroek This is normal and harmless. It is a somewhat confusing 828*00b67f09SDavid van Moolenbroek side effect of the way BIND 9 does RFC2181 trust ranking 829*00b67f09SDavid van Moolenbroek and of the efforts BIND 9 makes to avoid promoting glue 830*00b67f09SDavid van Moolenbroek into answers. 831*00b67f09SDavid van Moolenbroek </para> 832*00b67f09SDavid van Moolenbroek <para> 833*00b67f09SDavid van Moolenbroek When BIND 9 first starts up and primes its cache, it receives 834*00b67f09SDavid van Moolenbroek the root server addresses as additional data in an authoritative 835*00b67f09SDavid van Moolenbroek response from a root server, and these records are eligible 836*00b67f09SDavid van Moolenbroek for inclusion as additional data in responses. Subsequently 837*00b67f09SDavid van Moolenbroek it receives a subset of the root server addresses as 838*00b67f09SDavid van Moolenbroek additional data in a non-authoritative (referral) response 839*00b67f09SDavid van Moolenbroek from a root server. This causes the addresses to now be 840*00b67f09SDavid van Moolenbroek considered non-authoritative (glue) data, which is not 841*00b67f09SDavid van Moolenbroek eligible for inclusion in responses. 842*00b67f09SDavid van Moolenbroek </para> 843*00b67f09SDavid van Moolenbroek <para> 844*00b67f09SDavid van Moolenbroek The server does have a complete set of root server addresses 845*00b67f09SDavid van Moolenbroek cached at all times, it just may not include all of them 846*00b67f09SDavid van Moolenbroek as additional data, depending on whether they were last 847*00b67f09SDavid van Moolenbroek received as answers or as glue. You can always look up the 848*00b67f09SDavid van Moolenbroek addresses with explicit queries like "dig a.root-servers.net A". 849*00b67f09SDavid van Moolenbroek </para> 850*00b67f09SDavid van Moolenbroek </answer> 851*00b67f09SDavid van Moolenbroek </qandaentry> 852*00b67f09SDavid van Moolenbroek 853*00b67f09SDavid van Moolenbroek <qandaentry> 854*00b67f09SDavid van Moolenbroek <question> 855*00b67f09SDavid van Moolenbroek <para> 856*00b67f09SDavid van Moolenbroek Why don't my zones reload when I do an "rndc reload" or SIGHUP? 857*00b67f09SDavid van Moolenbroek </para> 858*00b67f09SDavid van Moolenbroek </question> 859*00b67f09SDavid van Moolenbroek <answer> 860*00b67f09SDavid van Moolenbroek <para> 861*00b67f09SDavid van Moolenbroek A zone can be updated either by editing zone files and 862*00b67f09SDavid van Moolenbroek reloading the server or by dynamic update, but not both. 863*00b67f09SDavid van Moolenbroek If you have enabled dynamic update for a zone using the 864*00b67f09SDavid van Moolenbroek "allow-update" option, you are not supposed to edit the 865*00b67f09SDavid van Moolenbroek zone file by hand, and the server will not attempt to reload 866*00b67f09SDavid van Moolenbroek it. 867*00b67f09SDavid van Moolenbroek </para> 868*00b67f09SDavid van Moolenbroek </answer> 869*00b67f09SDavid van Moolenbroek </qandaentry> 870*00b67f09SDavid van Moolenbroek 871*00b67f09SDavid van Moolenbroek <qandaentry> 872*00b67f09SDavid van Moolenbroek <question> 873*00b67f09SDavid van Moolenbroek <para> 874*00b67f09SDavid van Moolenbroek Why is named listening on UDP port other than 53? 875*00b67f09SDavid van Moolenbroek </para> 876*00b67f09SDavid van Moolenbroek </question> 877*00b67f09SDavid van Moolenbroek <answer> 878*00b67f09SDavid van Moolenbroek <para> 879*00b67f09SDavid van Moolenbroek Named uses a system selected port to make queries of other 880*00b67f09SDavid van Moolenbroek nameservers. This behaviour can be overridden by using 881*00b67f09SDavid van Moolenbroek query-source to lock down the port and/or address. See 882*00b67f09SDavid van Moolenbroek also notify-source and transfer-source. 883*00b67f09SDavid van Moolenbroek </para> 884*00b67f09SDavid van Moolenbroek </answer> 885*00b67f09SDavid van Moolenbroek </qandaentry> 886*00b67f09SDavid van Moolenbroek 887*00b67f09SDavid van Moolenbroek <qandaentry> 888*00b67f09SDavid van Moolenbroek <question> 889*00b67f09SDavid van Moolenbroek <para> 890*00b67f09SDavid van Moolenbroek I get warning messages like <quote>zone example.com/IN: refresh: 891*00b67f09SDavid van Moolenbroek failure trying master 1.2.3.4#53: timed out</quote>. 892*00b67f09SDavid van Moolenbroek </para> 893*00b67f09SDavid van Moolenbroek </question> 894*00b67f09SDavid van Moolenbroek <answer> 895*00b67f09SDavid van Moolenbroek <para> 896*00b67f09SDavid van Moolenbroek Check that you can make UDP queries from the slave to the master 897*00b67f09SDavid van Moolenbroek </para> 898*00b67f09SDavid van Moolenbroek <informalexample> 899*00b67f09SDavid van Moolenbroek <programlisting> 900*00b67f09SDavid van Moolenbroekdig +norec example.com soa @1.2.3.4</programlisting> 901*00b67f09SDavid van Moolenbroek </informalexample> 902*00b67f09SDavid van Moolenbroek <para> 903*00b67f09SDavid van Moolenbroek You could be generating queries faster than the slave can 904*00b67f09SDavid van Moolenbroek cope with. Lower the serial query rate. 905*00b67f09SDavid van Moolenbroek </para> 906*00b67f09SDavid van Moolenbroek <informalexample> 907*00b67f09SDavid van Moolenbroek <programlisting> 908*00b67f09SDavid van Moolenbroekserial-query-rate 5; // default 20</programlisting> 909*00b67f09SDavid van Moolenbroek </informalexample> 910*00b67f09SDavid van Moolenbroek </answer> 911*00b67f09SDavid van Moolenbroek </qandaentry> 912*00b67f09SDavid van Moolenbroek 913*00b67f09SDavid van Moolenbroek <qandaentry> 914*00b67f09SDavid van Moolenbroek <question> 915*00b67f09SDavid van Moolenbroek <para> 916*00b67f09SDavid van Moolenbroek I don't get RRSIG's returned when I use "dig +dnssec". 917*00b67f09SDavid van Moolenbroek </para> 918*00b67f09SDavid van Moolenbroek </question> 919*00b67f09SDavid van Moolenbroek <answer> 920*00b67f09SDavid van Moolenbroek <para> 921*00b67f09SDavid van Moolenbroek You need to ensure DNSSEC is enabled (dnssec-enable yes;). 922*00b67f09SDavid van Moolenbroek </para> 923*00b67f09SDavid van Moolenbroek </answer> 924*00b67f09SDavid van Moolenbroek </qandaentry> 925*00b67f09SDavid van Moolenbroek 926*00b67f09SDavid van Moolenbroek <qandaentry> 927*00b67f09SDavid van Moolenbroek <question> 928*00b67f09SDavid van Moolenbroek <para> 929*00b67f09SDavid van Moolenbroek Can a NS record refer to a CNAME. 930*00b67f09SDavid van Moolenbroek </para> 931*00b67f09SDavid van Moolenbroek </question> 932*00b67f09SDavid van Moolenbroek <answer> 933*00b67f09SDavid van Moolenbroek <para> 934*00b67f09SDavid van Moolenbroek No. The rules for glue (copies of the *address* records 935*00b67f09SDavid van Moolenbroek in the parent zones) and additional section processing do 936*00b67f09SDavid van Moolenbroek not allow it to work. 937*00b67f09SDavid van Moolenbroek </para> 938*00b67f09SDavid van Moolenbroek <para> 939*00b67f09SDavid van Moolenbroek You would have to add both the CNAME and address records 940*00b67f09SDavid van Moolenbroek (A/AAAA) as glue to the parent zone and have CNAMEs be 941*00b67f09SDavid van Moolenbroek followed when doing additional section processing to make 942*00b67f09SDavid van Moolenbroek it work. No nameserver implementation supports either of 943*00b67f09SDavid van Moolenbroek these requirements. 944*00b67f09SDavid van Moolenbroek </para> 945*00b67f09SDavid van Moolenbroek </answer> 946*00b67f09SDavid van Moolenbroek </qandaentry> 947*00b67f09SDavid van Moolenbroek 948*00b67f09SDavid van Moolenbroek <qandaentry> 949*00b67f09SDavid van Moolenbroek <question> 950*00b67f09SDavid van Moolenbroek <para> 951*00b67f09SDavid van Moolenbroek What does <quote>RFC 1918 response from Internet for 952*00b67f09SDavid van Moolenbroek 0.0.0.10.IN-ADDR.ARPA</quote> mean? 953*00b67f09SDavid van Moolenbroek </para> 954*00b67f09SDavid van Moolenbroek </question> 955*00b67f09SDavid van Moolenbroek <answer> 956*00b67f09SDavid van Moolenbroek <para> 957*00b67f09SDavid van Moolenbroek If the IN-ADDR.ARPA name covered refers to a internal address 958*00b67f09SDavid van Moolenbroek space you are using then you have failed to follow RFC 1918 959*00b67f09SDavid van Moolenbroek usage rules and are leaking queries to the Internet. You 960*00b67f09SDavid van Moolenbroek should establish your own zones for these addresses to prevent 961*00b67f09SDavid van Moolenbroek you querying the Internet's name servers for these addresses. 962*00b67f09SDavid van Moolenbroek Please see <ulink url="http://as112.net/"><http://as112.net/></ulink> 963*00b67f09SDavid van Moolenbroek for details of the problems you are causing and the counter 964*00b67f09SDavid van Moolenbroek measures that have had to be deployed. 965*00b67f09SDavid van Moolenbroek </para> 966*00b67f09SDavid van Moolenbroek <para> 967*00b67f09SDavid van Moolenbroek If you are not using these private addresses then a client 968*00b67f09SDavid van Moolenbroek has queried for them. You can just ignore the messages, 969*00b67f09SDavid van Moolenbroek get the offending client to stop sending you these messages 970*00b67f09SDavid van Moolenbroek as they are most probably leaking them or setup your own zones 971*00b67f09SDavid van Moolenbroek empty zones to serve answers to these queries. 972*00b67f09SDavid van Moolenbroek </para> 973*00b67f09SDavid van Moolenbroek <informalexample> 974*00b67f09SDavid van Moolenbroek <programlisting> 975*00b67f09SDavid van Moolenbroekzone "10.IN-ADDR.ARPA" { 976*00b67f09SDavid van Moolenbroek type master; 977*00b67f09SDavid van Moolenbroek file "empty"; 978*00b67f09SDavid van Moolenbroek}; 979*00b67f09SDavid van Moolenbroek 980*00b67f09SDavid van Moolenbroekzone "16.172.IN-ADDR.ARPA" { 981*00b67f09SDavid van Moolenbroek type master; 982*00b67f09SDavid van Moolenbroek file "empty"; 983*00b67f09SDavid van Moolenbroek}; 984*00b67f09SDavid van Moolenbroek 985*00b67f09SDavid van Moolenbroek... 986*00b67f09SDavid van Moolenbroek 987*00b67f09SDavid van Moolenbroekzone "31.172.IN-ADDR.ARPA" { 988*00b67f09SDavid van Moolenbroek type master; 989*00b67f09SDavid van Moolenbroek file "empty"; 990*00b67f09SDavid van Moolenbroek}; 991*00b67f09SDavid van Moolenbroek 992*00b67f09SDavid van Moolenbroekzone "168.192.IN-ADDR.ARPA" { 993*00b67f09SDavid van Moolenbroek type master; 994*00b67f09SDavid van Moolenbroek file "empty"; 995*00b67f09SDavid van Moolenbroek}; 996*00b67f09SDavid van Moolenbroek 997*00b67f09SDavid van Moolenbroekempty: 998*00b67f09SDavid van Moolenbroek@ 10800 IN SOA <name-of-server>. <contact-email>. ( 999*00b67f09SDavid van Moolenbroek 1 3600 1200 604800 10800 ) 1000*00b67f09SDavid van Moolenbroek@ 10800 IN NS <name-of-server>.</programlisting> 1001*00b67f09SDavid van Moolenbroek </informalexample> 1002*00b67f09SDavid van Moolenbroek <para> 1003*00b67f09SDavid van Moolenbroek <note> 1004*00b67f09SDavid van Moolenbroek Future versions of named are likely to do this automatically. 1005*00b67f09SDavid van Moolenbroek </note> 1006*00b67f09SDavid van Moolenbroek </para> 1007*00b67f09SDavid van Moolenbroek </answer> 1008*00b67f09SDavid van Moolenbroek </qandaentry> 1009*00b67f09SDavid van Moolenbroek 1010*00b67f09SDavid van Moolenbroek <qandaentry> 1011*00b67f09SDavid van Moolenbroek <question> 1012*00b67f09SDavid van Moolenbroek <para> 1013*00b67f09SDavid van Moolenbroek Will named be affected by the 2007 changes to daylight savings 1014*00b67f09SDavid van Moolenbroek rules in the US. 1015*00b67f09SDavid van Moolenbroek </para> 1016*00b67f09SDavid van Moolenbroek </question> 1017*00b67f09SDavid van Moolenbroek <answer> 1018*00b67f09SDavid van Moolenbroek <para> 1019*00b67f09SDavid van Moolenbroek No, so long as the machines internal clock (as reported 1020*00b67f09SDavid van Moolenbroek by "date -u") remains at UTC. The only visible change 1021*00b67f09SDavid van Moolenbroek if you fail to upgrade your OS, if you are in a affected 1022*00b67f09SDavid van Moolenbroek area, will be that log messages will be a hour out during 1023*00b67f09SDavid van Moolenbroek the period where the old rules do not match the new rules. 1024*00b67f09SDavid van Moolenbroek </para> 1025*00b67f09SDavid van Moolenbroek <para> 1026*00b67f09SDavid van Moolenbroek For most OS's this change just means that you need to 1027*00b67f09SDavid van Moolenbroek update the conversion rules from UTC to local time. 1028*00b67f09SDavid van Moolenbroek Normally this involves updating a file in /etc (which 1029*00b67f09SDavid van Moolenbroek sets the default timezone for the machine) and possibly 1030*00b67f09SDavid van Moolenbroek a directory which has all the conversion rules for the 1031*00b67f09SDavid van Moolenbroek world (e.g. /usr/share/zoneinfo). When updating the OS 1032*00b67f09SDavid van Moolenbroek do not forget to update any chroot areas as well. 1033*00b67f09SDavid van Moolenbroek See your OS's documentation for more details. 1034*00b67f09SDavid van Moolenbroek </para> 1035*00b67f09SDavid van Moolenbroek <para> 1036*00b67f09SDavid van Moolenbroek The local timezone conversion rules can also be done on 1037*00b67f09SDavid van Moolenbroek a individual basis by setting the TZ environment variable 1038*00b67f09SDavid van Moolenbroek appropriately. See your OS's documentation for more 1039*00b67f09SDavid van Moolenbroek details. 1040*00b67f09SDavid van Moolenbroek </para> 1041*00b67f09SDavid van Moolenbroek </answer> 1042*00b67f09SDavid van Moolenbroek </qandaentry> 1043*00b67f09SDavid van Moolenbroek 1044*00b67f09SDavid van Moolenbroek <qandaentry> 1045*00b67f09SDavid van Moolenbroek <question> 1046*00b67f09SDavid van Moolenbroek <para> 1047*00b67f09SDavid van Moolenbroek Is there a bugzilla (or other tool) database that mere 1048*00b67f09SDavid van Moolenbroek mortals can have (read-only) access to for bind? 1049*00b67f09SDavid van Moolenbroek </para> 1050*00b67f09SDavid van Moolenbroek </question> 1051*00b67f09SDavid van Moolenbroek <answer> 1052*00b67f09SDavid van Moolenbroek <para> 1053*00b67f09SDavid van Moolenbroek No. The BIND 9 bug database is kept closed for a number 1054*00b67f09SDavid van Moolenbroek of reasons. These include, but are not limited to, that 1055*00b67f09SDavid van Moolenbroek the database contains proprietory information from people 1056*00b67f09SDavid van Moolenbroek reporting bugs. The database has in the past and may in 1057*00b67f09SDavid van Moolenbroek future contain unfixed bugs which are capable of bringing 1058*00b67f09SDavid van Moolenbroek down most of the Internet's DNS infrastructure. 1059*00b67f09SDavid van Moolenbroek </para> 1060*00b67f09SDavid van Moolenbroek <para> 1061*00b67f09SDavid van Moolenbroek The release pages for each version contain up to date 1062*00b67f09SDavid van Moolenbroek lists of bugs that have been fixed post release. That 1063*00b67f09SDavid van Moolenbroek is as close as we can get to providing a bug database. 1064*00b67f09SDavid van Moolenbroek </para> 1065*00b67f09SDavid van Moolenbroek </answer> 1066*00b67f09SDavid van Moolenbroek </qandaentry> 1067*00b67f09SDavid van Moolenbroek 1068*00b67f09SDavid van Moolenbroek <qandaentry> 1069*00b67f09SDavid van Moolenbroek <question> 1070*00b67f09SDavid van Moolenbroek <para> 1071*00b67f09SDavid van Moolenbroek Why do queries for NSEC3 records fail to return the NSEC3 record? 1072*00b67f09SDavid van Moolenbroek </para> 1073*00b67f09SDavid van Moolenbroek </question> 1074*00b67f09SDavid van Moolenbroek <answer> 1075*00b67f09SDavid van Moolenbroek <para> 1076*00b67f09SDavid van Moolenbroek NSEC3 records are strictly meta data and can only be 1077*00b67f09SDavid van Moolenbroek returned in the authority section. This is done so that 1078*00b67f09SDavid van Moolenbroek signing the zone using NSEC3 records does not bring names 1079*00b67f09SDavid van Moolenbroek into existence that do not exist in the unsigned version 1080*00b67f09SDavid van Moolenbroek of the zone. 1081*00b67f09SDavid van Moolenbroek </para> 1082*00b67f09SDavid van Moolenbroek </answer> 1083*00b67f09SDavid van Moolenbroek </qandaentry> 1084*00b67f09SDavid van Moolenbroek 1085*00b67f09SDavid van Moolenbroek </qandadiv> <!-- General Questions --> 1086*00b67f09SDavid van Moolenbroek 1087*00b67f09SDavid van Moolenbroek <qandadiv><title>Operating-System Specific Questions</title> 1088*00b67f09SDavid van Moolenbroek 1089*00b67f09SDavid van Moolenbroek <qandadiv><title>HPUX</title> 1090*00b67f09SDavid van Moolenbroek 1091*00b67f09SDavid van Moolenbroek <qandaentry> 1092*00b67f09SDavid van Moolenbroek <question> 1093*00b67f09SDavid van Moolenbroek <para>I get the following error trying to configure BIND: 1094*00b67f09SDavid van Moolenbroek<programlisting>checking if unistd.h or sys/types.h defines fd_set... no 1095*00b67f09SDavid van Moolenbroekconfigure: error: need either working unistd.h or sys/select.h</programlisting> 1096*00b67f09SDavid van Moolenbroek </para> 1097*00b67f09SDavid van Moolenbroek </question> 1098*00b67f09SDavid van Moolenbroek <answer> 1099*00b67f09SDavid van Moolenbroek <para> 1100*00b67f09SDavid van Moolenbroek You have attempted to configure BIND with the bundled C compiler. 1101*00b67f09SDavid van Moolenbroek This compiler does not meet the minimum compiler requirements to 1102*00b67f09SDavid van Moolenbroek for building BIND. You need to install a ANSI C compiler and / or 1103*00b67f09SDavid van Moolenbroek teach configure how to find the ANSI C compiler. The later can 1104*00b67f09SDavid van Moolenbroek be done by adjusting the PATH environment variable and / or 1105*00b67f09SDavid van Moolenbroek specifying the compiler via CC. 1106*00b67f09SDavid van Moolenbroek </para> 1107*00b67f09SDavid van Moolenbroek <informalexample> 1108*00b67f09SDavid van Moolenbroek <programlisting>./configure CC=<compiler> ...</programlisting> 1109*00b67f09SDavid van Moolenbroek </informalexample> 1110*00b67f09SDavid van Moolenbroek </answer> 1111*00b67f09SDavid van Moolenbroek </qandaentry> 1112*00b67f09SDavid van Moolenbroek 1113*00b67f09SDavid van Moolenbroek </qandadiv> <!-- HPUX --> 1114*00b67f09SDavid van Moolenbroek 1115*00b67f09SDavid van Moolenbroek <qandadiv><title>Linux</title> 1116*00b67f09SDavid van Moolenbroek 1117*00b67f09SDavid van Moolenbroek <qandaentry> 1118*00b67f09SDavid van Moolenbroek <question> 1119*00b67f09SDavid van Moolenbroek <para> 1120*00b67f09SDavid van Moolenbroek Why do I get the following errors: 1121*00b67f09SDavid van Moolenbroek<programlisting>general: errno2result.c:109: unexpected error: 1122*00b67f09SDavid van Moolenbroekgeneral: unable to convert errno to isc_result: 14: Bad address 1123*00b67f09SDavid van Moolenbroekclient: UDP client handler shutting down due to fatal receive error: unexpected error</programlisting> 1124*00b67f09SDavid van Moolenbroek </para> 1125*00b67f09SDavid van Moolenbroek </question> 1126*00b67f09SDavid van Moolenbroek <answer> 1127*00b67f09SDavid van Moolenbroek <para> 1128*00b67f09SDavid van Moolenbroek This is the result of a Linux kernel bug. 1129*00b67f09SDavid van Moolenbroek </para> 1130*00b67f09SDavid van Moolenbroek <para> 1131*00b67f09SDavid van Moolenbroek See: 1132*00b67f09SDavid van Moolenbroek <ulink url="http://marc.theaimsgroup.com/?l=linux-netdev&m=113081708031466&w=2"><http://marc.theaimsgroup.com/?l=linux-netdev&m=113081708031466&w=2></ulink> 1133*00b67f09SDavid van Moolenbroek </para> 1134*00b67f09SDavid van Moolenbroek </answer> 1135*00b67f09SDavid van Moolenbroek </qandaentry> 1136*00b67f09SDavid van Moolenbroek 1137*00b67f09SDavid van Moolenbroek <qandaentry> 1138*00b67f09SDavid van Moolenbroek <question> 1139*00b67f09SDavid van Moolenbroek <para> 1140*00b67f09SDavid van Moolenbroek Why does named lock up when it attempts to connect over IPSEC tunnels? 1141*00b67f09SDavid van Moolenbroek </para> 1142*00b67f09SDavid van Moolenbroek </question> 1143*00b67f09SDavid van Moolenbroek <answer> 1144*00b67f09SDavid van Moolenbroek <para> 1145*00b67f09SDavid van Moolenbroek This is due to a kernel bug where the fact that a socket is marked 1146*00b67f09SDavid van Moolenbroek non-blocking is ignored. It is reported that setting 1147*00b67f09SDavid van Moolenbroek xfrm_larval_drop to 1 helps but this may have negative side effects. 1148*00b67f09SDavid van Moolenbroek See: 1149*00b67f09SDavid van Moolenbroek<ulink url="https://bugzilla.redhat.com/show_bug.cgi?id=427629"><https://bugzilla.redhat.com/show_bug.cgi?id=427629></ulink> 1150*00b67f09SDavid van Moolenbroek and 1151*00b67f09SDavid van Moolenbroek<ulink url="http://lkml.org/lkml/2007/12/4/260"><http://lkml.org/lkml/2007/12/4/260></ulink>. 1152*00b67f09SDavid van Moolenbroek </para> 1153*00b67f09SDavid van Moolenbroek <para> 1154*00b67f09SDavid van Moolenbroek xfrm_larval_drop can be set to 1 by the following procedure: 1155*00b67f09SDavid van Moolenbroek<programlisting> 1156*00b67f09SDavid van Moolenbroekecho "1" > proc/sys/net/core/xfrm_larval_drop</programlisting> 1157*00b67f09SDavid van Moolenbroek </para> 1158*00b67f09SDavid van Moolenbroek </answer> 1159*00b67f09SDavid van Moolenbroek </qandaentry> 1160*00b67f09SDavid van Moolenbroek 1161*00b67f09SDavid van Moolenbroek <qandaentry> 1162*00b67f09SDavid van Moolenbroek <question> 1163*00b67f09SDavid van Moolenbroek <para> 1164*00b67f09SDavid van Moolenbroek Why do I see 5 (or more) copies of named on Linux? 1165*00b67f09SDavid van Moolenbroek </para> 1166*00b67f09SDavid van Moolenbroek </question> 1167*00b67f09SDavid van Moolenbroek <answer> 1168*00b67f09SDavid van Moolenbroek <para> 1169*00b67f09SDavid van Moolenbroek Linux threads each show up as a process under ps. The 1170*00b67f09SDavid van Moolenbroek approximate number of threads running is n+4, where n is 1171*00b67f09SDavid van Moolenbroek the number of CPUs. Note that the amount of memory used 1172*00b67f09SDavid van Moolenbroek is not cumulative; if each process is using 10M of memory, 1173*00b67f09SDavid van Moolenbroek only a total of 10M is used. 1174*00b67f09SDavid van Moolenbroek </para> 1175*00b67f09SDavid van Moolenbroek <para> 1176*00b67f09SDavid van Moolenbroek Newer versions of Linux's ps command hide the individual threads 1177*00b67f09SDavid van Moolenbroek and require -L to display them. 1178*00b67f09SDavid van Moolenbroek </para> 1179*00b67f09SDavid van Moolenbroek </answer> 1180*00b67f09SDavid van Moolenbroek </qandaentry> 1181*00b67f09SDavid van Moolenbroek 1182*00b67f09SDavid van Moolenbroek <qandaentry> 1183*00b67f09SDavid van Moolenbroek <question> 1184*00b67f09SDavid van Moolenbroek <para> 1185*00b67f09SDavid van Moolenbroek Why does BIND 9 log <quote>permission denied</quote> errors accessing 1186*00b67f09SDavid van Moolenbroek its configuration files or zones on my Linux system even 1187*00b67f09SDavid van Moolenbroek though it is running as root? 1188*00b67f09SDavid van Moolenbroek </para> 1189*00b67f09SDavid van Moolenbroek </question> 1190*00b67f09SDavid van Moolenbroek <answer> 1191*00b67f09SDavid van Moolenbroek <para> 1192*00b67f09SDavid van Moolenbroek On Linux, BIND 9 drops most of its root privileges on 1193*00b67f09SDavid van Moolenbroek startup. This including the privilege to open files owned 1194*00b67f09SDavid van Moolenbroek by other users. Therefore, if the server is running as 1195*00b67f09SDavid van Moolenbroek root, the configuration files and zone files should also 1196*00b67f09SDavid van Moolenbroek be owned by root. 1197*00b67f09SDavid van Moolenbroek </para> 1198*00b67f09SDavid van Moolenbroek </answer> 1199*00b67f09SDavid van Moolenbroek </qandaentry> 1200*00b67f09SDavid van Moolenbroek 1201*00b67f09SDavid van Moolenbroek <qandaentry> 1202*00b67f09SDavid van Moolenbroek <question> 1203*00b67f09SDavid van Moolenbroek <para> 1204*00b67f09SDavid van Moolenbroek I get the error message <quote>named: capset failed: Operation 1205*00b67f09SDavid van Moolenbroek not permitted</quote> when starting named. 1206*00b67f09SDavid van Moolenbroek </para> 1207*00b67f09SDavid van Moolenbroek </question> 1208*00b67f09SDavid van Moolenbroek <answer> 1209*00b67f09SDavid van Moolenbroek <para> 1210*00b67f09SDavid van Moolenbroek The capability module, part of "Linux Security Modules/LSM", 1211*00b67f09SDavid van Moolenbroek has not been loaded into the kernel. See insmod(8), modprobe(8). 1212*00b67f09SDavid van Moolenbroek </para> 1213*00b67f09SDavid van Moolenbroek <para> 1214*00b67f09SDavid van Moolenbroek The relevant modules can be loaded by running: 1215*00b67f09SDavid van Moolenbroek<programlisting> 1216*00b67f09SDavid van Moolenbroekmodprobe commoncap 1217*00b67f09SDavid van Moolenbroekmodprobe capability</programlisting> 1218*00b67f09SDavid van Moolenbroek </para> 1219*00b67f09SDavid van Moolenbroek </answer> 1220*00b67f09SDavid van Moolenbroek </qandaentry> 1221*00b67f09SDavid van Moolenbroek 1222*00b67f09SDavid van Moolenbroek <qandaentry> 1223*00b67f09SDavid van Moolenbroek <question> 1224*00b67f09SDavid van Moolenbroek <para> 1225*00b67f09SDavid van Moolenbroek I'm running BIND on Red Hat Enterprise Linux or Fedora Core - 1226*00b67f09SDavid van Moolenbroek </para> 1227*00b67f09SDavid van Moolenbroek <para> 1228*00b67f09SDavid van Moolenbroek Why can't named update slave zone database files? 1229*00b67f09SDavid van Moolenbroek </para> 1230*00b67f09SDavid van Moolenbroek <para> 1231*00b67f09SDavid van Moolenbroek Why can't named create DDNS journal files or update 1232*00b67f09SDavid van Moolenbroek the master zones from journals? 1233*00b67f09SDavid van Moolenbroek </para> 1234*00b67f09SDavid van Moolenbroek <para> 1235*00b67f09SDavid van Moolenbroek Why can't named create custom log files? 1236*00b67f09SDavid van Moolenbroek </para> 1237*00b67f09SDavid van Moolenbroek </question> 1238*00b67f09SDavid van Moolenbroek 1239*00b67f09SDavid van Moolenbroek <answer> 1240*00b67f09SDavid van Moolenbroek <para> 1241*00b67f09SDavid van Moolenbroek Red Hat Security Enhanced Linux (SELinux) policy security 1242*00b67f09SDavid van Moolenbroek protections : 1243*00b67f09SDavid van Moolenbroek </para> 1244*00b67f09SDavid van Moolenbroek 1245*00b67f09SDavid van Moolenbroek <para> 1246*00b67f09SDavid van Moolenbroek Red Hat have adopted the National Security Agency's 1247*00b67f09SDavid van Moolenbroek SELinux security policy (see <ulink 1248*00b67f09SDavid van Moolenbroek url="http://www.nsa.gov/selinux"><http://www.nsa.gov/selinux></ulink>) 1249*00b67f09SDavid van Moolenbroek and recommendations for BIND security , which are more 1250*00b67f09SDavid van Moolenbroek secure than running named in a chroot and make use of 1251*00b67f09SDavid van Moolenbroek the bind-chroot environment unnecessary . 1252*00b67f09SDavid van Moolenbroek </para> 1253*00b67f09SDavid van Moolenbroek 1254*00b67f09SDavid van Moolenbroek <para> 1255*00b67f09SDavid van Moolenbroek By default, named is not allowed by the SELinux policy 1256*00b67f09SDavid van Moolenbroek to write, create or delete any files EXCEPT in these 1257*00b67f09SDavid van Moolenbroek directories: 1258*00b67f09SDavid van Moolenbroek <informalexample> 1259*00b67f09SDavid van Moolenbroek <programlisting> 1260*00b67f09SDavid van Moolenbroek$ROOTDIR/var/named/slaves 1261*00b67f09SDavid van Moolenbroek$ROOTDIR/var/named/data 1262*00b67f09SDavid van Moolenbroek$ROOTDIR/var/tmp 1263*00b67f09SDavid van Moolenbroek </programlisting> 1264*00b67f09SDavid van Moolenbroek </informalexample> 1265*00b67f09SDavid van Moolenbroek where $ROOTDIR may be set in /etc/sysconfig/named if 1266*00b67f09SDavid van Moolenbroek bind-chroot is installed. 1267*00b67f09SDavid van Moolenbroek </para> 1268*00b67f09SDavid van Moolenbroek 1269*00b67f09SDavid van Moolenbroek <para> 1270*00b67f09SDavid van Moolenbroek The SELinux policy particularly does NOT allow named to modify 1271*00b67f09SDavid van Moolenbroek the $ROOTDIR/var/named directory, the default location for master 1272*00b67f09SDavid van Moolenbroek zone database files. 1273*00b67f09SDavid van Moolenbroek </para> 1274*00b67f09SDavid van Moolenbroek 1275*00b67f09SDavid van Moolenbroek <para> 1276*00b67f09SDavid van Moolenbroek SELinux policy overrules file access permissions - so 1277*00b67f09SDavid van Moolenbroek even if all the files under /var/named have ownership 1278*00b67f09SDavid van Moolenbroek named:named and mode rw-rw-r--, named will still not be 1279*00b67f09SDavid van Moolenbroek able to write or create files except in the directories 1280*00b67f09SDavid van Moolenbroek above, with SELinux in Enforcing mode. 1281*00b67f09SDavid van Moolenbroek </para> 1282*00b67f09SDavid van Moolenbroek 1283*00b67f09SDavid van Moolenbroek <para> 1284*00b67f09SDavid van Moolenbroek So, to allow named to update slave or DDNS zone files, 1285*00b67f09SDavid van Moolenbroek it is best to locate them in $ROOTDIR/var/named/slaves, 1286*00b67f09SDavid van Moolenbroek with named.conf zone statements such as: 1287*00b67f09SDavid van Moolenbroek <informalexample> 1288*00b67f09SDavid van Moolenbroek <programlisting> 1289*00b67f09SDavid van Moolenbroekzone "slave.zone." IN { 1290*00b67f09SDavid van Moolenbroek type slave; 1291*00b67f09SDavid van Moolenbroek file "slaves/slave.zone.db"; 1292*00b67f09SDavid van Moolenbroek ... 1293*00b67f09SDavid van Moolenbroek}; 1294*00b67f09SDavid van Moolenbroekzone "ddns.zone." IN { 1295*00b67f09SDavid van Moolenbroek type master; 1296*00b67f09SDavid van Moolenbroek allow-updates {...}; 1297*00b67f09SDavid van Moolenbroek file "slaves/ddns.zone.db"; 1298*00b67f09SDavid van Moolenbroek}; 1299*00b67f09SDavid van Moolenbroek </programlisting> 1300*00b67f09SDavid van Moolenbroek </informalexample> 1301*00b67f09SDavid van Moolenbroek </para> 1302*00b67f09SDavid van Moolenbroek 1303*00b67f09SDavid van Moolenbroek <para> 1304*00b67f09SDavid van Moolenbroek To allow named to create its cache dump and statistics 1305*00b67f09SDavid van Moolenbroek files, for example, you could use named.conf options 1306*00b67f09SDavid van Moolenbroek statements such as: 1307*00b67f09SDavid van Moolenbroek <informalexample> 1308*00b67f09SDavid van Moolenbroek <programlisting> 1309*00b67f09SDavid van Moolenbroekoptions { 1310*00b67f09SDavid van Moolenbroek ... 1311*00b67f09SDavid van Moolenbroek dump-file "/var/named/data/cache_dump.db"; 1312*00b67f09SDavid van Moolenbroek statistics-file "/var/named/data/named_stats.txt"; 1313*00b67f09SDavid van Moolenbroek ... 1314*00b67f09SDavid van Moolenbroek}; 1315*00b67f09SDavid van Moolenbroek </programlisting> 1316*00b67f09SDavid van Moolenbroek </informalexample> 1317*00b67f09SDavid van Moolenbroek </para> 1318*00b67f09SDavid van Moolenbroek 1319*00b67f09SDavid van Moolenbroek <para> 1320*00b67f09SDavid van Moolenbroek You can also tell SELinux to allow named to update any 1321*00b67f09SDavid van Moolenbroek zone database files, by setting the SELinux tunable boolean 1322*00b67f09SDavid van Moolenbroek parameter 'named_write_master_zones=1', using the 1323*00b67f09SDavid van Moolenbroek system-config-securitylevel GUI, using the 'setsebool' 1324*00b67f09SDavid van Moolenbroek command, or in /etc/selinux/targeted/booleans. 1325*00b67f09SDavid van Moolenbroek </para> 1326*00b67f09SDavid van Moolenbroek 1327*00b67f09SDavid van Moolenbroek <para> 1328*00b67f09SDavid van Moolenbroek You can disable SELinux protection for named entirely by 1329*00b67f09SDavid van Moolenbroek setting the 'named_disable_trans=1' SELinux tunable boolean 1330*00b67f09SDavid van Moolenbroek parameter. 1331*00b67f09SDavid van Moolenbroek </para> 1332*00b67f09SDavid van Moolenbroek 1333*00b67f09SDavid van Moolenbroek <para> 1334*00b67f09SDavid van Moolenbroek The SELinux named policy defines these SELinux contexts for named: 1335*00b67f09SDavid van Moolenbroek <informalexample> 1336*00b67f09SDavid van Moolenbroek <programlisting> 1337*00b67f09SDavid van Moolenbroeknamed_zone_t : for zone database files - $ROOTDIR/var/named/* 1338*00b67f09SDavid van Moolenbroeknamed_conf_t : for named configuration files - $ROOTDIR/etc/{named,rndc}.* 1339*00b67f09SDavid van Moolenbroeknamed_cache_t: for files modifiable by named - $ROOTDIR/var/{tmp,named/{slaves,data}} 1340*00b67f09SDavid van Moolenbroek </programlisting> 1341*00b67f09SDavid van Moolenbroek </informalexample> 1342*00b67f09SDavid van Moolenbroek </para> 1343*00b67f09SDavid van Moolenbroek 1344*00b67f09SDavid van Moolenbroek <para> 1345*00b67f09SDavid van Moolenbroek If you want to retain use of the SELinux policy for named, 1346*00b67f09SDavid van Moolenbroek and put named files in different locations, you can do 1347*00b67f09SDavid van Moolenbroek so by changing the context of the custom file locations 1348*00b67f09SDavid van Moolenbroek . 1349*00b67f09SDavid van Moolenbroek </para> 1350*00b67f09SDavid van Moolenbroek 1351*00b67f09SDavid van Moolenbroek <para> 1352*00b67f09SDavid van Moolenbroek To create a custom configuration file location, e.g. 1353*00b67f09SDavid van Moolenbroek '/root/named.conf', to use with the 'named -c' option, 1354*00b67f09SDavid van Moolenbroek do: 1355*00b67f09SDavid van Moolenbroek <informalexample> 1356*00b67f09SDavid van Moolenbroek <programlisting> 1357*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_conf_t /root/named.conf 1358*00b67f09SDavid van Moolenbroek </programlisting> 1359*00b67f09SDavid van Moolenbroek </informalexample> 1360*00b67f09SDavid van Moolenbroek </para> 1361*00b67f09SDavid van Moolenbroek 1362*00b67f09SDavid van Moolenbroek <para> 1363*00b67f09SDavid van Moolenbroek To create a custom modifiable named data location, e.g. 1364*00b67f09SDavid van Moolenbroek '/var/log/named' for a log file, do: 1365*00b67f09SDavid van Moolenbroek <informalexample> 1366*00b67f09SDavid van Moolenbroek <programlisting> 1367*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_cache_t /var/log/named 1368*00b67f09SDavid van Moolenbroek </programlisting> 1369*00b67f09SDavid van Moolenbroek </informalexample> 1370*00b67f09SDavid van Moolenbroek </para> 1371*00b67f09SDavid van Moolenbroek 1372*00b67f09SDavid van Moolenbroek <para> 1373*00b67f09SDavid van Moolenbroek To create a custom zone file location, e.g. /root/zones/, do: 1374*00b67f09SDavid van Moolenbroek <informalexample> 1375*00b67f09SDavid van Moolenbroek <programlisting> 1376*00b67f09SDavid van Moolenbroek# chcon system_u:object_r:named_zone_t /root/zones/{.,*} 1377*00b67f09SDavid van Moolenbroek </programlisting> 1378*00b67f09SDavid van Moolenbroek </informalexample> 1379*00b67f09SDavid van Moolenbroek </para> 1380*00b67f09SDavid van Moolenbroek 1381*00b67f09SDavid van Moolenbroek <para> 1382*00b67f09SDavid van Moolenbroek See these man-pages for more information : selinux(8), 1383*00b67f09SDavid van Moolenbroek named_selinux(8), chcon(1), setsebool(8) 1384*00b67f09SDavid van Moolenbroek </para> 1385*00b67f09SDavid van Moolenbroek </answer> 1386*00b67f09SDavid van Moolenbroek </qandaentry> 1387*00b67f09SDavid van Moolenbroek 1388*00b67f09SDavid van Moolenbroek <qandaentry> 1389*00b67f09SDavid van Moolenbroek <question> 1390*00b67f09SDavid van Moolenbroek <para> 1391*00b67f09SDavid van Moolenbroek I'm running BIND on Ubuntu - 1392*00b67f09SDavid van Moolenbroek </para> 1393*00b67f09SDavid van Moolenbroek <para> 1394*00b67f09SDavid van Moolenbroek Why can't named update slave zone database files? 1395*00b67f09SDavid van Moolenbroek </para> 1396*00b67f09SDavid van Moolenbroek <para> 1397*00b67f09SDavid van Moolenbroek Why can't named create DDNS journal files or update 1398*00b67f09SDavid van Moolenbroek the master zones from journals? 1399*00b67f09SDavid van Moolenbroek </para> 1400*00b67f09SDavid van Moolenbroek <para> 1401*00b67f09SDavid van Moolenbroek Why can't named create custom log files? 1402*00b67f09SDavid van Moolenbroek </para> 1403*00b67f09SDavid van Moolenbroek </question> 1404*00b67f09SDavid van Moolenbroek <answer> 1405*00b67f09SDavid van Moolenbroek <para> 1406*00b67f09SDavid van Moolenbroek Ubuntu uses AppArmor <ulink url="http://en.wikipedia.org/wiki/AppArmor"> 1407*00b67f09SDavid van Moolenbroek <http://en.wikipedia.org/wiki/AppArmor></ulink> in 1408*00b67f09SDavid van Moolenbroek addition to normal file system permissions to protect the system. 1409*00b67f09SDavid van Moolenbroek </para> 1410*00b67f09SDavid van Moolenbroek <para> 1411*00b67f09SDavid van Moolenbroek Adjust the paths to use those specified in /etc/apparmor.d/usr.sbin.named 1412*00b67f09SDavid van Moolenbroek or adjust /etc/apparmor.d/usr.sbin.named to allow named to write at the 1413*00b67f09SDavid van Moolenbroek location specified in named.conf. 1414*00b67f09SDavid van Moolenbroek </para> 1415*00b67f09SDavid van Moolenbroek </answer> 1416*00b67f09SDavid van Moolenbroek </qandaentry> 1417*00b67f09SDavid van Moolenbroek 1418*00b67f09SDavid van Moolenbroek <qandaentry> 1419*00b67f09SDavid van Moolenbroek <question> 1420*00b67f09SDavid van Moolenbroek <para> 1421*00b67f09SDavid van Moolenbroek Listening on individual IPv6 interfaces does not work. 1422*00b67f09SDavid van Moolenbroek </para> 1423*00b67f09SDavid van Moolenbroek </question> 1424*00b67f09SDavid van Moolenbroek <answer> 1425*00b67f09SDavid van Moolenbroek <para> 1426*00b67f09SDavid van Moolenbroek This is usually due to "/proc/net/if_inet6" not being available 1427*00b67f09SDavid van Moolenbroek in the chroot file system. Mount another instance of "proc" 1428*00b67f09SDavid van Moolenbroek in the chroot file system. 1429*00b67f09SDavid van Moolenbroek </para> 1430*00b67f09SDavid van Moolenbroek <para> 1431*00b67f09SDavid van Moolenbroek This can be be made permanent by adding a second instance to 1432*00b67f09SDavid van Moolenbroek /etc/fstab. 1433*00b67f09SDavid van Moolenbroek <informalexample> 1434*00b67f09SDavid van Moolenbroek <programlisting> 1435*00b67f09SDavid van Moolenbroekproc /proc proc defaults 0 0 1436*00b67f09SDavid van Moolenbroekproc /var/named/proc proc defaults 0 0</programlisting> 1437*00b67f09SDavid van Moolenbroek </informalexample> 1438*00b67f09SDavid van Moolenbroek </para> 1439*00b67f09SDavid van Moolenbroek </answer> 1440*00b67f09SDavid van Moolenbroek </qandaentry> 1441*00b67f09SDavid van Moolenbroek 1442*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Linux --> 1443*00b67f09SDavid van Moolenbroek 1444*00b67f09SDavid van Moolenbroek <qandadiv><title>Windows</title> 1445*00b67f09SDavid van Moolenbroek 1446*00b67f09SDavid van Moolenbroek <qandaentry> 1447*00b67f09SDavid van Moolenbroek <question> 1448*00b67f09SDavid van Moolenbroek <para> 1449*00b67f09SDavid van Moolenbroek Zone transfers from my BIND 9 master to my Windows 2000 1450*00b67f09SDavid van Moolenbroek slave fail. Why? 1451*00b67f09SDavid van Moolenbroek </para> 1452*00b67f09SDavid van Moolenbroek </question> 1453*00b67f09SDavid van Moolenbroek <answer> 1454*00b67f09SDavid van Moolenbroek <para> 1455*00b67f09SDavid van Moolenbroek This may be caused by a bug in the Windows 2000 DNS server 1456*00b67f09SDavid van Moolenbroek where DNS messages larger than 16K are not handled properly. 1457*00b67f09SDavid van Moolenbroek This can be worked around by setting the option "transfer-format 1458*00b67f09SDavid van Moolenbroek one-answer;". Also check whether your zone contains domain 1459*00b67f09SDavid van Moolenbroek names with embedded spaces or other special characters, 1460*00b67f09SDavid van Moolenbroek like "John\032Doe\213s\032Computer", since such names have 1461*00b67f09SDavid van Moolenbroek been known to cause Windows 2000 slaves to incorrectly 1462*00b67f09SDavid van Moolenbroek reject the zone. 1463*00b67f09SDavid van Moolenbroek </para> 1464*00b67f09SDavid van Moolenbroek </answer> 1465*00b67f09SDavid van Moolenbroek </qandaentry> 1466*00b67f09SDavid van Moolenbroek 1467*00b67f09SDavid van Moolenbroek <qandaentry> 1468*00b67f09SDavid van Moolenbroek <question> 1469*00b67f09SDavid van Moolenbroek <para> 1470*00b67f09SDavid van Moolenbroek I get <quote>Error 1067</quote> when starting named under Windows. 1471*00b67f09SDavid van Moolenbroek </para> 1472*00b67f09SDavid van Moolenbroek </question> 1473*00b67f09SDavid van Moolenbroek <answer> 1474*00b67f09SDavid van Moolenbroek <para> 1475*00b67f09SDavid van Moolenbroek This is the service manager saying that named exited. You 1476*00b67f09SDavid van Moolenbroek need to examine the Application log in the EventViewer to 1477*00b67f09SDavid van Moolenbroek find out why. 1478*00b67f09SDavid van Moolenbroek </para> 1479*00b67f09SDavid van Moolenbroek <para> 1480*00b67f09SDavid van Moolenbroek Common causes are that you failed to create "named.conf" 1481*00b67f09SDavid van Moolenbroek (usually "C:\windows\dns\etc\named.conf") or failed to 1482*00b67f09SDavid van Moolenbroek specify the directory in named.conf. 1483*00b67f09SDavid van Moolenbroek </para> 1484*00b67f09SDavid van Moolenbroek <informalexample> 1485*00b67f09SDavid van Moolenbroek <programlisting> 1486*00b67f09SDavid van Moolenbroekoptions { 1487*00b67f09SDavid van Moolenbroek Directory "C:\windows\dns\etc"; 1488*00b67f09SDavid van Moolenbroek};</programlisting> 1489*00b67f09SDavid van Moolenbroek </informalexample> 1490*00b67f09SDavid van Moolenbroek </answer> 1491*00b67f09SDavid van Moolenbroek </qandaentry> 1492*00b67f09SDavid van Moolenbroek 1493*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Windows --> 1494*00b67f09SDavid van Moolenbroek 1495*00b67f09SDavid van Moolenbroek <qandadiv><title>FreeBSD</title> 1496*00b67f09SDavid van Moolenbroek 1497*00b67f09SDavid van Moolenbroek <qandaentry> 1498*00b67f09SDavid van Moolenbroek <question> 1499*00b67f09SDavid van Moolenbroek <para> 1500*00b67f09SDavid van Moolenbroek I have FreeBSD 4.x and "rndc-confgen -a" just sits there. 1501*00b67f09SDavid van Moolenbroek </para> 1502*00b67f09SDavid van Moolenbroek </question> 1503*00b67f09SDavid van Moolenbroek <answer> 1504*00b67f09SDavid van Moolenbroek <para> 1505*00b67f09SDavid van Moolenbroek /dev/random is not configured. Use rndcontrol(8) to tell 1506*00b67f09SDavid van Moolenbroek the kernel to use certain interrupts as a source of random 1507*00b67f09SDavid van Moolenbroek events. You can make this permanent by setting rand_irqs 1508*00b67f09SDavid van Moolenbroek in /etc/rc.conf. 1509*00b67f09SDavid van Moolenbroek </para> 1510*00b67f09SDavid van Moolenbroek <informalexample> 1511*00b67f09SDavid van Moolenbroek <programlisting> 1512*00b67f09SDavid van Moolenbroekrand_irqs="3 14 15"</programlisting> 1513*00b67f09SDavid van Moolenbroek </informalexample> 1514*00b67f09SDavid van Moolenbroek <para> 1515*00b67f09SDavid van Moolenbroek See also 1516*00b67f09SDavid van Moolenbroek <ulink url="http://people.freebsd.org/~dougb/randomness.html"> 1517*00b67f09SDavid van Moolenbroek <http://people.freebsd.org/~dougb/randomness.html></ulink>. 1518*00b67f09SDavid van Moolenbroek </para> 1519*00b67f09SDavid van Moolenbroek </answer> 1520*00b67f09SDavid van Moolenbroek </qandaentry> 1521*00b67f09SDavid van Moolenbroek 1522*00b67f09SDavid van Moolenbroek </qandadiv> <!-- FreeBSD --> 1523*00b67f09SDavid van Moolenbroek 1524*00b67f09SDavid van Moolenbroek <qandadiv><title>Solaris</title> 1525*00b67f09SDavid van Moolenbroek 1526*00b67f09SDavid van Moolenbroek <qandaentry> 1527*00b67f09SDavid van Moolenbroek <question> 1528*00b67f09SDavid van Moolenbroek <para> 1529*00b67f09SDavid van Moolenbroek How do I integrate BIND 9 and Solaris SMF 1530*00b67f09SDavid van Moolenbroek </para> 1531*00b67f09SDavid van Moolenbroek </question> 1532*00b67f09SDavid van Moolenbroek <answer> 1533*00b67f09SDavid van Moolenbroek <para> 1534*00b67f09SDavid van Moolenbroek Sun has a blog entry describing how to do this. 1535*00b67f09SDavid van Moolenbroek </para> 1536*00b67f09SDavid van Moolenbroek <para> 1537*00b67f09SDavid van Moolenbroek <ulink 1538*00b67f09SDavid van Moolenbroek url="http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris"> 1539*00b67f09SDavid van Moolenbroek <http://blogs.sun.com/roller/page/anay/Weblog?catname=%2FSolaris> 1540*00b67f09SDavid van Moolenbroek </ulink> 1541*00b67f09SDavid van Moolenbroek </para> 1542*00b67f09SDavid van Moolenbroek </answer> 1543*00b67f09SDavid van Moolenbroek </qandaentry> 1544*00b67f09SDavid van Moolenbroek 1545*00b67f09SDavid van Moolenbroek </qandadiv> 1546*00b67f09SDavid van Moolenbroek 1547*00b67f09SDavid van Moolenbroek <qandadiv><title>Apple Mac OS X</title> 1548*00b67f09SDavid van Moolenbroek 1549*00b67f09SDavid van Moolenbroek <qandaentry> 1550*00b67f09SDavid van Moolenbroek <question> 1551*00b67f09SDavid van Moolenbroek <para> 1552*00b67f09SDavid van Moolenbroek How do I run BIND 9 on Apple Mac OS X? 1553*00b67f09SDavid van Moolenbroek </para> 1554*00b67f09SDavid van Moolenbroek </question> 1555*00b67f09SDavid van Moolenbroek <answer> 1556*00b67f09SDavid van Moolenbroek <para> 1557*00b67f09SDavid van Moolenbroek If you run Tiger(Mac OS 10.4) or later then this is all you need to do: 1558*00b67f09SDavid van Moolenbroek </para> 1559*00b67f09SDavid van Moolenbroek <informalexample> 1560*00b67f09SDavid van Moolenbroek <programlisting> 1561*00b67f09SDavid van Moolenbroek% sudo rndc-confgen > /etc/rndc.conf</programlisting> 1562*00b67f09SDavid van Moolenbroek </informalexample> 1563*00b67f09SDavid van Moolenbroek <para> 1564*00b67f09SDavid van Moolenbroek Copy the key statement from /etc/rndc.conf into /etc/rndc.key, e.g.: 1565*00b67f09SDavid van Moolenbroek </para> 1566*00b67f09SDavid van Moolenbroek <informalexample> 1567*00b67f09SDavid van Moolenbroek <programlisting> 1568*00b67f09SDavid van Moolenbroekkey "rndc-key" { 1569*00b67f09SDavid van Moolenbroek algorithm hmac-sha256; 1570*00b67f09SDavid van Moolenbroek secret "uvceheVuqf17ZwIcTydddw=="; 1571*00b67f09SDavid van Moolenbroek};</programlisting> 1572*00b67f09SDavid van Moolenbroek </informalexample> 1573*00b67f09SDavid van Moolenbroek <para> 1574*00b67f09SDavid van Moolenbroek Then start the relevant service: 1575*00b67f09SDavid van Moolenbroek </para> 1576*00b67f09SDavid van Moolenbroek <informalexample> 1577*00b67f09SDavid van Moolenbroek <programlisting> 1578*00b67f09SDavid van Moolenbroek% sudo service org.isc.named start</programlisting> 1579*00b67f09SDavid van Moolenbroek </informalexample> 1580*00b67f09SDavid van Moolenbroek <para> 1581*00b67f09SDavid van Moolenbroek This is persistent upon a reboot, so you will have to do it only once. 1582*00b67f09SDavid van Moolenbroek </para> 1583*00b67f09SDavid van Moolenbroek </answer> 1584*00b67f09SDavid van Moolenbroek 1585*00b67f09SDavid van Moolenbroek <answer> 1586*00b67f09SDavid van Moolenbroek <para> 1587*00b67f09SDavid van Moolenbroek Alternatively you can just generate /etc/rndc.key by running: 1588*00b67f09SDavid van Moolenbroek </para> 1589*00b67f09SDavid van Moolenbroek <informalexample> 1590*00b67f09SDavid van Moolenbroek <programlisting> 1591*00b67f09SDavid van Moolenbroek% sudo rndc-confgen -a</programlisting> 1592*00b67f09SDavid van Moolenbroek </informalexample> 1593*00b67f09SDavid van Moolenbroek <para> 1594*00b67f09SDavid van Moolenbroek Then start the relevant service: 1595*00b67f09SDavid van Moolenbroek </para> 1596*00b67f09SDavid van Moolenbroek <informalexample> 1597*00b67f09SDavid van Moolenbroek <programlisting> 1598*00b67f09SDavid van Moolenbroek% sudo service org.isc.named start</programlisting> 1599*00b67f09SDavid van Moolenbroek </informalexample> 1600*00b67f09SDavid van Moolenbroek <para> 1601*00b67f09SDavid van Moolenbroek Named will look for /etc/rndc.key when it starts if it 1602*00b67f09SDavid van Moolenbroek doesn't have a controls section or the existing controls are 1603*00b67f09SDavid van Moolenbroek missing keys sub-clauses. This is persistent upon a 1604*00b67f09SDavid van Moolenbroek reboot, so you will have to do it only once. 1605*00b67f09SDavid van Moolenbroek </para> 1606*00b67f09SDavid van Moolenbroek </answer> 1607*00b67f09SDavid van Moolenbroek </qandaentry> 1608*00b67f09SDavid van Moolenbroek 1609*00b67f09SDavid van Moolenbroek </qandadiv> 1610*00b67f09SDavid van Moolenbroek 1611*00b67f09SDavid van Moolenbroek </qandadiv> <!-- Operating-System Specific Questions --> 1612*00b67f09SDavid van Moolenbroek 1613*00b67f09SDavid van Moolenbroek </qandaset> 1614*00b67f09SDavid van Moolenbroek</article> 1615