Trying to use sed to edit named.conf and add some DNS forwarders but can't?

This is how I would do it. There are probably more creative ways.

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 };

It is far, far much easier to update the named.conf file if you also place strategically your settings using the include pragma.

option {
.
.
.
   forwarders {

include “/var/lib/named/forwarders-named.conf”;

       };
.
.
.
};

then your bash script can simply do

myip=“8.8.8.8”
echo “${myip};” > /var/lib/named/forwarders-named.conf
chmod a+r /var/lib/named/forwarders-named.conf

This include has been around since ISC Bind v8.0 and can be placed anywhere within the named.conf and can even be include-nested up to 16 times, although I have done 4-deep include nesting myself without any effect; i use include to separate each clause plus keys, ACL, dynamic IP address,

a working example of include with my hidden-master’s named.conf here:

// 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";