尝试用新的转发器替换所有转发器，但我似乎无法使模式匹配正常工作。我无论如何也找不到错误：
sudo sed -i .bak "s/forwarders {[^]]*}/forwarders { 127.0.0.1 }/g" /etc/named/named.conf
答案1
我会这样做。可能还有更多有创意的方法。
cat temp
forwarders { 8.8.8.8 };
sed -i i.bak -e 's/forwarders.*/forwarders { 127.0.0.1 };/g' temp
cat temp
forwarders { 127.0.0.1 };
答案2
named.conf如果您还使用编译指示策略性地放置您的设置include，那么更新文件就会容易得多。
option {
.
.
.
forwarders {
include “/var/lib/named/forwarders-named.conf”;
};
.
.
.
};
那么你的 bash 脚本就可以简单地执行
myip=“8.8.8.8”
echo “${myip};” > /var/lib/named/forwarders-named.conf
chmod a+r /var/lib/named/forwarders-named.conf
这include从 ISC Bind v8.0 开始就存在了，可以放在任何地方，named.conf甚至可以嵌套包含多达 16 次，尽管我自己做过 4 层深嵌套，但没有任何效果；我用来include分隔每个子句加上键、ACL、动态 IP 地址，
include这里是我的隐藏主人的工作示例named.conf：
// File: /etc/bind/public-named.conf
//
// Bind9 configuration for public-facing Internet
//
// Customized for testing purposes using relative directory
//
// This is the primary name server configuration file for the
// BIND DNS named daemon.
//
// 'include' statement must have an absolute filespec or it
// will read from current directory ($CWD) UNTIL it
// hits the 'directory' config inside 'options' clause.
// This means that include statement should not contain an
// 'options' clause until an options clause 'directory'
// gets encountered.
//
// A highly dynamic variable, this 'directory' option is.
//
// On Debian 9, that '$CWD' of named daemon is usually
// '/var/cache/bind' or wherever that 'bind' user
// $HOME directory as specified.
//
// Default (compilable-only) $CWD (for Debian OS) is:
// /var/cache/bind/public
// Please read /usr/share/doc/bind9/README.Debian.gz for
// information on the structure of BIND configuration
// files in Debian, *BEFORE* you customize this
// configuration file.
//
// If you are just adding zones, please do that
// inside /etc/bind/named.conf.local
// We can share the ACL amongst private/public zones because
// it is a consistent thing to do. There is no leakage
// of ACL characteristics unless persistent DNS probing
// gets used to map out such ACL.
//
// We cannot perform include statement within ACL clauses due
// to its need to prescreen all variable names.
// Bind9 Access Control List (ACL) configuration
//
// DNS xfer
// Allow no transfers. If we have other
// name servers, place them here.
acl xfer_acl {
none;
};
// Running two DNS servers on same host/gateway
// dynamically updated by /etc/dhcp/dhclient-enter-hooks.d/0-bind-update-ip
include "/var/lib/bind/public/named.conf.acl_intf_ext";
// List all secondary nameservers here:
// Dont forget to repeat those in 'masters' (masters-public.conf) option.
// Do not list any master (hidden or not) as downstream.
acl external_downstream_nameservers_acl {
x.x.x.x;
x.x.x.x;
};
acl localhost_direct_acl { 127.0.1.1; };
acl localnet_acl { 127.0.0.0/8; };
// support for cable network
acl trusted_cablesupport_acl {
192.168.8.0/24;
192.168.1.1/24;
};
# dmz
acl trusted_real_dmz_acl {
192.168.5.0/24;
};
# dmz2
acl trusted_residential_network_dmz_acl {
192.168.6.0/24;
};
# blue
acl trusted_residential_network_blue_acl {
192.168.6.0/24;
};
# special, single-host, GATEWAY
acl trusted_residential_gateway_acl {
192.168.6.1;
};
# green
acl trusted_residential_network_green_acl {
192.168.4.0/24;
};
# white
acl trusted_residential_network_white_acl {
192.168.5.0/24;
};
# vmnet
acl trusted_residential_network_vmnet_acl {
192.168.122.0/24;
};
acl trusted_residential_network_acl {
trusted_residential_network_blue_acl;
trusted_residential_network_green_acl;
trusted_residential_network_white_acl;
};
acl trusted_residential_network_all_acl {
trusted_residential_network_dmz_acl;
trusted_residential_network_blue_acl;
trusted_residential_network_green_acl;
trusted_residential_network_white_acl;
trusted_residential_network_vmnet_acl;
};
acl trusted_all {
trusted_real_dmz_acl;
trusted_residential_network_dmz_acl;
trusted_residential_network_blue_acl;
trusted_residential_network_green_acl;
trusted_residential_network_white_acl;
trusted_residential_network_vmnet_acl;
trusted_cablesupport_acl;
localnet_acl;
};
// We do not perform any include statement for options clause
// due to relative path support by 'directory' statement found
// within options clause.
//// Bind9 options clause
////
//// 'options' clause is a groups statements that control generic or
//// global behavior and that have scope for all zones and views
//// unless overridden within a zone, views or other clause.
//
// Customized for public network
//
// Many options below may be superceded inside and by
// subsequential options in other views and zones.
//
////
//// The options clause group together statements that have
//// global scope - the statemnts apply to all zones or views
//// unless overridden by the same statement in a view or zone
//// clause. Only one options clause should be defined in a
//// named.conf file. The options clause can take a serious
//// list of statements.
////
options {
version "DNS v1.1";
//// directory "path_name";
////
//// directory option is a quoted string defining the
//// absolute path for the server e.g. "/var/named".
//// All subsequent relative paths use this base directory.
//// If no directory options is specified the directory
//// from which BIND was loaded is used.
//// This option may only be specified in a 'global' options statement.
////
//// This directory option must contain absolute directory path
////
//// tell named daemon where to find files mentioned below
//// directory "/var/cache/bind/public";
// directory "."; // testing directory
//// bindkeys-file is OBSOLETED on Feb 2017.
//// key-directory is a quoted string defining the absolute path,
//// for example, "/var/named/keys" where the keys used in the
//// dynamic update of secure zones may be found. Only
//// required if this directory is different from that defined
//// by a directory option. This statement may only be used in
//// a global options clause.
////
//// other documentation says to use "/etc/bind/keys" but
//// bind9 named daemon is writing to that directory so
//// the /var subdirectory is better for temporary data
//// We use /var/cache/bind where journal files are also
//// if relative dirspec is given, then the directory option is
//// prepended to key-directory.
//// When performing dynamic update of secure zones, the
//// directory where the public and private DNSSEC key
//// files should be found, if different than the current
//// working directory. (Note that this option has no
//// effect on the paths for files containing non-DNSSEC
//// keys such as bind.keys, rndc.key or session.key.)
key-directory "/var/cache/bind/public";
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
managed-keys-directory "/var/lib/bind/public/dynamic";
//// dump-file path_name;
////
//// dump-file option is a quoted string defining the absolute
//// path where BIND dumps the database (cache) in response
//// to a rndc dumpdb.
//// If not specified, the default is named_dump.db in the
//// location specified by a directory option.
//// This option may only be specified in a 'global' options statement.
dump-file "/var/cache/bind/public/cache_dump.db";
// file that contains the process id when bind/named daemon is running
pid-file "/var/run/named/named-public.pid";
// enable statistics
statistics-file "/var/log/bind/public/named_stats.txt";
zone-statistics yes;
/////////////////////////////////////////////////////////////////
//// NETWORK INTERFACE(S)
/////////////////////////////////////////////////////////////////
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0s placeholder.
// on a multi-homed host, you might want to tell named
// to listen for queries only on certain interfaces
//
// Use a series of NOT-IPs to avoid the public IP address, which
// often are dynamically-ISP-assigned.
include "/var/lib/bind/public/interface-public";
listen-on port 53 {
!127.0.0.1; // localhost-generic
!127.0.1.1; // localhost-direct
!192.168.1.1; // cable-support
};
listen-on-v6 { none; };
// automatically rescan network interfaces
// when the interface addresses are added or removed. The default is yes
// Internal network are very stable, no need to be polling kernels here.
automatic-interface-scan yes;
// Internal network have no dynamic interfaces, so BIND
// should not need to poll for interface state {UP|DOWN}.
// Here, our eth1 is this dynamic interface
// interface-interval 120;
//// allow-query defines an match list of IP address(es) which are
//// allowed to issue queries to the server. If not specified all
//// hosts are allowed to make queries (defaults to allow-query {any;};).
////
//// allow-query-on defines the server interface(s) from which
//// queries are accepted and can be useful where a server
//// is multi-homed, perhaps in conjunction with a view clause.
//// Defaults to allow-query-on {any;};) meaning that queries
//// are accepted on any server interface.
////
//// allow-query statements may be used in a zone, view or
//// a global options clause.
// to allow only specific hosts to use the DNS server:
//// Some views/zones may restrict or expand on this
allow-query { any; };
// TODO: Open it up a bit
allow-query-on {
external_bastion_ip_acl; // that public DNS server
external_downstream_nameservers_acl;
};
//// all public-facing interface should not support recursion
//// we limit that to localhost
recursion no;
/////////////////////////////////////////////////////////////////
//// Zone Transfers
/////////////////////////////////////////////////////////////////
server-id none; // Ignore EDNS0/NSID
// Generate more efficient zone transfers. This will place
// multiple DNS records in a DNS message, instead of one per
// DNS message.
transfer-format many-answers;
// GATEWAY.LAB comments this forwarders out so that SERVFAIL results
// forwarders {
// 0.0.0.0;
// };
///////////////////////////////////////////////////////
//// Sending DNS records to other DNS servers
///////////////////////////////////////////////////////
//// Sending DNS records to slave servers from here
// do not generate notify messages for all zones on a restart.
// override for authorative zones
//
// Instead, use notify option within each zone (or view) sections.
//
// Prevent DoS attacks by generating bogus zone transfer
// requests. This will result in slower updates to the
// slave servers (e.g. they will await the poll interval
// before checking for updates).
// notify behaviour is applicable to both master zones
// (with 'type master;') and slave zones (with 'type slave;')
// and if set to 'yes' (the default) then, when a zone is
// loaded or changed, for example, after a zone transfer,
// NOTIFY messages are sent to the name servers defined in
// the NS records for the zone (except itself and the
// 'Primary Master' name server defined in the SOA record)
// and to any IPs listed in any also-notify statement.
//
// * If set to 'no' NOTIFY messages are not sent.
// * If set to 'explicit' NOTIFY is only sent to those IP(s)
// listed in an also-notify statement.
// If a global notify statement is 'no' an also-notify
// statement may be used to override it for a specific zone,
// and conversely if the global options contain an
// also-notify list, setting notify 'no' in the zone will
// override the global option.
//
// This statement may be specified in zone, view clauses or
// in a global options clause.
notify no;
// Set the maximum zone transfer time to something more
// reasonable. In this case, we state that any zone transfer
// that takes longer than 60 minutes is unlikely to ever
// complete. WARNING: If you have very large zone files,
// adjust this to fit your requirements.
max-transfer-time-in 60;
// sets BIND’s default behaviour to refuse all zone transfers.
// Without setting this option, anyone can AXFR transfer any zone.
// Zone tranfers limited to members of the
// "xfer_acl" ACL.
//// allow-transfer option is the ACL of who this daemon
//// can send DNS records to.
////
//// allow-transfer defines a match list e.g. IP address(es)
//// that are allowed to transfer (copy) the zone information
//// from the server (master or slave for the zone).
//// The default behaviour is to allow zone transfers to any host.
//// While on its face this may seem an excessively friendly
//// default, DNS data is essentially public (that is why its
//// there) and the bad guys can get all of it anyway.
//// However if the thought of anyone being able to transfer
//// your precious zone file is repugnant, or (and this is
//// far more significant) you are concerned about possible
//// DoS attack initiated by XFER requests,
//// then use the following policy:
////
//// options {
//// ....
//// // ban everyone by default
//// allow-transfer {"none";};
//// };
//// ...
//// zone "example.com" in{
//// ....
//// // explicity allow the slave(s) in each zone
//// allow-transfer {192.168.0.3;};
//// };
////
//// This statement may be used in a zone, view or global options clause.
////
// we force ourselves to establish allow-transfer in each view/zone
allow-transfer { none; };
// force us to declare a specific allow-update within each view/zone
allow-update {
none;
};
//// Since BIND 9.4 allow-query-cache (or its default) controls
//// access to the cache and thus effectively determines
//// recursive behavior. This was done to limit the number of,
//// possibly inadvertant, OPEN DNS resolvers.
//// allow-query-cache defines an address_match_list of IP
//// address(es) which are allowed to issue queries that access
//// the local cache - without access to the local cache
//// recursive queries are effectively useless so, in effect,
//// this statement (or its default) controls recursive
//// behavior.
//// Its default setting depends on:
////
//// If recursion no; present, defaults to
//// allow-query-cache {none;};.
//// No local cache access permitted.
////
//// If recursion yes; (default) then, if allow-recursion
//// present, defaults to the value of allow-recursion.
//// Local cache access permitted to the same
//// address_match_list as allow-recursion.
////
//// If recursion yes; (default) then, if allow-recursion is NOT
//// present, defaults to
//// allow-query-cache {localnets; localhost;};.
//// Local cache access permitted to localnets and localhost only.
////
//// Both allow-query-cache and allow-recursion statements are
//// allowed - this is a recipe for conflicts and a debuggers
//// dream come true. Use either statement consistently - by
//// preference allow-recursion.
////
//// allow-query-cache-on defines the server interface(s) from
//// which queries that access the local cache are accepted and
//// can be useful where a server is multi-homed, perhaps in
//// conjunction with a view clause.
//// Defaults to allow-query-cache-on {any;};) meaning that
//// queries that access the local cache are accepted on any
//// server interface.
////
//// These statements may be used in a view or a global options clause.
allow-query-cache {
external_bastion_ip_acl;
trusted_residential_network_all_acl;
};
///////////////////////////////////////////////////////
//// DNS Security (DNSSEC)
///////////////////////////////////////////////////////
//// dnssec-enable ( yes | no );
////
//// dnssec-enable indicates that a secure DNS service is being
//// used which may be one, or more, of TSIG (for securing zone
//// transfers or DDNS updates), SIG(0) (for securing DDNS
//// updates) or DNSSEC.
//// Since BIND9.5 the default value is dnssec-enable yes;.
//// This statement may be used in a view or global options clause.
dnssec-enable yes;
dnssec-accept-expired yes;
////
//// Enable DNSSEC validation in named. Note dnssec-enable also
//// needs to be set to yes to be effective.
//// If set to no, DNSSEC validation is disabled.
////
//// If set to auto , DNSSEC validation is enabled, and a default
//// trust-anchor for the DNS root zone is used.
////
//// If set to yes, DNSSEC validation is enabled, but a trust
//// anchor must be manually configured using a trusted-keys
//// or managed-keys statement.
////
//// The dnssec-validation default is yes.
////
//// dnssec-validation indicates that a resolver (a caching or
//// caching-only name server) will attempt to integrity_check replies
//// from DNSSEC enabled (signed) zones.
//// To perform this task the server also needs either a valid
//// trusted-keys clause (containing one or more
//// trusted-anchors or a managed-keys clause.
//// Since 9.5 the default value is dnssec-validation yes;.
//// This statement may be used in a view or global options clause.
////
//// NOTE: Whenever the resolver sends out queries to an
//// EDNS-compliant server, it always sets the DO bit
//// indicating it can support DNSSEC responses even
//// if dnssec-validation is off.
dnssec-validation yes;
// conform to RFC1035
auth-nxdomain no;
//// session is only used for DHCP running on this machine
//// DHCP is not needed on slave-type DNS servers.
//// and only when 'update-policy local' is used.
////
//// XXX: 'session-key*' is practically useless if you
//// do not use 'update-policy local'.
//// Since you are only allowed one 'update-policy' option,
//// using 'local' robs you of further filtering capability.
session-keyfile "/var/run/bind/public/session.key";
session-keyalg "hmac-sha256";
session-keyname "local-ddns";
// CIS says do not use 'query-source'
// RNDC ACL
allow-new-zones no;
//// notify-to-soa [no|yes]; // default is no.
//// If yes do not check the nameservers in the NS RRset against
//// the SOA MNAME.
//// Normally a NOTIFY message is not sent to the SOA
//// MNAME (SOA ORIGIN) as it is supposed to contain the
//// name of the ultimate master. Sometimes, however, a
//// slave is listed as the SOA MNAME in hidden master
//// configurations and in that case you would want the
//// ultimate master to still send NOTIFY messages to all
//// the nameservers listed in the NS RRset.
// is this NS a Hidden-master? Still send to MNAME in SOA
notify-to-soa
no;
};
include "/etc/bind/public/statistics-named.conf";
include "/etc/bind/public/channels-named.conf";
include "/etc/bind/public/masters-named.conf";
include "/etc/bind/public/local-named.conf";
// include "/etc/bind/public/default_zones-named.conf";
include "/etc/bind/public/keys/keys-named.conf";
include "/etc/bind/public/controls-named.conf";
include "/etc/bind/public/servers-named.conf";
include "/etc/bind/public/trusted-keys-named.conf";