Secure64Cache v3.1 Admin Guide

SECURE64®
DNS CacheTM
Version: 3.1
ADMINISTRATOR GUIDE
December 5, 2013
Copyright © 2003-2013 Secure64 Software Corporation
ALL RIGHTS RESERVED
SECURE64 DNS CACHE 3.1
ii
Copyright Notices
© Copyright 2003-2013 Secure64 Software Corporation. ALL RIGHTS RESERVED.
U.S. Patents 7,509,644; 7,509,639; and 8,176,179
The information contained herein is subject to change without notice. The only warranties for Secure64 products
and services are set forth in the express warranty statements accompanying such products and services.
Nothing herein should be construed as constituting an additional warranty. Secure64 shall not be liable for technical
or editorial errors or omissions contained herein.
EFI fsck tools (fsckfat.efi and fsckffs.efi) Copyright (c) 2008-2010 Secure64 Software Corporation.
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later
version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the
implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License along with this program on the documentation
CD; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
USA. For a copy of the EFI fsck source code for fsckfat.efi and fsckffs.efi, email a request to
support@secure64.com.
Copyright (c) 2007, NLnet Labs. All rights reserved.

This software is open source. Redistribution and use in source and binary forms, with or without modification, are
permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution. Neither the name
of the NLNET LABS nor the names of its contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright 2009 Sun Microsystems, Inc. All rights reserved.

The contents of this file are subject to the terms of the Common Development and Distribution License (the
"License"). You may not use this file except in compliance with the License. You can obtain a copy of the license at
usr/src/OPENSOLARIS.LICENSE or http://www.opensolaris.org/os/licensing. See the License for the specific
language governing permissions and limitations under the License.
When distributing Covered Code, include this CDDL HEADER in each file and include the License file at usr/src/
OPENSOLARIS.LICENSE. If applicable, add the following below this CDDL HEADER, with the fields enclosed
by brackets "[]" replaced with your own identifying information: Portions Copyright [yyyy] [name of copyright
owner]
iii
Net-SNMP License
Various copyrights apply to this package, listed in various separate parts below. Please make sure that you read all
the parts.
---- Part 1: CMU/UCD copyright notice: (BSD like) -----
Copyright 1989, 1991, 1992 by Carnegie Mellon University
Derivative Work - 1996, 1998-2000
Copyright 1996, 1998-2000 The Regents of the University of California
All Rights Reserved
Permission to use, copy, modify and distribute this software and its documentation for any purpose and without
fee is hereby granted, provided that the above copyright notice appears in all copies and that both that copyright
notice and this permission notice appear in supporting documentation, and that the name of CMU and The
Regents of the University of California not be used in advertising or publicity pertaining to distribution of the
software without specific written permission.
CMU AND THE REGENTS OF THE UNIVERSITY OF CALIFORNIA DISCLAIM ALL WARRANTIES
WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL CMU OR THE REGENTS OF THE
UNIVERSITY OF CALIFORNIA BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL
DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM THE LOSS OF USE, DATA OR
PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS
SOFTWARE.
---- Part 2: Networks Associates Technology, Inc copyright notice (BSD) -----
Copyright (c) 2001-2003, Networks Associates Technology, Inc
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the
following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the
following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the Networks Associates Technology, Inc nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS `ÀS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
iv
---- Part 3: Cambridge Broadband Ltd. copyright notice (BSD) -----
Portions of this code are copyright (c) 2001-2003, Cambridge Broadband Ltd.
disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided with the distribution.
* The name of Cambridge Broadband Ltd. may not be used to endorse or promote products derived from this
software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER `ÀS IS'' AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
---- Part 4: Sun Microsystems, Inc. copyright notice (BSD) -----
Copyright © 2003 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara,
California 95054, U.S.A. All rights reserved.
Use is subject to license terms below.
This distribution may include materials developed by third parties.
Sun, Sun Microsystems, the Sun logo and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc.
in the U.S. and other countries.
disclaimer.
* Neither the name of the Sun Microsystems, Inc. nor the names of its contributors may be used to endorse or
promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS `ÀS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED
AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
v
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
---- Part 5: Sparta, Inc copyright notice (BSD) -----
Copyright (c) 2003-2009, Sparta, Inc
disclaimer.
* Neither the name of Sparta, Inc nor the names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
---- Part 6: Cisco/BUPTNIC copyright notice (BSD) -----
Copyright (c) 2004, Cisco, Inc and Information Network Center of Beijing University of Posts and
Telecommunications. All rights reserved.
disclaimer.
* Neither the name of Cisco, Inc, Beijing University of Posts and Telecommunications, nor the names of their
contributors may be used to endorse or promote products derived from this software without specific prior
written permission.
vi
---- Part 7: Fabasoft R&D Software GmbH & Co KG copyright notice (BSD) -----
Copyright (c) Fabasoft R&D Software GmbH & Co KG, 2003
oss@fabasoft.com
Author: Bernhard Penz
disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
* The name of Fabasoft R&D Software GmbH & Co KG or any of its subsidiaries, brand or product names may not
be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER `ÀS IS'' AND ANY EXPRESS OR
EVENT SHALL THE COPYRIGHT HOLDER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
---- Part 8: Apple Inc. copyright notice (BSD) -----
Copyright (c) 2007 Apple Inc. All rights reserved.
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following
disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following
3. Neither the name of Apple Inc. ("Apple") nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY APPLE AND ITS CONTRIBUTORS "AS IS" AND ANY EXPRESS OR
EVENT SHALL APPLE OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.
vii
---- Part 9: ScienceLogic, LLC copyright notice (BSD) -----

Copyright (c) 2009, ScienceLogic, LLC
disclaimer.
* Neither the name of ScienceLogic, LLC nor the names of its contributors may be used to endorse or promote
products derived from this software without specific prior written permission.
viii
Trademarks
Secure64®, SourceT®, Secure64 DNS Authority™, and Secure64 DNS Cache™ are trademarks or registered
trademarks of Secure64 Software Corporation.
All trade names referenced herein are the service mark, trademark, or registered trademark of the respective owner.
Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries. Linux is a registered trademark of Linus Torvalds in the United States and other countries.
UNIX is a registered trademark of The Open Group. Microsoft, Windows, and Active Directory are registered
trademarks of Microsoft Corporation in the United States and/or other countries.
Reproduction, adaptation, or translation of this document without prior written permission is prohibited, except as
allowed under the copyright laws.
Corporate Address
Secure64 Software Corporation
5600 South Quebec Street, Suite 320D
Greenwood Village, CO 80111-2216
Main: (303) 242-5890
FAX: (720) 489-0694
Certifications
The SourceT micro operating system has received the IPv6 Ready Phase-2 Logo certification from the IPv6 Forum.
http://www.ipv6ready.org/phase-2_approved_list
ix
x
Table of Contents
About Secure64 DNS Cache ............................................................................................... 1
Overview ......................................................................................................................................... 1
Secure64 DNS Cache Application Software .................................................................................. 1
Name Server .............................................................................................................................................1
Secure Console ........................................................................................................................................1
User Accounts, Roles, and RADIUS or LDAP Support .............................................................................1
SNMP and Syslog for Monitoring and Reporting ......................................................................................2
BGP for Anycast .......................................................................................................................................2
SourceT Micro Operating System .................................................................................................. 2
Hardware ........................................................................................................................................ 2
Additional Features ......................................................................................................................... 3
What’s New in Version 3.1 .............................................................................................................4
New and Enhanced Features ...................................................................................................................4
Other Command Changes and Additions .................................................................................................4
New and Modified Configuration Attributes ...............................................................................................5
Document Conventions .................................................................................................................. 7
About this Guide ............................................................................................................................. 8
Chapter 1. Operating Environment and User Accounts ................................................... 9
About the Command-Line Interface ................................................................................................9
Using the CLI ............................................................................................................................................9
View Mode, Enabling Roles, and Exiting the System .............................................................................10
Secure Console ............................................................................................................................ 12
Accessing the CLI with SSH ...................................................................................................................12
Using the iLO MP Console ......................................................................................................................17
Additional Information About the HP Integrity iLO MP ............................................................................19
Removing and Creating Server/Client SSH Keys ...................................................................................22
Secure Copy ................................................................................................................................. 23
Incoming and Outgoing Ports ....................................................................................................... 26
Roles and User Accounts ............................................................................................................. 27
About Authorization, Accountability, and Authentication (AAA) ..............................................................27
Authorization and Roles ..........................................................................................................................27
User Account Administration ...................................................................................................................31
Authentication .........................................................................................................................................49
Accounting .................................................................................................................................... 54
User Account Examples ............................................................................................................... 55
Small Non-RADIUS or Non-LDAP Installation Scenario .........................................................................55
Large Non-RADIUS or Non-LDAP Installation Scenario .........................................................................56
RADIUS or LDAP Installation Scenario ..................................................................................................58
Chapter 2. Getting Started .............................................................................................. 59

Preparations for Initial Configuration ............................................................................................ 59
Verifying Package Contents ....................................................................................................................59
Verifying Required Equipment ...............................................................................................................59
Completing the Network Information Worksheet .....................................................................................60
Connecting and Logging into the iLO Console ............................................................................. 61
Connecting and Logging into the iLO 2 MP Console (HP rx2660 Server) ..............................................61
Connecting and Logging into the iLO 3 MP Console (HP rx2800 Server) ..............................................65
Connecting and Logging into the iLO MP Console (HP Integrity Blade) .................................................67
Logging Into Secure64 DNS Cache and Creating Users ............................................................. 69
Configuring the Secure64 DNS Cache Management Console ....................................................73
Configuring the Default Gateway and Other Routes ...............................................................................75
Verifying the Console Interface ...............................................................................................................76
Disabling Telnet Access ..........................................................................................................................77
xi
Configuring DNS Interface(s) ....................................................................................................... 78

Attaching Mitigation Rules to Console and DNS Interfaces ......................................................... 79
Configuring Interfaces for Additional Services .............................................................................. 80
Configuring syslog .................................................................................................................................. 80
Configuring BGP, SNMP, and RADIUS or LDAP Interface(s) ................................................................ 81
Checklists for Configuring Additional System Settings ................................................................. 82
About Secure64 DNS Cache Administration ................................................................................ 83
System Configuration States .................................................................................................................. 83
Rebooting and Powering Off ................................................................................................................... 87
File System and Text Editor Commands ................................................................................................ 88
Chapter 3. Configuring Secure64 DNS Cache ................................................................. 91

Overview ....................................................................................................................................... 91
Checklist for Configuring New DNS Caching Servers .................................................................. 92
The Cache Configuration File ....................................................................................................... 93
About the Configuration File ................................................................................................................... 93
Configuration File Format and Rules ...................................................................................................... 93
Editing the Configuration File ....................................................................................................... 94
Creating the Initial Configuration File ...................................................................................................... 94
Using a Text Editor to Change the Configuration File ............................................................................ 94
Loading the Configuration Changes ....................................................................................................... 95
Standard Configuration Attributes ................................................................................................ 96
Configuring Basic Server Attributes ........................................................................................................ 96
Configuring Performance Attributes ...................................................................................................... 101
Configuring Caches and Internal TTL Values ....................................................................................... 104
Configuring Local Zones ....................................................................................................................... 108
Configuring for Basic Security .............................................................................................................. 118
Using Include Files ............................................................................................................................... 124
Chapter 4. Advanced Configuration Topics .................................................................. 127

Overview ..................................................................................................................................... 127
Enabling DNSSEC-Validated Queries ........................................................................................ 128
Understanding Validation Behavior ...................................................................................................... 128
Configuration Attributes for Trust Anchors ............................................................................................ 130
Obtaining and Configuring the Root Trust Anchor ................................................................................ 131
Obtaining Additional Trust Anchors ...................................................................................................... 133
Managing Trust Anchors ....................................................................................................................... 134
Using DLV ............................................................................................................................................. 134
Defining Resolver Forwarding .................................................................................................... 138
Defining Stub Zones ................................................................................................................... 140
Defining Merge Zones ................................................................................................................ 143
Checking Merge Zone Configuration .................................................................................................... 146
Configuring IPv6 Transition Technologies .................................................................................. 148
DNS64 .................................................................................................................................................. 148
IPv4 Filtering ......................................................................................................................................... 152
Redirecting NXDOMAIN Responses .......................................................................................... 156
DNSSEC and NXDOMAIN Redirection ................................................................................................ 157
Configuring NXDOMAIN Redirection .................................................................................................... 158
Testing NXDOMAIN Redirection .......................................................................................................... 162
Logging NXDOMAIN Redirection Activity ............................................................................................. 162
Defining Views ............................................................................................................................ 163
View Clause Configuration Attributes ................................................................................................... 164
Rules, Options, and Behaviors ............................................................................................................. 165
Configuring Separate Caches ............................................................................................................... 168
Checking View Information ................................................................................................................... 169
Creating Location-Based Views ............................................................................................................ 169
Advanced Security Configuration ............................................................................................... 172
xii
Filtering Requests Based on Incoming Query Type ..............................................................................173
Blacklisting Domains Using Local Zone Configuration ..........................................................................173
Specifying an Unbound Configuration File .................................................................................177
Chapter 5. Managing Secure64 DNS Cache .................................................................. 179
Overview .....................................................................................................................................179
Multiple Resolver Instances ........................................................................................................180
Caches and Size Distribution ................................................................................................................180
Independent Caches and Query Handling ............................................................................................181
Multiple Instances and Views ................................................................................................................181
Query Logging ......................................................................................................................................183
Resolver Instances, Physical Processors, and Logical Processors ......................................................183
Starting and Stopping the Name Server .....................................................................................184
Starting the Name Server .....................................................................................................................184
Stopping the Name Server ....................................................................................................................184
Reloading Configuration Changes Dynamically .........................................................................185
Using the Reload Command .................................................................................................................186
Verifying the Reload Configuration Results ..........................................................................................187
Testing the Name Server ............................................................................................................189
Checking the Server Status and Using the Dig Command ...................................................................189
Troubleshooting Response, Validation, and Caching Errors ................................................................192
Troubleshooting Startup Errors .............................................................................................................192
Caching Server Utility Commands ..............................................................................................193
Flushing the Cache ...............................................................................................................................193
Displaying Cache Information for a Domain Name ...............................................................................196
Displaying Caching Server Configuration .............................................................................................201
Saving and Loading the Cache ..................................................................................................204
Preserving the Cache on Stop and Start ..............................................................................................204
Preloading the Cache for Specific Zones ..............................................................................................206
Prefetching Expiring Entries ..................................................................................................................206
DNS Query Monitoring ...............................................................................................................207
Real Time Query Monitoring (RTQM) ...................................................................................................207
DNS Query Logging ..............................................................................................................................211
Server Activity Reporting and Statistics ......................................................................................215
Displaying Statistics at the Command Line ...........................................................................................215
Information Displayed ...........................................................................................................................219
Chapter 6. Secure Configuration .................................................................................. 223

Overview .....................................................................................................................................223
Inherent Security ........................................................................................................................224
Defending Against DNS DDoS Attacks ......................................................................................224
About Attack Threats and Countermeasures ........................................................................................225
DNS Packet Inspection .........................................................................................................................225
About Data Flood Protection Mechanisms ............................................................................................226
About Rate-Limiting Rules ....................................................................................................................227
Configuring UDP Rate Limit or Drop Rules ...........................................................................................234
Configuring TCP Rules for SSH and DNS Traffic .................................................................................236
DNS RRtype Filtering Rules .................................................................................................................238
Attack Monitoring, Notification, and Statistics .......................................................................................242
Restricting Console Connections ..........................................................................................................242
Securing Sensitive Data .............................................................................................................244
About Sensitive Data Protection (SDP) ................................................................................................244
Creating and Managing Sensitive Data Units (SDUs) ...........................................................................245
Recommendations and Best Practices .......................................................................................249
Using Anycast and BGP to Disperse DNS Servers Geographically ....................................................249
Recommendations for Securing the DNS Hosting Environment ...........................................................249
Chapter 7. System Administration ................................................................................ 251
xiii
Overview ..................................................................................................................................... 251

System Administration Tasks ..................................................................................................... 252
Configuring the Default Gateway and Other Routes ............................................................................ 252
Configuring In-Bound Traffic Routing Style .......................................................................................... 255
Configuring IP Fragmentation Resource Limits .................................................................................... 256
Configuring UDP Packet Checking ....................................................................................................... 257
Configuring a Nodename ...................................................................................................................... 258
Configuring System Name Servers ...................................................................................................... 259
Defining the Time Zone ........................................................................................................................ 260
Changing the Date and/or Time ............................................................................................................ 261
Managing NTP Servers ........................................................................................................................ 263
Managing Syslog Servers and Local Logging ...................................................................................... 269
Adding and Removing IP Addresses for Interfaces .............................................................................. 276
Configuring a Loopback Interface ......................................................................................................... 280
Adding and Removing Console Interfaces ........................................................................................... 281
Changing the IP Address of a Console Interface .................................................................................. 282
Changing the Console Timeout ............................................................................................................ 283
Configuring Ethernet Bonding ............................................................................................................... 284
Customizing Login with an Issue File (optional) ................................................................................... 289
Setting the Chassis Polling Interval ...................................................................................................... 290
Connecting a VGA Monitor (optional) ................................................................................................... 291
Configuring RAID .................................................................................................................................. 291
Starting in Safe Mode ........................................................................................................................... 292
Backup and Recovery Tasks ................................................................................................................ 296
System Recovery .................................................................................................................................. 299
Viewing the Cryptographic Module Status ............................................................................................ 299
Upgrading the Software ........................................................................................................................ 300
Reversing a Software Upgrade ............................................................................................................. 302
Determining the Secure64 DNS Cache License Key ........................................................................... 302
Chapter 8. Enabling BGP for Anycast ........................................................................... 303

Overview ..................................................................................................................................... 303
About BGP and Secure64 DNS Cache ...................................................................................... 305
Memory Requirements ......................................................................................................................... 305
BGP Message Types ............................................................................................................................ 305
TCP MD5 Signatures ............................................................................................................................ 305
Defining the BGP Configuration ................................................................................................ 306
Format and Rules ................................................................................................................................. 306
Global BGP Configuration Parameters ................................................................................................. 309
Group and Neighbor BGP Configuration Parameters ........................................................................... 310
UPDATE Filter Rules ............................................................................................................................ 311
BGP Configuration Preparations .......................................................................................................... 313
Changing the BGP Configuration File ................................................................................................... 316
Implementing TCP MD5 Signatures ..................................................................................................... 317
BGP Commands ......................................................................................................................... 318
Using BGP Commands .............................................................................................................. 320
Stopping and Starting BGP ................................................................................................................... 320
Viewing the Current BGP System State ............................................................................................... 321
Viewing BGP Information ...................................................................................................................... 321
Withdrawing and Announcing Service for a Specific IP Address .......................................................... 322
Testing and Managing BGP ....................................................................................................... 324
Using traceroute ................................................................................................................................... 324
Viewing Neighbor Information ............................................................................................................... 324
Viewing RIB Information ....................................................................................................................... 327
Viewing FIB Information ........................................................................................................................ 328
Changing Routing Information .............................................................................................................. 328
Troubleshooting BGP .......................................................................................................................... 328
Backing Up and Restoring BGP Information ........................................................................................ 329
xiv
Chapter 9. Enabling RADIUS or LDAP for User Authentication ................................... 331
Overview .....................................................................................................................................331
About RADIUS and Secure64 DNS Cache ................................................................................332
Defining Secure64 Vendor-Specific Attributes ...........................................................................332
RADIUS Dictionary Files .......................................................................................................................332
Assigning Login Permissions to Users ..................................................................................................333
Configuring the Secure64 DNS Cache RADIUS Client ..............................................................336
Format and Rules .................................................................................................................................336
Configuration File Attributes ..................................................................................................................337
Configuring Access to RADIUS Servers .....................................................................................338
Preparations ..........................................................................................................................................338
Encrypting the Shared Secret ...............................................................................................................339
Editing the RADIUS Configuration File .................................................................................................339
Testing RADIUS Server Settings ..........................................................................................................340
Using RADIUS Commands ........................................................................................................342
Starting and Stopping RADIUS Authentication .....................................................................................342
Viewing the Current RADIUS System State ..........................................................................................343
Viewing the RADIUS Configuration ......................................................................................................344
Managing RADIUS .....................................................................................................................345
Troubleshooting RADIUS ......................................................................................................................345
Backing Up and Restoring RADIUS Information ...................................................................................346
About LDAP Authentication and Secure64 DNS Cache .............................................................347
Defining Password Authentication on the LDAP server .............................................................347
Defining Secure64 DNS Cache Roles on the LDAP Server .......................................................349
Determining Server Groups and/or Schemas .......................................................................................349
Configuring the Secure64 DNS Cache LDAP Client ..................................................................351
Format and Rules .................................................................................................................................351
Encrypting the LDAP Bind Password ....................................................................................................351
Example Secure64 DNS Cache LDAP Configurations .........................................................................352
Server, Client, and Search Attributes ....................................................................................................354
Mapping Roles in Secure64 DNS Cache ..............................................................................................355
Editing the Secure64 DNS Cache LDAP Configuration ............................................................357
Using LDAP Commands .............................................................................................................357
Starting and Stopping LDAP Authentication .........................................................................................357
Viewing the Current LDAP System State ..............................................................................................359
Viewing the LDAP Configuration ...........................................................................................................360
Managing LDAP .........................................................................................................................362
Troubleshooting LDAP ..........................................................................................................................362
Backing Up and Restoring LDAP Information .......................................................................................363
Chapter 10. Information and Diagnostics ..................................................................... 365

System Information and Diagnostics ..........................................................................................365
Monitoring Logging Messages ..............................................................................................................365
Using System Utility Commands ...........................................................................................................366
Displaying Mitigation and Self-Defense Statistics .................................................................................386
Using BFD ..................................................................................................................................388
Configuring BFD ...................................................................................................................................388
BFD Commands ...................................................................................................................................389
Implementing SNMP ..................................................................................................................391
About SNMP and Secure64 DNS Cache .............................................................................................391
Supported SNMP MIBs .........................................................................................................................392
Importing the Secure64 DNS Cache MIBs into the NMS .....................................................................394
Defining the SNMP Configuration in Secure64 DNS Cache .................................................................394
Using SNMP Commands ......................................................................................................................401
Testing SNMP .......................................................................................................................................404
Troubleshooting SNMP ........................................................................................................................405
Backing Up SNMP Information .............................................................................................................405
xv
Secure64 Mitigation Trap Type Categories and Notifications ............................................................... 406

Secure64 Chassis Trap Type Categories and Notifications ................................................................. 412
Using the Secure64 DNS Cache dig Command ......................................................................... 415
Appendix A. Command Reference ..................................................................................421
View Mode Commands .............................................................................................................. 421
User Account Administration Commands ................................................................................... 425
System Administration Commands ............................................................................................ 427
Caching DNS Server Commands ............................................................................................... 433
BGP Administration Commands ................................................................................................. 435
Login and Authentication Administration Commands ................................................................. 437
Upgrade Commands .................................................................................................................. 439
Security Administration Commands ........................................................................................... 439
SNMP Administration Commands .............................................................................................. 441
Appendix B. Syslog and System Boot Messages .........................................................443
System Logging Messages ....................................................................................................... 443
User Account/Roles Logging Messages ..................................................................................... 446
Defense and Mitigation Logging Messages (Statistical) ............................................................. 448
Defense and Mitigation Logging Messages (Events) ................................................................. 450
Caching Application Logging Messages ..................................................................................... 452
Stub Resolver Logging Messages .............................................................................................. 469
BGP Logging Messages ............................................................................................................. 471
LDAP Logging Messages ........................................................................................................... 474
System Boot Messages .............................................................................................................. 478
Appendix C: Unbound Configuration Differences ........................................................479
Appendix D: Example Configuration File .......................................................................483
Index ..................................................................................................................................497
xvi
About Secure64 DNS Cache
This chapter provides an overview of the Secure64 DNS Cache software and platform
technologies. For additional information, visit the Secure64 web site at www.secure64.com.
Overview
Secure64 DNS Cache is a caching and validating DNS resolver that runs on the HP Integrity
server hardware platform. The software is designed for high performance, attack resistance, and
DNSSEC validation.
The user interface includes a management console connection through a serial or Ethernet port.
Configuration and administrative tasks are performed with a command-line interface (CLI) in a
vt100 terminal emulation, through a serial connection or a Secure Shell (SSH) version 2 session
over the network.
The following sections summarize each of the three main system components: the Secure64 DNS
Cache application software, the Secure64 SourceT micro operating system, and the server
hardware.
Secure64 DNS Cache Application Software

Name Server
Secure64 DNS Cache is a DNS caching, recursive, and validating server derived from the
Unbound open-source code base (www.unbound.net). Unbound was developed to provide
diversity for DNS implementations. It is specifically designed for environments where security,
performance, DNSSEC validation, and cache-poisoning resistance are highly important.
Secure Console
Configuration and administrative tasks are performed through commands at the command-line
interface (CLI), using a secure management console. Secure64 DNS Cache management console
options include an SSH2 connection and a serial console. The SSH2 connection supports public-
key authentication. In addition, the HP Integrity iLO (Integrated Lights-Out) management
processor connection is built into the HP Integrity server. It provides access to certain out-of-
band management capabilities. For more information, see Additional Information About the HP
Integrity iLO MP on page 19.
User Accounts, Roles, and RADIUS or LDAP Support

For security, accountability, and compartmentalization of tasks and privileges, the Secure64 DNS
Cache operational environment employs user accounts and roles. Roles are assigned to user
accounts according to your organization’s security and administrative policies. Each role provides
a distinct command set that corresponds to the tasks associated with the role.
1
If you prefer to use Remote Authentication Dial In User Service (RADIUS) or the Lightweight
Directory Access Protocol (LDAP) for user account management and authentication, Secure64
DNS Cache provides a configurable RADIUS client or LDAP client.
SNMP and Syslog for Monitoring and Reporting

To promote ease of monitoring the Secure64 DNS Cache server, you can configure the
software to support standard and proprietary Simple Network Management Protocol (SNMP)
get requests and SNMP traps to an SNMP-capable management system. Secure64 DNS Cache
supports SNMP v2c.
In addition to SNMP capabilities, you can configure Secure64 DNS Cache to log information
to syslog. Secure64 DNS Cache also includes commands for displaying DNS statistics, attack
statistics, and system information.
BGP for Anycast

For organizations that want to implement anycast IP addressing for security, latency reduction,
and redundancy, Secure64 DNS Cache offers built-in Border Gateway Protocol (BGP) support.
It can provide BGP updates to BGP neighbors, and it lets you withdraw specific IP addresses
from BGP announcements. You can also enable BGP to update outbound routing information
or both outbound and inbound routing information.
SourceT Micro Operating System

The Secure64 DNS Cache application runs on the specialized Secure64 SourceT micro
operating system. The micro OS employs a secure architecture that makes applications immune
to compromise from rootkits and malware and resistant to network attacks. Additionally, its
high-speed network I/O stack and parallel processing capabilities accelerate application
performance.
Because SourceT is not a general-purpose OS, such as Linux or Windows, all incoming ports
are closed except the UDP and TCP ports required for DNS activities, SSH, and BGP (if
enabled). The system includes protection from data floods, denial of service attacks (DoS), and
distributed denial of service attacks (DDoS). Mitigation features identify and block attack
traffic, while continuing to respond to DNS queries from legitimate sources.
Hardware
Secure64 DNS Cache runs on the HP Integrity rx2660, rx2800 i2/i4, BL860c (blade), and
BL860c i2/i4 (blade) server platforms with the following specifications:
• 1 or 2 dual-core or 1 quad-core Intel® Itanium® processor
• 4 GB of memory minimum (additional memory may be required, depending on
configuration and desired performance)
• 36 GB, 2.5-inch SAS HDD
2
Additional components and connections used by Secure64 DNS Cache include:

• DVD-ROM optical drive (for software installation)
• RJ-45 Gigabit Ethernet ports
• VGA port (for optional viewing of console information)
• RS-232 serial console port
• iLO LAN port
• HP Integrity iLO MP
To learn more about Secure64 DNS Cache and the HP Integrity iLO MP, see Additional
Information About the HP Integrity iLO MP on page 19. For connections and details about accessing
the console, see Connecting and Logging into the iLO Console on page 61.
Additional Features
In addition to performance, interoperability, and security features, Secure64 DNS Cache provides
the following features and benefits:
• Automatically starts DNS upon system reboot
• Uses a streamlined DNS configuration file format that’s easy to manage and deploy
• Supports UDP and TCP query/response
• Delivers high query throughput
• Provides real-time query monitoring features
• Offers NXDOMAIN redirection and blacklisting capabilities
• Provides a Capacity Expansion Module (CEM) with multiple resolver instances for higher
performance
Secure64 DNS Cache includes support for all or a portion of the following DNS RFCs:
• General DNS: RFCs 1034, 1035
• Localhost: RFC 1918
• Clarifications: RFC 2181
• Negative Caching: RFC 2308EDNS(0): RFC 2671
• Resolver support for DNSSEC: RFC 3225
• DNSSEC: RFCs 4033, 4034, 4035
• TLSA and DANE: RFC 6698
• DNS Resiliency: RFC 5452
3
What’s New in Version 3.1

New and Enhanced Features
• Support for RADIUS authentication is now available in Secure64 DNS Cache version
3.1. For complete details, refer to Chapter 9. Enabling RADIUS or LDAP for User
Authentication on page 331.
• A new Sensitive Data Protection (SDP) infrastructure for encrypting sensitive
information stored on the server is now available. You can protect the RADIUS shared
secret or the LDAP bind password with this feature. For details, refer to Securing Sensitive
Data on page 244.
• New security options are now available to filter incoming queries based on RRtype:
— Server-wide rate limiting and blacklisting: You can configure the mitigation
system to rate limit and/or blacklist queries for a specific RRtype. For details, see
DNS RRtype Filtering Rules on page 238.
— Per domain, using local zone: You can configure the local zone attribute to take
action on incoming queries for a specific domain and RRtype. See the Blacklisting
Domains Using Local Zone Configuration on page 173.
— All ANY type queries or MX type queries: You can configure the drop-any: or
drop-mx: configuration attributes to block all queries of the ANY or MX type. For
details, see Other Security, Hardening, and Testing Settings on page 121 in the
Configuring Secure64 DNS Cache chapter of the Administrator Guide. You can
also configure these for a specific source or destination IP address using a view.
• During boot time, the system now compares the hardware platform version to the
image version and the status of hardware threads. If there is a platform mismatch with
the software image, a warning message displays. If hardware threads are enabled, a
warning message along with the commands required to disable hardware threads
display. For details, refer to System Boot Messages on page 478.
• When a client query to a signed zone fails to validate in a Secure64 DNS Cache resolver
configured for full validation, the validation failure messages are now logged at syslog
level 5. Previously, the messages were logged at syslog level 7.
Other Command Changes and Additions

• The following commands have changed or are new with the addition of RADIUS
support to the Secure64 DNS server. For complete details, refer to Chapter 9. Enabling
RADIUS or LDAP for User Authentication on page 331.
Modified commands:
— show authenticate config <radius | ldap> [<server>]
— show authenticate info <radius | ldap>
— show authenticate status
4
— authenticate <radius | ldap>

— no authenticate <radius | ldap>
New commands:
— authprobe radius [<username> <password> <pap> <server> <port> <secret> <retries>
<timeout>]
• The following commands are available to support the new SDP feature. For details, refer
to Securing Sensitive Data on page 244:
— sdu delete <subsystem> <keyword>
— sdu list [<subsystem>]
— sdu protect <subsystem> <keyword> <SDU>
— sdu replace <subsystem> <keyword> <SDU>
— sdu reset
— sdu reveal <subsystem> <keyword>
• The new cpuinfo command provides information about the processor type, the number
of CPU cores enabled via the hardware, and the number CPU cores in use by the
Secure64 DNS server software. It is available in all roles.
• Updated the uptime command documentation in the Information and Diagnostics chapter
describing the processor number scheme that became effective with Secure64 DNS
Cache 3.0.2.
• When the server has the CEM enabled, multiple cryptographic module instances (1, 2, 3)
are also enabled. Non-CEM systems have a single CM instance (1). As a result, additional
options have been added to the status command in the securityadmin role:
status [all|#]
For additional details, refer to Viewing the Cryptographic Module Status on page 299.
New and Modified Configuration Attributes

• The addition of RADIUS support to the Secure64 DNS server includes a new
configuration file called radius.conf, located in the RADIUS directory of the loginadmin
role. For complete details, see Chapter 9. Enabling RADIUS or LDAP for User Authentication
on page 331.
• The new cache.conf configuration attribute domain-insecure: <domain name>
allows you to define a domain to omit from DNSSEC validation. This can be used to
define a “negative trust anchor” to temporarily disable DNSSEC validation for a specific
domain name. For details, see Configuration Attributes for Trust Anchors on page 130.
• The new cache.conf configuration attribute rrset-roundrobin: <yes|no> defines
whether to rotate the order of RRs within RRsets in DNS responses. The default is no.
For details, see Standard Configuration Attributes on page 96.
5
• The new cache.conf configuration attribute drop-any: <yes|no> defines whether

the server should drop all incoming queries of the type ANY. The default is no. When
set to yes, it is designed as a temporary protection from DDoS attacks that employ the
ANY RR type, to allow you to investigate other mitigation options. The attribute is
valid in the server: and view: clauses, and you can use the cachedns reload
command to change its settings. The number of dropped ANY queries is reported in
the show cachedns info command output.
• The new cache.conf configuration attribute drop-mx: <yes|no> defines whether
the server should drop all incoming queries of the type MX. Use with views to allow or
drop MX queries from specific clients. The attribute is valid in the server: and view:
clauses, and you can use the cachedns reload command to change its settings. The
number of dropped MX queries is reported in the show cachedns info command
output.
• You can define separate root-hints files using the root-hints: <filename> attribute
within a view: clause. If not defined, the view uses the default root-hints setting as
before.
• You can now specify an optional RRtype with a local-zone: attribute in the
cache.conf configuration. This allows you to define an action for the server to take,
such as deny or refuse, for a specific RRtype query of a domain and its subdomains.
The syntax is:
local-zone: <zone> <type> [RRtype] [log]
• To accommodate blacklist file requirements for servers managed by Secure64 DNS

Manager, the default value for the local-zone-log-file-num: attribute is changed
from 10 to 128. The default value for the local-zone-log-file-size: is changed
from 1 GB to 137 MB. Values that are explicitly defined in cache.conf are not
affected by this change.
6
Document Conventions
The typographical conventions for identifying information in this document are shown in
Table 1.
Table 1. Document conventions
Convention Example Description

Courier Font route default 10.0.0.1 Command line text that you type
[sysadmin@Secure64DNS]# route default 10.0.0.1 Command line output that you do
not type
Pending configuration changed
Courier Bold Font File contents

server:
interface: 192.168.127.94
Variable that you replace with the

Italics console <interface>
appropriate value
Information you type or select,
Bold Text Type enable sysadmin and press ENTER.
when included in a procedure
Press the ENTER key. Names of keys
Capital Letters
7
About this Guide

Chapter 1. Operating Environment and User Accounts on page 9 describes the command-line
interface, secure console, secure copy (scp), and user accounts and roles.
Chapter 2. Getting Started on page 59 provides instructions for configuring users, interfaces, and
routing. It offers checklists for completing additional configuration tasks and describes basic
system administration tasks.
Chapter 3. Configuring Secure64 DNS Cache on page 93 describes how to configure the name
server, including caching, local zones, and security settings.
Chapter 4. Advanced Configuration Topics on page 127 provides details about advanced
configuration options such as DNSSEC, IPv6 migration techniques, and views.
Chapter 5. Managing Secure64 DNS Cache on page 175 describes how to start, stop, test, and
manage the name server, including flushing the cache, dynamically reloading caching
configuration changes, and monitoring query activity.
Chapter 6. Secure Configuration on page 223 describes built-in defense mechanisms, rate-limiting
and mitigation rules, rule configuration, attack monitoring, zone transaction security, and
security recommendations and best practices.
Chapter 7. System Administration on page 251 provides detailed instructions for system
configuration tasks, upgrades, and backups.
Chapter 8. Enabling BGP for Anycast on page 303 details how to configure, test, and manage BGP
on the Secure DNS Cache server.
Chapter 9. Enabling RADIUS or LDAP for User Authentication on page 331 explains how to
configure the Secure64 DNS Cache RADIUS or LDAP client for user authentication.
Chapter 10. Information and Diagnostics on page 365 explains monitoring syslog messages,
displaying system information, displaying self-defense statistics, implementing SNMP support,
and using DNS information and diagnostics.
Appendix A. Command Reference on page 421 lists all of the commands in the Secure64 DNS
Cache software, based on role.
Appendix B. Syslog and System Boot Messages on page 443 lists syslog messages along with
recommended actions, if any.
.Appendix C: Unbound Configuration Differences on page 451 discusses the configuration
differences between Secure64 DNS Cache and the Unbound server.
Appendix D: Example Configuration File on page 455 illustrates an example cache.conf
configuration file for the Secure64 DNS Cache server.
8
Chapter 1. Operating Environment and User
Accounts
This chapter describes the Secure64 DNS Cache operating environment, user accounts, and roles.
After reviewing the information in this chapter, proceed to Chapter 2. Getting Started to perform
the initial configuration steps.
About the Command-Line Interface

Secure64 DNS Cache uses a specialized OS and file system. It offers a distinct command set
designed for the product’s function as a DNS name server, providing additional security
compared to a general purpose OS such as Linux. The following sections describe the Secure64
DNS Cache operating environment, including the command-line interface (CLI), secure console,
and secure copy.
Using the CLI

Configuration and administrative tasks are performed at the command-line interface, using a
secure management console. Table 2 describes common tasks and features of the CLI. For a
complete list of commands, see Appendix A. Command Reference on page 421.
Table 2. Secure64 DNS Cache CLI tasks
Task Additional Information

Display a list of commands for the current
Type help or ? and press ENTER.
operational mode
Type help command_name or ? command_name and press
Display help for a specific command
ENTER.
Use the no form of the command.
Cancel or remove a system configuration For example, console eth0 sets the management console to the
command eth0 interface, and no console eth0 removes the management
console from the eth0 interface.
Use the BACKSPACE key.
Correct an entry before pressing ENTER Note: User accounts and the file system are upper- and lower-case
specific. Commands are not case specific.
If you incorrectly enter a command, the system displays Command
not found. If you incorrectly enter a file or directory name, the
system displays No such file or directory
To make corrections after pressing ENTER, use the up- and down-
arrow keys to recall commands. Then use the right- and left-arrow
Correct an entry after pressing ENTER
keys to navigate the command line and edit the entry.
The BACKSPACE and DELETE keys are operational for editing a
recalled command. The CLI is always in insert mode.
Note: User accounts and the file system are upper- and lower-case
specific. Commands are not case specific.
9
Chapter 1. Operating Environment and User Accounts
Use command history scrolling or Use the up- and down-arrow keys to scroll through the command
command line completion history. Command line completion is not currently available.
Use wildcards in commands with file and If the file or directory specified includes path information, the wildcard
directory names (*,?) must be defined in the last part of the path.
For example, ls zones/*.dat is valid and
ls zone*/files.dat is not valid.
Use double quotes (" ") to cause the system to interpret the file or
Use spaces and/or special characters in directory name literally. Use a slash (/) without quotes to escape the
commands with file and directory names next character.
For example, "abc def" is interpreted as a file or directory named
’abc def’ and / abc is interpreted as a file or directory named
’ abc’.
Configurable timeout based on seconds of inactivity. By default, SSH
is limited to five simultaneous connections. If five simultaneous SSH
Log in via SSH console or serial console connections exist, additional attempts to open more connections are
disregarded and the client system may not respond. You can modify
this limit when configuring the console.
View Mode, Enabling Roles, and Exiting the System

To access the Secure64 DNS Cache CLI, you must have either a local user account or a
RADIUS or LDAP user account. Your user account is assigned one or more Secure64 DNS
Cache roles, which controls your command set and system privileges. (Roles and user accounts
are discussed in more detail in the section Roles and User Accounts on page 27.)
The CLI becomes available to you when you log into the system with your user account. All log
ins automatically default to the CLI view mode. To access a privileged mode based on the
role(s) your account is assigned, use the enable <role> command. This enables the privileged
mode for the role you define.
If your user account is assigned multiple roles and you want to enable a different role, return to
the view mode using the exit or quit command. You can then use the enable <role>
command, or you can use the exit or quit command again to exit the CLI. Figure 1 illustrates
how to enable modes, exit modes, and exit the system.
10
Figure 1. Accessing view mode, enabling modes, and exiting
• Whenever you log in to Secure64 DNS Cache with your user account, you are
automatically in the view mode, as indicated by the view prompt shown below:
[view@Secure64DNS]>
• To access the commands that correspond to a role assigned to your user account, you
can:
— Execute a corresponding enable <role> command at the view mode prompt., and
enter the commands within the enabled role
— Enter role-specific commands from view mode or any role you are authorized for
using the role command syntax:
[<role>][/<directory_path>] <command>
where:
<role> is the Secure64 role corresponding to the command (required except for
view mode commands or commands corresponding to the currently enabled role)
<directory path> is the an optional location which, if present, is the directory
pathname that the command executes under
<command> is the Secure64 DNS Cache command to execute, including any
arguments or parameters
For example, to execute BGP administration commands, you can:

• Log in with a user account assigned to the bgpadmin role and then enter the enable
bgpadmin command at the view mode prompt.
[view@Secure64DNS]> enable bgpadmin
[bgpadmin@Secure64DNS]# stop bgp
11
• Or use the role command syntax, which allows you to execute privileged mode
commands for your authorized roles without explicitly enabling the role:
[view@Secure64DNS]> bgpadmin stop bgp
If you want to change to a different role to execute commands directly from the role, first exit
to view mode and then execute the enable command for the different role. (Your user account
must be assigned to the role you want to enable.)
Example:
[bgpadmin@Secure64DNS]# exit
[view@Secure64DNS]> enable sysadmin
[sysadmin@Secure64DNS]#
• If you attempt to enable a role that is not assigned to your user account, Secure64 DNS
Cache denies access and you remain in view mode.
• To exit Secure64 DNS Cache, type exit or quit at the view mode prompt and press
ENTER.
• For a complete description of view mode commands and commands available in each
privileged role, see Appendix A. Command Reference on page 421.
Secure Console
Secure64 DNS Cache offers two options for console access to the machine and the system’s
command-line interface:
• SSH via a configured Ethernet port (usually eth0)
• Terminal emulation, SSH, or web via the HP Integrity iLO MP console interface
The console screen performs best at a display of 80 characters wide by 24 lines in length.
Note To log into Secure64 DNS Cache, you need a user account. The system ships with a default user
account called Installer, which you can use to get started creating the necessary user accounts. For
additional information, see Roles and User Accounts on page 27.
Accessing the CLI with SSH

Secure64 DNS Cache supports the SSH protocol engine (version 2.0).
• To use SSH, you must configure an Ethernet port for administrative access. For
configuration instructions, see Configuring the Secure64 DNS Cache Management Console on
page 73.
• You can log into SSH using a password or an SSH public key. SSH keys are stored in
directories that are user specific. For details about configuring SSH keys or passwords,
see Authentication on page 49.
12
Note For RADIUS and LDAP servers, Secure64 DNS Cache uses password-based authentication.
• You can execute any Secure64 DNS Cache command from an SSH command line,
provided you are an authorized user for the role associated with the command.
• Executing the enable <role> command from an SSH command line does not enable the
role or change the privileged role status for the next SSH command.
To access the Secure64 DNS Cache command-line interface with SSH (non-RADIUS
and non-LDAP):
1. Access the Secure64 DNS Cache name server via a secure shell (SSH) session:
— For Linux/UNIX administrative machines, enter the following command:
ssh [-P <port>] [<user>]@<host>
where:
-P <port> is the optional incoming SSH port (if different than port 22, see Adding and
Removing Console Interfaces on page 281 for details about changing the default port)
<user> is the Secure64 DNS Cache user account
<host> is the Secure 64 DNS Cache server IPv4 address, [IPv6 address] in square
brackets, or hostname
Note If you are using X11 forwarding or agent forwarding, add the –x (to disable X11 forwarding) and/or
–a (to disable agent forwarding) flags to the ssh command.
— For Windows administrative machines, use an SSH application such as PuTTY (see
OpenSSH at www.openSSH.org/windows.html.)
Enter the IP address for the Secure64 DNS Cache name server in the appropriate box
in the SSH application.
2. If prompted for a password or pass phrase, enter the appropriate password or pass phrase
for the user account.
3. The system displays the view mode command prompt:
[view@Secure64DNS]>
13
Note For additional security, the system defaults to ending SSH sessions after five (5) minutes of inactivity
and allowing a maximum of five (5) SSH logins per IP address. If five simultaneous SSH connections
exist, additional attempts to open more connections are disregarded and the client system may not
respond.
You can modify or disable the timeout as described in Changing the Console Timeout on page 283.
You can override the simultaneous connections limit as described in Adding and Removing Console
Interfaces on page 281. You can restrict console connections as described in Restricting Console
Connections on page 242.
To execute Secure64 DNS server commands from the SSH command line:
1. Use the following syntax from an SSH shell prompt:
— For Linux/UNIX administrative machines:
ssh [<user>]@<host> [<role>][/<directory_path>] <command>
where:
<host> is the Secure 64 DNS Cache server IPv4 address, [IPv6 address] in
square brackets, or hostname
<role> is the Secure64 role corresponding to the command (required except
for view role commands)
<directory path> is the an optional location which, if present, is the
directory pathname that the command executes under
<command> is the Secure64 DNS Cache command to execute, including any
arguments or parameters
Note The syntax is intended to provide the same functionality as the UNIX system command
su -<user> (cd<directory path> ;<command>)
— For Windows administrative machines, use the format above with an SSH
command-line application such as Plink (see they PuTTY link on OpenSSH at
www.openSSH.org/windows.html.):
2. If prompted, enter your Secure64 DNS Cache password.
14
Note You may or may not be prompted for a password, depending on how you have configured authentication.
For more information, see Authentication on page 49.
3. Assuming you are authorized to execute the command, the command is executed and any
related output displays on the SSH command line.
Note Commands are executed just as they are at the Secure64 DNS server command line. For example, if you
execute a sysadmin command that requires the activate and save commands to change the system
configuration, be sure to execute them at the SSH command line.
Examples:
admin1@server:~$ ssh user@192.168.127.1 show bgp info
user@192.168.127.1's password:
Copyright (c) 2003-2013 Secure64 Software Corp.
All Rights Reserved
Authorized access only
Last login: Thu Oct 24 08:17:55 2013 from 192.168.95.2
No information available.
bgp is not running
admin1@server:~$ ssh user@192.168.127.1 sysadmin ifconfig eth3

63.146.91.202 255.255.255.240
All Rights Reserved
Pending configuration changed.
admin1@server:~$ ssh user@192.168.127.1 sysadmin activate

All Rights Reserved
15
Running configuration changed.
admin1@server:~$ ssh user@192.168.127.1 sysadmin save

All Rights Reserved
Running configuration successfully saved.
16
Using the iLO MP Console

The HP Integrity server is equipped with the HP Integrity iLO (Integrated Lights-Out)
management processor (MP). Integrity iLO enables out-of-band system management capabilities
such as powering the system up and down, as discussed in Additional Information About the HP
Integrity iLO MP on page 19.
The iLO MP comes with two types of physical connections that provide console access:
• The Serial Console (RS-232) port for the iLO MP allows direct access to a console via
terminal emulation.
• iLO MP LAN port allows remote access to a console via SSH or a web browser. This
method also provides remote access to management of the server hardware.
Note Refer to the next section for important security information about the iLO MP interface.
For details about configuring the console through either the iLO MP Serial Console port or the
iLO MP LAN port, refer to Connecting and Logging into the iLO Console on page 61. Once the
connection is configured, refer to the following instructions for login procedures.
To log into Secure64 DNS Cache via the iLO MP Console:
1. If the physical connection is to the Serial Console (iLO MP):
— Using a vt100 serial terminal program, with port settings of 9600, 8N1 (8 databits, no
parity, 1 stop bit), no flow control, connect to the HP Integrity server.
If the physical connection is to the iLO MP LAN:
— Connect to the HP Integrity server via SSH or a web browser.
2. If you are using a command line interface (serial terminal or SSH) the MP Login prompt
displays:
— For the iLO 2 (rx2660, BL860c) enter Admin for the user and enter Admin for the
password.
For the iLO 3 (rx2800 i2/i4, BL860c i2/i4) enter Administrator for the user and the
randomly generated password found on the iLO Network Information Tag on the
server.
Note This is the default password if you have not yet changed it. See the HP Integrity server documentation for
password management details.
— At the MP Main Menu, type CO and press ENTER to select Console.
17
If you are using a web browser:

— Open a web browser and enter the host name or IP address of the iLO MP LAN.
— For the iLO 2 (rx2660, BL860c) enter Admin for the user and enter Admin for the
password.
For the iLO 3 (rx2800 i2/i4, BL860c i2/i4) enter Administrator for the user and
the randomly generated password found on the iLO Network Information Tag on
the server.
Note (This is the default password if you have not yet changed it. See the HP Integrity server
documentation for password management details.)
— Select Remote Console and select the Launch button.
3. At the login prompt, log into Secure64 DNS Cache with a Secure64 DNS Cache user
account. (If you do not have a user account, refer to User Account Administration on
page 31.)
4. Enter your Secure64 DNS Cache password.
5. The view mode prompt displays:
[view@Secure64DNS]>
Note For additional security, the system ends serial terminal and SSH connections after five (5) minutes of
inactivity. You can modify or disable the timeout as described in Changing the Console Timeout on
page 283.
18
Additional Information About the HP Integrity iLO MP
! WARNING The iLO MP console provides access to the system’s EFI (Extensible Firmware Interface) shell.
From the shell, an administrator can modify the system configuration, including the boot procedure,
firmware, security (Trusted Platform Module state), and configuration options. Do not modify the
configuration. A modified configuration can cause a boot failure of the Secure64 DNS Cache
server.
In addition to console capabilities discussed in Using the iLO MP Console on page 17,

administrators can use the iLO MP interface to:
• Monitor and manage the HP Integrity server hardware platform
• Provide information and alerts to remote management systems such as HP-SIM and
other HP OpenView products
• Remotely power-cycle the system
• Integrate with LDAP or Microsoft Active Directory for centralized administration of user
accounts (see notes below; requires iLO Advanced Pack)
• Provide encrypted console access through the iLO network adapter
Other capabilities include:
• Always-on capability with remote control of power and reset
• A web-based interface (SSL encrypted) for communicating with the iLO, as well as an
SSH command language interface
• System event display and recording
• Display of detailed information about internal subsystems such as power supplies, fans,
and processor components
• Integration with HP Systems Insight Manager for managing a large number of servers; an
SNMP agent integrates with other management systems
For a complete listing of Integrity iLO capabilities, refer to the documentation accompanying the
HP Integrity server.
Note HP offers an Advanced Pack iLO license for the iLO 2 MP and includes it automatically with the iLO 3 MP.
The Advanced Pack enables additional functionality for directory-based authorization and authentication,
such as LDAP and LDAP-lite integration, and access to the integrated remote console.
LDAP integration allows you to define Integrity iLO users and roles centrally in a company directory. Note
that it does not provide LDAP integration with the Secure64 DNS Cache server itself. For LDAP support
with the Secure64 DNS Cache server, see Chapter 9. Enabling RADIUS or LDAP for User Authentication
on page 331.
19
Security Considerations
The HP iLO management processor (MP) incorporates many security features, including
encrypted communication with SSL and SSH, as well as management of user accounts with
authorization and authentication. Nevertheless, you must take certain precautions or you risk
exposing the server to very serious attack scenarios.
Note Integrity iLO users and user privileges are defined only for the Integrity iLO management subsystem.
They do not carry over to the Secure64 DNS Cache server.
Types of risks include:

• A remote attacker can power down the server if access to iLO is gained.
• The serial console interface is a shared resource accessible to all individuals logged in to
the iLO. Because of this console multiplexing, someone issuing the esc-E C F
sequence can hijack an administrator’s serial console session.
Integrity iLO security best practices include:
• Change the default login and password.
• Disable telnet access (see Disabling Telnet Access on page 77).
• Use a separate management LAN for the iLO. Mixing DNS traffic with iLO traffic
creates the potential for attack.
• Determine the number of iLO accounts to allow and the corresponding privileges:
— Minimize local accounts (iLO-specific, onboard accounts)
— If possible, use LDAP/Active Directory account management. It is easier to add
and remove administrators and to set policies and privileges from a central
authority. Ensure that access to the LDAP server is secure. LDAP access requires
the Advanced Pack Integrity iLO option.
• Give minimum privileges to accounts based on each administrator role. For example:
— All privileges should be removed from accounts intended solely for viewing system
information, such as power supply, fans, and temperature.
— Only administrators with Secure64 DNS Cache accounts should be given access to
the serial console iLO interface.
— Only selected system administrators should be able to power cycle the server.
• Review administrator accountability by monitoring logs on a periodic basis:
— The serial console interface keeps a log of every command entered. (The log is not
accessible in web-access mode; it is only accessible from the iLO command-line
mode.)
— The iLO maintains an internal log of all major events such as power cycles.
20
LDAP and Active Directory Considerations

HP publishes instructions for integrating the iLO interface with a central directory using either
LDAP-Lite or schema-extended mechanisms. This integration is only possible with the Advanced
Pack Integrity iLO option. The Advanced Pack must be purchased for the iLO 2 MP and is
included with the iLO 3 MP.
Using a centralized directory simplifies the administration involved in adding/deleting users or
changing access rights and policies. Secure64 recommends use of the schema extensions for
maximum administration benefits. An administrator can use the LDAP credentials to log in to the
iLO interface to perform management tasks. Local accounts (non-LDAP) may also be defined.
Note LDAP integration allows you to define Integrity iLO users and roles centrally in a company directory. Note
that it does not provide LDAP integration with the Secure64 DNS Cache server itself. For LDAP support
with the Secure64 DNS Cache server, see Chapter 9. Enabling RADIUS or LDAP for User Authentication
on page 331.
Virtual Serial Console Considerations

If an administrator has a user account for the Secure64 DNS Cache server and access rights to
the virtual serial console, then the administrator may login first to the iLO interface (with LDAP,
for example) and then login to the DNS server by launching the virtual serial console.
Note If multiple administrators are logged in to the iLO interface, all of them can view the virtual serial console
simultaneously. This can be very useful to train new administrators at remote locations on how to use the
Secure64 DNS Cache server commands. However, any administrator with serial console access can
take write privilege to the console at any time. Do not leave a console session unattended or you may
find someone else logged in to your account, even from a remote location.
! WARNING The iLO virtual serial console emulates serial hardware; it is not an actual serial connection. Do not
use the standard CTRL/S and CTRL/Q commands to control data flow when connected to the
Secure64 DNS Cache server through the iLO virtual serial console.
21
Recommended Resources
HP publishes documents and white papers on its web site at www.hp.com. The following are
recommended to better understand the iLO interface, its integration with LDAP and Active
Directory, and various other security considerations.
• HP Integrity iLO 2 MP Operations Guide
http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c01936251/
c01936251.pdf
• HP Integrity iLO 3 MP Operations Guide
http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02111169-6.pdf
• HP Integrated Lights-Out Security; technology brief
• Configuring HP Integrated Lights-Out with Microsoft Active Directory
• HP Directory Services Schema Information Booklet
Removing and Creating Server/Client SSH Keys

If you are using SSH to access the Secure64 DNS Cache server, you may want to periodically
change the server’s SSH keys. The Secure64 DNS Cache server automatically generates SSH
keys upon start up if the keys are not already present. To create new SSH keys for the Secure64
DNS Cache server, you must remove the current keys and reboot the system.
To remove the Secure64 DNS Cache server’s SSH keys and create new SSH keys:
1. Log into Secure64 DNS Cache with a user account assigned to the securityadmin role.
2. At the view prompt, type enable securityadmin and press ENTER to enable
securityadmin mode.
3. At the securityadmin prompt, type remove sshkeys and press ENTER.
4. To determine whether the DNS server is running, type show cachedns status and
press ENTER.
If DNS is running, login as a user assigned to the cachednsadmin role, enable
cachednsadmin, and issue the stop cachedns command to stop the DNS server.
5. To determine whether BGP is running, type show bgp status and press ENTER.
If BGP is running, login as a user assigned to the bgpadmin role, enable bgpadmin, and
issue the stop bgp command to stop the BGP service.
6. To determine whether SNMP is running, type show snmp status and press ENTER.
If SNMP is running, login as a user assigned to the snmpadmin role, enable
snmpadmin, and issue the stop snmp command to stop the SNMP service.
7. Enable the securityadmin role or the sysadmin role, type reboot, and press ENTER.
Respond yes to the reboot prompt.
8. The server restarts and automatically generates new SSH keys.
22
9. Start DNS, BGP, and/or SNMP as necessary by enabling the cachednsadmin role and
entering start cachedns (for DNS), enabling the bgpadmin role and entering start bgp
(for BGP), and/or enabling the snmpadmin role and entering start snmp.
Example:
[view@Secure64]> enable securityadmin
[securityadmin@Secure64]# remove sshkeys

SSH server keys removed successfully.
SSH client keys removed successfully.
[securityadmin@Secure64]# show cachedns status

The server is running 2 instances
[securityadmin@Secure64]# show bgp status

bgp is not running
[securityadmin@Secure64]# show snmp status
snmp agent not running
[securityadmin@Secure64]# exit
[view@Secure64]> enable cachednsadmin
[cachednsadmin@Secure64]# stop cachedns

Stopping cachedns
Statistic logging stopped.
Stopping cachedns with 0 queries in progress
Stopped cachedns
[cachednsadmin@Secure64]# exit
[view@Secure64]> enable securityadmin
[securityadmin@Secure64]# reboot
are you sure? (y/n)
Secure Copy
Administrators need to copy files to and from the Secure64 DNS Cache server. Examples of files
to copy to the system include ASCII zone files and DNS configuration files. Files to copy from
the system include BGP or DNS configuration files for editing and backup.
23
Note The remote client system must use the scp protocol for file transfers. Other file transfer protocols, such
as SFTP, are not supported.
To use the scp command to copy a file from a remote system to Secure64 DNS Cache:
• Type the following at the remote system, and press ENTER:
scp [-r] [-P <port>] <file> <user>@<host>:/<role>/[destination]
where:
-r is the optional recursive copy flag
<file> is the path and file name of the source file
<role>is the Secure64 mode the user is acting in (cachednsadmin, sysadmin,
bgpadmin, loginadmin, securityadmin, snmpadmin, upgrade, or backup)
[destination] is the optional destination path and file name within the Secure64 role
Note If you are copying an SSH public key, refer to Using SSH Keys for User Authentication on page 50 for
special instructions.
To use the scp command to copy a file from the Secure64 DNS Cache to a remote
system:
• Type the following at the remote system:
scp [-r] [-P <port>] <user>@<host>:/<role>/<file> <destination>
where:
-r is the optional recursive copy flag
-P <port> is the optional destination port
<host> is the Secure64 DNS Cache server IPv4 address, [IPv6 address] in square
<role>is the Secure64 mode the user is acting in (cachednsadmin, sysadmin,
bgpadmin, loginadmin, securityadmin, snmpadmin, upgrade, or backup)
24
<file> is the path and file name of the source file

<destination> is the location to copy the file to
Note Secure64 DNS Cache supports wildcard * option with the scp command.
25
Incoming and Outgoing Ports

Secure64 DNS Cache disregards incoming traffic on all ports other than the ports configured
for DNS queries (default port 53), the SSH (default port 22), and the BGP port (default port
179, if BGP is enabled).
Security measures are provided for incoming traffic. For example, you can define rate-limiting
and mitigation rules to handle UDP and TCP traffic on the port configured for DNS,
providing a mechanism to decrease the risk of UDP and TCP data floods. For more
information, see Defending Against DNS DDoS Attacks on page 224.
Table 3 summarizes the ports used by Secure64 DNS Cache services.
Table 3. Secure64 DNS Cache system ports
Destination
Incoming (Remote)
Service (Secure64) Port System Port Security Measures
UDP or TCP port 53 UDP or TCP port Built-in security and configurable defense and
DNS
(default) 53 mitigation rules
SSH2, SSH keys, configurable timeout based on

seconds of inactivity, configurable maximum
SSH TCP port 22 (default) NA
concurrent SSH connections, configurable rule to
limit connections per minute
TCP port 179
BGP TCP port 179 TCP MD5 signatures
(default, if enabled)
TCP port 389 (if Username and password for LDAP server
LDAP NA
enabled) access
NTP undefined UDP port 123 NA
UDP port 162
Traditional SNMPv2c access control, throttling of
SNMP UDP port 161 (default, if
DoS/DDoS-related traps
enabled)
Throttling of DoS/DDoS-related logging
Syslog NA UDP port 514
messages
UDP port 1812
RADIUS NA (default, if Shared secret for RADIUS server access
enabled)
26
Roles and User Accounts

About Authorization, Accountability, and Authentication (AAA)
To enforce the network security principles of authorization, accountability, and authentication
(AAA), Secure64 DNS Cache requires individuals to log in to the system with a user account. The
combination of user accounts with other features provides:
• Authorization. Secure64 DNS Cache enforces authorization by requiring each user
account to be assigned one or more roles. A role is a privilege level that determines the set
of features, commands, and areas of the system a user account can access.
• Accountability. Secure64 DNS Cache enforces accountability by requiring a user
account for each individual and logging user account activity to syslog.
• Authentication. Secure64 DNS Cache enforces authentication by associating each user
account with either an SSH2 public key (if present) or an encrypted password. Secure64
DNS can also serve as a RADIUS client or as an LDAP client for centralized user account
management and authentication with a Microsoft Active Directory® or OpenLDAP
server.
The following sections discuss authorization and predefined roles, user administration,
authentication, and accounting. Examples of user account scenarios for a small installation and a
large installation are provided at the end of this chapter. Initial setup of user accounts is described
in Logging Into Secure64 DNS Cache and Creating Users on page 69.
Authorization and Roles

The predefined roles in Secure64 DNS Cache control the privileges of the user accounts assigned
to them. Roles separate tasks and capabilities. For security, the system provides each role with:
• Distinct command sets
• Specific tasks and privileges
• Separate, predetermined root directories (chroot jails)
Secure64 DNS Cache includes three main role classifications:
• Installer role
• Creator roles
• Administrator roles
Note A user account can be assigned to any number or roles and to both creator and administrator roles. Your
organization should determine role distribution as appropriate for your security and administration
environment. Your organization should also take measures to ensure only authorized users have access
to the Installer role/account.
27
Installer Role
Secure64 DNS Cache ships with a special Installer role, which is a predefined Installer user
account.
• The Installer role is not accessible through SSH. You must connect to the Secure64
DNS Cache name server’s iLO MP to log in with the Installer account. For details, see
Using the iLO MP Console on page 17.
• When you first log in to Secure64 DNS Cache, you use the Installer account to create
initial user accounts and assign them to creator roles. Creator roles are used to create
the administrator accounts that control various components of the system.
• In addition to creating the initial user accounts, the Installer role provides a means to
disable and reset all user accounts in the event of a security breach or other user
account issue. The Installer account establishes the password required to execute the
reset command.
• Your organization should take measures to ensure only authorized users have access to
the Installer account.
• When one user account is assigned to each of the creator roles, Secure64 DNS Cache
automatically disables the Installer role.
Creator Roles
Creator roles assign administrator roles to user accounts. Creator roles can also create and
remove user accounts. Each creator role has the authority to assign specific administrator
role(s). Creator roles include:
• syscreate (assigns the sysadmin, upgrade, and backup roles to user accounts)
• cachednscreate (assigns the cachednsadmin role to user accounts)
• bgpcreate (assigns the bgpadmin role to user accounts)
• logincreate (assigns the loginadmin role to user accounts)
• securitycreate (assigns the securityadmin role to user accounts)
• snmpcreate (assigns the snmpadmin role to user accounts)
In addition to assigning administrator roles, creator accounts can assign their own creator
role(s) to a user account. For example, if you are logged in as a user account with the syscreate
role, you can create user Mary and assign her to the syscreate role.
Administrator Roles
Administrator roles operate and administer different functions of the Secure64 DNS Cache
server, such as system administration and DNS administration. Administrator roles include:
• sysadmin (system administration tasks and commands)
• cachednsadmin (caching DNS server administration tasks and commands)
• upgrade (system upgrade tasks and commands)
28
• backup (system backup tasks and commands)

• bgpadmin (BGP administration tasks and commands)
• loginadmin (authentication and login administration tasks and commands)
• securityadmin (additional security tasks and commands)
• snmpadmin (SNMP administration tasks and commands)
Note If you configure the RADIUS or LDAP client in Secure64 DNS, you manage users and roles through your
authentication server. However, you must create certain users in Secure64 DNS Cache to install the
software, configure networking, and configure RADIUS or LDAP. See About User Account Administration
with RADIUS or LDAP on page 31 for more information.
Role Hierarchy and Assignment

Figure 2 illustrates the predefined roles in Secure64 DNS Cache and the roles that each creator
role can assign.
Figure 2. Secure64 DNS Cache role assignment
29
The Installer account is available at installation and when one or more creator roles are not
assigned. Creator roles assign users to the administrative roles that configure and operate
different components of the system.
For a summary about the roles in Secure64 DNS Cache, refer to Table 4.
Table 4. Summary of Secure64 DNS Cache roles
Role Type Tasks

Special role; only available under certain conditions and access must be
through the iLO console. Organizations should take measures to ensure only
authorized users have access to the Installer account.
Creates user accounts and assigns them to the creator roles (syscreate,
cachednscreate, bgpcreate, logincreate, securitycreate, snmpcreate).
Installer Creator
Can assign only one user to each creator role, after which the Installer role
becomes disabled for security purposes.
Enabled when a user account is not assigned to any one or more of the
syscreate, cachednscreate, bgpcreate, logincreate, securitycreate, or
snmpcreate roles.
Creates user accounts and assigns them to system administration roles
(sysadmin, upgrade, backup).
syscreate Creator
Removes user accounts from system administration roles and deletes user
accounts.
Creates user accounts and assigns them to the DNS administration role
(cachednsadmin).
cachednscreate Creator
Removes user accounts from the DNS administration role and deletes user
accounts.
Creates user accounts and assigns them to the BGP administration role
(bgpadmin).
bgpcreate Creator
Removes user accounts from the BGP administration role and deletes user
accounts.
Creates user accounts and assigns them to the authentication and login
administration role (loginadmin).
logincreate Creator
Removes user accounts from the authentication administration role and
deletes user accounts.
Creates user accounts and assigns them to the security administration role
(securityadmin).
securitycreate Creator
Removes user accounts from the security administration role and deletes
user accounts.
Creates user accounts and assigns them to the SNMP administration role
(snmpadmin).
snmpcreate Creator
Removes user accounts from the SNMP administration role and deletes user
accounts.
sysadmin Administrator Performs system administration tasks.
upgrade Administrator Performs system version upgrades and roll backs.
Backs up and restores system files using scp. This role does not require
backup Administrator access to Secure64 DNS Cache commands.
(DNS backup/restore is handled by the cachednsadmin role.)
cachednsadmin Administrator Performs DNS administration tasks.
30
bgpadmin Administrator Performs BGP administration tasks (optional; assign if will implement BGP).
loginadmin Administrator Performs user account, login, and authentication administration tasks.
securityadmin Administrator Performs system SSH key administration tasks.
snmpadmin Administrator Performs SNMP administration tasks.
User Account Administration

User account administration differs based on whether or not you use a RADIUS or LDAP server.
The following information describes user account administration with and without RADIUS or
LDAP. For additional information and examples, see User Account Examples on page 55.
About User Account Administration with RADIUS or LDAP

You can configure the Secure64 DNS Cache server to use the RADIUS or LDAP protocol to
access a remote directory service for user information. The information is stored on a centralized
RADIUS or LDAP database, which manages the user information.
To implement the Secure64 DNS Cache client, you must create and assign certain user accounts
to configure network and RADIUS or LDAP settings. In most cases, the following steps occur:
• The Installer account creates initial user accounts
• The Installer account assigns the initial user accounts to the syscreate, cachednscreate,
bgpcreate, logincreate, securitycreate, and snmpcreate roles
Note When each creator account has one user assigned to it, the Installer account is disabled. If any of the
creator accounts are not assigned to a user, the Installer account remains enabled and becomes a
security risk. Even if you are not implementing BGP, RADIUS, LDAP, and/or SNMP you should assign
users to the bgpcreate, logincreate, and snmpcreate roles in addition to all other create roles.
• The syscreate role creates a user account (or uses an existing account) and assigns it to the
sysadmin role to configure networking for Secure64 DNS
• The logincreate role creates a user account (or uses an existing account) and assigns it to
the loginadmin role to configure the Secure64 DNS RADIUS or LDAP client
• All other user accounts are created and managed on the RADIUS or LDAP server
• If the RADIUS/LDAP server is unavailable, the local Secure64 DNS user accounts are
enabled
For detailed procedures, see Chapter 9. Enabling RADIUS or LDAP for User Authentication on
page 331.
31
About User Account Administration with Secure64 DNS Cache

All creator accounts can access a set of user account administration commands. The commands
allow the syscreate, cachednscreate, bgpcreate, logincreate, securitycreate, and snmpcreate roles
to add and remove user accounts, assign user accounts to roles, and remove user accounts from
roles.
In most cases, the following steps occur:
• The Installer account creates the initial user accounts for the syscreate, cachednscreate,
bgpcreate, logincreate, securitycreate, snmpcreate roles
• The Installer account assigns the initial user accounts to the syscreate, cachednscreate,
bgpcreate, logincreate, securitycreate, and snmpcreate roles
Note When each creator account has one user assigned to it, the Installer account is disabled. If any of the
creator accounts are not assigned, the Installer account remains and becomes a security risk. Even if
you are not implementing BGP, RADIUS, LDAP, and/ or SNMP, you should assign users to the
bgpcreate, logincreate, and snmpcreate roles, in addition to all other create roles.
• The syscreate role creates user accounts and assigns them to the sysadmin, backup, and
upgrade roles
• The cachednscreate role creates user accounts and assigns them to cachednsadmin role
• The bgpcreate role creates user accounts and assigns them to the bgpadmin role
• The securitycreate role creates user accounts and assigns them to the securityadmin role
• The snmpcreate role creates user accounts and assigns them to the snmpadmin role
General rules for user account administration with Secure64 DNS Cache include:
• A create mode is enabled by typing enable <role> at the default view mode prompt,
where role is syscreate, cachednscreate, bgpcreate, logincreate, securitycreate,
or snmpcreate
• User accounts can be associated with any number or roles and both creator and
administrator roles
• A creator account can administer only those user accounts that belong to the role
controlled by the creator account; for example, the cachednscreate account can assign
and remove users to/from the cachednsadmin and cachednscreate accounts only
• User accounts require a password or public key for SSH2 access (for more information,
see Secure Console on page 1)
Table 5 summarizes the user administration commands in Secure64 DNS Cache. The sections
that follow provide instructions for specific user administration tasks. For initial set up of user
accounts, refer to Logging Into Secure64 DNS Cache and Creating Users on page 69.
32
Note If you configure the RADIUS or LDAP client, the commands below do not apply to users or roles
managed by the RADIUS or LDAP server.
Table 5. User account administration commands
Command Description
adduser <username> -a <days> [options] Adds the username to the list of valid user accounts for Secure64
DNS Cache.
The username must consist of 3-32 characters, start with an alpha
character, and contain alphanumeric characters (after the first
character).
-a <days> for account aging (required) defines the number of days of
inactivity before disabling the account. Configurable to 0 to disable
feature (weakens security), or between 20-90 days.
Available options are:
[-r realname] Displays in the show users command results, with up
to 64 alphanumeric characters and 10 words
[-p password_age] System defaults to 60 days before requiring users
to change password. Configurable to 0 to disable feature (weakens
security), or between 20-90 days.
[-c lockout_count] System defaults to lock out a user account after
greater than 3 failed logins, for the number of minutes defined by the
-t lockout-time. Configurable to 0 to disable feature (weakens
security), or between 3-5 attempts.
[-i lockout_interval] System defaults to 60 minutes before resetting
the lockout counter. Configurable to 0 to disable feature (weakens
security), or between 15-60 minutes.
[-t lockout_time] If the user account has been locked out, system
defaults to lock out the account for 60 minutes. Configurable to 0 to
require the loginadmin to reset locked out user, or between 15-60
minutes.
[-h history] System defaults to preventing the user from re-using the
last 5 passwords for the user account. Configurable to 0 to disable
feature (weakens security), or between 0-5 passwords.
deluser <username> Removes a user account from Secure64 DNS Cache. Before issuing
this command, you must use the usermod command to remove any
roles assigned to the user account.
Invoking this command for a user that is not associated with any
roles removes the user account and all associated data, including
SSH keys.
reset Disables all user accounts and enables the predefined Installer
account. Prompts for the reset password. FOR EMERGENCY USE
ONLY. For more information about the reset password, refer to
Logging Into Secure64 DNS Cache and Creating Users on page 69.
passwd [username] Sets or changes the password for the specified user account.
Passwords must be a minimum of 8 characters and include at least 3
alphabetic characters and at least 1 non-alphabetic character.
33
passwd reset Changes the reset command password. Prompts for the current
reset password.
show users [<username>] Without the <username> parameter, lists system users, one per line,
in the format of:
<username> : [real name]: <enabled|disabled>
To see details about a specific user account, add the <username>
parameter.
show roles Lists system roles, one per line, in the format of:
<role name> : [<user name1>, <user name2> [, ...]]
userdisable <username> Disables the specified user account.
userenable <username> Re-enables the specified user account after the reset command or
the userdisable <username> command is executed.
usermod +r <role name> <username> Adds (+r) or removes (-r) the username to/from the role name.
The issuer of the command must be a member of the corresponding
usermod -r <role name> <username>
create role to assign or remove the role.
34
Creating User Accounts
Note For a list of user account scenarios, see User Account Examples on page 55.
To create a user account:

1. Log in to Secure64 DNS Cache with a user account that has creator privileges (syscreate,
cachednscreate, bgpcreate, logincreate, securitycreate, or snmpcreate).
Note For initial set up of user accounts, including the syscreate, cachednscreate, bgpcreate, logincreate,
securitycreate, and snmpcreate accounts, refer to Logging Into Secure64 DNS Cache and Creating
Users on page 69.
2. Type enable <role> and press ENTER, where <role> is syscreate, cachednscreate,
bgpcreate, logincreate, securitycreate, or snmpcreate.
3. At the create prompt, type the following command and press ENTER, where
<username> is the user account name, <days> is the number of days of inactivity before
disabling account (between 20-90 days or 0 to disable, which weakens security), and
[options] are user and password management options:
adduser <username> -a <days> [options]
Note User accounts are case sensitive.
The required account aging parameter (-a <days>) and [options] can appear in any order after the
username. If you omit the account aging parameter, an error message displays stating that account aging
must be explicitly set when adding a user.

[-r realname] Displays in the show users command results, with up to 64 alphanumeric
characters and 10 words
[-p password_age] System defaults to 60 days before requiring users to change password.
Configurable to 0 to disable feature (weakens security), or between 20-90 days.
[-c lockout_count] System defaults to lock out a user account after greater than 3 failed
logins, for the number of minutes defined by the -t lockout-time. Configurable to 0 to
disable feature (weakens security), or between 3-5 attempts.
35
[-i lockout_interval] System defaults to 60 minutes before resetting the lockout counter.
Configurable to 0 to disable feature (weakens security), or between 15-60 minutes.
[-t lockout_time] If the user account has been locked out, system defaults to lock out the
account for 60 minutes. Configurable to 0 to require the loginadmin to reset locked out
user, or between 15-60 minutes.
[-h history] System defaults to preventing the user from re-using the last 5 passwords for
the user account. Configurable to 0 to disable feature (weakens security), or between 0-
5 passwords.
! WARNING Disabling user account and password security options is not recommended. For best practices
information about user account and password management, refer to NIST SP 800-118 Guide to
Enterprise Password Management at http://csrc.nist.gov/publications/PubsSPs.html and the
Center for Strategic and International Studies Twenty Critical Controls for Effective Cyber
Defense: Consensus Audit Guidelines at
http://csis.org/files/publication/Twenty_Critical_Controls_for_Effective_Cyber_Defense_CAG.pdf
4. Type passwd <username> and press ENTER, where <username> is the name of the
user account you created in the previous step.
Note Passwords must be a minimum of 8 characters and include at least 3 alphabetic characters
and at least 1 non-alphabetic character. Passwords are not recoverable. If you lose a password,
you must delete the user account and create a new user account. If you enable RADIUS or LDAP, the
local password and user account information is referenced only if all configured RADIUS or LDAP
servers are unavailable or authentication is disabled.
5. Follow the prompts to enter and confirm the password.
Note The owner of the user account can modify the password after logging into Secure64 DNS Cache. The
account owner must provide the current password upon log in and when modifying the password. The
account owner must also supply the password when installing an SSH2 public key for Secure64 DNS
Cache.
36
Example:
[view@Secure64DNS]> enable syscreate
[create@Secure64DNS]# adduser joe -r Joseph Doe -a 20 -p 20

Successfully added user joe
Account will expire after 20 days of inactivity

Password will expire after 20 days of inactivity
Account will be locked after more than 3 failed login attempts
Failed login lockout count will be automatically reset after 60
minutes
Locked out accounts will be automatically re-enabled after 60 minutes
A password history of 5 previous passwords will be retained
Run 'passwd joe' to set the password
[create@Secure64DNS]# passwd joe

Changing password for joe.
Enter NEW password:
Confirm NEW password:

User joe password changed.
6. To verify the information about the user account, type show users <username> and
press ENTER.
Example:
[create@Secure64DNS]# show users joe
Current time: Wed Feb 3 13:07:57 2010
User: joe
Real name: Joseph Doe
User is enabled
SSH password authentication: Yes
Account expires after 20 days of no activity (plus 3 days grace period)
Account inactive for less than 1 day
Password expires after 20 days of no change
Last password change: Wed Feb 3 13:07:43 2010
Password history: 5
Lockout after more than 3 failed logins for 60 minutes
Current failed logins counter: 0
Failed logins counter reset every 60 minutes, or after successful login
Last activity: Wed Feb 3 13:05:54 2010 created by admin
37
7. If any of the information is incorrect, you can use the deluser <username> command
to remove the account (if you have not yet assigned roles to the account) and use the
adduser <username> -a <days> [<options>] command to re-add the account.
Alternatively, the loginadmin user can modify account and password management
settings. For more information, see Modifying User Account and Password Management
Configuration on page 46.
8. Proceed to the next section to assign a role to the user account.
Assigning Creator Roles

Creator roles are assigned by the Installer user account or by an existing creator account.
Note When each creator account has one user assigned to it, the Installer account is disabled. You can
enter the show roles command to display the roles assigned to each local (non-RADIUS or non-
LDAP) user account.
To assign a user account to a creator role:

1. Log in to an existing creator (Installer, syscreate, cachednscreate, bgpcreate, logincreate,
securitycreate, or snmpcreate) user account.
2. At the view prompt, enable the desired creator role by typing the following command:
enable <syscreate|cachednscreate|bgpcreate|logincreate|securitycreate|snmpcreate>
and press ENTER.
3. At the create prompt, type the following command and press ENTER, where the role
is syscreate (for creating system administration accounts), cachednscreate (for
creating DNS administration accounts), bgpcreate (for creating bgp administration
accounts), logincreate (for creating login/authentication administration accounts),
securitycreate (for creating security administration accounts), or snmpcreate (for
creating SNMP administration accounts) and <username> is the name of the user
account to assign:
usermod +r <role> <username>
Example:
[create@Secure64DNS]# usermod +r syscreate Joe
Added Joe to syscreate
Note For redundancy, assigning a minimum of two users to each creator role is recommended.
38
Assigning Administrator Roles

Procedures for assigning administrator roles are described in this section. Required administrator
roles include sysadmin, cachednsadmin, securityadmin, and loginadmin. A syscreate user account
assigns users to the system administrator role, backup role, and upgrade role (sysadmin, backup,
upgrade). A user assigned to the cachednscreate role assigns users to the DNS administrator role
(cachednsadmin). A securitycreate user account assigns users to the security administrator role
(securityadmin), and a logincreate user account assigns users to the login administrator role
(loginadmin).
Note If you want to implement RADIUS or LDAP, you need to set up networking and configure the Secure64
DNS Cache RADIUS or LDAP client. To configure networking, a syscreate user account must assign a
user to the sysadmin role. For RADIUS or LDAP configuration, a logincreate user account must assign a
user to the loginadmin role. Refer to Logging Into Secure64 DNS Cache and Creating Users on page 69
for more information. After RADIUS or LDAP is configured, you can manage all other users and roles
through the RADIUS or LDAP server.
Optional administrator roles include bgpadmin and snmpadmin. If you want to implement BGP,
then a bgpcreate user account must assign a user to the BGP administrator role (bgpadmin). If
you want to implement SNMP, then an snmpcreate user account must assign a user to the SNMP
administrator role (snmpadmin).
Note If you have multiple creator roles assigned to your user account, you do not need to exit and enable each
role separately to assign administrator roles. For example, if your user account is assigned to the
bgpcreate and syscreate roles, you can enable bgpcreate and assign bgpadmin, sysadmin, backup, and
upgrade roles to users without logging out and enabling the syscreate role.
To assign a user account to the sysadmin, backup, or upgrade roles:

1. Log in to a syscreate user account.
2. At the view prompt, type enable syscreate and press ENTER.
<username> is the name of the user account to assign to the sysadmin, backup, or
upgrade role:
usermod +r <sysadmin|backup|upgrade> <username>
39
Example:
[create@Secure64DNS]# usermod +r sysadmin Bill
Added Bill to sysadmin
[create@Secure64DNS]# usermod +r upgrade Bill

Added Bill to upgrade
[create@Secure64DNS]# usermod +r backup Bill

Added Bill to backup
To assign a user account to the loginadmin role configuration:

1. Log in to a logincreate user account.
2. At the view prompt, type enable logincreate and press ENTER.
<username> is the name of the user account to assign to the loginadmin role:
usermod +r loginadmin <username>
To assign a user account to the cachednsadmin role:

1. Log in to an cachednscreate user account.
2. At the view prompt, type enable cachednscreate and press ENTER.
<username> is the name of the user account to assign to the cachednsadmin role:
usermod +r cachednsadmin <username>
Example:
[view@Secure64DNS]> enable cachednscreate
[create@Secure64DNS]# usermod +r cachednsadmin Bill

Added Bill to cachednsadmin
To assign a user account to the securityadmin role:

1. Log in to a securitycreate user account.
2. At the view prompt, type enable securitycreate and press ENTER.
<username> is the name of the user account to assign to the securityadmin role:
usermod +r securityadmin <username>
40
Example:
[view@Secure64DNS]> enable securitycreate
[create@Secure64DNS]# usermod +r securityadmin Bob

Added Bob to securityadmin
To assign a user account to the bgpadmin role:

1. Log in to a bgpcreate user account.
2. At the view prompt, type enable bgpcreate and press ENTER.
<username> is the name of the user account to assign to the bgpadmin role:
usermod +r bgpadmin <username>
Example:
[view@Secure64DNS]> enable bgpcreate
[create@Secure64DNS]# usermod +r bgpadmin Bill

Added Bill to bgpadmin
To assign a user account to the snmpadmin role:

1. Log in to a snmpcreate user account.
2. At the view prompt, type enable snmpcreate and press ENTER.
<username> is the name of the user account to assign to the bgpadmin role:
usermod +r snmpadmin <username>
Example:
[view@Secure64DNS]> enable snmpcreate
[create@Secure64DNS]# usermod +r snmpadmin Bill

Added Bill to snmpadmin
41
Viewing Users and Roles
Note User administration commands apply only to the user information stored locally in Secure64 DNS
Cache. If you have configured RADIUS or LDAP, use your RADIUS/LDAP server to manage user
information stored on the server.
To view a list of all users:

1. Log in to a creator (syscreate, cachednscreate, bgpcreate, logincreate, securitycreate,
snmpcreate) user account.
2. At the view prompt, type enable
<syscreate|cachednscreate|bgpcreate|logincreate|securitycreate|snmpcreate
> and press ENTER.
3. At the create prompt, type show users and press ENTER.
4. A list of user accounts, the associated real name (if assigned), and account status
(enabled or disabled) displays.
Example:
[create@Secure64DNS]# show users
Installer : Installer : disabled
Mary : : enabled
Jim : : enabled
Jane : Jane Doe : enabled
Bill : William Smith : enabled
To view information about a specific user account:

2. At the view prompt, type enable
<syscreate|cachednscreate|bgpcreate|logincreate|securitycreate|snmpcreate>
and press ENTER.
3. At the create prompt, type show users <username> and press ENTER.
4. Detailed information about the user account and password management parameters
displays:
42
Example:
[create@Secure64DNS]# show users joe
Current time: Wed Feb 3 13:07:57 2010
User: joe
Real name: Joseph Doe
User is enabled
SSH password authentication: Yes
Account expires after 20 days of no activity (plus 3 days grace period)
Account inactive for less than 1 day
Password expires after 20 days of no change
Last password change: Wed Feb 3 13:07:43 2010
Password history: 5
Lockout after more than 3 failed logins for 60 minutes
Current failed logins counter: 0
Failed logins counter reset every 60 minutes, or after successful login
Last activity: Wed Feb 3 13:05:54 2010 created by admin
To view a list of all roles and user accounts assigned to them:

2. At the view prompt, type
enable <syscreate|cachednscreate|bgpcreate|logincreate|securitycreate|snmpcreate> and
press ENTER.
3. At the create prompt, type show roles and press ENTER.
4. A list of roles and user accounts assigned to each role displays.
Example:
[create@Secure64DNS]# show roles
syscreate : Mary, Jim
sysadmin : Mary, Jim
cachednscreate : Bill, Jane
cachednsadmin : Bill
backup : Mary
upgrade : Mary
bgpcreate : Jim
bgpadmin : Jane
logincreate: Jim
loginadmin: Bill
securitycreate: Jim
securityadmin: Bob
snmpcreate: Mary
snmpadmin: Jim
43
Removing Creator or Administrator Roles from a User Account
Note Commands to remove roles from a user account apply only to the user information stored locally in
Secure64 DNS Cache. If you have configured RADIUS or LDAP, use your RADIUS or LDAP server to
manage user and role information configured on the server.
To remove a user account from a creator or administrator role:

1. Log in to a user account that has access to the creator role corresponding to the role
you want to remove.
2. Type enable <creator account> and press ENTER, where creator account is:
— syscreate (to remove the sysadmin, backup, upgrade, or a syscreate roles)
— cachednscreate (to remove the cachednsadmin or cachednscreate roles)
— bgpcreate (to remove the bgpadmin or bgpcreate roles)
— logincreate (to remove the loginadmin or logincreate roles)
— securitycreate (to remove the securityadmin or securitycreate roles)
— snmpcreate (to remove the snmpadmin or snmpcreate roles)
3. At the create prompt, type the following and press ENTER:
usermod –r <role> <username>
where <role> is the role to remove and <username> is the Secure64 DNS Cache user
account.
Example:
[create@Secure64DNS]# usermod -r sysadmin Bill
Removed Bill from sysadmin
Deleting User Accounts
Note Commands to delete user accounts apply only to the user information stored locally in Secure64 DNS
Cache. If you have configured RADIUS or LDAP, use your RADIUS or LDAP server to manage user
and role information stored on the server.
Before you can remove a user account, you must remove all currently assigned roles from the
user account.
44
To delete a user account:

1. Remove the all roles from the user account. See Removing Creator or Administrator Roles from
a User Account on page 44 for instructions.
2. At the create prompt, type deluser <username> and press ENTER, where username is the
user account to delete.
Example:
[create@Secure64DNS]# deluser Bill
User Bill removed successfully

Installer : Installer : disabled
Mary : : enabled
Jim : : enabled
Jane : Jane Doe : enabled
45
Modifying User Account and Password Management Configuration
! WARNING Disabling user account and password security options is not recommended. For best practices
information about user account and password management, refer to NIST SP 800-118 Guide to
Enterprise Password Management at http://csrc.nist.gov/publications/PubsSPs.html and the
Center for Strategic and International Studies Twenty Critical Controls for Effective Cyber
Defense: Consensus Audit Guidelines at
http://csis.org/files/publication/Twenty_Critical_Controls_for_Effective_Cyber_Defense_CAG.pdf
To manage account and password security for existing user accounts, the loginadmin role
includes the commands described in :
Table 6. User and password login administration commands
Command Description
No system default, must be set when user is added.to
define the number of days of inactivity before disabling
user <username> age account <0, 20-90> account. Configurable to 0 to disable feature (weakens
security), or between 20-90 days. A three-day grace
period is applied before disabling the account.
System defaults to 60 days before requiring users to
user <username> age passwd <0, 20-90> change password. Configurable to 0 to disable feature
(weakens security), or between 20-90 days.
System defaults to lock out a user account after greater
than 3 failed logins, for the number of minutes defined
user <username> lockout count <0, 3-5>
by the lockout time. Configurable to 0 to disable feature
(weakens security), or between 3-5 attempts.
System defaults to 60 minutes before resetting the
user <username> lockout interval <0, 15-60> lockout counter. Configurable to 0 to disable feature
(weakens security), or between 15-60 minutes.
If the user account has been locked out, system
defaults to lock out the account for 60 minutes.
user <username> lockout time <0, 15-60>
Configurable to 0 to require the loginadmin to reset
locked out user, or between 15-60 minutes.
System defaults to preventing the user from re-using the
last 5 passwords for the user account. Configurable to 0
user <username> history <0-5>
to disable feature (weakens security), or between 0-5
passwords.
Generates a random temporary password. After logging
in with a temporary password, the user must change it,
and the temporary password becomes invalid. The
user <username> randompass
random password is not included in the password
history. The following characters will not be used: “ ‘ , . [
] { } ( ) | and spaces, backspaces, or deletes.
user <username> <enable|disable> Enable or disable the user account.
46
Resetting All User Accounts
Note Commands to reset all user accounts apply only to the user information stored locally in Secure64 DNS
Cache. If you have configured RADIUS or LDAP, use your RADIUS or LDAP server to manage user and
role information configured on the server.
In an emergency situation, such as an internal security breach or if the only user assigned to a
creator role leaves the organization, a creator role can disable all user accounts. To do so, you
must enable a creator role, issue the reset command, and enter the correct reset password.
The reset command password is initially established by the Installer account when Secure64 DNS
Cache is installed.
Note If your system was preinstalled or if you want to change the reset password for other reasons, you can do
so with the passwd reset command. The command is available to creator accounts and requires you to
provide the current reset password. Be sure to store the new password in a secure location available to
authorized personnel only.
After issuing the reset command and entering the correct password, you can delete or re-enable
user accounts. Note that you must re-enable your own user account.
To reset all user accounts:

1. At the view prompt, type enable <creator_role> and press ENTER, where creator_role is
syscreate, cachednscreate, bgpcreate, logincreate, securitycreate or snmpcreate.
2. At the create prompt, type reset and press ENTER.
3. When prompted, type the reset password and press ENTER.
4. Secure64 DNS Cache disables all user accounts, with the exception of the Installer
account.
5. To enable a user account, type userenable <username> and press ENTER.
Note Be certain to enable your own user account so that it is available after you exit Secure64 DNS Cache. If
you neglect to do so and you exit the system, use the Installer account to regain access.
6. To delete a user account, see Deleting User Accounts on page 44.
47
Example:
[create@Secure64DNS]# reset
Enter reset password: **********

Installer : Installer : enabled
Joe : : disabled
Jane : : disabled
Jim : : disabled
Mary : : disabled
[create@Secure64DNS]# userenable Joe

Successfully enabled user "Joe"

Joe : : enabled
Jane : : disabled
Jim : : disabled
Mary : : disabled
[create@Secure64DNS]# userenable Jim

Successfully enabled user "Jim"

Joe : : enabled
Jane : : disabled
Jim : : enabled
Mary : : disabled
48
Authentication
Authentication is handled at the initiation of the login session by SSH or the code handling the
serial console. For SSH sessions, authentication is performed with a user account and password
OR a user account and an SSH key. For the serial console, Secure64 DNS Cache requires a user
account and password.
Note The following sections apply only to the user information stored locally in Secure64 DNS Cache. If you
have configured RADIUS or LDAP for user authentication, use your RADIUS or LDAP server to manage
user authentication. For more information, see Chapter 9. Enabling RADIUS or LDAP for User
Creating SSH Keys for User Authentication

For user authentication, Secure64 DNS Cache supports the use of SSH version 2 public/private
key pairs in the OpenSSH format.
Guidelines and information about creating the key pair include:
• Secure64 DNS Cache supports RSA and DSA (DSS) public keys that are up to 2048 bits
in length.
• Secure64 DNS Cache supports the use of a pass phrase for encryption of the key file,
which provides additional security. Use of a pass phrase is highly recommended.
• The private key in the key pair must reside on the client computer you use to access
Secure64 DNS Cache.
• The public key in the key pair must reside in your user directory on the Secure64 DNS
Cache system. (Executing a specific scp command adds the key to the appropriate
location.)
• If you access Secure64 DNS Cache from multiple client computers, you can create
multiple key pairs.
To create your SSH key pair, use a key generation program that is compliant with OpenSSH, such
as ssh-keygen (Linux/UNIX) or the PuTTY Key Generator (Windows). See www.openssh.org
for more information.
Note If you use the PuTTY Key Generator, do not use the “Save Public Key” button to save the public key
information. Instead, select the Conversions menu and select Export OpenSSH key. Then select the
“Save Private Key” button.
49
Using SSH Keys for User Authentication
Note The SSH key information applies only to the user information stored locally in Secure64 DNS Cache. If
you have configured RADIUS or LDAP for user authentication, use your LDAP server to manage user
authentication. For more information, see Chapter 9. Enabling RADIUS or LDAP for User
To add an SSH public key to your Secure64 DNS Cache log in:
1. A creator account must create a user account for you to log into Secure64 DNS Cache.
The creator account must also assign your account an initial password and role(s). If
you do not have a user account, refer to User Account Administration on page 31.
2. At the client machine you plan to use for Secure64 DNS Cache, generate a public/
private key pair. See Creating SSH Keys for User Authentication on page 49 for more
information.
3. At the client machine, type the following and press ENTER:
scp [-P <port>] <keyfilename> <user>@<Secure64_host>:/ssh/add
where:
Removing Console Interfaces on page 281 for information about changing the default port)
<keyfilename> is the name of the file containing the public key,
<user> is your Secure64 DNS Cache user account
<Secure64_host> is the Secure64 DNS Cache server IPv4 address, [IPv6 address] in
4. When prompted, enter the Secure64 DNS Cache password for your account.
5. Log into your Secure64 DNS Cache user account. If you used a pass phrase when you
created your key pair, a prompt displays for you to enter the pass phrase.
50
To remove an SSH public key from your Secure64 DNS Cache log in:
• At the client machine, type the following and press ENTER:
scp [-P <port>] <keyfilename> <user>@<Secure64_host>:/ssh/delete
where:
<keyfilename> is the name of the file containing the public key
<user> is your Secure64 DNS Cache user account
Using Passwords for Authentication
Note The password information applies only to the user information stored locally in Secure64 DNS Cache. If
you have configured RADIUS or LDAP for user authentication, use your RADIUS or LDAP server to
manage user passwords. For more information, see Chapter 9. Enabling RADIUS or LDAP for User
When a creator account establishes a user account, the creator account must also assign a
password for the account holder to use upon logging into Secure64 DNS Cache. After the first
login using this initial password, new user accounts can change their passwords using the passwd
command.
For additional security, the Secure64 server stores passwords using a scheme based on the SHA-
256 hash algorithm.
To change your Secure64 DNS Cache password:
Note Passwords must be a minimum of 8 characters and include at least 3 alphabetic characters and
at least 1 non-alphabetic character. Passwords are not recoverable. If you lose a password, you must
delete the user account and create a new user account. See User Account Administration on page 31 for
more information.
Passwords can be changed only once per 24 hours. If required, you can request a temporary password
from a login administrator as described in Modifying User Account and Password Management
Configuration on page 46.
1. Log into your Secure64 DNS Cache account, type your current password when
prompted, and press ENTER.
51
2. At the view prompt, type passwd and press ENTER.

3. When prompted, type your old (current) password and press ENTER.
4. When prompted, type your new password and press ENTER.
5. When prompted, type your new password to confirm and press ENTER.
Example:
[view@Secure64DNS]> passwd
Changing password for tester.
Enter OLD password:
Enter NEW password:

User tester password changed.
Disabling Password Authentication

When you are using SSH keys for user authentication, you may want to disable password
authentication for additional security. With SSH password authentication disabled, the user can
successfully login to the Secure64 DNS Cache via SSH only from a client system that is using
SSH keys for authentication as described on Using SSH Keys for User Authentication on page 50.
! WARNING If you disable SSH password authentication, the user must have SSH keys in place for
authentication in order to access the Secure64 DNS Cache server through SSH.
To view the password authentication status:

1. Log into Secure64 DNS Cache with an account that is assigned to the loginadmin role.
2. Type enable loginadmin and press ENTER to enable the login administration mode.
3. Type sshpwdauth and press ENTER.
4. The user accounts with password authentication enabled display.
Example:
[loginadmin@Secure64]# sshpwdauth
SSH password authentication status:
jkj: Enabled.
fred: Disabled.
Ben: Enabled.
52
To disable or enable password authentication for all user accounts:

3. Use the sshpwdauth <on|off> command to enable or disable password authentication
as follows:
— Type sshpwdauth on and press ENTER to enable password authentication for all
user accounts. (By default, password authentication is enabled for all users.)
— Type sshpwdauth off and press ENTER to disable password authentication for all
user accounts.
! WARNING The sshpwdauth off command disables SSH password authentication for all user accounts.
The users will not be able to access the Secure64 DNS Cache server through SSH unless they
have configured SSH keys for authentication. For more information, see Using SSH Keys for User
Example:
[loginadmin@Secure64]# sshpwdauth on
Enabled SSH password authentication for all
[loginadmin@Secure64]# sshpwdauth off

Disabled SSH password authentication for all
To disable or enable password authentication for a single user account:

3. Use the sshpwdauth <on|off> <username> command to enable or disable password
authentication as follows:
— Type sshpwdauth on <username> and press ENTER to enable password
authentication for a specific username. (By default, password authentication is enabled
for all user accounts.)
— Type sshpwdauth off <username> and press ENTER to disable password
authentication for a specific username.
53
Accounting
Secure64 DNS Cache logs user account activity and user administration activity to syslog.
Actions that are logged include:
• Login with an invalid user name
• Login to a user account without a password
• Login of a disabled user
• Login with an invalid password
• Successful login
• Role assignment/authorization
• Addition of a new user account
• Deletion of a user account
• Attempted password changes
• RADIUS or LDAP activity, if the Secure64 DNS Cache RADIUS or LDAP client is
configured
54
User Account Examples

In Secure64 DNS Cache, you can assign a user account as many roles as your organization’s
security policies allow. For example, you can assign the same user account to BGP and system
administration duties, or split them between several user accounts.
The following scenarios provide examples of how you can allocate roles to user accounts based
on the size and/or security policies of your organization.
Small Non-RADIUS or Non-LDAP Installation Scenario

In a smaller organization, one or two administrators may be responsible for the entire system. In
this case, roles are distributed among the administrators as illustrated in the following example.
The Installer:
• Creates Joe user account
• Assigns Joe (himself) the syscreate, bgpcreate, cachednscreate, logincreate, securitycreate,
and snmpcreate roles
Note When the syscreate, bgpcreate, cachednscreate, logincreate, securitycreate, and snmpcreate roles all
have at least one user account assigned to them, Secure64 DNS Cache automatically disables the
Installer account.
Joe user account:

• Logs in and enables syscreate
• Creates Mary user account
• Assigns Mary the syscreate, bgpcreate, securitycreate, sysadmin, upgrade, backup, and
bgpadmin roles
• Creates Jim user account
• Assigns Jim the cachednscreate, logincreate, and cachednsadmin roles
• Assigns Joe (himself) the sysadmin, cachednsadmin, bgpadmin, securityadmin, and
snmpadmin roles
Note Although Joe enabled the syscreate role, he can assign cachednsadmin, bgpadmin, and snmpadmin
roles without logging out and enabling each create role separately (because he is authorized for the
cachednscreate, bgpcreate, and snmpcreate roles).
55
The following summary shows the distribution of roles for this example:
Table 7. Small installation role distribution
Role Joe Mary Jim
syscreate X X
bgpcreate X X
cachednscreate X X
logincreate X X
securitycreate X X
snmpcreate X
sysadmin X X
upgrade X
backup X
cachednsadmin X X
bgpadmin X X
securityadmin X
snmpadmin X
Large Non-RADIUS or Non-LDAP Installation Scenario

In a larger organization, security policies can require more division of responsibilities and
privileges. In this example:
The Installer:
• Assigns Joe user account the syscreate, bgpcreate, logincreate, and securitycreate roles
• Assigns Mary user account the cachednscreate and snmpcreate roles
Mary user account:
• Logs in and enables cachednscreate
• Creates Jane user account
• Assigns Jane the cachednsadmin role
• Assigns Mary (herself) the cachednsadmin role and the snmpadmin role
• Creates Jim user account
• Assigns Jim the cachednscreate role
Joe user account:
• Logs in and enables bgpcreate
56
• Creates John user account

• Assigns John user account the bgpcreate and bgpadmin roles
• Creates Bob user account
• Assigns Bob user account the backup role
• Assigns Bob user account the securityadmin role
• Assigns Jim the syscreate role
• Assigns Joe (himself) the sysadmin and bgpadmin roles
Note Although Joe enabled the bgpcreate role, he can assign the backup role without logging out and enabling
the syscreate role separately (because he is authorized for the syscreate role).
Table 8. Large installation role distribution
Role Joe Mary Jim Bob Jane John
syscreate X X
bgpcreate X X
cachednscreate X X
logincreate X
securitycreate X
snmpcreate X
sysadmin X X
upgrade X
backup X
cachednsadmin X X
bgpadmin X X
securityadmin X
snmpadmin X
57
RADIUS or LDAP Installation Scenario

All creator roles, the sysadmin role, and the loginadmin role are required for initial network and
RADIUS or LDAP configuration when you use RADIUS or LDAP to manage user accounts.
After the initial network and RADIUS or LDAP configuration is complete, you create
additional users and assign roles using your RADIUS or LDAP server.
In this scenario, the Installer:
• Assigns Joe the syscreate, cachednscreate, bgpcreate, logincreate, securitycreate, and
snmpcreate roles
Note When the syscreate, cachednscreate, bgpcreate, logincreate, securitycreate, and snmpcreate roles all
have at least one user account assigned to them, Secure64 DNS Cache automatically disables the
Installer account.
Joe user account:

• Logs in and enables syscreate
• Assigns Mary the sysadmin and loginadmin roles
• Assigns Joe (himself) the sysadmin role
The following summary shows the distribution of roles for this example:
Table 9. Role distribution for RADIUS or LDAP

implementation
Role Joe Mary
syscreate X
bgpcreate X
cachednscreate X
logincreate X
securitycreate X
snmpcreate X
sysadmin X X
loginadmin X
Joe or Mary can configure networking for the Secure64 DNS Cache server. Mary can configure
and enable the RADIUS or LDAP client on the Secure64 DNS Cache server, and then she can
use the RADIUS or LDAP server to create user accounts, establish passwords, and assign
Secure64 DNS Cache roles to user accounts.
58
Chapter 2. Getting Started
The following sections provide detailed instructions for initial configuration. Alternatively, you
can refer to the printed Quick Start Guide included with your software or available online on the
Secure64 Support Portal.
Note If the Secure64 DNS Cache software is not pre-installed, refer to the printed Installation Guide included
with your software or available online on the Secure64 Support Portal. Complete the installation
instructions prior to configuring interfaces and routing.
Preparations for Initial Configuration

Verifying Package Contents
1. Verify you have received the following software:
— Secure64 DNS Cache Installation software
2. If you plan to use RAID, refer to Configuring RAID on page 291.
Verifying Required Equipment

To set up and configure Secure64 DNS Cache you need:
• A computer and cable to connect to the Secure64 DNS Cache eth0 interface.
Note The eth0 interface is preconfigured with IP address 192.168.64.1. As part of the system configuration
process, you will modify the IP address and netmask for your operations.
• A console connection to the iLO MP. Additional information is provided in the

following sections.
• Network information. Use the table in the next section to record initial network
information and IP address assignments.
59
Completing the Network Information Worksheet

Complete the worksheet below to record your system information prior to configuration.
Note The Secure64 DNS Cache server supports a total of 256 configured IP addresses. You can configure
each physical interface with multiple IP addresses and define VLAN IDs, up to a total allocation of 256
IP addresses for the server. In addition, you can use the same IP address for multiple services,
including the console, the DNS server, BGP, SNMP, and other services. Both IPv4 and IPv6 addresses
are supported.
Item Record IPv4 or IPv6 address information

IPv4 address and netmask or IPv6 address/prefix
length for the eth0 DNS server management
console
IPv4 address and netmask or IPv6 address/prefix
length for the DNS server(s)
IPv4 or IPv6 address for default gateway and/or
other routes (You can configure routing for
Secure64 DNS Cache to locate other resources,
such as your syslog servers.)
IPv4 or IPv6 address for syslog server(s)
(NOTE: For reporting and troubleshooting,
configuring at least one syslog server is strongly
recommended.)
IPv4 or IPv6 address for up to 5 NTP servers
IPv4 or IPv6 addresses for up to 3 name servers for

address resolution for Secure64 DNS Cache to
locate its NTP and syslog servers
Next Steps
Refer to the following sections, based on the type of installation process:
• If the software was pre-installed, proceed to Connecting and Logging into the iLO Console on
page 61.
• If you just completed installing the Secure64 DNS Cache software onsite, skip this
section and proceed to Logging Into Secure64 DNS Cache and Creating Users on page 69.
60
Connecting and Logging into the iLO Console

The following sections illustrate the necessary connections and logging into the iLO MP console
for the different HP Integrity servers that support the Secure64 DNS Cache application.
• For the HP Integrity rx2660, see the next section
• For the HP Integrity rx2800 i2/i4, see Connecting and Logging into the iLO 3 MP Console (HP
rx2800 Server) on page 65
• For the HP Integrity BL860c and BL860c i2/i4 server blades, see Connecting and Logging
into the iLO MP Console (HP Integrity Blade) on page 67
Connecting and Logging into the iLO 2 MP Console (HP rx2660 Server)
To initially configure the Ethernet interface(s) for Secure64 DNS Cache and enable management
of the server hardware, you can connect to the HP rx2660 iLO 2 MP Serial Console port (local)
or the iLO 2 MP LAN port (local or remote). Both ports connect to the server’s iLO 2 MP on the
system board and provide console access. If AC power is present, the iLO 2 MP is active, even if
the power switch is off. (For information about using the iLO 2 after initial set up, see Using the
iLO MP Console on page 17 and Additional Information About the HP Integrity iLO MP on page 19.)
Figure 3. Secure64 DNS Cache connections (HP Integrity rx2660 server, rear)
61
Using the iLO 2 MP Serial Console

For the Serial Console (iLO 2 MP) connection, you need:
— A computer that can host a vt100 terminal session
— A Female-to Female 9-pin null modem serial cable, such as a laplink cable, or a null
modem USB serial cable
To connect to the server:
1. Attach the null modem cable to the Serial Console labeled “Console |O|O|” on the
rear of the HP Integrity rx2660 and to the computer hosting the terminal console.
Note Do NOT use the serial port labeled “Auxiliary |O|O|.”
2. Attach the AC cord to the HP Integrity rx2660 and to a power source.

3. Use the front power button to power on the HP Integrity rx2660.
4. Connect to the HP Integrity rx2660 via a serial terminal. Port settings are 9600, 8N1 (8
databits, no parity, 1 stop bit), no flow control.
5. Enter Admin for the user and enter Admin for the password. (This is the default
password if you have not yet changed it. See the HP Integrity rx2660 documentation
for secure console password management details.)
6. At the MP Main Menu, type CO and press ENTER to select Console.
7. The Secure64 DNS Cache login prompt displays.
8. Proceed to Logging Into Secure64 DNS Cache and Creating Users on page 69 for
information and instructions about logging in and creating users.
Using the iLO 2 MP LAN Port

The iLO 2 MP LAN port provides a dedicated port for remote or local access to the iLO 2 MP.
For the iLO2 MP LAN connection, you need:
— A LAN cable
— A PC connected to a network that is on the same physical subnet as the server OR
an existing server on the network that you can log into and run ARP Ping
If you have not already done so, you must assign an IP address to access the iLO 2 MP through
the iLO 2 MP LAN. The following instructions provide details for configuring the IP address
using the ARP Ping method.
62
Note If you prefer to use DHCP/DNS to configure the IP address, see the HP rx2660 User Service Guide for
details).
To configure a static IP address using the ARP Ping utility:

1. Obtain the iLO 2 MP MAC address. The MAC address of the iLO 2 MP LAN on the
label located on the server front panel. (Make sure you obtain the MAC address of the
iLO 2 MP LAN and not the MAC address of the server core LAN.)
4. Verify that an active LAN cable on the local subnet is connected to the iLO 2 MP LAN
port on the server.
5. Access the PC or server you are using to assign the IP address.
6. Type arp -s <IP address to assign> <iLO MAC address> and press ENTER to assign the IP
address to the iLO MAC address.
7. Type ping <IP address assigned> to verify that the iLO 2 MP LAN port is configured with
the appropriate IP address.
63
To connect to the iLO 2 MP LAN using the assigned IP address:

1. Use SSH, telnet, or a web browser to connect to the iLO 2 MP from a host on the local
subnet.
Note To protect passwords and other private information, you should disable telnet access after initial
configuration is complete. See Disabling Telnet Access on page 77 for details.
password if you have not yet changed it. See the HP Integrity rx2660 documentation
for secure console password management details.)
3. If you used SSH or telnet, at the MP Main Menu type CO and press ENTER to select
Console. If you are using a web browser, select the Remote Console tab and the
Launch button.
64
Connecting and Logging into the iLO 3 MP Console (HP rx2800 Server)
of the server hardware, you can connect to the HP rx2800 i2/i4 iLO 3 MP Serial Console port
(local) or the iLO 3 MP LAN port (local or remote). Both ports connect to the server’s iLO 3 MP
on the system board and provide console access. If AC power is present, the iLO 3 MP is active,
even if the power switch is off. (For information about using the iLO after initial set up, see Using
the iLO MP Console on page 17 and Additional Information About the HP Integrity iLO MP on
page 19.)
Figure 4. Secure64 DNS Cache connections (HP Integrity rx2800 server, rear)
Using the iLO 3 MP Serial Console

For the Serial Console (iLO 3 MP) connection, you need:
— A computer that can host a vt100 terminal session
— A Female-to Female 9-pin null modem serial cable, such as a laplink cable, or a null
modem USB serial cable
To connect to the server:
1. Attach the null modem cable to the Serial Console labeled “|O|O|” on the rear of the
HP Integrity rx2800 and to the computer hosting the terminal console.
4. Connect to the HP Integrity rx2800 via a serial terminal. Port settings are 9600, 8N1 (8
databits, no parity, 1 stop bit), no flow control.
5. Enter Administrator for the user and the randomly generated password found on the
iLO Network Information Tag on the server. (This is the default password if you have
not yet changed it. See the HP Integrity rx2800 documentation for secure console
password management details.)
6. At the MP Main Menu, type CO and press ENTER to select Console.
65

Using the iLO 3 MP LAN Port

The iLO 3 MP LAN port provides a dedicated port for remote or local access to the iLO 3 MP.
For the iLO 3 MP LAN connection, you need:
— A LAN cable
— A console device (for example, a laptop or terminal)
If you have not already done so, you must assign an IP address to access the iLO 3 MP through
the iLO 3 MP LAN. See the HP rx2800 Installation Guide for details.
To connect to the iLO 3 MP LAN using the assigned IP address:

3. Connect the LAN cable to the iLO 3 MP LAN port.
4. Use SSH or a web browser to connect to the iLO 3 MP from a host on the local subnet.
5. Enter Administrator for the user and the randomly generated password found on the
iLO Network Information Tag on the server. (This is the default password if you have
not yet changed it. See the HP Integrity rx2800 documentation for secure console
password management details.)
6. If you used SSH, at the MP Main Menu type CO and press ENTER to select Console.
If you are using a web browser, select the Remote Serial Console option and the
Launch button.
66
Connecting and Logging into the iLO MP Console (HP Integrity Blade)
of the HP Integrity blade hardware, the server uses the iLO MP. If AC power is present, the iLO
MP is active, even if the power switch is off. (For information about using the iLO after initial set
up, see Using the iLO MP Console on page 17 and Additional Information About the HP Integrity iLO
MP on page 19.)
To access the server blade iLO MP, use the Onboard Administrator iLO (OA/iLO) port on the
rear of the enclosure or the RS-232 port on the serial, USB, video (SUV) cable. The method to
use depends on how your server blade enclosure is set up:
• If the OA iLO port on the enclosure is connected to the local network that has a DHCP
server, your iLO MP IP address is automatically generated by the DHCP server.
• If the enclosure is not connected to a network, you must configure the server through the
serial port on the SUV cable.
For detailed information about the iLO 2 MP (BL860c blade), refer to the HP Integrity BL860c
Server Blade User Service Guide, Chapter 3, in the section “Accessing the Integrated Lights Out 2
Management Processor,” available online at http://h20000.www2.hp.com/bc/docs/support/
SupportManual/c01157868/c01157868.pdf
For detailed information about the iLO 3 MP (BL860c i2/i4 blade), refer to the HP Integrity iLO 3
Operations Guide, Chapter 3, in the section “Getting Connected to iLO 3.” This guide is available
online at http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02111169-6.pdf.
Figure 5. Secure64 DNS Cache connections (HP Integrity BL860c blade server, front)
Figure 6. Secure64 DNS Cache connections (HP Integrity BL860c i2/i4 blade server, front)
67
Figure 7. Secure64 DNS Cache connections (HP BladeSystem c3000 Enclosure, rear)
To connect to the iLO 2 MP LAN (BL860c) using the assigned IP address:

1. After you have configured the iLO 2 MP connection, use SSH, telnet, or a web browser
to connect to the iLO 2 MP from a host on the local subnet.
Note To protect passwords and other private information, you should disable telnet access after initial
configuration is complete. See Disabling Telnet Access on page 77 for details.
password if you have not yet changed it. See the HP Integrity server documentation for
secure console password management details.)
3. If you used SSH or telnet, at the MP Main Menu type CO and press ENTER to select
Console. If you are using a web browser, select the Remote Console tab and the
Launch button.
5. Proceed to the next section for information and instructions about logging in and
creating users.
68
To connect to the iLO 3 MP LAN (BL860c i2/i4) using the assigned IP address:
1. After you have configured the iLO 3 MP connection, use SSH or a web browser to
connect to the iLO 3 MP from a host on the local subnet.
2. At the login prompt, enter Administrator for the user and enter the randomly generated
password found on the iLO Network Information Tag on the right side of the monarch
blade. (This is the default password. See the HP documentation for console password
details.)
3. If you used SSH or a serial terminal, at the MP Main Menu type CO and press ENTER to
select Console. If you are using a web browser, select the Remote Console tab and the
Launch button.
5. Proceed to the next section for information and instructions about logging in and
creating users.
Logging Into Secure64 DNS Cache and Creating Users

To create user accounts for Secure64 DNS Cache, you must log into the default Installer account.
Prior to completing the following steps, refer to Roles and User Accounts on page 27 and User
Account Examples on page 55 for an explanation of user accounts and example scenarios. After
reviewing the information, determine the user accounts you need and the roles to assign to each.
Note The Installer creates user accounts and assigns them to the syscreate, cachednscreate, bgpcreate,
logincreate, securitycreate, and snmpcreate roles only. The syscreate, cachednscreate, bgpcreate,
logincreate, securitycreate, and snmpcreate user accounts create and assign user accounts to their
respective administrative roles as needed for your Secure64 DNS Cache implementation.
When creating user accounts, note the following:

• You can assign multiple roles to a single user account.
• Each creator role must be assigned one user account to disable the Installer role.
• If you are not enabling BGP, you do not need to assign a user to the bgpadmin role.
• If you are not enabling RADIUS or LDAP authentication, you do not need to assign a
user to the loginadmin role, unless you plan to create an issue file to display information
when users login to the Secure64 DNS DNS Cache server.
• If you are enabling RADIUS or LDAP authentication, you must assign a user to the
sysadmin role and the loginadmin role for initial configuration of networking and
authentication (in addition to assigning all creator roles).
69
Use the worksheet below to define the local user accounts to create and the roles to assign.
Required Required
without with Account that
RADIUS or RADIUS or assigns the
Role LDAP LDAP role User account(s) to create and assign
syscreate Yes Yes Installer
cachednscreate Yes Yes Installer
bgpcreate Yes Yes Installer
logincreate Yes Yes Installer
securitycreate Yes Yes Installer
snmpcreate Yes Yes Installer
sysadmin Yes Yesa syscreate
backup Yes No syscreate
upgrade Yes No syscreate
cachednsadmin Yes No cachednscreate

Yes (if using
bgpadmin No
BGP) bgpcreate
loginadmin Yes Yes logincreate
securityadmin Yes No securitycreate

Yes (if using
snmpadmin No
SNMP) snmpcreate
a. For security purposes, you can remove the sysadmin account from the local database after RADIUS or LDAP is configured.
To begin creating user accounts and assigning create roles:

1. If not already connected, login to the iLO 2 MP console. For detailed instructions, see
Connecting and Logging into the iLO 2 MP Console (HP rx2660 Server) on page 61
2. At the login prompt, type Installer and press ENTER.
3. At the password prompt, type Installer and press ENTER.
4. Follow the prompts to create the reset command password.
! WARNING In an emergency situation, such as an internal security breach, a creator role can disable all user
accounts. To do so, you must issue the reset command and enter the correct reset password.
70
Note Be sure to store the reset password in a secure location, such as a sealed envelope in a safe that is
accessible to authorized personnel only. Passwords are not recoverable from the system. For more
information about the reset command, see Resetting All User Accounts on page 47.
5. The view mode prompt should display as shown: [view@Secure64DNS]>

6. Type enable syscreate and press ENTER to log into create mode:
[create@Secure64DNS]#
7. Type adduser <username> [options] and press ENTER.
Note The username must consist of 3-32 characters, start with an alpha character, and contain alphanumeric
characters (after the first character). User accounts are case sensitive. The realname is optional. It can
contain up to 64 characters and 10 words.
For a list of [options], see Table 5 on page 33
[create@Secure64DNS]# adduser Joe

Successfully added user Joe
Account will expire after 60 days of inactivity

Password will expire after 60 days of inactivity
Account will be locked after more than 3 failed login attempts
Failed login lockout count will be automatically reset after 60
minutes
Locked out accounts will be automatically re-enabled after 60 minutes
A password history of 5 previous passwords will be retained
Run 'passwd Joe' to set the password
8. Type passwd <username> and press ENTER to create a password for the new user
account.
[create@Secure64DNS]# passwd Joe
Changing password for Joe.
Enter NEW password:
User Joe password changed.
71
Note You must create a password so that the new user account can log in to Secure64 DNS Cache. Users
can then create SSH keys, or they can log in and change their passwords using the passwd
command, according to your organization’s security policies. See Authentication on page 49 for more
information.
9. Type the following to add the user account to the appropriate create role and press
ENTER, where <role> is syscreate, cachednscreate, bgpcreate, logincreate,
securitycreate, or snmpcreate and <username> is the user account:
[create@Secure64DNS]# usermod +r <role> <username>
10. Repeat steps 6 through 8 as needed to assign one user to each of the syscreate,
cachednscreate, bgpcreate, logincreate, securitycreate, and snmpcreate roles. (You can
assign the same user or different users to the creator roles.)
Note When each creator account has one user assigned to it, the Installer account is disabled. Even if your
organization does not plan to use a feature such as BGP or LDAP authentication, an account should
be assigned to each of the create roles. Otherwise, the default Installer account remains available and
poses a security risk.
11. When account creation and role assignment for the creator roles is complete, type exit
and press ENTER to return to the view mode prompt.
12. At the view mode prompt, type exit and press ENTER to return to the user log in
prompt.
13. The user accounts assigned to the create roles should now login to create and assign
accounts to creator and administrator roles. For detailed instructions, refer to Creating
User Accounts on page 35, Assigning Creator Roles on page 38, and Assigning Administrator
Roles on page 39.
72
Configuring the Secure64 DNS Cache Management

Console
To remove the default eth0 IP address and configure the interface for your network:
1. Attach the LAN cable to the eth0 port on the HP Integrity server and to the console
computer on your network.
2. Log into Secure64 DNS Cache with a user account assigned to the sysadmin role.
3. At the view mode prompt, type enable sysadmin and press ENTER to enable system
administration mode.
4. Enter the commands below to remove the preconfigured eth0 interface:
no ifconfig eth0 192.168.64.1
activate
5. Enter the command below to configure eth0 as a management console on your server:
ifconfig <interface> <ipv4 address> <ipv4 netmask>
or
ifconfig <interface> <ipv6 address>/<ipv6 prefix length>
where interface is defined in the form:

ethX, ethX.I, ethX:V.I, or bondX, bondX.I and
X= the number of the physical interface
V= the VLAN ID
I= the address identifier (you can use the identifier to configure additional IP addresses
for each physical interface, 1-255 for non-bonded and 1-11 for bonded interfaces)
Note You can configure each physical interface with multiple IP addresses and define VLAN IDs, up to a total
allocation of 256 IP addresses for the server. In addition, you can use the same IP address for multiple
services, including the console, the DNS server, BGP, SNMP, and other services. Both IPv4 and IPv6
addresses are supported. For more information about the ifconfig command and configuring multiple IP
addresses per interface, see Adding and Removing IP Addresses for Interfaces on page 276.
Note Ethernet bonding for failover is also supported. For details, see Configuring Ethernet Bonding on
page 284.
73
Examples:
Configure the first IPv4 address of an interface (no VLAN):
ifconfig eth0 192.168.12.14 255.255.255.0
Configure a second IPv4 address to the interface (no VLAN):

ifconfig eth0.1 192.168.0.4 255.255.255.0
Configure the first IPv6 address of an interface with a VLAN ID of 12:

ifconfig eth0:12 2001:db8:aaa:bbb:/64
Configure the second IPv6 address of an interface with a VLAN ID of 12:

ifconfig eth0:12.1 2001:db8:ccc:ddd:/64
6. Enter the command below to set the interface as the management console:
console [-P <port>] [-S <sessionmax>] <interface>
where <port> is the port to listen on (defaults to 22 if not defined), <sessionmax> is

the maximum number of simultaneous connections (from 1-255; defaults to 5 if not
defined), and <interface> is defined in the form:
ethX, ethX.I, or ethX:V.I and
V= the VLAN ID
I= the address identifier
7. Type activate and press ENTER to initiate the changes.
8. Type save and press ENTER to save the changes.
9. For additional security, you can restrict access to the console. For more information, see
Restricting Console Connections on page 242.
Example:
[sysadmin@Secure64DNS]# no ifconfig eth0 192.168.64.1
[sysadmin@Secure64DNS]# activate
stopping interface eth0
Running configuration changed
[sysadmin@Secure64DNS]# ifconfig eth0:1.1 192.168.12.14 255.255.255.0

[sysadmin@Secure64DNS]# console eth0:1.1

eth0:1.1 console enabled
74
stopping interface eth0, address 192.168.64.1
starting interface eth0:1.1, address 192.168.12.14
[sysadmin@Secure64DNS]# save
running configuration successfully saved
Note If you need to modify the console IP address after initial configuration, see Changing the IP Address of a
Console Interface on page 282.
Configuring the Default Gateway and Other Routes

The default gateway should generally point to the next external-facing router, most likely your
first outbound router.
To configure the default IPv4 or standard IPv6 gateway:

1. Enter the following command at the sysadmin prompt, where <gateway> is the IPv4 or
IPv6 address of the gateway for all traffic without a specified route:
route default <ipv4_or_ipv6_gateway>
Example:
[sysadmin@Secure64DNS]# route default 10.0.0.1
[sysadmin@Secure64DNS]# route default 2001:db8::1


Note You can configure routing for Secure64 DNS Cache to locate other resources, such as your syslog
server(s). For detailed information about routing configuration, see Configuring the Default Gateway and
Other Routes on page 252.
75
Note The Secure64 DNS Cache server also supports default route using an IPv6 link local address. For
details, see Adding an IPv6 Link Local Default Gateway on page 254.
For information about configuring inbound routing, see Configuring In-Bound Traffic Routing Style on
page 255.
To add other routes:

1. Enter the following command at the sysadmin prompt::
route net <ipv4 address> <ipv4 netmask> <gateway>
or
route net <ipv6 address>/<ipv6 prefix length> <gateway>
Example:
[sysadmin@Secure64DNS]# route net 192.168.255.0 255.255.255.0
10.1.2.3
[sysadmin@Secure64]# route net 2001:db8:aaa:bbb:/64 2001:db8::1


Verifying the Console Interface

To verify that the console interface is functioning, ping an external IPv4 or IPv6 address or
hostname from the interface you configured, as follows:
1. Login as a user assigned to the sysadmin role.
2. At the view prompt, type enable sysadmin and press ENTER.
3. At the sysadmin prompt, enter the ping or ping6 command for an external IP address
of hostname from the management port (for ping6, you can use the optional
[datasize] to define the number of octets to send, from 1-1500):
ping <interface> <external ipv4address|hostname>
or
ping6 <interface> [datasize] <external ipv6address|hostname>
Example:
[sysadmin@Secure64DNS]# ping eth0:1.1 192.168.95.95
ping to 192.168.95.95 on interface eth0:1.1
ping successful
76
[sysadmin@Secure64DNS]# ping6 eth1.1 2001:db8::1

ping to 2001:db8::1 on interface eth1.1
ping successful
4. If the ping command is not successful, enter show config and verify network settings
and routing information. Also check cable connections and try pinging a different
external machine. If necessary, use the no ifconfig command to remove an incorrect
configuration and the ifconfig command to correct the configuration.
Disabling Telnet Access

Telnet access is enabled by default on the HP server’s iLO 2 interface (rx2660 server and BL860c
server blade). To protect passwords and other private information, you should disable telnet
access.
To disable telnet access on the HP Integrity server iLO 2 interface:

1. Log into the iLO 2 MP console. For detailed instructions, see Using the iLO MP Console on
page 17.
2. At the MP Main Menu, type CM and press ENTER to select Command Menu.
3. Type SA and press ENTER to modify the MP access configuration.
4. Follow the onscreen prompts to disable telnet access.
77
Configuring DNS Interface(s)

The Secure64 DNS Cache server supports a total of 256 configured IP addresses. You can
configure each physical interface with multiple IP addresses and define VLAN IDs, up to a
total allocation of 256 IP addresses for the server. In addition, you can use the same IP address
for multiple services, including the console, the DNS server, BGP, SNMP, and other services.
Both IPv4 and IPv6 addresses are supported.
To configure DNS interfaces:

1. At the sysadmin prompt, type the following command:
or

V= the VLAN ID
I= the address identifier (you can use the identifier to configure additional IP
addresses for each physical interface, 1-255 for non-bonded and 1-11 for bonded
interfaces)
Note Ethernet bonding for failover support is also supported. For details, see Configuring Ethernet Bonding
on page 284.
2. Repeat the ifconfig command for each additional interface you want to configure.
Secure64 DNS Cache supports a total allocation of 256 IP addresses on the server.
3. To initiate the configuration settings, type activate and press ENTER.
4. To save the new configuration, type save and press ENTER.
5. To verify the interface is functioning, enter the ping or ping6 command for an
external IP address or hostname from the management port (for ping6, you can use
the optional [datasize] to define the number of octets to send, from 1-1500):
ping <interface> <external_ipv4|hostname>
or
ping6 <interface> [datasize] <external_ipv6|hostname>
78
Example:
ping successful

ping successful
Attaching Mitigation Rules to Console and DNS

Interfaces
To provide initial security and attack mitigation for the console and DNS interfaces you have
configured, Secure64 DNS Cache provides default rules to limit UDP, TCP, and SSH attack
traffic. To make the rules operable, you must attach them to the interfaces you configure.
Note The provided rules are a recommended minimum that may or may not apply to your system needs. After
initial configuration and testing are complete, refer to Defending Against DNS DDoS Attacks on page 224
for details about refining the attack mitigation rules according to your specific system needs and
architecture. For additional console security, also refer to Restricting Console Connections on page 242.
To attach the provided SSH limit rule to your console interface(s):

attach <interface> LOGINLIM
where <interface> is the console interface in the form of ethX, ethX.I, ethX:V.I,
or bondX, bondX.I and
V= the VLAN ID
2. Repeat the previous command for each console interface.
79
Note The provided console rule limits the number of established TCP connections on port 22 (SSH logins)
to 8 per minute.
To attach the provided UDP and TCP rules to your DNS interface(s):
attach <interface> UDPQUERYLIM TCPXFERLIM
where <interface> is the DNS interface in the form of ethX, ethX.I, ethX:V.I,
or bondX, bondX.I and
V= the VLAN ID
2. Repeat the previous command for each DNS interface.
Note The provided UDP and TCP rules limit UDP queries incoming on port 53 to 92,160 per second
(90x1024) and TCP packets incoming on port 53 to 10,240 per second (10x1024).
Configuring Interfaces for Additional Services

Configuring syslog
To facilitate system monitoring and reporting, you should configure at least one syslog server
for the Secure64 DNS Cache system. Syslog messages are designed to report system health,
notify you of potential attacks, track DNS traffic, and record other important server activity.
Secure64 DNS Cache also includes a local logging feature that records a portion of the syslog
messages to a local file. You can display the file contents at the command line and export the
local log to another system.
For details about configuring syslog and using the local logging tool, see Managing Syslog Servers
and Local Logging on page 269. For a list of syslog messages and recommended actions, see
Appendix B. Syslog and System Boot Messages on page 443.
80
Note Secure64 DNS Cache supports up to four syslog servers. Configuring at least one syslog server
is strongly recommended. Certain actionable error messages that may not be available at the
command line are sent to syslog.
Configuring BGP, SNMP, and RADIUS or LDAP Interface(s)

• If you plan to enable and use BGP, refer to BGP Configuration Preparations on page 313 for
details about interfaces and IP addresses required for BGP.
• If you plan to enable and use SNMP, refer to Importing the Secure64 DNS Cache MIBs into the
NMS on page 394.
• If you plan to enable and use RADIUS or LDAP, you can configure a specific interface
for the client, or you can allow Secure64 DNS Cache to automatically select an existing
interface. See Server, Client, and Search Attributes on page 354 for more information.
Note The bgpadmin and loginadmin roles do not have access to interface and system configuration
commands; the sysadmin role must configure the interface(s) and IP addresses.
81
Checklists for Configuring Additional System Settings

To configure additional system settings, refer to Table 10. With the exception of configuring
BGP and authentication, the sysadmin role performs these tasks.
Table 10. Additional system configuration tasks
Completed Description Reference

Set the system nodename. This is the name that
identifies the Secure64 DNS Cache system, for Configuring a Nodename on page 258
example, in syslog and at the command prompt.
Configuring the Default Gateway and Other
Configure routing for the Secure64 DNS Cache
Routes on page 252 and Configuring In-Bound
system, as needed.
Traffic Routing Style on page 255
Configure up to three name servers to act as
DNS server(s) for DNS address resolution for the
Configuring System Name Servers on page 259
Secure64 DNS Cache system to locate its NTP
and syslog servers.
Set the time zone for the Secure64 DNS Cache
Defining the Time Zone on page 260
system.
Configure the NTP server(s) for the Secure64
Managing NTP Servers on page 263
DNS Cache system.
Configure the syslog server(s) and local logging Managing Syslog Servers and Local Logging on
for the Secure64 DNS Cache system. page 269
Recommendations and Best Practices on
Review DNS security best practices information.
page 249
Defending Against DNS DDoS Attacks on
Define DoS and DDoS rules.
page 224
Limit the systems allowed to establish a
Restricting Console Connections on page 242
connection with the console via SSH.
Enable SNMP (optional). Implementing SNMP on page 391
Configure RAIDUS or LDAP authentication Chapter 9. Enabling RADIUS or LDAP for User
(optional). Authentication on page 331
Chapter 8. Enabling BGP for Anycast on
Configure BGP (optional).
page 303
82
About Secure64 DNS Cache Administration

For security purposes, users and roles compartmentalize administration of the Secure64 DNS
Cache server. Not all features and capabilities are available to each role.
This section discusses operating features and the roles that can access each. Table 11 summarizes
the operating features and applicable roles.
Table 11. Server administration feature compartmentalization
Feature Secure64 DNS Cache Role(s) Reference

System Configuration States on
System configuration states sysadmin, loginadmin
page 83
cachednsadmin, bgpadmin, File System and Text Editor
File system commands
loginadmin, snmpadmin Commands on page 88
cachednsadmin, bgpadmin,
Text editor About the Text Editor on page 89
loginadmin, snmpadmin
Rebooting the Secure64 DNS
Reboot system sysadmin, upgrade, securityadmin
Cache Server on page 87
Powering Off the Secure64 DNS
Shut down system sysadmin
Cache Server on page 88
System Configuration States

About Configuration States
System configuration tasks performed in the sysadmin role use three configuration states:
pending, running, and saved. The system configuration states allow you to make changes to the
configuration and test them prior to saving the changes.
Table 12. Configuration states
State Description
pending The modified configuration that has not been saved.
If you have not issued the activate command, use the discard command to
remove pending modifications.
running The configuration that is currently running, which may be different than the
saved configuration.
If you modify configuration settings, issue the activate command to make the
changes the new running configuration. Use the revert command to reverse
the activated changes and return to the saved configuration state.
saved The configuration saved in the configuration file that is read on startup.
Issue the save command for a running configuration file to overwrite the
existing saved configuration.
After issuing the save command, you cannot return to the previous
configuration.
83
Note For system configuration changes to be saved and in effect upon rebooting the machine, the sysadmin
mode must issue the activate and save commands. For RADIUS or LDAP configuration
changes to be saved and in effect upon rebooting the machine, the loginadmin mode must issue the
activate and save commands.This does not apply to DNS configuration file cache.conf
changes, BGP configuration file bgp.conf changes, or SNMP configuration file snmpd.conf
changes.
Figure 8. Configuration states
Using Configuration State Commands

Figure 8 above illustrates the flow of configuration states as follows:
1. When the system boots, it reads the Saved Configuration, which becomes the Running
Configuration.
2. When you type configuration changes (using the CLI) the changes become the Pending
Configuration.
84
3. You can activate or discard the Pending Configuration.

If you enter activate, the Pending Configuration becomes the Running Configuration.
If you enter discard, the system returns to the Saved Configuration.
Note If the console session times out before you activate a pending configuration, the system returns to the
Saved Configuration. In addition, if multiple user accounts have enabled the sysadmin role and are
modifying the system configuration, one of the user accounts may be instructed to use the discard
command. Doing so ensures that the user account is working with the most current configuration.
4. You can revert or save an activated configuration:

If you enter revert, the system returns to the Saved Configuration.
If you enter save, the Running Configuration becomes the new Saved Configuration.
Viewing Configuration Settings

You can view system configuration settings by typing the following:
show <cmd>
where <cmd> is:

— pending: Displays configuration information that is invoked when the administrator
enters the activate command
— config: Displays current system configuration
— saved: Displays configuration information saved in the configuration file that invokes
at the next boot of the system
Note The show command is available in all operational modes.
You can view information about the physical hardware network interfaces by typing the following
command:
• show interfaces
85
Example:
[view@Secure64DNS]> show interfaces
Interfaces:
eth0: Oct 25 16:42:19 MDT Ethernet 00:1a:4b:08:ef:6a i82546_3

IPv6 link-local fe80::21a:4bff:fe08:ef6a
Speed:1000Mb/s Duplex:Full Link up:Yes
RX packets:631478 errors:0 dropped:0
TX packets:7144 errors:0 dropped:0
RX bytes:53948428 TX bytes:457216
eth1: Oct 25 16:42:19 MDT Ethernet 00:1a:4b:08:ef:6b i82546_3

IPv6 link-local fe80::21a:4bff:fe08:ef6b
Speed:10Mb/s Duplex:Half Link up:Yes
eth2: Oct 25 16:42:19 MDT Ethernet 00:1c:c4:fc:d3:ff BCM5704C

IPv6 link-local fe80::21c:c4ff:fefc:d3ff
Speed:Unknown Duplex:Unknown Link up:No
eth3: Oct 25 16:42:19 MDT Ethernet 00:1c:c4:fc:d3:fe BCM5704C

IPv6 link-local fe80::21c:c4ff:fefc:d3fe
lo0: Oct 25 16:42:19 MDT Loopback 00:00:00:00:00:00

IPv6 link-local fe80::200:ff:fe00:0
For a complete description of the interface information that displays, see Displaying Physical
Interfaces on page 378.
86
Rebooting and Powering Off

The HP Integrity server iLO management port offers out-of-band system management
capabilities such as powering the system up and down. However, you should use the Secure64
DNS Cache command line to reboot the server as instructed below.
Note Rebooting the Secure64 DNS Cache server should be performed at the Secure64 DNS Cache command
line.
Rebooting the Secure64 DNS Cache Server

To reboot the Secure64 DNS Cache server:
1. To determine whether the DNS server is running, type show cachedns status and press
ENTER.
If DNS is running, login as a user assigned to the cachednsadmin role, enable
cachednsadmin, and issue the stop cachedns command to stop the DNS server.
2. To determine whether BGP is running, type show bgp status and press ENTER.
If BGP is running, login as a user assigned to the bgpadmin role, enable bgpadmin, and
issue the stop bgp command to stop the BGP service.
3. To determine whether SNMP is running, type show snmp status and press ENTER.
If SNMP is running, login as a user assigned to the snmpadmin role, enable snmpadmin,
and issue the stop snmp command to stop the SNMP service.
4. Enable the securityadmin role or the sysadmin role, type reboot, and press ENTER.
5. A prompt appears on-screen allowing you to confirm (Y) or cancel (N) the reboot before
it actually occurs.
[sysadmin@Secure64DNS]# reboot
are you sure? (y/n)
6. Press Y to continue, N to cancel.

7. The system closes the connection and restarts.
8. Start DNS, BGP, and/or SNMP as necessary by enabling the cachednsadmin role and
entering start cachedns (for DNS), enabling the bgpadmin role and entering start bgp
(for BGP), and/or enabling the snmpadmin role and entering start snmp.
87
Powering Off the Secure64 DNS Cache Server

To completely power down the Secure64 DNS Cache server, you must stop the Secure64 DNS
Cache running services at the command line as instructed below.
To power off the Secure64 DNS Cache server:

1. Log into a Secure64 DNS Cache user account assigned to the cachednsadmin role.
2. The view mode prompt displays: [view@Secure64DNS]>
3. At the view mode prompt, type enable cachednsadmin and press ENTER to log in
to cachednsadmin mode.
4. Type stop cachedns and press ENTER to stop the Secure64 DNS Cache server.

Stopping cachedns
Stopped cachedns
5. If BGP is also running log into a Secure64 DNS Cache user account assigned to the
bgpadmin role, enter enable bgpadmin, enter stop bgp, and enter exit twice.
6. If SNMP is also running, log into a Secure64 DNS Cache user account assigned to the
snmpadmin role, enter enable snmpadmin, enter stop snmp, and enter exit twice.
7. To power off the server, log into a Secure64 DNS Cache user account assigned to the
sysadmin role, enter enable sysadmin, and enter halt.
8. A prompt appears on-screen allowing you to confirm (Y) or cancel (N).
[sysadmin@Secure64DNS]# halt
are you sure? (y/n)
9. Press Y to continue, N to cancel.

10. If you select Y, the server powers down.
File System and Text Editor Commands

The Secure64 DNS Cache file system and text editor commands are available in the
cachednsadmin, bgpadmin, and loginadmin roles only. The commands provide basic
directory and text-editing capabilities.
Note To enhance security for DNS data and configuration files, other operational modes cannot perform
directory-related functions such as removing directories, creating directories, or viewing directory
contents.
88
About Directory Commands

As noted, directory commands are available in cachednsadmin, bgpadmin, loginadmin, and
snmpadmin roles only. The commands follow UNIX/Linux conventions as described in
Table 13:
Table 13. File system commands
Command Description
cat <file> Display the contents of the specified file. Note that the
system displays as much as is allowed by the screen buffer.
cd [directory] Change to the specified directory. If a directory is not
specified, change to the top-level directory.
cp [-r] <source> <destination> Copy one or more files and/or directories. If more than one
source is defined, destination must be a directory. Use -r to
copy the entire directory tree starting with source to the
destination directory.
ls [-R] [directory|file] Display the contents of the current directory (if no directory is
defined) or the specified directory or file. Wildcards are
permitted and multiple files/directories can be defined.
Include the -R argument to include descendent directories.
edit <file> Load the specified file in the Secure64 text editor.
mkdir [-p] <directory> Create the specified directory, for example:
mkdir data. Include -p to create subdirectories, for
example: mkdir -p data/zones/example
mv <from > <to> Move or rename the from filename to the to filename, within
the same directory or different directories.
rm [<file>|-r <directory>] Delete the specified file or directory. Wildcards are permitted
and multiple files/directories can be specified. If specifying a
directory, the -r argument is required to remove all
descendent directories and files.
rmdir <directory> Remove the specified directory. The directory must be
empty.
touch <file> Change the modification time of the specified file to the
current time. If the specified file does not exist, it is created.
About the Text Editor

For most text editing tasks, edit files offline using the editing application of your choice. You can
use the secure copy command to copy files to and from Secure64 DNS Cache for offline editing.
(For details about using secure copy, see Secure Copy on page 23.)
For convenience, Secure64 DNS Cache includes a basic text editor for small editing tasks directly
on the name server.
89
90
Chapter 3. Configuring Secure64 DNS Cache
Overview
The configuration file cache.conf defines the DNS server’s caching and resolver options. DNS-
related configuration tasks require you to login to cachednsadmin mode. For more information
about operational logins, see Roles and User Accounts on page 19.
Configuration attributes allow you to control basic server operations, cache sizes, local zone
information, and hardening for security.
Note For more advanced configuration information, such as configuring DNSSEC, forward zones to forward
queries to a different resolving DNS server, and stub zones to obtain authoritative answers to queries
without resolver processing, see Chapter 4. Advanced Configuration Topics on page 127.
Use the following references to locate information in this chapter:

• If you are configuring a new Secure64 DNS Cache server, refer to Checklist for
Configuring New DNS Caching Servers on page 92.
• If you need to modify configuration settings, refer to the references below:
Configuration File Format and Rules ............................................93
Creating the Initial Configuration File ............................................94
Configuring Basic Server Attributes ..............................................96
Configuring Performance Attributes ............................................101
Configuring Caches and Internal TTL Values .............................104
Configuring Local Zones .............................................................108
Configuring for Basic Security..................................................... 118
Using Include Files......................................................................124
91
Checklist for Configuring New DNS Caching Servers

The following checklists contain the steps to configure, start, and test a new Secure64 DNS
Cache server.
Table 14. Checklist for configuring new DNS caching servers
Completed Step Description Reference

Review the rules and format information for the The Cache Configuration File on
1
cache.conf file. page 93
Scp the test cache.conf on the Secure 64 DNS
Cache server to another system and open it with Creating the Initial Configuration File
2
your preferred text editor or create a new on page 94
cache.conf file with your preferred text editor.
Configuring Basic Server Attributes on
page 96
Configuring Performance Attributes on
Add/edit general attributes in the server: clause page 101
3
of the cache.conf configuration file.
Configuring Caches and Internal TTL
Values on page 104
Configuring Local Zones on page 108
Add/edit security attributes in the server: clause Configuring for Basic Security on
4
of the cache.conf configuration file. page 118
Starting and Stopping the Name Server
5 Start and test the name server. on page 184
Testing the Name Server on page 189
Chapter 6. Secure Configuration on
Securely configure the Secure64 DNS Cache server page 203
6 network and system settings before placing the
server into production. Chapter 7. System Administration on
page 221
Enabling DNSSEC-Validated Queries
on page 128
Defining Resolver Forwarding on
page 138
Defining Stub Zones on page 140
Configuring IPv6 Transition
If you want to configure more advanced features, Technologies on page 148
7 refer to the applicable information in Chapter 4.
Advanced Configuration Topics as noted. Redirecting NXDOMAIN Responses on
page 156
Defining Views on page 163
Advanced Security Configuration on
page 172
Specifying an Unbound Configuration
File on page 177
8 Configure and monitor DNS query activity (optional). DNS Query Logging on page 211
Configure and monitor caching server performance, Server Activity Reporting and Statistics
9
security, and activity statistics (optional). on page 215
92
The Cache Configuration File

About the Configuration File
The configuration file cache.conf defines options for the DNS caching server. The
configuration is based on the Unbound caching DNS server (www.unbound.net), which provides
support for DNSSEC validation, security, and performance.
If you already have an Unbound configuration file in place, you can include it for use by Secure64
DNS Cache, as discussed in Specifying an Unbound Configuration File on page 177.
The following sections provide details about the cache.conf configuration file.
Note Secure64 DNS Cache does not support all of the configuration attributes in the Unbound server. For
more information, see Appendix C: Unbound Configuration Differences on page 479.
Configuration File Format and Rules

The cache.conf configuration file uses the following format and rules:
• The file consists of one required clause and several optional clauses:
— server: (required; one clause allowed) contains attributes that define base
functionality, security, local data, NXDOMAIN redirection, and other features.
— stub-zone: (optional; multiple clauses allowed) configures authoritative data to be
used by the resolver that cannot be accessed using the public Internet servers.
— merge-zone: (optional; multiple clauses allowed) defines authoritative servers that
the Secure64 DNS Cache server uses explicitly to obtain and provide answers as if it is
an authoritative server.
— forward-zone: (optional; multiple clauses allowed) lists name servers to forward
queries to handle further recursion of the query.
— views: (optional; multiple clauses allowed) defines a set of information to provide to
specific requesters.
! WARNING You must list the server: clause, stub-zone: clause, merge-zone: clause,
forward-zone: clause, and all related attributes before any view: clauses and attributes.
• Options within each clause are defined with attributes and values. Some attributes contain
additional attributes. The notation is attribute: value
• There must be whitespace after the colon that ends a clause or attribute and is followed
by an option or value.
93
• Quotation marks are optional for value strings, unless otherwise noted. Note that if the
string includes spaces, quotation marks are required.
• Comments start with # and continue to the end of the line.
• Empty lines and whitespace at the beginning of a line are ignored.
• Both IPv4 and IPv6 addresses are supported.
• If an attribute is listed multiple times and multiple attributes are not supported for that
item, the last value specified is used.
• Files can be included using the include: attribute. The attribute can appear anywhere.
It takes a single filename as an argument, and you can nest include files 10 deep.
Processing occurs as if the text from the included file is present at the point the
attribute appears. For details, see Specifying an Include File on page 124.
• To view the contents of the example configuration file included with Secure64 DNS
Cache, refer to Appendix D: Example Configuration File on page 483.
Editing the Configuration File

Creating the Initial Configuration File
Secure64 DNS Cache provides three options for creating the cache.conf configuration file:
• Use the sample s64_example.conf in the default directory of cachednsadmin mode,
make a copy named cache.conf, and edit it for your DNS server requirements
• Use the sample s64_example.conf in the default directory of cachednsadmin mode,
make a copy named cache.conf, and edit it to include an existing Unbound
configuration file (see Using Include Files on page 124 for more information)
• Start with an empty cache.conf file
Using a Text Editor to Change the Configuration File

Unless you are making minor changes to the configuration file, using scp to copy the
configuration file to another system for editing is recommended. If you are making minor
changes to the configuration file, you can use the built-in text editor as described below.
To securely copy the configuration file to another system for editing outside of
Secure64 DNS Cache:
• The syntax is:
scp [-P <port>] <user>@<host>:/cachednsadmin/<file> <destination>/
cache.conf
where:
<user> is a Secure64 DNS Cache user account assigned to the cachednsadmin role
94
<file> is the sample s64_example.conf (new systems) or the cache.conf file
(existing systems)
<destination> is the location to copy the file to
After editing the file outside of Secure64 DNS Cache, securely copy the cache.conf file to
the Secure64 DNS Cache server:
• Type the following at a client machine, and press ENTER:
scp [-P <port>] cache.conf <user>@<host>:/cachednsadmin/
where:
To edit the cache.conf file using the basic text editor included in Secure64 DNS Cache
(designed for small editing tasks):
1. Login as a user assigned to the cachednsadmin role.
2. At the view prompt, type enable cachednsadmin and press ENTER.
3. Type edit cache.conf and press ENTER.
4. The editor screen displays 24 lines of the file contents at one time, and it supports 80
characters per line. Use the arrow keys and control commands to navigate the file
contents. The keyboard control commands for the editor are listed at the top of the editor
screen.
Loading the Configuration Changes

A new or modified cache.conf configuration file must be located in the default directory of the
cachednsadmin user. To make the changes effective, you also need to stop the server if it is
running, then start the server. Or you can reload the configuration changes dynamically.
• For detailed instructions about stopping and starting the server, see Starting and Stopping the
Name Server on page 184.
• For detailed instructions about reloading configuration changes dynamically, without
stopping and starting the server, see Reloading Configuration Changes Dynamically on
page 185.
95
Standard Configuration Attributes

Configuring Basic Server Attributes
Table 15 identifies the basic server: clause configuration attributes. Many of these
configuration items use default settings. However, you should carefully examine the defaults to
ensure that they are correct for your operations.
Note Many attributes use default values if they are not defined. However, for ease of reference, it is strongly
recommended that your cache.conf configuration file reflect the default values, which are
included in the example file installed on the Secure64 DNS Cache server.
In addition, ensure that the following attributes are configured correctly for your system and
DNS operations:
• interface:
The IPv4 or IPv6 address(es) to answer queries from.
• outgoing-interface:
The IPv4 or IPv6 address(es) to send queries to authoritative servers and receive their
replies.
• access-control:
The clients that can make recursive queries to this server. The default is to refuse all
except the local host. This attribute allows you to whitelist/blacklist IP addresses that
can use the server for recursive queries.
These attributes are critical to define the clients that can access the server and receive DNS
responses. Refer to Table 15 for a complete description of each attribute.
Table 15. DNS configuration file: server clause attributes
Attribute: Value
Example(s) Description
auto-start: <no|yes> Set to yes for the Secure64 DNS Cache server to automatically
auto-start: no start when the system is rebooted. If problems occur during
autostart, see Troubleshooting Startup Errors on page 192.
If not defined, the default is no.
auto-bgp: <no|yes> Ensures that BGP is enabled only when the DNSserver is
auto-bgp: no running. When set to yes, causes BGP to automatically start
when the DNS server starts and automatically stop BGP when
the DNS server stops.If not defined, the default is no.
Note: Do not use the autostart parameter in bgp.conf
when auto-bgp is yes.
96
Attribute: Value
interface: <ip_address> Specify the set of IPv4 and IPv6 addresses to listen for queries
interface: 192.0.2.153 from clients and provide answers back to clients.
interface: 2001:DB8::5 At least one address must must be specified, and the addresses
must already be configured with the ifconfig command in the
sysadmin role.
Specify 0.0.0.0 to listen on all configured IPv4 addresses, and
specify ::0 to listen on all available IPv6 addresses.
Specify one or more IP addresses on a separate interface: lines.
port: <number> Use for testing purposes to answer DNS queries on the
port: 53 specified port.
If not defined, the default is 53 (the standard DNS port).
outgoing-interface: <ip_address> Specify the source IP address(es) used to send outgoing
outgoing-interface: 192.0.2.153 queries to authoritative servers. In general, the Secure64 DNS
outgoing-interface: 2001:DB8::5 server selects the outgoing interface to use based on the route
to the destination server. You should ensure that default routing
and IP addresses are configured such that the Secure64 DNS
Cache server can reach the necessary authoritative servers.
If you define multiple outgoing-interface: attributes,
and multiple interfaces are routable to the destination server,
the Secure64 DNS Cache server randomizes the interface
selection for security purposes.
If only one outgoing-interface: is configured, it is used
as the source address regardless of routing. For example, if
destination servers are on the Internet but the default route is
not routable to the Internet, define one outgoing interface.
If no outgoing interfaces are defined, the Secure64 DNS Cache
server selects and randomizes all of the system-configured IP
addresses that match the routing to the destination server.
access-control: <ip netblock> Define the clients that can make recursive queries to this server.
<allow|deny|refuse> The default is to refuse all except the local host.
access-control: 192.168.1.0/24 allow The <ip netblock> is an IP4 or IP6 address with
access-control: 127.0.0.0/8 allow /size appended for a classless network block.
access-control: ::ffff:127.0.0.1 allow Options for the action to take:
access-control: 0.0.0.0/0 refuse
access-control: ::0/0 refuse allow: The server gives access to clients from the defined
netblock. It gives access only to recursion clients--
nonrecursive queries are refused.
deny: The server drops messages from the defined clients
with no response.
refuse: The server drops messages from the defined clients
and responds with a DNS rcode REFUSED error message.
do-ip4: <no|yes> Enable or disable whether IPv4 queries are answered or issued.
do-ip4: yes If not defined, the default is yes.
97
Attribute: Value
do-ip6: <no|yes> Enable or disable whether IPv6 queries are answered or issued.
do-ip6: yes If disabled, queries are not answered on IPv6, and queries are
not sent on IPv6 to the Internet nameservers.
If no IPv6 interfaces are configured on the system, setting do-
ip6 to “no” can improve performance.
If not defined, the default is yes.
do-tcp: <no|yes> Enable or disable whether inbound TCP queries are accepted.
do-tcp: yes If not defined, the default is yes.
incoming-num-tcp: <number> Define the number of incoming simultaneous TCP buffers. If set
incoming-num-tcp: 10 to 0, or if do_tcp is "no", no TCP queries from clients are
accepted
If not defined, the default is 10.
edns-buffer-size: <bytes> Number of bytes to advertise as the EDNS reassembly buffer
edns-buffer-size: 4096 size. This value is placed in datagrams over UDP to peers.
If fragmentation reassembly problems occur, usually seen as
timeouts, a value of 1480 may help. Setting to 512 bypasses
even the most stringent path MTU problems, but is seen as
extreme, since the amount of TCP fallback generated is
excessive. (For more information about IP fragmentation
settings, see Configuring IP Fragmentation Resource Limits on
page 226.)
Minimum is 512 and the maximum is 65535. If not defined, the
default is 4096.
root-hints: <filename> Define a root hints file for the resolver. The file has the format of
root-hints: root.hints DNS zone files, with root name server names and addresses.
Because the built-in default may become outdated when
servers change, it is good practice to define and use a root hints
file. You can obtain a current file at
ftp://FTP.INTERNIC.NET/domain/named.cache
Use scp to copy the current root hints file to the Secure64 DNS
Cache server. For more information about the scp command,
see Secure Copy on page 15.
Note: If your network is not connected to the Internet, you must
define a root hints file and replace the NS and A records with
NS and A records of the authoritative DNS servers for the root
of your private TCP/IP network.
If root hints is not defined, the server defaults to built-in root
hints for the IN class. If you define a custom root hints file,
ensure that it includes IPv4 and/or IPv6 address type(s) that
correspond to your defined outgoing interfaces. If it does not,
the server uses the default root hints.
To define different root hint files, such as for internal and
external queries, use views. For more information, see Defining
Views on page 163.
98
Attribute: Value
minimal-responses: <yes|no> Define which sections to return in DNS responses. If no, return
minimal-responses: no the Answer, Authority, and Additional sections. If yes, respond
with the Answer section only, unless the query specified
DNSSEC or the answer is an NXDOMAIN response with an
associated SOA in the Authority section.
Setting the attribute to yes can speed up performance.
If not defined, the server defaults to no and includes the Answer,
Authority, and Additional sections in DNS responses.
rrset-roundrobin: <yes|no> Define whether to rotate the order of RRs within RRsets in DNS
rrset-roundrobin: no responses. If no, the order is not rotated. If yes, the order is
rotated (the random number source is the query ID).
99
The following is an example of the server: clause portion of the cache.conf configuration
file using the basic configuration attributes.
Note These attributes provide basic functionality for the server. Additional attributes control other features
such as security, performance, local zones and data, forward zones, stub zones, merge zones, and
views as discussed in following sections and chapter. To view the contents of the example
configuration file included with Secure64 DNS Cache, refer to Appendix D: Example Configuration File
on page 483.
Example:
# This is a comment.
server:
#auto-start caching server on reboot
auto-start: yes
#interfaces to listen to queries from clients and send

#responses to clients
#for all/any use interface: 0.0.0.0 or interface: ::0
interface: 192.168.127.99
interface: 2001:DB8::5
port: 53
#interfaces for resolving queries, server uses in random order

#if not defined, server uses all interfaces in random order
#outgoing-interface: 192.0.2.1
#control clients that can access the server

access-control: 192.168.0.0/16 allow
access-control: ::1 allow
access-control: 217.132.248.134 deny
#Other Options
do-ip4: yes
do-ip6: yes
do-tcp: yes
incoming-num-tcp: 10
edns-buffer-size: 4096
#define a root hints file

root-hints: root.hints
#define whether to return minimal responses (Answer section only)

minimal-responses: no
100
Note To view the entire contents of the example configuration file included with Secure64 DNS Cache, refer to
Appendix D: Example Configuration File on page 483.
Configuring Performance Attributes

For DNS caching servers, performance is normally measured by latency and throughput:
• Latency is defined as the time to answer a particular query. Latency measures the
efficiency of the resolver process and depends on factors such as network speed and
congestion, Internet congestion, authoritative server congestion, authoritative server
availability, the size of query replies, and the efficiency of the caching server’s recursive
lookup.
Note Latency for cached data is extremely fast and does not reflect a caching server’s recursive lookup
capability.
• Throughput is defined as the number of queries the server can process per second.
Throughput varies based on network bandwidth, the number of incoming queries
configured for the server’s incoming interfaces, memory, and the availability of the answer
(cache hit or cache miss).
Performance-Tuning Configuration Attributes

To optimize efficiency of the Secure64 DNS Cache resolver, you can tune the latency and
throughput performance of the server by adjusting the following attributes:
• num-recursive-clients: The number of recursive queriers allowed per listening
interface
• incoming-query-timeout: The total time the resolver allows to resolve a query
• outgoing-query-timeout: The time the resolver allows for each query sent to
authoritative servers before retransmitting the query
The attributes are described in Table 16.
Note Performance information for other, non-performance related attributes are included in their respective
descriptions.
101
Table 16. Performance configuration attributes
Attribute: Value
num-recursive-clients: <number> Define the number of recursive client queries per listening
num-recursive-clients: 768 interface for incoming DNS queries. The number applies to
UDP client requests and controls the total number of queries
that can be answered at one time for each interface (defined
by the interface: attribute). The number must be
between 10 and 32767.
This attribute allows you to scale resource use based on the
level of expected queries.
If not defined, the default is 768 per logical interface.
incoming-query-timeout: <seconds> Define the number of seconds to allow for resolution of
incoming-query-timeout: 30 incoming client queries. If the query is not resolved in this
time, the query is dropped to avoid bottlenecks at the query
front end; however, the server still attempts to obtain an
answer and cache the result.
(Note: In addition to the timeout, Secure64 DNS Cache limits
the total number of resolver query traversals to other servers
to 30. If this number is exceeded, the Secure64 DNS Cache
server sends the original querier a SERVFAIL response.)
If incoming-query-timeout is not defined, the default
value is 30 seconds. The minimum value is 1 and the
maximum value is 30.
outgoing-query-timeout: <milliseconds> Define the number of milliseconds to wait to receive a
outgoing-query-timeout: 400 response to an outgoing query during name resolution. If the
queried server does not respond within this time, Secure64
DNS Cache queries the next authoritative name server. The
timeout value should provide enough time to receive a
response in most cases, but not so large as to affect
performance. For example, a caching server that normally
receives responses very quickly can set the timeout to a
lower number than the default.
If none of the authoritative servers respond, Secure64 DNS
Cache adds the outgoing-query-increment value
(described below) to the original timeout and attempts the
query again. If no answer is received after multiple attempts,
the server sends the original querier a SERVFAIL response.
If not defined, the default is 400 milliseconds. The minimum
value is 200 and the maximum value is 4096.
outgoing-query-increment: Define the number of milliseconds to increment the
<milliseconds> outgoing-query-timeout when no response is received
outgoing-query-increment: 400 from any authoritative server when resolving a query.
If not defined, the default is 400 milliseconds. The minimum
value is 200 and the maximum value is 4096.
102
Recursive Clients, Memory, and Performance

The num-recursive-clients: attribute defines the number of recursive client queries per
logical interface for incoming DNS queries. The number applies to UDP client requests and
controls the total number of queries that can be answered at one time for each interface (defined
by the interface: attribute).
This attribute allows you to scale resource use based on the level of expected queries. However, a
larger number of recursive clients consumes more memory. Therefore, sufficient system memory
and balancing memory usage with other needs such as cache sizes is important. (For details about
configuring cache sizes, see Configuring Caches and Internal TTL Values on page 104).
On startup, the caching server calculates the required memory based on the configuration. If the
configuration requires more memory than is available, an error message displays. In addition, if
free memory drops below 300 megabytes during operation of the server, the number of recursive
clients is automatically reduced, performance may be affected, and related messages are written to
syslog. If these errors occur during startup or during server operation, review the configuration
and modify it appropriately.
To estimate the amount of memory required use the formula: 16,384 bytes * # of listening
interfaces * # of recursive clients. You can also use the show cachedns info command to view
information about current memory allocation and queries in progress:
• UDP context memory displays the total amount of memory preallocated to the
interfaces for incoming queries.
• Queries in progress shows the total number of queries the system is handling. If it is
consistently equal to the (# of recursive clients) x (# of interfaces), consider increasing
the number of recursive clients, which may also require additional memory.
• For additional details about the show cachedns info command and system statistics, see
Server Activity Reporting and Statistics on page 215.
103
Configuring Caches and Internal TTL Values

The Secure64 DNS Cache server uses multiple caches to provide faster response times and the
ability to customize cache settings. The caches are separated based on the type of information
they contain. They also have separately configured internal TTL information.
Note The TTLs for cached information are internal to the Secure64 DNS Cache server. Responses to
clients still contain the TTL information based on the original values obtained during the query
resolution process.
The types of caches and TTL information are described in Table 17. Configuration information
for caches and TTL attributes are described in the following sections.
Table 17. Cache types and TTL information
Type Contents TTL attribute in cache.conf

cache-max-ttl:
Answers (A, AAAA, MX, TXT, etc. Sets the maximum TTL for message and
records) and negative (NXDOMAIN) RRset caches.
responses, unless the NXDOMAIN val-bogus-ttl:
Answer (Message) cache
responses are redirected (see Sets the TTL for cached data that has failed
Redirecting NXDOMAIN Responses on validation. The TTL from that data cannot be
page 156 for more information) trusted, and this value prevents repeated
revalidation of bogus data
cache-max-ttl:
Referral (RRset) cache Referrals (NS records) Sets the maximum TTL for the message and
RRset caches
infra-host-ttl:
Sets the TTL for the RTT and EDNS version
Round-trip time (RTT), EDNS, and information cache
Infrastructure cache
lame delegation information
infra-lame-ttl:
Sets the TTL for lame delegation cache
DNSSEC public key information used Not applicable. Signatures use the
Key cache
for validation (RRSIG records) expiration date set in the RRSIG records.
104
Configuring the Answer Cache and the Referral Cache

The message (answer) cache stores the responses that the Secure64 DNS Cache server receives
during the query resolution process. The referral cache contains the NS RRset records that the
Secure64 DNS Cache receives as referrals during the query resolution process. Table 18 identifies
the configuration attributes for the answer and referral caches.
Table 18. Message (answer) and RRset (referral) cache configuration attributes
Attribute: Value
msg-cache-size: <bytes>[k|m|g] Define the amount of memory to use for the answer
msg-cache-size: 128m cache. Plain value is in bytes or you can append k
(kilobytes), m (megabytes) or g (gigabytes), with
1024*1024 bytes in a megabyte. The value must be an
integer. If the server uses multiple resolver instances, the
memory is divided and allocated evenly to each instance.
If not defined, the default is 128 megabytes (128m). The
minimum is 512 kilobytes.
msg-cache-slabs: <num> Define the number of slabs in the answer cache.
msg-cache-slabs: 1 Increasing the number of slabs reduces lock contention,
but fragments memory usage.
cache-servfail-ttl: <seconds> Define the number of seconds to store a SERVFAIL
cache-servfail-ttl: 300 response in the message cache when there are issues
resolving the name, such as the resolver running out of
servers to ask, asking too many questions, or taking too
long to resolve the query. Acceptable range is 1-300
seconds. If not defined, the default is 300 seconds.
rrset-cache-size: <bytes>[k|m|g] Define the amount of memory to use for the referral
rrset-cache-size: 128m (RRset) cache. Plain value is in bytes or you can append
k (kilobytes), m (megabytes) or g (gigabytes), with
1024*1024 bytes in a megabyte. The value must be an
integer. If the server uses multiple resolver instances, the
memory is divided and allocated evenly to each instance.
105
rrset-cache-slabs: <num> Define the number of slabs in the referral (rrset) cache.
rrset-cache-slabs: 1 Increasing the number of slabs reduce lock contention,
cache-max-ttl: <seconds> Define the maximum TTL for RRsets and answer
cache-max-ttl: 86400 messages in the server’s internal cache. Defining a
maximum TTL helps prevent the use of large TTL values
for RRsets and answer messages.
Answers with TTLs shorter than the cache-max-ttl value
expire normally.
Answers with TTLs longer than the cache-max-ttl value
decrement until they reach the defined maximum, and
then they expire from the cache.
Setting the maximum to a low value, such as 900
seconds (15 minutes), can cause slower performance
because the server must update answers more
frequently. Setting the maximum to below 60 seconds can
cause SERVFAIL responses. The minimum allowable
value is 20 seconds
If not defined, the default is 86400 seconds (1 day).
Note You can configure the server to refresh the message (answer) cache when the TTL is expiring. For
more information, see the prefetch: attribute in Prefetching Expiring Entries on page 206.
106
Configuring the Infrastructure Cache

The infrastructure cache stores roundtrip time (RTT) information, which is a measure of the
response time from DNS servers that Secure64 DNS Cache has queried. It also stores EDNS
lameness information to track host support for EDNS0. Table 20 describes the configuration
options for the infrastructure cache.
Table 19. Infrastructure cache configuration attributes
Attribute: Value
infra-host-ttl: <seconds> Define the time to live for entries in the host infrastructure
infra-host-ttl: 900 cache. The host cache contains RTT and EDNS
information for hosts.
infra-cache-numhosts: <num> Define the number of hosts for which RTT and EDNS
infra-cache-numhosts: 10000 information is cached.
infra-cache-slabs: <num> Define the number of slabs in the infrastructure cache.
infra-cache-slabs: 1 Increasing the number of slabs reduces lock contention,
infra-lame-ttl: <seconds> Define the time to live for entries in the lame delegation
infra-lame-ttl: 900 cache.
infra-cache-lame-size: <bytes>[k|m|g] Define the amount of memory to use for the lame
infra-cache-lame-size: 10k delegation cache, per host. Plain value is in bytes or you
can append k (kilobytes), m (megabytes) or g (gigabytes),
with 1024*1024 bytes in a megabyte. The value must be
an integer. If the server uses multiple resolver instances,
the memory is divided and allocated evenly to each
instance.
If not defined, the default is 10 kilobytes (10k).
107
Configuring the Key Cache

The key cache stores DNSSEC public key information, which the Secure64 DNS Cache server
uses for validation. Table 20 describes the configuration options for the key cache.
Table 20. Key cache configuration attributes
Attribute: Value
key-cache-size: <bytes>[k|m|g] Define the amount of memory to use for the key cache.
key-cache-size: 64m Plain value is in bytes or you can append k (kilobytes), m
(megabytes) or g (gigabytes), with 1024*1024 bytes in a
megabyte. The value must be an integer. If the server
uses multiple resolver instances, the memory is divided
and allocated evenly to each instance.
key-cache-slabs: <num> Define the number of slabs in the key cache. Increasing
key-cache-slabs: 1 the number of slabs reduces lock contention, but
fragments memory usage.
Configuring Local Zones

By default, Secure DNS Cache includes records for the local host addresses (127.0.0.1 and ::1),
reverse records for 127.0.0.1 and ::1, and NXDOMAIN responses for AS112 zones. (For a list
of defaults, see Default Local Zone Contents on page 114.)
You can use the local zone attributes in the server: clause to:
• Override the default local zone contents
• Define authoritative answers for local zones
• Create a list of blacklisted zones and define specific behaviors for related queries (for
details and examples, see Blacklisting Domains Using Local Zone Configuration on page 173)
• Redirect specific queries to alternative locations using a CNAME record
• Log local zone activity, see Logging Local Zone Activity on page 116
If you need other types of authoritative data, you can set up a stub zone to point to a full
authoritative server as described in Defining Stub Zones on page 140 or a merge zone to act as an
authoritative server as described in Defining Merge Zones on page 143.
108
Table 21 details the local zone attributes for cache.conf. Examples and a list of default values
follow.
Table 21. Local data configuration attributes
Attribute: Value
local-zone: <zone> <type> [RRtype] [log] Configure a local zone. Use local-data: to enter data into
local-zone: “example.com” redirect the local zone. If there is no match from the local-data:
local-zone: example.com deny attribute, the defined type determines the answer to give.
local-zone: example.com deny ANY Answers for local zones are authoritative.
local-zone: example.com static log
Use the RRtype option to define a specific DNS Resource
Record for this local zone and type. See Blacklisting Domains
Using Local Zone Configuration on page 173 for examples.
Use the log option to log activity related to this local zone to a
local file. See Logging Local Zone Activity on page 116 for
details.
For type:
deny- if there is a match from local data, answers the query;
otherwise, drops queries.
refuse- if there is a match from local data, answers the query;
otherwise, replies with rcode REFUSED.
static- if there is a match from local data, answers the query;
otherwise, sends NXDOMAIN or NOERROR NODATA answer.
CNAME entries are matches when the name and class match,
but the specific type queried for is not found. For a negative
answer, an SOA is included if present as local-data for the zone
apex domain.
transparent- if there is a match from local data, provides the
answer to the query; otherwise, the query is resolved normally.
CNAME entries are matches when the name and class match,
but the specific type queried for is not found. If the query is for a
name in local data, but no such type of data is present, then a
NOERROR NODATA answer is returned. If local-data is
defined without local-zone, a transparent zone is created by
default.
redirect- answers queries for the zone and all subdomains of
the zone with the local data for the zone. It can be used to
redirect a domain to a different address.
nodefault- turns off default content for AS112 zones. The other
types also turn off default contents for the zone, but the
nodefault option has no other effect than turning off default
contents for the given zone. For a list of the default AS112
zones, see Default Local Zone Contents on page 114.
local-zone-log-file-num: <num> Define the total number of local zone log files to maintain, within
local-zone-log-file-num: 128 the range of 1-128. This setting applies to all local zones with
logging enabled.The files are stored in the lz_logging directory
of the cachednsadmin role. Filenames use the syntax
localzone_log_<8-digit-rolling-number>.
If local zone logging is enabled and the number of files is not
defined, the default is 128.
109
local-zone-log-file-size: <bytes> Define the size of the local zone log file(s). This setting applies
local-zone-log-file-size: 143654912 to all local zones with logging enabled.
If local zone logging is enabled and the log file size is not
defined, the default is 143654912 (137 MB).
local-data: "<resource record string>” Configures local data to serve in reply to queries. The query
local-data: “my.local. IN A 192.0.2.51” must match exactly unless you configure the local-zone as
redirect or define CNAME data.
If not matched exactly, the local-zone <type> determines
further processing. For transparent and static types, CNAME
entries are matches when the name and class match, but the
specific type queried for is not found. If local-data is configured
that is not a subdomain of a local-zone, a transparent local-
zone is created by default.
For record types such as TXT, use single quotes, as in local-
data: 'example. TXT "text"'. If you need other types of
authoritative data, you can set up a stub zone to point to a full
authoritative server as detailed in Defining Stub Zones on
page 140 or a merge zone to act as an authoritative server as
described in Defining Merge Zones on page 143.
local-data-ptr: "<resource record Configures local data shorthand for a PTR record with the IPv4
string>” or IPv6 address and the corresponding host name without
local-data-ptr: “192.0.2.4 reversing the IP address manually. TTL can be included, for
www.example.com” example:
local-data-ptr: "2001:DB8::4 7200 www.example.com"
Note You can configure different local zone behavior for specific clients using the view clause. For details,
see Defining Views on page 163.
Local Zone Rules and Examples

Local zone configuration uses the following rules:
• You can configure multiple locally served zones.
• Local zone attributes are listed in the server: clause of the cache.conf file. You can
also define them in a view: clause.
• Responses that contain information derived from a local-zone: are not validated for
DNSSEC.
• For local-zone: <type> transparent and static, CNAME entries are considered
matches when the name and class in the query are matched, but the specific type
queried for is not found. The server chases the CNAME through the resolution
process, rather than returning the CNAME value from local data.This allows you to
redirect queries to alternative locations for resolution. (For examples, see CNAME
Local Data Examples on page 113.)
110
• For local-data:, the query must match exactly unless you configure the local-zone:
as redirect or you use a CNAME (where they query matches except the type queried
for). If not matched exactly, the local-zone: <type> determines further processing.
• If local-data: is configured that is not a subdomain of a local-zone:, a
transparent local-zone is assumed. (If there is a match from local data, it provides the
answer to the query; otherwise, the query is resolved normally.)
• For details and examples of using local zones to blacklist zones, see Blacklisting Domains
Using Local Zone Configuration on page 173.
• For local data record types such as TXT, use single quotes:
local-data: 'example. TXT "text"'
Note For additional information and examples of using a CNAME record with local-data, refer to CNAME Local
Data Examples on page 113
To add locally served data:

local-zone: "local." static
local-data: "mycomputer.local. IN A 192.0.2.51"
local-data: 'mytext.local TXT "content of text record"'
To override certain queries:

# (automatically creates a transparent local-zone)
local-data: "adserver.example.com A 127.0.0.1"
111
To redirect a domain or subdomain to a fixed address:

# (makes example.com, www.example.com, go to 192.0.2.3)
local-zone: "example.com" redirect
local-data: "example.com A 192.0.2.3"
To respond to a query for a domain or subdomain with NXDOMAIN:

# (makes example.com, www.example.com responses NXDOMAIN)
# do not define local-data
local-zone: "example.com" static
To respond to a query for a domain or subdomain with REFUSED:

# (this makes example.com, www.example.com responses REFUSED)
# do not define local-data
local-zone: "example.com" refuse
To create PTR records:

# Configure local data shorthand for a PTR record with the IPv4 or
# IPv6 address and the corresponding host name without reversing
# the IP address manually.
local-data-ptr: "192.0.2.3 www.example.com"
112
CNAME Local Data Examples

CNAME local data entries are considered matches when the name and class in the query are
matched, but the specific record type queried for is not found. Rather than returning the
CNAME value from local data, the Secure64 Cache DNS resolver redirects to the alternative
location defined by the CNAME record. This allows queries for specific zones to be redirected to
alternative locations that may vary over time. The server chases the CNAME through the
resolution process and provides the resulting response.
Refer to the configuration and queries below for examples of resolver behavior based on
CNAME local data:
# Configure local data to resolve variable addresses through
# CNAME chasing
#Example with transparent local zone
local-zone: “search.example.com.” transparent
local-data: “search.example.com. 900 IN CNAME www.google.com.”
# Example that creates a transparent local-zone by default

local-data: “help.example.com. 900 IN CNAME www.yahoo.com.”
# Example with static local zone

local-zone: “alp.example.com.” static
local-data: "local.alp.example.com” IN A 192.0.2.51"
local-data: “alp.example.com. 900 IN CNAME www.secure64.com.”
Given the configuration attributes defined above, queries to the local zones provide the following
results:
dig @caching-server search.example.com A IN
— Finds a match in local-zone/local-data processing
— Responds with a CNAME chased through www.google.com to the appropriate A
records for www.google.com.
dig @caching-server example.com A IN

— Does not find a match in local-zone/local-data processing
— Normal resolution applies
dig @caching-server help.example.com AAAA IN

— CNAME chased through www.yahoo.com:
If an AAAA record exists, return the AAAA record
If an AAAA record does not exist and a dns64-prefix is defined in
cache.conf, a synthesized AAAA response is provided (if possible)
113
If an AAAA record does not exist and a dns64-prefix is not defined in

cache.conf, a response with the appropriate RCODE is provided
dig @caching-server alp.example.com TXT IN

— CNAME chased through www.secure64.com for final TXT RR
dig @caching-server local.alp.example.com MX IN

— Finds a match in the static local-zone alp.example.com
— The name and type do not match local-data
— Responds with an NXDOMAIN response
Note If an NXDOMAIN response results from a CNAME chase initiated from local-data processing, an
NXDOMAIN redirection check occurs.Otherwise, if an NXDOMAIN response results from any other
local-data processing, NXDOMAIN redirection does not occur.
Default Local Zone Contents

The default zones are localhost, reverse 127.0.0.1 and ::1, and the AS112 zones. The AS112
zones are reverse DNS zones for private use and reserved IP addresses for which the servers
on the Internet cannot provide correct answers. They are configured by default to give
NXDOMAIN (no reverse information) answers.
Note To remove a default setting, define your own local-zone: or use the nodefault type as
follows: local-zone: <zone> nodefault
As noted above, the nodefault type turns off default content for AS112 zones. The other types
for local-zone: turn off default contents, but also provide other behaviors.
Local data default content:

localhost: The IPv4 and IPv6 localhost information is provided. NS and SOA records are
included for completeness and to satisfy some DNS update tools. Default content:
local-zone: "localhost." static
local-data: "localhost. 10800 IN NS localhost."
local-data: "localhost. 10800 IN SOA localhost.nobody.invalid. 1 3600 1200
604800 10800"
local-data: "localhost. 10800 IN A 127.0.0.1"
local-data: "localhost. 10800 IN AAAA ::1"
114
Reverse IPv4 loopback default content:

local-zone: "127.in-addr.arpa." static
local-data: "127.in-addr.arpa. 10800 IN NS localhost."
local-data: "127.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600
1200 604800 10800"
local-data: "1.0.0.127.in-addr.arpa. 10800 IN PTR localhost."
Reverse IPv6 loopback default content:

local-zone: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa." static
local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. 10800 IN
NS localhost."
SOA localhost. nobody.invalid. 1 3600 1200 604800 10800"
PTR localhost."
Reverse RFC 1918 data for the zones listed below. The local-zone: is set to static and
local-data: SOA and NS records are provided:
10.in-addr.arpa
16.172.in-addr.arpa
17.172.in-addr.arpa
18.172.in-addr.arpa
19.172.in-addr.arpa
20.172.in-addr.arpa
21.172.in-addr.arpa
22.172.in-addr.arpa
23.172.in-addr.arpa
24.172.in-addr.arpa
25.172.in-addr.arpa
26.172.in-addr.arpa
27.172.in-addr.arpa
28.172.in-addr.arpa
29.172.in-addr.arpa
30.172.in-addr.arpa
31.172.in-addr.arpa
168.192.in-addr.arpa
Reverse data for RFC 3330 IPv4 addresses for this network, link local, testnet, and broadcast
zones:
0.in-addr.arpa
254.169.in-addr.arpa
2.0.192.in-addr.arpa
255.255.255.255.in-addr.arpa
Reverse data for RFC 4291 IPv6 unspecified zone:

0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa
Reverse data for RFC 4193 IPv6 locally assigned local addresses:
D.F.ip6.arpa
115
Reverse data for RFC 4291 IPv6 link local addresses:

8.E.F.ip6.arpa to B.E.F.ip6.arpa
Reverse data for IPv6 example prefix:

8.B.D.0.1.0.0.2.ip6.arpa
Logging Local Zone Activity

The Secure64 DNS Cache server can log information about queries that are directed to local
zones configured in cache.conf. This can help you monitor local zone activity and identify
clients that are attempting to access malicious sites or known bad domains.
Local zone logging rules, configuration, and behaviors include:
• No logging occurs for implicit transparent local zones created automatically or for the
default local zones described in Default Local Zone Contents on page 114
• Messages are logged to disk in the lz_logging directory of the cachednsadmin role
• Log files use the naming convention localzone_log_<num> where num is a 8-digit
rolling number based on the number of log files the server is configured to retain
• Information for all zones with logging enabled is written to the same log file, regardless
of the number of zones or whether zones are in a view
• Processing can move between local zones and regular recursive resolution for a single
query, such as CNAME chasing and DNS64 processing, which could result in multiple
local zone activity messages generated for a single query
• If you change the local-zone-log-file-num: or local-zone-log-file-size:
attributes, stop and start the server to activate; you can activate changes to the “log”
option for the local-zone: attribute using the cachedns reload command
To configure local zone logging in Secure64 DNS Cache:

• Enable logging for one or more local zones in cache.conf using the syntax:
local-zone: <zone> <type> log
• Configure the local-zone-log-file-num: and local-zone-log-file-size: attributes
in the server: clause of cache.conf.
Note These are global settings that apply to all local zones with logging enabled. The default values and
acceptable ranges are detailed in Table 21 on page 109.
• Stop and start the server (issue the stop cachedns and start cachedns commands.
• To help you identify the amount of hard disk space allocated for different types of log
files, the start cachedns command displays the total disk space allocated for
116
NXDOMAIN redirection logging, local zone logging, and query logging. The server
makes use of the allocation(s) for only the specific logging features you have enabled.
The log output contains the date/time, the view name, the client IP address, the domain name,
and the action taken.
Action taken messages are as follows:
• If local-data is served: “local data returned”
• If the query is dropped: “query dropped”
• If the response is rcode refuse: “query refused”
• If the response is nxdomain: “nxdomain returned”
• If the response is nodata: “no data returned”
• If the response is to redirect: “response redirected”
Example local-data match (all local-zone types):

Jul 19 14:54:37 View: default, Query from client 192.168.127.17 for
domain name.com resolved via name.com local-zone: local data returned
Example local-zone TRANSPARENT:

domain name.com resolved via name.com local-zone: local data returned
Example local-zone DENY:

domain name.com resolved via name.com local-zone: query dropped
Example local-zone REFUSE:

domain name.com resolved via name.com local-zone: query refused
Example local-zone REDIRECT:

domain name.com resolved via name.com local-zone: response redirected
Example local-zone STATIC:

domain name.com resolved via name.com local-zone: nodata response

domain name.com resolved via name.com local-zone: nxdomain response
117
Configuring for Basic Security

The Secure64 DNS Cache server includes built-in protections against cache poisoning and
spoofing attempts. Configuration options are also available so that you can enable or disable
additional security features:
• For protection against cache poisoning and spoofing attempts, the server includes built-
in filtering and randomization features, discussed below.
• The server offers configuration options for additional security and protection, which
are described in following subsections.
The server also offers additional protections that are discussed in different sections of this
guide:
• Secure64 DNS Cache includes protection against, mitigation, and rate limiting for
security vulnerabilities such as DoS and DDoS attacks (see Chapter 6. Secure Configuration
on page 203).
• The Secure64 DNS Cache resolver supports DNSSEC validation (see Enabling
DNSSEC-Validated Queries on page 128).
• Advanced security options, such as blacklisting based on a specific domain or query
type, are available (see Advanced Security Configuration on page 172).
Built-in Features to Prevent Cache Poisoning and Spoofing

The server’s filtering component disallows (removes) possibly malicious content as follows:
• Only in-bailiwick data is accepted.
• RFC 2181 trust is employed. Data with additional section trust is not used to answer
queries from clients. Placing a record in the additional section cannot make the record
appear to clients.
• The records in the authority and additional sections are filtered for relevance to the
query in question. If the data is irrelevant, it is removed.
• The answer section is filtered for relevance. Only answers to the query that the server
wants to ask are allowed.
• CNAME chains are cut off; only the first CNAME is kept as an answer. The remaining
CNAMEs or answer records are not kept, but looked up instead.
• To limit DoS/DDoS attacks, CNAME chasing is limited to 30 iterations.
• For DNAME records, the CNAME is synthesized by the server itself.
• DNAME records are not taken from the cache to perform redirection, even if they
seem to match. Only for validated DNAME records (where the digital signature was
correct) is redirection performed from cache; this requires the use of DNSSEC.
118
Randomization makes spoofing more difficult. With more random data, a spoofed reply must
contain more correct data to get through, lowering the chances of a successful poison attempt.
Randomization features include:
• All 16 bits in the ID are used.
• If configured with multiple public IP addresses, Secure64 DNS Cache can perform a
random choice of outgoing interfaces.
• If IPv6 is available, the server obtains another random bit by choosing the IPv4 or IPv6
transport protocol randomly.
• Query aggregation prevents identical outstanding queries to the same server, which
prevents birthday-paradox attacks.
• Query name strict matching prevents an answer from matching a query for which it is not
meant. If an answer can match multiple queries, you get the birthday paradox attack again
(from the previous item).
• The server uses a cryptographically strong random number generator for ports, which is
built into the Secure64 DNS Cache server stack. UDP ports are randomly selected from
the range of 1024 to 65535, and TCP ports are randomly selected from the range of
16384 to 65535.
Using Identity and Version Denial

To protect against CH TXT queries that an attacker may use to obtain information about the
Secure64 DNS Cache server, use the identity and version arguments in the server: clause of
cache.conf to either refuse the queries or provide a false answer, as shown in Table 22:
Table 22. Identity and version security attributes in the server: clause of cache.conf
Attribute: Value
hide-identity: <yes|no> If set to yes, the server refuses id.server and hostname.bind queries.
hide-identity: yes If not defined, the default is yes.
hide-version: <no|yes> If set to yes, the server refuses version.server and version.bind queries.
hide-version: yes If not defined, the default is yes.
identity: “<string>” Set the identity to report for id.server and hostname.bind queries.
identity: “unknown”
If not defined and hide-identity: is set to no, the default is the
system node name.
version: “<string>” Set the version to report for version.server and version.bind queries.
version: “unknown”
If not defined and hide-version: is set to no, the default is the output
from the Secure64 Cache DNS version command.
To provide a different answer if hide-identity: and/or hide-version: are no, include the
following in the server: clause of the cache.conf configuration file:
identity: “string”
version: “string”
where “string” is the text to use in the response.
119
To test the responses, use the dig command (from another system) as follows, where
<Secure64_server > is the Secure64 DNS Cache server:
dig @<Secure64_server> CH TXT id.server
dig @<Secure64_server> CH TXT id.bind
dig @<Secure64_server> CH TXT hostname.server
dig @<Secure64_server> CH TXT hostname.bind
dig @<Secure64_server> CH TXT version.server
dig @<Secure64_server> CH TXT version.bind
Using DNS-0x20 for Forgery Resistance

The Internet draft “draft-vixie-densest-dns0x20-00.txt” proposes using 0x20-encoded random
bits in DNS queries to foil spoof attempts. When attempting to resolve a query, the 0x20
technique causes the Secure64 DNS Cache server to randomly mix the lowercase and
uppercase letters in query names that it sends to authoritative servers. The Secure64 DNS
Cache server then determines whether the reply from the authoritative server preserves the
correct casing.
The following example illustrates a query for www.EXamPLE.cOM, with the answer returning
the same casing. A system attempting to forge the answer and poison the cache would need to
guess the correct casing, in addition to the other elements needed to spoof the answer (such as
the 16-bit query ID field):
dig @192.168.127.99 www.EXamPLE.cOM
; <<>> DiG 9.5.0-P1 <<>> @192.168.127.99 www....
;; Got answer:
...
;; QUESTION SECTION:
;www.EXamPLE.cOM. IN A
....
;; ANSWER SECTION:
www.EXamPLE.cOM. 172800 IN A
To use 0x20 forgery resistance, add the following to the server: clause of the
cache.conf configuration file:
use-caps-for-id: yes
Note The longer the query name, the more protection the 0x20 technique provides.
120
Responses from most authoritative server software preserve the query name casing. However, a
small minority do not. If the response from the authoritative server does not preserve the correct
casing when 0x20 forgery resistance is enabled, the Secure64 DNS Cache server:
• Records related messages to syslog:
— %s: label comparison failure for %s
— Response from server %s for query %s: response name <%s> bit for
bit comparison failed
• Records statistics (see Server Activity Reporting and Statistics on page 215)
• Queries the next authoritative server
Unless it is known for certain that the responding authoritative server preserves query name
casing, it is not possible to determine whether an incorrect response is due to a forgery attempt
or the lack of 0x20 support from the responding authoritative server.
Other Security, Hardening, and Testing Settings

Use the arguments listed in Table 23 to provide additional security measures and to test the server
configuration.
Table 23. Security-related server clause attributes
Attribute: Value
harden-glue: <no|yes> Define whether to avoid spoofing attempts by hardening
harden-glue: yes against out-of-zone RRsets in glue information.
WARNING: Setting this option to no opens systems
connected to the Internet to cache poisoning.
harden-dnssec-stripped: <no|yes> Define whether to require DNSSEC data for zones with
harden-dnssec-stripped: yes trust-anchors. If set to no, failing to validate DNSSEC or
DNSKEY data for a trust anchor causes the server to
treat the zone as insecure.
You may want to set this to no if the system is sometimes
behind an intrusive firewall that removes DNSSEC data
from packets, or a zone changes from signed to unsigned
or badly signed often. When set to no, a downgrade
attack could disable security for a zone.
harden-mismatch: <no|yes> Define whether to protect against cache poisoning
harden-mismatch: no attempts that use mismatches of the DNS message ID
and query name in a response when compared to the
original question.
If the answer message ID does not match, but the query
name does match, then the minimum information is
returned to the querier and the answer is not cached. If
the query name does not match, the answer is not
returned or cached.
121
Attribute: Value
private-address: <IP address or subnet> Define IPv4/IPV6 addresses or subnets on your private
private-address: 10.0.0.0/8 network that are not allowed to be returned for public
private-address: fd00::/8 Internet names. Any occurrence of such addresses are
removed from DNS answers.
Additionally, the DNSSEC validator may mark the
answers bogus. This protects against DNS rebinding,
where a user’s browser is turned into a network proxy,
allowing remote access through the browser to other
parts of your private network.
Some names can be allowed to contain your private
addresses. By default, all the local-data that you
configure is allowed to contain private addresses, and
you can specify additional names using private-domain.
If not defined, no private addresses are enabled.
private-domain: <domain name> Allow this domain and all of its subdomains to contain
private-domain: example.com private addresses. List multiple times to allow multiple
domain names to contain private addresses.
If not defined, the default is none.
do-not-query-address: <IP address>[/num] Do not query the given IPv4 or IPv6 address. Append
do-not-query-address: 10.2.3.4/24 /num to indicate a classless delegation netblock.
do-not-query-address: 127.0.0.1/8
do-not-query-address: ::1 If not defined, the default is 0 (no IP address).
do-not-query-localhost: <no|yes> If yes, localhost is added to the do-not-query-address

do-not-query-localhost: yes entries, both IPv6 ::1 and IPv4 127.0.0.1/8. If no, then
localhost can be used to send queries to.
drop-any: <yes|no> If yes, this option instructs the server to drop all incoming
drop-any: no queries of the type ANY. It is designed as a temporary
protection from DDoS attacks that employ the ANY RR
type, to allow you to investigate other mitigation options.
drop-mx: <yes|no> If yes, this option instructs the server to drop all incoming
drop-mx: no queries of the type MX. Use with views to allow or drop
MX queries from specific clients for spam protection.
val-override-date: <YYYYMMDDHHmmss> If enabled by providing an RRSIG-style date, the date is
val-override-date: 20090302113243 used to verify RRSIG inception and expiration dates,
instead of the current date. Do not set unless you are
debugging signature inception and expiration.
If not defined, the default is to use the current date.
val-bogus-ttl: <seconds> Define the TTL (time to live) for bogus data. This is data
val-bogus-ttl: 60 that has failed validation due to invalid signatures or other
checks. The TTL from that data cannot be trusted, and
this value is used to prevent repeated revalidation of
bogus data.
If not defined, the default is 60 seconds.
122
Attribute: Value
val-clean-additional: <no|yes> If yes, protects users that rely on the Secure64 DNS
val-clean-additional: yes Cache server for authentication from potentially bad data
in the Additional section of the response.
Removes all unsigned data from the Additional section of
secure messages. Does not affect insecure, bogus,
indeterminate, or unchecked messages.
val-permissive-mode: <no|yes> Define whether to permit bogus messages. When set to
val-permissive-mode: no yes, instructs the validator to mark bogus messages as
indeterminate. The security checks are performed, but if
the result is bogus (failed security), the reply is not
withheld from the client with SERVFAIL as usual. The
client receives the bogus data. For messages that are
found to be secure, the AD bit is set in replies.
Note: While DNSSEC is still in the early stages of
deployment, it may be best to use the permissive mode
(set to yes). This will result in a response, but AD bit will
not be set.
If not defined, the default value is no.
val-nsec3-keysize-iterations: “<keysize Define a list of key sizes and Next Secure version 3
iterations>” (NSEC3) iteration count values, separated by spaces. An
val-nsec3-keysize-iterations: “1024 150 NSEC3 message with a larger iteration count for the
2048 500 4096 2500” corresponding key size is marked insecure instead of
performing all hashing iterations. This protects against
DoS attacks that attempt to use a large number of hash
iterations.
The list must be in ascending order and have at least one
entry. Defining a very long list can cause slower
operation. Setting the attribute to "1024 65535" forces no
restriction on NSEC3 iteration values.
If not defined, the default is "1024 150 2048 500 4096
2500"
123
Using Include Files

For ease of configuration management, you can use the include: attribute to create subsets of
information stored in separate files. Secure64 DNS Cache supports up to 10 levels of nested
include: attributes and files.
Specifying an Include File

The include: attribute can appear anywhere in cache.conf, and it takes a single filename as
an argument. Processing continues as if the text from the include file is present at the point of
the attribute.
For an example of maintaining an include file offline and using the scp and the cachedns
reload commands to automate changes, see Maintaining Blacklists Offline with an Include File on
page 176.
Recommendations for Using Include Files

Maintaining cache.conf configuration items using include files are especially useful in the
following situations:
• Configuration attributes that change frequently
• Configuration sections that are lengthy and need to be maintained on a separate system
with a full editor
• Configuration attributes that you would like to automate and load dynamically using
scripts and the cachedns reload command (for details about using the command and
the configuration items you can reload dynamically, see Reloading Configuration Changes
Dynamically on page 185)
Example:
# The server clause sets the main parameters and must come FIRST.
server:
# Use this to include configuration attributes into the file

# for ease of management
#Start/stop options
include: include_start_stop_options
# Control which clients are allowed to make (recursive) queries

# to this server by specifying ip-address and action, or specify
# classless netblocks with /size and action.
include: include_acls
# Cache memory and config items
124
include: include_caches_config
# Local data, with nested blacklist file

# contents of include files shown below
include: include_local_data
# List or include other server clause items...

# include: include_additional_server
# List or include forward zone information, if applicable

# include: include_forward
#List or include stub zone information, if applicable

# include: include_stub
Example of include file contents:

[root@comp28]# cat include_local_data
# Redirect a domain to a fixed address
# (this makes example.com, www.example.com, etc, all go to 192.0.2.3)
local-zone: "example.com" redirect
local-data: "example.com A 192.0.2.3"
# Specify local data shorthand for a PTR record with the reversed IPv4
# IPv6 address and the hostname. A TTL can be included.
# local-data-ptr: "192.0.2.3 7200 www.example.com"
# Blacklist certain domains and subdomains, returning NXDOMAIN

include: include_blacklist
[root@comp28]# cat include_blacklist

local-zone: example-domain1.com static
local-zone: example-domain2.net static
local-zone: example-domain3.edu static
125
126
Chapter 4. Advanced Configuration Topics
Overview
This chapter provides information about optional advanced features controlled by the DNS
server’s cache.conf configuration file. DNS-related configuration tasks require you to login to
cachednsadmin mode. For more information about operational logins, see Roles and User
Accounts on page 19.
Prior to configuring advanced options, the basic configuration and set up options should be
operational in cache.conf. For details, refer to Chapter 3. Configuring Secure64 DNS Cache on
page 91.
Enabling DNSSEC-Validated Queries.........................................128
Defining Resolver Forwarding.....................................................138
Defining Stub Zones....................................................................140
Defining Merge Zones.................................................................143
Configuring IPv6 Transition Technologies ...................................148
Redirecting NXDOMAIN Responses...........................................156
Defining Views ............................................................................163
Advanced Security Configuration................................................172
Specifying an Unbound Configuration File ..................................177
127
Enabling DNSSEC-Validated Queries

To enable DNSSEC validation of queries in Secure64 DNS Cache, you must define trust
anchors in the cache.conf configuration file. Trust anchors are the public keys (KSKs) of the
secure entry points (SEPs) for the zones that you want Secure64 DNS Cache to validate.
The root zone is now signed and a trust anchor is available, as discussed in Obtaining and
Configuring the Root Trust Anchor on page 131. However, not all top-level or parent domains are
signed, and a chain of trust from root to a specific domain may or may not exist. This means
that in addition to the root zone trust anchor, you may need to install additional trust anchors,
as discussed in Obtaining Additional Trust Anchors on page 133.
Simply defining a trust anchor in cache.conf enables DNSSEC. Configuring DNSSEC
Lookaside Validation (DLV) is another method for enabling trust anchor information. As
stated in RFC 5074, DNSSEC Lookaside Validation (DLV) is a mechanism for publishing
DNSSEC trust anchors outside of the DNS delegation chain. DLV uses an alternate resource
record called a DLV RR to validate DNS records. The DLV method is discussed in Using DLV
on page 134.
Note Defining trust anchors or a DLV causes DNSSEC validation to occur for all queries.
Exceptions are queries for configured local zones or queries that have the checking disabled (CD) bit
set.
Understanding Validation Behavior

Before you configure DNSSEC validation, it is important to understand its affect on query and
response handling. Variables that determine validation behavior include:
• Enabling trust anchors in cache.conf
• Enabling DNSSEC Lookaside Validation (DLV) in cache.conf
• Handling of insecure/unvalidated queries (return SERVFAIL or bogus)
Note The val-permissive-mode: attribute in cache.conf determines how queries that fail
validation are handled. If set to no, SERVFAIL is returned for bogus responses. If set to yes, the bogus
response is returned.
128
Use Table 24 to determine query and response behavior based on the configuration of these
variables in the cache.conf configuration file.
Table 24. Query behavior with DNSSEC validation
Trust Anchor DLV val-permissive-mode Result

No validation occurs
AD bit not set in replies
N N Not applicable NOERROR, REFUSED, NXDOMAIN, FORMERR, or
SERVFAIL response is sent, based on result of query
resolution
Attempts validation for all queriesa
If validation is not successful (bogus), AD bit is not set
N and SERVFAIL is returned in replies
If validation is successful, AD bit is set and NOERROR
or NXDOMAIN response is sent, based on result of
query resolution
Y N
If validation is not successful, AD bit is not set and the
Y bogus response is sent in replies
query resolution
If no trust anchor exists, checks the DLV and performs
DLV processing
N If validation is not successful (bogus), AD bit is not set
and SERVFAIL is returned in replies
query resolution
Y Y
If no trust anchor exists, checks the DLV and performs
DLV processing
Y If validation is not successful, AD bit is not set and the
unvalidated/bogus response is sent in replies
query resolution
a. Exceptions are queries for configured local zones or queries that have the checking disabled (CD) bit set
129
Configuration Attributes for Trust Anchors

Configuring trust anchors in cache.conf automatically enables DNSSEC validation for the
zones related to the trust anchors. Secure64 DNS Cache provides three different cache.conf
attributes to configure the trust anchor information for DNSSEC signature validation, as
shown in Table 25. If you have multiple trust anchors, you can use any combination of the
three configuration attributes to define your trust anchors. However, you should define each
individual trust anchor only once.
Table 25. Trust anchor configuration attributes
Attribute: Value
trust-anchor-file: <filename> Specify one or more trusted key files that contain DS and
trust-anchor-file: trustanchor.lst DNSKEY records using the zone file format. List one file
trust-anchor-file: /secure/keys.txt per trust-anchor-file attribute.
If not defined, the default is no trust anchor file.
trust-anchor: “DS or DNSKEY record” Specify a DS or DNSKEY record, including the trusted
trust-anchor: “example.com DNSKEY 257 3 5 key information. List one record per trust-anchor
AQPzzTWMz8q...” attribute. Note that the TTL is ignored and class is IN by
default.
If not defined, the default is no trust anchor.
trusted-keys-file: <bind9-style-file> Specify one or more trusted key files that use the BIND-9
trusted-keys-file: trust_anchor_table.txt style format with the trusted-keys clause.
Wildcards in filenames are currently not supported.
If not defined, the default is no trust anchor file.
domain-insecure: <domain name> Define a domain to omit from DNSSEC validation. This
domain-insecure: www.example.com can be used to define a “negative trust anchor” to
temporarily disable DNSSEC validation for a specific
domain name.
List a separate attribute for each domain name to omit.
The defined domain name creates an endpoint for the
resolver to stop validation of the authentication chain. For
example, defining www.example.com affects only names
within the www.example.com domain; validation is still
performed on example.com, .com, and the root (".")
Note that if you set a trust anchor for the specific domain
name, it overrides this setting and the domain name is
secured. For example, defining a trust anchor for
www.example.com overrides the setting
domain-insecure: www.example.com
If not defined, the default is none.
If you have a trust anchor file for example.com in zone file format and a trust anchor file for
example.net in BIND-9 format, define the following attributes in the server: clause of the
cache.conf configuration file:
server:
trust-anchor-file: com.anchor
trusted-keys-file: net.keys
130
Contents of com.anchor:
example.com. IN DS 6109 5 1 e1eccc7262384c2e7708b6a80d0aac958252135a
Contents of net.keys:
trusted-keys {
example.net 257 3 5
"AwEAAb1Uz2SnHcZc0g5uhKZ3w7dAXwD1R++sTfSZ
yQiLuU6VQbQnQdznJPmGNLviSIp/8eSRzq9f
AU7k3pkrV4COh3FIX5Ypqw3jgjs6Qic4voyH
zEBSkKeDNkCScidt05Kc6fte8u1QyKEMqzGQ
dCLF1Ax+RJJ4y22BvhdiOlYHYSGR";
};
Use the following information when configuring trust anchors:

• If you modify the trust anchor information in cache.conf, you must issue the stop
cachedns and start cachedns commands to start the server with the revised
configuration.
• You can place the trust anchor keys in a subdirectory and define the path in the
cache.conf.
• If there is a temporary issue with validation for a specific domain name (such as a
misconfiguration on the part of the domain operator), you can omit the domain name
from validation using the domain-insecure: attribute. Refer to the description in
Table 25 on page 130 for details.
Obtaining and Configuring the Root Trust Anchor
Note The Secure64 DNS Cache server does not currently support automated root trust anchor updating.
To maintain the root trust anchor in the Secure64 DNS Cache server:
1. Go to the Internet Assigned Numbers Authority web site at
https://www.iana.org/dnssec/.
2. Download the root trust anchor from the IANA web site and verify its authenticity.
Note The root trust anchor file format and verification options are described in the Draft ICANN document
DNSSEC Trust Anchor Publication for the Root Zone, which is provided on the IANA web site.
3. Place the contents of the root trust anchor in DS record format, for example, in a
root.key text file.
131
Example:
Contents of root.key:
. IN DS 19036 8 2 49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5
4. Use scp to copy the root.key file to the Secure64 DNS Cache server:
scp [-P <port>] root.key <user>@<host>:/cachednsadmin
where:
132
5. Login as a user assigned to the cachednsadmin role. Add the following argument to
cache.conf in the server: clause section:
server:
trust-anchor-file: root.key
6. To activate the changes to the cache.conf configuration file, stop and start the server:
Stopping cachedns
Stopped cachedns
[cachednsadmin@Secure64]# start cachedns

Starting cachedns
Reading configuration file.
cache.conf:7: resolver config parser: 0 errors, 0 warnings
Reading root hints file: validator_hints.
Configured memory approximately: 524 mb
Total disk space configured for logging: 51200 MB
10240 MB - Nxdomain Redirection Logging
10240 MB - Local Zone Logging
30720 MB - Query Logging
Started cachedns
7. From another system, use the dig utility to test and query the server. For example, the
command below queries for the root zone SOA record:
dig @<server_IP_address> . SOA +dnssec
The response should return NOERROR for the status and the AD bit should be included
in the flags list indicating authentication was successful.
8. To receive notification of key rollovers and other important information, subscribe to the
IANA root announcement e-mail list as described on the organization’s web site.
9. For information about obtaining trust anchors for domains that do not have a chain of
trust up to the root zone, refer to the next section.
Obtaining Additional Trust Anchors

For domains that do not have a chain of trust established to the root zone, you need to install
their trust anchors if you want the server to validate DNSSEC for the domain. If you are unsure
as to a domain’s status, you can use the following tools and information to help determine trust
anchor and validation status:
• The TLD DNSSEC report, which lists the trust anchor status of top-level domains:
http://stats.research.icann.org/dns/tld_report/
133
• The Sandia Laboratories DNSSEC visualization tool, which creates a diagram showing
the DNSSEC status for a domain: http://dnsviz.net/
As described in RFC 4986, you must establish the authenticity of any keys you plan to configure
as a trust anchor. The RFC states:
“Operators of security-aware resolvers must ensure that they initially obtain any Trust
Anchors in a trustworthy manner.... This might be accomplished through a
combination of technical, procedural, and contractual relationships, or use other
existing trust relationships outside the current DNS protocol. Those responsible for
the operation of the security-aware resolver are responsible for establishing policies and
procedures to ensure that a sufficient Initial Trust Relationship is in place before adding
Trust Anchors for a particular DNS zone to their security-aware resolver
configuration.”
How you establish trust for a trust anchor key depends on the method the zone owner offers
for validation. Methods for obtaining trust anchors include:
• Visiting the zone owner’s secure web site and validating the key information.
• Obtaining the trust anchors from the zone owner via secure email.
• Using the SecSpider trusted keys file http://secspider.cs.ucla.edu/ta.html.
• Configuring DNSSEC Lookaside Validation (DLV) for zones registered with a DLV
repository. For more information, see Using DLV on page 134.
Note For information about the root trust anchor, see Obtaining and Configuring the Root Trust Anchor on
page 131.
Managing Trust Anchors

The zone owners of the public keys defined in trust anchor files must rollover the keys
periodically to maintain security. Depending on how the zone operator distributes new trust
anchor information, you can receive notification via an email list, from the owner’s web site, or
by some other means.
Assuming you have established a trusted means of receiving notification from the zone owner,
you can manually update the public key information in your trusted key files. You can also
create a script to monitor and retrieve updated key information automatically.
As previously noted, if you modify the cache.conf file to obtain new key information, you
must issue the stop cachedns and start cachedns commands for the server to read the
change.
Using DLV
DNSSEC Lookaside Validation (DLV) uses an alternate resource record called a DLV RR to
validate DNS records. As stated in RFC 5074, DNSSEC Lookaside Validation (DLV) is a
134
mechanism for publishing DNS Security (DNSSEC) trust anchors outside of the DNS delegation
chain. It allows validating resolvers to validate DNSSEC-signed data for zones whose parents
aren’t signed or don’t publish DS records.
Zone owners register their zones with a DLV registry, such as Internet Systems Consortium (ISC)
DLV at https://dlv.isc.org. The registry publishes a DLV record for each zone. The DLV record
is defined in RFC 4431, and it uses the same format as the DS record.
Secure64 DNS Cache enables DLV support when you define a DLV anchor file or record in the
cache.conf configuration file. Table 26 provides a description of the DLV-related configuration
attributes.
Table 26. DLV configuration attributes
Attribute: Value
dlv-anchor-file: <filename> File with trusted keys for a DLV (DNSSEC Lookaside
dlv-anchor-file: dlv.isc.org.key Validation) registry. DS and DNSKEY entries are
supported, in the same format as for trust-anchor-file:
statements.
Configure only one DLV registry. The DLV registry is used
as a root trusted DLV; you cannot limit DLV queries to
specific domains such as .com. The registry domain is
inferred from the DS or DNSKEY record in the file.
Default is no DLV anchor file.
dlv-anchor: “DS or DNSKEY record” Alternative to the dlv-anchor-file: attribute.
dlv-anchor: “dlv.isc.org. IN DNSKEY 257 3 Specify a DS or DNSKEY record, including the trusted
5 BEAAAAPHMu/5onzr...” key information, for the DLV registry. See the dlv-anchor-
file description for additional information.
If not defined, the default is no DLV anchor.
neg-cache-size: <bytes> Define the byte size of the aggressive negative cache for
neg-cache-size: 128m DLV. A plain number is in bytes, append 'k', 'm' or 'g' for
kilobytes, megabytes or gigabytes (1024*1024 bytes in a
megabyte). If the server uses multiple resolver instances,
the memory is divided and allocated evenly to each
instance.
If not defined, the default is 128 megabytes.
When processing a query with a DLV registry defined, Secure64 DNS Cache:
1. Checks to see if there is a trust anchor defined in cache.conf. If a trust anchor is
defined, Secure64 DNS Cache validates the response using the trust anchor information.
2. If no trust anchor exists or if the response using the trust anchor is insecure or
indeterminate, Secure64 DNS Cache checks whether DLV is configured.
3. If DLV is configured, Secure64 DNS Cache checks the DLV registry for the DLV record
of the zone. If a DLV record is defined, Secure64 DNS Cache uses it to validate the
response. Otherwise, an unvalidated response is provided.
135
In addition, Secure64 DNS Cache implements DLV using the following format and rules:
• The registry domain to query, such as dlv.isc.org, is inferred from the DS or DNSKEY
record defined in the dnssec-anchor-file: or dnssec-anchor: argument.
• The maximum query name is 255 characters, including the name of the DLV registry
(such as dlv.isc.org). When this limit is exceeded, an unvalidated answer is provided.
• You cannot limit DLV queries to specific domain names such as .com or .org. (The
DLV registry is used as a root trusted DLV).
• Enabling DLV affects query performance. DLV checking adds an additional step to the
querying process when:
— A trust anchor is not defined for the zone being validated
— Trust anchor validation returns an insecure or indeterminate result
• To reduce the impact of DLV on performance and minimize the load on DLV
registries, Secure64 DNS Cache implements aggressive negative caching as described in
RFC 5074. Using aggressive negative caching, the server does not make queries for any
name covered by a cached and validated NSEC record. The records must be signed
with NSEC (not NSEC3) and cannot use wildcards, although they can have (secured)
delegations inside the DLV repository.
Note Secure64 DNS Cache also performs standard negative caching (caching an NXDOMAIN response,
for example), which is the negative caching that comes from the SOA TTL value in the zone.
To use the ISC DLV with Secure64 DNS Cache:

1. Download the ISC’s DLV trusted KSK (public key) from the ISC web site at dlv.isc.org,
verifying the PGP signature on the download.
2. Place the key in a file named dlv.isc.org.key
3. Use scp to copy the ISC DLV trusted KSK to the Secure64 DNS Cache server:
scp [-P <port>] dlv.isc.org.key <user>@<host>:/cachednsadmin
where:
4. Login as a user assigned to the cachednsadmin role. Add the following argument to
cache.conf in the server: clause section:
dlv-anchor-file: dlv.isc.org.key
136
5. To activate the changes to the cache.conf configuration file, stop and start the server:
Stopping cachedns
Stopped cachedns

Starting cachedns
Started cachedns
6. From another system, use the dig utility to test and query the server. For example, the
command below queries for the isc.org. NS record type (assumes the ISC’s DLV registry
is defined):
dig @<server_IP_address> +dnssec +multiline -t ns isc.org.
The response should return NOERROR for the status, the AD bit should be included in
the flags list, and the RRSIG record should be included in the Answer section.
7. To receive notification about key rollovers and other important information, subscribe to
the ISC DLV announcement e-mail list as described on the organizations web site.
137
Defining Resolver Forwarding

The forward zone clause lets you configure different server(s) to resolve DNS queries. As a
result, the server(s) you forward to must be capable of handling recursion to other name
servers. Forwarding can be useful to work around firewalls, to limit the number of servers that
access the Internet, or to redirect a query to a DNS blacklist.
Note For authoritative data, use a stub zone as discussed in Defining Stub Zones on page 140.
Table 27 lists the attributes for the forward-zone clause:
Table 27. Forward zones configuration attributes
Attribute: Value
name: <domain name> Name of the zone to forward. To forward all queries sent
name: “secure64.com” to the Secure64 DNS Cache server, use ‘.’
forward-addr: <IP address> IPv4 or IPv6 address of the server to forward to. To use a
forward-addr: 192.168.127.99 non-default port for DNS communication, append '@' with
forward-addr: 192.168.127.95@5355 the port number. You must define at least one forward-
addr or forward-host. The maximum combined forward-
addr: and forward-host:attributes per forward zone is 16.
forward-host: <domain name> Name of server to forward to. The name itself is resolved
forward-host: forward.secure64.com before it is used. You must define at least one forward-
addr or forward-host. The maximum combined forward-
addr: and forward-host:attributes per forward zone is 16.
Forward zone clause rules, options, and behaviors include:

• If forward-host: is specified and the nameserver command option is not
configured, the caching server will not start. For details about configuring a nameserver,
see Configuring System Name Servers on page 229.
• Multiple forward-zone: clauses are allowed so that you can define multiple zones to
forward (one clause for each zone).
• Each forward-zone: clause requires a name: and one or more hostnames or IP
addresses.
• Multiple forward-addr: and/or forward-host: attributes are allowed:
— The Secure64 DNS Cache server starts forwarding to the last IP address listed in
the forward-addr: list.
— If the query is not answered, the server moves up the list to the next IP address or
forward-host:.
— The maximum combined forward-addr: and forward-host: attributes per
forward zone is 16.
138
— The Secure64 DNS Cache server attempts to contact the forward zone server(s) a
total of three times. If the query is not answered, the Secure64 DNS Cache server
responds with SERVFAIL.
• The forwarding server handles further recursion for the query and returns the answer to
the Secure64 DNS Cache server.
• The Secure64 DNS Cache server provides the answer from the forward zone server to
the querier.
• With the exception of CNAME and/or DNAME responses from a forward zone server,
the Secure64 DNS Cache server caches the result from the forward zone. CNAME or
DNAME/CNAME pair responses are not cached to allow for consistent responses from
the forward zone server.
• A forward-zone entry with name "." and a forward-addr:<IP_address> forwards all
queries to the targeted server (unless it can answer from the cache).
Example:
forward-zone:
name: "example.com"
forward-addr: 192.0.2.68
forward-addr: 192.0.2.73@5355
forward-zone:
name: "example.org"
forward-host: fwd.example.com
139
Defining Stub Zones

A stub zone refers the Secure64 DNS Cache resolver to an authoritative DNS server for
authoritative data that the resolver cannot access using the public Internet servers, zones that
are private, and zones that have no delegation to them. Stub zones are used for more
complicated authoritative data than what the local-zone: option provides (see Configuring
Local Zones on page 108).
You put the authoritative DNS data on a separate server and configure cache.conf as stub for
those zones. This allows clients to access data from the Secure64 DNS Cache server, without
making the server authoritative for the zones. This is useful for:
• Company-local data
• Private zones
• Referrals, wildcards, and DNAME support
• DNSSEC authoritative service for private zones
Note For local data and CNAME records, you can use local zones as discussed in Configuring Local Zones
on page 108. To configure the Secure64 DNS Cache server to act as an authoritative server for zone
data, see Defining Merge Zones on page 143
To use a stub zone, first configure the zone on an authoritative server on a different host. In
the cache.conf configuration file, configure the stub-zone: clause to point to the different
host for the zone. This allows the zone to be served by the authoritative server.
If you want DNSSEC validation for a stub zone that is signed, you can place a trusted key entry
with the zone’s public key in either the trust-anchor: (see Table 25 on page 130) or stub-
trust: (see Table 28 on page 141) attribute. The Secure64 DNS Cache server can then
validate the data and set the AD (authenticated data) bit on replies for the private zone
(authoritative servers do not set the AD bit). Note that the AA (authoritative) bit is not set on
these replies.
140
Table 28 describes the attributes for the stub-zone clause:
Table 28. Stub zones configuration attributes
Attribute: Value
name: <domain name>
Name of the stub zone.
name: secure64.com
stub-addr: <IP address> IPv4 or IPv6 address of the server to forward to. To use a
stub-addr: 192.168.127.99 non-default port for DNS communication, append '@' with
stub-addr: 192.168.127.95@5355 the port number. You must define at least one stub-addr
or stub-host. The maximum combined stub-addr and
stub-host attributes per stub zone is 16.
stub-host: <domain name> Name of stub zone nameserver. The name itself is
stub-host: ns.example.com resolved before it is used. You must define at least one
stub-addr or stub-host. The maximum combined stub-
addr and stub-host attributes per stub zone is 16.
stub-trust: “<DS or DSKEY>” If validation is required, specify a DS or DNSKEY record
stub-trust: “example. DS 12345 3 1 for the trust anchor of the stub zone, including the trusted
123456789abcdef6789012...” key information. List one record per line. Note that the
TTL is ignored and class is IN by default.
If preferred for organizational purposes, you can define
stub-trust: in the server: clause or use the
trust-anchor: attribute in the server: clause
instead of stub-trust:.
If not defined, the default is no stub trust anchor.
Stub zone clause rules, options, and behaviors include:

• If stub-host: is specified and the nameserver command option is not configured, the
caching server will not start. For details about configuring a nameserver, see Configuring
System Name Servers on page 229.
• Multiple stub-zone: clauses are allowed (one clause for each zone).
• Each stub-zone: clause requires a name: and one or more IP addresses (defined by
stub-addr:) or domain names (defined by stub-host:).
• Multiple stub-addr: and/or stub-host: attributes are allowed:
— The Secure64 DNS Cache server starts with the last IP address listed in the stub-
addr: list. If the query is not answered, the next stub-addr: entry is tried.
— If the query is not answered after each stub-addr: is tried, the server moves up the
list to the next IP address or stub-host:.
— The Secure64 DNS Cache server attempts to contact the stub zone server(s) a total of
three times. If the query is not answered, the Secure64 DNS Cache server responds
with SERVFAIL.
— The maximum combined stub-addr: and stub-host: attributes per stub zone is
16.
141
• The stub zone server returns the authoritative answer to the Secure64 DNS Cache
server. The stub zone processing will follow delegations returned by the configured
authoritative server.
• The Secure64 DNS Cache server provides the answer to the querier and caches the
result.
Example:
stub-zone:
name: "example.com"
stub-addr: 192.0.2.68
stub-zone:
name: "example.org"
stub-host: ns.example.com.
stub-trust: “example.org DS 36157 3 1 akdjfakldjajfdkagjlsd..."
142
Defining Merge Zones

If you manage zones on authoritative servers, you may want to use the Secure64 DNS Cache
server to help administer authoritative answers. With the merge zone feature, you can configure a
Secure64 DNS Cache server to act as the front end for a zone that is located on one or more of
your authoritative DNS servers.
When it receives a request for a configured merge zone, the Secure64 DNS Cache server queries
only the authoritative servers you specify by IP address in the merge zone configuration
attributes. Once it receives an answer, the caching server provides a response as if it were the
authoritative server for the zone. This allows you to use the merge zone feature to:
• Split authoritative data for a large zone across multiple servers, with no server having the
complete zone information. The Secure64 DNS Cache server will query each of the
specified authoritative servers in turn, looking for the server with the information
requested.
• Add a Secure64 DNS Cache server to your infrastructure to provide authoritative answers
for zones, allowing you to diversify your DNS software without disrupting or
reconfiguring your existing authoritative server(s).
Note Do not configure a zone where domains or subdomains are duplicated across multiple servers and each
server has a specific non-overlapping record type(s). For example, do not define a zone where all A
records are on server A, all AAAA records are on server B, and TXT records are on server C. Once a
domain or subdomain is found to reside on a particular server, the merge zone feature assumes that all
configured record types for that domain or subdomain are in the same location.
The stub zone feature (see Defining Stub Zones on page 140) also provides answers from
authoritative servers. However, the merge zone feature differs from the stub zone feature in the
following ways:
• Merge zone responses are not validated, stub zone responses are validated.
• If a merge zone query receives a referral from the authoritative server, the information is
returned as the response. For a stub zone, the information is used to continue recursive
resolution.
• For a merge zone, NXDOMAIN responses indicate that the Secure64 DNS Cache server
needs to check the next authoritative server. For a stub zone, the NXDOMAIN response
is considered an answer.
• The merge zone feature passes the AA (Authoritative Answer) bit set by an authoritative
server in the response. The stub zone feature does not pass the AA bit.
143
Table 29 describes the nsd.conf configuration attributes for the merge-zone clause:
Table 29. Merge zones configuration attributes
Attribute: Value
name: <domain name>
Name of the merge zone.
name: secure64.com
merge-addr: <IP address> IPv4 or IPv6 address of an authoritative server to query
merge-addr: 192.168.127.99 for the defined name. To use a non-default port for DNS
merge-addr: 192.168.127.95@5355 communication, append '@' with the port number. You
must define at least one merge-addr. The maximum
merge-addr attributes per merge zone is 16.
Merge zone clause rules, options, and behaviors include:

• Multiple merge-zone: clauses are allowed (one clause for each zone).
• Each merge-zone: clause requires a name: and one or more IP addresses (defined by
merge-addr:).
• Multiple merge-addr: attributes are allowed:
— The Secure64 DNS Cache server starts with the last IP address listed in the merge-
addr: list. If the query is not answered, the next merge-addr: entry is tried.
— If the query is not answered after each merge-addr: is tried, the server moves up
the list to the next IP address.
— The maximum combined merge-addr: attributes per merge zone is 16.
— Increasing the number of authoritative servers defined by the merge-addr:
attribute can increase the query latency.
• You can activate changes to the merge-zone: clause and merge-addr: and name:
attributes using the cachedns reload command.
Merge zone response behaviors include:
• The Secure64 DNS Cache server attempts to contact the authoritative server(s) a
maximum of three times. If an authoritative server indicates that it does not have the
record(s) requested (such as through an NXDOMAIN response), that server is not
queried again, even if all other servers also fail to provide the requested response.
Empty NOERROR and NOERROR NODATA responses indicate that the domain
exists but the requested record type does not. For a merge zone, this is considered a
final response and no further processing is needed.
• If all defined authoritative servers return SERVFAIL, the Secure64 DNS Cache server
responds with SERVFAIL. If all defined authoritative servers return NXDOMAIN, the
Secure64 DNS Cache server responds with NXDOMAIN. If all defined authoritative
servers return REFUSED, the Secure64 DNS Cache server responds with REFUSED.
144
• If all defined authoritative servers return NODATA (SOA or empty NOERROR) the
Secure64 DNS Cache server provides the NODATA response received from the last
server queried.
• The Secure64 DNS Cache server does not provide DNSSEC validation for merge zone
answers. However, if the DO (DNSSEC OK) bit was in the request, the Secure64 DNS
Cache server will return the necessary DNSKEY, RRSIG, NSEC, and DS RRsets in the
response, if defined on the configured authoritative server(s).
• CNAME responses are not re-queried. The Secure64 DNS Cache server returns the
CNAME response it receives from the authoritative server
• If the query does not include the RD (Recursion Desired) bit, but the query is for a
defined merge zone, merge zone processing takes place. All non-merge zone queries
received without the RD bit are REFUSED by the Secure64 DNS Cache server.
• When the RD bit is set, queries for domains covered by a merge zone definition are
processed as merge zones. Queries for domains not covered by a merge zone definition
are handled through normal recursion and processing.
• Merge zone responses do not use IPv4 filtering or trigger DNS64 processing if a
requested AAAA record does not exist. (See Configuring IPv6 Transition Technologies on
page 148 for more information about IPv4 filtering and DNS64 processing.)
• Merge zone responses do not use NXDOMAIN redirection processing. (See Redirecting
NXDOMAIN Responses on page 156 for more information about NXDOMAIN
redirection.)
• The Secure64 DNS Cache server acting as an authoritative server through the merge zone
feature does not respond to queries it may receive related to zone transfers (such as IXFR
or AXFR) or other authoritative server maintenance. The zone data is managed on the
authoritative server(s) as usual.
• The Secure64 DNS Cache server acting as an authoritative server through the merge zone
feature is authoritative for the configured merge zone name(s) only. It continues to
operate as a DNS caching server for all other domains. As with any Secure64 DNS Cache
server configuration, you can limit access to the server through its configured incoming
interfaces and access control specifications.
• The Secure64 DNS Cache server caches a result as follows:
— Full responses are cached based on the TTL of the response RRs.
— SERVFAIL and empty NOERROR responses are cached based on the cache-
servfail-ttl: configuration attribute.
— NXDOMAIN responses are cached based on the TTL of the SOA.
— Cached responses do not use the prefetch feature.
145
Example:
merge-zone:
name: “example.com”
merge-addr: 192.168.127.1
merge-addr: 192.168.127.2
merge-addr: 192.168.127.3
In the above example, assume the following:

• Authoritative server 1- includes zone information for the us.example.com and
news.example.com subdomains
• Authoritative server 2- includes zone information for the us.example.com and
images.example.com subdomains
• Authoritative server 3- includes zone information for the news.example.com and
images.example.com subdomains
Each subdomain is defined twice to avoid a single point of failure if one of the authoritative
servers is down. A request for a record in the “news.example.com” subdomain will result in the
Secure64 DNS Cache server querying the first authoritative server. If it receives an answer,
processing is complete. If it receives an NXDOMAIN response, it queries the next server in
the list. Assuming all 3 authoritative servers are operational, the query would be answered in a
maximum of 2 lookups.
Checking Merge Zone Configuration

You can use the cachedns lookup command to verify that the Secure64 DNS Cache server is
configured to retrieve an answer from a defined merge zone.
To display the resolver information for a cached merge zone domain name:
1. Use the dig command or another method to send a request for a domain defined by a
merge zone to the Secure64 DNS Cache server.
2. Log into Secure64 DNS Cache with a user account assigned to the cachednsadmin role.
3. At the view prompt, type enable cachednsadmin and press ENTER to enable
cachednsadmin mode.
4. At the cachednsadmin prompt type cachedns lookup <name> referral
<record_type> and press ENTER, where <name> is the domain name to look up
and <record_type> is the DNS record.
5. The authoritative name server(s) defined by the merge-addr: attribute should display
in the a list of name servers used for lookup of the domain.
146
Example:
[cachednsadmin@Secure64]# cachedns lookup secure64.com referral A
View: default
Cache: default
The following name servers are used for lookup of secure64.com.:
Queries for secure64.com. are resolved from the authoritative
server(s) at:
64.92.220.221 @53 not in infrastructure cache.

2607:fa88:1002::fff0@53 not in infrastructure cache.
147
Configuring IPv6 Transition Technologies

The Secure64 DNS Cache server includes two configurable mechanisms to facilitate the
transition to IPv6 addresses:
• DNS64
A mechanism that synthesizes AAAA records from A records, allowing an IPv6 client
to access the IPv4 Internet
• IPv4 filtering
A mechanism that filters AAAA records in answers to clients connecting via IPv4,
preventing delays and connectivity issues
DNS64
About DNS64 and NAT64
DNS64 works in conjunction with a NAT64 device to translate IPv4 addresses into IPv6
addresses. It applies to requests from an IPv6-only client for a name that does not have an IPv6
address (AAAA record).
As shown in Figure 9, when an IPv6 client requests an IPv6 destination on the Internet, the
traffic is handled via IPv6. With DNS64 and NAT64 enabled, when an IPv6 client requests an
IPv4 destination, the DNS64 mechanisms synthesizes the IPv4 destination response into an
IPv6 destination. The packets are translated by the NAT64 device to access the IPv4 Internet.
To the client, it appears that every destination on the Internet has an IPv6 address.
Figure 9. DNS64/NAT64 overview
148
Figure 10 illustrates how an IPv4 address is synthesized into an IPv6 address when DNS64 is
enabled. If an authoritative DNS server responds that there is not an AAAA resource record the
for the name, the Secure64 DNS Cache server requests the A resource record. DNS64
synthesizes an AAAA resource record from the A resource record via an algorithm and a
configured IPv6 prefix.
The synthesized AAAA response is sent to the requesting client, which uses a separately
configured NAT64 IPv6/IPv4 translator to convert the response. In order to perform the
translation, the NAT64 device must be configured to use the same IPv6 prefix as the DNS64
configuration.
Figure 10. DNS64/NAT64 query handling for IPv4
149
Configuring DNS64
To implement DNS64/NAT64, you need to enable DNS64 in the Secure64 DNS Cache
server’s cache.conf configuration file. This is done by configuring one or more IPv6 prefixes
for one or more NAT64 devices. The NAT64 device(s) must be configured to use the same
IPv6 prefix(es) as the DNS64 configuration.
Note DNS64 synthesized answers are not retained in the Secure64 DNS Cache server’s caches. As a
result, enabling DNS64 can affect server performance.
To configure DNS64 for Secure64 DNS Cache, define the following in the server:
clause of the cache.conf configuration file:
dns64-prefix: <Pref64::/n>
where:
— Pref64:: is the IPv6 prefix to use when synthesizing an IPv6 address from an
IPv4 address.
— n is the prefix length. Acceptable prefix lengths are 32, 40, 48, 56, 64, or 96.
Example:
dns64-prefix: 2001:db8:122:344::/96
The prefix length determines the position of the IPv4 address within the synthesized IPv6
address. Specifically, the synthesized address algorithm is:
• Concatenate the prefix, the 32 bits of the IPv4 address, and the suffix (if needed, set to
zero) to obtain an 128-bit address
• If the prefix length is less than /96, insert the null octet “u” at the appropriate position
(bits 64 to 71)
For example, a prefix length of /96 causes the four octets of the IPv4 address to become the
last four octets of the synthesized IPv6 address. (As noted, bits 64-71 must be set to zero in the
synthesized IPv6 address. For a /96 prefix length, you can do this by constructing a /96 prefix
using a /64 prefix and adding four octets set to zero.)
Examples:
• With a prefix of 2001:db8:122:344::/96 and an IPv4 address of 192.0.2.33
The synthesized IPv6 address is 2001:db8:122:344::192.0.2.33
The synthesized IPv6 address is 2001:db8:122:344:c0:2:2100::
The synthesized IPv6 address is 2001:db8:122:3c0:0:221::
150
Note For additional details about addressing techniques and standards for DNS64, see the Internet Draft
“draft-ietf-behave-address-format.”
Defining Multiple DNS64 Prefixes

You can define multiple dns64-prefix: attributes to support multiple NAT64 devices and
spread the load across the devices. Each NAT64 has a different IPv6 prefix defined, which are
also defined in the dns64-prefix: attributes of the Secure64 DNS Cache cache.conf
configuration file.
When more than one prefix is defined, Secure64 DNS Cache allocates use of the prefixes based
on DNS query source. (Specifically, the system uses the last octet of the IP address of the
requesting client and the modulo of that value against the number of prefixes defined to select the
prefix used for the client.) As a result, the requesting client uses the same prefix, and the load is
spread across the NAT64 devices.
Example:
dns64-prefix: 2607:fb90:beef::/96
dns64-prefix: 2001:db8:01a0::/96
dns64-prefix: 1234:db8:5678::/96
Using the above example, assume the client’s IP address is 2001:abcd::1998. The modulo of 98/3
is 2, which causes the third dns64-prefix: to be selected (since the internal ordering is 0, 1, 2).
For the given client, the same dns64-prefix: is always selected (assuming the same number of
defined prefixes and the same client IP address).
Customizing DNS64 Behavior for Specific Clients

If you want to customize DNS64 behavior for specific clients, you can use the views feature. With
views, you can specify configurations based on the client’s IP address and/or destination IP
address and apply a different DNS64 attribute. For details, see Defining Views on page 163.
Note DNS64 and IPv4 filtering can be used together. For more information, see Using IPv4 Filtering with
DNS64 on page 155.
151
IPv4 Filtering
Enabling IPv4 filtering on the Secure64 DNS Cache server can help prevent connection
problems and delays for clients attempting to access IPv4-based content. The issue can occur
when some applications or operating systems request AAAA DNS records by default, even if
the client’s IPv6 Internet connectivity is broken.
Figure 11. Delays can occur with AAAA queries over IPv4 connections
152
When enabled, IPv4 filtering causes the Secure64 DNS Cache server to return AAAA records
only to clients that successfully connect via IPv6. Enabling filtering causes Secure64 DNS Cache
to remove the AAAA record from the response to clients that connect via IPv4. Filtering applies
to both authoritative and non-authoritative answers.
! WARNING You should enable IPv4 filtering only if necessary, as it changes the default behavior of the DNS.
In addition, IPv4 filtering is not performed for answers from DNSSEC-signed zones.
Figure 12. IPv4 filtering enabled
Note When filter-aaaa-on-v4: is enabled, the Secure64 DNS Cache server does not provide
AAAA records in the answer section of the response. It does allow AAAA records in the additional
section.
153
Example dig output without IPv4 filtering:

; <<>> DiG 9.4.3-P3 <<>> ipv6.google.com aaaa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56176
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 4
;ipv6.google.com. IN AAAA
;; ANSWER SECTION:
ipv6.google.com. 10567 IN CNAME ipv6.l.google.com.
ipv6.l.google.com. 67 IN AAAA 2001:4860:8007::63
;; AUTHORITY SECTION:
google.com. 78086 IN NS ns1.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 78082 IN A 216.239.32.10
ns2.google.com. 78082 IN A 216.239.34.10
Example dig output with IPv4 filtering enabled:

; <<>> DiG 9.4.3-P3 <<>> ipv6.google.com aaaa
;; global options: printcmd
;; Got answer:
;ipv6.google.com. IN AAAA
;; ANSWER SECTION:
ipv6.google.com. 10567 IN CNAME ipv6.l.google.com.
ns1.google.com. 78082 IN A 216.239.32.10
ns2.google.com. 78082 IN A 216.239.34.10
154
Configuring IPv4 Filtering
To configure IPv4 filtering for Secure64 DNS Cache, define the following in the server:
filter-aaaa-on-v4: <yes|no>
If set to yes, the server filters out AAAA records in the answer section of a response to clients
connecting via IPv4. If not defined, the default is no.
Example:
filter-aaaa-on-v4: yes
Customizing IPv4 Filtering Behavior for Specific Clients

If you want to customize IPv4 filtering behavior for specific clients, you can use the views feature.
With views, you can specify configurations based on the client’s IP address and/or destination IP
address and apply a different attribute to the default behavior defined by your cache.conf
configuration file. For details, see Defining Views on page 163.
Using IPv4 Filtering with DNS64

The filter-aaaa-on-v4: and dns64-prefix: attributes can be used together. When both
attributes are enabled and an AAAA query is received:
• The Secure64 DNS Cache server attempts to obtain the AAAA answer
• If the server obtains an AAAA answer:
— If the query is from an IPv4 connection, the AAAA record is filtered from the
response
— If the query is from an IPv6 connection, the AAAA record is included in the response
• If the server cannot obtain an AAAA answer, it obtains the A record and synthesizes the
AAAA response:
— If the query is from an IPv4 connection, the synthesized AAAA record is filtered
from the response
— If the query is from an IPv6 connection, the synthesized AAAA record is included in
the response
155
Redirecting NXDOMAIN Responses

When users mistype a domain name, the corresponding response code (RCODE) from the
authoritative server indicates that the domain does not exist (NXDOMAIN). Typically, the
user’s browser responds with an error message that the server does not exist.
With NXDOMAIN redirection, you can configure the Secure64 DNS Cache server to redirect
NXDOMAIN responses to an IP address. You can use this feature to provide alternative
information such as search mechanisms, related web sites, or additional help.
! WARNING NXDOMAIN redirection is an optional feature available only to authorized organizations.
For authorization to use the NXDOMAIN redirection feature, you must include the NXDOMAIN
redirection feature in your organization’s Secure64 DNS Cache license agreement.
Note To simply redirect all queries for a specific domain, use the local-zone attribute with the redirect option
as discussed in Configuring Local Zones on page 108.
To provide security and interoperability with the DNS, Secure64 DNS Cache offers the
following features:
• By default, NXDOMAIN redirection is disabled.
• When enabled, NXDOMAIN redirection applies only to A and AAAA DNS records.
All other record types are not redirected.
• By default, NXDOMAIN redirection is not executed on a DNSSEC-signed response
of non-existence of a domain. You can configure the server to redirect signed
NXDOMAIN responses when certain conditions are met, as discussed in DNSSEC
and NXDOMAIN Redirection on page 157.
• A rule syntax is available to specifically define the domain queries to redirect.
Note The rule syntax does NOT follow regular expression format. See the configuration information and
examples that follow for details about the rule syntax.
• The time-to-live (TTL) for NXDOMAIN redirection for the recipient (client) defaults
to 0 (no TTL) and cannot be set longer than 60 seconds. This minimizes conflicts with
domain owners’ changes in the DNS that modify former NXDOMAIN responses into
responses where the name does exist.
156
• Server administrators can offer users a method for opting out of NXDOMAIN
redirection.
• You can configure Secure64 DNS Cache to log NXDOMAIN redirection activity. For
details, see Logging NXDOMAIN Redirection Activity on page 162.
Note You can configure different NXDOMAIN redirection behavior for specific clients using the view: clause.
For details, see Defining Views on page 163.
DNSSEC and NXDOMAIN Redirection

By default, NXDOMAIN redirection does not occur for DNSSEC signed responses. However,
you can configure the server to redirect signed responses in some cases.
Conditions that cause NXDOMAIN redirection to occur for a signed response are:
• The attribute nxdomain-redirect-dnssec-allow: yes in the cache.conf configuration
file, and
• The client query indicates that DNSSEC is not enabled (DO flag is not included;
equivalent to the dig +nodnssec command), and
• The client query does not include the CD (Checking Disabled) flag, and
• The NXDOMAIN response is signed
Table 30 summarizes the expected behaviors based on the client query and the cache.conf
configuration file settings, when NXDOMAIN redirection is enabled:
Table 30. NXDOMAIN redirection and DNSSEC
Client Query Unsigned Response Signed, Valid Response Signed, Bogus Response
CD flag or DO flag set Redirect Do not redirect Do not redirect
If redirection for DNSSEC is If redirection for DNSSEC is
configured no (default), do not configured no (default), do
CD flag not set and DO redirect not redirect
Redirect
flag not set
If redirection for DNSSEC is If redirection for DNSSEC is
configured yes, redirect configured yes, redirect
157
Configuring NXDOMAIN Redirection

Table 31 defines the NXDOMAIN configuration attributes. Place the attributes in the
server: clause section of the cache.conf configuration file. At a minimum, you must define
where to redirect the queries (use the nxdomain-redirect-destination: attribute) and
what to redirect (use the nxdomain-redirect-modify: attribute).
Table 31. NXDOMAIN redirection configuration attributes
Attribute: Value
nxdomain-redirect-destination: <IP_address> The IPv4 or IPv6 address of the servers to
nxdomain-redirect-destination: 71.33.226.72 receive redirected NXDOMAIN
nxdomain-redirect-destination: 192.168.127.94 responses. This can be an external
service over the Internet or an internal
network server that you host.
The IP addresses appear in the A or
AAAA records in the redirect response.
Multiple IP addresses can be listed;
define one line per IP address.
There is no limit on the number of
destinations listed; however, a maximum
of 13 are referred in each response. If
more than 13 IP addresses are defined,
the system circulates through the list.
If not defined, the default is no
NXDOMAIN redirection.
nxdomain-redirect-modify: “<rule1>” [<AND|OR> Defines a rule string to match one or more
“<rule2>”]... fully qualified domain names. When the
nxdomain-redirect-modify: “example” domain owner response is NXDOMAIN,
nxdomain-redirect-modify: “êxam” AND “.net.$” domains that match the defined rules are
nxdomain-redirect-modify: “êxample.com.$” redirected to the defined redirect
nxdomain-redirect-modify: “.” destination. Note that the syntax does
NOT follow regular expression format.
Multiple nxdomain-redirect-
modify: attributes are allowed.
Rule strings can use the following syntax
and symbols for matching:
<string>- The domain name includes
the defined string.
^<string>- The start of the domain
name must match the rule string.
<string>.$- The end of the domain
AND|OR- operators that you can use to
combine rule strings.
“.” - redirect all remaining domains;
should be after all other nxdomain-
redirect-modify: attributes.
158
nxdomain-redirect-log: <yes|no> Defines whether to log NXDOMAIN

nxdomain-redirect-log: no redirection activity. For additional
information, refer to Logging NXDOMAIN
Redirection Activity on page 162.
nxdomain-redirect-log-file-num: <num> Defines the total number of NXDOMAIN
nxdomain-redirect-log-file-num: 10 redirection log files to maintain, within the
range of 1-128. The files are stored in the
nxrd_logging directory of the
cachednsadmin role. Filenames use the
syntax redirect_log_<8-digit-rolling-
number>.
If NXDOMAIN redirection logging is
enabled and the number of files is not
defined, the default is 10.
nxdomain-redirect-log-file-size: <bytes> Defines the size of the NXDOMAIN
nxdomain-redirect-log-file-size: 1000 redirect log file(s).
If NXDOMAIN logging is enabled and the
log file size is not defined, the default is
1073741824 (1 GB).
nxdomain-redirect-ttl: <seconds> Defines the amount of time to retain
nxdomain-redirect-ttl: 0 redirection responses on the client
receiving the response. The range is low
(0 to 60 seconds) to avoid conflicts with
redirection and domain owners’ changes
in the DNS that result in removing the
NXDOMAIN response.
If not defined, the default is 0 (no TTL).
nxdomain-redirect-pass: “<rule1>” [<AND|OR> “<rule2>”]... Defines a rule string to match one or more
nxdomain-redirect-pass: “.gov.$” fully qualified domain names. Domains
nxdomain-redirect-pass: “êxam” AND “.com.$” that match any of the defined pass rules
nxdomain-redirect-pass: “êxample.com.$” are not redirected. Note that the syntax
does NOT follow regular expression
format.
Multiple nxdomain-redirect-
pass: attributes are allowed.
Rule strings can use the following syntax
and symbols for matching:
<string>- The domain name includes
the defined string.
^<string>- The start of the domain
<string>.$- The end of the domain
AND|OR- operators that you can use to
combine rule strings.
159
nxdomain-redirect-optout: <IP_address>[/prefix] Defines an IPv4 or IPv6 address and

nxdomain-redirect-optout: 231.22.0.0/16 prefix length of clients to omit from
NXDOMAIN redirection. The clients with
matching IP addresses will receive the
NXDOMAIN response. Multiple
arguments can be listed.
This attribute allows server administrators
to provide users the choice to opt out from
NXDOMAIN redirection.
If not defined, default is to redirect all
client IP addresses.
nxdomain-redirect-dnssec-allow: <yes|no> If set to yes, NXDOMAIN redirection is
nxdomain-redirect-dnssec-allow: no enabled for signed NXDOMAIN
responses, when both the CD (checking
disabled) flag is not set and the DO
(DNSSEC OK) flag is not set in the client
request.
If set to no, when both the CD (checking
disabled) flag is not set and the DO
(DNSSEC OK) flag is not set in the client
request, do not enable NXDOMAIN
redirection for signed NXDOMAIN
responses.
For additional details about NXDOMAIN
redirection and DNSSEC, see DNSSEC
and NXDOMAIN Redirection on
page 157.
Note You can configure different NXDOMAIN redirection information for specific clients using the view
clause. For details, see Defining Views on page 163.
Example:
server:
auto-start: yes
interface: 192.168.127.99
interface: 2001:DB8::5
port: 53
access-control: ::1 allow
access-control: 217.132.248.134 deny
edns-buffer-size: 4096
root-hints: root.hints
do-ip4: yes
do-ip6: yes
do-tcp: yes
160
#IP addresses to list for A or AAAA responses in place of an

#NXDOMAIN response
nxdomain-redirect-destination: 212.33.231.82
#No nxdomain TTL

nxdomain-redirect-ttl: 0
#Allow redirect of signed NXDOMAIN responses if the

#client query has both the CD and DO flags clear
nxdomain-redirect-dnssec-allow: yes
#Enable logging of NXDOMAIN redirection activity

nxdomain-redirect-log: yes
nxdomain-redirect-log-file-num: 5
nxdomain-redirect-log-file-size: 5242880
#Rules to specify domains that are not redirected.

#Do not redirect domains that contain “private”
nxdomain-redirect-pass: “private”
#Do not redirect domains that start with ftp.

nxdomain-redirect-pass: "^ftp."
#Do not redirect domains that end with .org

#Note: Use fully-qualified domain names
nxdomain-redirect-pass: ".org.$"
#Do not redirect the domain that matches exactly www.example.com

nxdomain-redirect-pass: "^www.example.com.$"
#Do not redirect domains that contain “my” and end with
#“secure64.com.”
nxdomain-redirect-pass: “my” AND “secure64.com.$”
#Rule(s) to specify domains to redirect when the domain owner

#response is NXDOMAIN (domains that meet the pass rules are
#not redirected).
#Redirect all remaining domains
nxdomain-redirect-modify: “.”
#Redirect opt-out IP addresses

nxdomain-redirect-optout: 231.22.0.0/16
161
Testing NXDOMAIN Redirection

You can test NXDOMAIN response redirection using the dig tool (see Using the Secure64 DNS
Cache dig Command on page 369). Using the above configuration example, a response to a query
for www.example.com should include the list of A records based on the list of nxdomain-
redirect-destination: arguments.
Logging NXDOMAIN Redirection Activity

The Secure64 DNS Cache server can log information about NXDOMAIN redirection activity.
This can help provide a record of redirection responses for auditing and troubleshooting
purposes.
NXDOMAIN redirection logging rules, configuration, and behaviors include:
• Messages are logged to disk in the nxrd_logging directory of the cachednsadmin role
• Log files use the naming convention redirect_log_<num> where num is a 8-digit
rolling number based on the number of log files the server is configured to retain
• Information for all NXDOMAIN activity is written to the same log file
• You can limit the size and number of the log files using the nxdomain-redirect-
log-file-size: and nxdomain-redirect-log-file-num: attributes, respectively.
• If you change the nxdomain-redirect-log-file-num: and nxdomain-redirect-log-
file-size: attributes, stop and start the server to activate. You can activate changes to
the nxdomain-redirect-log: attribute using the cachedns reload command
To configure NXDOMAIN redirection logging in Secure64 DNS Cache:

• Enable logging for NXDOMAIN redirection in the server: clause of cache.conf
using the syntax:
nxdomain-redirect-log: yes
• Configure the nxdomain-redirect-log-file-num: and nxdomain-redirect-log-file-
size: attributes in the server: clause of cache.conf.
Note These are global setting. The default values and acceptable ranges are detailed in Table 31 on
page 158.
• Stop and start the server (issue the stop cachedns and start cachedns commands.
Log output contains the date/time, the view name, the client IP address, the domain name
queried, and the action taken, for example:
Aug 23 15:50:11 View: default, Query from client 192.168.127.17 for
domain staticlog.com. IN A redirected
162
Defining Views
A view allows you to configure different functionality and attributes based on characteristics of
the requesting client. The methods used to characterize clients for a view are:
• The source IP address of the requesting client, and/or
• The query destination IP address of the incoming message (the IP address on the
Secure64 DNS server to which the query was sent)
Note When based on the destination IP address, a view is valid only if the Secure64 DNS Cache server is
configured to listen for queries on multiple IP addresses (defined with the interface: attribute in the
server: clause).
To customize behaviors based on the requesting client defined by the view, you can define the
following configuration attributes in a view:
• Root hints information (root-hints: attribute)
• DNS64 functionality (dns64-prefix: attribute)
• IPv4/AAAA record filtering (filter-aaaa-on-v4: attribute)
• Local zones information (local-zone:, local-data:, local-data-ptr: attributes)
• NXDOMAIN redirection (nxdomain-redirect-ttl:, nxdomain-redirect-
destination:, nxdomain-redirect-pass:, nxdomain-redirect-modify:,
nxdomain-redirect-optout:, nxdomain-redirect-dnssec-allow:, nxdomain-
redirect-log: attributes, assuming your organization is authorized for NXDOMAIN
functionality)
• One IPv4 and/or one IPv6 outgoing interface (outgoing-interface: attribute) to
define the source of queries from the defined view (see also Creating Location-Based Views
on page 169 for more information)
• Drop type ANY (drop-any: attribute) to drop all incoming queries of the type ANY
• Drop type MX (drop-mx: attribute) to drop all incoming queries of type MX
163
View Clause Configuration Attributes

Table 32 lists the attributes available when configuring a view: clause:
Table 32. View configuration attributes
Attribute: Value
view-name: <name> Required. Defines a unique name for the view; maximum
view-name: internal of 64 characters.
cache-name: <name> Optional. Defines a configured cache to use for this view.
cache-name: central The cache must be defined using the cache attribute in
the server clause (see Configuring Separate Caches
on page 168 for details). Multiple views can use the same
cache-name.
Note: If a view defines its own root-hints: file, then a
separate cache is required for the view.
If not defined, the view uses the default shared cache.
match-clients: <ip_spec> Defines the clients to use the view based on the IPv4 or
match-clients: 3ffe:801::/32 IPv6 source address(es) of the incoming message. At
least one match-clients or match-destinations
attribute is required (defining both is allowed).
For ip-spec:
Plain IP address (IPv4 or IPv6): 1.2.3.4
Subnet: 1.2.3.0/24
Note that if used in combination with different match-
destinations, you can define a specific ip-spec
more than once.
To define multiple match-clients for a view name,
list one attribute for each, one per line.
match-destinations: <ip_address> Defines the clients to use the view based on the
match-destinations: 192.168.127.100 destination IPv4 or IPv6 address(es) of the incoming
message (the IP address on the Secure64 DNS server to
which the query was sent). At least one match-clients
or match-destinations attribute is required (defining
both is allowed).
The Secure64 DNS Cache server must be listening for
queries on multiple IP addresses (defined by the
interface attribute), and the destination IP address
must be one of the addresses defined.
Note that if used in combination with different match-
clients, you can define a specific IP address more
than once.
To define multiple match-destinations for a view
name, list one attribute for each, one per line.
164
Rules, Options, and Behaviors

View clause rules, options, and behaviors include:
• The view: clause(s) must be after the server:, forward-zone:, stub-zone:, and
merge-zone: clauses.
• Local zones/local data and NXDOMAIN redirection information in a view are treated as
data sets rather than individual configuration attributes. To ensure the settings are correct
for the view, define all local zones/local data or NXDOMAIN redirection information in
the view. For example, if you define a local-zone: in a view, then include all local-
zone:, local-data:, and local-ptr: attributes that you want to be in effect for the
view.
• A view automatically inherits the configuration items from the server:, forward-
zone:, stub-zone:, and merge-zone: clauses, with the exception of the values defined
inside the view for:
— The root-hints; dns64-prefix:, filter-aaaa-on-v4:, or outgoing-
interface: attributes
— The local zones/local data or NXDOMAIN redirection data sets
• Multiple view clauses can be defined, up to a limit of 64.
! WARNING If defining multiple views, take care when configuring the match-clients: and match-
destinations: attributes to ensure that each view definition is unique. If multiple views have
the same definition, the last one in the list is used.
• The view: clause and a unique view-name: for each view are required.
• At least one match-clients: or match-destinations: attribute is required (defining
both is allowed).
• If only match-destinations: is specified for a view name, that view becomes the
default for all traffic received on that interface (as opposed to the non-view
configuration). To use other views on the interface, specify match-clients: in addition
to the same match-destinations: attribute.
• If only match-clients: is specified for a view name, that view becomes the default
view for the specified client IP address(es).
• A match-clients: attribute defined for one view can be a superset of a match-
clients: attribute defined for another view.
• If you add, remove, or change the view-name:, match-clients:, match-
destinations:, or cache-name: attributes, you must stop and start the server to make
the changes effective (you cannot use the cachedns reload command for this purpose).
• The cachedns reload command is operational for reloading DNS64, IPv4 filtering, local
zone, NXDOMAIN redirection, and drop type ANY components of the view.
165
• Views use the default shared cache, unless the view includes the cache-name: attribute
to link to a separately configured cache (discussed in Configuring Separate Caches on
page 168).
• Views use the default root-hints:, unless the view includes the root-hints:
attribute. If the view includes the root-hints: attribute, it must also use a separately
configured cache (see Configuring Separate Caches on page 168).
• Implementing views reduces the performance of the server both for cache hits and
misses.
Examples:
view:
view-name: IPv6transition
# applies to all clients with the specified IP address, regardless
# of the destination IP address receiving the query
match-clients: 192.168.111.0/24
filter-aaaa-on-v4: yes
view:
view-name: no_google # don't let clients use Google search
# applies to clients with the specified IP address querying
# the match-destinations IP address
match-destinations: 192.168.127.45
match-clients: 192.168.122.0/24
local-zone: "google.com" static
view:
view-name: no_bing # don't let clients use Bing search
# applies to clients with the specified IP address querying
# the match-destinations IP address
match-clients: 192.168.133.0/24
local-zone: "bing.com" static
view:
view-name: redirect
# applies to all clients querying the specified destination IP
# address
# Except those matching the IPv6transition view
#IP addresses to list for A or AAAA responses in place of an

#NXDOMAIN response
166
#No nxdomain TTL

nxdomain-redirect-ttl: 0
#Rules to specify domains that are not redirected.

#Do not redirect domains that start with ftp.
nxdomain-redirect-pass: "^ftp."
#Do not redirect domains that end with .org

#Note: Use fully-qualified domain names
nxdomain-redirect-pass: ".org.$"
#Rule(s) to specify domains to redirect when the domain owner

#response is NXDOMAIN (domains that meet the pass rules are
#not redirected).
#Redirect all remaining domains
nxdomain-redirect-modify: “.”
#Redirect opt-out IP addresses

nxdomain-redirect-optout: 231.22.0.0/16
Figure 13 provides an illustration of the previous examples, showing how incoming queries are
directed to the configured views or the default (non-view) configuration.
Figure 13. Illustration of view examples
167
Configuring Separate Caches

By default, views you define in the Secure64 DNS Cache cache.conf configuration file use
the server’s default shared cache. If you want to configure views that obtain a different response
to queries for the same information (for example, location-based views), the views should use
separate caches. When configuring separate caches, the associated rules, options, and behaviors
include:
• The cache: attribute in the server: clause defines a separate cache.
• Multiple views can share a separate cache in the cache-name: attribute.
• If the view includes its own root-hints:, then a separate cache is required.
Note Do not define the same cache in views that you expect to receive different answer values for the same
set of queries.
• If the view does not define a separate cache, it uses the default shared cache.
• If you define a separate cache, it must be used in a view or the server will not start.
• Named caches use memory separate from the default cache. To ensure total memory
use does not exceed available memory, be sure to consider all memory specified. For
example, if the system as configured prior to adding named caches was close to using all
system memory, then cache sizes must be reduced to allow for the new named caches.
To define a separate cache:

• Configure the cache: attribute in the server: clause using the following format:
cache: name: “<name>” msg-cache-size: <bytes>[k|m|g] rrset-cache-size: <bytes>[k|m|g]
where:
name is a string in quotes that defines the name of the separate cache.
msg-cache-size is the amount of memory for the answer cache for this separate
cache. Plain value is in bytes or append k (kilobytes), m (megabytes) or g (gigabytes).
rrset-cache-size is the amount of memory for the referral (RRset) cache for this
separate cache. Plain value is in bytes or append k (kilobytes), m (megabytes) or g
(gigabytes).
Example:
cache: name: ”north” msg-cache-size: 1024m rrset-cache-size: 512m
cache: name: ”central” msg-cache-size: 1024m rrset-cache-size: 512m
168
Note For an example of how to use separate caches in views, see Creating Location-Based Views on
page 169.
Checking View Information

Once you have defined a view and started the server, you can check information about the view
operations using the show cachedns info view <viewname> command. For details about the
command, see Displaying Statistics at the Command Line on page 215.
Creating Location-Based Views

Overview
You can use views on the Secure64 DNS Cache server to enhance performance or reduce latency
for requesting clients based on geographic location. The process is handled by configuring the
caching server(s) and authoritative server(s) as follows:
• Configure the caching server to direct DNS queries to specific views with separate caches
based on the location of requesting clients using the match-clients attribute
• Configure the location-based views on the caching server to use a specific outgoing-
interface:
• Configure authoritative DNS servers with location-based views that correspond to the
source IP address (outgoing-interface:) of the caching server
• Configure the authoritative server zone files to return the content server closest to the
requesting client
Configuring Location-Based Views
To define a location-based view:

1. Assuming you do not want the view to use the default shared cache, configure the cache
attribute in the server clause using the following format, for each separate cache as
needed:
cache: name: “<name>” msg-cache-size: <bytes>[k|m|g] rrset-cache-size: <bytes>[k|m|g]
where:
name is a string in quotes that defines the name of the separate cache.
msg-cache-size is the amount of memory for the answer cache for this separate cache.
Plain value is in bytes or append k (kilobytes), m (megabytes) or g (gigabytes).
rrset-cache-size is the amount of memory for the referral (RRset) cache for this
separate cache. Plain value is in bytes or append k (kilobytes), m (megabytes) or g
(gigabytes).
169
2. In the view clause, link the separate cache to the view using the cache-name: attribute.
3. In the view clause, define the match-clients: attribute
4. In the view clause, define the outgoing-interface: attribute based on location. You
can define one IPv4 address and one IPv6 address.
Example:
The north and central locations are using a separate cache so that client queries directed to
those views can use a different outgoing-interface:. The south location is using the default
shared cache.
server:
auto-start: yes
incoming-query-timeout: 30
num-recursive-clients: 20000
outgoing-query-timeout: 400
outgoing-query-increment: 800
interface: 0.0.0.0
outgoing-interface: 1.2.3.4
msg-cache-size: 1024m
msg-cache-slabs: 1
rrset-cache-size: 512m
rrset-cache-slabs: 1
cache: name: ”north” msg-cache-size: 1024m rrset-cache-size: 512m

cache: name: ”central” msg-cache-size: 1024m rrset-cache-size: 512m
view: #view for north location

view-name: northcenter
cache-name: north
match-clients: 1.4.0.0/16
view: # view for the central location

view-name: centralcenter
cache-name: central
view: # view for the south, which catches all others

view-name: southcenter
# this view uses the default shared cache
170
171
Advanced Security Configuration

Secure64 DNS Cache provides built-in and configurable methods for that enhance the server’s
security and allow you to customize your configuration based on the individual server’s
operational environment.
Built-in Security Features

• System-level security (see Inherent Security on page 224 and DNS Packet Inspection on
page 225)
• DNS caching server defenses (see Built-in Features to Prevent Cache Poisoning and Spoofing
on page 118)
Configurable Options
These options allow you to:
• Mitigate and rate limit UDP and TCP data floods (see About Data Flood Protection
Mechanisms on page 226
• Mitigate and rate limit excessive queries based on query type (see DNS RRtype Filtering
Rules on page 238)
• Enable DNSSEC validation in the Secure64 DNS Cache resolver (see Enabling
DNSSEC-Validated Queries on page 128).
• Control the clients that can or cannot access the DNS server (use the access-
control: attribute (see Configuring Basic Server Attributes on page 96)
• Define certain IP addresses that the server will not query, (use the do-not-query-
address: attribute, see Other Security, Hardening, and Testing Settings on page 121)
• Configure basic security settings to defend against cache poisoning, spoofing, and other
security issues (see Configuring for Basic Security on page 118)
• Filter queries based on query type (see Filtering Requests Based on Incoming Query Type in
the following section)
• Compare a query to an internal list of blacklisted domains via a local zone (use the
local-zone: clause, see Blacklisting Domains Using Local Zone Configuration on page 173)
• Forward a query to a different server running rbldnsd or similar software for DNS
blacklist (DNSBL) support (use the forward-zone: clause and related attributes, see
Defining Resolver Forwarding on page 138)
• Dynamically change certain configuration attributes without stopping and starting the
server (see Reloading Configuration Changes Dynamically on page 185)
172
Filtering Requests Based on Incoming Query Type

For excessive queries of a specific RRtype, the Secure64 DNS Cache server offers several filtering
methods that vary in scope:
• Server-wide rate limiting and blacklisting: Configure the mitigation system to rate
limit and/or blacklist queries for a specific RRtype. This is the first line of defense. For
details, see DNS RRtype Filtering Rules on page 238.
• Per domain, using local zone: Configure the local zone attribute to take action on
incoming queries for a specific domain and RRtype. See the Blacklisting Domains Using
Local Zone Configuration section that follows.
• All ANY type queries or MX type queries: If the issue is related to ANY or MX
queries, configure the drop-any: or drop-mx: configuration attributes to block all
queries of the ANY or MX type. For details, see Other Security, Hardening, and Testing Settings
on page 121. You can also configure these for a specific source or destination IP address
using a view. For details about views, see Defining Views on page 163.
If each of these methods are enabled, the order of processing for the various filtering options is:
1. The server-wide mitigation system drops the query or passes it to the query front end.
2. The query front end system (configuration items such as drop-any: and drop-mx:)
drops the query or passes it to the resolver.
3. The resolver answers with local zone information or passes the query to the validator.
4. The validator processes DNSSEC information.
Blacklisting Domains Using Local Zone Configuration

You can define a list of blacklisted domains with the local-zone: configuration attribute. To
specify certain types of queries to blacklist within the domain, you can use the optional RRtype
parameter with the local-zone: attribute. For more information about using the local-zone:
configuration attribute, see Configuring Local Zones on page 108.
For blacklisting, local zone configuration uses the following rules:
• Local zone attributes are listed in the server: clause of the cache.conf file. You can
also define them in a view: clause to configure different behavior for specific clients.
• You can use an include file to maintain the blacklist as discussed in Maintaining Blacklists
Offline with an Include File on page 176.
• Do not define local data when using the static or refuse options with the local-
zone: attribute for blacklisting purposes
173
• For the optional RRtype local-zone: parameter, the supported RRtypes are:
A DLV KEY MX OPT SSHFP

A6 DNAME KX NAPTR PTR TALINK
AAAA DNSKEY LOC NIMLOC PX TLSA
AFSDB DS MAILA NS RP TSIG
ANY EID MAILB NSAP RRSIG TXT
APL GID MB NSAP_PTR RT UID
ATMA GPOS MD NSEC SIG UINFO
AXFR HINFO MF NSEC3 SINK UNSPEC
CERT IPSECKEY MG NSEC3PARAMS SOA WKS
CNAME ISDN MINFO NULL SPF X25
DHCID IXFR MR NXT SRV
Examples of Local Zone Blacklisting

• To configure the server to return an NXDOMAIN response for queries within the
domain, including subdomains:
• Specify the following in the server: clause of cache.conf:
local-zone: <zone> static
Example:
local-zone: “badzone1.” static
To configure the server to return a REFUSED response for queries within the domain,
including subdomains:
local-zone: <zone> refuse
Example:
local-zone: “badzone1.” refuse
174
To configure the server to return a REFUSED response for a specific RRtype for a
domain and its subdomains:
local-zone: “<zone>” refuse <RRtype>
Example:
#Send REFUSED in response to ANY queries for example.com and its
# subdomains
local-zone: “example.com” refuse ANY
To configure the server to return drop queries for a specific RRtype for a domain and its
subdomains:
local-zone: “<zone>” deny <RRtype>
Example:
#Drop MX queries for example.com and its subdomains
local-zone: “example.com” deny MX
To configure the server to return specific data for queries to a specific domain:
local-data: “<resource record>”
Example:
#return the defined record for queries to adserver.example.com
local-data: "adserver.example.com IN A 127.0.0.1"
To configure the server to return specific data for queries to a domain or subdomain:
local-zone: “<zone>” redirect
local-data: “<resource record>”
Example:
#return the defined record for queries to example.com and subdomains
local-zone: “example.com” redirect
local-data: "example.com IN A 10.0.0.1"
175
Maintaining Blacklists Offline with an Include File
To simplify maintenance of blacklisted domains, configure an include file as follows:

1. Create the local zone blacklist file on an off-line system that allows you to scp files to
2. Use scp to copy the file to the Secure64 DNS Cache server:
scp <blacklist> <user>@<host>:/cachednsadmin/<blacklist>
where:
3. Login to the Secure64 DNS Cache server as a user assigned to the cachednsadmin role.
5. In the server: clause of the cache.conf configuration file, add the following
statement:
include: <blacklist>
6. To load the configuration file changes, either stop and start the server (issue the stop
cachedns and start cachedns commands) or use the cachedns reload command.
The cachedns reload command loads the configuration changes without stopping the
server.
7. Use the dig command to verify that queries to the domains defined in the blacklist file
return the desired response. (For details about using the dig command, see Using the
Secure64 DNS Cache dig Command on page 369.)
To update a blacklist from off-line without stopping the caching server:

1. Update the blacklist file on an off-line system that allows you to scp files to the
Secure64 DNS Cache server.
2. Use scp to copy the file to the Secure64 DNS Cache server:
scp <blacklist> <user>@<host>:/cachednsadmin/<blacklist>
where:
3. Use a script to perform the cachedns reload command from the cachednsadmin role.
176
Specifying an Unbound Configuration File

If you have an existing Unbound configuration, you can also use the include: attribute to point
at an Unbound (unbound.conf) configuration file located on the name server. Secure64 DNS
Cache parses the Unbound configuration file when you start Secure64 DNS Cache and when you
perform other operations.
If information in the Unbound configuration file changes, Secure64 DNS Cache parses the
changes upon the next name server stop/start cycle.
Note Due to the differences in configuration attributes, some Unbound configuration clauses and statements
will be ignored by Secure64 DNS Cache. The unsupported attributes are noted when you start the server
and are detailed in Appendix C: Unbound Configuration Differences on page 479.
To specify the Unbound configuration file to import, securely copy the Unbound file to Secure64
DNS Cache and modify cache.conf to include the include: statement, as instructed below.
Note Define configuration parameters in the unbound.conf file, not the cache.conf file.
To specify the Unbound configuration file to include:

1. Copy the Unbound configuration file to the Secure64 DNS Cache server. Use the scp
command with the user designation.
scp [-P <port>] unbound.conf <user>@<host>:/cachednsadmin
where:
2. Add the include: statement to the cache.conf configuration file:
include: unbound.conf
177
178
Chapter 5. Managing Secure64 DNS Cache
Overview
This chapter discusses how to start and stop the server, test the server, flush items from the
cache, and monitor server information and statistics.
• For information about the server’s multiple resolver instance implementation,

refer to Multiple Resolver Instances on page 180
• To start or stop the server, refer to Starting and Stopping the Name Server on page 184.
• To dynamically change certain configuration attributes without stopping and
starting the server, see Reloading Configuration Changes Dynamically on page 185.
• To test caching and resolving functionality, refer to Testing the Name Server on
page 189.
• To flush items from the cache, display the server status, or lookup resolver
information, refer to Caching Server Utility Commands on page 193.
• To save, load, or preload cache information, refer to Saving and Loading the Cache on
page 204.
• To monitor query activity, refer to DNS Query Monitoring on page 207.
• To monitor server statistics and information, refer to Server Activity Reporting and
Statistics on page 215.
179
Multiple Resolver Instances

Effective with Secure64 DNS Cache version 3.0, the server software became available with the
Capacity Expansion Module (CEM). The CEM provides additional DNS resolver instances for
enhanced performance. It requires a minimum of (1) four-core processor or (2) two-core
processors and Secure64 DNS Cache CEM version 3.0 or higher. To verify the version running
on your system, you can use the version command as described in Displaying the Software and
Platform Version on page 374.
The following sections discuss the characteristics of multiple resolver instance operations,
including cache sizes, separation of caches, query handling, views, and query logging.
Caches and Size Distribution

The Secure64 DNS Cache server uses multiple types of caches. (For details, see Configuring
Caches and Internal TTL Values on page 104.) The caches are separated based on the type of
information they contain and how they use the information:
• Answer (message) cache - Answers (A, AAAA, MX, TXT, etc. records) and negative
(NXDOMAIN) responses
• Referral (RRset) cache - Referrals (NS records)
• Infrastructure cache - Round-trip time (RTT), EDNS, and lame delegation
information
• Key cache - DNSSEC public key information used for validation (RRSIG)
• Negative cache - Negative caching associated with DLV (see Using DLV on page 134)
Each cache has a separately configured cache size that defines the amount of memory to use
for the cache.
180
With systems using multiple resolver instances, each of the cache sizes are divided evenly among
the instances, as illustrated in Figure 14. For example, the answer and referral cache have 128 MB
of memory total by default. Each instance is allocated 1/3 of the total, or approximately 42.67
MB of memory:
Figure 14. Allocation of caches for multiple resolver instances
Independent Caches and Query Handling

Within each cache type, each resolver instance uses independent, separate caches that contain
information related only to the queries the specific instance receives and processes. As a result,
the resolver behavior and information cached for the same query handled by one instance can
differ from another instance, depending on the timing of the query and the available DNS
information. This is similar to the behavior of separate caching servers.
For UDP query handling, the Secure64 DNS Cache server distributes incoming queries from
clients across the instances. All TCP queries are handled by resolver instance 1.
Multiple Instances and Views

A view allows you to configure different functionality and attributes based on characteristics of
the requesting client. For example, you can use views to redirect certain clients, prevent certain
clients from accessing specific destinations, and reduce latency for requesting clients based on
geographic location. (For more information about views, see Defining Views on page 163.)
181
A view can use the default shared cache or a separately configured named cache. A separate
named cache includes its own answer and referral cache (the infrastructure cache, key cache,
and negative cache are always shared). It also defines memory sizes for the answer and referral
caches separate from the default shared caches. Figure 15 shows that the named cache assigned
to a view has separate answer and referral caches, and they are equally divided among instances.
Figure 15. Allocation of caches for multiple resolver instances, with a named cache for a view
182
Query Logging
Because the resolver behavior and DNS information can differ for each instance, Secure64 DNS
Cache creates separate query log directories and file sets for each instance. This maintains the
query/response sequences for each resolver instance to facilitate analysis and diagnostics. If the
server is running a single resolver instance, the server maintains one directory and with one set of
log files. For details, see DNS Query Logging on page 211.
Resolver Instances, Physical Processors, and Logical Processors

The physical CPU, logical processors, and resolver instances (CEM) align as shown in the table
below. Depending on the commands you are running or the system information you are using,
you can refer to the table when you need a cross reference of processor resources.
Processor or Name/ Name/ Name/ Name/

Resolver Number Number Number Number
Physical
CPU 0 CPU 1 CPU 2 CPU 3
(CPU)
Logical I/O 0 App 0 App 1 App 2
Resolver
Instance (CEM -- Instance 1 Instance 2 Instance 3
version)
183
Starting and Stopping the Name Server

Starting the Name Server
Note You can configure the Secure64 DNS Cache server to automatically load a previously saved cache
from a file. For more information, see Saving and Loading the Cache on page 204.
To start the Secure64 DNS Cache server:

cachednsadmin mode.
3. At the cachednsadmin prompt type start cachedns and press ENTER.
The system displays output similar to the following:
Starting cachedns
Started cachedns
4. To help you identify the amount of hard disk space allocated for different types of log
files, the command displays the total disk space allocated for NXDOMAIN redirection
logging, local zone logging, and query logging. The server makes use of the allocation(s)
for only the specific logging features you have enabled.
5. If errors display, proceed to Troubleshooting Startup Errors on page 192.
Stopping the Name Server

When you stop the server, all of the cached information is removed from memory. However,
you can configure the Secure64 DNS Cache server to automatically save the cached
information to a file. For more information, see Saving and Loading the Cache on page 204.
To stop the Secure64 DNS Cache server:

cachednsadmin mode.
184
3. At the cachednsadmin prompt type stop cachedns and press ENTER.

The system displays output similar to the following:
Stopping cachedns
Stopped cachedns
Reloading Configuration Changes Dynamically

You can change certain settings in the cache.conf file and then use the cachedns reload
command to load the changes without stopping and starting the server. Configuration attributes
that you can change dynamically include:
• basic reloadable attributes:
dump-cache-on-stop
load-cache-on-start
outgoing-query-timeout
outgoing-query-increment
incoming-query-timeout
dns64-prefix:
filter-aaaa-on-v4:
logging-flag-query-recv
logging-flag-query-resp
logging-flag-resolv-query
logging-flag-resolv-resp
logging-file-write-immediate
• security reloadable attributes:
access-control
hide-identity
hide-version
drop-any
drop-mx
• validation reloadable attributes:
val-override-date
val-clean-additional
val-permissive-mode
• local reloadable attributes:
local-zone
local-data
local-data-ptr
• zone reloadable attributes:
forward-zone name
forward-addr
185
forward-host
stub-zone name
stub-addr
stub-host
merge-zone name
merge-addr
do-not-query-address
private-domain
private-address
• nxdomain reloadable attributes:
nxdomain-redirect-destination
nxdomain-redirect-log
nxdomain-redirect-ttl
nxdomain-redirect-pass
nxdomain-redirect-modify
nxdomain-redirect-optout
nxdomain-redirect-dnssec-allow
Using the Reload Command
To reload cache.conf configuration changes without stopping and starting the server:
1. Edit the cache.conf configuration file, either directly or via an include file.
— For information about editing the file, see Editing the Configuration File on page 94.
— For information about using include files, see Using Include Files on page 124.
2. Log in as user assigned to the cachednsadmin role, if you are not already, and type
enable cachednsadmin and press ENTER.
3. To reload all dynamically changeable configuration changes, type cachedns reload and
press ENTER.
Note As the configuration change(s) become effective, the server will experience a brief time in which it
does not respond to queries.
4. If the change affects data that may be cached and you want to serve the new data, you
can flush the cache to remove any previously cached data. See Flushing the Cache on
page 193 for more information.
5. After you execute the cachedns reload command, use the show cachedns reload
status command to verify the results. For details, see Verifying the Reload Configuration
Results on page 187.
186
Note The server replaces the previous configuration value with the new value; the changes are not additive.
Example:
[cachednsadmin@Secure64]# cachedns reload
Successfully launched cachedns reload task
Run 'show cachedns reload status' from the command line to see the
result
Verifying the Reload Configuration Results

The cachedns reload command runs in the background so that you can perform other tasks
from the command line. To determine whether the reload configuration operation was successful,
use the show cachedns reload status command at any Secure64 DNS prompt:
• show cachedns reload status
If the cachedns reload command is still in process, the command displays the following
information:
• reload submitted: The last date/time a reload was requested
• runtime: The time to complete the reload, in seconds
• status: in progress
Example (reload in progress):

[cachednsadmin@Secure64DNS]# show cachedns reload status
reload submitted : Fri Dec 21 10:40:19 MST 2012
runtime : 10 seconds
status : in progress
After the cachedns reload completes, the command displays the following information:
• reload submitted: The last date/time a reload was requested
• runtime: The time to complete the reload, in seconds
• status: success|failed
• error code: Error code found during processing, for use by Secure64 support
• error message: Information and/or recommended actions corresponding to the error
If the command is successful, the Status line reads “success.” If an error occurs, the Status line
reads “failed.” Check the Error Message line for additional details to help you identify any issues.
Syslog messages also identify cachedns reload activity.
187
Example (successful reload, command line):

runtime : less than 1 second
status : success
error code : RELOAD_ERR_NONE
error message : No errors reported.
Example (successful reload, syslog messages):

[APPLICATION:CACHE_CONFIG_RELOAD] Entering state RELOAD_INIT
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to RELOAD_READ_CONFIG
[APPLICATION:RESOLVER] Reading configuration file.
[APPLICATION:RESOLVER] cache.conf:12: resolver config parser: 0
errors, 0 warnings
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to
RELOAD_VIEW_CFG_CHECK
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to RELOAD_SET_CFG_TYPE
RELOAD_VALIDATION_CFG_MODS
RELOAD_SWAP_IN_NEW_CFG
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to RELOAD_LOG_STATUS
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to RELOAD_COMPLETE
[APPLICATION:CACHE_CONFIG_RELOAD] Transition to RELOAD_DONE
Example (failed reload, command line)

runtime : less than 1 second
status : failed
error code : RELOAD_ERR_READ_CONFIG
error message : Error processing the configuration.
Check the configuration and try again.
Example (failed reload, syslog messages):

[APPLICATION:CACHE_CONFIG_RELOAD] Entering state RELOAD_INIT
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to
RELOAD_READ_CONFIG
[APPLICATION:RESOLVER] Reading configuration file.
[APPLICATION:RESOLVER] cache.conf:82: resolver config parser: 0
errors, 1 warnings
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to
RELOAD_VIEW_CFG_CHECK
188
[APPLICATION:CACHE_CONFIG_RELOAD]aborting reload: views configuration

has been modified
[APPLICATION:CACHE_CONFIG_RELOAD] Error detected:
RELOAD_ERR_VIEW_NAME_CMP
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to RELOAD_ERROR_EXIT
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to RELOAD_LOG_STATUS
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to RELOAD_COMPLETE
[APPLICATION:CACHE_CONFIG_RELOAD]transitioning to RELOAD_DONE
Testing the Name Server

Checking the Server Status and Using the Dig Command
To view the status of the name server:

• At the cachednsadmin prompt, type show cachedns status and press ENTER to verify
that the name server is running.
Example:
[cachednsadmin@Secure64DNS]# show cachedns status
The server is running
To use dig to query the name server:

1. At the sysadmin or cachednsadmin prompt, enter the following:
dig @<server> [<name>] [<type>] [<+queryopt>...] [<-flag>...]
where:
<server> is the IP address of the Secure64 DNS Cache server
<name> is the host or domain name to query
<type> is the resource record to query
<queryopt> is a query option, such as +dnssec to request DNSSEC validation,
+cdflag to request that DNSSEC validation is disabled (helpful to examine a validated
query that returns SERVFAIL)
<-flag> is an optional flag, such as -o to write the output to a file
Note For a full description of the dig command implementation in Secure64 DNS Cache, see Using the
Secure64 DNS Cache dig Command on page 369.
2. Verify the following:
189
— If the query is successful, the status on line 4 returns NOERROR. Other

possibilities, if the query is not successful, are SERVFAIL (server failure), NXDOMAIN
(name error), FORMERR (format error), and REFUSED (caching server refused to
perform the requested operation).
— If the +dnssec option was included, the AD (Authenticated Data) bit is returned
in the flags list and RRSIG resource records are returned in the Answer section if
DNSSEC validation was successful.
— If the +cdflag option was included, the AD (Authenticated Data) bit should not
be returned because validation is disabled.
Example:
[cachednsadmin@Secure64]# dig @192.168.127.175 secure64.com +dnssec
; <<>> DiG SourceT 3.x <<>> @192.168.127.175 secure64.com +dnssec
;; Got answer:
;;flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL:
1
;secure64.com. IN A
;; ANSWER SECTION:
secure64.com. 3600 IN A 72.167.37.13
secure64.com. 3600 IN RRSIG A RSASHA1 2
3600 20100208100007 20100201090007 53733 secure64.com.
oBkFdR78z+LV9O5QGwWNdktNLgmPPOENdLM+4K9OqObLKULp04155+M5ScDisdp4g4F
U+RhLOBYegSvvoQF0taScbpyXz3wzutMvPQ2aWJ0be2P5PLeDIa2Nq2GKnD6noLmwP5
sVCSA5LuGi8m0ZyRAFSDAj+RgOQWTh26ITM= )
[cachednsadmin@Secure64]# dig @192.168.127.175 secure64.com

; <<>> DiG SourceT 3.x <<>> @192.168.127.175 secure64.com
;; Got answer:
;secure64.com. IN A
;; ANSWER SECTION:
secure64.com. 3494 IN A 72.167.37.13
190
secure64.com. 3494 IN NS
ns1.secure64.com.
ns2.secure64.com.
ns1.secure64.com. 3494 IN A 64.92.220.221
ns2.secure64.com. 3494 IN A 216.17.193.194
[cachednsadmin@Secure64]# dig @192.168.127.175 secure64.com +cdflag

; <<>> DiG SourceT 3.x <<>> @192.168.127.175 secure64.com +cdflag
;; Got answer:
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL:
2
;secure64.com. IN A
;; ANSWER SECTION:
secure64.com. 3403 IN A 72.167.37.13
ns1.secure64.com.
ns2.secure64.com.
ns1.secure64.com. 3403 IN A 64.92.220.221
ns2.secure64.com. 3403 IN A 216.17.193.194
[cachednsadmin@Secure64]# dig @192.168.127.175 secure64.com NS

; <<>> DiG SourceT 3.x <<>> @192.168.127.175 secure64.com NS
;; Got answer:
;secure64.com. IN NS
;; ANSWER SECTION:
ns1.secure64.com.
191
ns2.secure64.com.
ns1.secure64.com. 3600 IN A 64.92.220.221
ns2.secure64.com. 3600 IN A 216.17.193.194
Troubleshooting Response, Validation, and Caching Errors
Note By default, when DNSSEC validation is enabled, SERVFAIL is sent as a response for all queries that
result in a bogus result (cannot be validated). For more information, see Understanding Validation
Behavior on page 128.
General troubleshooting steps include:

• Use the show syslog command to display recent syslog entries, or check the syslog
server
• Use the show config command to check your network and system configuration (see
Displaying Current System Configuration on page 316)
• Enable the sysadmin role and try the ping or ping6 commands to check the server’s
ability to reach other systems (see Using Ping and Ping6 on page 317)
• Check the attributes and values in the cache.conf DNS configuration file; you can use
the show cachedns config command or open the file in an editor (see Displaying
Caching Server Configuration on page 201)
• Use the dig utility from another system to query the Secure64 DNS Cache server (see
Checking the Server Status and Using the Dig Command on page 189)
• Use the show cachedns info command to display information and statistics for the
Secure64 DNS Cache server (see Server Activity Reporting and Statistics on page 215)
Troubleshooting Startup Errors

When you start Secure64 DNS Cache using the start cachedns command, any unsupported
attributes enabled in cache.conf are listed as warnings. See Appendix C: Unbound Configuration
Differences on page 479 for more information.
If start cachedns reports other warnings or errors, load the cache.conf file or zone data (as
indicated by the warning or error) in a text editor and check the line(s) reported.
Check each line for syntax errors. Common errors include:
• Omitting a space after a colon (:)
• Including more than one server: statement (only one is needed and allowed)
• Listing the server: clause and/or related attributes after the view-zone: clauses and
attributes
192
• Improperly constructing IP addresses or IP specifications

• Making typographical errors in attribute names or values
After you correct any errors, rerun start cachedns until it completes successfully. Then proceed
to Testing the Name Server on page 189 to test the Secure64 DNS Cache server.
Note If the system restarts abnormally, [SYSTEM:STARTUP] messages relating to safe boot mode are written
to syslog, and the server boots into safe mode. For more information, see Starting in Safe Mode on
page 262.
Caching Server Utility Commands

Flushing the Cache
You can use the flush commands to remove a specific domain from the Secure64 DNS Cache
server’s answer and referral caches. You can also flush specific record types for a name or flush
common records at or below the specified name.
If you have configured multiple caches for views, all of the caches are flushed. You can limit the
action to a specific cache by specifying an optional cache name. If you have configured multiple
caches and want to flush the global/standard cache, use default as the cache name. For more
information about configuring multiple caches, see Configuring Separate Caches on page 168.
To remove a specified name and its common records from the answer and referral caches:
cachednsadmin mode.
3. At the cachednsadmin prompt type:
cachedns flush name <name> [cachename|default] and press ENTER., where
<name> is the domain name to flush and [cachename|default] is the optional cache
name.
Examples:
[cachednsadmin@Secure64]# cachedns flush name org
Flushing common record types from all caches for <org>
[cachednsadmin@Secure64]# cachedns flush name org default

Flushing common record types from cache default for <org>
[cachednsadmin@Secure64]# cachedns flush name org north

Flushing common record types from cache north for <org>
193
4. For the specified name, the server removes the A, AAAA, NS, SOA, CNAME,
DNAME, MX, PTR, SRV, NAPTR, RRSIG, DNSKEY, DS, NSEC, NSEC3, and DLV
records from the answer and referral caches for the specified name.
To remove a specific record for a specific name from the answer and referral caches:
cachednsadmin mode.
cachedns flush type <name> <type> [cachename|default] and press ENTER,
where <name> is the domain name to flush the record from, <type> is A, AAAA,
NS, SOA, CNAME, DNAME, MX, PTR, SRV, NAPTR, RRSIG, DNSKEY, DS,
NSEC, NSEC3, or DLV, and [cachename|default] is the optional cache name.
Examples:
[cachednsadmin@Secure64]# cachedns flush type secure64.com NS
Flushing record type <NS> from all caches for <secure64.com>
[cachednsadmin@Secure64]# cachedns flush type secure64.com NS default

Flushing record type <NS> from cache default for <secure64.com>
[cachednsadmin@Secure64]# cachedns flush type secure64.com NS north

Flushing record type <NS> from cache north for <secure64.com>
4. The server removes the specified record from the answer and referral caches only for
the specified domain name.
Note If the record is part of a larger cached answer, it is not flushed from the answer cache. For example, if
the NS records are flushed for a specific name, they are removed from the referral cache. They are not
removed from the answer cache if the NS records are a subset of a cached answer's records.
To remove all records at or below a specified name from the answer and referral caches:
cachednsadmin mode.
cachedns flush zone <name> [cachename|default] and press ENTER, where
<name> is the domain name to flush and [cachename|default] is the optional cache
name.
194
Examples:
[cachednsadmin@Secure64]# cachedns flush zone org
Flushing all zone data from all caches at or below <org>
[cachednsadmin@Secure64]# cachedns flush zone org default

Flushing all zone data from cache default at or below <org>
[cachednsadmin@Secure64]# cachedns flush zone org north

Flushing all zone data from cache north at or below <org>
4. The server removes all records for the domain and all subdomains from the answer and
referral caches.
Note The cachedns flush zone command sets the records' TTL entries to "expired." Expired records
are included in show cachedns info entry counts until they are reclaimed, based on least
recently used activity.
To remove the cached validation status for a specific zone from the answer and referral
caches:
cachednsadmin mode.
cachedns flush validation <zone> [cachename|default] and press ENTER, where
<zone> is the zone to flush and [cachename|default] is the optional cache name.
Examples:
[cachednsadmin@Secure64]# cachedns flush validation s64
Flushing all validation data from all caches at or below <s64>
[cachednsadmin@Secure64]# cachedns flush validation s64 default

Flushing all validation data from cache default at or below <s64>
[cachednsadmin@Secure64]# cachedns flush validation s64 north

Flushing all validation data from cache north at or below <s64>
4. The server removes the cached validation status for the specified zone. This forces
validation to occur the next time the zone is queried (assuming validation is enabled for
the zone).
195
Displaying Cache Information for a Domain Name

The cachedns lookup command displays cache information for a specified domain name,
record type, and optional view. You can use the command to check the cached answer or the
resolver information for the domain and record. It can help identify the answer source or the
resolver progression, which are useful for diagnostics and troubleshooting resolver issues.
The command syntax is:
cachedns lookup <name> [answer|referral] [record_type] [view]
where:
<name> is the domain name to look up (required)
[answer|referral] is the type of look up to perform (if not defined, the default is
referral):
— answer - look up and display the response in the answer cache
— referral - look up and display the information used to resolve the domain name,
including local zones, local data, forward zones, stub zones, merge zones, and the
contents of the referral cache
[record_type] is an optional DNS record type to look for; if not defined, the default
is A
[view] is an optional view name
Displaying Answer Cache Information
To display the answer cache information for a domain name:

1. At the cachednsadmin prompt, type:
cachedns lookup <name> answer [record_type] [view] and press ENTER,
where <name> is the domain name, [record_type] is the DNS record, and [view] is
the optional name of a view.
2. If a [view] is not defined, the cached answer information for the specified name and
record for all views and caches (if configured) display. If the server is using a multi-
instance resolver implementation, the corresponding instance numbers for the caches
are included.
3. If a [view] is defined, only the cached answer information for that view displays. If the
server is using a multi-instance resolver implementation, the corresponding instance
number also displays.
Note Any configuration attributes that are not defined in a separate view use the “default” view, and any
views that do not define a separate cache use the “default” cache. See Defining Views on page 163 for
more information.
196
Example (multiple resolver instances):

[cachednsadmin@S4DNS]# cachedns lookup www.secure64.com answer
View: default
Cache: default
Instance: 1
The following information was found in the answer cache for

www.secure64.com. IN A:
The validation status for this record is: secure
ANSWER SECTION:
www.secure64.com. 3565 IN A 66.94.38.200

www.secure64.com. 3565 IN RRSIG A 7 3 3600 20130419090025
20130412080025 52469 secure64.com.
ZLMqwAmRaYjeTjOoHWMtnBb5wTXX1nVTX6B0oEpLQohitjyQM3BMsktG731IZehS7xq/
URybQEMHhq4yOMoO4cTDJbVBJ0jEVkmR1JZQQtUYXuOawrBFzZBVQoH2QNAwqbdU3fvQ9
vsp59aqQ+NhpXZasohDgVlRwpAYX16pKUU= ;{id = 52469}
AUTHORITY SECTION:
secure64.com. 3565 IN NS ns1.secure64.com.

secure64.com. 3565 IN RRSIG NS 7 2 3600 20130419090025
20130412080025 52469 secure64.com. BwZAdrUfrEm95/
Tf1KsJWUqgMiR4yAEiKYr7QuGv5LHn5+ZccEWZAkj6QEPi0ESUMBNhd5mv1GMZ7xNOYsQ
OFX92I2BbhVmZgVIXCsTOvCeofsQhwPC8e+2g01bm4FTsAEuown+Hp9z4um6NA4qifn4Z
cHyRNvj7OZGd8Wr6Hwc= ;{id = 52469}
ADDITIONAL SECTION:
ns1.secure64.com. 3565 IN A 64.92.220.221

ns1.secure64.com. 3565 IN RRSIG A 7 3 3600 20130419090025
20130412080025 52469 secure64.com.
C3qzNYWrudt3m4+APZiVOEBSOVnZKFI8hoAZycxryk50CjPxfysFgQwiZIzeN4BnZUV+T
YmYSGT9LyA8txQJq6wWFUwPTXQE6doI3h9z9vfpAG785mrB1Nx60YrI9uODre8stCnQPq
xVx6GHvXcBonv3N0nh2vfZO9/ts6EOuaA= ;{id = 52469}
ns2.secure64.com. 3565 IN A 216.17.193.194
ns2.secure64.com. 3565 IN RRSIG A 7 3 3600 20130419090025
20130412080025 52469 secure64.com. EP6e52UHhV6IqxbNvl5c8/Ex6zTR//
WdUjOHDgU2UcD3qm6X3vRbBG/nWy/Fqtkjo6oLhCVcBzTtNkEw4/
r3twOV6FkAJArPYUvvqAkYiwIvsFGS+zfCWb2Z10vL4jj8b6ZDbo4mfLHmbn0tHg5ZO7V
jJ6Hq4LJ2TrjAn5jo3gQ= ;{id = 52469}
ns2.secure64.com. 3565 IN AAAA 2607:fa88:1002::fff0
197
ns2.secure64.com. 3565 IN RRSIG AAAA 7 3 3600

20130419090025 20130412080025 52469 secure64.com. REVMbJiccZPr8x/
Bz5tRjwDpd9YufKKnFAIeXaNtvC0UeQfhJglPP2vordloYOAjUCd/
8gLKlOL2xtQaqX90SFETsGO+Ta9TmPkH3Pgv89LLjWFDiLX9LCr02IxK4fJ0loz/
usnUrbAPUkLwMiCwwHQL6kJvT8I8chfkuwoQVXY= ;{id = 52469}
View: default
Cache: default
Instance: 2
No information was found in the answer cache for

www.secure64.com. IN A
View: default
Cache: default
Instance: 3

View: test65
Cache: t65
Instance: 1

View: test65
Cache: t65
Instance: 2

View: test65
Cache: t65
Instance: 3

198
Displaying Referral Cache Information
To display the resolver information for a cached domain name:

cachedns lookup <name> referral [record_type] [view] and press ENTER,
where <name> is the domain name, [record_type] is the DNS record, and [view] is the
optional name of the view.
2. If a [view] is not defined, the information and name server(s) used to resolve the
specified name and record for all views and caches (if configured) display. If the server is
using a multi-instance resolver implementation, the corresponding instance numbers for
the caches are included.
3. If a [view] is defined, only the lookup information for that view displays. If the server is
using a multi-instance resolver implementation, the corresponding instance number also
displays.
Note Any configuration attributes that are not defined in a separate view use the “default” view, and any views
that do not define a separate cache use the “default” cache. See Defining Views on page 163 for more
information.

[cachednsadmin@S64]# cachedns lookup www.secure64.com referral
View: default
Cache: default
Instance: 1
The following name servers are used for lookup of

www.secure64.com.:

ns2.secure64.com. 172703 IN A 216.17.193.194
ns1.secure64.com. 172703 IN A 64.92.220.221
Delegation with 2 names. Providing 2 IP addresses.
199
64.92.220.221 @53 rtt 15 msec.

216.17.193.194 @53 rtt 17 msec.
ns2.secure64.com.
ns1.secure64.com.
View: default
Cache: default
Instance: 2

www.secure64.com.:
no delegation from cache; goes to configured roots
View: default
Cache: default
Instance: 3

www.secure64.com.:
View: test65
Cache: t65
Instance: 1

www.secure64.com.:
View: test65
Cache: t65
Instance: 2

www.secure64.com.:
View: test65
Cache: t65
Instance: 3
200

www.secure64.com.:
Displaying Caching Server Configuration
To display caching server configuration information:

From any prompt, type the following and press ENTER:
show cachedns config
The command displays the caching configuration settings from running memory (what the server
is actively using).
To make the output more readable, you can select one of the following modifiers to display a
subset of the active configuration, as follows:
— show cachedns config basic - Displays system settings
— show cachedns config sizes - Displays cache size settings
Note The cache sizes displayed differ from the numbers configured in cache.conf. The system
automatically adjusts the sizes for memory allocation overhead, which prevents extending over the
maximum memory allowed.
— show cachedns config local - Displays local zone configuration

— show cachedns config security - Displays security settings
— show cachedns config validation - Displays validation specific settings
— show cachedns config zone - Displays forward zone, stub zone, merge zone, do-
not-query, and private address settings
Note The IP addresses in the cache.conf file and the format displayed by the show cachedns
config zone command output can differ. For example, if you define a set of IP addresses and then
a sub-set of the same set, only the overriding set displays. In addition, if a netblock is not specified, the
command displays the IP address with the appropriate netblock notation.
— show cachedns config nxdomain - Displays nxdomain redirection settings

— show cachedns config views - Displays a list of configured views
— show cachedns config views [viewname] - Displays the specified configured
view
201
Example:
[cachednsadmin@Secure64]# show cachedns config basic
start the server automatically on system boot = <no>
start the bfd service automatically on system boot = <no>
start the bgp service automatically on system boot = <no>
dump the answer and referral caches automatically on server stop =
<no>
load the answer and referral caches automatically on server start =
<no>
return minimal responses = <no>
statistics interval = <0>
cumulative statistics = <0>
prefetch almost expired cache entries = <no>
port = <53>
do ip4 = <yes>
do ip6 = <yes>
do tcp = <yes>
incoming tcp connections = <10>
EDNS buffer size = <4096>
Filter AAAA responses on IPv4 = <no>
dns64-prefix list:
There are no dns64 prefixes defined.
number of simultaneous recursive clients = <768>
initial timeout value for outbound UDP requests = <400>
increment value for timedout UDP queries = <400>
maximum processing time for incoming DNS queries = <30>
number of incoming interfaces = <8>
incoming interface 0 = <192.168.127.81>
incoming interface 4 = <fd64:0:0:127::81>
incoming interface 5 = <fd64:0:0:95::81>
incoming interface 6 = <2001:470:1f04:ad8:1::51>
incoming interface 7 = <2002::1>
number of outgoing interfaces = <8>
outgoing interface 0 = <192.168.127.81>
outgoing interface 4 = <fd64:0:0:127::81>
outgoing interface 5 = <fd64:0:0:95::81>
outgoing interface 6 = <2001:470:1f04:ad8:1::51>
202
outgoing interface 7 = <2002::1>

logging-file-num = <10>
logging-file-size = <1073741824>
logging-file-write-immediate = <no>
logging-flag-query-recv = <no>
logging-flag-query-resp = <no>
logging-flag-resolv-query = <no>
logging-flag-resolv-resp = <no>
identity = <<NULL>>
version = <<NULL>>
Configured root hints:
198.41.0.4
192.228.79.201
192.33.4.12
199.7.91.13
192.203.230.10
192.5.5.241
192.112.36.4
128.63.2.53
192.36.148.17
192.58.128.30
193.0.14.129
199.7.83.42
202.12.27.33
2001:503:BA3E::2:30
2001:500:2f::f
2001:500:1::803f:235
2001:503:C27::2:30
2001:dc3::35
Note The show cachedns config command lists the active root hints entries. If the DNS server has only IPv4
outgoing interfaces specified, then only the IPv4 address in the root hints entries display. If both IPv4 and
IPv6 outgoing interfaces are specified, then both IPv4 and IPv6 root hints entries display. If you define a
custom root hints file, ensure that it includes IP address type(s) that correspond to3.13.1 your defined
outgoing interfaces. If it does not, the server uses the default root hints.
203
Saving and Loading the Cache

The Secure64 DNS Cache server provides several methods for saving and loading cache
entries, pre-loading cache entries, and pre-fetching expiring entries. The following sections
discuss how to configure these features.
Preserving the Cache on Stop and Start

You can configure the Secure64 DNS Cache server to save the contents of the answer and
referral caches to a file when the server stops. You can also configure the server to load the
contents from the saved file when the server starts up. This preserves the cache so that the
information is not lost when you stop and start the server. In addition, the cache dump file is
useful for viewing cache contents.
Note the following behaviors of the cache dump feature:
• If you load a cache dump file on a Secure64 DNS Cache server, do not edit it. To
prevent tampering, the file contains a checksum which becomes invalid if you modify
the file.
• If DNSSEC validation is enabled, the RRSIG records are preserved and loaded on
start. The validation flag is cleared so that validation can occur if a query is received for
validated information.
• The TTL of records in the cache are preserved in the cache dump files. The value is the
absolute TTL (the UTC time when the record will expire). Upon a cache file load at
start, the server omits loading of any records with expired TTLs.
• Using the cache dump file to warm the cache on another server is not recommended.
• If there is not data in the cache, a cache dump file is not created.
Cache Dump Files and Multi-Instance Resolver

Each resolver instance uses independent, separate caches that contain information related only
to the queries the specific instance receives and processes. As a result, Secure64 DNS Cache
creates separate cache dump files for each instance. If the server is running a single resolver
instance, the server maintains one cache dump file.
The file name format is cache_dump_<instance> where <instance> is the instance
number. The file(s) are saved in the top-level directory of the cachednsadmin role.
Example (single resolver instance):

cache_dump_1

cache_dump_1
cache_dump_2
cache_dump_3
204
Cache Dump Files and Separate Named Caches for Views

By default, a view defined in the Secure64 DNS Cache cache.conf configuration file uses the
server’s default shared cache. You can also configure a view to use a separate cache that you
define using the cache-name: attribute (see Configuring Separate Caches on page 168).
If separate caches are configured, Secure64 DNS Cache creates separate cache dump files based
on the view and instance, using the format cache_dump_<named-cache>_<instance> where
<instance> is the instance number and <named-cache> is the alternate cache name. The files
are saved in the top-level directory of the cachednsadmin role.
Example (single resolver instance, named caches ‘centralcache’ and ‘northcache’):

cache_dump_1
cache_dump_centralcache_1
cache_dump_northcache_1
Example (multiple resolver instances, named caches ‘centralcache’ and ‘northcache’):

cache_dump_1
cache_dump_2
cache_dump_3
cache_dump_northcache_cache_dump_3
Configuring Cache Save and Load

Table 33 describes the cache.conf configuration file attributes for saving and loading the cache.
Table 33. Cache saving and loading configuration attributes
Attribute: Value
dump-cache-on-stop: <yes|no> Define whether to save the answer and referral cache to
dump-cache-on-stop: no a file when the server is stopped. If yes, the information is
saved to files in the top-level directory of the
cachednsadmin role.
load-cache-on-start: <yes|no> Define whether to load saved cache file(s) into the cache
load-cache-on-start: no when the server starts. The file(s) must be located in the
top-level directory of the cachednsadmin role. To prevent
loading a tampered file, the files contain a checksum and
the server will not load a file if it has been modified.
205
Note If the message or referral caches do not contain information, the saved cache file(s) are not created.
For example, if you start and then stop the server before it receives and caches queries, the file is not
created.
If load-cache-on-start: is yes, an error message is generated during the next server start
if the saved cache file(s) are not present; however, the server continues to start.
Preloading the Cache for Specific Zones

The Secure64 DNS Cache server configuration allows you to define one or more zones that
you want the server to preload responses (warm) the cache. If configured, the server generates
queries for the specified zones at startup. This is useful for commonly requested zones. Only
class IN and A, AAAA, and PTR record types are supported.
To define preloading of responses in the cache, use the following attribute in the server:
preload-zone: <zone> <A|AAAA|PTR>
Examples:
preload-zone: yahoo.com A
preload-zone: yahoo.com AAAA
preload-zone: google.com A
preload-zone: google.com AAAA
preload-zone: amazon.com A
preload-zone: amazon.com AAAA
Prefetching Expiring Entries

The Secure64 DNS Cache server configuration allows you to define whether to refresh
message cache entries retrieved via a cache hit that are within 10% of their TTL expiration. If
yes, the server generates cache refreshing queries for the expiring message cache entries. If not
defined, the default is no.
To define prefetching of expiring entries, use the following attribute in the server: clause of
the cache.conf configuration file:
prefetch: <yes|no>
Example:
prefetch: yes
206
DNS Query Monitoring

The Secure64 DNS Cache server offers two methods for monitoring DNS queries:
• Real time query monitoring using command-line options
• DNS query logging to a file for offline analysis
For a quick capture of top queriers by IP address or domain, use the real time query monitoring
commands as described in the following section. If you want a more robust set of data for
analysis, refer to DNS Query Logging on page 211.
Real Time Query Monitoring (RTQM)

The real time query monitoring (RTQM) feature provides a quick, command-line method for
monitoring incoming DNS queries. It allows you to monitor the clients that are sending the most
queries and the domains that are being queried for most frequently.
About RTQM
RTQM is a feature that you enable as needed to monitor incoming DNS queries. By default,
RTQM is not started or running on the Secure64 DNS Cache server, and users assigned to the
cachednsadmin role have the ability to start and stop RTQM
After RTQM is started, it begins collecting query information and stores the information in
memory. This allows you to quickly obtain data about the queries via the command line.
The amount of query information retained by RTQM is based on the amount of memory
allocated when it is started. By default, the system allocates 128 MB of memory, and you can
specify more or less memory when you start RTQM. Note that each megabyte of memory
captures information for about 10,000 queries.
If RTQM reaches the limits of the allocated memory as it collects query information, it discards
information about the oldest queries as needed to allow for incoming queries. This ensures that
the monitoring data pertains to the most recent queries and that the allocated memory is not
exceeded.
Starting and Stopping RTQM Information
To start RTQM and initiate DNS query data collection:

2. At the view prompt, type enable cachednsadmin and press ENTER to enable the
cachednsadmin mode.
3. Type start rtqm [max memory] and press ENTER, where max memory is the maximum
amount of memory for the service in megabytes, with a minimum of 1 MB. If not
defined, the default maximum memory is 128 MB.
207
Note If the system cannot allocate the requested amount of memory when you attempt to start RTQM, the
message “Error starting realtime query-monitoring: out of memory”
displays at the command line and the following syslog message is generated:
[APPLICATION:RTQM] ERROR: out of memory
To stop RTQM:
2. At the view prompt, type enable cachednsadmin and press ENTER to enable the
cachednsadmin mode.
3. Type stop rtqm and press ENTER.
Viewing RTQM Reporting Information
To display RTQM data:

1. If RTQM has not already been started, see Starting and Stopping RTQM Information on
page 207.
2. From view mode or any Secure64 DNS Cache role, type the following and press
ENTER:
show rtqm <N>/[T] <clients|domains>
where:
N is the maximum number of queriers to report, from 1 to 1000 (if there are more
queriers than the defined limit, the top N are reported)
T is the number of minutes of capture history to report on (minimum value of 1),
starting from the end of the capture (if T is not specified, history is reported for the
last 1 minute of data)
clients or domains indicates whether to report the top queries by requesting client
IP address (clients) or the domain queried for (domains)
Note The command line is unavailable until reporting is complete.
208
Explanatory Examples:
• show rtqm 100 clients - displays the top 100 clients over the past 1 minute
• show rtqm 100/5 clients - displays the top 100 clients over the last 5 minutes
• show rtqm 5/60 domains - displays the top 5 queried-for domains over the last hour
Command Line Examples:

[view@Secure64DNS]> show rtqm 100 clients
Top 100 clients from Tue Mar 13 22:36:20 to 22:37:20 (1787590 queries,
5960 qps)
(1)208.28.3.210 1584163 (88.62%)
(2)173.194.33.17 10379 (0.58%)
.
.
.
(100)128.138.240.1 1 (0.01%)
Note For illustration purposes, clients 3-99 are not displayed in the example above
[cachednsadmin@Secure64DNS]# show rtqm 10 domains

Top 10 domains from Mon Mar 19 15:32:44 to 15:33:01 (129985 queries,
7646 qps)
(1) 149.74.60.202.in-addr.arpa 4531 (3.48%)
(2) _nfsv4idmapdomain 3556 (2.73%)
(3) 66.124.92.222.in-addr.arpa 2540 (1.95%)
(4) umbra.ops 1644 (1.26%)
(5) _sip._udp.asterisk.isc.org 1118 (0.86%)
(6) localhost 761 (0.58%)
(7) 41.188.152.204.in-addr.arpa 586 (0.45%)
(8) rous.redbarn.org 586 (0.45%)
(9) www.google.com 570 (0.43%)
(10) 1.0.0.10.in-addr.arpa 557 (0.42%)
[view@Secure64DNS]> show rtqm 10/9000 domains

Top 10 domains from Mon Mar 19 15:32:43 to 21:41:29 (310583 queries,
14 qps)
(1) _nfsv4idmapdomain 8289 (2.66%)
(2) 177.204.136.89.in-addr.arpa 5826 (1.87%)
(3) 149.74.60.202.in-addr.arpa 4531 (1.45%)
(4) umbra.ops 3847 (1.23%)
(5) 87.117.129.61.in-addr.arpa 2714 (0.87%)
(6) _sip._udp.asterisk.isc.org 2619 (0.84%)
209
(7) 66.124.92.222.in-addr.arpa 2541 (0.81%)

(8) 173.0.130.220.in-addr.arpa 1916 (0.61%)
(9) localhost 1649 (0.53%)
(10) 12.80.113.202.in-addr.arpa 1490 (0.47%)
Reported Data
The real time query monitoring command show rtqm <N>/[T] <clients|domains>
displays the following information:
• Heading line:
— Number of clients or domains reported
— If T was not specified, the time of the oldest recorded query
If T was specified, the newer of the time T minutes in the past or the first recorded
query
— Ending time period of the reported data
— Total number of queries captured
— Average number of queries per second over the reported data
• Client/domain information lines (one line per client/domain):
— Rank
— IP address of client or domain name queried for
— Number of queries from the client or for the domain
— Percentage of the total number of queries from the client or for the domain
210
DNS Query Logging

The Secure64 DNS Cache server can log information about packets it receives and sends.
Logging options include:
• Queries received from clients
• Query responses returned to clients
• Queries sent to authoritative DNS servers
• Query responses returned from authoritative DNS servers
By default, the log files are created in a pcap-readable format. Using commonly available tools,
such as tcpdump, Wireshark, tcpreplay, CA NetMaster, or Microsoft Network Monitor, you can
read and extract information from the pcap files for debugging or other purposes, such as
determining DNS query usage patterns.
Note A Secure64 proprietary format for log files (set by the logging-file-pcap: no attribute in
cache.conf) was in affect prior to the pcap implementation.The standard pcap format is now
recommended, as support for the proprietary format may be phased out in future releases. The multi-
instance behavior and directory/file structure operate in the same manner for both file formats.
Query Logging and Multi-Instance Resolver Behavior

Each resolver instance uses independent, separate caches that contain information related only to
the queries the specific instance receives and processes. As a result, the resolver behavior and
information cached for the same query handled by one instance can differ from another instance,
depending on the timing of the query and the available DNS information. This is the same
behavior exhibited by separate caching servers.
Because the resolver behavior and DNS information can differ for each instance, Secure64 DNS
Cache creates separate query log directories and file sets for each instance. This maintains the
query/response sequences for each resolver instance to facilitate analysis and diagnostics. If the
server is running a single resolver instance, the server maintains one directory and with one set of
log files.
Note TCP queries are not distributed across processors. All TCP queries are handled by resolver instance 1.
As a result, all TCP logging is done to query log file 1.
211
Log File Location, File Name, Size, and Number

Query log files are stored in directories below the cachednsadmin root directory. The
directories and files allow for both a single resolver and a multi-instance structure:
• Log files are written to the query_logging_<instance> directory of the
cachednsadmin role, where <instance> is the resolver instance number, starting with
instance 1. If the server is not using multi-instance resolvers, the instance number
defaults to 1.
• Log file naming convention is logfile<instance>_<hex>.pcap, where <instance>
is the resolver instance number and <hex> is a hexadecimal number. If the server is
using a single resolver, the instance number defaults to 1.
Example:
/query_logging_1
logfile1_00000000.pcap
/query_logging_2
• Use configuration options (described in Table 34 on page 213) to control the amount
of hard disk space consumed by the query log files:
— The configured log file size (logging-file-size:) applies to each individual log
file.
— The configured number of log files per directory (logging-file-num:) applies to
each individual query logging directory.
— The server log file automatically rolls to the next file when the logging file size is
reached. Because the log data can differ on a per-instance basis, the log files for
each instance may roll at different times in a multi-instance resolver environment.
• To help you identify the amount of hard disk space allocated for different types of log
files, the start cachedns command displays the total disk space allocated for
NXDOMAIN redirection logging, local zone logging, and query logging. The server
makes use of the allocation(s) for only the specific logging features you have enabled.
Example:
[cachednsadmin@Secure64DNS]# start cachedns
Starting cachedns
cache.conf:18: config parser: 0 errors, 0 warnings
212

Validation deactivated, no usable trust anchors found.
Started cachedns
Configuring Query Logging

The query logging facility provides configuration attributes to manage the log files and data. The
attributes are included in the server: clause of the cache.conf configuration file. (For details
about the configuration file, see The Cache Configuration File on page 93.)
Use the following attributes in the server: clause of the cache.conf configuration file to
configure the query logging utility in Secure64 DNS Cache:
Table 34. Query logging configuration attributes
Attribute: Value
logging-file-pcap: <yes|no> Specify whether to save log data in standard pcap format
logging-file-pcap: yes (yes) or the Secure64 proprietary format (no). The pcap
format is recommended, as support for the proprietary
format may be phased out in future releases.
logging-file-num: <number> Specify the maximum number of logging files that should
logging-file-num: 10 exist at any one time within each query logging directory;
acceptable values are 1-128.
If undefined and a logging flag is set to yes, the default is
10 files per directory.
logging-file-size: <bytes> Specify the maximum size of each log file, in bytes.
logging-file-size: 1000000000 If undefined and a logging flag is set to yes, the default is
(1024*1024*1024 or 1,073,741,824 bytes)
logging-flag-query-recv: <yes|no> Specify whether to log queries received from clients.
logging-flag-query-recv: no If undefined, the default is no.
logging-flag-query-resp: <yes|no> Specify whether to log responses sent to clients.
logging-flag-query-resp: no If undefined, the default is no.
logging-flag-resolv-query: <yes|no> Specify whether to log resolver queries to authoritative
logging-flag-resolv-query: no servers.
If undefined, the default is no.
logging-flag-resolv-resp: <yes|no> Specify whether to log responses from authoritative
logging-flag-resolv-resp: no servers.
logging-file-write-immediate: <yes|no> Specify whether to write query log entries immediately
logging-file-write-immediate: no instead of buffering them. Setting the attribute to yes can
reduce performance.
213
To configure the logging utility in Secure64 DNS Cache:

• Enable one or more logging flag attributes in the server: clause of cache.conf, as
described in Table 34 on page 213.
• Configure the logging-file-size: and logging-file-num: attributes in the
server: clause of cache.conf.
• Either stop and start the server (issue the stop cachedns and start cachedns
commands) or use the cachedns reload command. The cachedns reload command
loads the configuration changes without stopping the server.
Note A new log file is started each time the server is started even if all logging flags are set to ‘no.’ This
allows for changing the logging flags during a cachedns reload operation. Initially, the file contains
only header information.
logging-file-pcap:, logging-file-num:, and logging-file-size:

changes do not take affect during a reload, but logging flag changes do. This allows you to configure
the server to start or stop logging data as a result of a reload.
To copy the files to another system, use the scp command as follows:
scp [-P <port>] <user>@<host>:/cachednsadmin/query_logging_<instance>/<logfiles>
<destination>
where:
<user> is the Secure64 DNS Cache user account with cachednsadmin privileges
<instance> is the resolver instance number
<logfiles> are the files to copy
<destination> is the location to copy the file(s) to
Note If you attempt to copy a log file that is active, errors may occur when attempting to open the file in a
pcap-compatible application. To ensure log files are closed, stop the server prior to executing the scp
command or temporarily set the logging-file-write-immediate: yes attribute,
issue the cachedns reload command, then reverse the process after you have copied the file.
To view or extract information in the pcap format log files:

• Use commonly available pcap tools, such as tcpdump, Wireshark, tcpreplay, CA
NetMaster, or Microsoft Network Monitor.
214
Server Activity Reporting and Statistics

Secure64 DNS Cache offers several methods for displaying or obtaining statistical data about the
server’s activity:
• Execute the show cachedns info command from any system prompt (see Displaying
Statistics at the Command Line below).
• Configure the Secure64 DNS Cache software to act as an SNMP (Simple Network
Management Protocol) host agent for reporting information about the server (see
Implementing SNMP on page 391). The S64-CACHE-MIB reports a subset of the
information reported by the show cachedns info command. If you have configured
views, the MIB reports view-specific information. It does not break down information on
a per instance basis.
• Use the query monitoring and logging features (see DNS Query Monitoring on page 207)
Displaying Statistics at the Command Line

If the Secure64 DNS Cache server is running, you can display statistics information from the
command line. The information is useful for monitoring server activity and performance.
Operational behaviors of the command include:
• Statistics are reset when you stop and start the server; they are cumulative since the last
time the server was started.
• The cache entries as shown in the statistics do not decrement based on the configured
cache TTL values.
• You can add a views option to the command to display view-specific information.
• You can add an instance option to the command to display information for a specific
resolver instance.
• Not all data applies to all forms of the command. The data that displays is based on the
command options you specify.
Note For detailed descriptions of the items displayed by the show cachedns info command, refer to Table 35
on page 219.
215
Displaying Summary Information
The default version of the show cachedns info command allows you to obtain a summary of
statistics for the server overall since the last time the server was started.
• If you have not configured views and the server is using a single resolver instance, the
summary version is the only version that applies to your operations.
• If you have configured views or are using multiple resolver instances, the summary
version of the command includes all views and instances. You can use other versions of
the command (described in the following sections) to break down information by view,
instance, or both.
To display a summary of all statistics, at any Secure64 DNS Cache prompt:

• Type show cachedns info and press ENTER.
Example:
[cachednsadmin@Secure64DNS]# show cachedns info
====== requested operation =====
Reporting statistics for : all instances
Statistics collected on : Mon Nov 11 10:52:05 MST 2013
Statistics collection start time: Mon Nov 11 10:48:41 MST 2013
====== cachedns server stats =====

validating lookups received : 0
non-validating lookups received : 20
cache hits : 0
cache misses : 20
recursive clients per interface : 768
queries in progress : 0
average queries per second : 0
resolver lookups : 25
== cache miss histogram ==

validation: enabled
< 64 ms : 20
64 - 127 ms : 0
128 - 255 ms : 0
256 - 511 ms : 0
512 - 1023 ms : 0
1024 - 2047 ms : 0
2048 - 4095 ms : 0
> 4095 ms : 0
216
== defensive stats ==
scrubbed rrsets : 1
acl denied requests : 0
acl refused requests : 0
dns 0x20 mismatches : 0
transaction id mismatches : 0
dropped type ANY queries : 0
dropped type MX queries : 0
== extended server stats ==

rate limited tcp sessions : 0
resolver retransmissions : 0
cache prefetch queries : 0
cache preload queries : 0
local zone answers : 0
dns64 answers : 0
filtered aaaa on v4 answers: 0
NXDOMAIN answers : 18
SERVFAIL answers : 1
NXDOMAIN redirects : 0
resolver loops detected : 0
lame delegations : 0
failed validation attempts : 0
====== cachedns application stats =====

== cachedns uptime ==
days : 0
hours : 0
minutes : 3
seconds : 24
== number of cache entries ==

referral cache : 4
answer cache : 24
key cache : 1
infrastructure cache : 1
total : 30
== memory usage breakdown ==

referral cache : 9216 kb
answer cache : 17408 kb
key cache : 512 kb
217
infrastructure cache : 512 kb

negative cache : 512 kb
udp context memory : 1149 kb
general purpose memory : 5240 kb
218
Information Displayed
The data that displays for the show cachedns info command is described in Table 35. Because
not all data applies to all forms of the command, the data that displays is based on the command
options you specify.
As noted in the Context column:
• All - data displays for all forms of the command
• Summary - data displays for show cachedns info
• View - data displays for show cachedns info view <viewname>
• Instance - data displays for show cachedns info <instance>
• View/Instance - data displays for show cachedns info view <viewname>
<instance>
Table 35. Caching server statistical data
Data Context Description

cachedns server stats
Number of lookups (queries) received that request DNSSEC validation (DO
validating lookups
All bit is set). The total of the non-validating and validating lookups received is
received
the number of lookups received.
Number of lookups (queries) received that do not request DNSSEC
non-validating
All validation (DO bit is not set). The total of the non-validating and validating
lookups received
lookups are the number of lookups received.
Number of cache hits. This is the number of answers retrieved from the
cache hits All
cache.
Number of cache misses. Cache misses are client requests that result in
cache misses All recursive resolver lookups. The rate of increase in this number should
decrease over time after the cache is primed.
Number of recursive clients per listening interface (applies to UDP client
requests). This is the maximum number of queries that can be answered at
recursive clients per
All one time for each interface. For more information, see the num-
interface
recursive-clients configuration attribute as discussed in
Configuring Basic Server Attributes on page 82.
queries in progress Summary Number of queries in progress when the command was executed.
Summary
average queries per
View The average number of queries received per second.
second
View/Instance
Number of lookups conducted by the resolver during the name resolution
resolver lookups All
process.
lookup time averages
Exponential weighted moving average time for non-validated lookups that
avg cached lookup View
were in the cache, in microseconds. If performance slows, check system
time View/Instance
memory and CPU utilization.
Exponential weighted moving average time for lookups that were not in the
cache, in microseconds. If performance slows, check network traffic,
View
avg lookup time system memory, and CPU utilization. Also use review the cache miss
View/Instance
histogram (see next data item) for anomalies. Enabling DNSSEC can also
cause increase the average lookup time for non-cached answers.
219
cache miss histogram

Summary
cache miss A breakdown of the time required to resolve non-cached queries, in
View
histogram milliseconds.
View/Instance
defensive stats
Number of scrubbed RRsets. An RRset is scrubbed (removed) from an
scrubbed rrsets All answer if it is not pertinent to the query. An increase in scrubbed RRsets
can indicate a cache poisoning attempt.
Number of ACL (access control list) denied client requests. The list is
defined by the access-control: attribute in cache.conf. An
acl denied requests All
increase in refused or denied client requests can indicate unwanted server
traffic, an attack, or ACL misconfiguration.
Number of ACL refused client requests. The list is defined by the
access-control: attribute in cache.conf. An increase in refused
acl refused requests All
or denied client requests can indicate unwanted server traffic, an attack, or
ACL misconfiguration.
Number of DNS 0x20 mismatches. If the use-caps-for-id: attribute
is configured in cache.conf for 0x20 forgery resistance, the number of
dns 0x20 mismatches is recorded in this statistic. An increase in the number of
All mismatches can indicate a cache poisoning attack or a name lookup
mismatches
request to a server that does not preserve the casing in the query name.
See Using DNS-0x20 for Forgery Resistance on page 120 for more
information.
transaction id Number of DNS responses received with mismatched transaction IDs,
All
mismatches which can indicate a cache poisoning attempt.
dropped type ANY Number of dropped ANY queries, related to the drop-any: yes
All
queries configuration attribute in cache.conf.
dropped type MX Number of dropped MX queries, related to the drop-mx: yes
All
queries configuration attribute in cache.conf.
extended server stats
Number of rate-limited TCP sessions. The number of dropped concurrent
TCP requests is directly related to the caching configuration of the allowed
number of incoming TCP buffers defined by the incoming-num-tcp:.
rate limited tcp attribute in cache.conf.
All
sessions
If the number rises over time, you may need to increase the incoming-
num-tcp: number to accommodate a higher rate of TCP resolver
lookups. A large increase may indicate an attack.
Number of resolver retransmissions or timeouts. Secure64 DNS Cache
resolver attempts to contact authoritative servers 3 times. A large number of
All
retransmissions resolver lookup retries can indicate a network related problem and slower
resolution times.
Number of expiring message cache entries that have been refreshed. For
cache prefetch
All more information, see the prefetch: configuration attribute in
queries
Number of queries that are related to preloading responses in the cache.
cache preload
All For more information, see Preloading the Cache for Specific Zones on
queries
page 206.
local zone answers All Number of local zone and local data resolutions.
Number of queries resolved via DNS64 processing. For more information
dsn64 answers All
about DNS64 configuration, see DNS64 on page 148.
220
filtered aaaa on v4 Number of AAAA answers filtered from IPv4 queries. For more information
All
answers about filtering AAAA responses, see IPv4 Filtering on page 152.
Number of NXDOMAIN (non-existent domain) answers. This number
should be a small percentage of the overall number of queries. A high
number of NXDOMAIN answers can indicate a misconfiguration or a
NXDOMAIN answers All
possible attack. Note that the counter continues to function even when
NXDOMAIN redirection is enabled. For more information about redirection,
see Redirecting NXDOMAIN Responses on page 156.
Number of SERVFAIL (server failure) answers. SERVFAIL responses can
SERVFAIL answers All occur when validation fails and the data is bogus or when a bad packet is
received.
Number of NXDOMAIN responses that are redirected by the attributes in
NXDOMAIN redirects All the cache.conf configuration file. For more information, see Redirecting
NXDOMAIN Responses on page 156.
resolver loops Number of resolver loops detected, which indicates that the resolution
All
detected process for a lookup is looping.
Number of lame delegations. This indicates name servers configured as
lame delegations All
authoritative for a zone that do not have authoritative data for the zone.
Number of failed validation attempts. Numerous failed validations can
failed validation
All indicate configuration issues with trust anchors, a DLV, or keys. It can also
attempts
indicate upstream trust or signing/key problems.
cachedns application stats
The time the server has been running since it was last started. This
cachedns uptime All
provides a timeframe for understanding the overall statistics.
number of cache entries
Summary
referral cache entries View Number of RRset cache entries
View/Instance
Summary
answer cache entries View Number of message cache entries
View/Instance
Summary
key cache entries View Number of key cache entries
View/Instance
Summary
infrastructure cache
View Number of infrastructure cache entries
entries
View/Instance
Summary
entries total View Number of total cache entries
View/Instance
memory usage breakdown
Summary
referral cache
View RRset cache size in kb
memory
View/Instance
Summary
answer cache
View Message cache size in kb
memory
View/Instance
Summary
key cache memory View Key cache size in kb
View/Instance
221
Summary
infrastructure cache
View Infrastructure cache size in kb
memory
View/Instance
Summary
negative cache
View Negative cache size in kb
memory
View/Instance
Total amount of memory allocated to recursive client queries configured for
Summary logical interfaces. Configuring a larger number of permitted client queries
udp context memory View requires more memory. For more information, see the num-
View/Instance recursive-clients configuration attribute as discussed in
general purpose
Summary General purpose memory size in kb
memory
222
Chapter 6. Secure Configuration
Overview
Many security features are built into the Secure64 DNS Cache system. Operating system and
platform security, such as protection from protocol exploits and TCP SYN flood attacks, are
automatic and require no additional configuration or activation.
For UDP and TCP data flood attacks, Secure64 DNS Cache includes rules-based limits. The
system administrator (sysadmin role) configures rate limiting and DoS/DDoS mitigation.
A number of issues related to securing DNS are outside the scope of the name server software.
For your convenience, this chapter includes many of the security recommendations found in the
Secure Domain Name System (DNS) Deployment Guide published by the National Institute of
Standards and Technology, located at
http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf.
• For information about automatic security mechanisms, see Inherent Security on
page 224.
• For configuration instructions and information about DNS DDoS attack
mitigation, see Defending Against DNS DDoS Attacks on page 224.
• For configuration instructions and information about mitigating queries based on
query type, see DNS RRtype Filtering Rules on page 238
• For information and commands related to the Sensitive Data Protocol (SDP), see
Securing Sensitive Data on page 244.
223
Inherent Security
The Secure64 DNS Cache platform is powered by the secure, high-performance Secure64
SourceT micro operating system. The micro OS is secure by design at the root to take full
advantage of the advanced security capabilities found only in the Intel Itanium processor. The
system utilizes the unique security and parallel performance characteristics of the processor,
and the OS is designed to be self-defending from various attacks.
In addition, the system includes detection and mitigation for protocol exploits and TCP SYN
flood attacks. Segregated roles and responsibilities, a secure console, and an SSH command-line
interface help defend against additional types of security threats and attacks.
Table 36 summarizes threat types and built-in mitigation methods. The following sections
provide additional information about security measures built into Secure64 DNS Cache.
Table 36. Platform security measures
Threat Mitigation Method

Compromise by rootkits, viruses, Trojans, Inherent to the SourceT micro operating system; see the Secure64
and other malware web site for details (www.secure64.com)
Inherent to the SourceT micro operating system; see the Secure64
OS buffer overflow attacks
web site for details (www.secure64.com)
Extremely small attack surface; all ports closed except those used
Port-based access/compromise
for DNS, SSH, and BGP (if enabled)
Automatic detection of malformed packets and invalid combinations
Protocol exploits
of header bits, which are dropped automatically
TCP SYN flood attacks Automatic detection and mitigation via pre-connect/aging method
Automatic detection of TCP packets with the FIN, URG, and PSH
Christmas tree attacks
bits set.
User accounts and segregated roles and responsibilities; see Roles
Inside attack
and User Accounts on page 27
SSH command-line interface and scp file copy from/to the server;
Secure access and file copy
see Secure Console on page 12 and Secure Copy on page 23
Passwords for Secure64 DNS server users are stored using a
Password security
scheme based on the SHA-256 has algorithm
Defending Against DNS DDoS Attacks

DNS servers can be used by hackers to reflect and amplify DNS data floods directed at another
target. In addition, a DNS server can be the intended victim of the flood and/or amplification
attack. Secure64 DNS Cache protects against both situations for UDP and TCP traffic.
The system administrator (sysadmin role) should configure rate limiting and DDoS defenses.
The following sections provide information about different types of attacks and how to
configure Secure64 DNS Cache to defend against them.
224
Note For details about built-in cache poisoning protections and setting up the cache.conf server configuration
file to protect against caching-related security exploits, refer to Configuring for Security on page 119,
Enabling DNSSEC-Validated Queries on page 128, and Advanced Security Configuration on page 172.
About Attack Threats and Countermeasures

Table 37 identifies DNS DDoS threats and security measures.
Table 37. DNS threats and countermeasures
Threat Countermeasure
Automatic detection and mitigation via DNS packet inspection. See
Malformed DNS requests
DNS Packet Inspection below.
Automatic blacklisting, rules-based flood protection, and high-
performance system that can operate while under attack. See About
UDP packet flood attacks
UDP Data Flood Protection on page 226 and About Rate-Limiting
Rules on page 227.
Automatic blacklisting, rules-based flood protection, and high-
performance system that can operate while under attack. See About
TCP packet flood attacks
TCP Flood Protection on page 226 and About Rate-Limiting Rules on
page 227.
Rules-based DNS RRtype request filtering and high-performance
DNS query type request flood system that can operate while under attack. See DNS RRtype
Filtering Rules on page 238.
Restrict console connections. See Restricting Console Connections
Malicious host on same LAN as DNS client
on page 242.
DNS Packet Inspection

To efficiently withstand attacks while processing valid DNS queries, the Secure64 DNS Cache
I/O processor performs DNS validation on all UDP packets sent to the server’s configured DNS
IP address(es) and port. This process eliminates threats posed by malformed DNS queries.
By default, UDP packets with a bad checksum or no checksum are dropped. You can configure
the server to accept UDP packets that do not contain a checksum. For details, see Configuring
UDP Packet Checking on page 257.
Secure64 DNS Cache rejects queries that are shorter than the minimum query length and rejects
any DNS responses sent to the standard DNS port 53. DNS responses to queries sent by
Secure64 DNS Cache are sent to a different UDP port and do not affect the validation process.
225
About Data Flood Protection Mechanisms

About UDP Data Flood Protection
Secure64 DNS Cache supplies port-based protection from UDP packet floods through
automatic IP-based rate limiting and configurable aggregate rate limiting as follows:
• Administrators can configure the software to limit the number of UDP packets
accepted per second. This is an aggregate limit, regardless of the source IP address.
• Once an administrator configures the aggregate limit, Secure64 DNS automatically
invokes a predetermined packets-per-second limit, per source IP address. The per
source IP address limit can be customized.
• The system continuously compares the limits with the average packet rate, on both an
aggregate and a per-source-IP basis.
• If a source IP address surpasses the packets-per-second limit, the software
automatically blacklists the IP address and drops its incoming packets. “Good” traffic
continues to flow and new connections can occur, even though an attack is being
blocked.
Note The mitigation system computes a running average of incoming traffic to compare to the traffic limits. A
running average makes use of data over time, which introduces a phase delay as the running
averages are calculated. This can cause a lag before the mitigation system begins blacklisting, which
means that the real-time traffic rate when blacklisting begins may be slightly higher than the limits.
• If the flood from the blacklisted IP address backs off, traffic is accepted after a timeout
period. This helps ensure that a spoofed IP address does not block a real user.
• Repeat offenses result in faster blacklisting than the first-time offense. The system
retains blacklisted IP addresses for a period of time, which is known as graylisting.
• If the configured aggregate UDP limit is reached, a rate-controller mechanism begins
probabilistically dropping packets in order to maintain the incoming rate at the
configured limit. This may result in some good traffic loss; however, the server can
remain available to a quantity of good traffic and to administrators for remediation and
recovery.
About TCP Flood Protection

To help protect against TCP floods, Secure64 DNS Cache limits the number of allowed
simultaneous TCP connections. You can also configure the software to apply further limits on
specific TCP ports, such as the SSH port 22.
Secure64 DNS Cache supplies port-based protection from TCP packet floods through
automatic IP-based rate limiting and configurable aggregate rate limiting as follows:
226
• Administrators can configure the software to limit the number of TCP packets accepted
per second. This is an aggregate limit, regardless of the source IP address.
invokes a packets-per-second limit, per source IP address. The per source IP address limit
can be customized.
• The system continuously compares the limits with the average packet rate, on both an
• Administrators can specify that trusted TCP traffic, such as an internal DNS caching
server, is not subject to the mitigation features.
• If an IP address surpasses the packets-per-second limit, the software issues a TCP reset
(RST) packet to block the specific attacker. (A RST is issued because blocking TCP traffic
based on IP address can incorrectly stop valid TCP traffic.)
• If the configured aggregate limit is reached, packets arriving in excess of the limit are
dropped.
About Rate-Limiting Rules

Rules govern how a given type of traffic is treated. You define rules to handle UDP and TCP
traffic on the port configured for DNS, providing a mechanism to decrease the risk of UDP and
TCP data floods. The sysadmin role configures and manages rules.
Note that Secure64 DNS Cache disregards incoming traffic on all ports other than the port
configured for DNS queries (default port 53), the SSH (default port 22), and BGP port 179
(default port, enabled). For outgoing traffic, Secure64 DNS Cache uses port 123 for NTP, port
162 for SNMP (if enabled), port 514 for syslog, port 1812 (default, if enabled) for RADIUS, and
port 389 for LDAP.
Rule Syntax and Examples

The rule command syntax is:
rule <name> <logical_expression> : <action> [value]
Note Spaces in the syntax are significant.
227
The components of the command are identified in Table 38:
Table 38. Rule components
Component
Examples Description
name
A text string that provides a name for the rule. Do not use
udprule
spaces in the string.
tcprule
logical_expression Operators include:
udp.dstport == 22 > greater than
udp.port == 53 >= greater than or equal to
ip.addr == 192.168.127.63/16
< less than
ip.addr == 2001:db8:aaa:bbb:/64
icmp.type == 8 <= less than or equal to
tcp.dstport == 22 == equal to
tcp.port != not equal to
ip.addr == 10.20.0.220/24 && tcp.port == 53 && and
|| or
Variables include :
eth.type Payload indicator in the Ethernet header
icmp.type ICMP type (number)
ip.addr IPv4 or IPv6 address/prefix (CIDR notation)
ip.srcaddr IPv4 or IPv6 source address/prefix (CIDR
notation)
ip.dstaddr IPv4 or IPv6 destination address/prefix (CIDR
notation)
ip.proto The IP protocol number in the IP header
describing the payload of the IP packet
tcp.port incoming (destination) TCP port or remote host
(originating) TCP port
tcp.dstport incoming TCP (destination) port
tcp.srcport outgoing TCP (source) port
udp.port incoming (destination) UDP port or remote host
(originating) UDP port
udp.dstport incoming UDP (destination) port
udp.srcport outgoing UDP (source) port
action [value][/per_IP_value] limit <value>[/per_IP_value] for <value>, define a
limit 100 limit for the number of incoming kilopackets per second (UDP
limit 5/1024 and TCP); for [per_IP_value], define a limit for the number of
estblimit 8 incoming packets per second for each unique source IP
drop address, if undefined the per_IP_value is 4096
pass estblimit <value> define a limit for the number of
established connections per minute (TCP)
drop drop traffic from a specific IP address (UDP and TCP)
pass allow all traffic from a specific IP address (TCP, trusted
UDP)
228
Examples of rules are included in Table 39.
Table 39. Rule examples
Example Description
rule udptraffic udp.dstport == 53 : limit 10 Creates the rule named
udptraffic that limits
the aggregate incoming
traffic on UDP port 53 to 10
kilopackets (10 x 1024) per
second
rule udptraffic udp.dstport == 53 : limit 100/1024 Creates the rule named
udptraffic that limits
the aggregate incoming
traffic on UDP port 53 to 100
kilopackets (100 x 1024) per
second and incoming traffic
for each unique IP address
to 1024 packets per second
rule block ip.addr == 2001:db8:aaaa::/48 : drop Creates the rule named
block that drops all
incoming UDP/TCP traffic
from IP address block
2001:db8:aaaa::/48
rule SSHLIMIT tcp.dstport == 22 : estblimit 8 Creates the rule named
SSHLIMIT that limits the
number of established TCP
connections on TCP port 22
(the default SSH port) to 8
per minute
rule IPv4PINGBLOCK icmp.type == 8 : drop Blocks IPv4 ICMP Echo
(ping) requests
rule IPv6PINGBLOCK icmp.type == 128 : drop Blocks IPv6 ICMP Echo
(ping) requests
229
Understanding Rule Attachment, Multiple Rules, and Compound Rules

Rules are attached to one or more interfaces. You can also attach multiple rules to a single
interface.
Note To retain rule configuration changes, issue the activate and save commands. When the configuration
changes are activated, the system resets the accumulated mitigation state. Any blacklisted or
graylisted hosts are cleared, but they will retrigger their status if attacks continue. In addition, syslog
messages and SNMP traps are reset.
To associate one or more rules with an interface:

• Type the following command and press ENTER:
attach <interface> <rule1> [rule2] [rule3]
where interface is defined in the form: ethX, ethX.I, ethX:V.I, or bondX,
bondX.I and
V= the VLAN ID
addresses for each physical interface, 1-255)
and <rule1>, [rule2], and [rule3] are the names of rules you have created.
Note The above is an example only. You can attach more than three rules to an interface.
The following conventions apply when attaching multiple rules to an interface:

• The system applies rules to incoming traffic based on the order the rules are attached to
the interface.
• The system implements the first rule that matches the incoming data; any remaining
rules are not applied to that traffic.
Examples:
• In the following example, all traffic from IP address 10.1.1.54/32 is passed with no port
restriction, while traffic to port 53 from any other IP address is rate limited:
rule MAILWHITE ip.addr == 10.1.1.54/32 : pass
rule UDPLIMIT udp.dstport == 53 : limit 100
attach eth0 MAILWHITE UDPLIMIT
230
• If the rules are attached in reverse order, the system applies the first rule that matches and
any remaining rules are not applied. As a result, all traffic to port 53, including traffic
from 10.1.1.54/32, is rate limited:
attach eth0 UDPLIMIT MAILWHITE
The following conventions apply when attaching compound rules to an interface:

• The system applies rules to incoming traffic based on the order the rules are presented in
the compound rule.
• If the incoming traffic matches the first logical expression, but fails to match a subsequent
expression in the compound rule, the traffic is dropped.
• If the incoming traffic does not match the first logical expression, the compound rule is
not applied.
Examples:
• In the following example, traffic coming from IP address 192.168.1.0/24 is rate limited,
while all other traffic is passed. This occurs for all other traffic because it does not match
the first expression (ip.addr == 192.168.1.0/24), so the rule does not apply.
rule LIMIT ip.addr == 192.168.1.0/24 && udp.dstport == 53 : limit 5
• If the order of the expressions is reversed, then 192.168.1.0/24 is rate limited, but all
other traffic is blocked. This occurs for all other traffic because the first expression
(udp.dstport == 53) matches, but the subsequent expression (ip.addr ==
192.168.1.0/24) does not.
rule LIMIT udp.dstport == 53 : limit 5 && ip.addr == 192.168.1.0/24
231
Default Rules
To provide initial security and attack mitigation for the console and DNS interfaces you have
configured, Secure64 DNS Cache provides default rules to limit UDP, TCP, and SSH attack
traffic. Attaching Mitigation Rules to Console and DNS Interfaces on page 79 describes how to attach
the default rules to the Secure64 DNS Cache interfaces.
For reference, the format of the default rules are:
rule LOGINLIM tcp.dstport == 22 : estblimit 8
rule TCPXFERLIM tcp.dstport == 53 : limit 10/4096
rule UDPQUERYLIM udp.dstport == 53 : limit 90/4096
After initial configuration and testing is complete, you can remove the default rules and create
and attach new rules based on your system’s configuration and architecture. For details about
removing rules, see the following section. More information about creating rules for UDP and
TCP rate limiting is provided in Configuring UDP Rate Limit or Drop Rules on page 234 and
Configuring TCP Rules for SSH and DNS Traffic on page 236.
Disabling Rule Actions

If you want to monitor logging and SNMP traps (see Implementing SNMP on page 391)
generated by rules without enforcing the actions defined by the rules, use the ruleactions
command. By default, rule actions are enabled.
! WARNING Disabling rule actions requires administrators to carefully monitor activity and determine whether
to take action, rather than using the built-in mitigation features of Secure64 DNS Cache.
Disablling rule actions affects all rules and is not recommend for production use.
In addition, reporting and logging details will not reflect mitigation activity, such as automatic
blacklisting discussed in About Data Flood Protection Mechanisms on page 226, that would
occur if the rule actions were enabled.
To disable rule actions:

• At the sysadmin prompt, type the following command and press ENTER:
ruleactions off
• After typing activate and save to make the configuration changes effective, type show
config and press ENTER. The server configuration information should display “rule
actions disabled.”
Example:
[sysadmin@Secure64DNS]# ruleactions off
Rule actions disabled.
232
To re-enable rule actions:

ruleactions on
• After typing activate and save to make the configuration changes effective, type show
config and press ENTER. The server configuration information should display “rule
actions enabled.”
Removing a Rule
To remove a rule, you must first unattach any interfaces linked to the rule.
To unattach rules from an interface:

• At the sysadmin prompt, type the following command and press ENTER, where
<interface> is the interface name in the form ethX:I.V or bondX.I
no attach <interface>
Example:
[sysadmin@Secure64DNS]# no attach eth3:43.2
Note The no attach command removes ALL rules from the defined interface. You must use the
attach command to reattach the rules you want to retain, if any, and attach them in the order you want
them applied.
To remove the rule:

• At the sysadmin prompt, type the following command and press ENTER, where <name>
is the name of the rule to remove:
no rule <name>
Example:
[sysadmin@Secure64DNS]# no rule mytest2
Rule mytest2 removed
233
Configuring UDP Rate Limit or Drop Rules
Rate Limit Rules

Secure64 DNS Cache offers port-based protection from UDP packet floods through rate
limiting. You define an aggregate limit in kilopackets per second.
Tips for estimating the aggregate UDP rate limit include:
• Base the limit you define on the expected load. Accordingly, a name server that receives
large volumes of queries needs a higher limit than a low-traffic server.
• You can estimate the expected load by looking at the average per-second query rate per
server. Multiply this estimate by 5x to estimate a reasonable normal load. However, to
avoid blocking good traffic, take care not to set the limit too low.
As an example, if the expected load is 20K queries per second, 5x this amount results in the
following rule:
rule udplimit udp.dstport == 53 : limit 100
In addition to an aggregate limit, you can also define a limit per source IP address. If you do not
define a custom per-IP address limit, the server defaults to limiting each IP address to 4096
incoming packets per second.
To create a rule for rate limiting on UDP port 53:

1. At the sysadmin prompt, type the following command and press ENTER:
rule <name> udp.dstport == 53 : limit <value>[/per_IP_value]
where <name> is the name of the rule, <value> is the aggregate limit in kilopackets
per second, and [per_IP_value] is the optional custom per source IP limit in packets
per second.
Example:
[sysadmin@Secure64DNS]# rule mytest udp.dstport == 53 : limit 100/
2048
Rule mytest added
2. To attach the rule to the interface(s) configured for DNS traffic, type the following
command and press ENTER:
attach <interface> <name>
234

V= the VLAN ID
for each physical interface, 1-255)
and <name> is the name of the rule.
Example:
[sysadmin@Secure64DNS]# attach eth3 udplimit
Rules to Drop Traffic
You can use other information about your server’s traffic to customize its rule set. For example, if
a specific IP range identifies a known attacker, you can use the drop action to ignore all traffic
originating from it.
To create a rule to drop a specific IP address on UDP port 53:

rule <name> ip.addr == <#> && udp.dstport == 53 : drop
where <name> is the name of the rule and <#> is the IP address/prefix from which to
drop traffic.
Example:
[sysadmin@Secure64DNS]# rule drop ip.addr == 10.20.0.220/16 udp.dstport == 53 : drop
Rule drop added
To create a rule to drop all incoming traffic on UDP port 53:

rule <name> udp.dstport == 53 : drop
where <name> is the name of the rule.
Example:
[sysadmin@Secure64DNS]# rule dropall udp.dstport == 53 : drop
Rule dropall added
235
Note If you are in the process of creating multiple rules for your DNS interface(s), wait to use the attach,
activate, and save commands until you have created all necessary rules. You can then attach
the rules in the order you want them applied. See Understanding Rule Attachment, Multiple Rules, and
Compound Rules on page 230 for more information.
Configuring TCP Rules for SSH and DNS Traffic
You can establish rules to limit the number of established TCP connections for DNS and SSH
traffic on a per-port basis. You can also configure rules to allow the traffic to pass without
limits for trusted internal traffic. To prevent DDoS attacks on TCP ports used for SSH and
DNS traffic:
• Configure a rule to limit the number of established TCP connections per minute on
SSH port 22 (or an alternate port if configured); this prevents a host attacking on port
(trying to repeatedly connect) from blocking out a valid host on the same port
• Configure a rule to limit the number of incoming TCP packets per second on DNS
port 53 (or alternate port if configured)
• If you want to allow all TCP traffic to pass, you can configure a pass rule
• Attach SSH rules to any interfaces used for console connections (see Adding and
Removing Console Interfaces on page 281 and Restricting Console Connections on page 242)
• Attach the DNS rule(s) to the interfaces used for DNS traffic (see Adding and Removing
IP Addresses for Interfaces on page 276)
To create a rule that limits the number of established connections on TCP port 22
(SSH):
rule <name> tcp.dstport == 22 : estblimit <value>
where <name> is the name of the rule and <value> is the number of established
connections.
Example:
[sysadmin@Secure64DNS]# rule SSH tcp.dstport == 22 : estblimit 8
Rule SSH added
236
To create a rule that limits the number of incoming packets per second on a specific TCP
port, such as DNS port 53:
rule <name> tcp.dstport == <port_number> : <value>[/per_IP_value]
where <name> is the name of the rule, <port_number> is the TCP port, <value> is
the aggregate limit in kilopackets per second, and [per_IP_value] is the optional
custom per source IP limit in packets per second
Example:
[sysadmin@Secure64DNS]# rule DNS tcp.dstport == 53 : limit 10
Rule DNS added
To create rules that allow internal traffic to bypass incoming TCP packet limits:
rule <name> ip.addr == <internalIP> && tcp.port == 53 : pass
where <name> is the name of the rule <internalIP> is the IP address/prefix of the
internal, trusted server
To attach rule(s) to the interface(s) configured for SSH or DNS traffic:

• Type the following command and press ENTER:
attach <interface> <rule1> [rule2][rule3]
V= the VLAN ID
and <rule1> [rule2][rule3]are the names of the rules to attach to the interface.
Note If you are in the process of creating multiple rules for your DNS interface(s), wait to use the attach,
activate, and save commands until you have created all necessary rules. You can then attach the
rules in the order you want them applied. See Understanding Rule Attachment, Multiple Rules, and
Compound Rules on page 230 for more information.
237
DNS RRtype Filtering Rules

About RRtype Filtering
Secure64 DNS Cache provides filtering of incoming queries based on a defined RRtype as
follows:
• Administrators can configure the software to limit the number of queries for a specific
DNS RRtype accepted per second. This is an aggregate limit, regardless of the source
IP address.
invokes a predetermined queries-per-second limit, per source IP address. The per
source IP address limit can be customized.
• The system continuously compares the limits with the average query rate, on both an
• If a source IP address surpasses the queries-per-second limit, the software automatically
blacklists the IP address and drops its incoming queries. “Good” traffic continues to
flow, even though an attack is being blocked.
Note The mitigation system computes a running average of incoming traffic to compare to the traffic limits. A
running average makes use of data over time, which introduces a phase delay as the running
averages are calculated. This can cause a lag before the mitigation system begins blacklisting, which
means that the real-time traffic rate when blacklisting begins may be slightly higher than the limits.
• If the flood from the blacklisted IP address backs off, traffic is accepted after a timeout
period. This helps ensure that a spoofed IP address does not block a real user.
• Repeat offenses result in faster blacklisting than the first-time offense. The system
retains blacklisted IP addresses for a period of time, which is known as graylisting.
• If the configured aggregate query limit is reached, a rate-controller mechanism begins
probabilistically dropping queries in order to maintain the incoming rate at the
configured limit. This may result in some good traffic loss; however, the server can
remain available to a quantity of good traffic and to administrators for remediation and
recovery.
238
About RRtype Filtering Rules
changes are activated, the system resets the accumulated mitigation state. Any blacklisted or graylisted
hosts are cleared, but they will retrigger their status if attacks continue. In addition, syslog messages and
SNMP traps are reset.
You can establish rules to drop or limit specific DNS RRtype queries received by the Secure64
DNS Cache server. You can also configure rules to allow specific DNS RRtype queries to pass
without limits.
For DNS RRtype filtering, the rule command syntax is:
rule <name> dns.rrtype <operator> <RRtype> : <action>
Note Spaces in the syntax are significant.
where:
• <name> is a text string that provides a name for the rule (no spaces)
• <operator> is one of the following symbols:
= = (equal to)
!= (not equal to)
|| (or)
Note The additional operators described inTable 38 on page 228 are operable for RRtype filtering, but there
are not practical applications for their use.
• <RRtype> is the numeric code or alpha representation of the DNS query type
• <action> is one of the following parameters:
limit <value>[/per_IP_value]
For <value>, define an aggregate limit for the number of incoming queries per
second; for [per_IP_value], define a limit for the number of incoming queries per
second for each unique source IP address, if undefined the per_IP_value is 4096
drop
Drop traffic for a specific RRtype query
pass
Allow all traffic for a specific RRtype query
239
Table 40. RRtype filtering examples
Example Description
rule TXTlimit dns.rrtype == 16 : limit 4/100 Creates the rule named
TXTlimit that limits the
aggregate incoming queries
for RRtype 16 (TXT) to 4 x
1024 queries per second
and the per IP address limit
to 100 queries per second.
rule TSIGexempt dns.rrtype == TSIG : pass Creates the rule named
TSIGexempt that allows
all incoming TSIG queries
without mitigation.
rule ANYdrop dns.rrtype == ANY : drop Creates the rule named
ANYdrop that drops all
incoming ANY RRtype
queries.
rule TXTMX dns.rrtype == TXT || dns.rrtype == MX : drop Creates the rule named
TXTMX that drops all
incoming TXT or MX
RRtype queries.
About RRtype Filtering Rule Attachment

To enable the DNS RRtype filtering rule, issue the attach command using the following syntax:
attach dnsserver <rule1> [rule2] [rule3]
Where <rule1>, [rule2], and [rule3] are the names of rules you have created.
Note The above is an example only. You can attach more than three RRtype filter rules to the server.
The following conventions apply when attaching RRtype filter rules:

• The dnsserver keyword in the attach command denotes that the rule is applied at the
DNS server level. You must use this keyword for DNS RRtype filtering rules, and it is
not allowed for UDP- or TCP-based rules.
• As with other rule types, DNS RRtype rules are applied in the order attached to the
server, and
• When multiple rules are attached to the server, the system implements the first rule that
matches incoming queries, causing further processing to stop
• You cannot create compound rules using dns.rrtype with other types of rules. You can
create compound dns.rrtype rules.
240
• You cannot attach I/O rules to the dnsserver keyword
Examples:
• In the following example, two RRtype rules are attached to the server. Based on the order,
the ANYdrop rule is examined first. If the incoming query does not match, the server
compares it to the TXTlimit rule.
rule ANYdrop dns.rrtype == ANY : drop
rule TXTlimit dns.rrtype == 16 : limit 4/100
attach dnsserver ANYdrop TXTlimit
Disabling Rules
Secure64 DNS Cache provides a mechanism to monitor logging and SNMP traps generated by
rules without enforcing the actions defined by the rules. For details, refer to Disabling Rule Actions
on page 232.
Removing an RRtype Filtering Rule

To remove a rule, you must first unattach the rule.
To unattach an RRtype rule from the server:

no attach dnsserver
Example:
[sysadmin@Secure64DNS]# no attach dnsserver
Note The no attach command removes ALL rules from the server. You must use the attach
command to reattach the rules you want to retain, if any, and attach them in the order you want them
applied.
To remove the rule:

• At the sysadmin prompt, type the following command and press ENTER, where <name>
is the name of the rule to remove:
no rule <name>
Example:
[sysadmin@Secure64DNS]# no rule mytest2
Rule mytest2 removed
241
Attack Monitoring, Notification, and Statistics

For information about its defense and mitigation system, the Secure64 DNS Cache server
provides the following tools:
• Defense statistics are available through the show defense info command. For
details, see Displaying Mitigation and Self-Defense Statistics on page 386.
• Notifications of attack behavior are available through SNMP traps and statistical
information is available through standard and proprietary MIBs. For details, see
Implementing SNMP on page 391.
• The Secure64 DNS Cache reporting and logging system records statistical data and
event-specific data to syslog. The syslog messages are sent as SYSTEM:DDOS at the
LOG_ALERT level.
• For DDoS and DoS messages in syslog, the statistical data closely parallels the SNMP
trap behavior, and event-specific data identifies events associated with specific hosts
and/or IP addresses. You can use this information to help defend your system against
attack. For additional details about mitigation reporting and logging, see Defense and
Mitigation Logging Messages (Statistical) on page 448 and Defense and Mitigation Logging
Messages (Events) on page 450.
Restricting Console Connections

Secure64 DNS Cache allows you to limit the systems allowed to connect to it via SSH. You can
also limit the number of established connections per minute as discussed in Configuring TCP
Rules for SSH and DNS Traffic on page 236.
Note If no restrictions are configured, all IP addresses are allowed to connect to the console by default.
Adding a Restriction
To limit the systems allowed to establish a connection with the console via SSH:
<ipaddress> defines the IP address and [netmask] (optional) defines a netmask for
the console connection(s):
allow <ipv4 address> [ipv4 netmask]
or
allow <ipv6 address>[/<ipv6 prefix length>]
If an IPv4 netmask or IPv6 prefix length is not specified, only the system matching the
explicit IP address can connect to the console.
242
Examples:
The following example allows systems with IPv4 addresses in the range 192.168.152.0
through 192.168.152.255 to establish connections to the console via SSH:
[sysadmin@Secure64DNS]# allow 192.168.152.0 255.255.255.0
The following example allows an IPv6 address of 2001:db8::1 to establish a connection to

the console via SSH:
[sysadmin@Secure64]# allow 2001:db8::1
The following example allows IPv6 addresses of 2001:db8:aaaa::/48 to establish

connections to the console via SSH:
[sysadmin@Secure64DNS]# allow 2001:db8:aaaa::/48
Removing a Console Restriction
To remove a console connection restriction established by the allow command:

• At the sysadmin prompt, type the following command and press ENTER, where <ipv4
address> defines the IP address and [ipv4 netmask] defines the netmask (if
configured), or where <ipv6 address> defines the IP address and [/<ipv6 prefix
length>] the prefix length (if configured):
no allow <ipv4 address> [ipv4 netmask]
or
no allow <ipv6 address>[/<ipv6 prefix length>]
Examples:
[sysadmin@Secure64DNS]# no allow 192.168.152.0
[sysadmin@Secure64DNS]# no allow 2001:db8:aaaa::/48
243
Securing Sensitive Data

For additional security, the Secure64 DNS server provides a Sensitive Data Protection (SDP)
infrastructure for encrypting sensitive information stored on the server.
You can protect the following information with this feature:
• RADIUS shared secret
• LDAP bind password
About Sensitive Data Protection (SDP)

SDP secures a Sensitive Data Unit (SDU), such as a RADIUS shared secret, by storing it in
encrypted form. Through the use of identifiers and keywords, you use commands available in
the securityadmin role to associate the encrypted SDU with the subsystem that uses it.
Components
The components of SDP include:
• Protection key - A 128-bit AES encryption key automatically generated by the system.
A unique key is used for each subsystem.
• SDU - The data (Sensitive Data Unit) being secured. It must consist of an extended
ASCII set (EAS) string, and it is case sensitive.
Note Do not use the NUL character (EAS code 0) in the value of the SDU. To enter a non-printable EAS
character, use the convention \x<ascii-code> where <ascii-code> is the hexadecimal code for the
character.
• Subsystem - The Secure64 DNS server subsystem linked to the SDU. Options are
RADIUS or LDAP.
• Keyword - The keyword linked to the SDU, based on subsystem. It is not case
sensitive.
— RADIUS subsystem - The keyword is the value of the server: attribute in
radius.conf associated with the SDU. Multiple keywords are supported (one for
each RADIUS server defined).
— LDAP subsystem - The keyword is the string: bindpasswd
This is the only keyword supported or necessary. The ldap.conf configuration
uses a single bind password for multiple LDAP servers.
244
Rules and Format

• The SDU commands are available in the securityadmin role
• The currently supported Secure64 DNS server subsystems are RADIUS and LDAP
• The Secure64 DNS server attempts to use an SDU first, and then if not successful,
attempts to use the regularly configured data.
• SDUs and protection keys are included in the Secure64 DNS server backup and restore
processes.
• The data (Sensitive Data Unit) must consist of an extended ASCII set (EAS) string. Do
not use the NUL character (EAS code 0) in the value of the SDU. To enter a non-
printable EAS character, use the convention \x<ascii-code> where <ascii-code> is
the hexadecimal code for the character. The code must be two digits, for example, the
character with ASCII code 13 is entered as \x0d or \x0D.
Creating and Managing Sensitive Data Units (SDUs)

Creating and managing SDUs is accomplished through a set of commands. The SDU commands
are available to users assigned to the securityadmin role.
Creating an SDU
To create an SDU:
• From the securityadmin role, execute:
sdu protect <subsystemID> <keyword> <SDU>
where
<subsystemID> is the related subsystem (RADIUS or LDAP)
<keyword> is the identifier linked to the SDU
— RADIUS subsystem - The value of the server: attribute in radius.conf
associated with the SDU. Multiple keywords are supported (one for each RADIUS
server defined).
— LDAP subsystem - The string: bindpasswd
This is the only keyword supported or necessary. The ldap.conf configuration uses
a single password for multiple LDAP servers.
<SDU> is the data to protect
Example:
[securityadmin@Secure64]# sdu protect RADIUS 192.168.127.1 mysecret
SDU created for keyword 192.168.127.1
245
Viewing the Contents of the SDP
To view the contents of the SDP:

sdu list [<subsystemID>]
where the optional <subsystemID> limits the list to the defined subsystem (RADIUS or
LDAP)
Example:
[securityadmin@Secure64]# sdu list
RADIUS:
192.168.127.2
192.168.127.1
Displaying Plain Text SDU Content
To display the plain text (unencrypted) content of an SDU associated with a specific
subsystem and keyword:
sdu reveal <subsystemID> <keyword>
where
server defined).
This is the only keyword supported or necessary. The ldap.conf configuration
uses a single password for multiple LDAP servers.
Example:
[securityadmin@Secure64]# sdu reveal RADIUS 192.168.127.1
SDU is mysecret
246
Replacing an SDU
To replace an existing SDU with a new SDU:

sdu replace <subsystemID> <keyword> <SDU>
where
server defined).
<SDU> is the new SDU data
Example:
[securityadmin@Secure64]# sdu replace RADIUS 192.168.127.1 newsecret
SDU mysecret replaced for keyword 192.168.127.1
Deleting an SDU
To delete an SDU for a specific subsystem and keyword:

sdu delete <subsystemID> <keyword>
where
server defined).
247
Example:
[securityadmin@Secure64]# sdu delete RADIUS 192.168.127.2
SDU deleted for keyword 192.168.127.2
Clearing the SDP of Content
To clear the SDP of all content:

sdu reset
! WARNING Executing this command removes all content in the SDP. This action cannot be reversed.
Example:
[securityadmin@Secure64]# sdu reset
WARNING: This action irretrievably removes all entries from the

SDP repository and generates new SDU protection keys.
Do you wish to proceed? (y/n)
Backing Up and Restoring the SDP

SDP information is included in the system back up and restore process as discussed in Backing
Up and Restoring System Files on page 297.
248
Recommendations and Best Practices

The Secure Domain Name System (DNS) Deployment Guide published by the National Institute of
Standards and Technology, at http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-
81r1.pdf includes many of the following recommendations.
Using Anycast and BGP to Disperse DNS Servers Geographically

Many of the root DNS servers today employ anycast IP addressing methods for redundancy,
reduced latency, and protection from DDoS attacks. Anycast allows exact copies of a DNS name
server, including its name and IP address, to be deployed in different locations. If a server
becomes unavailable due to an attack or for other reasons, another server with identical
information can handle its queries. For more information, see Chapter 8. Enabling BGP for Anycast
on page 303.
Recommendations for Securing the DNS Hosting Environment

Because Secure64 DNS Cache runs on a secure platform, threats found with other DNS
implementations are not present. For example, restricted privileges are built into the system’s
operating modes, and the server is dedicated to running Secure64 DNS Cache. It does not run
other applications or services.
Table 41 presents additional recommendations and mitigation methods for securing the DNS
host environment.
Table 41. DNS Hosting environment security
Recommendation Mitigation Method

Subscribe to mailing lists and Secure64 DNS Cache update
Monitor security threats and vulnerabilities information. See Appendix F. Recommended Resources on
page 499.
Refer to the Secure64 web site and support notices for
Keep Secure64 software updated
system upgrade availability.
BIND comes with many UNIX and Linux systems and should
Remove name server software from non-DNS hosts be removed from machines that are not providing DNS
services.
Reduce the risk of common application compromises by
Mix the deployment of DNS server software types mixing Secure64 DNS Cache name servers with BIND or
other DNS servers.
249
250
Chapter 7. System Administration

Overview
This chapter details the procedures for system administration tasks for Secure64 DNS Cache.
System related tasks are performed by the sysadmin role, with the exception of configuring an
issue file to display when users log in (optional, performed by the loginadmin role).
Most system configuration tasks are performed during initial set up of the system through the
command-line interface. You must activate and save system configuration changes for the system
to retain them, as discussed in System Configuration States on page 83.
• System administration tasks:
Configuring the Default Gateway and Other Routes...................252
Configuring In-Bound Traffic Routing Style .................................255
Configuring IP Fragmentation Resource Limits...........................256
Configuring UDP Packet Checking .............................................257
Configuring a Nodename ............................................................258
Configuring System Name Servers.............................................259
Defining the Time Zone ...............................................................260
Changing the Date and/or Time ..................................................261
Managing NTP Servers...............................................................263
Managing Syslog Servers and Local Logging.............................269
Adding and Removing IP Addresses for Interfaces ....................276
Configuring a Loopback Interface ...............................................280
Adding and Removing Console Interfaces..................................281
Changing the IP Address of a Console Interface ........................282
Changing the Console Timeout...................................................283
Configuring Ethernet Bonding .....................................................284
Customizing Login with an Issue File (optional)..........................289
Setting the Chassis Polling Interval.............................................290
Connecting a VGA Monitor (optional) .........................................291
Configuring RAID ........................................................................291
Starting in Safe Mode..................................................................292
Backup and Recovery Tasks.......................................................296
System Recovery ........................................................................299
Viewing the Cryptographic Module Status...................................299
Cryptographic module is in the Ready state. ..............................300
Upgrading the Software ..............................................................300
Determining the Secure64 DNS Cache License Key..................302
251
System Administration Tasks

System administration tasks are performed through interactive commands at the system
command-line interface from an administration console. To perform these tasks, log in as a
user assigned to the Secure64 DNS Cache in sysadmin mode.
In addition to this chapter, other resources for system administration include Chapter 6. Secure
Configuration on page 223 and Appendix A. Command Reference on page 421.
Configuring the Default Gateway and Other Routes
Note If you are configuring your machine for the first time, see Chapter 2. Getting Started on page 59.
There are three forms for the route command: standard default gateway routes, other routes,
and IPv6 link local default gateway routes.
For standard default gateway routes and other routes, the command syntax is:
route default <ipv4_or_ipv6_gateway>
or
or
route net <ipv6 address>/<prefix length> <gateway>
Note You can define a maximum of 32 routes.
The Secure64 DNS Cache software does not allow addition of a route that conflicts with the subnet of
a configured interface.
If you are using BGP, you must stop and start the BGP service if static routes are added or deleted.
See Stopping and Starting BGP on page 320 for more information.
For IPv6 link local default gateway routes, the command syntax is:
route default <IPv6_linklocal>%<interface>
where <IPv6_linklocal> is an IPv6 link local address and <interface> is the
interface to use.
Note The IPV6 link local address cannot be the ::1 loopback address. The interface must be configured with
a valid IPv6 address.
252
Adding a Standard Default IPv4 or IPv6 Gateway

• Enter the following command at the sysadmin prompt, where <gateway> is the IPv4 or
IPv6 address of the gateway for all traffic without a specified route:
route default <gateway>
Example:
[sysadmin@Secure64DNS]# route default 10.0.0.1
[sysadmin@Secure64DNS]# route default 2001:db8::1

Adding Other Routes

• To add other routes, the command syntax is:
or
route net <ipv6 address>/<prefix length> <gateway>
or
route net <ipv6 address>/<prefix length> <IPv6_linklocal>%<interface>
Example:
[sysadmin@Secure64DNS]# route net 192.168.255.0 255.255.255.0 10.1.2.3
[sysadmin@Secure64]# route net 2001:db8:aaa:bbb:/64 2001:db8::1

[sysadmin@Secure64]# route net 2001:db8:aaa:bbb:/64 2001:db8::1%eth1

253
Adding an IPv6 Link Local Default Gateway

• Enter the following command at the sysadmin prompt, where <gateway> is the IPv6
link local address of the gateway and <interface> is the interface to use:
route default <gateway>%<interface>
Example:
[sysadmin@Secure64DNS]# route default fe80::2c0:9fff:fe05:2327%eth1
Note You can use the show interfaces command to display the IPv6 link local address for the
configured interfaces.
Deleting a Route
• Use the no form of the command.
Examples:
[sysadmin@Secure64DNS]# no route default 10.0.0.1
[sysadmin@Secure64DNS]# no route net 192.168.250.0 255.255.255.0 10.1.2.3

[sysadmin@Secure64DNS]# no route default 2001:db8::1

[sysadmin@Secure64DNS]# no route net 2001:db8:aaa:bbb:/64 2001:db8::1

Note To invoke the configuration change, type activate and press ENTER.
To confirm the pending configuration, type show pending and press ENTER.
To return to the saved configuration, type revert and press ENTER.
To save the running (changed and activated) configuration, type save and press ENTER.
To restart the system with the configuration changes, type reboot.
254
Configuring In-Bound Traffic Routing Style

Secure64 DNS Cache is not a general-purpose IP packet router. However, the software offers two
different routing mechanisms for responding to inbound traffic: symmetrical routing and
asymmetrical routing.
Note Outbound TCP and UDP traffic originating from Secure64 DNS Cache always uses standard IP route
and ARP lookups.
Symmetrical Routing
With symmetrical routing, responses to in-bound requests are automatically sent back to the
neighboring router that sent in the request. For example, if a DNS query comes in on eth0 with a
specific source Ethernet address, the reply goes out the same interface to the Ethernet address of
the query source. Symmetrical routing does not perform route look ups.
Advantages of symmetrical routing include:
• Lower memory usage by the internal routing table
• Reduced CPU utilization by removing the per packet IP route lookup
• Easier management because only routes for outbound connections need to be configured
or learned via BGP
The disadvantage of symmetrical routing is a sub-optimal response path, in the rare case that the
optimal path for the out-bound response differs from the optimal path for its in-bound request.
To configure symmetrical routing:
• Enter the following command at the sysadmin prompt:
route sym
To restart the system with the configuration change, type reboot.
255
Asymmetrical Routing
With asymmetrical routing, every packet sent by Secure64 DNS involves an IP route and ARP
table lookup before transmission. Advantages of asymmetrical routing include:
• All IP packets are sent to their destination via the optimal path
• TCP connections are maintained across route table changes
Disadvantages of asymmetrical routing include potentially more manual configuration of routes
and increased CPU/memory use for per packet IP route and ARP lookups.
Note You can use BGP to update routing tables. For more information, see Chapter 8. Enabling BGP for
Anycast on page 303.
To configure asymmetrical routing:

• Enter the following command at the sysadmin prompt:
route asym
Configuring IP Fragmentation Resource Limits

To support larger DNS UDP packet sizes that can occur as a result of EDNS0 and DNSSEC
requirements, Secure64 DNS Cache provides the ability to reassemble fragmented IP packets.
Several configuration parameters are available for the system to manage resources used for
reassembly and help withstand IP fragmentation attacks.
The configuration commands are available in the sysadmin role and include:
• ip frag timeout <seconds>: The time limit for the reassembly subsystem to hold
an incomplete set of IP fragments, where seconds is 1-60. The default configuration is 5
seconds.
• ip frag high <0-50>: The maximum percentage of network buffers dedicated to
reassembly of IP fragments. The default configuration is 40 percent.
• ip frag low <0-50>: The maximum percentage of network buffers that can be
started as a new fragment set. The default configuration is 30 percent.
256
Example:
[sysadmin@Secure64]# ip frag timeout 10
[sysadmin@Secure64]# ip frag low 20

[sysadmin@Secure64]# ip frag high 30

Configuring UDP Packet Checking

To efficiently withstand attacks while processing valid DNS queries, the Secure64 DNS Cache
I/O processor performs DNS validation on all UDP packets sent to the server’s configured DNS
IP address(es) and port. This process eliminates threats posed by malformed DNS queries.
By default, UDP packets with a bad checksum or no checksum are dropped. You can configure
the server to accept UDP packets with a checksum of 0 (no checksum) with the nullchecksums
<allow|disallow> command.
To allow UDP packets without a checksum:

nullchecksums allow
Example:
[sysadmin@Secure64]# nullchecksums allow
UDP checksum processing disabled (NULL checksums are allowed).
To disallow UDP packets without a checksum:

nullchecksums disallow
257
Example:
[sysadmin@Secure64]# nullchecksums disallow
UDP checksum processing enabled (NULL checksums are disallowed).
Configuring a Nodename
To specify the name that appears in the system prompt and in syslog messages:
<name> is the identifier of the Secure64 DNS Cache name server:
nodename <name>
The new nodename is not reflected in the system prompt until you enter activate to
invoke the change.
Example:
[sysadmin@Secure64DNS]# nodename MyServer
Nodename set to MyServer
[sysadmin@MyServer]# save
To return to the default name (Secure64DNS):

<name> is the current nodename:
no nodename <name>
The default nodename (Secure64DNS) is not reflected in the system prompt until you enter
activate to invoke the change.
258
Example:
[sysadmin@MyServer]# no nodename MyServer
nodename set to Secure64DNS
[sysadmin@MyServer]# activate
Configuring System Name Servers

Specify at least two name servers for external DNS address resolution (stub resolvers) for
the Secure64 DNS Cache system to locate its NTP and syslog servers. You can specify as
many as three name servers.
Note When you specify multiple name servers, Secure64 DNS Cache uses them according to the order listed
in the system configuration. To see the currently running configuration, enter show config. To see
the currently saved configuration, enter show saved.
To specify name servers for address resolution for Secure64 DNS Cache:
• At the sysadmin prompt, type the following command and press ENTER, where 0|1|2
defines one of the three name servers <ipaddress> is the corresponding IPv4 or IPv6
address, and [timeout] is the number of seconds to wait to retry a name server:
nameserver <0|1|2> <ipaddress> [timeout]
If you do not specify [timeout], the default is 4 seconds.
Example:
[sysadmin@Secure64DNS]# nameserver 1 192.168.127.11 20
[sysadmin@Secure64DNS]# nameserver 2 2001:db8::1 10
259
Defining the Time Zone
To set the time zone:

• Type the following command at the sysadmin prompt and press ENTER:
tz <spec>
Where <spec> is the designation for the desired <timezone> or the <region>/
<timezone>.
Example:
[sysadmin@Secure64DNS]# tz MST
To revert to the default time zone (GMT):

no tz <spec>
Where <spec> is the current setting.
Example:
[sysadmin@Secure64DNS]# no tz MST7MDT
timezone set to GMT
For a list of top level time zones and regions:

tz
For a list of time zones within a region:

• Type the following command at the sysadmin prompt and press ENTER, where
<region> is the toplevel region:
tz <region>
260
Example:
tz Chile
Chile time zones:
EasterIsland Continental
To define a time zone within a region, enter:

tz <region>/<timezone>
Example:
tz Chile/EasterIsland
Changing the Date and/or Time
Note To ensure that the date and time is synchronized with other systems, configure up to five NTP servers for
the Secure64 DNS Cache server. For more information, see Managing NTP Servers on page 263. The
NTP server synchronization overrides changes made using the date command.
To display the current system date and time:

• At any prompt, type date and press ENTER.
To change the system date and/or time:

date <MMDDhhmmYYYY>
Where MMDDhhmmYYYY is the month (01-12), day of the month (01-31), hour (00-23),
minute (00-59) and four-digit year.
261
Example:
[sysadmin@Secure64]# date
Thu Sep 15 14:40:22 GMT 2011
[sysadmin@Secure64]# date 091508422011

Thu Sep 15 08:42:00 GMT 2011
262
Managing NTP Servers

Secure64 DNS Cache provides an Network Time Protocol (NTP) client to synchronize the
system clock and accurately maintain the Secure64 DNS Cache server time. The correct system
time is critical for certain DNS server functions.
Characteristics of the NTP client in Secure64 DNS Cache include:
• The NTP client supports NTP servers with and without authentication.
• You can configure up to five NTP servers.
• Immediately after booting or after an activated NTP configuration change, the NTP
client employs a random 1-5 minute delay to each configured NTP server before querying
the server, as specified in RFC 4330.
— The server with the smallest random initial delay is the first server queried by the
NTP client. Subsequent servers are queried after their delay periods expire.
— If the query fails, the NTP client extends the delay for that server by 50%, up to a
maximum of 900 seconds (15 minutes).
— If the query succeeds, the NTP client attempts to requery that server every hour.
• Once all the configured servers have been queried (regardless of whether they answered
or not), the NTP client forms a consensus for the current time using a median filter
algorithm over all valid server responses.
— The algorithm automatically rejects responses that are outliers, as compared to the
responses from the other servers. As a result, the more NTP servers configured, the
better (since outliers are easier to detect).
— If the consensus time is greater than 300 seconds (five minutes) from the system time,
no action is taken other than an alert message to syslog, noting that the time must be
set manually. Otherwise, the system clock is set to the consensus time.
Note The defined NTP server(s) are considered trusted.
For unauthenticated NTP servers, do not specify a server that you think might be compromised, or over
which you do not have control. The ideal server is a server on an internal network that can be fixed if
broken or attacked.
The Secure64 DNS Cache name server does not respond to NTP time broadcasts.
Configuring an NTP Server without Authentication

To help prevent unauthorized access or spoofing of NTP servers, NTP supports authentication
between the client (Secure64 DNS Cache) and the NTP server. The authentication mechanism
requires both systems to use a matching key number and encrypted checksum. For details, see
Configuring an NTP Server with Authentication on page 265.
263
If the NTP server you are configuring does not support authentication, use the following
procedures for configuration.
! WARNING Using an NTP server without authentication is strongly discouraged. Authentication prevents NTP
server messages from being spoofed.
To configure an unauthenticated NTP server:

1. At the sysadmin prompt, type the following command and press ENTER, where
<host> is the IPv4/IPv6 address or hostname of the NTP server and
[source_ipaddress] is the optional source IPv4/IPv6 address:
ntp <host> [source_ipaddress]
Note If you have configured two or more Secure64 DNS Cache IP addresses on the same subnet, define a
source IP address when you need to designate a specific IP address for NTP traffic, for example, to
allow traffic through a firewall.
2. For redundancy, you can configure up to five NTP servers. Repeat the command for
each NTP server you want to define.
Example:
[sysadmin@Secure64DNS]# ntp 10.0.0.1 192.168.127.175
Added NTP server 10.0.0.1
[sysadmin@Secure64DNS]# ntp 2001:db8::1

Added NTP server 2001:db8::1
264
Configuring an NTP Server with Authentication

To help prevent unauthorized access or spoofing of NTP servers, NTP supports authentication
between the client (Secure64 DNS Cache) and the NTP server. The authentication mechanism
requires both systems to use a matching key number and encrypted checksum (derived from a
shared secret).
Before you can configure the NTP server with authentication, you need the key number, hashing
method, and shared secret from the NTP server administrator. Because the authentication
information is shared between the NTP server and client (Secure64 DNS Cache), the
information must match.
To configure an authenticated NTP server:

1. Confirm the key number, hashing method, and shared secret with the NTP server
administrator.
ntpkey <keynum> <method> <secret>
Where:
— <keynum> is the NTP key number (between 1 and 4,294,967,295)
— <method> is M, for the MD5 hashing method
— <secret> is the shared secret string (1-8 characters, case sensitive)
3. To activate the NTP authentication key, type activate and press ENTER.
4. To save the NTP authentication key, type save and press ENTER.
ntp <host> <keynum> [source_ipaddress]
Where:
— <host> is the IPv4/IPv6 address or hostname of the NTP server
— <keynum> is the unique NTP key number shared with the NTP server
— [source_ipaddress] is the optional source IPv4/IPv6 address
source IP address when you need to designate a specific IP address for NTP traffic, for example, to allow
traffic through a firewall.
6. For redundancy, you can configure up to five NTP servers. Repeat the command for each
NTP server you want to define.
265
Example:
[sysadmin@Secure64]# ntpkey 204 M ctPq8iU
NTP key #204 added to pending configuration
[sysadmin@Secure64]# activate
[sysadmin@Secure64]# save
[sysadmin@Secure64]# ntp testserver 204

Added NTP server testserver using key 204
Displaying or Removing NTP Authentication Keys

You can display NTP authentication key information from any login prompt. To remove an
NTP authentication key, you must enable the sysadmin role.
To display the NTP key information:

• At the any prompt, type the following command and press ENTER:
show ntp keys
Example:
[sysadmin@Secure64]# show ntp keys
204 M ctPq8iU
To remove an NTP key:

no ntpkey <keynum>
Example:
[sysadmin@Secure64]# no ntpkey 204
NTP authentication key 204 marked for removal (pending activation)
266
Displaying NTP Server Information
To view information about the configured NTP server(s):

• At any prompt, type the following command and press ENTER:
show ntp
Example:
[sysadmin@Secure64DNS]# show ntp
remote refid st when poll reach delay offset
================================================================
*192.168.127.1 72.232.254.202 3 1540 3600 1 0 3
209.114.111.1 132.163.4.102 2 1582 3600 1 0 3
Table 42 describes the items and values in the show ntp command output::
Table 42. Show ntp command values
Item Description
The remote server name or address, truncated to a maximum of 15 characters. The asterisk to the left of
remote
the remote server indicates that the NTP subsystem is using the server for synchronization attempts.
The server reference identifier, as described in RFC 4330. If the refid shows as “.ERR,” there is a problem
refid setting up the session to the remote server. This can occur if the server name cannot be resolved or if the
server is valid but does not respond to the NTP query.
The NTP stratum of the server. Stratum 1 servers are "primary references" connected to a precision
st hardware clock source. Stratum 2 servers get their time from stratum 1 servers, stratum 3 from stratum 2
servers, and so on.
when The number of seconds since the last successful contact with the NTP server.
poll The synchronization polling interval to the NTP server, in seconds.
An 8-bit shift register. For every successful NTP server contact, the register is left-shifted one bit and the
least significant bit is set to 1. This register displays in base 8 (octal) for a quick overview of the
reach reachability of the NTP server over the last eight attempts. The value 001 indicates the most recent
attempt was answered, while 357 indicates one attempt was not answered. The value 377 indicates all
recent attempts have been answered.
delay The network transmission delay to the NTP server, in seconds.
offset The last adjustment made to the client clock, in seconds.
Sending an NTP Query to a Configured NTP Server

The ntpdate command sends an NTP query immediately, rather than waiting for the startup
delay described in RFC 4330. You can use the command to determine whether an NTP server
configured in Secure64 DNS Cache is answering NTP queries.
267
Note The ntpdate command does not set the local clock and requires the NTP server you are querying
to be configured as an NTP server in Secure64 DNS Cache.
To query a configured NTP server:

ntpdate <NTP_server>
2. To check the server status, type the following command and press ENTER:
show ntp
Note For a description of the show ntp command output, see Displaying NTP Server Information on
page 267.
Removing a Configured NTP Server

The no ntp command removes a configured NTP server (with or without authentication
enabled).
To remove a configured NTP server:

<host> is the IPv4/IPv6 address or hostname of the NTP server:
no ntp <host>
Example:
[sysadmin@Secure64DNS]# no ntp 192.168.127.99
NTP server 192.168.127.99 removed
268
Managing Syslog Servers and Local Logging

To facilitate system monitoring and reporting, Secure64 DNS Cache supports configuration of
up to four syslog servers. You should configure at least one syslog server for the Secure64 DNS
Cache system. Syslog messages are designed to report system health, notify you of potential
attacks, track DNS traffic, and record other important server activity.
Note Secure64 DNS Cache supports up to four syslog servers. Configuring at least one syslog server
is strongly recommended. Certain actionable error messages that may not be available at the
command line are sent to syslog.
In addition to writing messages to the syslog server(s), Secure64 DNS Cache writes a portion of
the syslog messages to a local file. The sysadmin role can define the size of the file using the
loglevel command as described below. The file is created whether or not a syslog server is
configured. To view the contents of the local log file, see Displaying and Exporting the Local Log File
on page 274.
Configuring Syslog and Local Logging
Note Ensure that the syslog server(s) will accept messages from remote systems. For example, on Linux,
syslogd is not configured by default to accept syslog entries from remote systems. You can set up the
syslog server on another subnet. To do so, you also need to configure the appropriate routing for
Secure64 DNS Cache to locate the syslog server. For more information, see Configuring the Default
Gateway and Other Routes on page 252.
To add a new syslog server:

1. At the sysadmin prompt, type the following command (where <server> is the syslog
IPv4/IPv6 address or host name and [source] is an optional IPv4/IPv6 source address)
and press ENTER.
syslog <server> [source]
269
source IP address when you need to designate a specific IP address for syslog traffic, for example, to
allow traffic through a firewall.
When source is specified, if server is an IP address, source must be in the same IPv4 or
IPv6 family; if server is a host name, name resolution will query for an address of the same type
(IPv4 or IPv6) as the source. If source is not specified and server is a host name, name
resolution will query for an IPv4 (A) record, and then and IPv6 (AAAA) record.
Do not configure the same server by IP address and by domain name.
Examples:
[sysadmin@Secure64DNS]# syslog 2001:db8::1
Syslog server[0]: 2001:db8::1
[sysadmin@Secure64DNS]# syslog 10.20.0.234 192.168.127.99

Syslog server[1]: 10.20.0.234
[sysadmin@Secure64DNS]# syslog 2001:db8::2

Syslog server[2]: 2001:db8::2
[sysadmin@Secure64DNS]# syslog denverbranch

Syslog server[3]: denverbranch
[sysadmin@Secure64DNS]# syslog fcbranch

All possible syslog servers are configured
2. To define the syslog level, type the command below and press ENTER, where
<level> is the level of messages sent to the syslog server(s) as defined in Table 43 and
[entries] is the number of syslog entries to store in the local log file, from 50-10,000.
Setting [entries] to 0 disables the local log file.
loglevel <level> [entries]
270
Note The log level value you define includes all levels numerically less than the value specified. For example,
if you define level 6, the system logs levels 0 through 6. The higher the log level, the more messages that
are sent and logged
Defining a log level of 7 (LOG_DEBUG) will noticeably affect performance due to the large volume of
messages sent to syslog. Enable log level 7 only for as long as needed to capture debug information.
Table 43. Log levels
Name Level Description

LOG_EMERG 0 System is unusable
LOG_ALERT 1 Action must be taken immediately
LOG_CRIT 2 Critical conditions exist
LOG_ERR 3 Error conditions
LOG_WARNING 4 Warning conditions
LOG_NOTICE 5 Normal but significant conditions
LOG_INFO 6 Informational
LOG_DEBUG 7 Debug-level messages
Example:
[sysadmin@Secure64DNS]# loglevel 7 50
3. To define a syslog logging facility for Secure64 DNS Cache to correspond to the syslog
server configuration, type the following command and press ENTER, where
log_local# is log_local0 – log_local7 or 0-7:
logfacility <log_local#>
Example:
[sysadmin@Secure64DNS]# logfacility log_local7
[sysadmin@Secure64DNS]# logfacility 4
Note If logfacility is not defined or you use the no logfacility <log_local#> command to
remove a configured log facility, Secure64 DNS Cache logs to the system daemon facility.
271
To display the log facility settings:

• At the sysadmin prompt, type logfacility and press ENTER:
Example:
[sysadmin@Secure64]# logfacility
Syslog log facility is LOG_DAEMON (default)
To remove a syslog server:

server specifies the IP address or host name of the syslog server to remove or all
specifies removal of all configured syslog servers:
no syslog <server|all>
Example:
[sysadmin@Secure64DNS]# no syslog 192.168.127.99
Syslog server 192.168.127.99 removed
[sysadmin@Secure64DNS]# no syslog all

All syslog servers removed
To return to the saved configuration change, type revert and press ENTER.
272
Sending a User Defined or Test Syslog Message

You can use the logmsg command to send a test message or a user defined syslog message from
the sysadmin role.
To send a syslog message:
logmsg [<0-7>] [log_local#] <message>
where:
<0-7> is the optional syslog level (if not defined, the currently configured log level is
used)
log_local# is the optional logfacility (if not defined, the currently configured logfacility
is used)
message is the user defined or test message you want to send
2. The message is sent to the active syslog servers and the local syslog file in the following
format:
[APPLICATION:ADMIN] From <username>: <message>
Example:
[sysadmin@Secure64]# logmsg 4 this is a test
syslog message sent
[sysadmin@Secure64]# show syslog

Mar 12 08:32:50 Secure64: [APPLICATION:ADMIN] From testuser: this is
a test
Displaying Syslog Server Status
To display information about all active syslog servers, including run state, host address,
current log level, and facility settings:
show syslog status
Example:
[sysadmin@Secure64]# show syslog status
Level 7, Facility Default (System Daemon)
Running 2001:db8::1
Idle denverbranch (Unresolved)
The information displayed includes:

• Log level and log facility
• State and server information for each configured syslog server
273
The syslog server states are:

• Running: This is the normal status and indicates that the syslog server is running.
• Idle: The syslog server is not running because there is a connection error or a host
name resolution error.
• Connect: Connection to the syslog server is in progress.
• Lookup: Initial resolution of the syslog server host name is in progress.
• Refresh: A check for changes in the host name address is in progress.
Displaying and Exporting the Local Log File

The local log file records a portion of syslog activity as defined by the loglevel command.
You can configure the loglevel to retain from 50 to 10,000 lines of syslog entries in the local
file (see Configuring Syslog and Local Logging on page 269).
Any role in Secure64 DNS Cache can view the contents of the local file from the server’s
command line interface. To avoid tying up the command line, the system displays a maximum
of 50 entries, regardless of the number of entries stored in the local file. If you want to view
more than 50 entries, you can export the file to a different system, as described below.
To display up to the last 50 entries in the local log file:

show syslog
274
To export the local log file to another system using scp:

1. At the sysadmin prompt, type the following command and press ENTER.
export syslog [-I <eth>] [-P <port>] <user>@<host>:<file>
where:
-I <eth> specifies an optional interface
<user> is an authorized user on the target system
<host> is the target IPv4 address, [IPv6 address] in square brackets, or hostname
<file> is the target file name
2. The file is exported in ASCII format to the target system.
Examples:
[sysadmin@Secure64]# export syslog tester@192.168.127.99:mysyslog
Syslog file transfer successful.
[sysadmin@Secure64]# export syslog tester@[2001:db8:3c4d:15::abcd:1]:mysyslog

Syslog file transfer successful.
275
Adding and Removing IP Addresses for Interfaces

The following commands let you assign an IP address to an Ethernet interface or remove an IP
address from an Ethernet interface for services such as the administration console (normally
eth0), DNS, BGP, or SNMP.
The Secure64 DNS Cache server supports a total of 256 configured IP addresses. You can
configure each physical interface with multiple IP addresses and define VLAN IDs, up to a
total allocation of 256 IP addresses for the server. In addition, you can use the same IP address
for multiple services, including the console, the DNS server, BGP, SNMP, and other services.
Note If you are adding an administration console, you must also invoke the console command. See
Adding and Removing Console Interfaces on page 281.
If you are using BGP, you must stop and start the BGP service if static routes are added or deleted.
See Stopping and Starting BGP on page 320 for more information.
To specify an IP address for an interface:

or

V= the VLAN ID
interfaces)
Note You can configure each physical interface with multiple IP addresses and define VLAN IDs, up to a
total allocation of 256 IP addresses for the server. In addition, you can use the same IP address for
multiple services, including the console, the DNS server, BGP, SNMP, and other services.
276
Examples:
Configure the first IPv4 address of an interface (with no VLAN):
ifconfig eth0 192.168.12.14 255.255.255.0
Configure a second IPv4 address to the interface (with no VLAN):

ifconfig eth0.1 192.168.0.4 255.255.255.0
Configure the first IPv6 address of an interface with a VLAN ID of 12:

Configure the second IPv6 address of an interface with a VLAN ID of 12:

ifconfig eth0:12.1 2001:db8:ccc:ddd:/64
To test a configured interface:

At the sysadmin prompt, enter the ping or ping6 command for an external IP address or
hostname from the management port:, where <interface> is the ethX, ethX.I, or
ethX:V.I interface you are testing and
V= the VLAN ID
(for ping6, you can use the optional [datasize] to define the number of octets to send,
from 1-1500):
or
Example:
ping successful
[sysadmin@Secure64DNS]# ping6 eth1 2001:db8::1

ping to 2001:db8::1 on interface eth1
ping successful
277
To check for a misconfigured or disabled interface:

Use the show config command to check for an interface that is reported as
DISABLED. If an interface is DISABLED, you can remove the configuration:
— If the configuration has been activated but you have not issued the save command,
use the revert command to return to the previously saved configuration and
remove the disabled interface.
— If the configuration has already been saved, reboot the server to remove the
disabled interface. For details, see Rebooting the Secure64 DNS Cache Server on page 87.
Example:
[sysadmin@Secure64]# show config
running configuration:
ifconfig bond9 192.168.88.2 255.255.255.0
ifconfig bond9.1 192.168.89.3 255.255.255.0
ifconfig bond9.2 2001:db8:aaa:bbb1:/64
ifconfig bond9.5 192.168.86.3 255.255.255.0
ifconfig bond9.12 2001:db8:aaa:ccc1:/64 DISABLED
ifconfig eth2 192.168.110.100 255.255.255.0
ifconfig eth2.1 2001:db8:aaa:ccc2:/64
ifconfig eth3 192.168.95.86 255.255.255.0
ifconfig eth3.1 2001:db8:aaa:ccc3:/64
ifconfig lo0 192.168.130.110 255.255.255.255
console eth2
route asym
nameserver 0 192.168.127.1 6
nameserver 1 192.168.127.8 4
ntp 192.168.95.65
tz America/Denver
syslog 192.168.95.65
loglevel 0 50
nodename Secure64
No defense rules configured.
ruleactions on
nullchecksums allow
278
timeout 0
ip frag timeout 5
ip frag high 40
ip frag low 30
bondcfg bond9 eth0 eth1
bondcfg bond9 mode miimon 1000 5000
bondcfg bond9 gratarp 3
bondcfg bond9 unsolnd 3
To remove a configured interface:

1. If you remove or change a configured interface/IP address, first verify whether it is used
by services such as DNS, BGP, RADIUS, LDAP and/or as a console.
Note If the interface is currently in use by a service, you must stop the service(s) before you can remove the
configuration. To check the configuration of various services, use the show config (general system
configuration), show cachedns config (DNS configuration), show bgp config (BGP
configuration), and show authenticate config <radius | ldap > authentication
configuration commands.
If you remove or change an IP address, be sure to modify any configuration files that use the IP address
accordingly. Also verify whether any rules need to be modified or attached to different interfaces. (See
About Rate-Limiting Rules on page 227 for more information).
If the interface is configured as a console and you want to change the IP address configured for the
console, see Changing the IP Address of a Console Interface on page 282.
2. Based on the type of IP address configured, at the sysadmin prompt type the IPv4 or
IPv6 command and press ENTER:
no ifconfig <interface> <ipv4 ipaddress>
or
no ifconfig <interface> <ipv6 ipaddress>/<ipv6 prefix length>
279
Example:
[sysadmin@Secure64DNS]# no ifconfig eth0 192.168.64.1
Configuration removed
Configuring a Loopback Interface
To configure a virtual loopback interface:

• At the sysadmin prompt, type
or

lo0 or lo0.I and
for the loopback interface, 1-255)
Note You can assign a regular unicast address to a loopback interface (lo0 or lo0.I). A loopback address
(127/8, ::1/128) can only be assigned to a loopback interface, not a physical interface.
Examples:
[sysadmin@Secure64]# ifconfig lo0 10.22.0.99 255.255.255.255
[sysadmin@Secure64DNS]# ifconfig lo0.1 ::1/128

280
Adding and Removing Console Interfaces

To designate administration console connections or change the console interface, use the
console command.
Note After adding or removing a console interface, make sure to attach a rule to limit the number of SSH logins
per minute for security. For more information, see Configuring TCP Rules for SSH and DNS Traffic on
page 236.
If you are using BGP, you must stop and start the BGP service if static routes are added or deleted. See
Stopping and Starting BGP on page 320 for more information.
To enable an interface to connect to the Secure64 DNS Cache name server:

where:
<port> is the port to listen on (defaults to 22 if not defined; alternate port must be
specified when using scp to copy files to the Secure64 server, see Secure Copy on page 23
for more information)
<sessionmax> is the maximum number of simultaneous connections (from 1-255,
defaults to 5 if not defined; increasing simultaneous connections uses more memory)
<interface> is defined in the form ethX, ethX.I, ethX:V.I, or bondX, bondX.I
and
V= the VLAN ID
Example:
[sysadmin@Secure64DNS]# console eth0
eth0 console enabled
[sysadmin@Secure64DNS]# console -P 44 -S 3 eth1
To remove a console interface:

no console <interface>
Example:
[sysadmin@Secure64DNS]# no console eth3
eth3 console disabled
281
To change an existing console interface configuration, first remove the console

interface:
• At the sysadmin prompt, type the following commands and press ENTER:
no console <interface>
activate
Example:
[sysadmin@Secure64DNS]# no console eth3
eth3 console disabled
[sysadmin@Secure64DNS]# console -P 44 -S 3 eth3

Changing the IP Address of a Console Interface
To change the IPv4 address of an existing console interface:

• At the sysadmin prompt, type each command and press ENTER, where <interface>
is the ethX, ethX.I, ethX:V.I, or bondX, bondX.I interface you are changing:
no ifconfig <interface> <old ipv4 address>
activate
ifconfig <interface> <new ipv4 address> <ipv4 netmask>
activate
save
To change the IPv6 address of an existing console interface:

• At the sysadmin prompt, type each command and press ENTER, where <interface>
is the ethX, ethX.I, ethX:V.I, or bondX, bondX.I interface you are changing:
no ifconfig <interface> <old ipv6 address>/<ipv6 prefix length>
activate
ifconfig <interface> <new ipv6 address>/<ipv6 prefix length>
activate
save
282
Changing the Console Timeout

By default, Secure64 DNS Cache logs users out of SSH and serial console connections after 300
seconds (5 minutes) of inactivity. The maximum value is 3600 (one hour). To change the console
time out, use the timeout command.
Note If a user changes the console timeout setting, the change affects the current session of the user
executing the command; all other users are affected upon their next log in.
To change the SSH and serial console timeout:

timeout <seconds>
where <seconds> specifies the number of seconds of inactivity before Secure64 DNS
Cache automatically logs out of the SSH or serial console.
Example:
[sysadmin@Secure64DNS]# timeout 600
283
To disable the console timeout:

no timeout
Configuring Ethernet Bonding

Ethernet bonding is one of many terms used to describe combining multiple physical Ethernet
connections into a single virtual connection. Other terms include “Ethernet trunking” and
“channeling.” It allows failover to another Ethernet port if the link to the original active port
becomes unavailable.
The Secure64 Ethernet bonding implementation supports the active/standby mode of
operation. When the Secure64 DNS Cache server boots, it selects one bonded Ethernet port as
active; the remaining port(s) are standby. No traffic goes through the standby ports.
The server periodically examines the link status of the active port to detect failures. If the
Secure64 DNS Cache server detects a failure in the active port, a standby port is made active
and the failed active port is taken out of service. When a failover occurs, the IP addresses
associated with the bond will use the MAC address of the newly active card. To alert neighbors
and the switch of the failover, gratuitous ARPS (for IPv4) and neighbor discoveries (for IPv6)
are sent out on the newly active port.
The sysadmin role in Secure64 DNS Cache configures Ethernet bonding. Three steps are
required:
• Step 1: Configure the Ethernet bond ports
• Step 2: Configure the Ethernet bond parameters
• Step 3: Assign the configured bond interface where needed, for example, an IP address
or console
Step 1: Configure the Ethernet bond ports:

1. At the sysadmin prompt, type the following command and press ENTER.
bondcfg bond<num> <ethX> <ethY> [<ethZ>...]
where
<num> is the bond number, 0-99 (only 8 total bonds allowed)
<ethX> <ethY> are two or more physical interfaces
284
Example:
[sysadmin@Secure64]# bondcfg bond0 eth1 eth2
Step 2: Configure the Ethernet bond parameters:

1. At the sysadmin prompt, type the following command and press ENTER to configure
the link status monitoring:
bondcfg bond<num> mode miimon <polltime> <holdtime>
where
<num> is the bond number
<polltime> is the time in milliseconds to poll the state of the Ethernet link, ranging
from 100 to 5000. If not defined for an existing bond, the default is 1000.
<holdtime> is the time in milliseconds to wait before changing the link state of a
detected failure, ranging from 2x the polltime to 100x the polltime. If not defined for an
existing bond, the default is 5000. Holdtime should be a multiple of polltime.
Note After the holdtime expires, the standby interface begins initiating its startup process. This results in a
delay after the holdtime expires before the standby interface becomes fully active.
2. At the sysadmin prompt, type the following command and press ENTER to configure
the number of gratuitous ARPs and unsolicited neighbor discoveries
bondcfg bond<num> gratarp <arp>
bondcfg bond<num> unsolnd <neighbor>
where
<arp> is the number of gratuitous ARPs to send to configured IPv4 addresses on a newly
active port. The acceptable range is 0-255. If the value is 0, then ARPs are not sent. If not
defined for an existing bond, the default is 3.
<neighbor> is the number of unsolicited neighbor discoveries to send to configured
IPv6 addresses on a newly active port. The acceptable range is 0-255. If the value is 0,
then unsolicited neighbor discoveries are not sent. If not defined for an existing bond, the
default is 3.
Example:
[sysadmin@Secure64]# bondcfg bond0 mode miimon 1000 5000
285
[sysadmin@Secure64]# bondcfg bond0 gratarp 3

[sysadmin@Secure64]# bondcfg bond0 unsolnd 3

Step 3: Assign the bond virtual interface where needed:

You can substitute the bond interface for an Ethernet interface in the server configuration, for
example, in an IP address or console configuration.
• To assign the bond interface to an IP address, at the sysadmin prompt, type the
following command and press ENTER:
ifconfig <bond_interface> <ipv4 address> <ipv4 netmask>
or
ifconfig <bond_interface> <ipv6 address>/<ipv6 prefix length>
where bond_interface is defined in the form:

bondX + bondX.I
addresses for each bond interface, 1-11)
Note You can configure up to 12 IP addresses for a single bond interface.
Examples:
[sysadmin@Secure64]# ifconfig bond0 192.168.127.180 255.255.255.255
[sysadmin@Secure64]# ifconfig bond1:12 192.168.95.180

255.255.255.255
286
Viewing bond status and configuration
To view the bond interface status:

show bond<num> status
where
Example:
[sysadmin@Secure64]# show bond0 status
bond0 mode miimon poll 1000 down 5000 gratarp 3 unsolnd 3
interface eth1 link up status active
interface eth2 link up status standby
To view the bond interface configuration:

show bond<num> config
where
Example:
[sysadmin@Secure64]# show bond0 config
bondcfg bond0 eth1 eth2
bondcfg bond0 mode miimon 1000 5000
bondcfg bond0 gratarp 3
bondcfg bond0 unsolnd 3
287
Changing a Bond Configuration

If you want to change the physical Ethernet interfaces associated with a bond interface, you
must remove the bond interface and then reconfigure it. See Removing a Bond Configuration on
If you are changing parameters for an existing bond interface, the system may prompt you to
use the activate and save commands, then reboot the system. For details about rebooting, see
Rebooting the Secure64 DNS Cache Server on page 87.
Removing a Bond Configuration
To remove a configured bond interface:

1. Verify whether the interface is used by services such as DNS, BGP, LDAP and/or as a
console.
Note If the interface is currently in use by a service, you must stop the service(s) before you can remove the
configuration. To check the configuration of various services, use the show config (general
system configuration), show cachedns config (DNS configuration), show bgp config
(BGP configuration), and show authenticate config <ldap | radius >
configuration commands.
If you remove or change an IP address, be sure to modify any configuration files that use the IP
address accordingly. Also verify whether any rules need to be modified or attached to different
interfaces. (See About Rate-Limiting Rules on page 227 for more information).
If the interface is configured as a console and you want to change the IP address configured for the
console, see Changing the IP Address of a Console Interface on page 282.
no bondcfg bond<num>
where <num> is the bond number
288
Example:
[sysadmin@Secure64]# no bondcfg bond3
Customizing Login with an Issue File (optional)

If you want Secure64 DNS Cache to display certain information to users when they login from
the SSH or serial console, you can use an issue file. The file is a plain text file that displays
during login, prior to the Secure64 DNS Cache command line prompt. It is managed by a user
assigned to the loginadmin role.
Note The issue file must be plain text. Escape characters and other non-text character sequences are not
recognized.
To edit the default issue file, use scp to copy a file you created on another system or edit the
default file directly on the Secure64 DNS Cache server.
To use scp to copy an issue file created on another system:

1. Create the issue file in a text editor on another system.
2. Use the scp command to copy the issue file to the Secure64 DNS Cache system as
follows:
scp [-P <port>] issue <user>@<host>:/loginadmin
where:
289
To edit the default file on the Secure64 DNS Cache server:

1. Login to Secure64 DNS Cache as a user assigned to the loginadmin role.
2. Type enable loginadmin and press ENTER.
3. Use the built-in editor to edit the issue file in the default loginadmin directory. (For
details about using the Secure64 DNS Cache editor, see About the Text Editor on
page 89.)
Setting the Chassis Polling Interval

The Secure64 DNS Cache server can report status information about hardware, including
temperature, voltage, fan, chassis intrusion, power supply, and power redundancy changes. The
information is available through the show sensors command (see Displaying Hardware Sensor
Information on page 370 ), SNMP traps (see Secure64 Chassis Trap Type Categories and Notifications
on page 412), and syslog messages. Use the chassispoll command to set the interval for
checking the hardware sensors.
Note To generate syslog messages for the power supply and other sensor changes, you must set a chassis
polling interval.
To configure the chassis polling interval:

chassispoll <seconds>
where <seconds> is the polling interval, between 1 second and 86400 seconds (1 day)
Example:
[sysadmin@Secure64]# chassispoll 120
To disable chassis polling:

no chassispoll
290
Connecting a VGA Monitor (optional)

You can connect a VGA monitor to a VGA port on the HP Integrity server to view current
system information, if desired. Information includes Secure64 DNS Cache build version
information, CPU and I/O processor load statistics, and total system uptime since boot.
Configuring RAID
You can configure the Secure64 DNS Cache server with multiple drives for RAID. This
configuration is useful for servers located in harsh or high-availability environments. The RAID
configuration allows complete disk redundancy so that in the event of a disk failure, the system
continues to function. The malfunctioning unit can be hot-swapped with a new unit.
Note that when multiple disks are installed, the server’s default configuration does not
automatically enable disk mirroring. The HP Integrity Installation Guide provides instructions for
configuring RAID.
Accessing the utilities necessary for RAID configuration differs based on whether you are
configuring RAID prior to or after installing the Secure64 DNS Cache software:
• RECOMMENDED: Prior to installing Secure64 DNS Cache software. The HP
Integrity server powers up to the EFI (Extensible Firmware Interface) console. From the
console menu, select the EFI shell and enter drvcfg –s to begin the RAID
configuration. Refer to HP’s documentation for additional details.
• After installing Secure64 DNS Cache software. To configure RAID after Secure64
DNS Cache is installed and running, you must backup the Secure64 DNS Cache software
and data, configure RAID, and re-install the Secure64 DNS Cache software and data. For
assistance with this process, contact Secure64 support at support@secure64.com.
291
Starting in Safe Mode

To prevent unsolicited reboot cycles from occurring, a safe mode feature and commands are
available to help manage startup issues. Safe mode allows you to gather information about the
system as well as modify system and application configurations that potentially initiate startup
issues.
About Safe Mode

The Secure64 DNS Cache server tracks information about solicited and unsolicited system
reboots. An unsolicited reboot can occur from a manual reset, a power failure, or other issue. If
the server autostart cycle counter detects an occurrence of an unsolicited reboot in a 45-minute
time period, the counter is incremented. When the counter reaches three such occurrences, the
system automatically boots into safe mode. A banner displays on the console and related
messages are written to syslog.
While in safe mode, only serial console access to the server is available. (For details about using
the serial console through the HP Integrity iLO, see Connecting and Logging into the iLO Console on
page 61.) In addition, processes such as DNS, RADIUS, LDAP, BGP, and SNMP are not
started.
The following sections provide details about viewing the startup status, troubleshooting the
server after it boots into safe mode, and resetting the startup status counters.
Viewing the Startup Status

To view the autostart status information:
1. At any prompt, type the following command and press ENTER.
show autostart status
2. The following information displays:

State: indicates whether the system processes started or autostart was interrupted
causing the system to boot into safe mode, followed by the date/time of the last start or
reboot.
Autostart cycle counter: counts the number of times an unsolicited reboot occurs in a
45-minute time period. When the counter reaches three such occurrences, the system
automatically boots into safe mode. This number is reset after a reboot from safe mode
or by using the reset autostart cycle-counter command.
Number of reported reboots: the total number of reboots since the last time the
history was reset using the reset autostart history command.
Number of requested reboots: the total number of reboots initiated from the
command line using the reboot command, since the history was last reset using the
reset autostart history command.
Number of requested halts: the total number of times that the halt command has
been issued from the command line since the history was last reset using the reset
autostart history command.
292
If the system is functioning normally, then the total number of requested reboots and
halts should equal the number of reported reboots.
Example (normal start):

[view@Secure64]> show autostart status
System processes started on Thu Oct 6 14:03:45 2011
Autostart cycle counter : 0
Number of reported reboots : 4
Number of requested reboots : 2
Number of requested halts: 2
Example (safe mode start):

[view@Secure64]> show autostart status
Process autostart interrupted, boot into safe mode on Tue Oct 11
10:52:06 2011
Autostart cycle counter : 3
Number of reported reboots : 26
Number of requested reboots : 14
Number of requested halts: 2
Troubleshooting a Safe Mode Reboot

If the server autostart cycle counter detects sufficient unsolicited reboots, the system
automatically boots into safe mode. When a safe mode reboot occurs:
• The console displays output similar to the following:
Software and system protected by one or more patents and patents
pending
Found drive sdb1
Found drive sdb2
buffer cache at 5%
root is on sdb2
/boot is on sdb1 file system maintenance in progress ... done
Cryptographic module is running.
!!!! AUTOSTART INTERRUPTED... SYSTEM BOOTING INTO SAFE MODE !!!!

username:
• Processes such as DNS, RADIUS, LDAP, BGP, and SNMP are not started.
• Configured networking is disabled.
• Access to the server is available only through the serial console.
293
To troubleshoot a safe mode reboot:

1. Using the serial console, login as a user assigned to the sysadmin role. (For details about
using the serial console through the HP Integrity iLO, see Connecting and Logging into the
iLO Console on page 61.)
Note If you use RADIUS or LDAP, the users you originally created to configure the Secure64 DNS Cache
server are available when RADIUS or LDAP is disabled.
2. At the view prompt, type enable sysadmin and press ENTER.

3. Use the following options to troubleshoot the cause of the safe mode reboot and
restore the system configuration:
— To display the most recent syslog messages, type show syslog and press ENTER.
— To display the saved system configuration, type show saved and press ENTER.
— To revert to the saved configuration, type revert and press ENTER. (This loads the
saved system configuration and enables networking so you can export the local
syslog file and make configuration changes if needed.)
— To export the contents of the syslog file after using the revert command, type the
following command and press ENTER:
export syslog [-I <eth>] [-P <port>] <user>@<host>:<file>
where:
-I <eth> specifies an optional interface
<user> is an authorized user on the target system
<host> is the target IPv4 address, [IPv6 address] in square brackets, or hostname
<file> is the target file name
— Investigate and/or modify the system configuration or DNS configuration and
related files. You can use scp to copy the DNS configuration file and any related
include files to another system for editing or troubleshooting:
scp [-P <port>] <user>@<Secure64_host>:/cachednsadmin/<file> <target>
where:
<user> is a Secure64 user account assigned to the cachednsadmin role
<Secure64_host> is the IPv4 address, [IPv6 address] in square brackets, or
hostname of the Secure64 DNS Cache administrative console
<file> is the configuration file to copy
<target> is the destination for the file
294
4. After you revert the system configuration and complete troubleshooting steps, at the
sysadmin prompt, type reboot and press ENTER to reset the autostart cycle counter and
allow the system to boot normally.
Resetting Startup Status Information

The system collects autostart safe mode status information and reboot history. You can use the
reset command to clear the autostart cycle counter or clear the reboot history. (For details about
the counter, reboot history, and the show autostart status command, see Viewing the Startup
Status on page 292.)
To reset the autostart cycle counter:

• In the sysadmin role, type reset autostart cycle-counter and press ENTER.
Example:
[sysadmin@Secure64DNS]# reset autostart cycle-counter
autostart cycle counter successfully reset to zero
To reset the reboot history:

• In the sysadmin role, type reset autostart history and press ENTER.
Example:
[sysadmin@Secure64DNS]# reset autostart history
autostart history successfully reset to zero
295
Backup and Recovery Tasks

To completely back up the Secure64 DNS Cache system, you must back up a number of
different items, such as the DNS data, DNS configuration file, and system configuration.
Table 44 provides a summary of backup tasks.
Table 44. Overview of backup tasks
Item Secure64 Role Method Frequency References

Secure64 DNS Contact Secure64 DNS
Not applicable Download NA
Cache software Cache support
System, BGP,
RADIUS, and Whenever system
Backing Up and Restoring
LDAP backup scp command configuration changes
System Files on page 297
configuration (if occur
applicable)
DNS data and Whenever DNS data
configuration, and/or DNS/BFD Backing Up and Restoring DNS
cachednsadmin scp command
BFD configuration changes Information on page 298
configuration occur
Whenever SNMP
SNMP Backing Up SNMP
snmpadmin scp command configuration changes
configuration Information on page 405
occur
The steps for recovering your system depend on the type of failure that occurs. For example,
the software may become corrupt in the case of a power failure, static electricity, or a power
surge. Recovery is also necessary if your system experiences a hardware failure.
The following sections describe backing up and restoring system configuration files and
backing up and restoring DNS information.
296
Backing Up and Restoring System Files

A user account assigned to the backup role performs system backups using scp.
Note This procedure backs up the Secure64 DNS Cache system configuration as seen in the show
config command. It also backs up user and role information, BGP configuration information (if
enabled), RADIUS or LDAP configuration information (if enabled and running), and SDP (Secure Data
Protection) information.
To backup the system files (excluding DNS-related files):

• Type the following command at the remote system and press ENTER:
scp [-P <port>] <user>@<Secure64_host>:/backup/files <destination>
where:
<user> is the user account assigned to the backup role
<destination> is the destination for the backup file
Secure64 DNS Cache creates a file called Secure64DNS.bak that contains the backup file
contents.
To restore the system files (excluding DNS-related files):

1. Make sure all user accounts are logged off Secure64 DNS Cache. Use the who command
in Secure64 DNS Cache view mode to verify all accounts are logged off, then exit the
system.
2. Type the following command at the remote system and press ENTER:
scp [-P <port>] Secure64DNS.bak <user>@<Secure64_host>:/backup/files
where:
<user> is the user account assigned to the backup role
3. Reboot the Secure64 DNS Cache server. See Rebooting the Secure64 DNS Cache Server on
page 87.
297
Backing Up and Restoring DNS Information
To back up DNS information, use the scp command at the remote system as follows:
scp –r [-P <port>] <user>@<host>:/cachednsadmin/* <backup_dest>
where:
<user> is the user account assigned to the cachednsadmin role
<backup_dest> is the destination for the backup files
To restore DNS information, use the scp command at the remote system as follows:
scp –r [-P <port>] <backup_dest>/* <user>@<host>:/cachednsadmin/
where:
<backup_dest> is the location of the backup files,
<user> is a user account assigned to the cachednsadmin role, and
298
System Recovery
The steps for recovering your system depend on the type of failure that occurs. For example, the
software may become corrupt in the case of a power failure, static electricity, or a power surge.
Recovery is also necessary if your system experiences a hardware failure.
Table 45 identifies different types of failures, the recommended recovery actions, and
corresponding references for more information.
Table 45. Failure scenarios and recovery actions
Failure Type Recovery Actions Corresponding Reference(s)

1. Obtain replacement HP Integrity server 1. HP Integrity server documentation
System
2. Move TPM and disk to new system 2. HP Integrity server documentation
1. Install new TPM 1. HP Integrity server documentation
TPM
2. Re-install software 2. Secure64 customer support
1. Install new disk 1. HP Integrity server documentation
Disk
System + TPM 1. Move disk to new system 1. HP Integrity server documentation
1. Move TPM to new system with new disk 1. HP Integrity server documentation
System + Disk
1. Install new TPM 1. HP Integrity server documentation
TPM + Disk 2. Install new disk 2. HP Integrity server documentation
System + TPM + 1. Obtain replacement HP Integrity server 1. HP Integrity server documentation
Disk 2. Re-install software 2. Secure64 DNS customer support
Viewing the Cryptographic Module Status

The Secure64 cryptographic module handles cryptographic functions for the DNS server. In the
securityadmin role, the status command reports the status of the cryptographic module, in
accordance with FIPS 140-2 Level 2 certification requirements (this is not normally required).
When the server has the CEM enabled, multiple cryptographic module instances (for example 1,
2, or 3) are also enabled. Non-CEM systems have a single CM instance (1). You can view the
status of one or more cryptographic modules using the status command.
To check the cryptographic module status:

• At the securityadmin prompt, type the following command and press ENTER:
status [all|#]
where:
— all displays the state of all cryptographic module instances
— # displays the state of the given cryptographic module instance (1, 2, 3, etc.)
— no parameters displays the state of cryptographic module instance 1
299
The possible states are:

• POWERUP (the cryptographic module is starting)
• INITIALIZE (the system is initializing the cryptographic module)
• READY (the cryptographic module is running)
• BUSY (the cryptographic module is performing cryptographic operations)
• FAILED (the cryptographic module is shut down due to an error or event such as a
chassis intrusion). If this occurs, SSH connectivity is no longer available. Login via the
serial console, then stop and reboot the server. You can also check syslog messages for
additional information. If the problem continues after rebooting, contact secure64
customer support.
If the cryptographic module shuts down due to an error or event such as a chassis intrusion,
the following message may display. See the FAILED state above for the appropriate actions to
take.
Cryptographic module has been shut down
Examples:
[securityadmin@Secure64]# status
Cryptographic module is in the Ready state.
[securityadmin@Secure64]# status all

Cryptographic module #1 is in the Ready state.
Cryptographic module #2 is in the Powerup state.
[securityadmin@Secure64]# status 2
Upgrading the Software

Secure64 will periodically release software upgrades. Unless otherwise directed, use the
following procedure to upgrade your system. If the version of the currently installed software is
more than two minor versions prior to the version you are upgrading to, consult
support@secure64.com for guidance on any additional steps that may be required.
To download the Secure64 DNS Cache upgrade from the Secure64 license server:
1. Using a web browser, go to the Secure64 license server at
https://download.secure64.com
2. In the Upgrade section of the Download Server web page, enter your Secure64 license
key (omitting dashes and spaces) in the License Key field and click Download.
300
Note If you do not know your license key information, see Determining the Secure64 DNS Cache License Key
on page 302.
3. When the Thank You web page displays, click the link provided to download the upgrade
files to a location where you can unzip, untar, and scp them to the Secure64 DNS Cache
server. For Windows systems use a utility that recognizes .tar.gz files, such as WinZip.
For Linux/UNIX systems, use the tar command, for example:
tar –xvzf Secure64*.tar.gz
Note The unzipped, decompressed filenames are s64dns and secure.efi. To successfully upgrade
your system, an upgrade user must scp both the s64dns and secure.efi files to the Secure64
DNS Cache server. You can copy the files one at a time or together as shown below.
4. Use scp to copy the upgrade files to the Secure64 DNS Cache server:
scp -P <port> s64dns secure.efi <upgrade_user>@<Secure64_host>:/upgrade/
where:
upgrade_user is a user account assigned to the upgrade role
Secure64_host is the Secure64 DNS Cache server IPv4 address, [IPv6 address] in
square brackets, or hostname.
To install the Secure64 DNS Cache upgrade files:
! WARNING Before issuing the upgrade command, ensure that the DNS server, BGP (if applicable), and SNMP
(if applicable) are stopped. To stop the DNS server, login as a user with the cachednsadmin role
and enter stop cachedns. To stop BGP, login as a user with the bgpadmin role and enter stop bgp.
To stop SNMP, login as a user with the snmpadmin role and enter stop snmp.
1. Log into Secure64 DNS Cache with a user account assigned to the upgrade role.
2. Enter enable upgrade to change from view mode to upgrade mode.
3. Type upgrade and press ENTER:
[upgrade@Secure64DNS]# upgrade
Current executable backed up
Upgrade complete. Reboot to run.
301
4. Type reboot and press ENTER to restart the Secure64 DNS Cache system.
[upgrade@Secure64DNS]# reboot
are you sure? (y/n)

rebooting. . .
5. If you want to verify the new system version, log into Secure64 DNS Cache view mode
and enter the version command.
[cachednsadmin@Secure64DNS]# version
Secure64 DNS Cache 3.1.0 B (ZX-2) built Dec 2 2013 16:40:36 (4.3.1)
Reversing a Software Upgrade
To rollback a Secure64 DNS Cache upgrade:

3. Type rollback and press ENTER:
[upgrade@Secure64DNS]# rollback
Previous versions of s64dns and secure.efi restored. Reboot to run.
4. Enter reboot to restart the Secure64 DNS Cache system.

[upgrade@Secure64DNS]# reboot
are you sure? (y/n)
rebooting. . .
5. If you want to verify that the system version has changed, log into Secure64 DNS
Cache view mode and enter the version command.
Determining the Secure64 DNS Cache License Key

The License Key is a 20-character string included on the original installation CD you received
when you purchased the software. If you cannot locate the CD, use the information below to
locate the License Key information.
To display your Secure64 DNS Cache License Key:

3. Type license and press ENTER.
Example:
[upgrade@Secure64DNS]# license
4712CJ80000012345678
302
Chapter 8. Enabling BGP for Anycast
Overview
BGP (Border Gateway Protocol) is a dynamic routing protocol. It allows two or more collections
of networks, known as autonomous systems, to exchange routing information. An autonomous
system (AS) is a collection of networks under a common administration and routing strategy.
The routing information maintained by BGP is dependent upon the routing style enabled for the
Secure64 DNS server. If you enable symmetrical routing, you can use BGP to update outbound
routing information. If you enable asymmetrical routing, BGP can update inbound and outbound
routing information. For more details about symmetrical and asymmetrical routing, see Configuring
In-Bound Traffic Routing Style on page 255.
You can also use BGP to implement an anycast IPv4 or IPv6 addressing scheme. In the context
of the Secure64 DNS Cache server, an anycast address is an IPv4 or IPv6 addressing technique
that assigns the same IP unicast address to multiple hosts. Routes are configured accordingly so
that queries sent to the anycast address go to the topologically closest server.
When combined with BGP, anycast routing can provide DNS servers with:
• Load distribution
• Increased reliability
• Decreased latency
• Localization of DoS attacks and distributed response to DDoS attacks
As an example of anycast and BGP for DNS, consider the fictitious company, example.com,
shown in Figure 16. The company’s DNS name server is dns.example.com, which resolves to
the IP address 1.2.3.4. The company has configured a DNS server in Argentina and another in
Australia using this anycast address.
303
Figure 16. BGP and anycast example
The routers in Argentina direct queries from clients in Argentina to the server in Argentina,
and the routers in Australia direct the queries from clients in Australia to the server in Australia.
To do this, the DNS server in Argentina announces an anycast address route to its BGP
neighbors in Argentina, and the DNS server in Australia announces a route to the same anycast
address to its BGP neighbors in Australia. Normal Internet routing sends the traffic to the
correct place.
An anycast cloud is a group of servers that share a service address and routing information. In
the example, the Argentina and Australia servers are in the same anycast cloud and the service
address is 1.2.3.4. If one of the DNS servers in the anycast cloud goes down, the route to its
address is withdrawn from the cloud. Queries directed to that server are redirected to the next
topologically available server.
Note For an additional level of failover protection, best practices for anycast DNS server operations indicate
a need for two separate overlapping clouds of anycast servers.
304
About BGP and Secure64 DNS Cache

The BGP protocol lets network devices exchange information about Internet routes. These
devices are known as BGP speakers, and the devices a BGP speaker exchanges information with
are called BGP neighbors. You can configure the Secure64 DNS Cache server to act as a BGP
speaker so that it announces the IP address of your DNS name server and learns IP routes for the
configured BGP neighbors. To do this, you define BGP information and neighbors in a Secure64
DNS BGP configuration file.
Secure64 DNS can also maintain BGP UPDATE information, routing tables, and forwarding
tables. It includes UPDATE filtering options that you can define in the BGP configuration file.
When configured, Secure64 DNS announces a list of local addresses to its BGP neighbors at
startup. In addition, commands in Secure64 DNS let you withdraw and announce specific IP
addresses to one or more of the configured BGP neighbors. A BGP instance on the Secure64
server provides its neighbors routing changes as appropriate.
Note Secure64 DNS Cache also supports bidirectional forwarding detection (BFD). BFD is often used in
conjunction with BGP because it typically detects failures faster than BGP. For details about
implementing BFD, see Using BFD on page 388.
Memory Requirements
BGP requires a minimum of 1 MB of memory on the Secure64 DNS Cache server. In addition,
for each BGP neighbor configured, the server requires approximately 125 MB of memory. To
determine the available memory when the server is running, use the memstat command as
described in Displaying Available Memory, Physical Memory, or Drive Space on page 368.
BGP Message Types

BGP uses four types of messages to communicate routing information:
• OPEN messages open a BGP communications session between neighbors and is the
first message sent by each side after a connection is established.
• UPDATE messages provide routing updates to other BGP systems, allowing Secure64
DNS and BGP-enabled routers to construct a consistent view of the network topology.
• NOTIFICATION messages indicate when an error condition is detected. Notifications
close an active session.
• KEEPALIVE messages notify BGP peers that a device is active. Keep-alives are sent
often enough to keep the sessions from expiring.
TCP MD5 Signatures

To ensure BGP traffic is coming from a known neighbor, as opposed to a spoofed address,
Secure64 DNS Cache also supports the TCP MD5 signature option for BGP. RFC 2385
describes the protection of BGP sessions via the TCP MD5 signature option.
305
Defining the BGP Configuration

The following sections describe how to configure the Secure64 DNS Cache server for BGP.
For more information about using anycast to route DNS queries, refer to RFCs 1546, 2101,
2181, and 3258 and the Carnegie Mellon resources for deploying IP anycast at
http://www.net.cmu.edu/pres/anycast.
To configure BGP on the Secure64 DNS name server, you must specify the BGP parameters in
a text file named bgp.conf. The file is stored in the root directory of the Secure64 DNS
bgpadmin role. A user account that needs access to BGP commands and configuration must be
assigned to the bgpadmin role.
Format and Rules

The configuration file bgp.conf is a text file that defines BGP configuration information and
neighbors for the Secure64 DNS name server. It is a subset of the OpenBGPD configuration
(www.openbgpd.org). Syntax and rules are as follows:
• The file must contain a global section and at least one neighbor section. It can also
contain a group section and filtering rules:
— Global section: The global section contains information that applies universally,
such as the router ID.
— Group section: The optional group section lets you define information that applies
to a group of BGP neighbors.
— Neighbor section: The neighbor section configures information related to the
Secure64 DNS Cache server’s BGP neighbors. You can configure multiple
neighbors in one bgp.conf configuration file.
— Filtering rules: Filtering rules allow or deny specific BGP UPDATE messages
coming from or going to BGP neighbors.
• BGP automatically determines the interfaces to listen on. (OpenBGPD includes a
listen on directive for historical configurations. The directive is not required in the
Secure64 implementation).
• Quotation marks are required for strings.
• Variables/macros are allowed; define with variable_name=value and call with
$variable_name
• Curly brackets { } start and end group sections and neighbor sections.
• Neighbors defined by a group must be listed within the group’s curly brackets.
• IPv4 and IPv6 information must be defined in different neighbor sections and cannot
share local-address, neighbor, or announce prefix attributes.
306
• For complete descriptions of the global configuration parameters, see Global BGP
Configuration Parameters on page 309.
• For descriptions of the group and neighbor configuration parameters, see Group and
Neighbor BGP Configuration Parameters on page 310.
• For descriptions of UPDATE filtering, see UPDATE Filter Rules on page 311.
Below is an example bgp.conf file that defines a group with two neighbors and UPDATE
filtering rules:
# global configuration
autostart yes
AS 65001
router-id 1.2.3.4
holdtime 180
holdtime min 30
route-collector no
# neighbors and peers

group "AS65001 peers" {
remote-as 65001
announce prefix 4.3.2.0/24
local-address 10.99.4.2
neighbor 10.0.0.1 {
descr "AS 65001 peer 1"
set localpref 200
tcp md5sig password neSR3s77pY
}
neighbor 10.0.0.2 {
descr "AS 65001 peer 2"
}
}
# filter out prefixes longer than 24 or shorter than 8 bits
deny from any
allow from any prefixlen 8 – 24
# do not accept a default route
deny from any prefix 0.0.0.0/0
# filter bogus networks
deny from any prefix 10.0.0.0/8 prefixlen >= 8
307
The example below is a mixed IPv4/IPv6 configuration:
Note IPv4 and IPv6 information must be defined in different neighbor sections and cannot share local-
address, neighbor, or announce prefix attributes.
# macros
box=192.168.89.250
ipv6addr=2001:db8:3c4d:15::abcd:2
# global configuration
autostart no
AS 65000
router-id 1.2.3.4
holdtime 180
holdtime min 30
route-collector no
# neighbors and peers
group "AS65001 peers" {
remote-as 65001
neighbor 2001:db8:3c4d:15::abcd:3 {
descr "AS 65001 peer 1 (terminus IPv6)"
local-address $ipv6addr
announce prefix 2001:db8:3c4d:15::/64
announce prefix 2001:db8:3c4d:15::abcd:8/128
announce prefix 2001:db0::1/64
}
neighbor 192.168.250.1 {
descr "AS 65001 peer 2 (gateway IPv4)"
local-address $box
}
}
308
Global BGP Configuration Parameters

The global configuration parameters describe settings that pertain to the entire instance of BGP
on the Secure64 DNS server. Table 46 lists the global parameters:
Table 46. BGP global configuration section
Clause Description Example(s)

AS <as-number> Set the local autonomous system number to as-number.
If you do not require a public AS number, use an AS
number reserved for private use, in the range from 64512
to 65535. AS 65001
If you need a public AS number, consult the Regional
Internet Registry (RIR) for North America, ARIN web site
at: www.arin.net.
router-id <id-number> Set the router ID to an IPv4-style address to use for the
BGP identifier. The address must be local to the Secure64
DNS Cache server. If not given, the BGP identifier is
determined as the biggest IP address assigned to the router-id 10.0.0.1
local machine. (Note: The router-id is not designed or
intended to accept an IPv6-style address.)
autostart <yes|no> If autostart it set to yes, then BGP automatically starts
when the Secure64 DNS Cache server boots. If autostart
is set to no, then BGP is not automatically started. You
can use the command start bgp to start BGP manually.
The default setting is no.
Note: Configure DNS to start automatically if you
autostart yes
configure BGP to start automatically.
To automatically start BGP when the DNS server starts
and automatically stop BGP when the DNS server stops,
use instead the auto-bgp: yes attribute in
cache.conf. See Configuring Basic Server Attributes
on page 98 for more information.
holdtime <seconds> Set the holdtime in seconds. Neighboring BGP systems
negotiate the holdtime used when establishing a
connection. Each neighbor announces its configured
holdtime; the smaller value is agreed upon.
holdtime 120
The holdtime is reset to its initial value when a
KEEPALIVE or an UPDATE message is received from a
BGP neighbor. If the holdtime expires, the session is
dropped. The default value is 90 seconds.
holdtime min <seconds> Defines the minimum holdtime value in seconds. The
value for seconds must be 3 or greater.
The holdtime negotiated between Secure64 DNS Cache holdtime min 30
and its BGP neighbors must be greater than or equal to
this value.
log updates Log received and sent UPDATE messages to syslog. The
default is not to log updates.
log updates
WARNING: Configuring log updates can generate a large
amount of syslog traffic.
route-collector <yes|no> When set to yes, the route selection process is not
route-collector no
operable. The default is no, which enables route selection.
309
Group and Neighbor BGP Configuration Parameters

For BGP, Secure64 DNS Cache establishes TCP connections to other BGP speakers known as
neighbors. Each neighbor is specified by a neighbor section to define properties specifically for
that neighbor. Neighbors can be placed in an optional group section that defines shared
configuration parameters. The clauses for neighbor configurations are listed in Table 47.
Table 47. BGP group and neighbor configuration section
Clause Description Example

announce prefix <IPv4|IPv6> Configure the Secure64 DNS Cache
IPv4 address/prefix or IPv6 address/
prefix to announce to neighbors. announce prefix 192.168.24.0/24
You can list multiple announce announce prefix 2001:db8:aaa:bbb:/64
prefix clauses per neighbor or
group.
descr <string> Add a description. The description is
used when logging neighbor events,
in status reports, and as a reference
for specifying neighbors. descr “denver branch”
You can list one descr clause per

neighbor.
set localpref <number> Set the local preference AS path
attribute for BGP speakers in the
same AS. The local preference is
included in internal BGP UPDATE
messages to help determine the
degree of preference for external set localpref 200
routes. A larger number indicates a
higher preference.
If not defined, a local preference of
100 is assumed.
holdtime <seconds> Configure the holdtime in seconds.
Defaults to the holdtime from the
holdtime 120
global section, if not defined in the
neighbor or group section.
holdtime min <seconds> Configure the minimum holdtime
value in seconds. Defaults to the
holdtime min from the global section, holdtime min 60
if not defined in the neighbor or group
section.
local-address <ipaddress> Configure the IPv4 or IPv6 address
for the source address when local-address 198.162.27.11
Secure64 DNS Cache initiates the
TCP connection to the neighbor local-address 2001:db8::1
system.
310
remote-as <as-number> Configure the AS number of the BGP

remote-as 65002
neighbor.
tcp md5sig <password|key> <secret> Enable TCP MD5 signatures per
RFC 2385. The shared secret can be tcp md5sig password E274f6b4
a password or hexadecimal key. Use tcp md5sig key
the identifier password or key f3870be274f6c49b3e31
depending on the type of secret.
UPDATE Filter Rules

Secure64 DNS Cache can allow or deny BGP UPDATES based on prefix or AS path attributes.
You can also allow or deny UPDATES based on filter rules. For each UPDATE, filter rules are
evaluated in the order listed in the bgp.conf configuration file. The last matching filter rule for a
specific UPDATE determines whether Secure64 DNS Cache allows or denies the UPDATE.
Note Filter rules do not support IPv6 addresses.
Syntax
List filter rules in the bgp.conf configuration file using the following syntax:
<action> <from|to> <peer> [parameter1] [parameter2] [...]
<action>
allow Pass the UPDATE
deny Block the UPDATE
match Apply the filter set without affecting the filter decision
<from|to>
from Apply the rule to incoming UPDATES
to Apply the rule to outgoing UPDATES
<peer>
any Evaluate the rule for any neighbor
<ipaddress> Evaluate the rule for neighbors that match the defined IP address
group <descr> Evaluate the rule for neighbors in the defined group
[parameter]
See the following section.
311
Filter Parameters
You can use one or more parameters to define the rules to apply to UPDATES. An UPDATE
always comes from or goes to one neighbor. Rules are applied to the UPDATE packets that
match the rule attributes.
Note that you do not need to define a parameter. Examples of rules that do not include a
parameter include:
deny from any
allow to any
allow from 251.28.16.2
Table 48 describes the available parameters and provides example rules that use each parameter.
Table 48. BGP filter rule parameters
Parameter
<as-type> <as-number> Applies only to UPDATES where the AS path matches the defined
<as-type> and <as-number>.
deny from any AS 1
For <as-type>, use the options below:
deny from any source-as 2 AS: The <as-number> matches any part of the AS
source-as: The <as-number> matches the rightmost AS number
transit-as: The <as-number> matches any except the rightmost AS
number
prefix <ipaddress>/<length> Applies to UPDATES for the specified IPv4 prefix.
Note: You can specify multiple <ipaddress>/<length> entries
separated by commas or whitespace, if enclosed in curly brackets.
deny from any prefix 192.168.0.0/16 You can also specify macros for multiple lists.
prefixlen <range> Applies to UPDATES for IPv4 prefixes where the defined prefix length
matches.
allow from any prefixlen 8 - 24
Use the following operators to define the prefix length range:
deny from any prefix 10.0.0.0/8 prefixlen >= 8 = equal
!= not equal
allow from any prefix 10.0.0.0/8 prefixlen > 16
< less than
> greater than
<= less than or equal to
>= greater than or equal to
- range, including the boundaries in the range
>< except the range
Note: You can combine prefixlen with the prefix parameter.

quick For UPDATES matching the filter rule, treats the rule as the last
matching rule and subsequent rules are skipped.
allow quick from 192.168.1.221
312
BGP Configuration Preparations

To configure BGP, you need information about the Secure64 DNS Cache system’s BGP
neighbors. Interfaces must also be configured for BGP traffic and the DNS server.
Interfaces for BGP and Anycast

You can use an existing interface or configure a new interface for BGP services. Depending on
your network configuration, you may need a physical unicast interface for BGP services and a
virtual loopback interface for the shared anycast IP address. This avoids ARP conflict errors and
allows multiple DNS servers on the same physical network to respond to DNS queries on the
same set of anycast addresses.
To view your current system configuration, which includes configured interfaces and IP
addresses:
• Type show config at the bgpadmin prompt, and press ENTER.
Example:
[bgpadmin@Secure64DNS]# show config
ifconfig eth0 192.168.95.99 255.255.255.0
ifconfig eth1 192.168.127.99 255.255.255.0
console eth0
route default 10.81.0.2
route sym
nameserver 0 192.168.95.95 4
ntp 2001:db8::1
tz MST7MDT
syslog 192.168.95.95
loglevel 5 75
nodename Secure64DNS
rule actions enabled
timeout 300
ip frag timeout 5
ip frag high 40
ip frag low 30
313
If you want to configure additional interface(s) for BGP services:

• At the sysadmin prompt, type the following and press ENTER:
or

V= the VLAN ID
interfaces)
Example:
[sysadmin@Secure64]# ifconfig eth1.2 10.20.0.99 255.255.255.0
To configure a loopback interface:

• At the sysadmin prompt, type

lo0 or lo0.I and
for the loopback interface, 1-255)
Example:
[sysadmin@Secure64]# ifconfig lo0 10.22.0.99 255.255.255.255
314
BGP Configuration Checklist

Refer to Table 49 for a checklist of information required for BGP configuration.
Table 49. BGP preparations
Description Corresponding BGP

Completed Value(s) configuration clause
Secure64 DNS Cache AS number (If this is a private network, you can
use any AS number in the range from 64512 to 65535.) AS
AS number:
IP addresses of BGP neighbors
neighbor
IP addresses:
AS numbers of BGP neighbors
remote-as
Neighbor AS numbers:
Password or secret for MD5 signatures
tcp md5sig
Password or secret:
IP addresses/prefixes to announce for the configured Secure64 DNS
Cache servers; if using anycast, this is the anycast address/prefix announce prefix
Anycast IP addresses/prefixes:
IP address for the source address when Secure64 DNS Cache initiates
the TCP connection to the neighbor system local-address
Secure64 DNS server BGP services IP address:
315
Changing the BGP Configuration File
To change the BGP configuration file:

1. Log in to Secure64 DNS Cache.
2. At the view prompt, type enable bgpadmin and press ENTER to enable the
bgpadmin role.
3. Type edit bgp.conf and press ENTER to open the bgp.conf configuration file for
editing.
4. Define the BGP parameters as appropriate for your system in the bgp.conf file. For
details about the configuration parameters, refer to Global BGP Configuration Parameters
on page 309 and Group and Neighbor BGP Configuration Parameters on page 310.
5. Define any filter rules for UPDATE messages. For rule syntax and parameters, see
UPDATE Filter Rules on page 311.
Note If you are using symmetrical routing (see Configuring In-Bound Traffic Routing Style on page 255) and
do not need to create RIB and FIB information for outbound connections, you can simply set the filter
to “deny from all.”
6. Save the bgp.conf file and exit the Secure64 DNS Cache editor.
7. If BGP is already enabled and running, type stop bgp and press ENTER to stop the
service.
Note You must stop and start BGP to read the new configuration. This clears the current BGP session,
including any routing, forwarding, and update information.
8. To start BGP, type start bgp and press ENTER.

9. For more details about BGP commands, see Using BGP Commands on page 320.
316
Implementing TCP MD5 Signatures

To ensure BGP traffic originates from a known neighbor and not a spoofed IP address, you can
implement the TCP MD5 signature option. As described in RFC 2385, each segment of the TCP
stream has a TCP option field with an MD5 digest of information known only to the valid
endpoints of the TCP stream. The receiver validates the MD5 digest before TCP protocol
processing occurs. If the MD5 digest is invalid, the receiver ignores the segment.
• To use TCP MD5 signatures, include the following statement in the appropriate group or
neighbor section of the bgp.conf configuration file:
tcp md5sig <password|key> <secret>
where <password|key> specifies whether the secret is a password or a hexadecimal key
and <secret> is the password or hexadecimal key.
• Ensure that corresponding BGP neighbors are using the specified password or key.
In addition, RFC 3562 recommends the following best practices for TCP MD5 security:
• Key lengths should be between 12 and 24 bytes, with larger keys having effectively no
additional computational costs when compared to shorter keys.
• Key sharing should be limited so that keys are not shared among multiple BGP peering
arrangements.
• Keys should be changed at least every 90 days.
317
BGP Commands
Table 50 lists the BGP administration and information commands. For examples showing how
to use many of the commands, see Using BGP Commands on page 320 and Testing and Managing
BGP on page 324.
Table 50. BGP commands
Command Description
BGP administration commands
start bgp Reads the bgp.conf configuration file and enables BGP services for
Secure64 DNS.
stop bgp Stops BGP services for Secure64 DNS Cache.
bgp neighbor <peer> up Takes the BGP session to the specified neighbor up.
<peer> can be the neighbor’s IPv4/IPv6 address or description.
bgp neighbor <peer> down Takes the BGP session to the specified neighbor down.
bgp neighbor <peer> clear Stops and restarts the BGP session to the specified neighbor.
bgp neighbor <peer> refresh Requests the specified neighbor to re-send all routes. Note that the
neighbor is not required to re-send routes, even if it announced the route
refresh capability.
bgp announce <ipaddress/prefix> [-n Sends a BGP UPDATE message to the neighbor(s) identified to re-
peer] establish the specified IPv4/IPv6 address/prefixes in the anycast cloud,
where ip_address/prefix is one or more IPv4/IPv6 address/
prefixes to announce and peer is the IPv4/IPv6 address or description
of the neighbor; you can list multiple neighbors after –n. To announce to
all neighbors, omit the –n flag.
bgp withdraw <ipaddress/prefix> [-n Sends a BGP UPDATE message to the neighbor(s) indicated. The
peer] UPDATE message contains the listed IPv4/IPv6 address/prefixes in the
withdrawn routes portion of the message, where ip_address/
prefix is one or more IPv4/IPv6 address/prefixes to withdraw and
peer is the IPv4/IPv6 address or description of the neighbor; you can list
multiple neighbors after –n. To withdraw from all neighbors, omit the –n
flag.
BGP information commands (Available in all modes)
show bgp config Displays the contents of the bgp.conf configuration file.
show bgp fib <filter> Displays routes from the Secure64 DNS Cache server’s Forwarding
Information Base.
For <filter>, define a specific IP address or one of the options
below:
connected: Show only connected routes
static: Show only static routes
bgp: Show only routes originating from the Secure64 DNS server
nexthop: Show only routes required to reach a BGP nexthop.
show bgp info Displays information about the messages sent and received by BGP on
show bgp interfaces Displays the interface states.
318
show bgp neighbor [peer] [modifier] Displays detailed information about the neighbor identified by the peer.
[peer] can be the neighbor’s IPv4/IPv6 address or description,
according to the modifier defined.
For [modifier], define one of the options below:
messages: Show statistics about sent and received BGP messages.
timers: Show the BGP timers.
show bgp nexthop Displays the list of BGP nexthops and the result of their validity check.
show bgp rib [options] [filter] Show routes from the RIB.
For [options]:
detail: Show more detailed output for matched routes.
For [filter]:
<address>: Show best matching route for the address.
as <as>: Show all entries with <as> anywhere in the AS path.
source-as <as>: Show all entries with <as> as the rightmost AS.
transit-as <as>: Show all entries with <as> anywhere but rightmost.
neighbor <peer>: Show only entries from the specified peer.
summary: Display a list of all neighbors, including information about the
session state and message counters.
memory: Show RIB memory statistics.
show bgp status Displays the current state of the BGP system in Secure64 DNS Cache.
show bgp summary Displays a list of all neighbors, including information about the session
state and message counters.
show bgp summary terse Display a list of all neighbors, including information about the session
state, in a condensed format.
319
Using BGP Commands

BGP commands are available only to user accounts that have been assigned the bgpadmin role
in Secure64 DNS Cache. The following sections provide procedures for using the most
common BGP commands. For a complete list of BGP commands, see BGP Commands on
page 318.
Stopping and Starting BGP
To start the BGP service:

2. At the view prompt, type enable bgpadmin and press ENTER.
3. To verify that the DNS server is started, type show cachedns status and press
ENTER.
4. If DNS is started, type start bgp at the bgpadmin prompt and press ENTER.
Note You can start BGP without the DNS server started; however, the addresses announced by the BGP
configuration will not be available to clients sending queries to the DNS server.
5. If DNS is not started, a user account assigned to the cachednsadmin role must log in
and start the server.
6. Secure64 DNS Cache reads the bgp.conf file, starts the BGP service, and begins
contacting the configured BGP neighbors.
Example:
[bgpadmin@Secure64DNS]# start bgp
bgp.conf:65: BGP configuration done with 0 errors, 0 warnings
successfully started bgp configuration bgp.conf
To stop the BGP service:

3. At the bgpadmin prompt, type stop bgp and press ENTER.
4. The server stops all BGP neighbor sessions and frees all resources allocated by the
BGP service.
Example:
[bgpadmin@Secure64DNS]# stop bgp
successfully stopped bgp bgp.conf
320
Viewing the Current BGP System State
To view the current state of the BGP system:

1. At any Secure64 DNS Cache prompt, type show bgp status and press ENTER.
2. The server displays BGP information, including the state of all neighbor sessions.
Example:
[view@Secure64DNS]> show bgp status
BGP instance: bgp.conf state: running AS: 65001 router-id 10.71.0.2
listening on the following addresses:
10.71.0.2
bgp is running
Viewing BGP Information

To view BGP information and statistics:
1. At any Secure64 DNS prompt, type show bgp info and press ENTER.
2. Secure64 DNS Cache displays BGP information, including the number and type of
messages received and sent since BGP was last started.
Example:
[view@Secure64DNS]> show bgp info
BGP instance: bgp.conf state: running AS: 65001 router-id 10.71.0.2
listening on the following addresses:
10.71.0.2
neighbor 10.81.0.1 AS: 65002

state: Active previous state: Connect
configured holdtime: 191 minimum holdtime: 40
received messages:
open 1
update 1
notification 0
keepalive 0
rrefresh 0
sent messages:
open 1
update 1
notification 0
keepalive 0
rrefresh 0
321
Withdrawing and Announcing Service for a Specific IP Address
To withdraw service of one or more IP addresses:

3. At the bgpadmin prompt, type the following and press ENTER.
bgp withdraw ip_address/prefix ... [-n peer ...]
where:
ip_address/prefix ... is one or more the IPv4 address/prefixes to withdraw
peer is the IPv4/IPv6 address or description of the neighbor to withdraw from; you
can list multiple peer definitions. To withdraw from all neighbors, omit the –n flag.
4. Secure64 DNS Cache sends a BGP UPDATE message to the neighbor(s) indicated.
The UPDATE message contains the listed IP address/prefixes in the withdrawn routes
portion of the message.
Example:
[bgpadmin@Secure64DNS]# bgp withdraw 10.71.0.2/32
Successfully sent withdraw to all neighbors
request sent.
322
To re-establish service of one or more IP addresses:

3. At the bgpadmin prompt, type the following and press ENTER.
bgp announce ip_address/prefix ... [-n peer ...]
where:
ip_address/prefix ... is one or more IPv4 address/prefixes to announce
peer is the IPv4/IPv6 address or description of the neighbor; you can list multiple peer
descriptions. To announce all neighbors, omit the –n flag.
4. Secure64 DNS Cache sends a BGP UPDATE message to the neighbor(s) identified to re-
establish the ip_address/prefix in the anycast cloud.
Example:
[bgpadmin@Secure64DNS]# bgp announce 10.71.0.2/32
Successfully sent updates to all neighbors
request sent.
323
Testing and Managing BGP

Using traceroute
To verify the path to the Secure64 DNS Cache server, from a client machine outside of your
network, use the traceroute <domain> command (UNIX/Linux) or the tracert <domain>
command (Windows).
Viewing Neighbor Information

To verify neighbor information, use the show bgp neighbor command to display detailed
information about the state of the connections with all neighbors. The show bgp summary
and show bgp summary terse commands display a list of all neighbors with consolidated
information about the session state and message counters.
You can also use the neighbor commands described in BGP Commands on page 318 to show
specific neighbor information or test BGP with specific neighbors.
To view detailed information about connected neighbor(s):

1. At any Secure64 DNS Cache prompt, type show bgp neighbor and press ENTER.
2. Secure64 DNS Cache displays BGP neighbor information, including the number and
type of messages received and sent for each neighbor since BGP was last started.
324
Example:
[view@Secure64DNS]> show bgp neighbor
BGP neighbor is 12.40.5.3, remote AS 65003
Description: cisco neighbor
BGP version 4, remote router-id 100.100.50.1
BGP state = Established, up for 00:00:08
Last read 00:00:08, holdtime 90s, keepalive interval 30s
Message statistics:
Sent Received
Opens 1 1
Notifications 0 0
Updates 1 2
Keepalives 1 3
Route Refresh 0 0
Total 3 6
Local host: 12.40.5.4

Remote host: 12.40.5.3
BGP neighbor is 12.40.5.2, remote AS 65002

Description: openbgp neighbor
BGP version 4, remote router-id 12.40.5.2
BGP state = Established, up for 00:00:08
Last read 00:00:08, holdtime 90s, keepalive interval 30s
Message statistics:
Sent Received
Opens 1 1
Notifications 0 0
Updates 1 2
Keepalives 1 1
Route Refresh 0 0
Total 3 4
Local host: 12.40.5.4

Remote host: 12.40.5.2
325
To view condensed information about BGP neighbor session states and messages:
1. At any Secure64 DNS Cache prompt, type show bgp summary or show bgp
summary terse and press ENTER.
2. For show bgp summary, Secure64 DNS Cache displays a summary of BGP neighbor
information, including:
— MsgRcvd - The number messages received from the neighbor
— MsgSent - The number of messages sent to the neighbor
— OutQ - The number of queued messages waiting to be sent (a nonzero value can
indicate a connectivity problem)
— Up/Down - The time since the last transition from the UP state to the DOWN
state, or vice versa since BGP was last started
— State/PrefixRcvd - If in the ESTABLISHED state, displays the number of
prefixes received from the peer, otherwise displays the BGP state for that peer (Idle,
Connect, Active, OpenSent, or OpenConfirm)
The show bgp summary terse command displays the neighbor information in a
shortened format.
Example:
[bgpadmin@Secure64DNS]# show bgp summary
Neighbor AS MsgRcvd MsgSent OutQ Up/Down State/PrefixRcvd
AS 65001 Peer1 65001 3 3 0 00:00:03 1
[bgpadmin@Secure64DNS]# show bgp summary terse

AS 65001 Peer1 65001 Established
326
Viewing RIB Information

You can view information about the routes in the RIB with the show bgp rib command.
To display RIB information:

1. At any Secure64 DNS Cache prompt, type show bgp rib and press ENTER.
2. Secure64 DNS Cache displays the RIB information with flags that designate the status of
each route and the origin.
Note If the RIB information contains a large number of routes, displaying this information may require
some time to complete.
Example:
[view@Secure64DNS]> show bgp rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced
origin: i=IGP, e=EGP, ?=Incomplete flags destination gateway lpref med aspath origin
*> 10.20.5.0/24 10.40.5.3 100 0 65003 i
* 10.20.5.0/24 10.40.5.2 100 0 65002 65001 i *> 10.30.5.0/24 10.40.5.2 100 0 65002 i
* 10.30.5.0/24 10.40.5.3 100 0 65003 65001 i *> 10.40.5.0/24 10.40.5.3 100 0 65003 i
* 10.40.5.0/24 10.40.5.2 100 0 65002 i
*> 192.168.95.0/24 10.40.5.3 100 0 65003 65001 i
327
Viewing FIB Information

You can view information about the routes in the FIB with the show bgp fib command.
To display FIB information:

1. At any Secure64 DNS Cache prompt, type show bgp fib and press ENTER.
2. Secure64 DNS Cache displays the FIB information with flags that designate the status
of each route.
Note If the FIB information contains a large number of routes, displaying this information may
require some time to complete.
Example:
[view@Secure64DNS]> show bgp fib
flags: * = valid, B = BGP, C = Connected, S = Static N = BGP Nexthop reachable via this
route r = reject route, b = blackhole route
flags destination gateway

*B 10.20.5.0/24 10.40.5.3
*B 10.30.5.0/24 10.40.5.2
*CN 10.40.5.0/24 link#1
*B 192.168.95.0/24 10.40.5.3
Changing Routing Information

If you add or delete static routes, change the address of an interface, or add or delete an
interface, you must issue the stop bgp and start bgp commands.
For more information about static routes, see Configuring the Default Gateway and Other Routes on
page 252. For more information about changing the address of an interface, see Adding and
Removing IP Addresses for Interfaces on page 276. For more information about adding or removing
a console interface, see Adding and Removing Console Interfaces on page 281.
Troubleshooting BGP
If the traceroute command or id.server CHAOS TXT query is unsuccessful, or the system is
not responding as expected, you can troubleshoot the issue by:
• Monitoring BGP error logging in syslog
• Verifying the contents of the bgp.conf configuration file
• Checking BGP information
The following sections discuss each of these methods.
328
Monitoring Error Logging

Secure64 DNS Cache sends BGP-related messages to syslog. The number and type of messages
sent depend upon the severity level configured.
• For more information about configuring syslog, see Managing Syslog Servers and Local
Logging on page 269.
• For a list of BGP-related messages for syslog, see BGP Logging Messages on page 471.
Displaying BGP Configuration
To display the current BGP configuration:

• At the bgpadmin prompt, type show bgp config and press ENTER, which displays the
bgp.conf configuration file contents.
or
• At the bgpadmin prompt, type edit bgp.conf and press ENTER, which loads the
bgp.conf configuration file for editing.
Displaying BGP Information
To display BGP information:

• At any Secure64 DNS Cache prompt, type show bgp info and press ENTER.
To verify that the BGP service is running:

• At any Secure64 DNS prompt, type show bgp status and press ENTER.
For additional informational (show) commands, see BGP Administration Commands on page 435.
Backing Up and Restoring BGP Information

BGP information is included in the system back up and restore process as discussed in Backing Up
and Restoring System Files on page 297.
329
330
Chapter 9. Enabling RADIUS or LDAP for
User Authentication
Overview
The Secure64 DNS Cache server comes with built-in user and role capabilities. However, you can
configure Secure64 DNS Cache to act as a RADIUS (Remote Authentication Dial In User
Service) or LDAP (Lightweight Directory Access Protocol) LDAP client for user authentication
and authorization.
Deploying RADIUS or LDAP for user authentication provides:
• Centralized administration of users and roles. When you add/remove users or alter
their roles, it is easier and less costly to update a single, centralized data base rather than
individual data bases on many different machines with different operating systems.
• Detailed audit trail. Centralized administration of user logins allows for a single, detailed
audit trail.
• Single user name and password. With centralized user administration, you can assign a
particular individual one user name and password for access to multiple applications and
systems.
• Separation of users and roles. A centralized data base facilitates a fine granularity of
roles for a particular user, which in turn helps overall security by assigning roles to only
those users who really need them.
• Ease of policy implementation. If all devices in an enterprise’s network authenticate to
a centralized service, the service can implement standardized policies for users and roles,
such as strong password requirements.
This chapter provides details for RADIUS and LDAP configuration:
• For details about RADIUS configuration, refer to the next section.
• For details about LDAP configuration, refer to About LDAP Authentication and Secure64
DNS Cache on page 347.
• For details about how RADIUS and LDAP interoperate with the Secure64 DNS Cache
local user database, refer to Roles and User Accounts on page 27 and About User Account
Administration with RADIUS or LDAP on page 31.
Note It is not possible to configure a Secure64 DNS Cache server as both a RADIUS client and an LDAP
client.
331
Chapter 9. Enabling RADIUS or LDAP for User Authentication
About RADIUS and Secure64 DNS Cache

If your organization uses RADIUS for user access administration, you can configure Secure64
DNS Cache as a RADIUS client. When RADIUS is configured, user information is stored in a
centralized RADIUS server. In addition, the Secure64 DNS Cache local user information is
recognized only if all configured RADIUS servers are not available.
Note During initial installation, Secure64 DNS Cache requires local users assigned to some of the roles for
security and configuration purposes. See About User Account Administration with RADIUS or LDAP
on page 31 for more information.
The RADIUS implementation in Secure64 DNS Cache is:

• Tested for interoperability with FreeRADIUS 2.* and the Cisco ACS 4.2 appliance
• Fully compliant with RFC 2865
• Configurable for encrypted storage of the shared secret
Note Public-key authentication through Secure64 DNS Cache is available for the local user data base, but it
is not available when RADIUS is enabled.
Defining Secure64 Vendor-Specific Attributes

To define the server dictionary and user login permissions, use the Secure64 Vendor-Specific
Attributes to configure your RADIUS server(s) to operate with Secure64 DNS products.
RADIUS Dictionary Files

RADIUS uses a dictionary file on both the client (Secure64 DNS) and the RADIUS server to
translate requests and responses.
Client Dictionary
For the client (Secure64 DNS), the system automatically generates the dictionary file in the
RADIUS directory of the Secure64 DNS Cache loginadmin user. The file contains the attributes
required for the Secure64 DNS client to communicate with the RADIUS server. Although a
loginadmin user can modify the file to include additional attributes, it is not recommended. If
the file becomes unusable, you can delete it and a new default file is automatically generated
when needed.
332
Server Dictionary
To configure your RADIUS server dictionary, you need to specify vendor information for
Secure64 DNS products and roles in the RADIUS server configuration scheme:
• Secure64 IANA PEN (Private Enterprise Number):
— Identification tag: 28428
• Product attributes:
— Secure64 DNS Cache: Secure64Cache
— Secure64 DNS Authority: Secure64Authority
— Secure64 DNS Signer: Secure64Signer
Example:
The information below illustrates the server dictionary definition in FreeRADIUS 2.* server
format. (The format required by other RADIUS server software may differ significantly from this
example):
VENDOR Secure64 28428
BEGIN-VENDOR Secure64
ATTRIBUTE Secure64Cache 1 string
ATTRIBUTE Secure64Signer 2 string
ATTRIBUTE Secure64Authority 3 string
END-VENDOR Secure64
Assigning Login Permissions to Users

After you define the server dictionary information, you can configure Secure64 DNS role
identifiers for RADIUS. The role identifiers control the user’s access to the Secure64 DNS
system.
Role Identifier Attributes

The role identifier attributes for RADIUS use the same naming convention as the name of the
role in the Secure64 DNS server products:
• All Secure64 DNS server product attributes can include the following role identifiers:
— view, syscreate, sysadmin, logincreate, loginadmin, securitycreate, securityadmin,
bgpcreate, bgpadmin, snmpcreate, snmpadmin, backup, upgrade
• The Secure64Cache attribute for the Secure64 DNS Cache server can also include the
following role identifiers:
— cachednscreate, cachednsadmin
333
• The Secure64Signer attribute for the Secure64 DNS Signer server and the
Secure64Authority attribute for the Secure64 DNS Authority server can also include
the following role identifiers:
— authdnscreate, authdnsadmin
Format and Rules

When configuring Secure64 DNS server role identifiers on the RADIUS server:
• Separate role identifiers by a comma , in an attribute value.
• You can precede or follow commas and role identifiers by any number of whitespace
characters, subject to the 253 character constraint specified for RADIUS strings in RFC
2865.
• If view is the only role identifier for a product attribute, you must explicitly include it in
the value string. The presence of any role identifier other than view implies that the
view privileges will also be granted.
• It is not an error to include the view role identifier when other role identifiers are
present in the value string.
• If present in a value string, a role identifier must appear only once in the string.
• Role identifiers may appear in any order in a value string.
• Password definition depends on your RADIUS server and the type of password
authentication protocol in use.
Example:
• Assume 3 users defined in RADIUS require access to Secure64 DNS product roles as
follows:
— user1: sysadmin in Secure64 DNS Cache and Secure64 DNS Signer; loginadmin
in all Secure64 systems; bgpadmin in all Secure64 systems; securityadmin in
Secure64 DNS Signer.
— user2: loginadmin in Secure64 DNS Cache; securityadmin in Secure64 DNS
Signer; view only in Secure64 DNS Authority.
— user3: All roles in Secure64 DNS Cache; view only in Secure64 DNS Signer.
334
• The configuration example below illustrates how to assign each of the users to these
Secure64 DNS roles for the various Secure64 DNS product attributes, in FreeRADIUS
2.* format:
user1 Cleartext-Password := "password1"
Secure64Cache = "sysadmin,loginadmin, bgpadmin",
Secure64Signer = "securityadmin,loginadmin,bgpadmin",
Secure64Authority = "loginadmin, bgpadmin"

Secure64Cache = "loginadmin",
Secure64Signer = "securityadmin",
Secure64Authority = "view"

Secure64Cache = "syscreate, sysadmin, logincreate, loginadmin,
bgpcreate, bgpadmin, securitycreate, securityadmin, snmpcreate,
snmpadmin, cachednscreate, cachednsadmin, backup, upgrade",
Secure64Signer = "view",
Secure64Authority = ""
335
Configuring the Secure64 DNS Cache RADIUS Client

The RADIUS configuration file radius.conf defines the necessary RADIUS server
information, client information, search information, and role/group mappings. The file is
accessible only to Secure64 DNS Cache users assigned to the loginadmin role, and it is stored in
the RADIUS directory of that role.
Format and Rules

• The radius.conf file must reside in the RADIUS directory in the loginadmin role.
• You can configure multiple RADIUS servers in case one or more are unavailable. Each
RADIUS server clause starts with the keyword server.
• Options within each server clause are defined with attributes and values. The notation
is: attribute: value
• Empty lines and whitespace at the beginning or the end of a line are ignored.
• Some attributes and values differ based on the type of RADIUS server configured.
• The attributes names are not case sensitive.
Example
# This is a sample radius.conf file with 3 servers defined.
# Server 1 defines all attributes, including default values
server: radius.secure64.com
port: 1812
PAP: PAP
timeout: 5
retries: 3
local: 192.168.127.23
# Server 2 defines only the server attribute.

# All other attributes use the default values.
server: 192.168.127.233
# Server 3 is using some non-default values and an unencrypted

# shared secret. It also defines an IPv6 address for the server and
# default local IPv6 address
server: [2001:db8::1]
secret: test-secret
port: 1613
retries: 10
local: ::
336
Configuration File Attributes

The radius.conf configuration file includes information about the RADIUS server, the
Secure64 DNS Cache RADIUS client, and the RADIUS directory search attributes.
The following limits apply to the components of the file:
• Maximum line length is 255 characters
• Maximum attribute value length is 241 characters
• Maximum server name length is 64 characters
Table 54 describes the server, client, and search attributes in the Secure64 DNS Cache
radius.conf configuration file.
Table 51. RADIUS server and client configuration attributes
Parameter
Example Description
server: <IP address | hostname> The IPv4/IPv6 address or host name of
a RADIUS server for authentication,
server: radius.example.com
limited to 128 characters (required).
server: 192.168.127.194
For IPv6 addresses, including [ ] around
server: [2001:db8::1] the address is optional.
port: <number> Port number for the RADIUS server. If
not defined, the default is 1812
port: 1812
(optional).
secret: <shared_secret> Unencrypted shared secret string. The
maximum length is 48 characters.
secret: example-secret
Use extended ASCII (EAS) for non-
printable characters. To enter a non-
printable EAS character in the secret, use
the convention \x<ascii-code> where
<ascii-code> is the hexadecimal code for
the character
Define only if you do not want to encrypt
the shared secret using the Sensitive
Data Protection (SDP) feature.
The recommended practice is to omit
this attribute and use an encrypted
shared secret via SDP as described in
Securing Sensitive Data on page 244.
PAP: [PAP | CHAP] Password Authentication Protocol (PAP)
PAP: PAP identifier that specifies how to combine
the shared secret and password.
PAP- Password authentication protocol
CHAP- Challenge-handshake
authentication protocol
If not defined, the default is PAP
(optional).
337
Table 51. RADIUS server and client configuration attributes
Parameter
Example Description
timeout: <seconds> The number of seconds to wait for a
timeout: 5 response from the RADIUS server. The
acceptable range is 0 (no timeout)
through 86400 seconds. If not defined,
the default is 5 (optional).
retries: <integer> The number of attempts to reach the
RADIUS server with no response.
retries: 3
Attempts cease after this number. The
acceptable range is 0 (no retries)
through 32. If not defined, the default is
3 (optional).
local: <IP address> IPv4 or IPv6 address of the client
local: 192.168.27.99 interface (Secure64 DNS Cache server)
to use to communicate with the RADIUS
local: 2001:db8::2 server. This must match a currently
configured Secure64 DNS Cache
interface.
For IPv6 addresses, include [ ] around
the address.
If not specified, Secure64 DNS Cache
automatically selects one of the
currently configured interfaces
(optional).
Configuring Access to RADIUS Servers

The radius.conf, located in the RADIUS directory of the loginadmin role, contains the
RADIUS configuration information for the Secure64 DNS Cache system.
For failover/backup, you can configure multiple RADIUS servers. When more than one
RADIUS server is configured, the system attempts authentication with the first server that is
reachable. This occurs with each RADIUS authentication attempt.
Preparations
To add a RADIUS server to the configuration file, you need:
• RADIUS server IP address or host name
A host name must be resolvable via DNS.
• RADIUS server port number
Required if the port number differs from the standard port 1812.
• RADIUS server shared secret
The shared secret specified by the RADIUS server and used for security within the
password protocol. The string must be an extended ASCII (EAS) string.
338
Note Do not use the NUL character (EAS code 0) in the shared secret. To enter a non-printable EAS character
in the secret, use the convention \x<ascii-code> where <ascii-code> is the hexadecimal code for the
character.
• RADIUS server password authentication protocol (PAP)

Secure64 DNS Cache supports the PAP and CHAP protocol(s).
Encrypting the Shared Secret

To encrypt the shared secret, use the Secure Data Protection feature available in the
securityadmin role. For details, refer to Securing Sensitive Data on page 244.
Note Encrypting the shared secret is recommended, but it is not required. If you want to use an unencrypted
shared secret, define it in the radius.conf using the secret: attribute. For more information,
see Configuration File Attributes on page 337.
Editing the RADIUS Configuration File
To edit the RADIUS configuration file:

1. Log in to Secure64 DNS Cache with a user account that is assigned to the loginadmin
role.
2. At the view prompt, type enable loginadmin and press ENTER to enable the
loginadmin role.
3. Type edit RADIUS/radius.conf and press ENTER to open the radius.conf
configuration file. Or if you prefer, use scp to copy the file to a different system and edit it
with your preferred editing application. For details about using scp, see Secure Copy on
page 23.
4. Define the RADIUS server attributes as appropriate for your system in the radius.conf
file.
339
Example:
# first server block
server: 10.10.10.1
port: 1812
PAP: PAP
timeout: 3
retries: 2
local: 192.168.127.1
# second server block (optional attributes are omitted)

server: 10.10.10.2
5. Save the radius.conf file and exit the Secure64 DNS Cache editor. Or use scp to
copy the file to the Secure64 DNS Cache server if you edited it offline.
6. If RADIUS is already enabled and running, type no authenticate radius and press
ENTER to stop the service.
7. To enable the changed configuration, start RADIUS as described in Starting and Stopping
RADIUS Authentication on page 342.
Testing RADIUS Server Settings

You can use the authprobe radius command in the loginadmin role to:
• Test authentication for specific users for a specific RADIUS server
• Test connectivity between a Secure64 DNS Cache server and one or more RADIUS
servers
Testing Authentication
If you want to verify that a specific user and password are valid for a RADIUS server, execute
the following:
• authprobe radius <username> <password> <pap> <server> <port>
<shared-secret> <timeout> <retries>
All parameters are required. For details about each parameter, refer to the configuration
attributes described in Configuration File Attributes on page 337.
The server uses the provided information to login to the RADIUS server; any information in
the radius.conf file is disregarded. In fact, you can use the command when a radius.conf
file does not exist.
340
Example:
[loginadmin@Secure64DNS]# authprobe radius user1 User1Password PAP
RADIUSServer 1812 RADIUSServerSecret 5 1
RADIUSServer ... user1/User1Password pair authenticated.

CacheDNS roles:
sysadmin
loginadmin
securityadmin
cachednsadmin
backup
Signer roles:
sysadmin
loginadmin
securityadmin
upgrade
backup
Authority roles:
sysadmin
loginadmin
Testing Connectivity
1. If you have already configured the RADIUS servers in the radius.conf file, use the
authprobe radius command without arguments to test connectivity only (no
authentication occurs):
authprobe radius
2. The server scans the current contents of the radius.conf file and attempts to reach
each of the servers listed. Results of the probe display on the command line and in syslog.
3. If connectivity issues are reported, refer to Troubleshooting RADIUS on page 345 for
troubleshooting information.
Example:
[loginadmin@Secure64DNS]# authprobe radius
10.10.10.1 ... OK
10.10.10.2 ... Timed out
341
Using RADIUS Commands

Starting and Stopping RADIUS Authentication
To enable RADIUS authentication:

1. Login as a user assigned to the loginadmin role.
2. At the view prompt, type enable loginadmin and press ENTER.
3. At the loginadmin prompt, type authenticate radius and press ENTER.
4. Secure64 DNS Cache checks the radius.conf configuration file and attempts to
connect to the RADIUS server.
5. If the configuration file has no syntax errors and the connection to the RADIUS server
is succesful, a message displays that the bind was successful.
(If there are syntax errors or the RADIUS server is unreachable, see Troubleshooting
RADIUS on page 345.)
6. To enable RADIUS authentication for subsequent logins, type activate and press
ENTER.
7. To save the setting upon reboot, type save and press ENTER.
Note After the activate command is entered, all subsequent logins are authenticated using RADIUS.
The local user data base is consulted only if TCP communication to all configured RADIUS servers
fails or RADIUS authentication is stopped.
Example:
[view@Secure64DNS]> enable loginadmin
[loginadmin@Secure64DNS]# authenticate radius

10.10.10.1 ... OK
10.10.10.2 ... Timed out
radius server(s) reachable.

Please type "activate" to enable radius authentication.
[loginadmin@Secure64DNS]# activate
[loginadmin@Secure64DNS]# save
342
To stop RADIUS authentication:

3. At the loginadmin prompt, type no authenticate radius and press ENTER.
4. If you want to save the configuration change so that RADIUS is not enabled upon
reboot, type activate and press ENTER, then type save and press ENTER.
Note If users assigned to the loginadmin role are logged in when you disable RADIUS, the users continue to
have RADIUS authentication capability until they log out of the Secure64 DNS server and log in again.
Example:
[loginadmin@Secure64DNS]# no authenticate radius
Please type "activate" to disable radius authentication
Viewing the Current RADIUS System State

Information about the status of RADIUS authentication is available to all roles and in view mode.
To check the status of RADIUS authentication:

• At any system prompt, type show authenticate status and press ENTER.
Example:
[loginadmin@Secure64DNS]# show authenticate status
LDAP authentication disabled
RADIUS authentication enabled
343
Viewing the RADIUS Configuration

Information about the configuration of RADIUS authentication is available to all roles and in
view mode.
To display the RADIUS configuration file (radius.conf) contents:

• At any system prompt, type show authenticate config radius and press ENTER.
Note The contents of the radius.conf file can differ from the activated configuration if you have not
issued commands to enable configuration changes (no authenticate radius, authenticate radius,
activate, and save).
Example:
[view@Secure64DNS]> show authenticate config radius
# first server block
server: 10.10.10.1
port: 1812
PAP: PAP
timeout: 3
retries: 2
local: 192.168.127.1
# second server block (optional attributes are omitted)

server: 10.10.10.2
344
Managing RADIUS
Troubleshooting RADIUS
When a RADIUS problem occurs, error messages display at the command line and in syslog. You
can troubleshoot the issue by:
• Monitoring RADIUS error logging in syslog
• Verifying the contents of the radius.conf configuration file
• Checking the RADIUS dictionary files
• Checking network information and the shared secret
The following sections discuss each method.

Secure64 DNS Cache sends RADIUS-related messages to syslog. The number and type of
messages sent depend upon the severity level configured.
• RADIUS syslog messages begin with [SYSTEM:RADIUS].
Sep 23 17:34:38 Secure64DNS: [SYSTEM:RADIUS] 192.168.94.19 timed
out
Sep 23 17:34:38 Secure64DNS: [SYSTEM:CONFIG] radius server(s)
unreachable, Cannot enable radius authentication.
Displaying RADIUS Configuration

When you enable RADIUS authentication using the authenticate radius command, Secure64
DNS Cache checks the syntax of the radius.conf configuration file. Errors are reported via the
command line interface and to syslog.
Examples:
[loginadmin@Secure64]# authenticate radius
RADIUS configuration file: Invalid retries figure (Line 6)

192.168.94.19 ... Timed out
radius server(s) unreachable, Cannot enable radius authentication.

radius.secure64.com ... Host unreachable
radius server(s) unreachable, Cannot enable radius authentication.
345
To check the current RADIUS configuration:

• At any prompt, type show authenticate config radius and press ENTER to display
the radius.conf configuration file contents.
or
• At the loginadmin prompt, type edit RADIUS/radius.conf and press ENTER to load
the radius.conf configuration file for editing.
or
• At the loginadmin prompt, issue the authprobe radius command to scan the
radius.conf configuration for errors and attempt to communicate with the RADIUS
server(s) defined.
Checking the RADIUS Dictionary Files

• Verify that the RADIUS server dictionary file is configured correctly on the RADIUS
server. See Server Dictionary on page 333 for more information.
• Verify that the RADIUS client dictionary file is present on the Secure64 DNS server.
See Client Dictionary on page 332 for more information. (This file is automatically
generated if not present, but it can be edited to include additional attributes by a user
assigned to the loginadmin role.)
Checking Network Information and the Shared Secret

If the radius.conf configuration file syntax is correct, but Secure64 DNS Cache cannot
connect to the RADIUS server, check the following:
• If all configured RADIUS servers are down, it may take a few minutes for Secure64
DNS Cache to report that it cannot login. Check to make sure the servers are available.
• If Secure64 DNS Cache reports that it failed to bind to the RADIUS server, check that
the correct IP address or host name information is configured for both the RADIUS
server (the server: attribute) and the local Secure64 DNS Cache server (the local:
attribute). To display the local interfaces, enter show interfaces. To display the
RADIUS configuration, enter show authenticate config radius.
• Verify that the shared secret is valid and correctly configured. See Encrypting the Shared
Secret on page 339 for details.
• For additional troubleshooting, check syslog messages.
Backing Up and Restoring RADIUS Information

RADIUS configuration information (radius.conf) is included in the system back up and
restore process as discussed in Backing Up and Restoring System Files on page 297.
346
About LDAP Authentication and Secure64 DNS Cache

If your organization uses LDAP for user administration, you can configure Secure64 DNS Cache
as an LDAP client. When LDAP is configured, user information is stored in a centralized LDAP
server, such as a Microsoft Active Directory server. In addition, the local Secure64 DNS Cache
user information is recognized only if all configured LDAP servers are not available.
Note During initial installation, Secure64 DNS Cache requires local users assigned to some of the roles for
security and configuration purposes. See About User Account Administration with RADIUS or LDAP on
The LDAP implementation in Secure64 DNS Cache:

• Supports OpenLDAP and Microsoft Active Directory servers.
• Requires administrator/password authentication to the LDAP server.
• Supports a subset of LDAP version 3. The traditional LDAP over SSL specified in LDAP
version 2 is not supported.
• Supports encrypted storage of the LDAP bind password.
• Examines the local user data base if TCP communication to all configured LDAP servers
fails.
• Supports user login password authentication via LDAP, with optional password hashing
for additional security.
Note Public-key authentication through Secure64 DNS Cache is available for the local user data base, but it is
not available when LDAP is enabled.
Defining Password Authentication on the LDAP server

The LDAP standards (see RFCs 2307 and 3112) specify a number of methods to prevent LDAP
clients and servers from sending LDAP passwords in the clear. The LDAP password
authentication mechanism in the Secure64 DNS Cache client supports the hashed password
method based on the userPassword attribute within an LDAP server. The advantage of hashed
passwords is that an attacker who discovers the hash does not have direct access to the actual
password.
347
Note Values of password attributes, regardless of storage scheme used, should be protected as if they
were clear text. Hashed passwords are subject to dictionary attacks and brute-force attacks.
On the LDAP server, the userPassword attribute can have more than one value, and it is
possible for each value to be stored in a different form. The storage scheme is a hash tag prefix
on the value. For example, the following is a hashed password using the salted SHA1 (SSHA)
scheme:
userPassword: {SSHA}DkMTwBl+a/3DQTxCYEApdUtNXGgdUac3
Standards-compliant hash tags supported by the Secure64 DNS Cache LDAP client include
{SHA}, {SSHA}, {MD5}, {SMD5}, {CRYPT}, and {UNIX}. The {CRYPT} and {UNIX}
tags are essentially synonymous, indicating that the password information that follows is hashed
with the UNIX/Linux crypt(3) function. There are a variety of crypt(3) functions that the
Secure64 DNS Cache LDAP client supports.
The crypt(3) functions supported by Secure64 DNS Cache are listed in Table 52:
Table 52. Crypt(3) functions supported by LDAP client
ID Method
MD5 extension supported by most
1
UNIX/Linux systems
2a Blowfish
md5 MD5 extension used by Solaris
5 SHA-256
6 SHA-512
-- Traditional DES-based
To use hashed passwords for LDAP:

1. On your LDAP server, configure userPassword hashing attributes and information
for the passwords associated with Secure64 DNS Cache users.
2. In the Secure64 DNS Cache ldap.conf configuration file, use the
AUTHSCHEME compare attribute to enable hashed password support. For details about
ldap.conf and the AUTHSCHEME attribute, see Configuring the Secure64 DNS Cache
LDAP Client on page 351.
348
Defining Secure64 DNS Cache Roles on the LDAP Server

Secure64 DNS Cache supports OpenLDAP and Microsoft Active Directory servers. Because
each Secure64 role offers a customizable LDAP search string, you can map Secure64 DNS Cache
roles directly to an LDAP server’s groups. You do not need to modify existing LDAP schema.
For failover/backup, you can configure multiple LDAP servers. Secure64 DNS Cache assumes
that the servers are configured in the same way. If more than one LDAP server is configured,
subsequent servers are contacted if TCP communication fails. However, if a search fails and TCP
communications are established, subsequent LDAP servers are not contacted.
Determining Server Groups and/or Schemas

For Secure64 DNS Cache roles, you can choose to use existing groups and/or schema definitions
or create new groups and/or schema definitions and assign them to the appropriate users.
For example, on an OpenLDAP server, you can:
• Use a standard attribute such as ou (organizational unit) to assign users to specific
Secure64 DNS Cache roles or other suitable roles already defined on your system
• Use an existing objectClass or other definitions and assign them to the appropriate users
• Extend your schema to create new definitions for Secure64 DNS Cache roles and assign
them to the appropriate users
For Active Directory, you can:
• Use existing groups and assign them to the appropriate users
• Create a group for each Secure64 DNS Cache role you plan to assign and add users to the
appropriate group(s)
349
Table 53 lists the Secure64 DNS Cache role definitions and includes space for you to note your
corresponding LDAP server definitions. For more information about Secure64 DNS Cache
roles and their responsibilities, see Authorization and Roles on page 27.
Table 53. LDAP roles/groups mapping
Secure64 DNS Cache Example Server

LDAP Role Definition Corresponding LDAP Server Definition/Group Definitions
SYSADMIN s64sysadmin
nwadmin
BACKUP s64backup
nwadmin
UPGRADE s64upgrade
dnsadmin
CACHEDNSADMIN s64cachednsadmin
dnsadmin
BGPADMIN s64bgpadmin
routingadmin
LOGINADMIN s64loginadmin
ldapadmin
SECURITYADMIN s64securityadmin
nwadmin
SNMPADMIN s64snmpadmin
snmpadmin
VIEWER s64viewer
dnsuser
Note If you are not using a role, you can disable the role for LDAP in the Secure64 DNS Cache
ldap.conf configuration file and omit it from your LDAP server. For details about disabling the role
for LDAP in Secure64 DNS Cache, see Disabling Unused Roles for LDAP on page 356.
350
To add Secure64 DNS Cache users and roles to your LDAP server:
1. Using the LDAP server group definition or schema, assign users on the LDAP server to
the Secure64 DNS Cache roles as needed. Note that:
— You can map users to multiple roles.
— All roles automatically include view capability. However, if you want to assign a user
only view capability, use the VIEWER role definition.
2. Secure64 DNS Cache requires an LDAP server administrator and administrator password
defined for the database. On an OpenLDAP server, this is the rootdn and rootpw. For
Microsoft Active Directory, this is the administrator or a user with administrator
privileges and corresponding password.
Configuring the Secure64 DNS Cache LDAP Client

The LDAP configuration file ldap.conf defines the necessary LDAP server information, client
information, search information, and role/group mappings. The file is accessible only to
Secure64 DNS Cache users assigned to the loginadmin role.
Format and Rules

• Options within each clause are defined with attributes and values. The notation is:
attribute value
• You can configure multiple LDAP servers in case one or more go down. The data in all
configured LDAP servers is assumed to be the same.
• Some attributes and values differ based on the type of LDAP server configured.
• All mapping information is upper- and lower-case sensitive.
Encrypting the LDAP Bind Password

To encrypt the bind password, use the Secure Data Protection feature available in the
securityadmin role. For details, refer to Securing Sensitive Data on page 244.
Note Encrypting the bind password is recommended, but it is not required. If you want to use an unencrypted
bind password, define it in the ldap.conf using the BINDPASSWD: attribute. For more
information, see Server, Client, and Search Attributes on page 354.
351
Example Secure64 DNS Cache LDAP Configurations

Active Directory
#===Server URI(s)===#
URI ldap://192.168.127.24
#===local address===#
LOCALADDR 192.168.127.199
#===DN===#
BINDDN CN=Administrator,CN=Users,DC=example,DC=com
BINDPASSWD secret
#===search base===#
BASE DC=example,DC=com
#===search filter===#
SEARCHFILTER sAMAccountName
#===mappings===#
SYSADMIN memberOf=CN=s64sysadmin,DC=example,DC=com
BACKUP memberOf=CN=s64backup,DC=example,DC=com
UPGRADE memberOf=CN=s64upgrade,DC=example,DC=com
CACHEDNSADMIN memberOf=CN=s64cachednsadmin,DC=example,DC=com
BGPADMIN memberOf=CN=s64bgpadmin,DC=example,DC=com
LOGINADMIN memberOf=CN=s64loginadmin,DC=example,DC=com
SECURITYADMIN memberOf=CN=s64securityadmin,DC=example,DC=com
SNMPADMIN memberOf=CN=s64snmpadmin,DC=example,DC=com
VIEWER memberOf=CN=s64viewer,DC=example,DC=com
#===disable create roles for ldap (users managed on LDAP server)===#

SYSCREATE disable
CACHEDNSCREATE disable
BGPCREATE disable
LOGINCREATE disable
SECURITYCREATE disable
SNMPCREATE disable
352
OpenLDAP
URI ldap://192.168.127.24
URI ldap://[2001:db8::1]
LOCALADDR 192.168.127.199
#===DN===#
BINDDN cn=root,dc=example,dc=com
BINDPASSWD secret
#===search base===#
BASE dc=example,dc=com
SEARCHFILTER uid
#===authentication===#
AUTHSCHEME compare
#===mappings===#
SYSADMIN ou=s64sysadmin
BACKUP ou=s64backup
UPGRADE ou=s64upgrade
CACHEDNSADMIN ou=s64cachednsadmin
BGPADMIN ou=s64bgpadmin
LOGINADMIN ou=s64loginadmin
SECURITYADMIN ou=s64securityadmin
SNMPADMIN ou=s64snmpadmin
VIEWER ou=s64viewer
#===disable create roles for ldap (users managed on LDAP server)===#

SYSCREATE disable
BGPCREATE disable
LOGINCREATE disable
SNMPCREATE disable
353
Server, Client, and Search Attributes

The ldap.conf configuration file includes information about the LDAP server, the Secure64
DNS Cache LDAP client, and the LDAP directory search attributes. Table 54 describes the
server, client, and search attributes in the Secure64 DNS Cache ldap.conf configuration file.
Table 54. LDAP server and client configuration attributes
Parameter
Example Description
URI ldap://<server IPv4 address>[:port] The IPv4/IPv6 address or host name of
URI ldap://<[server IPv6 address]>[:port] one or more LDAP servers for
authentication.
URI ldap://192.168.127.194
For IPv6 addresses, include [ ] around
URI ldap://192.168.127.194 ldap://secure.example.com:99 the address.
URI ldap://[2001:db8::1]
BASE <domain> The distinguished name (DN) of the
branch of the directory where all
BASE dc=example,dc=com
searches should begin.
BASE dc=ldaptest,dc=example,dc=com
SEARCHFILTER <attribute> The attribute to use as the search filter
for the LDAP server when the user logs
in to the Secure64 DNS Cache server.
Active Directory Example:
SEARCHFILTER sAMAccountName For Active Directory servers, use the
sAMAccountName value.
OpenLDAP Example: For OpenLDAP, use the attribute you

SEARCHFILTER uid want as defined on the OpenLDAP
server.
BINDDN <name> <domain> Administrator or root user name for the
LDAP server (required).
Active Directory Example: If you define multiple LDAP servers,

Secure64 DNS Cache assumes the
BINDDN CN=Administrator,CN=Users,DC=example,DC=com same login name is used for each.
OpenLDAP Example:
BINDDN cn=root,dc=example,dc=com
BINDPASSWD <password> Administrator or root user password of
BINDPASSWD secret the LDAP server (required). Define only
if you do not want to encrypt the
password using the Sensitive Data
Protection (SDP) feature.
The recommended practice is to omit
this attribute and use an encrypted
password as described in Securing
Sensitive Data on page 244.
If you define multiple servers, Secure64
DNS Cache assumes the same
password is used for each.
354
Table 54. LDAP server and client configuration attributes
Parameter
Example Description
AUTHSCHEME <bind|compare> Authentication scheme between the
Secure64 DNS Cache LDAP client and
AUTHSCHEME bind
the LDAP server.
bind: Authenticate with username and
clear text password.
compare: Authenticate with username
and hashed form of password stored on
the LDAP server. See Defining
Password Authentication on the LDAP
server on page 347 for additional
information.
If not specified, the default is bind.
LOCALADDR <ip_address> The IPv4 or IPv6 address of the LDAP
LOCALADDR 192.168.27.99 client (Secure64 DNS Cache server).
This must match a currently configured
LOCALADDR 2001:db8::2 Secure64 DNS Cache interface.
If not specified, Secure64 DNS Cache
automatically selects one of the
currently configured interfaces.
Mapping Roles in Secure64 DNS Cache

In the ldap.conf configuration file, each of the Secure64 roles are mapped to a role/group on
the configured LDAP server. The syntax for mapping the roles/groups differs, based on the type
of LDAP server you are using.
Note All mapping information is upper- and lower-case sensitive.
Mapping Microsoft Active Directory

For Microsoft Active Directory, the Secure64 DNS Cache ldap.conf syntax is:
<Secure64 role> memberOf=CN=<server group>,<domain>
where <Secure64 role> is a Secure64 DNS Cache role, <server group> is the
corresponding group defined on the Active Directory server, and <domain> is the
domain content to search on the Active Directory server.
Example:
SYSCREATE memberOf=CN=s64syscreate,DC=ldaptest,DC=example,DC=com
355
Mapping OpenLDAP
For OpenLDAP, the Secure64 DNS Cache ldap.conf syntax is:
<Secure64 role> <attribute>=<server group>
where <Secure64 role> is a Secure64 DNS Cache role, <attribute> is the attribute
defined on the OpenLDAP server, and <server group> is the corresponding group
defined on the OpenLDAP server.
Example:
SYSCREATE ou=s64syscreate
Disabling Unused Roles for LDAP

If you are not mapping a Secure64 DNS Cache role for LDAP, you should designate it as
disabled. For example, if you are not configuring BGP, you can disable the bgpadmin role.
Example:
#===mappings===#
SYSADMIN ou=s64sysadmin
BACKUP ou=s64backup
UPGRADE ou=s64upgrade
CACHEDNSADMIN ou=s64cachednsadmin
LOGINADMIN ou=s64loginadmin
SECURITYADMIN ou=s64securityadmin
SNMPADMIN ou=snmpadmin
VIEWER ou=s64viewer
#===Disable BGPADMIN role for LDAP===#

BGPADMIN disable
#===disable create roles for ldap (users managed on ldap server)===#

SYSCREATE disable
BGPCREATE disable
LOGINCREATE disable
SNMPCREATE disable
Note Within the Secure64 DNS Cache local user database, you should create and assign all create roles to
disable the Installer role for security reasons. See About User Account Administration with RADIUS or
LDAP on page 31 for more information.
356
Editing the Secure64 DNS Cache LDAP Configuration

Secure64 DNS Cache provides a sample ldap.conf in the root directory of loginadmin mode
that you can edit for your LDAP server requirements. For example configurations, see Example
Secure64 DNS Cache LDAP Configurations on page 352.
To edit the LDAP configuration file:

1. Log in to Secure64 DNS Cache with a user account that is assigned to the loginadmin
role.
2. At the view prompt, type enable loginadmin and press ENTER to enable the
loginadmin role.
3. Type edit ldap.conf and press ENTER to open the ldap.conf configuration file for
editing. Or if you prefer, use scp to copy the file to a different system and edit it with your
preferred editing application. For details about using scp, see Secure Copy on page 23.
4. Define the LDAP parameters as appropriate for your system in the ldap.conf file. For
details about the configuration parameters, refer to Server, Client, and Search Attributes on
page 354 and Mapping Roles in Secure64 DNS Cache on page 355.
5. Save the ldap.conf file and exit the Secure64 DNS Cache editor. Or use scp to copy the
file to the Secure64 DNS Cache server if you edited it offline.
6. If LDAP is already enabled and running, type no authenticate ldap and press ENTER
to stop the service.
7. To start LDAP, see Starting and Stopping LDAP Authentication in the following section.
Using LDAP Commands

Starting and Stopping LDAP Authentication
To enable LDAP authentication:

3. At the loginadmin prompt, type authenticate ldap and press ENTER.
4. Secure64 DNS Cache checks the ldap.conf configuration file and attempts to bind to
the LDAP server.
5. If the configuration file has no syntax errors and the connection to the LDAP server is
succesful, a message displays that the bind was successful.
(If there are syntax errors or the LDAP server is unreachable, see Troubleshooting LDAP on
page 362.)
6. To enable LDAP authentication for subsequent logins, type activate and press ENTER.
7. To save the setting upon reboot, type save and press ENTER.
357
Note After the activate command is entered, all subsequent logins are authenticated using LDAP. The
local user data base is consulted only if TCP communication to all configured LDAP servers fails or
LDAP authentication is stopped.
Example:
[view@Secure64DNS]> enable loginadmin
[loginadmin@Secure64DNS]# authenticate ldap

attempting to connect to LDAP server ldap://192.168.127.194 ...
Bind to LDAP server ldap://192.168.127.194 succeeded
358
To stop LDAP authentication:

3. At the loginadmin prompt, type no authenticate ldap and press ENTER.
4. If you want to save the configuration change so that LDAP is not enabled upon reboot,
type activate and press ENTER, then type save and press ENTER.
Note If users assigned to the loginadmin role are logged in when you disable LDAP, the users continue to have
LDAP authentication capability until they log out of the Secure64 DNS server and log in again.
Example:
[loginadmin@Secure64DNS]# no authenticate ldap
Running configuration successfully saved
Viewing the Current LDAP System State

Information about the status of LDAP authentication is available to all roles and in view mode.
To check the status of LDAP authentication:

• At any system prompt, type show authenticate status and press ENTER.
Example:
[loginadmin@Secure64]# show authenticate status
LDAP authentication disabled
RADIUS authentication disabled
[loginadmin@Secure64]# authenticate ldap

attempting to connect to LDAP server ldap://192.168.95.65 ...
Bind to LDAP server ldap://192.168.95.65 succeeded
ldap server(s) reachable.

Please type "activate" to enable ldap authentication.
359
[loginadmin@Secure64]# show authenticate status

LDAP authentication disabled, enable pending activate command
RADIUS authentication disabled
Viewing the LDAP Configuration

Information about the configuration of LDAP authentication is available to all roles and in
view mode.
To check the LDAP configuration:
• At any system prompt, type show authenticate config ldap and press ENTER.
Note The contents of the ldap.conf file can differ from the activated configuration if you have not
issued commands to enable configuration changes (no authenticate ldap, authenticate ldap,
activate, and save).
Example:
[view@Secure64DNS]> show authenticate config ldap
#openLDAP server
URI ldap://192.168.95.65
#===search base===#
#search base for openLDAP
BASE dc=sec64,dc=com
#search filter for openLDAP
SEARCHFILTER cn
#===mappings===#
#mappings for openLDAP
SYSCREATE objectClass=s64syscreate
SYSADMIN objectClass=s64sysadmin
BACKUP objectClass=s64backup
UPGRADE objectClass=s64upgrade
CACHEDNSCREATE objectClass=s64cachednscreate
CACHEDNSADMIN objectClass=s64cachednsadmin
BGPCREATE objectClass=s64bgpcreate
BGPADMIN objectClass=s64bgpadmin
LOGINCREATE objectClass=s64logincreate
360
LOGINADMIN objectClass=s64loginadmin
SECURITYCREATE objectClass=s64securitycreate
SECURITYADMIN objectClass=s64securityadmin
SNMPCREATE objectClass=s64snmpcreate
SNMPADMIN objectClass=s64snmpadmin
VIEWER objectClass=s64viewer
LOCALADDR 192.168.95.81
#===DN===#
#DN and password for openLDAP
BINDDN uid=root,ou=People,dc=sec64,dc=com
BINDPASSWD secret
361
Managing LDAP
Troubleshooting LDAP
When LDAP problems occur, error messages display at the command line and in syslog. You
can troubleshoot the issue by:
• Monitoring LDAP error logging in syslog
• Verifying the contents of the ldap.conf configuration file
• Checking network information
The following sections discuss each method.

Secure64 DNS Cache sends LDAP-related messages to syslog. The number and type of
messages sent depend upon the severity level configured.
• For a list of LDAP-related messages for syslog, see LDAP Logging Messages on page 474.
Displaying LDAP Configuration

When you enable LDAP authentication using the authenticate LDAP command, Secure64
DNS Cache checks the syntax of the ldap.conf configuration file. Errors are reported via the
command line interface and to syslog.
Example:
[loginadmin@Secure64DNS]# authenticate ldap
Failed to start LDAP authentication client: Invalid argument
Failed to enable LDAP authentication.
To check the current LDAP configuration:

• At any prompt, type show authenticate config ldap and press ENTER to display the
ldap.conf configuration file contents.
or
• At the loginadmin prompt, type edit ldap.conf and press ENTER to load the
ldap.conf configuration file for editing.
362
Checking Network Information

If the ldap.conf configuration file syntax is correct, but Secure64 DNS Cache cannot connect
to the LDAP server, check the following:
• If all configured LDAP servers are down, it may take a few minutes for Secure64 DNS
Cache to report that it cannot login. Check to make sure the servers are available.
• If Secure64 DNS Cache reports that it failed to bind to the LDAP server, check that the
correct IP address information is configured for both the LDAP server (the URI
attribute) and the locale Secure64 DNS Cache server (the LOCALADDR attribute). To
display the local interfaces, enter show interfaces. To display the LDAP configuration,
enter show authenticate config ldap.
• For additional troubleshooting, check syslog messages and refer to Appendix B. Syslog and
System Boot Messages on page 443.
Backing Up and Restoring LDAP Information

LDAP information is included in the system back up and restore process as discussed in Chapter
7. Backing Up and Restoring System Files on page 297.
363
364
Chapter 10. Information and Diagnostics
System Information and Diagnostics
If you configure the syslog server, application and system messages are recorded to syslog at the
log level you define. You can also connect a monitor to one of the machine’s VGA ports to
monitor activity. In addition, Secure64 DNS Cache includes a number of system utility
commands, which are described in this chapter.
Monitoring Logging Messages

You can configure Secure64 DNS Cache to log messages to syslog. For instructions about setting
up syslog, see Managing Syslog Servers and Local Logging on page 269.
In addition to writing to a remote syslog, Secure64 DNS Cache stores a portion of the syslog
contents to a local file. The sysadmin role defines the number of lines to write to the file when
configuring syslog and defining the loglevel.
Note To display up to 50 entries in the local log file, use the show syslog command at any Secure64
DNS Cache system prompt.
For a list of logging messages, causes, and explanations, see Appendix B. Syslog and System Boot
Messages on page 443. A sample output from syslog appears below. In this example, Secure64DNS
is the nodename of the Secure64 DNS Cache name server.
Note If you set the syslog logging level to 7 (LOG_DEBUG), it may affect performance due to the large volume
of messages sent to syslog. Enable log level 7 only for as long as needed to capture debug information.
Oct 4 19:58:21 Secure64DNS: [SYSTEM:USERS] Login successful for Joe

Oct 4 19:59:18 Secure64DNS: [SYSTEM:USERS] User Joe authorized for role
cachednsadmin.
Oct 4 19:59:47 Secure64DNS: [APPLICATION:RESOLVER] cache.conf:6: resolver
config parser: 0 errors, 0 warnings
Oct 4 19:59:47 Secure64DNS: [APPLICATION:RESOLVER] Validation deactivated,
no usable trust anchors found.
Oct 4 19:59:47 Secure64DNS: [APPLICATION:RESOLVER] error parsing local-
data 'secure64.com AAAA ': Syntax error, value expected
Oct 4 19:59:47 Secure64DNS: [APPLICATION:RESOLVER] Bad local-data RR
secure64.com AAAA
365
Using System Utility Commands

Displaying Current System Configuration
To display configuration settings in view, sysadmin, or cachednsadmin mode:

• Type the following and press ENTER:
show <cmd>
where <cmd> is:
— pending — displays configuration information that is invoked when the
administrator enters the activate command while in sysadmin mode
— config — displays current system configuration
— saved — displays configuration information saved in the configuration file that
invokes at the next boot of the system
Note The show commands listed here apply only to system settings such as networking. For configuration
information about DNS, use the show cachedns config command. For BGP, use the show
bgp config command. For RADIUS or LDAP, use the show authenticate config
command.
Example:
[sysadmin@Secure64]# show config
ifconfig eth2 192.168.110.100 255.255.255.0
ifconfig eth2.1 2001:db8:aaaa::/48
ifconfig eth3 192.168.95.86 255.255.255.0
ifconfig eth3.1 2001:db8:bbbb::/48
ifconfig lo0 192.168.130.110 255.255.255.255
console eth2
console eth3
console eth3.1
route asym
nameserver 0 192.168.127.1 6
nameserver 1 192.168.127.8 4
ntp 192.168.95.65
tz America/Denver
syslog 192.168.95.65
loglevel 0 50
nodename Secure64
366
ruleactions on
nullchecksums allow
timeout 0
ip frag timeout 5
ip frag high 40
ip frag low 30
Using Ping and Ping6

To verify that a configured Secure64 DNS Cache interface is functioning, ping an external IP
address or hostname from the interface, as follows:
1. Use SSH to connect to the management console IP address from your console computer
on the network.
2. Log into Secure64 DNS Cache with an account that is assigned to the sysadmin role.
3. Type enable sysadmin and press ENTER to enable the system administration mode.
4. Enter the ping or ping6 command for an external IP address or hostname from the
management port:, where <interface> is the ethX, ethX.I, ethX:V.I, or bondX,
bondX.I interface you are testing. For ping6, you can use [datasize] to define the
number of octets to send, from 1-1500:
or
367
Example:
ping successful

ping successful
Displaying Available Memory, Physical Memory, or Drive Space

The memstat command displays available memory in kilobytes. You can add -b to specify
bytes, -k for kilobytes, -m for megabytes, or -g for gigabytes. Add -p to display total physical
memory instead of available memory
To display available memory in kilobytes (applies to all modes):

• Type memstat and press ENTER.
To display total physical memory in kilobytes (applies to all modes):

• Type memstat -p and press ENTER.
Examples:
[view@Secure64DNS]> memstat
2916656 kilobytes of memory available
[view@Secure64DNS]> memstat -g
2.78 gigabytes of memory available
[view@Secure64DNS]> memstat -p
4194304 kilobytes of memory installed
[view@Secure64DNS]> memstat -p -g
4 gigabytes of memory installed
To display available hard drive space (applies to all modes):

• Type df and press ENTER.
368
Example:
[view@Secure64DNS]> df
Free drive space: 26,548,696 kilobytes, 5% full.
File nodes used: 484 files, 5% full.
Displaying Disk Information

The show disks command provides information about the disk or disks used by the file system.
The information displayed includes:
• The product ID
• The physical slot in which the disk is installed
• The total MB of storage available to the file system (not the total capacity)
• A count of the number of errors detected
• If the system uses RAID1 for mirrored disks, the status of the RAID volume and each
disk in the RAID volume display.
To display information about the disk or disks (applies to all modes):

• Type show disks and press ENTER.
Example (non-RAID):
[view@Secure64DNS]> show disks
disk: DG146BB976 slot: 5
capacity: 32718MB errors: 0
Example (RAID):
[view@Secure64DNS]> show disks
primary disk: DH036BB977 slot: 3
capacity: 38302MB status: okay errors: 0
secondary disk: DH036BB977 slot: 2

capacity: 28302MB status: okay errors: 0
hot spare disk: DH036BB977 slot: 6

capacity: 28302MB status: down errors: 0
369
Displaying Hardware Sensor Information
To display information from the hardware sensors located on the Secure64 DNS Cache
hardware:
• Type show sensors and press ENTER.
Note Use the chassispoll command to set the interval for checking the hardware sensors. To
generate syslog messages for the power supply and other sensor changes, you must set a chassis
polling interval. For details, see Setting the Chassis Polling Interval on page 290.
Example (HP rx2660):

[view@Secure64DNS]> show sensors
Temperature Sensors
Proc 0 ThermTrip: ok
Proc 1 ThermTrip: ok
Processor 0 Temp: 72 C ok
Ambient Temp: 21 C ok
Power Supply Sensors
Power Supply 1: installed
Power Supply 2: not present
Power Redundancy: redundancy lost
Voltage Sensors
Proc 0 Power: ok
Proc 1 Power: ok
1.2VFSB SystemBd: ok
1.5V SystemBoard: ok
5V System Board: ok
5V I/O Riser: ok
3.3V Display Brd: ok
Mgmt Battery: performance met
System Battery: performance met
Chassis Intrusion Sensor
Chassis Open: deasserted
Fan Sensors
Fan 1 (Memory): performance met
370

Fan 5 (CPU): performance met
Fan 9 (I/O): performance met
Example (HP rx2800):

[view@Secure64]> show sensors
Temperature Sensors
Ambient Temp: 28 C ok
Internal Temp 1: 33 C ok
Internal Temp 2: 31 C ok
Altitude Eq Temp: 5 C ok
IOH THERMALERT: ok
IOH THERMTRIP: ok
CPU0 THERMTRIP: ok
CPU0 PROCHOT: ok
CPU0 VR_FAN_R: ok
CPU0 VR_THRMALRT: ok
CPU0 VR_THRMTRIP: ok
CPU1 THERMTRIP: ok
CPU1 PROCHOT: ok
CPU1 VR_FAN_R: ok
CPU1 VR_THRMALRT: ok
CPU1 VR_THRMTRIP: ok
DIMM1B-R1 Temp: 33 C ok
DIMM2C-R1 Temp: 0 C ok
DIMM3A-R1 Temp: 33 C ok
371
IOR1 Temp Int: 27 C ok
IOR1 Temp ExtD1: 30 C ok
IOR2 Temp Int: 0 C ok
PSU 1 Inlet Temp: 31 C ok
PSU 2 Inlet Temp: 46 C ok
Power Supply Sensors
Power Redundancy: redundancy lost
Voltage Sensors
1_5V IOH PWR: performance met
3_3V System PWR: performance met
5V PWR: performance met
5V HD_PWR: performance met
1_1V CPU0 PWR: performance met
MEM RISER1 PWR: performance met
372

SAS PWR: performance met
1_5V ICH PWR: performance met
NIC STBY PWR: performance met
I/O RISER1 PWR: performance met
I/O RISER2 PWR: performance met
Proc 0 Power: performance met
Proc 1 Power: performance met
MP Battery: performance met
Chassis Intrusion Sensor
Chassis Open: deasserted
Fan Sensors
Fan1A Tach: 6100 RPM ok
Fan1B Tach: 5900 RPM ok
373
Displaying the Software and Platform Version
To display the Secure64 DNS Cache software version information (applies to all
modes):
• Type version and press ENTER.
The output includes the platform designation as follows:
Table 55. Platform designation in version command
Platform Designation Processor Server Model(s)

ZX-1 McKinley/Madison HP rx2600, HP rx1600 (obsolete)
E8870 McKinley/Madison SuperMicro, Intel Tiger (obsolete)
ZX-2 Montecito/Montvale HP rx2660, HP BL860c (Blade)
BXB Tukwila/Poulson HP rx2800 i2/i4, HP BL860c i2/i4 (Blade)
If the Capacity Expansion Module is installed, the “CEM” designation displays after the
product name and before the version number. For more information about the CEM, refer to
Multiple Resolver Instances on page 176.
Example (without CEM):

[view@Secure64DNS]> version
Secure64 DNS Cache 3.1.0 B (ZX-2) built Dec 2 2013 16:40:36 (4.3.1)
Example (with CEM):

[view@Secure64DNS]> version
Secure64 DNS Cache CEM 3.1.0 B (BXB) built Dec 2 2013 16:40:36 (4.3.1)
Displaying Processor Information
To display the Secure64 DNS Cache server processor information (applies to all
modes):
• Type cpuinfo and press ENTER.
The command output provides the following information:

• Processor vendor
• Processor series
374
The possible processor series values include the following:
Note The processor code name is shown in italics for informational purposes, but it does not display in the
cpuinfo command output.
— Itanium Processor McKinley

— Itanium Processor (up to 3MB L3 cache) Madison
— Itanium Processor 9000 Series Montecito
— Itanium Processor 9100 Series Montvale
— Itanium Processor 9300 Series Tukwila
— Itanium Processor 9500 Series Poulson
— Itanium Processor Unknown Not applicable
• Processor speed
• Number of CPU cores enabled by the EFI (hardware) cpuconfig command
• Number of CPU cores in use by the installed Secure64 DNS software
Example:
[view@Secure64DNS]> cpuinfo
GenuineIntel Itanium Processor 9300 Series 1.33 GHz
Number of enabled CPU cores : 4
Number of configured CPU cores: 4
cpu core 0: I/O-A
cpu core 1: App-1
cpu core 2: App-2
cpu core 3: App-3
Displaying the System Uptime and CPU Utilization

To display the average CPU utilization percentage across all processor cores in use, the individual
core App CPU and I/O level percentages in use, and how long Secure64 DNS Cache has been
running (applies to all modes):
• Type uptime and press ENTER.
Example:
[view@Secure64DNS]> uptime
CPU 8.7% (App CPU 0.6%, I/O CPU 16.9%), uptime 35 days, 03:18:15
375
To break down the information by core and/or processor type (applies to all modes):
• Execute the command with the appropriate argument(s):
uptime [[-cpu | -app | -io] [n]]
where:
-cpu requests information for both the application processor and the I/O processor
-app requests information for the application processor only
-io requests information for the I/O processor only
n is used with a processor argument (-cpu, -app, -io) to designate a specific processor
number to report; if not specified, all processor numbers are listed
The Secure64 DNS Cache server automatically assigns processor numbers as shown:
Table 56. Processor and resolver numbering
Processor or Resolver Name/Number Name/Number Name/Number Name/Number

CPU CPU 1 CPU 2 CPU 3 CPU 4
Assignment I/O A APP-1 APP-2 APP-3
Resolver Instance -- Instance 1 Instance 2 Instance 3
You can use the processor numbers with the uptime command to help identify and monitor
the load for a specific processor core. For example, CPU processor 2 is the equivalent of APP
processor 1.
Note The number of processors displayed are the number authorized for use by the Secure64 DNS
software, regardless of the number of available processors.
Examples:
[view@Secure64DNS]> uptime -cpu 3
APP-2 15.2%
[view@Secure64DNS]> uptime -app

APP-1 13.7%
APP-2 15.2%
APP-3 9.8%
[view@Secure64DNS]> uptime -app 1

APP-1 13.7%
376
[view@Secure64DNS]> uptime -io 1

I/O-A 15.2%
[view@Secure64DNS]> uptime -io a

I/O-A 15.2%
377
Displaying Physical Interfaces
To display information about the physical interfaces (applies to all modes):

• Type show interfaces and press ENTER.
Example:
[view@Secure64DNS]> show interfaces
Interfaces:
eth0: Oct 25 16:42:19 MDT Ethernet 00:1a:4b:08:ef:6a i82546_3

IPv6 link-local fe80::21a:4bff:fe08:ef6a
Speed:1000Mb/s Duplex:Full Link up:Yes
eth1: Oct 25 16:42:19 MDT Ethernet 00:1a:4b:08:ef:6b i82546_3

IPv6 link-local fe80::21a:4bff:fe08:ef6b
Speed:10Mb/s Duplex:Half Link up:Yes
eth2: Oct 25 16:42:19 MDT Ethernet 00:1c:c4:fc:d3:ff BCM5704C

IPv6 link-local fe80::21c:c4ff:fefc:d3ff
eth3: Oct 25 16:42:19 MDT Ethernet 00:1c:c4:fc:d3:fe BCM5704C

IPv6 link-local fe80::21c:c4ff:fefc:d3fe
lo0: Oct 25 16:42:19 MDT Loopback 00:00:00:00:00:00

IPv6 link-local fe80::200:ff:fe00:0
378
Table 57 describes the information that displays:
Table 57. Show interfaces command information

eth#: Delivery service Ethernet: Type MAC address NIC type
Line 1
lo0: Virtual loopback Loopback: Type
interface
Current time
IPv6 link-local: IPv6 NA NA NA
Line 2
link local address
Speed: Speed Duplex: Full or half duplex Link up: Status (yes or no) NA
Line 3
negotiated by the
Ethernet cards
RX packets: Number of RX errors: Number of RX dropped: Number of NA
Line 4
good Ethernet packets Ethernet packets received frames dropped due to lack
received with errors of room in the receive ring,
plus packets that the driver
drops due to any of the
following error conditions
detected in the received
packet: RX Data Error, IP
Checksum Error, TCP/UDP
Checksum Error, Carrier
Extension Error, Framing
Error, CRC Error, or
Alignment Error
TX packets: Number of TX errors: Number of TX dropped: Number of NA
Line 5
successfully transmitted transmissions with errors transmissions dropped due
Ethernet frames to a lack of room in the
transmit ring
RX bytes: Number of TX bytes: Number of bytes NA NA
Line 6
bytes received in the transmitted in the valid
valid Ethernet frames Ethernet frames
Note Because the loopback interface is virtual, the Ethernet address and IPv6 link local address are not
applicable in the show interfaces output.
379
Displaying Network Statistics

The netstat command provides detailed information about network activity for the Secure64
DNS Cache server. The statistics display IP, ARP, DNS, ICMP, and TCP activity since the last
server boot or the last time the statistics were cleared.
To display network statistics (applies to any mode):

• Type netstat and press ENTER.
To clear and reset network statistics (applies to any mode):

• Type netstat clear and press ENTER.
Example:
[sysadmin@Secure64]# netstat
Ip:
569817 packets delivered to upper layer protocol
575376 total packets received
0 received header errors
0 fragments received
0 successfully reassembled packets
0 failed reassembled packets
0 sent packets fragmented
0 fragmented packets failed
0 fragments created
Arp:
506 requests received
506 replies sent
108 requests sent
108 replies received
0 outbound IP packets dropped because of full queue
Dns:
100115 valid queries received
0 short requests received
0 illegal responses received
Icmp:
50 messages received
0 messages received with failed checksums
Icmp incoming histogram:
0 destination unreachable
0 time exceeded
0 invalid parameters
0 source quenches
0 redirects
380
40 echo requests
0 echo replies
0 time stamp requests
0 time stamp replies
0 address mask requests
0 address mask replies
126 unknown/invalid requests
40 outgoing messages sent
0 outgoing messages failed
Icmp outgoing histogram:
0 destination unreachable
0 time exceeded
0 invalid parameters
0 source quenches
0 redirects
0 echo requests
40 echo replies
0 time stamp requests
0 time stamp replies
0 address mask requests
0 address mask replies
Tcp:
0 syns received with hash table full
907 syns received
907 syn acks sent
907 acks received establishing a connection
0 packets with bad MD5 received
Udp:
196742 packets received
1 packets received with errors
205443 packets sent
307 packets to unknown port received
196446 packets queued
0 packets dropped when queue was full
0 packets filtered
0 rules rejected
381
Displaying IPv4 or IPv6 Routing Information
To display IPv4 routing information (applies to any mode):

• Type show ip route and press ENTER.
Example:
[view@Secure64]> show ip route
Destination Gateway Genmask Interface
192.168.25.0 192.168.95.61 255.255.255.0 eth5
0.0.0.0 192.168.127.1 0.0.0.0 eth1
10.95.0.0 0.0.0.0 255.255.255.0 eth5:95
192.168.95.0 0.0.0.0 255.255.255.0 eth5
63.146.91.192 0.0.0.0 255.255.255.248 eth4
10.10.0.0 0.0.0.0 255.255.255.0 eth3:10
10.20.0.0 0.0.0.0 255.255.0.0 eth3
192.168.127.0 0.0.0.0 255.255.255.0 eth1
192.168.64.0 0.0.0.0 255.255.255.0 eth0
To display IPv6 routing information (applies to any mode):

• Type show ipv6 route and press ENTER.
Example:
[view@Secure64]> show ipv6 route
Destination Gateway prefix length
2000:: 2001:470:1f04:ad8:1::2 3
2002::1 :: 64
2001:470:1f04:ad8:1::51 :: 80
Note To view IPv6 information for interfaces, see Displaying IPv6 Addresses Assigned to Interfaces on
page 383.
382
Displaying IPv6 Addresses Assigned to Interfaces
To display IPv6 addresses assigned to physical interfaces for the Secure64 DNS server
(applies to any mode):
• Type show ipv6 addr or show ipv6 and press ENTER.
The information includes the IPv6 address scope in accordance with RFC 4291:
• Link scope: Limited to the physical “wire” (allows for switches, but not routers) that the
interface is connected to. Usually, the link local address is automatically generated when
the interface is activated. These addresses never cross routers.
• Global scope: Assigned from the regional registry, the global scope address is globally
unique and fully routed.
• Multicast scope: Defined multicast groups identify IPv6 nodes within a given scope.
Defined groups include interface local all-nodes group (FF01::1) and link-local all-nodes
group (FF02::1). IPv6 makes extensive use of multicast for automatic address
management.
Example:
[view@Secure64]> show ipv6 addr
eth1.1
fe80::21a:4bff:fe06:45df/64 preferred Scope:Link
fd64:0:0:127::99/64 preferred Scope:Global
ff02::1:ff06:45df/64 preferred Scope:Multi
eth2.0
fe80::204:23ff:fec4:288/64 preferred Scope:Link
ff02::1:ffc4:288/64 preferred Scope:Multi
eth5.1
fe80::204:23ff:fec4:23b/64 preferred Scope:Link
ff02::1:ffc4:23b/64 preferred Scope:Multi
lo0.0
2002::1/64 preferred Scope:Link
2002::1/64 preferred Scope:Global
383
Displaying Serial Port Settings
To display the current available serial device:

• Type show comm and press ENTER.
or
3. Type comm and press ENTER.
Example:
[sysadmin@Secure64DNS]# comm
Serial Interfaces:
[0]: ttyS0
To display the current settings for the defined interface, where <interface> is the serial
interface:
3. Type comm <interface> and press ENTER
Example:
[sysadmin@Secure64DNS]# comm ttyS0
ttyS0 115200 8N1 None
Displaying Logged In Users
To display the console connections and users currently logged into the Secure64 DNS
Cache server (applies to all modes and includes users logged in with RADIUS or LDAP
authentication):
• Type who and press ENTER
Examples:
[view@Secure64DNS]> who
serial: tester
[view@Secure64DNS]> who
Joe 10.139.0.234:2459
tester 10.139.0.234:2461
384
Displaying the System RSA Key
To display information about the system’s RSA key (applies to all modes):
• Type show fingerprint and press ENTER.
Example:
[view@Secure64DNS]> show fingerprint
RSA key fingerprint is
15:5a:08:bb:37:23:5a:c8:b0:f4:26:81:4e:a3:e0:2d.
Displaying Application and Services Information

The show command allows you to display status, information, and configuration details about
each of the services running on the Secure64 DNS Cache system. For a summary of these
commands, see the System Information section in the table of View Mode Commands on page 421.
You can also find detailed descriptions of each of the show commands in the individual chapters
that discuss the applications and services.
385
Displaying Mitigation and Self-Defense Statistics

To identify mitigation, flood-control, and self-defense activities, the Secure64 DNS Cache
server includes a statistics information system. The system maintains a number of statistics that
can help administrators identify DoS and DDoS activity directed at the Secure64 DNS Cache
server.
To display the statistical information:

2. At any Secure64 DNS Cache prompt, type show defense info and press ENTER.
3. Output similar to the following displays:
[sysadmin@Secure64DNS]# show defense info
Inst 1min 5min 15min

Active clients: 0 0 0 0
Blacklisted: 0 111189703 37651264 13701815
Graylisted: 0 0 0 0
Incoming SYN: 0 1 1 1
Established TCP: 0 1 1 1
Incoming ssh: 0 0 0 0
No listener: 0 0 0 0
Aggregate drops: 0 13263 7901 3456
Free ctl(s): 262144 262144 262144 262144
Top Offenders
Source Address Refcount Age (seconds)
192.168.1.1 3738600 307
The four numeric columns show rates of each item, where:

• Inst represents instantaneous (the count over the previous 5 seconds)
• 1min is the one-minute moving average
• 5min is the five-minute moving average
• 15min is the 15-minute moving average
Note that the averages are exponentially weighted, so the 1min, 5min, and 15min numbers are
not exact unless the rate is stable. Additionally, the longer the moving average, the longer the
time required to collect the information and calculate the average.
For example, if the server receives 100 SSH connections every 5 seconds, the Inst column will
read 100. The other columns won’t read 100 until 5 minutes (for the 1min column), 25 minutes
(for the 5min column), and 75 minutes (for the 15 min column). Because it is unlikely that the
rate is stable over time, it is unlikely that all of the averages will reach the same value. However,
if the 15min column shows a high value, it is likely that a sustained, intense attack is occurring.
386
Table 58 describes each of the statistical items in more detail.
Table 58. Defense system statistics
Item Description
Active clients The number of unique IP addresses that are being tracked. An IP address is
tracked when it has a mitigation rule associated with the type of network traffic it
is sending.
For information about rules, see Configuring UDP Rate Limit or Drop Rules on
page 234, Configuring TCP Rules for SSH and DNS Traffic on page 236, and
DNS RRtype Filtering Rules on page 238.
Blacklisted The number of active clients on the blacklist (temporarily prevented from
communicating).
Graylisted The number of active clients on the graylist (allowed to send traffic, but strong
candidate for blacklisting).
Incoming SYN The rate of TCP SYN packet arrival.
Established TCP The number of established TCP sessions.
Incoming ssh The rate of attempted (not established) ssh sessions.
No listener The rate of packets arriving on closed UDP/TCP ports, where no process is
listening on a port. If the 1-minute average exceeds 61 (a packet per second or
more), a SYSTEM:DDOS warning regarding possible malicious activity is
generated in syslog.
Aggregate drops The rate of packets dropped due to an established rule.
Free controllers The number of internal control structures available for handling flood and attack
mitigation. The number drops as more active clients are established. If the
number reaches zero, no additional active clients can connect. Note: There is not
a one-to-one correspondence between the number of free controllers and the
number of active clients, but the number must be higher than zero for the self-
defense system to handle more connections.
Top offenders Displays the top attacking IP addresses and related information.
387
Using BFD
You can configure the Secure64 DNS Cache server to use the bidirectional forwarding
detection (BFD) protocol to provide fast failover detection for configured remote peers. BFD
makes no routing decisions. It simply detects and informs routers whether or not the session
between BFD peers is still operational.
Although it is independent from BGP, you can use BFD in conjunction with BGP because it
typically detects failures faster than BGP. (For more information about using BGP with
Secure64 DNS Cache, see Chapter 8. Enabling BGP for Anycast on page 303.)
Configuring BFD
To configure the BFD service:

1. Login as a user with access to the cachednsadmin role.
3. In the default directory of the cachednsadmin role, create the bfd.conf configuration
file. Configuration attributes are described in Table 59:
Table 59. BFD configuration attributes
Attribute: Value
interface: <IP address> IPv4 or IPv6 address of the Secure64 DNS Cache server
interface: 192.168.127.99 to listen on for incoming BFD packets. This must be a
configured interface on the server and at least one
interface is required.
peer: <IP address> <rx_interval> A remote BFD peer, where:
<tx_interval> <multiplier> <IP address> IPv4 or IPv6 address of the remote BFD
peer: 192.168.2.1 100 100 5 peer.
<rx_interval> The minimum interval between received
BFD control packets in milliseconds. Typical values are
between 100 and 10000. Values higher than 10000
defeat the purpose of BFD. Values lower than 100 can
result in instability of the BFD session.
<tx_interval> The minimum interval when transmitting
BFD control packets in milliseconds. Typical values are
between 100 and 10000. Values higher than 10000
defeat the purpose of BFD. Values lower than 100 can
result in instability of the BFD session.
<multiplier> The amount to multiply the negotiated
transmit interval by to determine the connection failure
detection time. Typical values are 3-10. Higher values
result in increased failure detection time, and lower
values can result in instability of the BFD session.
There must be at least one peer configured.
4. If you want to add comments, proceed the comment lines with the # symbol.
5. Save the bfd.conf configuration file.
388
BFD Commands
To start the BFD service:

3. Type start bfd and press ENTER.
Note If you want BFD to automatically start/stop when you start/stop the DNS server, add the following to the
server: section of the cache.conf configuration file:
bfd-auto-start: yes
Example:
[cachednsadmin@Secure64]# start bfd
BFD started
To stop the BFD server:

3. Type stop bfd and press ENTER.
Example:
[cachednsadmin@Secure64]# stop bfd
BFD stopped
To display the BFD service status:

• At any prompt, type show bfd status and press ENTER.
Example:
[cachednsadmin@Secure64]# show bfd status
BFD service is running
To display the information about the BFD session:

1. At any prompt, type show bfd status and press ENTER to verify that the service is
running.
2. Type show bfd info and press ENTER.
3. The system displays information about the current BFD session.
389
Example:
[cachednsadmin@Secure64]# show bfd info
BFD peer 192.168.2.1

rx_interval : 100
rx_pkts : 0
rx_diag : No Diagnostic
tx_interval : 100
tx_pkts : 4
tx_diag : No Diagnostic
multiplier : 5
local_disc : 15093
peer_disc : 0
state : Down
tx intv neg : 100
rx intv neg : 100
390
Implementing SNMP
About SNMP and Secure64 DNS Cache
You can configure the Secure64 DNS Cache software to act as an SNMP (Simple Network
Management Protocol) host agent for reporting information about the server. As an SNMP host
agent, Secure64 DNS Cache supports a set of managed information bases (MIBs) that you can
import into an SNMP management application or NMS (Network Management System) to
retrieve information about the server. It also supports sending a variety of SNMP traps related to
the server and mitigation of attack behavior.
The Secure64 DNS Cache SNMP host agent:
• Complies with SNMP v2c as defined in RFC 1901, RFC 1905, and RFC 1906
• Supports SNMP get requests (GetRequest, GetNextRequest, and GetBulkRequest)
• Does not support SNMP set requests
• Sends SNMP v2c trap notifications to the configured SNMP management application or
NMS
• Uses the IANA PEN (Private Enterprise Number) 28428
• Supports multiple SNMP hosts
• Supports traditional access methods and does not currently support View-based Access
Control Model (VACM)
• Provides the snmpadmin operational role, which administers the snmpd.conf
configuration file and commands for configuring and managing the Secure64 DNS Cache
SNMP host agent
391
Supported SNMP MIBs

Secure64 DNS Cache provides support for a collection of RFC-standard MIBs and proprietary
MIBs as listed in Table 60:
Table 60. Supported SNMP MIBs
RFC or Secure64
MIB Filename Proprietary Description
SNMPv2-MIB.txt RFC 3418 Standard SNMPv2 MIB objects and traps.
HOST-RESOURCES-MIB.txt Host resources MIB objects; used with HOST-
RFC 2790
RESOURCES-TYPES.txt.
HOST-RESOURCES-TYPES.txt Type definitions for storage, device, and file system
RFC 2790
types; used with HOST-RESOURCES-MIB.txt.
IF-MIB.txt RFC 2863 Network interfaces MIB objects.
IP-MIB.txt RFC 4293 IP and ICMP MIB objects.
TCP-MIB.txt RFC 4022 TCP MIB objects.
UDP-MIB.txt RFC 4113 UDP MIB objects.
Secure64 product platform object identifiers, resulting
Secure64 in the sysObjectID value of 1.3.6.1.4.1.28428.1.3 for
SECURE64-PRODUCTS-MIB.txt
Proprietary Secure64 DNS Cache and 1.3.6.1.4.1.28428.1.4 for
Secure64 DNS Signer; requires SECURE64-SMI.txt.
S64-MITIGATION-MIB.txt Mitigation and defense traps for irregular traffic flows
Secure64 directed at the Secure64 DNS server. See Secure64
Proprietary Mitigation Trap Type Categories and Notifications on
page 406 for details. Requires SECURE64-SMI.txt.
S64-CACHE-MIB.txt Caching server statistics and metrics objects. Refer to
Secure64
the MIB contents for details. Requires SECURE64-
Proprietary
SMI.txt.
S64-CHASSIS-MIB.txt Secure64 Information about the state of the Secure64 hardware
Proprietary platform.
SECURE64-SMI.txt Secure64
Secure64 Structure of Management Information (SMI).
Proprietary
Note Not all objects within the RFC standard MIBs apply to the Secure64 DNS Cache server or are
supported.
392
SNMP Configuration Checklist

Refer to Table 61 for a checklist of steps for SNMP configuration.
Table 61. SNMP configuration
Completed Description Reference

Importing the Secure64 DNS Cache MIBs into
Download and import the Secure64 MIBs and SMI
the NMS on page 394
If needed, configure interfaces on the Secure64 DNS SNMP Configuration Preparations on
server for SNMP page 399
Creating or Editing the SNMP Configuration
Create the Secure64 snmpd.conf configuration file
File on page 400
Configure the auto-start, agentaddress, rocommunity/
rocommunity6, maximum get bulk, and system object
attributes in snmpd.conf.
Defining the SNMP Configuration in Secure64
(If you want the server to respond to SNMP get
DNS Cache on page 394
requests, you must configure at least one
agentaddress and either rocommunity or
rocommunity6.)
If you want to configure a receiver for standard traps,
define a trapcommunity and/or trap2sink in the
snmpd.conf configuration file
If you want to receive authentication traps, enable the
authtrapenable attribute in the snmpd.conf
configuration file
If you want to receive traps regarding information Defining the SNMP Configuration in Secure64
about the Secure64 hardware, enable the DNS Cache on page 394
chassistrapenable attribute in the snmpd.conf Secure64 Chassis Trap Type Categories and
configuration file Notifications on page 412
If you want to receive Secure64 Mitigation MIB traps, DNS Cache on page 394
enable the desired traps and blacklist/graylist
intervals in the snmpd.conf configuration file Secure64 Mitigation Trap Type Categories and
Notifications on page 406
Start the SNMP host agent and check for
Stopping and Starting SNMP on page 402
configuration errors
Test the SNMP host agent Troubleshooting SNMP on page 405
Testing Secure64 Mitigation SNMP Traps on

Test the mitigation traps (if enabled)
page 411
Back up the SNMP configuration Backing Up SNMP Information on page 405
393
Importing the Secure64 DNS Cache MIBs into the NMS
To configure your NMS software for Secure64 MIBs:

1. Download the SECURE64-SMI and the desired Secure64 proprietary MIBs from the
Secure64 support web site at www.secure64.com/support.
Note s64-cache-mib.txt, secure64-products-mib.txt, s64-mitigation-mib, and s64-chassis-mib depend on

secure64-smi.txt. For best results all MIBs should be loaded.
Standard IETF MIBs, such as IF-MIB.txt and IP-MIB.txt, are normally included with the NMS software.
You can also find the IETF MIBs in MIB repositories such as http://www.mibDepot.com.
2. Import the SMI file and MIB files into your NMS software.
3. Follow the procedures as outlined in your NMS software to configure SNMP for use
with the Secure64 DNS Cache server SNMP host agent.
Defining the SNMP Configuration in Secure64 DNS Cache

The following sections describe how to configure the Secure64 DNS Cache server as an SNMP
host agent. To configure SNMP, you must specify the SNMP parameters in a text file named
snmpd.conf. The file is stored in the root directory of the Secure64 DNS snmpadmin role. A
user account that needs access to SNMP commands and configuration must be assigned to the
snmpadmin role.
Format and Rules

The configuration file snmpd.conf is a text file that defines SNMP configuration information
for the Secure64 DNS server’s host agent. It is a subset of the Net-SNMP configuration
(www.net-snmp.org). Syntax and rules are as follows:
• Quotation marks are optional for strings.
• Parameters and corresponding values are separated by a space.
394
Below is an example snmpd.conf file with:

auto-start no
# Attributes for receiving and responding to SNMP requests
agentaddress udp:192.168.127.99
rocommunity public 192.168.2.0/24
maxGetbulkRepeats 0
maxGetbulkResponses 100
sysLocation server room number 5, rack 10
sysContact John Doe
sysName DNS server 4
sysServices 72
sysDescr Secure64 DNS, HP rx2660
# Attributes for sending SNMP traps
trapcommunity public
trap2sink 192.168.2.1
authtrapenable enable
chassistrapenable enable
blacklisttrapenable enable
graylisttrapenable enable
synfloodtrapenable enable
packetfloodtrapenable enable
blacklist-interval 60
graylist-interval 60
395
SNMP Configuration Parameters

Table 62 describes the SNMP-related configuration parameters for the snmpd.conf
configuration file.
Table 62. Secure64 SNMP configuration parameters in snmpd.conf
Command Description
auto-start <yes|no> Determines whether the SNMP host agent starts
auto-start yes automatically upon boot.
Define the Secure64 DNS Cache listening
address(es) for incoming SNMP requests. For the
server to respond to SNMP requests, you must
define at least one agentadress and either
rocommunity or rocommunity6.
For UDP over IPv4 transport, use the udp prefix.
agentaddress <udp|udp6>:<transport_address>[:port] For UDP over IPv6 transport, use the udp6 prefix.
agentaddress udp:192.168.2.1 For transport-address, use a dotted decimal IPv4
agentaddress udp6:[2001:470:1f04:446:f002::1] address (udp), or a hexadecimal IPv6 address
agentaddress udp:192.168.127.99:161 wrapped by square braces (udp6).
For multiple addresses, use multiple
agentaddress lines.
Note: You must use IP address(es) configured for
Secure64 DNS Cache. If you need to configure
an IP address, see Adding and Removing IP
Addresses for Interfaces on page 276.
rocommunity <community> [source_ip/prefix [OID]] If one or more udp agentaddress(es) are
rocommunity myprivatecommunity specified, a corresponding rocommunity is
rocommunity public 192.168.2.0/24 required. Define an SNMPv2c community for
rocommunity public 192.168.2.0/24 .1.3.6.1.2.1.1 traditional read-only (GET and GETNEXT)
access.
To restrict access to a specified system or
systems, define source_ip/prefix as an IPv4
address followed by the prefix size.
To restrict access to a subtree, define OID as the
root of the subtree to restrict access to.
rocommunity6 <community> [source_ip/prefix [OID]] If one or more udp6 agentaddress(es) are
rocommunity6 myprivatecommunity specified, a corresponding rocommunity6 is
rocommunity6 public 2001:470:1f04:446:f002::/96 required. Define an SNMPv2c community for
traditional read-only (GET and GETNEXT)
access.
To restrict access to a specified system or
systems, define source_ip/prefix as an IPv6
address followed by the prefix size.
To restrict access to a subtree, define OID as the
root of the subtree to restrict access to.
396
maxGetbulkRepeats <num> Sets the maximum number of responses allowed

maxGetbulkRepeats 0 for a single variable in an SNMP GETBULK
request.
For num use:
0 for the default value from the request
-1 for an unlimited number of responses
An integer that sets the maximum, even if the
GETBULK request defines a larger number
Note: Because memory is allocated ahead of
time, defining -1 is not recommended if the
GETBULK source(s) cannot be trusted.
If undefined, the default is 0.
maxGetbulkResponses <num> Sets the maximum number of responses allowed
maxGetbulkResponses 100 for an SNMP GETBULK request.
For num use:
0 for the default value from the request
-1 for an unlimited number of responses
An integer that sets the maximum, even if the
GETBULK request defines a larger number
Note: Because memory is allocated ahead of
time, defining -1 is not recommended if the
GETBULK source(s) cannot be trusted. Also,
processing of maxGetbulkRepeats occurs
first.
If undefined, the default is 100.
sysLocation <string> Sets the system location information
sysLocation Denver (sysLocation.0), limited to 256 characters.
sysLocation 3rd floor, rack 15 If undefined, the default is “unknown”
sysContact <string> Sets the system contact information
sysContact Joe Smith joe.smith@example.com (sysContact.0), limited to 256 characters.
If undefined, the default is “@”
sysName <string> Sets the system name information (sysName.0),
sysName Zoro limited to 256 characters.
If undefined, the default is “unknown”
sysServices <num> Sets the system services value (sysServices.0). A
sysServices 72 good value for a host offering application services
is 72 (application + end-to-end layers).
If undefined, the default is no value.
sysDescr <string> Sets the system description information
sysDescr Secure64 DNS Server, HP rx2660 (sysDescr.0), limited to 256 characters.
If undefined, the default is “uknown”
trapcommunity <string> Configure the SNMP community string for traps.
trapcommunity public List trapcommunity in the configuration file
prior to any community-based trap destinations
(trap2sink).
If undefined, the default is public. The string is
limited to 32 characters.
397
<trap2sink> <host>[:port][:source_ip] Use the trap2sink attribute to define the

[community] [port] format and receivers for standard and Secure64
trap2sink 192.168.127.1 SNMP trap notifications.
trap2sink [2001:470:1f04:446:f002::1] mycommunity For host, use a dotted decimal IPv4 address
(udp), or a hexadecimal IPv6 address wrapped by
square braces (udp6). An optional source_IP can
be appended to the host'. If the source IP is
specified, the port must specified (for example,
192.168.2.2:162:192.168.2.1).
For multiple addresses, use multiple
trap2sink lines.
If community is not specified, the string from the
trapcommunity attribute is used. If port is not
specified, the SNMP trap port (162) is used.
authtrapenable <1|2|enable|disable> Determines whether to generate authentication
authtrapenable enable failure traps. To enable the traps, set the value to
1 or enable. A trap is sent if an SNMPget is
received with an unmatched community string.
If undefined, the default is 2 (disable).
chassistrapenable <1|2|enable|disable> Determines whether to generate chassis
chassistrapenable enable information traps. To enable the traps, set the
value to 1 or enable.
When enabled, traps are sent when a periodic
polling of the chassis health sensors detects a
change in state. The supported traps include
temperaturetrap, voltagetrap, fantrap,
chassisintrusiontrap, powersupplytrap, and
powerredundancytrap.
blacklisttrapenable <1|2|enable|disable> Determines whether to generate blacklist traps as
blacklisttrapenable enable defined in the S64-MITIGATION-MIB. To enable
the traps, set the value to 1 or enable and
configure a blacklist-interval. For
additional details, see Secure64 Mitigation Trap
Type Categories and Notifications on page 406.
blacklist-interval <seconds> Configure if sending blacklist traps. Define the
blacklist-interval 60 interval to send blacklist update events. For
If undefined, the default is 0 (disabled).
graylisttrapenable <1|2|enable|disable> Determines whether to generate graylist traps as
graylisttrapenable enable defined in the S64-MITIGATION-MIB. To enable
the traps, set the value to 1 or enable and
configure a graylist-interval. For additional
details, see Secure64 Mitigation Trap Type
Categories and Notifications on page 406.
398
graylist-interval <seconds> Configure if sending graylist traps. Define the

graylist-interval 60 interval to send graylist update events. For
If undefined, the default is 0 (disabled).
packetfloodtrapenable <1|2|enable|disable> Determines whether to generate packet flood
packetfloodtrapenable enable traps as defined in the S64-MITIGATION-MIB. To
enable the traps, set the value to 1 or enable. For
synfloodtrapenable <1|2|enable|disable> Determines whether to generate SYN flood traps
synfloodtrapenable enable as defined in the S64-MITIGATION-MIB. To
enable the traps, set the value to 1 or enable. For
SNMP Configuration Preparations

To configure SNMP, you need to configure interfaces for SNMP traffic and the DNS server. You
can use an existing interface or configure a new interface for SNMP services.
To view your current system configuration, which includes configured interfaces and IP
addresses:
• Type show config at any prompt, and press ENTER.
Example:
[sysadmin@Secure64DNS]# show config
ifconfig eth0 192.168.95.99 255.255.255.0
ifconfig eth1 192.168.127.99 255.255.255.0
console eth0
route default 10.81.0.2
route sym
nameserver 0 192.168.95.95 4
ntp 2001:db8::1
tz MST7MDT
syslog 192.168.95.95
loglevel 5 75
nodename Secure64DNS
rule actions enabled
timeout 300
ip frag timeout 5
ip frag high 40
ip frag low 30
399
If you want to configure additional interface(s) for SNMP services:

• At the sysadmin prompt, type the following and press ENTER:

ethX, ethX.I, or ethX:V.I and
V= the VLAN ID
addresses for each physical interface, 1-255)
Creating or Editing the SNMP Configuration File

To define the snmpd.conf SNMP configuration file contents, you can start by creating a new
file or by copying the included example.snmp.conf file to snmpd.conf.
To edit the SNMP configuration file:

2. At the view prompt, type enable snmpadmin and press ENTER to enable the
snmpadmin role.
3. To start with an empty file, type edit snmpd.conf and press ENTER.
To use the example.snmpd.conf, use the cp command to copy the
example.snmpd.conf to snmpd.conf in the root directory of the snmpadmin role.
Then type edit snmpd.conf and press ENTER to open the snmpd.conf configuration
file for editing.
4. Define the SNMP parameters as appropriate for your system in the snmpd.conf file.
For details about the configuration parameters, refer to the SNMP Configuration Checklist
on page 393 and SNMP Configuration Parameters on page 396.
5. Save the snmpd.conf file and exit the Secure64 DNS Cache editor.
6. If SNMP is already enabled and running, type stop snmp and press ENTER to stop
the service.
Note You must stop and start SNMP to read the new configuration. This clears the current SNMP session.
400
7. To start SNMP, type start snmp and press ENTER.

If there are configuration errors, messages display and the SNMP host agent does not
start. Refer to Troubleshooting SNMP on page 405 for more information.
Using SNMP Commands

SNMP commands are available only to user accounts that have been assigned the snmpadmin
role in Secure64 DNS Cache. Table 63 lists the SNMP administration and information
commands.
Table 63. SNMP commands
Command Description
SNMP administration commands
start snmp Reads the snmpd.conf configuration file and enables SNMP host
agent services for Secure64 DNS Cache.
stop snmp Stops SNMP services for Secure64 DNS Cache.
sendtrap <type> Sends the specified S64-MITIGATION-MIB trap type event or S64-
CHASSIS-MIB trap type event for testing purposes.
For S64-MITIGATION-MIB traps, specify <type> as one of the following:
blacklist, blacklistactive, blacklistinactive, graylist, graylistactive,
graylistinactive, packetfloodstart, packetfloodend, synfloodstart,
synfloodend.
For S64-CHASSIS-MIB traps, specify <type> as one of the following:
temperaturetrap, voltagetrap, fantrap, chassisintrusiontrap,
powersupplytrap, powerredundancytrap
For details, see Secure64 Mitigation Trap Type Categories and
Notifications on page 406.
SNMP information commands (Available in all modes)
show snmp config Displays the information in the snmpd.conf configuration file.
show snmp info Displays details about SNMPv2-MIB information
show snmp status Displays the current state of the SNMP system in Secure64 DNS Cache.
401
Stopping and Starting SNMP
To start the SNMP host agent:

2. At the view prompt, type enable snmpadmin and press ENTER.
3. Secure64 DNS Cache reads the snmpd.conf file and starts the SNMP host agent if no
errors are detected.
Example:
[snmpadmin@Secure64DNS]# start snmp
Started transport, UDP: [192.168.95.113]:161.
Started transport, UDP: [192.168.127.113]:161.
Successfully started snmp agent
To stop the SNMP host agent:

2. At the view prompt, type enable snmpadmin and press ENTER.
3. At the snmpadmin prompt, type stop snmp and press ENTER.
4. The server stops the SNMP host agent.
Example:
[snmpadmin@Secure64DNS]# stop snmp
Stopping snmp
Successfully stopped transport, UDP: [192.168.95.113]:161.
Successfully stopped transport, UDP: [192.168.127.113]:161.
Successfully stopped snmp
Viewing the Current SNMP Host Agent State
To view the current state of the SNMP system:

1. At any Secure64 DNS Cache prompt, type show snmp status and press ENTER.
2. The server displays SNMP status.
Note Secure64 DNS Cache also generates messages related to the status of the SNMP server in syslog.
For details, see System Logging Messages on page 443
402
Example:
[view@Secure64DNS]> show snmp status
snmp agent is running
Viewing SNMP Information

To view SNMP information and statistics:
1. At any Secure64 DNS prompt, type show snmp info and press ENTER.
2. Secure64 DNS Cache displays SNMP information.
Example:
[view@Secure64DNS]> show snmp info
snmp agent info:
snmpInPkts 0
snmpOutPkts 1
snmpOutTraps 1
snmpInBadVersions 0
snmpInBadCommunityNames 0
snmpInBadCommunityUses 0
snmpInASNParseErrs 0
snmpEnableAuthenTraps 0
snmpSilentDrops 0
snmpProxyDrops 0
Viewing SNMP Configuration

To view SNMP configuration information (snmpd.conf):
1. At any Secure64 DNS prompt, type show snmp config and press ENTER.
2. Secure64 DNS Cache displays the SNMP configuration.
403
Example:
[view@Secure64DNS]> show snmp config
auto-start off
blacklist-interval 0
graylist-interval 0
maxGetbulkRepeats 0
maxGetbulkResponses 100
agentaddress 192.168.127.113,192.168.95.113
rocommunity public 192.168.95.99
syscontact m@whitehall
sysname jackrabbit
sysdescr Secure64 DNS server
syslocation server room
synfloodtrapenable is disabled
blacklisttrapenable is disabled
packetfloodtrapenable is disabled
graylisttrapenable is disabled
Testing SNMP
In addition to the SNMP commands in Secure64 DNS Cache described in Using SNMP
Commands on page 401, you can use the Net-SNMP software suite (www.netsnmp.org) to test
and troubleshoot SNMP. The Net-SNMP suite includes command-line applications to:
• Retrieve information from an SNMP-capable device, either using single requests
(snmpget, snmpgetnext), or multiple requests (snmpwalk, snmptable, snmpdelta).
Note To obtain all of the SNMP information from a Secure64 DNS server, issue the following command from
a system that has the Net-SNMP software installed:
snmpwalk -v 2c -r 0 -c <community_name> <S64_server_ipaddresss> 1.3
• Manipulate configuration information on an SNMP-capable device (snmpset).

• Retrieve a fixed collection of information from an SNMP-capable device (snmpdf,
snmpnetstat, snmpstatus).
• Convert between numerical and textual forms of MIB OIDs, and display MIB content
and structure (snmptranslate).
You can use these command-line tools installed on another system or other SNMP utilities to
verify that the Secure64 DNS Cache SNMP host agent provides the expected information and
traps.
404
Troubleshooting SNMP
If the SNMP host agent is not responding as expected, you can troubleshoot the issue by:
• Monitoring SNMP error logging in syslog
Secure64 DNS Cache sends SNMP-related messages to syslog. The number and type of
messages sent depend upon the severity level configured. For more information about
configuring syslog, see Managing Syslog Servers and Local Logging on page 269.
• Verifying the contents and syntax of the snmpd.conf configuration file using the show
snmp config command
• Checking SNMP information using the show snmp info command
• Using the Net-SNMP tool or other tools
Backing Up SNMP Information
To back up SNMP information, use the scp command as follows:

scp –r [-P <port>] <user>@<host>:/snmpadmin/* <backup_dest>
where:
<user> is the user account assigned to the snmpadmin role
<backup_dest> is the destination for the backup files
To restore SNMP information, use the scp command as follows:

scp –r [-P <port>] <backup_dest>/* <user>@<host>:/snmpadmin/
where:
<backup_dest> is the location of the backup files,
<user> is a user account assigned to the snmpadmin role, and
405
Secure64 Mitigation Trap Type Categories and Notifications

Secure64 DNS Cache offers a MIB for mitigation and defense information (S64-
MITIGATION-MIB). The MIB defines the following types of SNMP traps:
• Black listing traps
• Gray listing traps
• Packet flood traps
• SYN flood traps
The following sections provide more information about each trap type.
Note To receive black list, gray list, and packet flood traps, you must configure one or more mitigation rules
and attach the rule(s) to the Secure64 DNS Cache name server. This is in addition to importing the
S64-MITIGATION-MIB into your NMS. For details, see Configuring UDP Rate Limit or Drop Rules on
page 234, Configuring TCP Rules for SSH and DNS Traffic on page 236, and DNS RRtype Filtering
Rules on page 238.
406
Blacklist Traps
The blackListActive, blackListInActive, and blackList traps and objects listed in the following
table are sent when you enable the blacklist trap type category with the blacklisttrapenable
configuration attribute in the snmpd.conf configuration file.
and attach the rule(s) to the Secure64 DNS Cache name server. This is in addition to importing the S64-
MITIGATION-MIB into your NMS. For details, see Configuring UDP Rate Limit or Drop Rules on
Rules on page 238.
407
Graylist Traps
The grayListActive, grayListInActive, and grayList traps and objects listed in the following table
are sent when you enable the graylist trap type category with the graylisttrapenable
and attach the rule(s) to the Secure64 DNS Cache name server. This is in addition to importing the
S64-MITIGATION-MIB into your NMS. For details, see Configuring UDP Rate Limit or Drop Rules on
Rules on page 238.
Table 64. Graylist control traps
Trap Description Object ID

At least one IP address is on the
grayListActive 1.3.6.1.4.1.28428.2.1.0.8
gray list.

grayListInActive No IP addresses are gray listed. 1.3.6.1.4.1.28428.2.1.0.9

Informational message that
reports the state of the gray list:
rising, falling, unchanged. The
grayList message includes the current 1.3.6.1.4.1.28428.2.1.0.10
number of IP addresses on the list
and previous number from the last
update.
Object Identifier Type: Description Object ID

Integer: Reports gray list IP
address activity since last update:
grayListState (1) grayListRising; 1.3.6.1.4.1.28428.2.1.1.8
(2) grayListFalling;
(3) grayListUnchanged
Integer32: Number of gray or
previousNumIPsOnList black listed IP addresses reported 1.3.6.1.4.1.28428.2.1.1.7
in previous black list update.
Integer32: Current number of
currentNumIPsOnList 1.3.6.1.4.1.28428.2.1.1.6
gray or black listed IP addresses.
408
Packet Flood Traps

The packetFloodStart and packetFloodEnd traps and objects listed in the following table are sent
when you enable the packetflood trap type category with the packetfloodtrapenable
and attach the rule(s) to the Secure64 DNS Cache name server. This is in addition to importing the S64-
MITIGATION-MIB into your NMS. For details, see Configuring UDP Rate Limit or Drop Rules on
Rules on page 238.
Table 65. Packet flood control traps

packetFloodStart A packet flood has been detected. 1.3.6.1.4.1.28428.2.1.0.3

Counter64: A counter that holds the
packetRateThreshold packet rate limit as defined by the rate 1.3.6.1.4.1.28428.2.1.1.4
limit or mitigation rule.
currentPacketRate current number of incoming packets per 1.3.6.1.4.1.28428.2.1.1.5
second.
Octet string: The network protocol
networkProtocol 1.3.6.1.4.1.28428.2.1.2.1
defined by the rate limit or mitigation rule.
Integer32: The UDP or TCP port defined
networkPort 1.3.6.1.4.1.28428.2.1.2.2
by the rate limit or mitigation rule.

packetFloodEnd A packet flood is no longer detected. 1.3.6.1.4.1.28428.2.1.0.4

packetRateThreshold packet rate limit as defined by the rate 1.3.6.1.4.1.28428.2.1.1.4
limit or mitigation rule.
currentPacketRate current number of incoming packets per 1.3.6.1.4.1.28428.2.1.1.5
second.
Octet string: The network protocol
networkProtocol 1.3.6.1.4.1.28428.2.1.2.1
defined by the rate limit or mitigation rule.
Integer32: The UDP or TCP port defined
networkPort 1.3.6.1.4.1.28428.2.1.2.2
by the rate limit or mitigation rule.
409
SYN Flood Traps

The synFloodStart and synFloodEnd traps and objects listed in the following table are sent
when you enable the synflood trap type category with the synfloodtrapenable
Table 66. SYN flood control traps

synFloodStart A SYN flood has been detected. A 1.3.6.1.4.1.28428.2.1.0.1
SYN flood is determined based on
a statistical analysis of the rate of
incoming SYN packets versus the
rate of connection establishment.

synRateThreshold A counter that holds the threshold 1.3.6.1.4.1.28428.2.1.1.2
value for the number of SYN
packets received by the system.
currentSynRate A counter that holds the current 1.3.6.1.4.1.28428.2.1.1.3
number of incoming SYN packets
per second.

synFloodEnd A SYN flood is no longer 1.3.6.1.4.1.28428.2.1.0.2
detected.

synRateThreshold A counter that holds the threshold 1.3.6.1.4.1.28428.2.1.1.2
value for the number of SYN
packets received by the system.
currentSynRate A counter that holds the current 1.3.6.1.4.1.28428.2.1.1.3
number of incoming SYN packets
per second.
410
Testing Secure64 Mitigation SNMP Traps

Secure64 DNS Cache includes commands that let you test SNMP mitigation trap functionality.
After configuring SNMP for Secure64 DNS Cache and your NMS trap receiver, use the
commands below to verify they are working.
To test SNMP traps:

1. Enable the snmpadmin role.
2. At the snmpadmin prompt, type sendtrap <type>, where <type> is the type of event to
test as defined in the list below:
blacklist
blacklistactive
blacklistinactive
graylist
graylistactive
graylistinactive
packetfloodstart
packetfloodend
synfloodstart
synfloodend
3. If the trap is sent successfully, the system displays Trap sent.
Example:
[snmpadmin@Secure64DNS]# sendtrap blacklist
Trap sent
If the trap is not sent successfully, the system displays an error message:
• Unrecognized Trap Type- Verify that you are entering the command and the trap event
type using correct spelling and upper- and lower-case letters.
• sendtrap failed- Type show snmp config and verify SNMP settings. If you change the
configuration or make corrections to it, type stop snmp and start snmp to read the
changes before retrying the test trap. Secure64 DNS Cache also generates messages
related to the status of the SNMP server in syslog.
411
Responding to SNMP Mitigation Trap Events

In addition to sending the SNMP traps you have configured, the Secure64 DNS Cache
reporting and logging system records statistical data and event-specific data to syslog. The
syslog messages are sent as SYSTEM:DDOS at the LOG_ALERT level.
Statistical data closely parallels the SNMP trap behavior, and event-specific data identifies
events associated with specific hosts and/or IP addresses. You can use this information to help
defend your system against attack. For details about mitigation reporting and logging, see
Appendix B. Syslog and System Boot Messages on page 443.
You can also use the show defense info command to display statistical information. For more
information, see Displaying Mitigation and Self-Defense Statistics on page 386.
Secure64 Chassis Trap Type Categories and Notifications

Secure64 DNS Cache offers a MIB for chassis and hardware status information (S64-
CHASSIS-MIB). The MIB defines the following types of SNMP traps, which are sent when the
sensor state changes:
• Temperature
• Voltage
• Fan
• Chassis intrusion
• Power supply
• Power redundancy
Note The S64-CHASSIS-MIB must be installed on your NMS. For details, see Importing the Secure64 DNS
Cache MIBs into the NMS on page 394.
To enable the chassis status traps:

1. Log in as a user assigned to the snmpadmin role.
2. Type enable snmpadmin and press ENTER.
3. Add the following attribute to the snmpd.conf SNMP configuration file:
— chassistrapenable enable
4. Exit and log in as a user assigned to the sysadmin role.
5. Type enable sysadmin and press ENTER.
6. To set the interval for collecting sensor information, type the following command:
chassispoll <seconds>
where <seconds> is the polling interval, between 1 and 86400 (1 day).
7. To save the change, type activate and press ENTER, then type save and press
ENTER.
412
Chassis Status Trap Details

After enabling chassis traps in the snmpd.conf configuration file and configuring the
chassispoll command, the following chassis MIB notifications are sent when the system
detects state changes:
Table 67. Chassis traps

temperature Reports an ambient or CPU
1.3.6.1.4.1.28428.6.1.4.1
temperature sensor state change
voltage Reports a battery voltage sensor
state change between
1.3.6.1.4.1.28428.6.1.4.2
performance met and
performance lags
fan Reports a fan voltage sensor
state change between
1.3.6.1.4.1.28428.6.1.4.3
performance met and
performance lags
chassisIntrusion Reports when the chassis cover
1.3.6.1.4.1.28428.6.1.4.4
has been opened or closed
powerSupply Reports a power supply sensor
state change state between OK, 1.3.6.1.4.1.28428.6.1.4.5
Failure, or Not Present
powerRedundancy Reports a power supply
1.3.6.1.4.1.28428.6.1.4.6
redundancy change
var binds Description Object ID

trap varbind Each trap contains a single string 1.3.6.1.4.1.28428.6.1.3.1.0
varbind detailing the state change
413
Testing Chassis Status Traps

Secure64 DNS Cache includes commands that let you test chassis information trap
functionality. After configuring SNMP for Secure64 DNS Cache and your NMS trap receiver,
use the commands below to verify they are working.
To test the chassis traps:

1. Enable the snmpadmin role.
2. At the snmpadmin prompt, type sendtrap <type>, where <type> is the type of event to
test as defined in the list below:
temperaturetrap
voltagetrap
fantrap
chassisintrusiontrap
powersupplytrap
powerredundancytrap
3. If the trap is sent successfully, the system displays Trap sent.

4. To verify the information reported by the trap, type show sensors and press ENTER.
If the trap is not sent successfully, the system displays an error message:
• Unrecognized Trap Type- Verify that you are entering the command and the trap
event type using correct spelling and upper- and lower-case letters.
• sendtrap failed- Type show snmp config and verify SNMP settings. If you change
the configuration or make corrections to it, type stop snmp and start snmp to read
the changes before retrying the test trap. Secure64 DNS Cache also generates messages
related to the status of the SNMP server in syslog.
414
Using the Secure64 DNS Cache dig Command

For the sysadmin and cachednsadmin roles, Secure64 DNS Cache includes a simplified version of
the Internet Systems Consortium (ISC) dig command. You can use the dig command to perform
different types of DNS queries and examine the responses for testing and troubleshooting.
Note The output of the dig command is a representation of a DNS message. For a detailed description of DNS
message contents, refer to RFC 1035, RFC 2136, and http://www.zytrax.com/books/dns/ch15/.
The basic syntax of the command is:

dig @<server> [<name>] [<type>] [<+queryopt>...] [<-flag>...]
415
Table 68 describes the dig command components.
Table 68. Components of the dig command
Component Description
server Name or IPv4/IPv6 address of the DNS server to query. If you define a host name,
dig attempts to resolve the name before querying the server.
Note: You can query the same server you are running the dig command on.
name Host of domain name for the query.
type Type of resource record (RR) to query. Supported types include:
A (default if none specified)
AAAA
AFSDB
APL
AXFR
CERT
CNAME
DNAME
DS
HINFO
ISDN
IXFR=sn (where sn is the SOA serial number)
KX
LOC
MG
MINFO
MR
MX
NAPTR
NS
NSAP
NXT
PTR
PX
RP
RT
SOA
SRV
SSHFP
TLSA
TXT
WKS
X25
416
+queryopt Query option keywords. Precede each query option with a plus symbol (+). Some
keywords set or reset an option, using the string 'no' to negate the meaning of the
keyword. Other keywords assign values to options and have the form
+keyword=value.
+[no]tcp
Use [do not use] TCP when querying name servers. The default behavior is to use
UDP unless an AXFR or IXFR query is requested, which uses TCP.
+[no]cdflag
Set [do not set] the CD (checking disabled) bit in the query. Use +cdflag to
disable DNSSEC validation of responses by the destination server.
+[no]short
Provide [do not provide] a terse answer. The default is verbose.
+time=<seconds>
Set the timeout for a query to seconds. The default is 5 seconds, and the minimum
is 1 second.
+tries=<number>
Set the number of times to try UDP queries. The default is 3, and the minimum is 1.
+retry=<number>
Set the number of times to retry the UDP queries. The default is 2. Unlike
+tries, this does not include the initial query.
+bufsize=<B>
Set the UDP message buffer size advertised using EDNS0 to <B> bytes.The
maximum and minimum sizes of this buffer are 65535 and 0, respectively. Values
other than zero cause an EDNS query to be sent.
+[no]dnssec
Request [do not request] DNSSEC records by setting the DNSSEC OK bit (DO) in
the OPT record in the additional section of the query.
417
-flag -o <filename>
Define a file to use for storing the dig queryoutput. When performing an AXFR or
IXFR query, use this option to avoid displaying large amounts of data. (Note: This
option is available only to the cachednsadmin role. The sysadmin role does not
have file system privileges.)
-p <port>
Define an alternate port of the DNS server to query. If not defined, the default is
DNS port 53.
-b <ip_address>[#port]
Define a source IP address and optional port to send the query from. The address
must be locally configured.
-k <filename>
Specify a TSIG key file to sign the DNS queries and responses using transaction
signatures.
-y [<hmac>:]<name>:<key>
Specify a TSIG key on the command line.
<hmac>
The type of TSIG, defaulting to hmac-md5 if not defined
<name>
The name of the TSIG key.
<key>
The base-64 encoded key string.
Note: Because you can expose the key information, use only if the -k <filename>
option is not available.
Examples:
• Get the A record for any record without a label and return the SOA for the host or
domain:
[cachednsadmin@Secure64DNS]# dig @192.168.127.99 s64
; <<>> DiG SourceT 3.x <<>> @192.168.127.99 s64.
;; Got answer:
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;s64. IN A
s64. 3600 IN SOA z97. root.localhost. (578 60 100 602200 604800)
• Get the SOA for the host or domain:

[cachednsadmin@Secure64DNS]# dig @192.168.127.99 s64 soa
; <<>> DiG SourceT 3.x <<>> @192.168.127.99 s64 soa
;; Got answer:
418

;s64. IN SOA
;; ANSWER SECTION:
s64. 3600 IN SOA z97. root.localhost. (578 60 100 602200 604800 )
s64. 3600 IN NS z97.s64.
z97.s64. 3600 IN A 192.168.127.97
• Get the NS record for a host or domain:

[cachednsadmin@Secure64DNS]# dig @192.168.127.99 s64 NS
; <<>> DiG SourceT 3.x <<>> @192.168.127.99 s64 NS
;; Got answer:
;s64. IN NS
;; ANSWER SECTION:
s64. 3600 IN NS z97.s64.
z97.s64. 3600 IN A 192.168.127.97
419
420
Appendix A. Command Reference
This appendix lists and describes commands for the view, create (syscreate, cachednscreate,
bgpcreate, logincreate, securitycreate, and snmpcreate), sysadmin, cachednsadmin, bgpadmin,
loginadmin, securityadmin, snmpadmin, and upgrade roles. For additional details about
roles, see Roles and User Accounts on page 27.
Note The backup role has scp access to Secure64 DNS Cache only. The role does not have command line
access, and therefore does not execute commands on the server.
View Mode Commands

Table 69 provides information about the view mode commands. Except where noted, the
commands are available to all roles.
Table 69. View mode commands
Command Description
Log in/log out commands
Enters system administration mode (from view mode only). The user
enable sysadmin
invoking this command must be assigned to the sysadmin role.
Enters DNS administration mode (from view mode only). The user invoking
enable cachednsadmin
this command must be assigned to the cachednsadmin role.
Enters BGP administration mode (from view mode only). The user invoking
enable bgpadmin
this command must be assigned to the bgpadmin role.
Enters login administration mode (from view mode only) for authentication
enable loginadmin and login configuration. The user invoking this command must be assigned
to the loginadmin role.
Enters security administration mode (from view mode only). The user
enable securityadmin
invoking this command must be assigned to the securityadmin role.
Enters SNMP administration mode (from view mode only). The user
enable snmpadmin
invoking this command must be assigned to the snmpadmin role.
Enters upgrade mode (from view mode only). The user invoking this
enable upgrade
command must be assigned to the upgrade role.
Enters user administration mode (from view mode only). The user invoking
enable [syscreate|cachednscreate|
this command must be assigned to the syscreate, cachednscreate,
bgpcreate|logincreate|securitycreate|
bgpcreate, logincreate, securitycreate, and/or snmpcreate role. If at least
snmpcreate]
one user is assigned to all of the create roles, the Installer user is disabled.
Ends the current operational mode. In sysadmin, cachednsadmin,
exit or quit bgpadmin, securityadmin, snmpadmin, or create mode, exits to view
mode. In view mode, exits the system.
421
Command Description
Sets the password for a local user account. User accounts can modify their
own passwords and optionally omit the username parameter. User
accounts assigned to a create role define the password for the specified
passwd [username]
username, if the create role is authorized to modify the specified username
account. Passwords must be a minimum of 8 characters and include at
least 3 alphabetic characters and at least 1 non-alphabetic character.
System information commands
cpuinfo Displays processor information.
date Displays the current date and time.
Displays the current amount of available disk drive space in kilobytes.
df
(1KB=1024 bytes)
help [command] Displays the commands available in the current mode. To display help for
? [command] a specific command, include the [command] name.
memstat [-b | -k | -m | -g ] [-p] Displays available memory in kilobytes. Add -b to specify bytes, -k for
kilobytes, -m for megabytes, or -g for gigabytes. Add -p to display total
physical memory instead of available memory.
netstat [clear] Displays network statistics since last server boot or the last time statistics
were cleared with the netstat clear command.
show <cmd> Where cmd is interfaces, config, saved, or pending.
interfaces — displays information about the available physical network
interfaces, which are sequentially numbered beginning at zero.
pending — displays configuration information that is invoked when the
administrator enters the activate command in sysadmin mode
config — displays currently running system configuration
saved — displays stored configuration information, which persists after
system boot
show cachedns config [display Displays the contents of the cache.conf configuration file for the DNS
option] server. Use the display option to display a subset of the active
configuration. Options include basic, sizes, local, security, validation, zone,
nxdomain, and views.
show cachedns info [views Displays DNS statistics, if queries have been received and the server is
viewname] [instance] running. For information about a specific view, add the views argument
and the viewname to display. For information about a specific resolver
instance number, add the number of the instance.
show cachedns reload status Displays the status of the cachedns reload command operations.
show cachedns status Displays the current DNS status of the Secure64 DNS Cache server. If
multiple resolver instances are running, the number of instances are also
reported.
show authenticate config <radius | Displays the specified RADIUS or LDAP configuration information. If
ldap> [<server>] specified, information displays only for the given RADIUS or LDAP server
hostname, IPv4 address, or [IPv6] address.
show authenticate info <radius | ldap> Displays a list of RADIUS or LDAP servers in the radius.conf or
ldap.conf configuration file.
show authenticate status Displays the current authentication status of the Secure64 DNS Cache
server.
show autostart status Displays the current autostart and reboot cycle status.
show bgp config Displays the contents of the bgp.conf configuration file for BGP.
422
Command Description
show bgp fib <filter> Displays routes from the Secure64 DNS server's Forwarding Information
Base.
Note: If the FIB information contains a large number of routes, displaying
this information may require some time to complete.
For <filter>, define a specific IP address or one of the options below:
connected: Show only connected routes
static: Show only static routes
bgp: Show only routes originating from the Secure64 DNS server
nexthop: Show only routes required to reach a BGP nexthop.
show bgp info Displays information about the messages sent and received by BGP on
show bgp interfaces Displays the interface states.
show bgp neighbor <peer> <modifier> Displays detailed information about the neighbor identified by the peer.
<peer> can be the neighbor's IPv4/IPv6 address or description, according
to the modifier defined.
For <modifier>, define one of the options below:
messages: Show statistics about sent and received BGP messages.
timers: Show the BGP timers.
show bgp nexthop Displays the list of BGP nexthops and the result of their validity check.
show bgp rib [options] [filter] Show routes from the RIB.
Note: If the RIB information contains a large number of routes, displaying
this information may require some time to complete.
For [options]:
detail: Show more detailed output for matched routes.
For [filter]:
<address>: Show best matching route for the address.
as <as>: Show all entries with <as>anywhere in the AS path.
source-as <as>: Show all entries with <as> as the rightmost AS.
transit-as <as>: Show all entries with <as> anywhere but rightmost.
neighbor <peer>: Show only entries from the specified peer.
summary: Display a list of all neighbors, including information about the
session state and message counters.
memory: Show RIB memory statistics.
show bgp status Displays the current state of the BGP system in Secure64 DNS Cache.
show bgp summary Displays a list of all neighbors, including information about the session
state and message counters.
show bgp summary terse Displays a list of all neighbors, including information about the session
state, in a condensed format.
show comm Displays the available serial devices. (Note: This replicates the comm
command in the sysadmin role.)
show bfd status Displays the current state of the BFD service in Secure64 DNS Cache.
show bfd info Displays details about the current BFD session.
show bfd config Displays the BFD configuration.
423
Command Description
show defense config Displays configuration information related to mitigation rules configured on
show defense info Displays information about TCP, SSH, and other activity coming into the
Secure64 DNS Cache server.
show disks Displays information about the disk or disks used by the file system.
show fingerprint Displays the system’s RSA fingerprint.
show ip route Displays the IPv4 routing information.
show ipv6 [addr|route] Display the IPv6 addresses assigned to the Secure64 DNS server
interfaces, or display the IPv6 routing information.
show ntp [keys] Displays status information about the NTP server(s) configured for the
Secure64 DNS server. Add the keys argument to display information
about NTP keys for authentication.
show roles If the user account is assigned a create role, displays all of the roles and
users assigned. Otherwise, displays the role assigned to the current user
account only.
show rtqm <N> [T] <clients|domains> Displays real time query monitoring information to identify the top number
of defined client queries, where N is the number of clients to display (from
1 to 1000); T is the optional number of minutes to monitor (minimum of 1; if
not defined the default is 1 minute), and clients|domains is the IP address
of the requesting clients (clients) or domain names being queried for
(domains). To display information, real time query monitoring must first be
started with the start rtqm command.
show sensors Displays hardware sensor status information.
show snmp config Displays SNMP configuration information.
show snmp status Displays whether SNMP is running.
show snmp info Displays SNMP object information.
show syslog [status] If status is not specified, displays up to 50 entries from the local log file.
If status is specified, displays information about all active syslog servers.
show users If the user account is assigned a create role, displays all user accounts.
Otherwise, displays the current user account only.
show zone status zone <zone> Displays status information about the specified zone.
uptime [[-cpu | -app | -io] [#]] Shows CPU utilization and the amount of time the system has been
running. Use the options to specify CPU, APP, and/or I/O information or a
processor #.
version Shows the Secure64 DNS Cache software version information.
who Shows the user accounts currently logged in to the Secure64 DNS Cache
server, including RADIUS or LDAP accounts.
424
User Account Administration Commands

Table 70 provides information about the user account administration commands, which are
available only in the syscreate, cachednscreate, bgpcreate, logincreate, snmpcreate,
securitycreate, and snmpcreate roles. View commands are also available to these roles. To use
the commands, the user account must be associated with a create role type.
Table 70. User administration commands
Command Description
adduser <username> -a <days> [options] Adds the username to the list of valid user accounts for Secure64
DNS Cache.
The username must consist of 3-32 characters, start with an alpha
character, and contain alphanumeric characters (after the first
character). The -a <days> account aging attribute (required) defines
the number of days of inactivity before disabling the account. It is
configurable to 0 to disable feature (weakens security), or between
20-90 days.
[-r realname] Displays in the show users command results, with up
to 64 alphanumeric characters and 10 words
[-p password_age] System defaults to 60 days before requiring users
to change password. Configurable to 0 to disable feature (weakens
security), or between 20-90 days.
[-c lockout_count] System defaults to lock out a user account after
greater than 3 failed logins, for the number of minutes defined by the
-t lockout-time. Configurable to 0 to disable feature (weakens
[-i lockout_interval] System defaults to 60 minutes before resetting
the lockout counter. Configurable to 0 to disable feature (weakens
[-t lockout_time] If the user account has been locked out, system
defaults to lock out the account for 60 minutes. Configurable to 0 to
require the loginadmin to reset locked out user, or between 15-60
minutes.
[-h history] System defaults to preventing the user from re-using the
last 5 passwords for the user account. Configurable to 0 to disable
feature (weakens security), or between 0-5 passwords.
deluser <username> Removes a user account from Secure64 DNS Cache. This command
requires that you first use the usermod command to remove any
roles assigned to the user account.
Invoking this command on an existing user that is not associated with
any roles will remove the user from the database.
reset Disables all user accounts and enables the predefined Installer
account. Prompts for the reset password. FOR EMERGENCY USE
ONLY.
passwd [username] Sets or changes the password for the specified user account.
Passwords must be a minimum of 8 characters and include at least 3
alphabetic characters and at least 1 non-alphabetic character.
passwd reset Changes the reset command password. Prompts for the current reset
password.
425
Table 70. User administration commands
Command Description
show users Lists system users, one per line, in the format of:
<username> : [real name]: <enabled|disabled>
show roles Lists system roles, one per line, in the format of:
<role name> : [<user name>[, ...]]
userdisable <username> Disables the specified user account.
userenable <username> Re-enables the specified user account after the reset command or
the userdisable command is executed.
usermod +r <role name> <username> Adds (+r) or removes (-r) the username to/from the role name.
The issuer of the command must be a member of the
usermod -r <role name> <username>
cachednscreate role to manage users of the cachednsadmin role; a
member of the syscreate role to manage users of the sysadmin,
upgrade, or backup roles; a member of the bgpcreate role to manage
users of the bgpadmin role, a member of the logincreate role to
manage users of the loginadmin role, a member of the securitycreate
role to manage users of the securityadmin role, and/or a member of
the snmpcreate role to manage users of the snmpadmin role.
426
System Administration Commands

Table 71 provides information about the system administration commands, which are available in
the sysadmin role. View commands are also available.
Table 71. System administration commands
Command Description
System state commands
activate Makes the pending configuration the running configuration.
discard Reverses pending changes that have not been activated.
reboot Restarts the system. A prompt appears on-screen allowing
you to confirm (Y) or cancel (N) the reboot before it actually
occurs.
revert Cancels the running (activated) configuration and
reinstates the saved configuration.
save Saves the running (activated) configuration. This becomes
the running configuration upon the next system boot. When
you save a configuration, it overwrites the existing saved
configuration.
Network configuration commands
bondcfg bond<num> ethX ethY [ethZ...] Configures a Ethernet bond to create a virtual interface for
no bondcfg bond<num> failover.
<num> is the bond number, 0-99 (but only 8 total bonds
allowed)
Use the no form of the command to remove the
configuration.
bondcfg bond<num> mode miimon <polltime> Configures link status monitoring for the specified bond
<holdtime> number.
<polltime> is the time in milliseconds to poll the state of the
Ethernet link, ranging from 100 to 5000. If not defined for
an existing bond, the default is 1000.
<holdtime> is the time in milliseconds to wait before
changing the link state of a detected failure, ranging from
2x the polltime to 100x the polltime. If not defined for an
existing bond, the default is 5000. Holdtime should be a
multiple of polltime.
bondcfg bond<num> <gratarp|unsolnd> <num> Defines the number of gratuitous ARPs (gratarp) for IPv4
addresses or unsolicited neighbor discoveries (unsolnd) for
IPv6 addresses to send on a newly active port.
The acceptable range for both is 0-255. If the value is 0 for
gratarp, ARPs are not sent. If the value is 0 for
unsolnd, unsolicited neighbor discoveries are not sent.
If not defined for an existing bond, the default is 3.
chassispoll <seconds> Configures the number of seconds for chassis hardware
no chassispoll polling, between 1 and 86,400 (1 day). Use the show
sensors command or chassis SNMP traps to view the
polling information.
configuration.
427
Command Description
comm Displays the serial port for console configuration. The
comm [interface] default configuration is 9600, 8N1 (8 databits, no parity, 1
stop bit), no flow control.
comm without arguments displays the available serial

devices.
comm <interface> displays the current settings for the
defined interface.
console [-P <port>] [-S <sessionmax>] <interface> Enables the named ethX, ethX.I, or ethX:V.I
no console <interface> interface to allow console connections, where <port> is the
port to listen on (defaults to 22 if not defined),
<sessionmax> is the maximum number of simultaneous
connections (from 1-255; defaults to 5 if not defined), and
<interface> is defined in the form:
V= the VLAN ID
I= the address identity
configuration.
Set the current date and time to the defined
MMDDhhmmYYYY, where MM is the month (01-12), DD is
date <MMDDhhmmYYYY>
the day (01-31), hh is the hour (00-23), mm is the minute
(00-59), and YYYY is the four-digit year.
dig @<server> [<name>] [<type>] [<+queryopt>...] Send a DNS query to the specified server, where name is
[<-flag>...] the host or domain name, type is the DNS RR type,
queryopt is query options, and flag is additional query
flags.
Exports the local log file to another system via scp, where
-I <eth> specifies an optional interface, -P <port> is the
export syslog [-I <eth>] [-P <port>] optional destination port; <user> is an authorized user on
<user>@<host>:<file> the target system; <host> is the target IPv4 address, [IPv6
address] in square brackets, or hostname; and <file> is the
target file name.
halt Powers off the Secure64 DNS server.
428
Command Description
ifconfig <interface> <ipv4 address> <ipv4 netmask> Specifies an IPv4 or IPv6 address for a given interface,
no ifconfig <interface> <ipv4 address> where interface is defined in the form: ethX, ethX.I, or
ethX:V.I or bondX, bondX.I and
ifconfig <interface> <ipv6 address>/<ipv6 prefix length> V= the VLAN ID
no ifconfig <interface> <ipv6 address>/<ipv6 prefix length> I= the address identifier (you can use the identifier to
configure additional IP addresses for each physical
interface, 1-255 for non-bonded and 1-11 for bonded
interfaces.)
Note: The Secure64 DNS server supports a total of 256 IP
address.
Examples:
Configure the first IPv4 address of an interface (no VLAN):
ifconfig eth0 192.168.12.14
255.255.255.0
Configure a second IPv4 address to the interface (no

VLAN):
ifconfig eth0.1 192.168.0.4
255.255.255.0
Configure the first IPv6 address of an interface with a

VLAN ID of 12:
Configure the second IPv6 address of an interface with a VLAN

ID of 12:
ifconfig eth0:12.1 2001:db8:aaa:bbb:ccc::1/96

configuration.
ip frag <timeout|high|low> <seconds|percent> Manages resources used for IP fragmentation reassembly
and helps withstand IP fragmentation attacks.
ip frag timeout <seconds>: The time limit for the
reassembly subsystem to hold an incomplete set of IP
fragments, where seconds is 1-60. The default
configuration is 5 seconds.
ip frag high <0-50>: The maximum percentage of
network buffers dedicated to reassembly of IP fragments.
The default configuration is 40 percent.
ip frag low <0-50>: The maximum percentage of
network buffers that can be started as a new fragment set.
The default configuration is 30 percent.
logfacility <log_local#> Specifies a logging facility for syslog messages as defined
no logfacility <log_local#> in the syslog server’s configuration, where log_local# is
log_local0 – log_local7 or 0-7. If not defined, logs to the
system daemon facility.
configuration and use the default system daemon facility.
429
Command Description
loglevel <level> [entries] Specifies the level of messages that are transmitted via
no loglevel <level> syslog, as follows:
Name Level # Description
LOG_EMERG 0 system unusable
LOG_ALERT 1 action must be taken
immediately
LOG_CRIT 2 critical conditions
LOG_ERR 3 error conditions
LOG_WARNING 4 warning conditions
LOG_NOTICE 5 normal but significant
conditions
LOG_INFO 6 informational
LOG_DEBUG 7 debug-level messages
For [entries], define the number of syslog entries to store in
the local syslog copy, from 50-10,000. An [entries] value of
0 disables the local log file.
Use the show syslog command to display up to 50
entries or export syslog to export the file to a different
system for viewing.
Use the no form of the command to return to the default
loglevel (4).
Sends a user defined message to the configured syslog
logmsg [<0-7>] [log_local#] <message> servers, where <0-7> is an optional custom syslog level
and log_local# is an optional custom logging facility.
nameserver <0|1|2> <ipaddress> [timeout] Specifies name servers for address resolution for the
no nameserver <0|1|2> Secure64 DNS Cache system to locate its NTP and syslog
servers. You can specify as many as three name servers,
numbered 0, 1, and 2. Timeout defines the number of
seconds to wait until retrying a name server; the default is
4 seconds.
Use the no form of the command to remove a configured
nameserver.
nodename <name> Sets the name of the system as it appears in the command
no nodename <name> prompt and syslog messages.
Use the no form of the command to return to the default
nodename (Secure64DNS).
ntp <host> [keynum] [source_ipaddress] Specifies Network Time Protocol (NTP) servers by
no ntp <host> providing the IPv4/IPv6 address or hostname of the
servers so the system automatically synchronizes its time-
of-day. You can define up to 5 NTP servers; issue the
command once for each server to configure. For
authenticated NTP, use the ntpkey command to configure
an NTP key and include the [keynum] argument with the
ntp command when configuring the server.
configuration.
430
Command Description
ntpdate <ntp_server> Query a configured NTP server. Use show ntp to view the
results.
ntpkey <keynum> <method> <secret> Create an NTP key for NTP server authentication, where
<keynum> is the NTP key number; <method> is M, for
the MD5 hashing method; and <secret> is the shared
secret string (1-8 characters, case sensitive).
nullchecksums <allow|disallow> Allow or disallow UDP packets that do not contain a
checksum. The default behavior is to drop UDP packets
with no checksum (disallow). UDP packets with bad
checksums are always dropped.
ping <interface> <ipv4_address|hostname> Verifies that the configured ethX, ethX.I, or
ping6 <interface> [datasize] <ipv6_address|hostname> ethX:V.I interface is able to contact an external IP
address or hostname, where:
V= the VLAN ID
For ping6, you can use the optional [datasize] to define
the number of octets to send, from 1-1500.
reset autostart <cycle-counter|history> Resets autostart tracking parameters that track abnormal
restart behavior when the DNS server is configured to
automatically start. (To view the value of the parameters,
use the show autostart status command).
cycle-counter: Resets the autostart cycle counter.
history: Resets the number of reported and requested
reboots.
route default <ipv4_or_ipv6gateway> Configures network routing. There are two forms for the
no route default <ipv4_or_ipv6gateway> route command: default routes and other routes.
To add a default route where 10.0.0.1 is the default
route default <ipv6linklocal%interface> gateway (IPv4), the form is: route default
10.0.0.1
no route default <ipv6linklocal%interface>
To add a default route where 2608:0300:03c0:B is the
default gateway (IPv6), the form is:
route net <ipv4address> <netmask> <gateway>
route default 2608:0300:03c0:B
no route net <ipv4address> <netmask> <gateway>
For other routes, the IPv4 form is:
route net 192.168.250.0 255.255.255.0 10.1.2.3
route net <ipv6address>/<prefixlength> <gateway>
The IPv6 form is:
no route net <ipv6address>/<prefixlength> <gateway> route net 2001:db8:aaa:bbb::ccc/64
2001:db8:ddd:eee::97
configuration.
route <sym|asym> Configures the routing style for inbound traffic.
sym: Sets symmetrical routing, which sends responds to
in-bound requests to the source of the request.
asym: Sets asymmetrical routing, which performs an IP
route and ARP table lookup before sending every packet.
431
Command Description
syslog <server> [source] Specify a syslog server, where server is the IPv4/IPv6
no syslog <server|all> address or server host name and source is the optional
IPv4/IPv6 source IP address for the syslog server. Up to
four syslog servers can be configured.
Use the no form of the command to remove a configured
syslog server or all configured syslog servers.
timeout <seconds> Specifies the number of seconds of inactivity before
no timeout Secure64 DNS Cache automatically logs out of the SSH or
serial console. The default is 300 seconds (5 minutes), and
the maximum value is 3600 (1 hour). The user changing
the timeout is affected immediately; all other users’
timeouts are affected upon their next log in.
Use the no form of the command to disable the console
timeout, which sets the timeout to 0 (no timeout).
tz [spec] Sets the time zone. If spec is omitted, a list of top level
no tz [spec] zones and regions displays. For a list of time zones within
a region, enter
tz region_name. Use the no form of the command to
set the time zone to GMT.
Security configuration commands
allow <ipv4 address> [netmask]
Adds the specified system to the list of systems allowed to
no allow <ipv4 address> [netmask]
establish connections to the console via SSH.
allow <ipv6 address>[/<prefix length>]
configuration.
no allow <ipv6address>[/<prefix length>]
attach <interface|dnsserver> <rule1> [rule2…] Attaches a set of rules to an ethX, ethX.I, or
no attach <interface|dnsserver> ethX:V.I interface, where
V= the VLAN ID
If attaching RRtype rules, use the dnsserver keyword to
attach the rules at the server level.
configuration.
rule <name> <logical_expression> : <action> Creates a rule with the given name and a
no rule <name> logical_expression consisting of one or more
conditions which if they evaluate to true, result in the traffic
defined in the rule to be treated according to the specified
action. See Defending Against DNS DDoS Attacks on
configuration.
ruleactions <on|off> Enables and disables rules for mitigation and rate-limiting.
Logging and SNMP traps are not affected by the
command. Default is on (enable rules).
432
Caching DNS Server Commands

Table 72 provides information about the caching server administration commands, which are
available only in the cachednsadmin role. View commands are also available.
Table 72. Caching DNS commands
Command Description
Dynamically reload caching configuration changes without
cachedns reload
stopping or starting the server.
Provides information about the status and results of the last
cachedns reload status
cachedns reload operation.
For the specified name, remove associated records from all
answer and referral caches. If multiple caches are
cachedns flush name <name>
configured, use the optional [cachename|default] parameter
[cachename|default]
to limit the action to a specific cache name or the default
shared cache.
Flush the specified record type from all answer and referral
caches for the specified name. If multiple caches are
cachedns flush type <name> <type>
[cachename|default]
shared cache.
Set the validation status of the specified validated zone to
cachedns flush validation <zone> unvalidated. If multiple caches are configured, use the
[cachename|default] optional [cachename|default] parameter to limit the action to
a specific cache name or the default shared cache.
Flush everything at or below the specified name from all
answer and referral caches. If multiple caches are
cachedns flush zone <name>
[cachename|default]
shared cache.
Display answer or referral cache information for the specified
name. Include the optional record_type to display information
cachedns lookup <name> [answer|referral]
for a specific DNS record (defaults to A if not defined).
[record_type] [view]
Include the optional view to limit the lookup information to a
specific view name in the cache.conf configuration file.
Statistical commands for the caching server.
cachedns stats <dump|reset> dump: Dump all caching statistics to the command line
reset: Reset all caching statistic counters to zero
cat <file> Displays the contents of the specified file. Note that the
cd [directory] Changes to the specified directory. If no directory is specified,
changes to the top-level directory.
dig @<server> [<name>] [<type>] [<+queryopt>...] Send a DNS query to the specified server, where name is the
[<-flag>...] host or domain name, type is the DNS RR type, queryopt is
query options, and flag is additional query flags.
edit <file> Loads the specified file in the Secure64 DNS text editor.
433
Table 72. Caching DNS commands
Command Description
ls [-R] [directory|filename] Displays the contents of the current directory (if no directory
is defined) or the specified directory or filename. Wildcards
are permitted and multiple files/directories can be specified.
Note that the system displays as much as is allowed by the
screen buffer. Use the -r argument to include descendent
directories in the list.
mkdir [-p] <directory> Creates the specified directory for example: mkdir data.
Include -p to create a subdirectories, for example: mkdir -
p data/zones/example
pwd Displays the current directory path.
mv <from> <to> Renames or moves the specified from filename to the to
filename, within the same directory or different directories.
rm [<file>| -r <directory>] Deletes the specified file or directory. Wildcards are permitted
and multiple files/directories can be specified. If specifying a
directory, the -r argument is required and all descendent
directories and files are also removed.
rmdir <directory> Removes the specified directory. The directory must be
empty.
start cachedns Start the Secure64 DNS Cache server.
stop cachedns Stop the Secure64 DNS Cache server.
start bfd Start the BFD service, if configured.
stop bfd Stop the BFD service, if configured.
start rtqm [max memory] Start real time query monitoring to collect query data, where
max memory is the maximum amount of memory used by
the service, with a minimum of 1 MB. If not defined, the
maximum memory is 128 MB.
stop rtqm Stop real time query monitoring.
434
BGP Administration Commands

Table 73 provides information about the BGP administration commands, which are available
only in the bgpadmin role. View commands are also available.
Command Description
cd [directory] Changes to the specified directory. If no directory is
specified, changes to the top-level directory.
ls [-R] [directory|filename] Displays the contents of the current directory (if no directory
is defined) or the specified directory or filename. Wildcards
are permitted and multiple files/directories can be specified.
Note that the system displays as much as is allowed by the
screen buffer. Use the -R argument to include descendent
directories in the list.
Include -p to create a subdirectories, for example: mkdir -
p data/zones/example
rm [<file>| -r <directory>] Deletes the specified file or directory. Wildcards are
permitted and multiple files/directories can be specified. If
specifying a directory, the -r argument is required and all
descendent directories and files are also removed.
empty.
BGP administration commands
start bgp Reads the bgp.conf configuration file and enables BGP
services for Secure64 DNS Cache.
stop bgp Stops BGP services for Secure64 DNS Cache.
bgp announce <ipaddress/prefix> [-n peer] Sends a BGP UPDATE message to the neighbor(s)
identified to re-establish the ip_address/prefix in the
anycast cloud, where ip_address/prefix is one or
more IPv4/IPv6 address/prefixes to announce and peer is
the IPv4/IPv6 address or description of the neighbor; you
can list multiple neighbors after –n. To announce all
neighbors, omit the –n flag.
435
Command Description
bgp neighbor <peer> up Takes the BGP session to the specified neighbor up. <peer>
can be the neighbor's IPv4/IPv6 address or description.
bgp neighbor <peer> down Takes the BGP session to the specified neighbor down.
<peer> can be the neighbor's IPv4/IPv6 address or
description.
bgp neighbor <peer> clear Stops and restart the BGP session to the specified neighbor.
<peer> can be the neighbor's IPv4/IPv6 address or
description.
bgp neighbor <peer> refresh Requests the specified neighbor to re-send all routes. Note
that the neighbor is not required to re-send routes, even if it
announced the route refresh capability. <peer> can be the
IPv4/IPv6 neighbor's address or description.
bgp withdraw <ipaddress/prefix> [-n peer] Sends a BGP UPDATE message to the neighbor(s)
indicated. The UPDATE message contains the listed IP
address/prefixes in the withdrawn routes portion of the
message, where ip_address/prefix is one or more
of the IPv4/IPv6 address/prefixes to withdraw and peer is
the IPv4/IPv6 address or description of the neighbor; you
can list multiple neighbors after –n. To withdraw from all
neighbors, omit the –n flag.
436
Login and Authentication Administration Commands

Table 74 provides information about the login and authentication administration commands,
which are available only in the loginadmin role. View commands are also available.
Table 74. Login and authentication administration commands
Command Description
system displays as much as is allowed by the screen
buffer.
defined, changes to the top-level directory.
cp [-r] <source> <destination> Copy one or more files and/or directories. If more than
one source is defined, destination must be a directory.
Use -r to copy the entire directory tree starting with source
to the destination directory.
ls [-R] [directory|filename] Displays the contents of the current directory (if no
directory is defined) or the specified directory or filename.
Wildcards are permitted and multiple files/directories can
be specified. Note that the system displays as much as is
allowed by the screen buffer. Use the -R argument to
include descendent directories in the list.
Include -p to create a subdirectories, for example: mkdir
-p data/zones/example
rm [<file>|-r <directory>] Deletes the specified file. Wildcards are permitted and
multiple files/directories can be specified. If specifying a
empty.
current time. If the specified file does not exist, it is
created.
Authentication administration commands
authprobe radius [<username> <password> <pap> Probe the RADIUS server to test connectivity from the
<server> <port> <secret> <retries> <timeout>] Secure64 DNS server or test authentication for a specific
username and password.
To test connectivity settings in radius.conf, do not
specify the optional parameters (authentication is not
attempted). To test settings outside of radius.conf,
such as authentication of a specific username and
password, specify all parameters.
437
Table 74. Login and authentication administration commands
Command Description
authenticate <ldap | radius> Reads the specified RADIUS or LDAP configuration file
and enables the RADIUS or LDAP client for Secure64
DNS Cache. Use the activate and save commands to
save the configuration change.
no authenticate <ldap | radius> Disables the RADIUS or LDAP client for Secure64 DNS
Cache. Use the activate and save commands to save the
configuration change.
activate Makes the pending configuration the running
configuration.
save Saves the running (activated) configuration.
discard Reverses pending changes that have not been activated.
Login administration commands
Display or enable/disable SSH password authentication.
sshpwdauth- Displays password authentication
information for user accounts
sshpwdauth [<on|off>] [<username>] sshpwdauth <on|off>- Enables/disables SSH password
authentication for all user accounts
sshpwdauth <on|off> <username>- Enables/disables
SSH password authentication for the specified username.
No system default, must be set when user is added.to
define the number of days of inactivity. Configurable to 0
user <username> age account <0, 20-90> to disable feature (weakens security), or between 20-90
days. A three-day grace period is applied before disabling the
account.
System defaults to 60 days before requiring users to
user <username> age passwd <0, 20-90> change password. Configurable to 0 to disable feature
(weakens security), or between 20-90 days.
System defaults to lock out a user account after 3 failed
logins, for the number of minutes defined by the lockout
user <username> lockout count <0, 3-5>
time. Configurable to 0 to disable feature (weakens
System defaults to 60 minutes before resetting the lockout
user <username> lockout interval <0, 15-60> counter. Configurable to 0 to disable feature (weakens
If the user account has been locked out, system defaults
to lock out the account for 60 minutes. Configurable to 0 to
user <username> lockout time <0, 15-60>
require the loginadmin to reset locked out user, or
between 15-60 minutes.
System defaults to preventing the user from re-using the
last 5 passwords for the user account. Configurable to 0 to
user <username> history <0-5>
disable feature (weakens security), or between 0-5
passwords.
Generates a random temporary password. After logging in
with a temporary password, the user must change it, and
user <username> randompass
the temporary password becomes invalid. The random
password is not included in the password history.
user <username> <enable|disable> Enable or disable the user account.
438
Upgrade Commands
Table 75 provides information about the upgrade commands, which are available only in the
upgrade role. View commands are also available.
Table 75. Upgrade commands
Command Description
Restarts the system. A prompt appears on-screen allowing you to confirm
reboot
(Y) or cancel (N) the reboot before it actually occurs.
Reverses a Secure64 DNS Cache system upgrade, returning to the
rollback
previous version.
license Displays the 20-character Secure64 DNS Cache license key.
upgrade Upgrades the Secure64 DNS Cache system.
Security Administration Commands

Table 76 provides information about the security administration commands, which are available
only in the securityadmin role. View commands are also available.
Table 76. Security administration commands
Command Description
Restarts the system. A prompt appears on-screen allowing you
reboot
to confirm (Y) or cancel (N) the reboot before it actually occurs.
Removes the server’s SSH keys. New keys are automatically
remove sshkeys
generated upon reboot.
Deletes the Sensitive Data Unit (SDU) associated with the
sdu delete <subsystem> <keyword>
specified <subsystem> and <keyword>.
Displays the existing SDU(s); use the optional <subsystem>
sdu list [<subsystem>]
parameter to limit the list to the specified <subsystem>
Add the specified <SDU> to the Sensitive Data Protection
sdu protect <subsystem> <keyword> <SDU>
(SDP) database for the specified <subsystem> and <keyword>.
Replace the existing SDU value with the newly defined <SDU>
sdu replace <subsystem> <keyword> <SDU>
for the specified <subsystem> and <keyword>.
Remove the contents of the SDP database. This clears all
sdu reset
content and is not reversible.
Displays the plain text (unencrypted) content of the SDU
sdu reveal <subsystem> <keyword>
associated with the specified <subsystem> and <keyword>.
439
Table 76. Security administration commands
Command Description
Removes the server’s cryptographic module keys. New keys
are automatically generated upon reboot.
remove cmkeys
CAUTION: This command should be used only after consulting
with Secure64 support.
Reports the status of the cryptographic module (CM)
instance(s), in accordance with FIPS 140-2 Level 2 certification
requirements. Use the all option to display the status for all CM
status [all|#]
instances. Use the # option to display the status for a given CM
instance (1, 2, or 3). Non-CEM systems have a single CM
instance (1). Defining no options displays the status for CM 1.
440
SNMP Administration Commands

Table 77 provides information about SNMP commands, which are available only in the
snmpadmin role. View commands are also available.
Table 77. SNMP administration commands
Command Description
system displays as much as is allowed by the screen
buffer.
defined, changes to the top-level directory.
cp [-r] <source> <destination> Copy one or more files and/or directories. If more than
one source is defined, destination must be a directory.
Use -r to copy the entire directory tree starting with source
to the destination directory.
ls [-R] [directory|filename] Displays the contents of the current directory (if no
directory is defined) or the specified directory or filename.
Wildcards are permitted and multiple files/directories can
be specified. Note that the system displays as much as is
allowed by the screen buffer. Use the -R argument to
include descendent directories in the list.
Include -p to create a subdirectories, for example: mkdir
-p data/zones/example
rm [<file>|-r <directory>] Deletes the specified file. Wildcards are permitted and
multiple files/directories can be specified. If specifying a
empty.
current time. If the specified file does not exist, it is
created.
SNMP administration commands
start snmp Reads the snmpd.conf configuration file and enables
SNMP agent services for Secure64 DNS Cache.
441
Table 77. SNMP administration commands
Command Description
stop snmp Stops SNMP services for Secure64 DNS Cache.
sendtrap <type> Sends the specified S64-MITIGATION-MIB trap type
event or S64-CHASSIS-MIB trap type event for testing
purposes.
For S64-MITIGATION-MIB traps, specify <type> as one of
the following: blacklist, blacklistactive, blacklistinactive,
graylist, graylistactive, graylistinactive, packetfloodstart,
packetfloodend, synfloodstart, synfloodend.
For S64-CHASSIS-MIB traps, specify <type> as one of
the following: temperaturetrap, voltagetrap, fantrap,
chassisintrusiontrap, powersupplytrap,
powerredundancytrap.
442
Appendix B. Syslog and System Boot
Messages
System Logging Messages
Table 78 lists the system logging System: Subsystem, Severity, and Text.
Note Currently, Secure64 DNS does not output the Severity to syslog.
Table 78. System logging messages
System: Subsystem Severity Text

SYSTEM: NETWORK LOG_WARNING system rebooting
Explanation: Secure64 DNS system restarted.
Recommended Action: None
SYSTEM: NETWORK LOG_INFO Unable to create <%s> directory
Explanation: Cannot create the specified directory
Recommended Action: Contact support.
SYSTEM: NETWORK LOG_WARNING Successfully synchronized to NTP server %s
Explanation: Secure64 DNS system has synchronized with the identified NTP
server.
SYSTEM: NETWORK LOG_WARNING Network write error while querying NTP server %s
Explanation: The Secure64 DNS system experienced a problem when
attempting to query the NTP server.
Recommended Action: Verify that there is a nameserver configured for the
Secure64 DNS system to locate it. See the nameserver command in the
sysadmin role.
SYSTEM: NETWORK LOG_WARNING Query to NTP server %s timed out
Explanation: The Secure64 DNS system experienced a problem finding the
NTP server.
Recommended Action: Verify that the NTP server is available.
SYSTEM: NETWORK LOG_WARNING Network read error while querying NTP server %s
Explanation: The Secure64 DNS system experienced a problem finding the
NTP server over the network.
Recommended Action: Verify that the NTP server is available and reachable
from the Secure64 DNS server.
443
Appendix B. Syslog and System Boot Messages

SYSTEM: NETWORK LOG_WARNING Invalid response from NTP server %s: expected %d octets,
got %d
Explanation: The response received from the NTP server was incorrectly
sized. The Secure64 DNS server disregards incorrectly sized responses. If the
response is “expected 68 octets, got 52” and authenticated NTP is in use,
verify that the remote server is using the correct secret and key. See
Configuring an NTP Server with Authentication on page 265 for more
information.
Recommended Action: Confirm with the NTP server administrator that it is
properly configured.
SYSTEM: NETWORK LOG_INFO User %s forcing immediate query to NTP server %s
Explanation: A Secure64 DNS user executed the ntpdate command for the
defined server.
Recommended Action: None.
SYSTEM: NETWORK LOG_WARNING Failed to connect to NTP server %s: %s
Explanation: A Secure64 DNS user executed the ntpdate command for the
defined server and the system was unable to connect to the NTP server.
Recommended Action: Verify that the NTP server is configured and
reachable from the Secure64 DNS server.
SYSTEM: NETWORK LOG_WARNING Received NTP update from server %s(UNVERIFIED)
Explanation: An NTP server response was received without authentication
Recommended Action: Verify that the NTP server credentials are valid.
SYSTEM: NETWORK LOG_WARNING Received NTP update from server %s (cryptographically

verified)
Explanation: An NTP server response was authenticated
SYSTEM: NETWORK LOG_WARNING NTP %s clock disparity greater than 300 seconds, ignoring
Explanation: The Secure64 DNS NTP server consensus mechanism
detected a disparity of greater than 5 minutes (300 seconds) between the
current Secure64 DNS system time and the NTP server consensus time.
Recommended Action: Determine the reason for the disparity and correct
the Secure64 DNS system time.
SYSTEM: SNMP LOG_INFO SNMP session enabled, s64GlobalSNMPsession = <ptr_value>
Explanation: SNMP server is running
SYSTEM: SNMP LOG_INFO SNMP Session Successfully Closed

Explanation: SNMP server has exited
SYSTEM: SNMP LOG_ERR s64snmpSessionInit: returned NULL, received error

<snmp_errno>
Explanation: SNMP server initialization has encountered an error.
Recommended Action: Check the SNMP configuration
SYSTEM: SNMP LOG_ERR netsnmp_udp_transport: Connect failed. errno: <errno>
Explanation: SNMP server is unable to establish a connection
Recommended Action: Check the network configuration
444

SYSTEM: SNMP LOG_ERR snmp-server host %s and trap-source %s are in different
address family
Explanation: If both snmp-server host and trap-source are configured, they
must be from the same address family (IPv4 or IPv6). SNMP is temporarily
disabled until the configuration is corrected
Recommended Action: Unconfigure the trap-source so that Secure64 DNS
selects the proper address automatically, or configure both items to use the
same IP address family.
SYSTEM: SYSLOG LOG_INFO Secure64 DNS Server logging started.
Explanation: Secure64 DNS logging started.
Recommended Action: No action required
SYSTEM: SYSLOG LOG_ERR out of memory
Explanation: System does not have sufficient memory to produce syslog
messages.
Recommended Action: Reboot system. If problem continues, install
additional memory.
SYSTEM: SYSLOG LOG_WARNING system rebooting
Explanation: Secure64 DNS system restarted.
SYSTEM: DISK LOG_ERR file system full
Explanation: The file system is at 95% or more capacity.
Recommended Action: Remove files from the disk to below 95% capacity.
SYSTEM: DISK LOG_ERR out of inodes
Explanation: The file system cannot add any additional files.
Recommended Action: Remove files from the disk.
SYSTEM: DISK LOG_ERR bad block
Explanation: Internal error in the file system.
Recommended Action: Contact Secure64 DNS Cache customer support.
445
User Account/Roles Logging Messages

Table 79 lists the user accounts/roles logging System: Subsystem, Severity, and Text.
Table 79. User account/roles logging messages

SYSTEM:USERS LOG_NOTICE No users.txt file found, creating empty one.
Explanation: Missing users.txt file.
Recommended Action: No action required
SYSTEM:USERS LOG_NOTICE No roles.txt file found, creating empty one

Explanation: Missing roles.txt file.
SYSTEM:USERS LOG_CRIT Users database initialization: <error>

Explanation: Possible loss of users data
Recommended Action: Reboot, contact support.
SYSTEM:USERS LOG_CRIT Roles database initialization: <error>
Explanation: Possible loss of roles data
SYSTEM:USERS LOG_CRIT Users commands initialization: <error>

Explanation: Users commands initialization error
SYSTEM:USERS LOG_CRIT Users database finalization: <error>
Explanation: Possible loss of users data.
SYSTEM:USERS LOG_CRIT Roles database finalization: <error>
Explanation: Possible loss of roles data.
SYSTEM:USERS LOG_ERR authenticate_user: Users/Roles subsystem is uninitialized
Explanation: Attempted authentication before users/roles initialization.
Recommended Action: Wait for system to initialize; reboot.
SYSTEM:USERS LOG_NOTICE Login failure: no such user
Explanation: Login with an invalid user name.
Recommended Action: Retry login with valid user name.
SYSTEM:USERS LOG_NOTICE Login failure: no password set: <username>
Explanation: Login to a user account that does not have a password set.
Recommended Action: Login with creator account and set the user's
password.
SYSTEM:USERS LOG_NOTICE Login failure: user disabled: <username>
Explanation: Login attempt for a user account that is disabled.
Recommended Action: Creator account can re-enable the user account if
appropriate.
446
Table 79. User account/roles logging messages

SYSTEM:USERS LOG_NOTICE Login failure: not authenticated: <username>
Explanation: Login with invalid password.
Recommended Action: Retry login with valid password.
SYSTEM:USERS LOG_NOTICE Login failure: user disabled: Installer
Explanation: Installer attempted to login when users are assigned to every
creator role.
Recommended Action: Login as a different user.
SYSTEM:USERS LOG_NOTICE Login successful for <username>
Explanation: Successful login
SYSTEM:USERS LOG_INFO <username> authorized for role <rolename>
Explanation: Successful role authorization.
SYSTEM:USERS LOG_INFO <username> not authorized for role <rolename>
Explanation: Unsuccessful role authorization
SYSTEM:USERS LOG_INFO New user added: <username>
Explanation: User added.
SYSTEM:USERS LOG_INFO User removed: <username>
Explanation: User account deleted.
SYSTEM:USERS LOG_INFO <username> add to role <rolename>
Explanation: User account added to role.
SYSTEM:USERS LOG_INFO <username> add to role <rolename>
Explanation: User account added to role.
SYSTEM:USERS LOG_INFO <username> removed from role <rolename>
Explanation: User account removed from role.
447
Defense and Mitigation Logging Messages (Statistical)

In order to avoid flooding the logs, each message is only sent at predefined intervals when the
condition is present. When the condition is first detected the message is sent, and then again
every T seconds while it persists, where T is defined for each message in the table below. "End
of condition" alerts, such as SYN flood ended, are only sent once.
The averages are computed using one minute average and an exponentially weighted filter,
similar to the method used by UNIX (and variants) to compute load averages. Averages are
recomputed every five seconds.
Table 80. Defense and mitigation logging messages (statistical)

SYSTEM:DDOS LOG_ALERT excessive SSH connection attempts
Explanation: SYN packets arriving on port 22 exceed limit.
T= 30 seconds
Recommended Action: Firewall TCP port 22 to prevent unauthorized
connections.
SYSTEM:DDOS LOG_ALERT excessive number of active clients (%d)
Explanation: The active clients (unique IP addresses that have sent
DNS request in the previous 10 seconds) exceeds 95% of the
designed maximum.
T= 30 seconds
Recommended Action: Reduce client load by firewalling or adding
additional servers.
SYSTEM:DDOS LOG_ALERT SYN flood detected
Explanation: The difference between the average of arriving SYN
packets and the average of the established TCP connections exceeds
the predefined limit.
T= 30 seconds
Recommended Action: Reduce SYN load by firewalling.
SYSTEM:DDOS LOG_ALERT SYN flood ended
Explanation: Sent when a SYN flood was previously reported, but the
associated difference between the average of arriving SYN packets
and established TCP connections has dropped below the predefined
limit.
T= NA
SYSTEM:DDOS LOG_ALERT Blacklist active
Explanation: Sent when the average of the number of hosts on the
blacklist is greater than zero.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Blacklist inactive
Explanation: Sent when a blacklist-active condition was present, but
the average number of hosts on the blacklist is zero.
T= NA
448
Table 80. Defense and mitigation logging messages (statistical)

SYSTEM:DDOS LOG_ALERT Blacklist growing
Explanation: The average number of hosts on the blacklist is
increasing.
T= 30 seconds
Recommended Action: Firewall offending hosts
SYSTEM:DDOS LOG_ALERT Blacklist unchanged
Explanation: The average number of hosts on the blacklist is nonzero
and unchanging.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Blacklist shrinking
Explanation: The average number of hosts on the blacklist is nonzero
but dropping.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Graylist active
Explanation: The average number of hosts on the graylist is nonzero.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Graylist inactive
Explanation: Sent when a graylist-active condition was present, but
when the average number of hosts on the graylist is zero.
T= NA
SYSTEM:DDOS LOG_ALERT Graylist growing
Explanation: Sent when the average number of hosts on the graylist
is increasing.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Graylist unchanged
Explanation: The average number of hosts on the graylist is nonzero
and unchanging.
T= 30 seconds
SYSTEM:DDOS LOG_ALERT Graylist shrinking
Explanation: The average number of hosts on the graylist is nonzero
but dropping.
T= 30 seconds
449
Defense and Mitigation Logging Messages (Events)

Events associated with specific hosts/IP addresses are logged asynchronously whenever they
occur. The system throttles the messages by sending them every T seconds as defined in the
table below. Events that occur faster than that rate are recorded in a backlog, and the backlog is
then logged (at up to 20 backlogged messages at once) every five seconds.
The following information pertains to backlogs:
Backlogged messages are dumped in the order in which they were recorded, with the message
"[ BACKLOGGED from uptime %d:%d:%d:%d ]" where the indicated time is the uptime of
the system.
If the backlog grows to 10,000 messages, the backlog buffer becomes full and the oldest
backlogged message will be lost. When this happens, the following message is logged: "Too
many events to log: BGP (%d); Blacklist (%d); Graylist(%d)." The counts of the
backlogged messages in each category are provided so that administrators can determine the
most active or worst offending conditions.
Table 81. Defense and mitigation logging messages (Events)

SYSTEM:DDOS LOG_ERR Excessive ssh connection attempts (blocked from
<ip_address>)
Explanation: The number of SSH connection attempts by the defined
ip_address exceed the limit
T= 10 seconds
SYSTEM:DDOS LOG_ERR Blacklisting <ip_address>
Explanation: The host is added to the blacklist.
T= 10 seconds
Recommended Action: Firewall the blacklisted address.
SYSTEM:DDOS LOG_ERR Graylisting <ip_address>
Explanation: The host moved from the blacklist to the graylist.
T= 10 seconds
SYSTEM:DDOS LOG_ERR Removing <ip_address> from graylist
Explanation: Sent when a host is taken off the graylist.
T= 10 seconds
SYSTEM:DDOS LOG_ERR packet flood on <port> (<packet_rate> > <configured_rate>)
Explanation: Current packet rate exceeds the configured rate.
T= 10 seconds
450
Table 81. Defense and mitigation logging messages (Events)

SYSTEM:DDOS LOG_ERR packet flood on <port> has stopped(<packet_rate> <
<configured_rate>)
Explanation: Current packet rate is less than the configured rate.
T= 10 seconds
SYSTEM:DDOS LOG_ERR Excessive incoming SYNs - possible SYN flood
Explanation: The rate of incoming SYNs indicates a possible SYN
flood.
T= 10 seconds
Recommended Action: Determine whether the incoming SYN rate is
expected or indicative of a SYN flood.
451
Caching Application Logging Messages

Table 82 lists the caching resolver logging System: Subsystems, Severity, and Text.
Table 82. Caching logging messages

APPLICATION: RESOLVER LOG_INFO duplicate acl address ignored
Explanation: The same IP address is configured multiple times for the
access-control: attribute in cache.conf.
Recommended Action: Remove the duplicate address.
APPLICATION: RESOLVER LOG_INFO access control type %s unknown
Explanation: An invalid type is configured for the access-control: attribute in
cache.conf.
Recommended Action: Correct the type to a valid entry.
APPLICATION: RESOLVER LOG_INFO cannot parse access control: %s %s
Explanation: There is a problem with the access-control: attribute in
cache.conf.
Recommended Action: Check the configuration and correct if necessary.
APPLICATION: RESOLVER LOG_ERR netblock too large: %s
Explanation: The identified netblock is configured incorrectly in cache.conf.
Recommended Action: Check the configuration and correct.
APPLICATION: RESOLVER LOG_ERR cannot parse netblock: '%s'.
Explanation: The identified netblock is configured incorrectly in cache.conf.
APPLICATION: RESOLVER LOG_ERR cannot parse ip address: '%s'
Explanation: The identified IP address is configured incorrectly in cache.conf.
APPLICATION: RESOLVER LOG_ERR cannot parse port number '%s'
Explanation: The identified port number is configured incorrectly in
cache.conf.
APPLICATION: RESOLVER LOG_DEBUG local-data-ptr: "%s" ==> "%s"
Explanation: Shows the local data shorthand for a PTR record with the
reversed IPv4 or IPv6 address and the host name, as configured in cache.conf
with the local-data-ptr attribute.
APPLICATION: RESOLVER LOG_CRIT %s: label comparison failure for %s
Explanation: DNS 0x20 forgery resistance checking found a mismatch. The
answering authoritative server may not support preservation of query name
casing or this may be a cache poisoning/forgery attempt.
Recommended Action: Check for additional occurrences of this message to
determine whether a cache poisoning attempt is underway.
452

APPLICATION: RESOLVER LOG_ERR find_delegation: out of memory
Explanation: The system is out of memory.
Recommended Action: Restart or stop and start the DNS server. If the error
continues to occur, reboot and contact Secure64 support.
APPLICATION: RESOLVER LOG_ERR find_delegation: addrs out of memory
APPLICATION: RESOLVER LOG_ERR out of memory creating local zones region
APPLICATION: RESOLVER LOG_ERR out of memory creating local zones
APPLICATION: RESOLVER LOG_ERR out of memory parsing local zone name
APPLICATION: RESOLVER LOG_ERR out of memory creating local zone region
APPLICATION: RESOLVER LOG_WARNING duplicate local-zone
Explanation: The same local zone is identified multiple times in cache.conf.
Recommended Action: Check the local-zone configuration and correct.
APPLICATION: RESOLVER LOG_ERR bad zone name %s %s
Explanation: The zone name identified for a local-zone: in cache.conf is
invalid.
APPLICATION: RESOLVER LOG_ERR bad lz_enter_zone type %s %s
Explanation: Type defined for a local-zone: in cache.conf is invalid.
APPLICATION: RESOLVER LOG_ERR could not enter zone %s %s
Explanation: The identified local-zone: or local-data: is invalid.
Recommended Action: Check the local-zone and local-data configuration
and correct.
APPLICATION: RESOLVER LOG_ERR error parsing local-data '%s': %s
Explanation: The identified local-data: in cache.conf is invalid.
Recommended Action: Check the local-data configuration and correct.
APPLICATION: RESOLVER LOG_ERR error converting RR '%s' to wireformat: %s
Explanation: The RR associated with a local-data: attribute in cache.conf is
invalid.
453

APPLICATION: RESOLVER LOG_ERR out of memory adding local data
APPLICATION: RESOLVER LOG_INFO internal: duplicate node name
Explanation: Duplicate zone detected in local data
Recommended Action: Check the local-data configuration and correct if
necessary.
APPLICATION: RESOLVER LOG_ERR bad local-data: %s
Explanation: The identified local-data: in cache.conf is invalid.
APPLICATION: RESOLVER LOG_ERR local-data in redirect zone must reside at top of zone
Explanation: The local-data for a local-zone using redirect in cache.conf
should be a top-level zone.
Recommended Action: Check the local-data and local-zone configuration
and correct.
APPLICATION: RESOLVER LOG_DEBUG ignoring duplicate RR: %s
Explanation: Multiple records for the same RR exist in local-data for a local-
zone in cache.conf.
and correct.
APPLICATION: RESOLVER LOG_ERR bad rr %s
Explanation: Invalid RR in the local-data of the specified local-zone.
and correct.
APPLICATION: RESOLVER LOG_ERR internal error: no zone for rr %s
Explanation: Local-data is defined for a RR but it is not associated with a
local-zone.
and correct.
APPLICATION: RESOLVER LOG_ERR bad local zone name %s
Explanation: The local-zone name is invalid.
APPLICATION: RESOLVER LOG_ERR out of memory adding default zone %s
APPLICATION: RESOLVER LOG_ERR Bad local-data RR %s
Explanation: The local-data RR specified is invalid.
and correct.
APPLICATION: RESOLVER LOG_ERR cannot create temporary buffer for local zones
APPLICATION: RESOLVER LOG_INFO number of auth zones %u
Explanation: Identifies the number of zones defined in the local zone to serve
authoritatively from the caching server.
454

APPLICATION: RESOLVER LOG_ERR internal: duplicate entry in local_zones_add_zone
Explanation: The same local-zone may be defined multiple times in
cache.conf.
and correct if necessary.
APPLICATION: RESOLVER LOG_ERR Error opening root hints file %s: %s.
Explanation: The specified root hints file cannot be opened.
Recommended Action: Check the root-hints configuration attribute in
cache.conf and verify the specified file is present on the server in the
cachednsadmin role directory structure.
APPLICATION: RESOLVER LOG_ERR Out of memory reading root hints file.
APPLICATION: RESOLVER LOG_WARNING Reading root hints file %s line %d: skipping record type
%s.
Explanation: There is a problem with the specified record type in the root
hints file.
Recommended Action: Verify the information in the specified root hints file
APPLICATION: RESOLVER LOG_WARNING Reading root hints file %s: no NS content.
Explanation: The NS record is missing from the root hints file.
Recommended Action: Verify the information in the specified root hints file
APPLICATION: RESOLVER LOG_INFO No root-hints file, using built-in root hints.
Explanation: A root hints file is not configured using the root-hints attribute in
cache.conf. The server uses a built-in default file for root hints.
Recommended Action: To ensure the file is up-to-date, maintain a root hints
file on the server in the cachednsadmin directory structure. Configure the root-
hints attribute in cache.conf to use this file.
APPLICATION: RESOLVER LOG_ERR cannot parse donotquery netblock: %s
Explanation: The defined netblock for the do-not-query-address attribute in
cache.conf is invalid.
Recommended Action: Check the do-not-query-address attribute
configuration and correct.
APPLICATION: RESOLVER LOG_ERR cannot parse private address %s
Explanation: The specified private-address attribute in cache.conf has an
invalid value.
Recommended Action: Check the private-address attribute and correct.
APPLICATION: RESOLVER LOG_INFO ignoring duplicate private-address: %s
Explanation: The same private-address information is defined multiple times
in cache.conf.
APPLICATION: RESOLVER LOG_ERR cannot parse private domain %s
Explanation: The specified private-domain attribute in cache.conf has an
invalid value.
Recommended Action: Check the private-domain attribute and correct.
455

APPLICATION: RESOLVER LOG_ERR ignoring duplicate private-domain: %s
Explanation: The same private-domain information is defined multiple times
in cache.conf.
APPLICATION: RESOLVER LOG_ERR error in private name lookup
Explanation: There was a problem with locating the private-domain
information defined in cache.conf.
Recommended Action: Check the private-domain attribute and correct.
APPLICATION: RESOLVER LOG_DEBUG Duplicate forward zone ignored.
Explanation: The same information is defined multiple times for a forward
zone in cache.conf.
Recommended Action: Check the forward zone information and correct.
APPLICATION: RESOLVER LOG_ERR Forward zone without a name (use name "." to forward
everything)
Explanation: A forward zone clause is defined without a name attribute.
Recommended Action: If forwarding should occur for specific zone(s), define
the zones in the forward-zone clause in cache.conf.
APPLICATION: RESOLVER LOG_ERR cannot parse forward zone name %s
Explanation: The name attribute for the forward zone clause in cache.conf is
invalid.
Recommended Action: Check the name attribute and correct.
APPLICATION: RESOLVER LOG_ERR cannot parse forward %s server name: '%s
Explanation: The forward-host attribute for the specified forward zone in
Recommended Action: Check the forward-host attribute and correct.
APPLICATION: RESOLVER LOG_ERR cannot parse forward %s ip address: '%s'
Explanation: The forward-address attribute for the specified forward zone in
Recommended Action: Check the forward-address attribute and correct.
APPLICATION: RESOLVER LOG_ERR Out of memory creating forward zone tree
APPLICATION: RESOLVER LOG_ERR Error reading forward zones from configuration
Explanation: There is a problem with the forward-zone clause in cache.conf.
Recommended Action: Check the forward-zone clause and correct.
APPLICATION: RESOLVER LOG_DEBUG "%s exceeded drop threshold on %s
Explanation: The limit for the total query resolution timeout was reached and
the query was dropped.
Recommended Action: If the message occurs frequently, consider increasing
the timeout configured for incoming-query-timeout in cache.conf.
APPLICATION: RESOLVER LOG_DEBUG "%s exceeded MAX_QUERY_TIME on %s
Explanation: The limit for a backend query for name resolution was reached.
Recommended Action: If the message occurs frequently, consider increasing
the timeout configured for outgoing-query-timeout in cache.conf.
456

APPLICATION: RESOLVER LOG_DEBUG %s exceeded number of traverses on %s
Explanation: The server has a maximum of 30 traversals during query
resolution. If this message occurs, query resolution attempted to exceed 30
traverses.
APPLICATION: RESOLVER LOG_ERR unknown IP type in configuration
Explanation: An IP address is not in a correct IPv4 or IPv6 format.
Recommended Action: Check the IP addresses configured in the cache.conf
and correct..
APPLICATION: RESOLVER LOG_ERR listening interface %s - invalid IP address
Explanation: The IP address defined for the interface attribute in cache.conf
is invalid.
Recommended Action: Check the interface attribute and correct.
APPLICATION: RESOLVER LOG_ERR listening interface %s - no such interface
Explanation: The configured interface attribute in cache.conf has not been
configured on the Secure64 server.
Recommended Action: Use the ifconfig command in the sysadmin role to
configure the interface, or correct the configuration in cache.conf.
APPLICATION: RESOLVER LOG_WARNING Running as full resolver.
Explanation: The server is running as a full (not stub) resolver.
APPLICATION: RESOLVER LOG_ERR Error opening crypto module session.
Explanation: A problem occurred when the system attempted to open the
cryptographic module for validation of queries.
Recommended Action: Reboot the server and start Secure64 DNS Cache. If
the problem continues, contact Secure64 customer support.
APPLICATION: RESOLVER LOG_WARNING Validation deactivated, no usable trust anchors found.
Explanation: DNSSEC validation of queries will not occur because no valid
trust anchors are defined in cache.conf.
Recommended Action: If DNSSEC validation is desired, check the trust
anchor configuration in cache.conf.
APPLICATION: RESOLVER LOG_ERR Error starting resolver query front end.
Explanation: A problem occurred when the resolver was attempting to start.
Recommended Action: Reboot the server and start Secure64 DNS Cache. If
the problem continues, contact Secure64 customer support.
APPLICATION: RESOLVER LOG_ERR Error no usable root hints found
Explanation: The server could not load the root hints file.
Recommended Action: If a root hints file is defined in cache.conf, verify the
root-hints: attribute syntax and file name. If no root hints file is defined, the
server cannot load the built-in root hints file. Reboot the system and try starting
the server. If the problem continues, contact Secure64 customer support.
APPLICATION: RESOLVER LOG_ERR Error starting nxdomain redirection
Explanation: NXDOMAIN redirection has been configured in cache.conf but
an error has occurred in starting.
Recommended Action: Check the NXDOMAIN redirection attributes in
cache.conf and correct if necessary.
APPLICATION: RESOLVER LOG_ERR error closing crypto module session.
Explanation: An error occurred closing the cryptographic module after query
validation.
Recommended Action: Contact Secure64 customer support.
457

APPLICATION: RESOLVER LOG_WARNING DNS resolver stopped
Explanation: There are no queries in progress to resolve; the DNS resolver is
no longer running.
APPLICATION: RESOLVER LOG_WARNING caching DNS server stopped
Explanation: The Secure64 DNS caching server has been stopped.
APPLICATION: RESOLVER LOG_ERR The current do-not-query-address configuration allows no
root hints
Explanation: The do-not-query-address attribute is set to block IP addresses
configured in the root hints file.
Recommended Action: Check the do-not-query-address attribute in
cache.conf and the root hints file; correct conflicts or incorrect information.
APPLICATION: RESOLVER LOG_ERR Response from server %s for query %s: response ID <%d>
does not match query ID <%d>. Discarding response.
Explanation: When the harden-mismatch attribute in cache.conf is yes, the
response is not cached when the message ID in the response does not match
the query message ID.
Recommended Action: Monitor the server for a possible cache poisoning
attack.
APPLICATION: RESOLVER LOG_ERR Response from server %s for query %s: response ID <%d>
does not match query ID <%d>. Discarding response.
Explanation: When the harden-mismatch attribute in cache.conf is no, the
response is cached when the message ID in the response does not match the
query message ID.
attack.
APPLICATION: RESOLVER LOG_ERR Response from server %s for query %s: response name <%s>
does not match query. Discarding response.
Explanation: When the harden-mismatch attribute in cache.conf is yes, the
response is not cached when the name in the response does not match the
original query name.
attack.
does not match query. Discarding response.
Explanation: When the harden-mismatch attribute in cache.conf is no, the
response is cached when the name in the response does not match the
original query name.
attack.
bit for bit comparison failed
Explanation: The use-caps-for-id attribute is yes and the DNS 0x20 checking
of the name failed.
attack.
APPLICATION: RESOLVER LOG_ERR Out of memory adding lame host to infrastructure cache
458

APPLICATION: RESOLVER LOG_INFO Lame delegation from server %s, continuing search with
next server
Explanation: The specified authoritative server provided a lame delegation
and the next server will be queried.
APPLICATION: RESOLVER LOG_ERR Unable to reach server %s for outbound query.
Explanation: The specified server cannot be reached during a query
resolution. The server will try to reach a different authoritative server.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating stub delegation point
APPLICATION: RESOLVER LOG_ERR Out of memory allocating forwarding delegation point
APPLICATION: RESOLVER LOG_ERR Could not create neg cache: out of memory
APPLICATION: RESOLVER LOG_ERR Out of memory creating negative cache
APPLICATION: RESOLVER LOG_ERR Could not create zone node: out of memory
APPLICATION: RESOLVER LOG_ERR out of memory inserting NSEC negative cache
APPLICATION: RESOLVER LOG_ERR out of memory adding negative zone
APPLICATION: RESOLVER LOG_DEBUG negcache got secure rrset
Explanation: A cached and validated NSEC record was found for a DLV
query.
APPLICATION: RESOLVER LOG_DEBUG negcache not proven
Explanation: When using DLV (aggressive negative caching) the name to
query was not covered by a cached and validated NSEC record.
APPLICATION: RESOLVER LOG_DEBUG negcache DLV denial proven
Explanation: When using DLV (aggressive negative caching) the name to
query was covered by a cached and validated NSEC record.
459

APPLICATION: RESOLVER LOG_ERR nsec3 CM SHA1 digest failed with diagnostic 0x%x
Explanation: An error occurred with NSEC3 validation.
APPLICATION: RESOLVER LOG_ERR CM SHA256 digest failed with diagnostic 0x%x
APPLICATION: RESOLVER LOG_ERR nsec3 hash of unknown algo %d
APPLICATION: RESOLVER LOG_ERR Error encoding: %d
Explanation: An error occurred during NSEC3 hash of name.
APPLICATION: RESOLVER LOG_ERR Out of memory calculating hash.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating wildcard.
APPLICATION: RESOLVER LOG_ERR Bad type for trust anchor
Explanation: The RR type for the trust anchor must be DS or DNSKEY.
Recommended Action: Correct the RR type for the trust anchor in
cache.conf.
APPLICATION: RESOLVER LOG_ERR Error converting trustanchor to wireformat: %s
Explanation: There is a problem with the configured trust anchor information
in cache.conf.
Recommended Action: Check and correct the trust anchor configuration in
cache.conf.
APPLICATION: RESOLVER LOG_ERR Error parsing trust anchor: %s
in cache.conf.
cache.conf.
APPLICATION: RESOLVER LOG_ERR Error storing trust anchor
in cache.conf.
cache.conf.
APPLICATION: RESOLVER LOG_ERR Error opening trust anchor file %s: %s
Explanation: The specified trust anchor file does not exist.
cache.conf.
APPLICATION: RESOLVER LOG_ERR error at %s line %d: no multiple anchor domains allowed
(you can have multiple keys, but they must have the same
name).
Explanation: Multiple trust anchor domains are not allowed.
cache.conf.
460

APPLICATION: RESOLVER LOG_ERR trusted-keys, %d, string too long
Explanation: The specified trusted keys string is too long.
cache.conf.
APPLICATION: RESOLVER LOG_ERR trusted-keys, line %d, expected %c
Explanation: There is a problem with the format of the configured trust anchor
information in cache.conf.
cache.conf.
APPLICATION: RESOLVER LOG_ERR trusted-keys, line %d, expected %c got EOF
cache.conf.
APPLICATION: RESOLVER LOG_ERR line %d, too long
cache.conf.
APPLICATION: RESOLVER LOG_ERR line %d, bad key
Explanation: There is a problem with the the format of the configured trust
anchor information in cache.conf.
cache.conf.
APPLICATION: RESOLVER LOG_ERR line %d, allocation failure
cache.conf
APPLICATION: RESOLVER LOG_ERR line %d, bad key before }
cache.conf
APPLICATION: RESOLVER LOG_ERR line %d, too long
cache.conf
APPLICATION: RESOLVER LOG_ERR line %d, EOF before }
cache.conf
APPLICATION: RESOLVER LOG_ERR Error opening file %s: %s
cache.conf
461

APPLICATION: RESOLVER LOG_ERR Error in trusted key: "%s
Explanation: There is a problem with the the format of the configured trusted
key information in cache.conf.
Recommended Action: Check and correct the trusted key configuration in
cache.conf
APPLICATION: RESOLVER LOG_ERR Error reading trust-keys-file: %s
Explanation: There is a problem with the the format of the configured trusted
key information in cache.conf.
Recommended Action: Check and correct the trusted key configuration in
cache.conf
APPLICATION: RESOLVER LOG_ERR Error in trust-anchor: "%s"
cache.conf
APPLICATION: RESOLVER LOG_ERR error reading dlv-anchor-file: %s
Explanation: There is a problem with the the format of the configured DLV
Recommended Action: Check and correct the DLV configuration in
cache.conf
APPLICATION: RESOLVER LOG_DEBUG Unable to classify response message
Explanation: The query response type is unknown.
APPLICATION: RESOLVER LOG_DEBUG Could not find signer name for unknown response type.
Explanation: The system could not determine the signer that generated a set
of RRSIG records.
APPLICATION: RESOLVER LOG_DEBUG Failed to match any usable DS to a DNSKEY.
Explanation: A given DS record did not match any DNSKEY records.
APPLICATION: RESOLVER LOG_ERR Out of memory initializing nsec3.
APPLICATION: RESOLVER LOG_ERR Nsec3 key iterations not ascending: %d %d.
Explanation: The val-nsec3-keysize-iterations: attribute in cache.conf does
not list the iterations in ascending order, as required.
Recommended Action: Check the cache.conf configuration for the val-
nsec3-keysize-iterations attribute and correct.
APPLICATION: RESOLVER LOG_ERR Out of memory initializing trust anchors.
APPLICATION: RESOLVER LOG_ERR Out of memory initializing key cache.
Explanation: The system is out of memory or the key cache is misconfigured
in cache.conf.
Recommended Action: Check the key cache attributes in cache.conf and
reduce the amount of memory used. Restart or stop and start the DNS server.
If the error continues to occur, reboot and contact Secure64 support.
462

APPLICATION: RESOLVER LOG_ERR Error initializing trustanchors.
Explanation: There is a problem with the configured trust anchors in
cache.conf.
Recommended Action: Check the cache.conf configuration file and trust
anchor attributes/files.
APPLICATION: RESOLVER LOG_ERR Unparseable or odd nsec3 key iterations: %s.
Explanation: The val-nsec3-keysize-iterations: attribute in cache.conf does
not list the iterations correctly.
APPLICATION: RESOLVER LOG_ERR Cannot apply nsec3 key iterations.
Explanation: The val-nsec3-keysize-iterations: attribute in cache.conf may be
misconfigured.
APPLICATION: RESOLVER LOG_ERR Out of memory initializing negative cache.
Recommended Action: Check the negative cache attribute in cache.conf and
reduce the amount of memory used. Restart or stop and start the DNS server.
If the error continues to occur, reboot and contact Secure64 support.
APPLICATION: RESOLVER LOG_DEBUG Failed to validate NODATA response.
Explanation: Validation of a signed NODATA response was unsuccessful.
APPLICATION: RESOLVER LOG_ERR Internal error: mismatched validation types.
Explanation: For validation of a type ANY query, the server found that the
query is no longer type ANY
APPLICATION: RESOLVER LOG_DEBUG Failed to validate CNAME chain to noanswer response
Explanation: A CNAME no answer response failed to prove status with
NSEC/NSEC3.
APPLICATION: RESOLVER LOG_ERR Unknown response subtype: %d.
Explanation: The validator found an unknown response type during
validation.
APPLICATION: RESOLVER LOG_DEBUG DLV lookup within DLV repository denied
Explanation: A DLV lookup within a DLV respository was attempted. This is
not a valid delegation.
APPLICATION: RESOLVER LOG_INFO Name too large to perform DLV lookup
Explanation: The DLV query name exceeded the maximum of 255
characters, which includes the name of the DLV registry.
Recommended Action: None. An unvalidated answer is provided.
APPLICATION: RESOLVER LOG_ERR Out of memory preparing DLV lookup
463

APPLICATION: RESOLVER LOG_ERR Out of memory caching validator results.
APPLICATION: RESOLVER LOG_ERR out of memory in process_dlv
APPLICATION: RESOLVER LOG_DEBUG %s: DLV woke up with status dlv_success
Explanation: The DLV lookup was successful.
APPLICATION: RESOLVER LOG_DEBUG "%s: DLV woke up with status dlv_ask_higher
Explanation: The DLV lookup status was set to DLV ask higher.
APPLICATION: RESOLVER LOG_DEBUG %s: DLV woke up with status dlv_there_is_no_dlv
Explanation: The DLV lookup status was set to no DLV.
APPLICATION: RESOLVER LOG_DEBUG %s: DLV woke up with status dlv_error
Explanation: The DLV lookup status was set to DLV error.
Recommended Action: Check the cache.conf DLV configuration for errors
and the DLV repository for problems.
APPLICATION: RESOLVER LOG_DEBUG %s: DLV woke up with status unknown
Explanation: The DLV lookup status was set to unknown.
APPLICATION: RESOLVER LOG_DEBUG %s: dlv error in lookup
Explanation: An error occurred during DLV lookup.
Recommended Action: Check the cache.conf DLV configuration for errors
and the DLV repository for problems.
APPLICATION: RESOLVER LOG_DEBUG Out of memory in DLVLook
APPLICATION: RESOLVER LOG_DEBUG state is not ask higher!
Explanation: The validator is attempting to go above the DLV repository to the
parent zone for validation, but the DLV state is not set to ask higher,
APPLICATION: RESOLVER LOG_DEBUG ask above dlv repo
Explanation: The validator has gone above the DLV repository to the parent
zone for validation.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating keys.
Explanation: The system is out of memory when attempting to allocate the
DNSSEC key cache.
Recommended Action: Check the cache.conf key cache configuration.
Restart or stop and start the DNS server. If the error continues to occur, reboot
and contact Secure64 support.
464

APPLICATION: RESOLVER LOG_ERR Out of memory verifying prime DS.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating primed key.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating null prime key.
APPLICATION: RESOLVER LOG_ERR Out of memory processing dnskey response
APPLICATION: RESOLVER LOG_ERR No DS rrset for new DNSKEY response
Explanation: The server received a response to a DNSKEY request but a
matching DS RRset was not found
Recommended Action: Contact the zone owner to correct.
APPLICATION: RESOLVER LOG_ERR Out of memory processing dnskey response
APPLICATION: RESOLVER LOG_WARNING POSITIVE DS response missing DS, marking bogus.
Explanation: A DS RRset was missing and failed to validate.
APPLICATION: RESOLVER LOG_ERR Out of memory processing DS response
APPLICATION: RESOLVER LOG_INFO number of tcp connections %d >= %d\n
Explanation: The current number of TCP connections is greater than or equal
to the configured incoming TCP connections in cache.conf.
Recommended Action: Change the incoming TCP attributes in cache.conf if
necessary.
APPLICATION: RESOLVER LOG_DEBUG %s: discarding unsolicited NOTIFY
Explanation: The caching server does not accept or respond to notifies.
APPLICATION: RESOLVER LOG_DEBUG %s: discarding IQUERY
Explanation: The caching server does not accept or respond to IQUERY
requests.
APPLICATION: RESOLVER LOG_CRIT insufficient memory to preallocate incoming udp contexts
465

APPLICATION: RESOLVER LOG_CRIT num udp contexts %d > num network handles %d
Explanation: The number of UDP contexts is greater than the number of
network handles.
Recommended Action: Reduce the number of configured num-recursive-
clients in cache.conf.
APPLICATION: RESOLVER LOG_CRIT Low Memory! Reducing the number of recursive clients to %d
Explanation: The caching server is automatically reducing the number of
recursive clients due to low memory.
Recommended Action: Examine additional syslog messages to determine
why the low memory event ocurred. Consider reducing the number of
configured num-recursive-clients in cache.conf to increase memory resources.
APPLICATION: RESOLVER LOG_CRIT Raising the number of recursive clients to %d
Explanation: After automatically reducing the number of recursive clients due
to low memory, the caching server now detects that enough memory is
available to increase the number.
APPLICATION: RESOLVER LOG_CRIT Restoring the number of recursive clients
Explanation: After automatically reducing the number of recursive clients due
to low memory, the caching server now detects that enough memory is
available to restore the number to its original value.
APPLICATION: RESOLVER LOG_ERR UDP and TCP are both disabled
Explanation: The cache.conf is configured to disable both UDP and TCP
queries.
Recommended Action: Check the cache.conf configuration and correct.
APPLICATION: RESOLVER LOG_ERR IPV4 and IPV6 are both disabled
Explanation: The cache.conf is configured to disable both IPv4 and IPv6
queries.
APPLICATION: RESOLVER LOG_ERR TCP enabled, but number of incoming or outgoing TCP's set
to zero
Explanation: The outgoing-num-tcp and/or incoming-num-tcp attributes in
cache.conf are configured to 0 and TCP queries are enabled.
APPLICATION: RESOLVER LOG_ERR No listening interfaces configured
Explanation: No interfaces are configured in cache.conf for incoming queries.
APPLICATION: RESOLVER LOG_ERR failed to close TCP listen on %s#%d %s
Explanation: A problem occurred when attempting to close the TCP
connection when stopping the server.
Recommended Action: Reboot the server. If the problem continues, contact
Secure64 customer support.
APPLICATION: RESOLVER LOG_ERR failed to close UDP listen on %s#%d %s
Explanation: A problem occurred when attempting to close the UDP
connection when stopping the server.
Recommended Action: Reboot the server. If the problem continues, contact
Secure64 customer support.
466

APPLICATION: RESOLVER LOG_WARNING Error: cannot parse rr :<status>: <str
Explanation: An error occurred trying to parse an rr from the cache_dump file.
The entire rrset will be skipped but the file load will attempt to continue.
Recommended Action: None, errors in the dumped cache file are not user
correctable.
APPLICATION: RESOLVER LOG_WARNING Error: expected rrsig but got <str>
Explanation: An error occurred trying to parse an rr from the cache_dump file,
an rrsig was expected but not found. The entire rrset will be skipped but the file
load will attempt to continue.
correctable.
APPLICATION: RESOLVER LOG_WARNING Error: cannot convert rr data :<status>
Explanation: An error occurred trying to manipulate rr data from the
cache_dump file. The entire rrset will be skipped but the file load will attempt to
continue.
correctable.
APPLICATION: RESOLVER LOG_ERR Error: out of memory
Explanation: The system has insufficient memory to continue the current
action, which will be aborted.
Recommended Action: Restart the server or reboot the system. If the
problem persists, add memory or contact Secure64 customer support.
APPLICATION: RESOLVER LOG_WARNING Error: expected ';rrset' but got <str>
Explanation: The expected ";rrset" meta line was missing or corrupted in the
cache_dump file. The load of the cache_dump file will be aborted.
Recommended Action: Remove the corrupted cache_dump file.
APPLICATION: RESOLVER LOG_WARNING Error: bad rrset spec <str>
Explanation: The rrset meta line control information is corrupted. The load of
the cache_dump file will be aborted.
APPLICATION: RESOLVER LOG_WARNING Error: bad rrset without contents
Explanation: An rrset control line indicates a saved rrset with no rrs.The load
of the cache_dump file will be aborted.
APPLICATION: RESOLVER LOG_WARNING Error: line too short, <str>
Explanation: The query name, type, class were not all present in the saved
message cache entry. The entire message entry will be skipped but the file
load will attempt to continue.
correctable.
APPLICATION: RESOLVER LOG_WARNING Error: cannot parse: <status> <str>
Explanation: The question section could not be reconstructed from the
information in the cache_dump file. The entire message entry will be skipped
but the file load will attempt to continue.
correctable.
467

APPLICATION: RESOLVER LOG_WARNING Error: cannot convert dname format: <status>
Explanation: Could not create a dname from the data parsed out of the
cache_dump file. The entire message entry will be skipped but the file load will
attempt to continue.
correctable.
APPLICATION: RESOLVER LOG_WARNING Error: cannot parse flags: <str>
Explanation: The query flags could not be parsed. The entire message entry
will be skipped but the file load will attempt to continue.
correctable.
APPLICATION: RESOLVER LOG_WARNING Error: expected msg but got <str>
Explanation: The expected "msg" meta line was missing or corrupted in the
cache_dump file. The load of the cache_dump file will be aborted.
APPLICATION: RESOLVER LOG_WARNING Error: cannot parse numbers: <str>
Explanation: The message entry meta line control information is corrupted.
The load of the cache_dump file will be aborted.
APPLICATION: RESOLVER LOG_ERR Error: cannot parse name
Explanation: For command “cachedns lookup", "cachedns flush type",
"cachedns flush zone", "cachedns flush name,” the zone name entered on the
command line is not parsable as a dname.
Recommended Action: Check the zone name for correctness
APPLICATION: RESOLVER LOG_ERR Error: out of memory
Explanation: For command “cachedns lookup", "cachedns flush type",
"cachedns flush zone", "cachedns flush name,” the system has insufficient
memory. The action will be aborted.
Recommended Action: Restart the server or reboot the system. If the
problem persists, add memory or contact Secure64 customer support.
APPLICATION: RESOLVER LOG_INFO Removing <name>:<type> from rrset cache
Explanation: Informational message indicating what is being removed from
the referral cache
APPLICATION: RESOLVER LOG_INFO Removing <name>:<type> from msg cache
Explanation: Informational message indicating what is being removed from
the message/answer cache
APPLICATION: RESOLVER LOG_INFO Removed <number> rrsets, <number> messages and <number>
key entries
Explanation: Informational message indicating what is being flushed from the
caches
APPLICATION: RESOLVER LOG_INFO Server for zone %s is a recursive resolver.
Explanation: Answers for the specified zone are available only from a
recursive resolver. If there is not an RR in the answer section of the response,
the query is reissued with the RD bit set.
468
Stub Resolver Logging Messages

Table 83 lists the stub resolver logging System: Subsystems, Severity, and Text.
Table 83. Stub resolver logging messages

APPLICATION: RESOLVER LOG_WARNING DNS resolver stopped
Explanation: Reconfiguring nameserver.
APPLICATION: RESOLVER LOG_ERR Error opening resolv.conf file.
Explanation: Missing or corrupted resolv.conf file
Recommended Action: Reboot the server and run the fsck utility. Contact
Secure64 support if the error continues.
APPLICATION: RESOLVER LOG_ERR No nameservers configured.
Explanation: Resolver has no configured nameserver to query
Recommended Action: Login as a sysadmin user and execute the
"nameserver" command to configure at least one nameserver.
APPLICATION: RESOLVER LOG_INFO "scrub for", zonename, LDNS_RR_TYPE_NS, qinfo->qclass
Explanation: This is an informational message indicating that message
scrubbing is occurring.
APPLICATION: RESOLVER LOG_WARNING rrset alloc: out of 64bit ids. Clearing cache.
Explanation: The allocation cache (pre-allocated memory for speed
enhancements) has been filled and the cache will be re-initialized.
APPLICATION: RESOLVER LOG_ERR bad dname in dname_pkt_copy
Explanation: The DNAME length is too long.
APPLICATION: RESOLVER LOG_INFO Packet contains rrset data in multiple sections, dropped
last part.
Explanation: Duplicate RR/RRset data. Since trust in RR data depends on
the section it is in, silently drop the last part. The less trustworthy part is
discarded, and the last part is more likely to be incomplete. RFC 2181: An
RRset can occur only once in a response.
APPLICATION: RESOLVER LOG_DEBUG Found DNAME rrset with size > 1: %u
Explanation: A DNAME rrset was found to have more than 1 record in it.
APPLICATION: RESOLVER LOG_DEBUG synthesized CNAME too long
Explanation: There was an error synthesizing the CNAME during scrubbing.
469
Table 83. Stub resolver logging messages

APPLICATION: RESOLVER LOG_DEBUG Found CNAME rrset with size > 1: %u
Explanation: A CNAME rrset was found to have more than 1 record in it. The
first record will be used.
APPLICATION: RESOLVER LOG_ERR find_delegation: out of memory
APPLICATION: RESOLVER LOG_ERR find_delegation: addrs out of memory
APPLICATION: RESOLVER LOG_ERR Out of memory.
APPLICATION: RESOLVER LOG_ERR Out of memory allocating incoming dns_msg
APPLICATION: RESOLVER LOG_ERR out of memory synthesizing CNAME
470
BGP Logging Messages

Table 84 lists the BGP application logging System: Subsystems, Severity, and Text.
Table 84. BGP logging messages

APPLICATION: BGP LOG_WARNING connection attempted by unknown neighbor %s
Explanation: An unknown system attempted to connect to the server.
APPLICATION: BGP LOG_INFO state change %s -> %s, reason:%s
Explanation: A change in state of the connection with a neighbor has
occurred.
APPLICATION: BGP LOG_CRIT %s: received notification, unknown errcode %u, subcode %u
Explanation: Illegal error code value in a received NOTIFICATION message
Recommended Action: Contact vendor of peer for clarification of subcode
value.
APPLICATION: BGP LOG_CRIT received notification: %s, unknown subcode %u
Explanation: Illegal subcode code value in a received NOTIFICATION
message
Recommended Action: Contact vendor of peer for clarification of subcode
value.
APPLICATION: BGP LOG_CRIT received notification: %s
Explanation: Received a NOTIFICATION message from neighbor with the
given error code string.
Recommended Action: Check configuration of local BGP and peer based on
the message string.
APPLICATION: BGP LOG_CRIT received notification: %s, %s
Explanation: Received a NOTIFICATION message from neighbor with the
given error code string and error sub code string.
Recommended Action: Check configuration of local BGP and peer based on
the error code and error sub code strings.
APPLICATION: BGP LOG_INFO connecting to %s from %s
Explanation: Attempting to establish a TCP connection with the given
neighbor and the given source IP address.
APPLICATION: BGP LOG_INFO connection to %s from %s failed: %s
Explanation: Failed to establish a TCP connection with the given neighbor
with the given source IP address.
Recommended Action: Check the configuration of the local BGP and peer,
based on the error string.
APPLICATION: BGP LOG_INFO connection to %s from %s established
Explanation: Successfully established a TCP connection with the given
neighbor and the given source IP address.
471

APPLICATION: BGP LOG_WARNING bad length, %d, from %s
Explanation: Message was too long or too short
APPLICATION: BGP LOG_WARNING sync error from %s
Explanation: Beginning of message was garbled
APPLICATION: BGP LOG_WARNING received msg with unknown type %d from %s
Explanation: A BGP message with an unknown type value was received.
Recommended Action: Contact vendor of peer for clarification of he received
message type value.
APPLICATION: BGP LOG_WARNING received OPEN: illegal len: %u byte from %s
Explanation: The value of the length field in the received OPEN message was
less than the minimum of 29.
Recommended Action: Contact vendor of peer for clarification of the
received message length value.
APPLICATION: BGP LOG_WARNING received KEEPALIVE: illegal len:%u byte from %s
Explanation: The value of the length field in the received KEEPALIVE
message was less than the minimum of 19.
Recommended Action: Contact vendor of peer for clarification of the
received message length value.
APPLICATION: BGP LOG_WARNING unrecognized version, %d, from %s
Explanation: Message not in BGP version 4 format
Recommended Action: Verify peer is configured for BGP version 4.
APPLICATION: BGP LOG_WARNING unexpected AS, %d, from %s expected %d
Explanation: Unexpected AS value in message from peer.
Recommended Action: Check local BGP and peer BGP configurations for
proper AS values.
APPLICATION: BGP LOG_WARNING unacceptable holdtime, %d, from %s
Explanation: A holdtime with the value of zero or a value less than the
configured minimum holdtime was received in the OPEN message from the
peer.
proper holdtime values.
APPLICATION: BGP LOG_ERR Missing MD5 authenticator from %s
Explanation: The local BGP was expecting TCP segments from the peer that
contain the TCP MD5 signature option described in RFC 2385.
proper enabling of RFC 2385 support.
APPLICATION: BGP LOG_ERR Bad MD5 authenticator from %s
Explanation: A TCP segment was received from the peer, but the value of the
received TCP MD5 signature option did not validate with the locally configured
password or key.
properly configured shared password or key.
APPLICATION: BGP LOG_INFO Nexthop %s1 now %s2 %s3 %s4
Explanation: The nexthop has been learned from an UPDATE message.
Recommended Action: If the nexthop shows “invalid” and you have control of
the neighbor router, check the router for configuration error.
472

APPLICATION: BGP LOG_INFO neighbor %s1 %s2 %s3 %s4 %s5
Explanation: Secure64 DNS received an update or withdraw message
APPLICATION: BGP LOG_INFO neighbor description %s not unique, request aborted
Explanation: Two neighbors have the same description
Recommended Action: Change bgp.conf to avoid same descriptions for
different neighbors
APPLICATION: BGP LOG_INFO listening on [ipaddress]
Explanation: The BGP service is listening on the defined IP address.
APPLICATION: BGP LOG_ERR Failed to get memory for path
Explanation: System is out of memory
Recommended Action: Reboot the Secure64 DNS server
473
LDAP Logging Messages

Table 85 lists the LDAP logging System: Subsystems, Severity, and Text.
Table 85. LDAP logging messages

APPLICATION: LDAP LOG_ERR too many uris. Maximum allowed is 256
Explanation: Secure64 LDAP client supports 256 uris in the ldap.conf file
Recommended Action: Reduce number of uris in ldap.conf..
APPLICATION: LDAP LOG_ERR readLdapConfig programmer error
Explanation: A program error has occurred; the system may be out of
memory
Recommended Action: Contact Secure64 support.
APPLICATION: LDAP LOG_ERR failed to allocate memory for ldap configuration
Explanation: out of memory
Recommended Action: Reboot system. Contact Secure64 support if
rebooting does not resolve the problem.
APPLICATION: LDAP LOG_ERR Failed to open ldap config file
Explanation: file system error
Recommended Action: Reboot and perform fsck. If problem continues,
contact Secure64 support.
APPLICATION: LDAP LOG_ERR Error on the ldap.conf file line <line number> "<line
content>"
Explanation: Invalid entry in ldap.conf file
Recommended Action: Check ldap.conf and modify accordingly.
APPLICATION: LDAP LOG_ERR Error: not all required ldap.conf fields are defined
Explanation: Some required fields are not defined in ldap.conf
Recommended Action: Define all required fields in ldap.conf. Fields include
BACKUP, BASE, BGPADMIN, BGPCREATE, BINDDN, BINDPASSWD,
LOGINADMIN, LOGINCREATE, SEARCHFILTER, SECURITYADMIN,
SECURITYCREATE, SNMPADMIN, SNMPCREATE, SYSADMIN,
SYSCREATE, UPGRADE, URI, VIEWER, CACHEDNSADMIN,
CACHEDNSCREATE
APPLICATION: LDAP LOG_ERR Error: with BINDDN and BINDPASSWD tokens
Explanation: BINDDN or BINDPASSWD is defined without the other in
ldap.conf; these parameters must be defined as a pair.
Recommended Action: Check ldap.conf for missing parameter or incorrect
syntax.
APPLICATION: LDAP LOG_ERR Error: local address is not one of the configured
interfaces
Explanation: The LOCALADDR attribute defined in ldap.conf is not a
configured IP address for Secure64 DNS Cache.
Recommended Action: Check ldap.conf for incorrect IP address or do not
define so that Secure64 DNS Cache automatically selects a configured IP
address.
474

APPLICATION: LDAP LOG_ERR LDAP authentication already started
Explanation: LDAP was already started when the authenticate ldap command
was issued
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to parse configuration
Explanation: ldap.conf may contain errors.
Recommended Action: Check ldap.conf parameters and syntax.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to allocate memory
Recommended Action: Reboot system. If the problem still occurs, contact
Secure64 support.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to set protocol version
Explanation: Program error
Recommended Action: Contact Secure64 support
APPLICATION: LDAP LOG_ERR Failed to bind to LDAP server <IP>
Explanation: Network failure; LDAP server down or unreachable
Recommended Action: Check network connection and that the LDAP server
is up and reachable.
APPLICATION: LDAP LOG_ERR Bind to ldap server <IP> succeeded
Explanation: The Secure64 LDAP client bind to the LDAP server was
successful
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to get second bind
response: <reason>
Explanation: The LDAP client did not receive a second bind response due to
<reason>, most likely due to network failure.
Recommended Action: Check network connection or reason given.
APPLICATION: LDAP LOG_INFO User <user name> authenticated!
Explanation: User authenticated via ldap
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to send second bind
request: <reason>
Explanation: The LDAP client did not send a second bind response due to
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to send unbind request:
<reason>
Explanation: The LDAP client did not send an unbind response due to
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to receive search
response: <reason>
Explanation: The LDAP client did not receive a search response due to
475

APPLICATION: LDAP LOG_ERR LDAP authentication client failed to send search request:
<reason>
Explanation: The LDAP client did not send the %s search request, most likely
due to network failure.
Recommended Action: Check network connection.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to get first bind
response: <reason>
Explanation: The LDAP client did not receive the first %s bind response, most
likely due to network failure.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to parse first bind
result: <reason> (<error code>)
Explanation: The LDAP client did not parse the first bind result due to
<reason>, most likely due to receiving a bad packet.
Recommended Action: Check LDAP configuration on both client and server
side.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to send first bind:
<reason>
Explanation: The LDAP client did not send the %s first bind, most likely due to
network failure.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to connect to <IP>:
<reason>
Explanation: The LDAP client did not connect to the given IP address, most
likely due to network failure.
APPLICATION: LDAP LOG_ERR Connection to all LDAP servers failed, using local
database
Explanation: All configured LDAP servers are unreachable; system is using
local user database for authentication.
Recommended Action: Check network connection and make sure LDAP
servers are up and reachable.
APPLICATION: LDAP LOG_INFO attempting to connect to LDAP server <IP>
Explanation: LDAP client is attempting to bind to the configured LDAP server.
APPLICATION: LDAP LOG_ERR LDAP authentication already in progress
Explanation: Another LDAP authentication process is in-flight while the
system is attempting to complete a new LDAP authentication instance.
Recommended Action: Wait for existing process to complete, which should
occur within 1-60 seconds. Check syslog for status messages.
APPLICATION: LDAP LOG_ERR Failed to start LDAP authentication client: <reason>
Explanation: LDAP client won’t start, due to reason given.
Recommended Action: Take action according to reason given. Possible
causes can be low memory or ldap.conf error.
APPLICATION: LDAP LOG_ERR LDAP authentication client failed to start, using local
user database.
Explanation: LDAP authentication is enabled, but LDAP is unable to start at
boot time.
Recommended Action: Login as local user, enable the loginadmin role, and
start LDAP manually with the authenticate ldap command.
476

APPLICATION: LDAP LOG_ERR Failed to allocate LDAP authentication client instance
Explanation: Program error
Recommended Action: Contact Secure64 support.
APPLICATION: LDAP LOG_ERR Failed to bind to LDAP server <reason>
Explanation: The LDAP client cannot connect to the LDAP server due to the
given reason.
Recommended Action: Take action according to reason given. Possible
causes can be low memory or ldap.conf error.
477
System Boot Messages

Table 86 lists messages that display during system boot.
Table 86. System boot messages
Message Explanation Recommended Action

System Configuration Error: Platform The server hardware platform does not Contact Secure64 support
Mismatch match the image platform, where:
This image is for a <system-platform> system-platform is BXB, ZX-2, ZX-1, or
platform E8870
This hardware requires an image for image-platform is BXB or ZX-2
<image-platform>
System Configuration Error: Platform The server hardware is not supported. Contact Secure64 support
Mismatch
This hardware is not supported
System Configuration Error: Hardware Hardware threads are enabled and should be Issue the following EFI shell commands
threads enabled disabled. to disable hardware threads:
To fix this problem, issue the EFI cpuconfig threads off
commands:
reset
cpuconfig threads off
reset
478
Appendix C: Unbound Configuration Differences
Appendix C: Unbound Configuration

Differences
Because Secure64 DNS Cache is not a general-purpose server, it does not require some of the
attributes in the configuration file that are used in the Unbound implementation. In addition,
Secure64 DNS Cache and the SourceT micro operating system include built-in security
protections against attacks such as protocol exploits, TCP SYN floods, buffer overflows, and
malware that are automatic and require no additional configuration or activation. For UDP and
TCP data flood attacks, Secure64 DNS Cache includes rules-based limits. The system
administrator (sysadmin role) configures rate limiting and DoS/DDoS mitigation.
Table 87 lists the differences in Secure64 DNS Cache and Unbound 1.2.1 configuration
attributes. When you start Secure64 DNS Cache using the start cachedns command, any
unsupported attributes enabled in cache.conf are listed as warnings on the command line and
in syslog.
Table 87. Unbound configuration differences
Attribute: Description
verbosity: In Secure64 DNS Cache, syslog verbosity is configured
by the sysadmin user with the loglevel command.
extended-statistics: Secure64 DNS Cache provides a custom statistics set as
described in Server Activity Reporting and Statistics on
page 215.
num-threads: Secure64 DNS Cache does not support threading at this
time.
interface-automatic: Detects source interface on UDP queries and copies
them to replies. Unbound experimental feature.
do-udp: Deprecated in Secure64 DNS Cache version 2.8; the
server always accepts UDP queries, making the attribute
unnecessary.
outgoing-range: Secure64 DNS Cache is not a general-purpose server
and does not require port restrictions.
outgoing-port-permit: Secure64 DNS Cache is not a general-purpose server
outgoing-port-avoid: Secure64 DNS Cache is not a general-purpose server
num-queries-per-thread: Secure64 DNS Cache does not support threading at this
time.
jostle-timeout: Secure64 DNS Cache and the SourceT micro operating
system provide defense mitigation and rules.
do-daemonize: Secure64 DNS Cache is not a general-purpose server.
chroot: Secure64 DNS Cache provides a built-in chroot
mechanism based on roles.
username: Secure64 DNS Cache has a built-in user and role
structure.
479
directory: Secure64 DNS Cache provides a built-in default directory

structure based on roles.
logfile: Secure64 DNS Cache logs to syslog, which is configured
by the sysadmin role.
use-syslog Secure64 DNS Cache logs to syslog, which is configured
by the sysadmin role.
pidfile: Secure64 DNS Cache is not a general-purpose server
and does not require a process ID.
module-config: All modules (validator and iterator) are automatically
enabled in Secure64 DNS Cache.
access-control: The Unbound allow_snoop option is not currently
supported.
remote-control: Remote control of caching server commands is not
currently supported.
control-enable: Remote control of caching server commands is not
control-interface: Remote control of caching server commands is not
control-port: Remote control of caching server commands is not
server-key-file: Remote control of caching server commands is not
server-cert-file: Remote control of caching server commands is not
control-key-file: Remote control of caching server commands is not
control-cert-file: Remote control of caching server commands is not
stub-prime: Priming of the NS set is not currently available.
target-fetch-policy: Not supported at this time.
harden-answer Deprecated in Secure64 DNS Cache version 2.8 for
security and performance reasons.
harden-referral-path: Hardening the referral path burdens the authority servers
and generates an extra query load that could lead to
performance problems.
(Unbound experimental option; not an RFC standard.)
harden-short-bufsize: Not supported at this time.
harden-large-queries: Not supported at this time.
outgoing-num-tcp: Not supported at this time.
cache-min-ttl: Not supported at this time.
unwanted-reply-threshold: Not supported at this time.
msg-buffer-size: Not supported at this time.
minimal-responses: This feature is not available in Unbound. See Configuring
Basic Server Attributes on page 96.
harden-mismatch: This feature is not available in Unbound. See Configuring
for Basic Security on page 118.
num-recursive-clients: This feature is not available in Unbound. See Configuring
Performance Attributes on page 101.
480
incoming-query-timeout: This feature is not available in Unbound. See Configuring

outgoing-query-timeout: This feature is not available in Unbound. See Configuring
outgoing-query-increment: This feature is not available in Unbound. See Configuring
cache-ttl: This feature is not available in Unbound. See Configuring
the Answer Cache and the Referral Cache on page 105.
481
482
Appendix D: Example Configuration File

Secure64 DNS Cache uses a configuration file cache.conf to define server software behavior.
A sample configuration file named s64_example.conf is included in the software installation,
and you can copy the example file to use as your server’s cache.conf file.
Note To enable an attribute, remove the # (comment) symbol from the beginning of the line. You must also
stop and start the caching server software for configuration changes to be read.
# Example configuration file.

#
# this is a comment.
# Use this to include other text into the file.

# include: "otherfile.conf"
# The server clause sets the main parameters.

server:
# Whitespace is not necessary, but looks cleaner.
# Specifies starting the DNS caching server automatically when the

# system boots. The default is do not autostart.
# auto-start: no
# Specifies starting the BFD service automatically when the

# BFD is also stopped automatically when the caching server stops.
# bfd-auto-start: no
# Specifies starting the BGP service automatically when the

# BGP is also stopped automatically when the caching server stops.
# auto-bgp: no
# Specifies if the DNS caching server should automatically dump the

# answer and referral caches when the server is shut down.
# The default is no.
# dump-cache-on-stop: no
# Specify if statistics logged are to be cumulative from the time

# the server starts or are since the last time the statistics were
# reported to the command line or log file.
# statistics-cumulative: no
483
# Specify the interval for logging statistics to a file. If 0 (zero)

# writing to the log file is disabled.
# The default is 0.
# statistics-interval: 0
# Specifies if the DNS caching server should automatically load the

# answer and referral caches from a cache_dump file, if one is found
# when the server starts. The default is no.
# load-cache-on-start: no
# Specifies if the DNS caching server should respond with only the
# answer section (dropping the authority and additional sections)
# minimal-responses: no
# if yes, generate cache refreshing queries for message cache entries

# retrieved via a cache hit which are within 10% of their ttl expiring.
# prefetch: no
# Specify the set of IPv4 and IPv6 addresses to listen for queries from
# clients and give answers back to clients. At least one address must
# must be specified, and the addresses must already be configured with
# the ifconfig command in the sysadmin role. Specify 0.0.0.0 to listen on
# all configured IPv4 addresses, and specify ::0 to listen on all available
# IPv6 addresses. Specify one or more IP addresses on a separate
# 'interface:' line.
#
# interface: 192.168.127.199
# interface: 192.0.2.154
# interface: 2001:DB8::5
# Specify the port to use when answering queries. Default is 53.

# port: 53
# Specify the set of source IP addresses used to send outgoing queries to

# authoritative servers. The default is to use all configured IP addresses
# as appropriate. In most cases the default is the desired behavior in
# order to maximize the number of source IP addresses used.
# In order to restrict the set of set of source IP addresses used to send
# outgoing queries, specify one or more IP addresses on a
# separate 'outgoing-interface:' line.
# outgoing-interface: 192.0.2.153
# outgoing-interface: 2001:DB8::5
# outgoing-interface: 2001:DB8::6
# Control which clients are allowed to make (recursive) queries

# to this server by specifying ip-address and action, or specify
484
# classless netblocks with /size and action. Choose deny (drop message),
# refuse (polite error reply), allow. By default, everything except the
# local host is refused.
# access-control: 127.0.0.0/8 allow
# access-control: ::0/0 refuse
# access-control: ::1 allow
# access-control: ::ffff:127.0.0.1 allow
# specify the number of recursive clients per listening interface

# num-recursive-clients: 768
# specify a value (in milliseconds) for the UDP read timeout for
# recursive queries
# outgoing-query-timeout: 400
# Parameters for query logging.

# logging-file-write-immediate: no # flush log entry to disk immediately
# logging-file-num: 10 # max number of log files kept
# logging-file-size: 1000000000 # max size of each log file (bytes)
# logging-file-pcap: yes # write log files in pcap format (default yes)
# logging-flag-query-recv: yes # packets received from clients
# logging-flag-query-resp: yes # responses sent to clients
# logging-flag-resolv-query: yes # resolver queries to authoritative servers
# logging-flag-resolv-resp: yes # responses from authoritative servers
# specify the amount (in milliseconds) to increment the UDP read timeout on
# subsequent queries to the same server when a previous query timed out
# outgoing-query-increment: 400
# specify a value (in seconds) between 1 and 30 for the amount of time to
# tie up resources trying to answer a query before dropping it in favor
# of servicing the next incoming query in the queue. Information gained
# from intermediate recursive queries will be cached, even after the
# original external query is dropped.
# incoming-query-timeout: 30
# Enable IPv4, 'yes' or 'no'. The default is 'yes'.

# do-ip4: yes
# Enable IPv6, 'yes' or 'no'. The default is 'yes'.

# do-ip6: yes
# Enable inbound TCP, 'yes' or 'no'. The default is 'yes'.

# do-tcp: yes
485
# Specify the number of incoming simultaneous tcp buffers. The default

# is 10.
# incoming-num-tcp: 10
# Specify the file to read root hints from. Get one from
# ftp://FTP.INTERNIC.NET/domain/named.cache. The default is no
# root hints file.
# root-hints: ""
# EDNS reassembly buffer to advertise to UDP peers.

# A setting of 1460 can solve issues with firewalls or servers than
# cannot handle the edns option or UDP fragmentation.
# edns-buffer-size: 4096
# Specify in bytes the buffer size for handling DNS data. No messages
# (answers) larger than this size can be sent or received, by UDP or TCP.
# The default is 65552.
# msg-buffer-size: 65552
# Specify the amount of memory to use for the message (answer) cache. A
# plain number of bytes or append k, m or g. The default is '128m'.
# msg-cache-size: 128m
# Specify the number of slabs to use for the message (answer) cache. The
# number # of slabs must be a power of 2. More slabs reduce lock
# contention, but fragment memory usage. The default is 1 slab.
# msg-cache-slabs: 1
# Specify the amount of memory to use for the RRset cache. A plain
# number of bytes or append k, m or g. The default is '4m'.
# rrset-cache-size: 128m
# Specify the number of slabs to use for the RRset cache. The number
# of slabs must be a power of 2. More slabs reduce lock contention,
# but fragment memory usage. The default is 1 slab.
# rrset-cache-slabs: 1
# Specify in seconds the time to live (TTL) value cap for RRsets and
# messages in the cache. Items are not cached for longer. The default
# is 86400 seconds (24 hours).
# cache-max-ttl: 86400
# Specify in seconds the time to live (TTL) value cap for cached
# servfail responses in the message cache.
# Items are not cached for longer. The default is 300 seconds (5 minutes).
# The minimum value is 1 second, the maximum value is 300 seconds.
# cache-servfail-ttl: 300
486
# Specify in seconds the time to live (TTL) value for cached roundtrip
# times and EDNS version information for hosts. The default is 900 seconds.
# infra-host-ttl: 900
# Specify in seconds the time to live (TTL) value for cached lame
# delegations. The default is 900 seconds.
# infra-lame-ttl: 900
# Specify the number of slabs to use for the Infrastructure cache. The
# number of slabs must be a power of 2. More slabs reduce lock contention,
# infra-cache-slabs: 1
# Specify the maximum number of hosts that are cached (roundtrip times,
# EDNS). The default is 10000 hosts.
# infra-cache-numhosts: 10000
# Specify in bytes the maximum size of the lame zones cached per host. A
# plain number of bytes or append k, m or g. The default is '10k'.
# infra-cache-lame-size: 10k
# Specify the amount of memory to use for the key cache. A plain
# number of bytes or append k, m or g. The default is '64m'.
# key-cache-size: 64m
# Specify the number of slabs to use for the key cache. The number
# of slabs must be a power of 2. More slabs reduce lock contention,
# key-cache-slabs: 1
# Specify whether or not the server should drop all incoming queries
# for data of the type "ANY". Default is 'no'.
# drop-any: no
# Specify whether or not the server should drop all incoming queries
# for data of the type "MX". Default is 'no'.
# drop-mx: no
# Specify a number of locally served zones.

# local-zone: <zone> <type> [RRtype] [log]
# local-data: "<resource record string>"
# where <type> is one of the following:
# o deny - serves local data (if any), else, drops queries.
# o refuse - serves local data (if any), else, replies with error.
# o static - serves local data, else, nxdomain or nodata answer.
# o transparent - gives local data, but resolves normally for other
# names.
# o redirect - serves the zone data for any subdomain in the zone.
487
# o nodefault - turns off default content for AS112 zones.

#
# Optionally specifying an RRtype allows one of the above action types
# to be specified for the given RRtype for the zone.
#
# The log specifier indicates if matches on the local zone should be logged.
# The parameter is optional and the default is no logging.
#
# Defaults are local host address, reverse for 127.0.0.1 and ::1
# and nxdomain for AS112 zones. When one of these zones is configured,
# the default content is omitted, or you can omit it with 'nodefault'.
#
# If local-data is configured without specifying local-zone, by
# default a transparent local-zone is created for the data. local-data
# statements are allowed to contain private addresses.
#
# Specify locally served with
# local-zone: "local." static
# local-data: "mycomputer.local. IN A 192.0.2.51"
# local-data: 'mytext.local TXT "content of text record"'
#
# Override certain queries with
# local-data: "adserver.example.com A 127.0.0.1"
#
# Redirect a domain to a fixed address with
# (this makes example.com, www.example.com, etc, all go to 192.0.2.3)
# local-zone: "example.com" redirect
# local-data: "example.com A 192.0.2.3"
# Specify local data shorthand for a PTR record with the reversed IPv4
# IPv6 address and the hostname. A TTL can be included.
# local-data-ptr: "192.0.2.3 7200 www.example.com"
# Settings for local-zone logging:

# Specify the maximum number of local zone logging files
# The value must be between 1 and 128. The default is 128
# local-zone-log-file-num: 128
# Specify the maximum size of local zone logging files

# The default size is 137MB (143654912 bytes).
# local-zone-log-file-size: 143654912
# generate queries for the specified zones at server startup to preload

# the cache with responses for commonly requested zones. Only class IN and
# A, AAAA and PTR record types supported.
# preload-zone: example.com A
# preload-zone: example.com AAAA
488
# Specify ('yes' or 'no') whether or not to answer id.server and

# hostname.bind queries. The default is to not answer these queries.
# hide-identity: yes
# Specify ('yes' or 'no') whether or not to answer version.server and

# version.bind queries. The default is to not answer these queries.
# hide-version: yes
# Specify the identity to report. Leave "" or default to return nodename.

# identity: ""
# Specify the version to report. Leave "" or default to return the

# software version.
# version: ""
# Harden against out of zone rrsets, to avoid spoofing attempts ('yes'

# or 'no'). The default is 'yes'.
# WARNING: setting this option to 'no' will open the system to
# cache poisoning.
# harden-glue: yes
# Harden against too many mismatched responses and suspect a cache

# poisoning attempt. When 'yes' do not query if multiple mismatched
# responses.
# Default is no.
# harden-mismatch: no
# Harden against receiving dnssec-stripped data ('yes' or 'no'. If 'no',

# failing to validate dnskey data for a trustanchor will trigger insecure
# mode for that zone (like not having a trustanchor). The default is
# 'yes', which insists on dnssec data for trust-anchored zones.
# harden-dnssec-stripped: yes
# Enforce the privacy of specified addresses. These addresses are

# stripped from answers to protect against 'DNS Rebinding' (i.e. using
# a browser as a network proxy). This may cause DNSSEC validation to
# mark answers as bogus. Only 'private-domain' and 'local-data' names
# are allowed to have these private addresses. The default is no
# private addresses.
# private-address: 10.0.0.0/8
# private-address: fd00::/8
# private-address: fe80::/10
# Use 0x20-encoded random bits in the query to foil spoof attempts.

# ('yes' or 'no'). The default is 'no'. This feature is an experimental
489
# implementation of draft dns-0x20.

# use-caps-for-id: no
# Allow the domain (and its subdomains) to contain private addresses.

# private-domain: "example.com"
# Do not query the following ip-addresses. No DNS queries are sent there.
# List one ip-address per entry. List classless netblocks with /size.
# The default is to query all ip-addresses.
# do-not-query-address: 127.0.0.0/8
# do-not-query-address: ::1
# Do not query localhost (127.0.0.0/8 and ::1).

# Default is yes.
# do-not-query-localhost: yes
# Define a domain to omit from DNSSEC validation. This can be used to

# define a "negative trust anchor" to temporarily disable DNSSEC
# validation for a specific domain name.
# domain-insecure: "example.com"
# Override the date for validation with a specific fixed date. The
# date format is <YYYMMDDHHmmss>. Set this only when debugging signature
# inception and expiration. The default is the current date.
# "" or "0" turns the feature off which is the default.
# val-override-date: ""
# Specify in seconds the time to live for bogus data, rrsets and messages.
# This avoids some of the revalidation, until the time interval expires.
# The default is 60 seconds.
# val-bogus-ttl: 60
# Specify ('yes' or 'no') whether the additional section of a secure

# message is kept clean of unsecure data. Useful to shield the users
# of this validator from potential bogus data in the additional section.
# All unsigned data in the additional section is removed from secure
# messages. The default is 'yes'.
# val-clean-additional: yes
# Instruct the validator to mark bogus messages as indeterminate.

# The security checks are performed, but if the result is bogus
# (failed security), the reply is not withheld from the client with
# SERVFAIL as usual. The client receives the bogus data. For messages
# that are found to be secure the AD bit is set in replies.
# The default is 'no'.
# val-permissive-mode: no
490
# Configure NSEC3 maximum iteration counts per keysize. Keep this

# table very short, as a linear search is done. A message with an
# NSEC3 with larger count is marked insecure. List in ascending
# order the keysize and count values.
# val-nsec3-keysize-iterations: "1024 150 2048 500 4096 2500"
# Specify file(s) with trusted keys for validation. The files must
# be in zone file format, with DS and DNSKEY entries. Specify each file
# on a separate 'trust-anchor-file:' line. The default is no trust
# anchor files.
# trust-anchor-file: ""
# Specify DS and DNSKEY trusted keys for validation. Place the entire
# RR on a single line, surrounded by "". TTL is ignored and the default
# class is IN. Specify each trusted key on a separate 'trust-anchor:'
# line. The default is no trust anchor keys.
# (These examples are from August 2007 and may not be valid anymore).
# trust-anchor: "nlnetlabs.nl. DNSKEY 257 3 5
AQPzzTWMz8qSWIQlfRnPckx2BiVmkVN6LPupO3mbz7FhLSnm26n6iG9N Lby97Ji453aWZY3M5/
xJBSOS2vWtco2t8C0+xeO1bc/d6ZTy32DHchpW
6rDH1vp86Ll+ha0tmwyy9QP7y2bVw5zSbFCrefk8qCUBgfHm9bHzMG1U BYtEIQ=="
# trust-anchor: "jelte.nlnetlabs.nl. DS 42860 5 1
14D739EB566D2B1A5E216A0BA4D17FA9B038BE4A"
# Specify file(s) with trusted keys for validation. The file must
# be in BIND-9 style format, the trusted-keys
# { name flag proto algo "key"; }; clauses are read. The default is
# no trusted keys files.
# trusted-keys-file: ""
# Specify a file that contains DLV trusted keys in the same format as
# a trust-anchor-file. There can be only one DLV configured, it is
# trusted from root down.
# Download https://secure.isc.org/ops/dlv/dlv.isc.org.key
# dlv-anchor-file: "dlv.isc.org.key"
# dlv-anchor-file:""
# Specify a DS or DNSKEY record, including the trusted key information,

# for the DLV registry. This ia an alternative to 'dlv-anchor-file:'.
# The default is no DLV anchor.
# dlv-anchor: ""
# Specify the amount of memory to use for the aggressive negative cache
# for DLV. A plain number of bytes or append k, m or g. The default
# is '128m'.
# neg-cache-size: 128m
491
# Specify the IPv4 or IPv6 addresses of the servers to receive redirected

# NXDOMAIN responses. The ip-addresses appear in the A or AAAA records
# of the redirected response. Define one ip-address per line. The
# default is no NXDOMAIN redirection.
# nxdomain-redirect-destination: 71.33.226.72
# nxdomain-redirect-destination: 193.148.127.94
# Specify if nxdomain redirections should be logged to a file on disk

# nxdomain-redirect-log: no
# Specify the maximum number of nxdomain redirection logging files

# The default is 10
# nxdomain-redirect-log-file-num: 10
# Specify the maximum size of nxdomain redirection logging files

# nxdomain-redirect-log-file-size: 1000000000
# Specify in seconds the time to live value to be included in the

# redirected response. The default is 0 seconds (no TTL).
# nxdomain-redirect-ttl: 0
# Specifies a rule string to match one or more fully qualified domain

# names. Domains that match any of the defined pass rules are not
# redirected. The syntax is <"rule1"> [<AND|OR> <"rule2">]. "Rule"
# strings can use the following syntax and symbols for matching:
# <string> - The domain name includes the defined string.
# ^<string> - The start of the domain name must match the rule string.
# <string>.$ - The end of the domain name must match the rule string.
# AND|OR - These operators are used to combine rule strings.
# The default is no rules.
# nxdomain-redirect-pass: ".gov.$"
# nxdomain-redirect-pass: "êxam" AND ".com.$"
# nxdomain-redirect-pass: "êxample.com.$"
# Specify a rule string to match one or more fully qualified domain

# names. When the domain owner response is NXDOMAIN, domains that
# match the defined rules are redirected to the defined redirect
# destination. The syntax is <"rule1"> [<AND|OR> <"rule2">]. "Rule"
# strings can use the following syntax and symbols for matching:
# <string> - The domain name includes the defined string.
# ^<string> - The start of the domain name must match the rule string.
# <string>.$ - The end of the domain name must match the rule string.
# AND|OR - These operators are used to combine rule strings.
# The default is no rules.
# nxdomain-redirect-modify: "example"
# nxdomain-redirect-modify: "êxam" AND ".net.$"
# nxdomain-redirect-modify: "êxample.com.$"
492
# Specify IPv4 or IPv6 addresses to omit from NXDOMAIN redirection or

# specify classless netblocks with /size. Clients with matching IP
# addresses receive the NXDOMAIN response. The default is to redirect
# all client IP addresses.
# nxdomain-redirect-optout: 231.22.0.0/16
# nxdomain-redirect-optout: 184.213.124.6
# Specify ('yes' or 'no') if nxdomain redirection is allowed in certain

# circumstances for signed domains. The default is 'no'.
# nxdomain-redirect-dnssec-allow: no
# Specify the dns64 prefix to be used to synthesize an IPv6 response

# from a A record when no AAAA record exists for a requested zone.
# The prefix must be a valid IPv6 address format.
# dns64-prefix: feed::1:0000:0000/96
# Specify if AAAA responses should be stripped from the answer section

# if the request came across an IPv4 interface
# filter-aaaa-on-v4: no
# Direct the server to rotate the order of RRs within RRsets in the
# answer for a query.
# rrset-roundrobin: no
# Stub zones.
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of nameservers. List zero or more
# nameservers by hostname or by ip-address.
# stub-zone:
# name: "example.com"
# stub-addr: 192.0.2.68
# stub-zone:
# name: "example.org"
# stub-host: ns.example.com.
# Forward zones
# Create entries like below, to make all queries for 'example.com' and
# 'example.org' go to the given list of servers. These servers have to handle
# recursion to other nameservers. List zero or more nameservers by hostname
# or by ip-address. Use an entry with 'name: "."' to forward all queries.
# forward-zone:
# name: "example.com"
# forward-addr: 192.0.2.68
# forward-addr: 192.0.2.73@5355 # forward to port 5355.
# forward-zone:
# name: "example.org"
# forward-host: fwd.example.com
493
# Define a separate cache to allow one or more zones to store

# responses unique to the cache(s).
# cache: name: "zapcache" msg-cache-size: 1024m rrset-cache-size: 512m
# views
# views can be used to control the resolver behavior with respect to
# local zones, nxdomain redirection, dns64 resolution and filtering
# AAAA responses from IPv4 queries, based upon the IP address of either
# the client or the destination. The IP can be an IP, range, subnet, etc...
# View names must be unique. See the entries for local data, nxdomain
# redirection, filter-aaa-on-v4, and dns64 for more details on these
# configuration items.
#
#view:
#view-name: oddball
#
# view for oddball information
#
# match-clients: 192.168.127.12
#
# Specify an alternate set of root hints for this view. The default
# is to use the same hints as the server above. The default is no
# root hints file.
# root-hints: ""
#
# we want to deny access to google, queries will get NXDOMAIN
# local-zone: "google.com" static
#
#
#view:
#view-name: nosearch
#
# don't let the Zap team use Internet search
#
# match-clients: 192.168.133.0/24
# match-destinations: 192.168.127.45
#
# local-zone: "google.com" static
# local-zone: "yahoo.com" static
# local-zone: "bing.com" static
#
# filter-aaaa-on-v4: yes
#
# dns64-prefix: feed::1:0000:0000/96
#
494
# # Specify a unique address to go out on so that

# # authoritative servers can identify the location for
# # location specific responses
# outgoing-interface: 1.2.3.6
#
# # Specify a cache for this view since it may have
# # unique information due to the outgoing-interface
# # specification.
# cache-name: zapcache
495
496
Index
A BGP files 297

AAA (Authentication, Authorization, Accountability) 27 Disk mirroring 291
AAAA record DNS files 298
DNS64 and 149 LDAP files 297
filtering for IPv4 155 Overview 296
access-control attribute 96, 97 RADIUS files 297
ACLs Sensitive Data Protection (SDP) 297
Secure64 DNS console 242 SNMP files 405
activate command 83, 85 System files 297
Active Directory See LDAP backup role 30
AD (Authenticated Data) 190 BFD 388
Add User Account 35 Autostart 389
Additional Section 118, 123 Commands 389
adduser command 33 Configuring 388
Administrator Roles Information 389
About 28 Status command 389
Assigning 39 bfd.conf configuration file 388
backup 30 BGP
bgpadmin 31 Announce 322
cachednsadmin 30 Autostart on boot 309
loginadmin 31 Autostart with DNS server 96
securityadmin 31 Backing up and restoring 297, 329
snmpadmin 31 Commands 318, 320
sysadmin 30 Configuration 306, 309, 316
upgrade 30 Example configuration 307
allow command 242 FIB information 328
Announce, BGP 322 Filter rules 311
ANY Queries (Drop) 122, 173 localpref 310
Anycast Log updates 309
BGP and 303 Logging messages 471
cloud 304 Memory requirements 305
IP addressing 304 Message types 305
ARP Ping 63 Neighbor and group configuration 310
AS (Autonomous System) 303, 309 Neighbor commands 318
AS112 Zones 108 Neighbor information 324
Asymmetrical Routing 256 Overview 303, 305
attach command 230 Preparations 315
authenticate ldap command 357 RIB information 327
authenticate radius command 342 Routing 303
Authenticated Data (AD) 190 Starting and stopping 320
Authentication Status 321
About 27 TCP MD5 and 305, 317
LDAP 331, 347 Testing 324
Local (SSH and serial console) 49 Troubleshooting 328
RADIUS 331, 332 Withdraw 322
Authoritative Answers, see Merge Zones bgp announce command 323
Authoritative Data, see Stub Zones bgp withdraw command 322
Authorization 27 bgp.conf 306
authprobe radius command 340 bgpadmin role 31, 306, 318, 320
auto-bgp attribute 96 bgpcreate role 30
Automatically start BGP 96 Bidirectional Forwarding Detection, see BFD
Automatically start DNS server 96 Birthday Paradox Attack 119
Autonomous System (AS) See AS BL860c Blade, see HP Integrity BL860c i2/i4 Blade
auto-start (DNS) attribute 96 BL860c i2/i4 Blade, see HP Integrity BL860c i2/i4 Blade
Blacklist
B About 226
Backing Up Domains 173
497
Index
Maintaining caching with include files 176 cat command 89

Number of active clients 387 cd command 89
RRtype, queries for specific 238 CEM, see Capacity Expansion Module
Rules 227 CH TXT Query 119
SNMP traps 407 Chassis Sensor Information 392, 412
Statistics 386 chassispoll command 290
See also DDoS, DoS Checklist
bondcfg command 285 BGP preparations 315
Bonding Configuring caching, validation, and resolver 92
About 284 Configuring system 82
Assigning a bond interface 286 SNMP configuration 393
Changing bond configuration 288 chroot jails, Secure64 roles 27
Configuring parameters 285 CLI See Command Line Interface (CLI)
Configuring ports 284 Client access to DNS server 97
Removing a bond interface 288 Client Dictionary File (RADIUS) 332
Status 287 CM (Cryptographic Module) 299
CNAME 118
C Using a local zone 108
Cables comm command 384
Connections 61 Command Line Interface (CLI)
Required 59 About 9
Cache Accessing with a serial console 17
Answer (answers, NXDOMAIN) 105 Accessing with SSH 12
Dumping 204 Exiting or quitting 10
EDNS 107 Using 9
Flush command 193 Commands
Infrastructure (EDNS, RTT, lame) 104 bgpadmin mode 318, 320, 401, 435
Key (RRSIGs) 104 create mode 425
Lame delegations 107 Directory 88
Loading 204 Executing from SSH 14
Memory for message/answer cache 105 History 10
Memory, key cache 108 LDAP administration 357, 437
Memory, lame delegation cache 107 ldapadmin mode 437
Memory, referral cache 105 loginadmin mode 342, 357
Message (answers, NXDOMAIN) 104 RADIUS administration 342
Multiple for views 168 Reference 421
Preload responses for zones 206 securityadmin mode 439
Referral (RRset, NS) 104, 105 sysadmin mode 427
Refresh (prefetch attribute) 206 System state 84
Removing items from with cachedns flush 193 upgrade mode 439
Reporting, See Statistics User account administration (local) 425
Saving 204 Using 9
Separate for views 168 view mode 421
Statistics, See Statistics Compartmentalization 83
Syslog messages 452 Configuration
Warming 204, 206 BGP 306
cache attribute 168 Checklists for system 82
Cache Hits, See Statistics Displaying 201
Cache Misses, See Statistics DNS See Configuration File, DNS
Cache Poisoning LDAP 351
DNS 0x20 mismatches 220 RADIUS 336
Out-of-zone glue protection (harden-glue attribute) 121 SNMP 394
Query/response mismatch protection (harden-mismatch System states, about 83
attribute) 121 System states, commands 84
Security features to address 119 TCP rate limit rules 236
Transaction id mismatch 220 UDP rate limit rules 234
cache.conf See Configuration File, DNS Viewing system 85
cachedns flush command 193 Configuration File, DNS
cachednsadmin role 91, 127 About cache.conf 93
cache_dump file 204 Backing up 298
cache-max-ttl attribute 106 Basic attributes 96
cache-name attribute 164 Checklist 92
cache-servfail-ttl attribute 105 Creating 94
Capacity Expansion Module (CEM) 180 Example (s64.example.conf) 94, 483
498
Index
Format and rules 93 Disk Space See df command

Include files 124 Distributed Denial of Service See DDoS, DoS
Performance attributes 101 DLV (DNSSEC Lookaside Validation), see Trust Anchor
Reload dynamically 185 dlv-anchor attribute 135
scp and 94 dlv-anchor-file attribute 135
Syntax rules 93 DNAME 118
console command 281 DNS
Console, iLO See Integrity iLO Automatically start 96
Console, Secure64 Client access to caching 97
Configuring 73, 281 Configuration See Configuration File, DNS
Limiting connections 236 Starting 184
Options 12 Testing 189
Restricting access 242 DNS address resolution (external) See Name Server
Testing interface 76 DNS Configuration File See Configuration File, DNS
Timeout 283 DNS-0x20 120
Copy Files (cp command) 89 DNS64 148
cp command 89 dns64-prefix attribute 150
CPU utilization (uptime command) 375 DNSSEC Lookaside Validation (DLV), see Trust Anchor
cpuinfo command 374 DNSSEC, see Validation
Creator Roles Documentation Conventions 7
About 28 do-ip4 attribute 97
Assigning 38 do-ip6 attribute 98
bgpcreate 30 domain-insecure attribute 130, 131
cachednscreate 30 do-not-query-address attribute 122
logincreate 30 do-not-query-localhost attribute 122
securitycreate 30 do-tcp attribute 98
snmpcreate 30 do-udp attribute (deprecated) 479
syscreate 30 Drive Space See df command
Cryptographic Module (CM) 299 drop-any attribute 122
drop-mx attribute 122
D dump-cache-on-stop attribute 205
Data flood protection See DDoS, DoS Dumping the Cache 204
Date
Changing 261 E
Displaying system 261 edit command 89
date command 261 Editor 89
DDoS, DoS EDNS
Configuring initial security 79 Buffer configuration 98
Countermeasures 224 Cache information 107
Data flood protection (TCP) 226 IP fragmentation and 256
Data flood protection (UDP) 226 edns-buffer-size attribute 98
Packet inspection (DNS) 225, 257 EFI Shell 19
RRtype query flood protection 238 Ethernet
Rule configuration See Rules Bonding See Bonding
Statistics (show defense info command) 386 Configuring IP address for interfaces 276
Syslog messages 448, 450 Connection location 61
Defense Logging Messages 448, 450 Trunking See Bonding 284
Defense Statistics Information 386 Viewing physical interface information 85
Delete Files or Directories (rm command) 89 exit command 10
Delete User Account 44 Exiting Secure64 DNS 10
deluser command 33 Expiring Cache Entries (refreshing) 206
Denial of Service See DDoS, DoS export syslog command 275
df command 368
dictionary file (RADIUS) 332 F
Dig Utility 189 FIB, BGP 328
Directory File
Create 89 Copy 89, 433, 435, 437, 441
Delete or remove 89 Delete or remove 89
List contents 89 Rename 89
Directory Commands 88 Filter Rules (BGP) 311
discard command 83, 85 filter-aaaa-on-v4 attribute 155
Disk Failure, Recovery From 299 Filtering (DNS)
Disk Information (show disks command) 369 Additional section (val-clean-additional attribute) 123
Disk Mirroring 291 Automatic for security 118
499
Index
Glue information (harden-glue attribute) 121 Recommendations for using 124

Mismatch query/response (harden-mismatch attribute) 121 incoming-num-tcp attribute 98
NSEC3 iterations (val-nsec3-keysize-iterations attribute) 123 incoming-query-timeout attribute 102, 481
Private addresses (private-address attribute) 122 infra-cache-lame-size attribute 107
RRtype for incoming query 173, 238 infra-cache-numhosts attribute 107
Forgery Resistance (DNS-0x20) 120 infra-cache-slabs attribute 107
Forward Zone 138 infra-host-ttl attribute 107
forward-addr attribute 138 infra-lame-ttl attribute 107
forward-host attribute 138 Installer Role 28, 30, 69
Forwarding Information Base See FIB Integrated Lights Out See Integrity iLO
forward-zone clause 138 Integrity iLO
Disabling telnet access 77
G MP LAN port for BL860c i2/i4 blade 67
Glue, Out-of-Zone (harden-glue attribute) 121 MP LAN port for rx2660 62
Graylist MP LAN port for rx2800 i2/i4 66
Number of 387 Security 19, 20
SNMP traps 398, 399, 408 Serial console 17, 62, 65
Statistics 386, 387 Using 19
See also DDoS, DoS Interface (Physical) See Ethernet
interface attribute 96
H Interface(s)
halt command 88 Configuring BGP 81
harden-answer attribute (deprecated) 480 Configuring LDAP (LOCALADDR) 355
harden-dnssec-stripped attribute 121 Configuring multiple IP addresses per 276
harden-glue attribute 121 Configuring RADIUS 338
harden-mismatch attribute 121, 480 Configuring Secure64 console 73
Hardware Configuring Secure64 name server 78
Cables 59 Configuring SNMP 81
Chassis MIB 392, 412 Disabled 278
Connections for HP BladeSystem c3000 Enclosure 68 Information about 378
Connections for HP Integrity BL860c Blade 67 IP address and netmask 276
Connections for HP Integrity BL860c i2/i4 Blade 67 Loopback 280
Connections for HP rx2660 61 Securing 79
Connections for HP rx2800 i2/i4 65 Viewing details 378
Disk mirroring 291 Virtual 280
Polling interval (chassispoll command) 290 VLAN 276
Requirements 2 ip frag command 256
Sensor information (show sensors) 370 IP Fragmentation 256
Hardware Information (SNMP S64-CHASSIS-MIB) 392 IP-MIB.txt 392
help command 9 IPv4 Filtering 152
hide-identity attribute 119 IPv6
hide-version attribute 119 Displaying interface addresses with show ipv6 addr 383
holdtime, BGP 309 Link local address 254, 378
Hostname See Nodename Transition technologies 148
hostname.bind query (denying) 119 Issue File 289
HOST-RESOURCES-MIB.txt 392
HOST-RESOURCES-TYPES.txt 392 K
HP Integrity BL860c Blade 67, 68 Key
HP Integrity BL860c i2/i4 Blade 2, 67, 69 License for software 302
HP Integrity rx2660 2, 61 SSH 49, 50
HP Integrity rx2800 2, 65 key-cache-size attribute 108
key-cache-slabs attribute 108
I KSK, see Trust anchor
IANA PEN (Secure64 28428) 333, 391
ICMP, Blocking Types of 229 L
id.server query (denying) 119 Lame delegation cache 107
identity attribute 119 LAN Ports 3
ifconfig command 276 LDAP
IF-MIB.txt 392 About Secure64 DNS and 347
iLO See Integrity iLO Authentication process 347
Include Files 124 Backing up and restoring 297
DNS configuration file and 124 Configuration, checking 344, 360
Example 124 Configuring (LDAP server) 349
Maintaining caching blacklist and 176 Configuring (Secure64 client) 351, 357
500
Index
Disabling 359 M
Enabling 342, 357 MAC address (physical interface) 378
Encrypting bind password with SDP 244, 351 Management Processor See Integrity iLO
Example configuration (Secure64 client) 352 match-clients attribute 164
Groups (server) 349 match-destinations attribute 164
Hash tag and passwords 347 Memory Requirements
Interface (LOCALADDR) 355 Answer cache size 105
Mapping roles (LDAP server) 350 BGP 305
Mapping roles (Secure64 client) 355 Caching and performance 103
Roles, disabling 356 Key cache size 108
Schemas 349 Lame delegation cache size 107
Search attribute 354 Minimum 2
Secure passwords with hashing 347 Referral cache size 105
Servers supported 347 Memory, see memstat command
Starting 342, 357 memstat command 368
Status 343, 359 Merge Zones 143
Stopping 359 merge-addr attribute 144
Syslog messages 474 merge-zone clause 144
Troubleshooting 362 merge-zone name attribute 144
User account example 58 MIBs for SNMP 392
Version 3 347 Microsoft Active Directory Server See LDAP
ldap.conf 357 minimal-responses attribute 99, 480
license command 302, 439 mkdir command 89
Lightweight Directory Access Protocol See LDAP Modes, About 10
Link Local Address (IPv6) 254, 378 Monitor See VGA
load-cache-on-start attribute 205 Monitoring Query Data (RTQM) 207
Loading the Cache 204 MP Login See Serial Console and Integrity iLO
Local Zone msg-buffer-size attribute 480
CNAME entries examples 113 msg-cache-size attribute 105
Configuring 108 msg-cache-slabs attribute 105
Default zones 114 Multiple Resolver Instances 180
Logging activity 116 Caches and 181
PTR record 110 Processors and 183
Rules and examples 110 Query logging and 211
local-data attribute 110 Views and 181
local-data-ptr attribute 110 MX Queries (Drop) 122, 173
localpref (BGP) 310
local-zone attribute 109 N
local-zone-log-file-num attribute 109 Name Server (Configuring External) 259
local-zone-log-file-size attribute 110 nameserver command 259
Log Level (syslog) 270 NAT64 148
Logfacility (syslog) 271 Negative Trust Anchor (domain-insecure
logfacility command 271 attribute) 130
Logging neg-cache-size attribute 135
Local zone activity 116 Neighbor, BGP
Query data 211 Commands 318
Syslog and syslog local file 269 Configuration 310
Logging In 10 netstat command 380
Logging Out See Exiting Secure64 Network Statistics (netstat command) 380
logging-file-num attribute 213, 214 nodename command 258
logging-file-pcap attribute 213 Nodename, Configuring 258
logging-file-size attribute 213, 214 NOERROR Response 190
logging-file-write-immediate attribute 213 NSEC3 Iteration Limit 123
logging-flag-query-recv attribute 213 ntp command 264, 265
logging-flag-query-resp attribute 213 NTP Server
logging-flag-resolv-query attribute 213 Adding an NTP key 265
logging-flag-resolv-resp attribute 213 Configuring with authentication 265
loginadmin role 31 Configuring without authentication 263
logincreate role 30 Deleting an NTP key 266
LOGINLIM rule 79 Displaying NTP keys 266
loglevel command 270 Displaying NTP server information 267
logmsg command 273 Overview 263
Loopback Interface 280 Removing a configured NTP server 268
ls command 89 Sending a query to an NTP server 267
501
Index
Source IP address 264, 265 DNS 225

ntpdate command 267 Incoming and outgoing 26
ntpkey command 265 No process listening but receiving packets 387
nullchecksums command 257 port attribute 97
num-recursive-clients attribute 102, 480 Power Off 88
NXDOMAIN prefetch attribute 206
Logging redirection activity 162 preload-zone attribute 206
Redirection 156 Private Zones 140
Response (no such domain) 190 private-address attribute 122
Validation and 157 private-domain attribute 122
nxdomain-redirect-destination attribute 158 Privileges, Users and Roles 27, 83
nxdomain-redirect-dnssec-allow attribute 160 Processors
nxdomain-redirect-log attribute 159, 162 Information (cpuinfo command) 374
nxdomain-redirect-log-file-num attribute 159, 162 Multiple resolver instances 183
nxdomain-redirect-log-file-size attribute 159, 162 Utilization (uptime command) 375
nxdomain-redirect-modify attribute 158 Public Key, SSH 49
nxdomain-redirect-output attribute 160
nxdomain-redirect-pass attribute 159 Q
nxdomain-redirect-ttl attribute 159 Quad A Hack, see IPv4 Filtering
Queries
O Enable IPv4 97
OpenLDAP See LDAP Enable IPv6 98
Operating System See SourceT Micro OS Enable TCP 98
outgoing-interface attribute 96 Forgery Resistance (DNS-0x20) 120
outgoing-query-increment attribute 102, 481 Identity denial 119
outgoing-query-timeout attribute 102, 481 Logging 211
Monitoring in real time 207
P Omitting specific IP addresses (do-not-query-address
Packet Flood attribute) 122
About data flood protection 226 Per interface limit (num-recursive-clients attribute) 102
Dropped packet rate 387 See also, Resolver
SNMP traps 409 TCP (incoming buffers) 98
See also DDoS, DoS Testing with dig 189
Packet Inspection Version denial 119
DNS 225 Query Logging 211
Protocol exploits 224 quit command 10
passwd command 33, 51
Passwords R
Enabling and disabling SSH passwords 52 RADIUS
Management 46 About Secure64 DNS and 332
passwd command 33, 51 Authentication process 332
Reset 70 Backing up and restoring 297, 346
Secure configuration 46 Client dictionary file 332
Secure64 51 Configuration, checking 344
Security with SHA-256 hash algorithm 51 Configuring (Secure64 client) 336, 337
sshpwdcommand 52 Disabling 343
PCAP Logging of Queries 211 Enabling 342
Peer See Neighbor, BGP Encrypting shared secret with SDP 244, 339
PEN See IANA PEN Example configuration (Secure64 client) 336
Pending Configuration State 83 Mapping roles (RADIUS server) 333
Performance PAP 337
Configuring to optimize caching 101 radius.conf 336
DLV configuration and 136 Server dictionary file 333
IPv6 queries and 98 Servers supported 332
Memory usage and 103 Shared secret 337, 339
Minimal responses and 99 Status 343
Query timeout and 101 Syslog messages 345
Recursive clients and 101 Testing 340
Performance, Configuring loglevel and 271 Troubleshooting 345
ping command 367 User account example 58
Ping Flood, Blocking with Rules 229 Vendor specific attributes for Secure64 332
ping6 command 367 radius.conf 336, 337
Plink 14 RAID Mirroring 291
Port Randomization 119
502
Index
Rate Limiting (UDP and TCP) See also DDoS, DoS 227 Summary 30
Real Time Query Monitoring (RTQM) rollback command 302
Commands 207 root-hints attribute 98
Data 208, 210 Round Robin DNS Responses (rrset-roundrobin attribute) 99
Examples 209 route asym command 256
reboot command 87 route sym command 255
Recovery Routing
See also, Restoring 299 Adding routes 252
See also, Safe Mode 292 Asymmetrical (Inbound) 256
System overview 299 BGP 303
Redundant Disk 291 Changing and BGP 328
Remote Authentication Dial In User Service See RADIUS Configuring initial 75
remove cmkeys command 440 Default gateway 252
rename command 89 Deleting routes 254
Reporting, See Statistics Displaying IPv4 information with show ip route 382
reset autostart cycle-counter command 295 Displaying IPv6 information with show ipv6 route 382
reset autostart history command 295 Inbound traffic options 255
reset command 33, 47 Link local (IPv6) 252, 254
Reset Password 70 Outbound traffic (standard ARP table) 255
Resolver Route collector 309
Forwarding to another server 138 Symmetrical (Inbound) 255
Multiple instances 180 Routing Information Base See RIB
Performance attributes 101 rrset-cache-size attribute 105
Syslog messages 452 rrset-cache-slabs attribute 106
Timeouts for incoming/outgoing query resolution 102 rrset-roundrobin attribute 99
Transversal limit during query resolution 102 RRSIG
Responses Key cache 104, 108
NOERROR 190 Override expiration (val-override-date attribute) 122
Omitting Authority and Additional sections 99 RRtype Filtering (Incoming Queries) 173, 238
Omitting private addresses from (private-address attribute) 122 RSA Key Information (system) 385
Testing with dig 189 RTQM, see Real Time Query Monitoring
Troubleshooting 192 rule command 227
Types of DNS during testing 190 ruleactions command 232
Restoring Rules
BGP files 297 Attachment of RRtype filtering 240
DNS files 298 Attachment to interface 230
LDAP files 297 BGP filter 311
Overview 296 Command 228
RADIUS files 297 Configuration (general) 227
Sensitive Data Protection (SDP) files 297 Configuration (RRtype filtering) 239
System files 297 Configuration (TCP security) 236
revert command 83, 85 Configuration (UDP security) 234
RFC 2181 118 Default for installation 79
RFCs Disabling actions 232
BGP 305, 306 Drop traffic 235
DNS 3 Examples of RRtype filtering 240
LDAP 347 Examples of UDP and TCP 228
NTP 263, 267 Examples of UDP, TCP, ICMP 229
RADIUS 332 Internal traffic 236
SNMP 391 Order 230
RIB, BGP 327 Pass traffic 237
rm command 89 Removal from interface 233
rmdir command 89 Removal of RRtype filter 241
Roles RRtype filtering 238
About 27 Syntax for RRtype filtering 239
Administrator 28, 31, 32 Syntax for UDP and TCP 227
Changing 10 Running Configuration State 83
Compartmentalization 83 rx2660, see HP Integrity rx2660
Creator 28 rx2800, see HP Integrity rx2800
Enabling 10
Hierarchy 29 S
Installer 28, 30 S64-CACHE-MIB.txt 392
Listing 43 S64-CHASSIS-MIB.txt 392
Removing from user account 44 s64_example.conf 94, 483
503
Index
S64-MITIGATION-MIB.txt 392, 406 Using 17

Safe Mode 292 Serial Port Settings See comm command and show comm
save command 83, 85 command
Saved Configuration State 83 Server Dictionary File (RADIUS) 333
Saving the Cache 204 SERVFAIL
Schemas, LDAP 349 Bogus data (val-permissive-mode attribute) 128
scp command 23 Caching responses, see cache-servfail-ttl 105
SDP, See Sensitive Data Protection show authenticate config command 344, 360
sdu delete command 247 show authenticate status command 343, 359
sdu list command 246 show autostart status command 292
sdu protect command 245 show bfd info command 389
sdu replace command 247 show bfd status command 389
sdu reset command 248 show bgp FIB command 328
sdu reveal command 246 show bgp info command 321, 403
SDU See Sensitive Data Unit show bgp neighbor command 324
Second Hard Drive 291 show bgp RIB command 327
Secure Entry Point (SEP), see Trust Anchors show bgp status command 321, 402
Secure64 DNS Hardware show bgp summary command 326
Chassis MIB 392, 412 show bgp summary terse command 326
Polling interval 290 show bond# config command 287
Sensor information (show sensors) 370 show bond# status command 287
Secure64 DNS Name Server show cachedns config command 201
Configuring See Configuration File, DNS show cachedns info command 215
Interface(s), configuring 78 show cachedns reload status command 187
Powering down 87 show comm command 384
Rebooting 87 show config command 85, 366
Secure64 DNS Software show defense info command 386
About 1, 3 show disks command 369
Backing up 296 show fingerprint command 385
Recovery 299 show interfaces command 378
Restoring 296 show ip route command 382
Rolling back 302 show ipv6 addr command 383
Upgrading 300 show ipv6 command 383
Version See version command show ipv6 route command 382
SECURE64-PRODUCTS-MIB.txt 392 show ntp command 267
SECURE64-SMI.txt 392, 394 show ntp keys command 266
Security show pending command 85, 366
Advanced configuration 172 show roles command 34, 42
Attaching initial DoS, DDoS rules 79 show rtqm command 208, 210
Built-in 224 show saved command 85, 366
Caching 118 show sensors command 370
DNS hosting environment 249 show snmp config command 403
Overview of defenses and options 172 show snmp info command 403
Platform 224 show snmp status command 402
Recommendations 249 show syslog command 274, 365
Restricting Secure64 DNS console access 242 show syslog status command 273
RRtype rules 239 show users command 34, 43
TCP rules 236 Shutting Down the Server 88
UDP rules 234 SNMP
securityadmin role 31 About 391
securitycreate role 30 Autostart on boot 396
sendtrap command 411 Backing up and restoring 405
Sensitive Data Protection (SDP) Blacklist traps 407
About 244 Chassis traps 412
Backing up and restoring 248, 297 Commands 401
Sensitive Data Unit (SDU) Configuration 394, 403
And SDP 244 Configuration checklist 393
Commands (securityadmin role) 245 Example configuration 395
Creating and managing 245 Graylist traps 408
Rules and format 245 MIBs supported 392
SEP, see Trust Anchors Mitigation MIB 406
Serial Console Packet flood traps 409
Port location 61 Preparations 393
Timeout 283 Starting 402
504
Index
Status 402, 403 Statistics 386

Stopping 402 See also DDoS, DoS
SYN flood traps 410 sysadmin role 30, 82, 252
Testing 404, 411 syscreate role 30
Trap receiver/NMS 394 Syslog
Troubleshooting 405 Configuring 80, 269
snmpadmin role 31, 394, 401 Displaying contents of local 274, 365
snmpcreate role 30 Example output 365
snmpd.conf 394 Exporting local log file 274
SNMPv2-MIB.txt 392 Log level 270
Source IP Address Logfacility 271
Caching server outgoing interface 97 Messages 443
NTP 264, 265 Removing 272
Syslog 269 Routing 269
SourceT Micro OS Source IP address 269
About 2 Status information 273
Security 224 Testing with logmsg command 273
Spoofing Protection syslog command 269
DNS-0x20 forgery resistance 120 System Configuration 82
Out-of-zone RRsets 121 System Configuration Error
Randomization for security 119 Hardware threads enabled 478
SSH Platform Mismatch 478
Enabling and disabling SSH password 52 System Prompt See Nodename
Executing Secure64 DNS commands from 14 System States See Configuration
Incoming session rate 387
Limiting connections 236 T
Logging in 12 TCP
Pass phrase 50 Established sessions 387
Restricting access 242 Queries 98
Timeout 283 Rate limiting for security 227
User keys, creating 49 Rules See Rules
User keys, installing 50 SYN See SYN
User keys, removing 51 TCP MD5, BGP and 305, 317
sshpwdauth command 52 TCP SYN See SYN
start bfd command 389 TCP-MIB.txt 392
start cachedns command 184 TCPXFERLIM rule 80
start rtqm command 207 Telnet, disabling access to the iLO 77
start snmp command 402 Testing
Starting DNS 184 BGP 324
Statistics Caching server 189
Command line caching information (show cachedns info DNS name server 189
command) 215 SNMP See sendtrap command
Defense and mitigation (show defense info command) 386 Text Editor 89
Network (netstat command) 380 Text File, Displaying Contents 89
Overview of caching 215 Time
stop bfd command 389 Displaying or changing 261
stop cachedns command 184 Synchronizing, see NTP Server
stop rtqm command 208 Time Zone
stop snmp command 402 Configuring 260
Stopping DNS 184 List of top level 260
Strong Random Number Generator 119 Regions 260
Stub Resolver timeout command 283
Configuring with nameserver command 259 Time-to-Live (TTL)
Logging messages 469 Caches overview
Stub Zones 140 Maximum for answer bogus data (val-bogus-ttl attribute) 122
stub-addr attribute 141 Maximum for answer cache (cache-max-ttl attribute) 106
stub-host attribute 141 Maximum for infrastructure hosts (infra-host-ttl attribute) 107
stub-trust attribute 141 Maximum for lame delegation cache (infra-cache-ttl
stub-zone clause 140 attribute) 107
Symmetrical Routing 255 TPM, Recovery from failure 299
SYN Traversals
Flood detection 224 DNS query resolution limit 102
Incoming rate 387 Troubleshooting
SNMP SYN flood traps 410 BGP 328
505
Index
Caching server 192 Additional section filtering (val-clean-additional attribute) 123

LDAP 362 Behavior 128
Monitoring syslog 365 Bogus data SERVFAIL (val-permissive-mode attribute) 123
RADIUS 345 Bogus data TTL (val-bogus-ttl) 122
SNMP 405 Checking disabled (cd flag and dig) 189
System utility commands 366 NSEC3 iteration limits (val-nsec3-keysize-iterations
Trust Anchors attribute) 123
Configuration (standard) 130 NXDOMAIN redirection and 157
DLV configuration 134 Omit zones with trust anchors (harden-dnssec-stripped) 121
Example 130 Override RRSIG date (val-override-date attribute) 122
Managing 134 Overview 128
Negative (domain-insecure attribute) 130 Testing 190
Overview 128 Troubleshooting 192
trust-anchor attribute 130 val-nsec3-keysize-iterations attribute 123
trust-anchor-file attribute 130 val-override-date attribute 122
trusted-keys-file attribute 130 val-permissive-mode attribute 123
TTL, see Time-to-Live version attribute 119
tz command 260 version command 374
version.bind query (denying) 119
U version.server query (denying) 119
UDP VGA
Dropping 234, 257 Connection 3, 61
IP fragmentation and 256 Support 291
nullchecksums command 257 view mode 10
Rate limiting for security 227 view-name attribute 164
Rules 234 Views, DNS
UDP-MIB.txt 392 Caches and 168
UDPQUERYLIM rule 80 Checking with show cachedns info command 169
Unbound Configuration File 177 Examples 166
Update, Secure64 See Upgrade Location-based configurations 169
Upgrade Multiple resolver instances and 181
Reversing 302 Overview 163
Secure64 300 Rules and options 165
upgrade command 300 Virtual Interface 280
upgrade role 30 VLAN Interface 276
uptime command 375
use-caps-for-id attribute 120 W
User Account Warming the Cache 204
Assigning administrator role(s) 39 who command 384
Assigning creator role(s) 38, 69 Withdraw, BGP 322
Authorization 27
Creating 35
Creating initial 69
Deleting 44
Examples 55
Information 42
Installer 69
Listing 42
Logging messages 446
Profile 42
RADIUS/LDAP example 58
Resetting all 47
Rules 32
Viewing logged in See who command
userdisable command 34
userenable command 34
usermod command 34
Users See User Account
V
val-bogus-ttl attribute 122
val-clean-additional attribute 123
Validation
AD (Authenticated Data) 190
506

Secure64Cache v3.1 Admin Guide

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Secure64Cache v3.1 Admin Guide

Caricato da

Copyright:

Formati disponibili

SECURE64®

Copyright (c) 2007, NLnet Labs. All rights reserved.

Copyright 2009 Sun Microsystems, Inc. All rights reserved.

---- Part 9: ScienceLogic, LLC copyright notice (BSD) -----

Chapter 2. Getting Started .............................................................................................. 59

Configuring DNS Interface(s) ....................................................................................................... 78

Chapter 3. Configuring Secure64 DNS Cache ................................................................. 91

Chapter 4. Advanced Configuration Topics .................................................................. 127

Chapter 6. Secure Configuration .................................................................................. 223

Chapter 7. System Administration ................................................................................ 251

Overview ..................................................................................................................................... 251

Chapter 8. Enabling BGP for Anycast ........................................................................... 303

Chapter 10. Information and Diagnostics ..................................................................... 365

Secure64 Mitigation Trap Type Categories and Notifications ............................................................... 406

Secure64 DNS Cache Application Software

User Accounts, Roles, and RADIUS or LDAP Support

SNMP and Syslog for Monitoring and Reporting

BGP for Anycast

SourceT Micro Operating System

Additional components and connections used by Secure64 DNS Cache include:

What’s New in Version 3.1

Other Command Changes and Additions

— authenticate <radius | ldap>

New and Modified Configuration Attributes

• The new cache.conf configuration attribute drop-any: <yes|no> defines whether

• To accommodate blacklist file requirements for servers managed by Secure64 DNS

Table 1. Document conventions

Convention Example Description

Courier Bold Font File contents

Variable that you replace with the

About this Guide

About the Command-Line Interface

Using the CLI

Table 2. Secure64 DNS Cache CLI tasks

Task Additional Information

View Mode, Enabling Roles, and Exiting the System

Figure 1. Accessing view mode, enabling modes, and exiting

For example, to execute BGP administration commands, you can:

Accessing the CLI with SSH

Last login: Thu Oct 24 08:17:55 2013 from 192.168.95.2

admin1@server:~$ ssh user@192.168.127.1 sysadmin ifconfig eth3

Last login: Thu Oct 24 08:19:19 2013 from 192.168.95.2

Pending configuration changed.

admin1@server:~$ ssh user@192.168.127.1 sysadmin activate

Last login: Thu Oct 24 08:19:40 2013 from 192.168.95.2

Running configuration changed.

admin1@server:~$ ssh user@192.168.127.1 sysadmin save

Last login: Thu Oct 24 08:20:26 2013 from 192.168.95.2

Running configuration successfully saved.

Using the iLO MP Console

— At the MP Main Menu, type CO and press ENTER to select Console.

If you are using a web browser:

— Select Remote Console and select the Launch button.

Additional Information About the HP Integrity iLO MP

In addition to console capabilities discussed in Using the iLO MP Console on page 17,

Types of risks include:

LDAP and Active Directory Considerations

Virtual Serial Console Considerations

Removing and Creating Server/Client SSH Keys

[securityadmin@Secure64]# remove sshkeys

[securityadmin@Secure64]# show cachedns status

[securityadmin@Secure64]# show bgp status

[view@Secure64]> enable cachednsadmin

[cachednsadmin@Secure64]# stop cachedns