Red Hat Summit Red Hat SummitApoyoConsolaDesarrolladoresIniciar una pruebaContacto

Este contenido no está disponible en el idioma seleccionado.

Chapter 2. Configuring zones on a BIND DNS server

To manage domain name resolution (DNS) for the example.com domain, configure a zone on a DNS BIND server. A DNS zone is a database with resource records for a specific sub-tree in the domain space. Therefore, clients can resolve www.example.com to the IP address configured in the zone.

2.1. The start of authority record in zone files
Copiar enlace

To manage several DNS servers authoritative for a zone and DNS resolvers, you can use the start of authority (SOA) record. This record is essential in a DNS zone.

A SOA record in BIND has the following syntax: 

name class type mname rname serial refresh retry expire minimum
Copy to Clipboard Toggle word wrap

For better readability, you need to split the record in zone files into several lines with comments that start with a semicolon (;). Note that, if you split a SOA record, parentheses keep the record together: 

@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL
Copy to Clipboard Toggle word wrap
Important

Note the trailing dot at the end of the fully-qualified domain name (FQDN). FQDN consists of several domain labels, separated by dots. Because the DNS root has an empty label, FQDN ends with a dot. Therefore, BIND appends the zone name to the names without a trailing dot.

A hostname without a trailing dot, for example, ns1.example.com expands to ns1.example.com.example.com., which is not the correct address of the primary name server.

These are the fields in a SOA record:

  • name: The name of the zone, the so-called origin. If you set this field to @, BIND expands it to the zone name defined in /etc/named.conf.
  • class: In SOA records, you must set this field always to Internet (IN).
  • type: In SOA records, you must set this field always to SOA.
  • mname (master name): The hostname of the primary name server of this zone.
  • rname (responsible name): The email address of who is responsible for this zone. Note that the format is different. You must replace the at sign (@) with a dot (.).

  • serial: The version number of this zone file. Secondary name servers only update their copies of the zone if the serial number on the primary server is higher.

    The format can be any numeric value. A commonly-used format is <year><month><day><two_digit_number>. With this format, you can, theoretically, change the zone file up to a hundred times per day.

  • refresh: The amount of time secondary servers should wait before checking the primary server if the zone update is successful.
  • retry: The amount of time after which a secondary server retries to query the primary server if the zone update is unsuccessful.
  • expire: The amount of time after which a secondary server stops querying the primary server, if all earlier attempts failed.
  • minimum: RFC 2308 changed the meaning of this field to the negative caching time. Compliant resolvers use it to decide how long to cache NXDOMAIN name errors.
Note

A numeric value in the refresh, retry, expire, and minimum fields define a time in seconds. However, for better readability, use time suffixes, such as m for minute, h for hours, and d for days. For example, 3h stands for 3 hours.

2.2. Setting up a forward zone on a BIND primary server
Copiar enlace

To enable mapping domain names to IP addresses and other information, set up a forward zone on a BIND primary server. For example, if you are responsible for the example.com domain, you can set up a forward zone in BIND to resolve names, such as www.example.com.

Prerequisites

  • You have installed the bind package on the server.
  • You have configured the server to run as a caching name server.
  • The named or named-chroot service is running.

Procedure

  1. Add a zone definition to the /etc/named.conf file: 

    zone "example.com" {
    type master;
    file "example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
};
    Copy to Clipboard Toggle word wrap

    These settings define:

    • This server is the primary server (type master) for the example.com zone.
    • The /var/named/example.com.zone file is the zone file. If you set a relative path, as in this example, this path is relative to the directory you set in directory in the options statement.
    • Any host can query this zone. However, you can specify IP ranges or BIND access control list (ACL) nicknames to limit the access.
    • No host can transfer the zone. Allow zone transfers only when you set up secondary servers and only for the IP addresses of the secondary servers.

  2. Verify the syntax of the /etc/named.conf file: 

    # named-checkconf
    Copy to Clipboard Toggle word wrap

    If the command displays no output, the syntax is correct.

  3. Create the /var/named/example.com.zone file, for example, with the following content: 

    $TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.
                  IN MX   10 mail.example.com.

www               IN A    192.0.2.30
www               IN AAAA 2001:db8:1::30
ns1               IN A    192.0.2.1
ns1               IN AAAA 2001:db8:1::1
mail              IN A    192.0.2.20
mail              IN AAAA 2001:db8:1::20
    Copy to Clipboard Toggle word wrap

    This zone file:

    • Sets the default time-to-live (TTL) value for resource records to 8 hours. Without a time suffix, such as h for hour, BIND interprets the value as seconds.
    • Has the required Start of Authority (SOA) resource record with details about the zone.
    • Sets ns1.example.com as an authoritative DNS server for this zone. To be functional, a zone requires at least one name server (NS) record. However, to be compliant with RFC 1912, you require at least two name servers.
    • Sets mail.example.com as the mail exchanger (MX) of the example.com domain. The numeric value in front of the hostname is the priority of the record. Entries with a lower value have a higher priority.
    • Sets the IPv4 and IPv6 addresses of www.example.com, mail.example.com, and ns1.example.com.

  4. Set secure permissions on the zone file that allow only the named group to read it: 

    # chown root:named /var/named/example.com.zone
# chmod 640 /var/named/example.com.zone
    Copy to Clipboard Toggle word wrap

  5. Verify the syntax of the /var/named/example.com.zone file: 

    # named-checkzone example.com /var/named/example.com.zone
zone example.com/IN: loaded serial 2022070601
OK
    Copy to Clipboard Toggle word wrap

  6. Reload BIND: 

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

    If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

Verification

  • Query different records from the example.com zone, and verify that the output matches the records you have configured in the zone file: 

    # dig +short @localhost AAAA www.example.com
    Copy to Clipboard Toggle word wrap 
    2001:db8:1::30
    Copy to Clipboard Toggle word wrap 
    # dig +short @localhost NS example.com
    Copy to Clipboard Toggle word wrap 
    ns1.example.com
    Copy to Clipboard Toggle word wrap 
    # dig +short @localhost A ns1.example.com
    Copy to Clipboard Toggle word wrap 
    192.0.2.1
    Copy to Clipboard Toggle word wrap

    This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2.3. Setting up a reverse zone on a BIND primary server
Copiar enlace

To map IP addresses to names, you can set up a reverse zone on a BIND primary server. For example, if you have the 192.0.2.0/24 IP range, you can set up a reverse zone in BIND to resolve IP addresses from this range to hostnames.

Note

If you create a reverse zone for classful IP addresses for a specific network, name the zone likewise. For example, for the class C network 192.0.2.0/24, the name of the zone is 2.0.192.in-addr.arpa. If you want to create a reverse zone for a different network size, for example 192.0.2.0/28, the name of the zone is 28-2.0.192.in-addr.arpa.

Prerequisites

  • You have configured BIND as a caching name server.
  • The named or named-chroot service is running.
  • You have administrative privileges.

Procedure

  1. Add a zone definition to the /etc/named.conf file: 

    zone "2.0.192.in-addr.arpa" {
    type master;
    file "2.0.192.in-addr.arpa.zone";
    allow-query { any; };
    allow-transfer { none; };
};
    Copy to Clipboard Toggle word wrap

    These settings define:

    • This server is the primary server (type master) for the 2.0.192.in-addr.arpa reverse zone.
    • The /var/named/2.0.192.in-addr.arpa.zone file is the zone file. If you set a relative path, as in this example, this path is relative to the directory you set in directory in the options statement.
    • Any host can query this zone. However, you can specify IP ranges or BIND access control list (ACL) nicknames to limit the access.
    • No host can transfer the zone. Allow zone transfers only when you set up secondary servers and only for the IP addresses of the secondary servers.

  2. Verify the syntax of the /etc/named.conf file: 

    # named-checkconf
    Copy to Clipboard Toggle word wrap

    If the command displays no output, the syntax is correct.

  3. Create the /var/named/2.0.192.in-addr.arpa.zone file, for example, with the following content: 

    $TTL 8h
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1d         ; refresh period
                          3h         ; retry period
                          3d         ; expire time
                          3h )       ; minimum TTL

                  IN NS   ns1.example.com.

1                 IN PTR  ns1.example.com.
30                IN PTR  www.example.com.
    Copy to Clipboard Toggle word wrap

    This zone file:

    • Sets the default time-to-live (TTL) value for resource records to 8 hours. Without a time suffix, such as h for hour, BIND interprets the value as seconds.
    • Has the required Start of Authority (SOA) resource record with details about the zone.
    • Sets ns1.example.com as an authoritative DNS server for this reverse zone. To be functional, a zone requires at least one name server (NS) record. However, to be compliant with RFC 1912, you require at least two name servers.
    • Sets the pointer (PTR) record for the 192.0.2.1 and 192.0.2.30 addresses.

  4. Set secure permissions on the zone file that only allow the named group to read it: 

    # chown root:named /var/named/2.0.192.in-addr.arpa.zone
# chmod 640 /var/named/2.0.192.in-addr.arpa.zone
    Copy to Clipboard Toggle word wrap

  5. Verify the syntax of the /var/named/2.0.192.in-addr.arpa.zone file: 

    # named-checkzone 2.0.192.in-addr.arpa /var/named/2.0.192.in-addr.arpa.zone
    Copy to Clipboard Toggle word wrap 
    zone __2.0.192.in-addr.arpa/IN__: loaded serial __2022070601__
OK
    Copy to Clipboard Toggle word wrap

  6. Reload BIND: 

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

    If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

Verification

  • Query different records from the reverse zone, and verify that the output matches the records you have configured in the zone file: 

    # dig +short @localhost -x 192.0.2.1
    Copy to Clipboard Toggle word wrap 
    ns1.example.com
    Copy to Clipboard Toggle word wrap 
    # dig +short @localhost -x 192.0.2.30
    Copy to Clipboard Toggle word wrap 
    www.example.com
    Copy to Clipboard Toggle word wrap

    This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

2.4. Updating a BIND zone file
Copiar enlace

To update several DNS servers authoritative for a zone, update a zone file only on the primary server. For example, if you change the IP address of a server, you need to update the zone file. Other DNS servers that store a copy of the zone receive the update through a zone transfer.

Prerequisites

  • You have configured a zone.
  • You have started the named or named-chroot service.
  • You have administrative privileges.

Procedure

  1. Optional: Identify the path to the zone file in the /etc/named.conf file: 

    options {
    ...
    directory       "/var/named";
}

zone "example.com" {
    ...
    file "example.com.zone";
};
    Copy to Clipboard Toggle word wrap

    You find the path to the zone file in the file statement in the zone’s definition. A relative path is relative to the directory set in directory in the options statement.

  2. Edit the zone file:

    1. Make the required changes.

    2. Increment the serial number in the start of authority (SOA) record.

      Important

      If the serial number is equal to or lower than the former value, secondary servers will not update their copy of the zone.

  3. Verify the syntax of the zone file: 

    # named-checkzone example.com /var/named/example.com.zone
    Copy to Clipboard Toggle word wrap 
    zone __example.com/IN__: loaded serial __2022062802__
OK
    Copy to Clipboard Toggle word wrap

  4. Reload BIND: 

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

    If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

Verification

  • Query the record you have added, modified, or removed, for example: 

    # dig +short @localhost A ns2.example.com
    Copy to Clipboard Toggle word wrap 
    192.0.2.2
    Copy to Clipboard Toggle word wrap

    This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

To ensure authenticity of zone information for clients, you can sign zones with Domain Name System Security Extensions (DNSSEC). Signed zones contain additional resource records.

Important

For enabling external DNS servers to verify the authenticity of a zone, add the public key of the zone to the parent zone. Contact your domain provider or registry for further details.

After enabling the DNSSEC policy feature for a zone, BIND automatically performs actions. It includes creating the keys, signing the zone, and maintaining the zone, including re-signing and periodically replacing the keys. In BIND, you can use the built-in default DNSSEC policy, which uses single ECDSAP256SHA key signatures. However, create your own policy to use custom keys, algorithms, and timings.

Prerequisites

  • You have installed the bind package on the server.
  • You have configured the zone for which you want to enable DNSSEC.
  • The named or named-chroot service is running.
  • You have configured the server to synchronize the time with a time server. Always check for the correct system time before enabling DNSSEC validation.

Procedure

  1. Add the dnssec-policy default; and inline-signing yes; in the /etc/named.conf file to enable DNSSEC for the zone: 

    zone "example.com" {
    ...
    dnssec-policy default;
    inline-signing yes;
};
    Copy to Clipboard Toggle word wrap

  2. Reload BIND: 

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

    If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

  3. BIND stores the public key in the /var/named/K<zone_name>.+<algorithm>+<key_ID>.key file. Use this file to display the public key of the zone in the format that the parent zone requires:

    • DS record format: 

      # dnssec-dsfromkey /var/named/Kexample.com.+013+61141.key
      Copy to Clipboard Toggle word wrap 
      example.com. IN DS 61141 13 2 3E184188CF6D2521EDFDC3F07CFEE8D0195AACBD85E68BAE0620F638B4B1B027
      Copy to Clipboard Toggle word wrap

    • DNSKEY format: 

      # grep DNSKEY /var/named/Kexample.com.+013+61141.key
      Copy to Clipboard Toggle word wrap 
      example.com. 3600 IN DNSKEY 257 3 13 sjzT3jNEp120aSO4mPEHHSkReHUf7AABNnT8hNRTzD5cKMQSjDJin2I3 5CaKVcWO1pm+HltxUEt+X9dfp8OZkg==
      Copy to Clipboard Toggle word wrap
  4. Request to add the public key of the zone to the parent zone. Contact your domain provider or registry for further details on how to do this.

Verification

  1. Query your own DNS server for a record from the zone for which you enabled DNSSEC signing: 

    # dig +dnssec +short @localhost A www.example.com
    Copy to Clipboard Toggle word wrap 
    192.0.2.30
A 13 3 28800 20220718081258 20220705120353 61141 example.com. e7Cfh6GuOBMAWsgsHSVTPh+JJSOI/Y6zctzIuqIU1JqEgOOAfL/Qz474 M0sgi54m1Kmnr2ANBKJN9uvOs5eXYw==
    Copy to Clipboard Toggle word wrap

    This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

  2. After the server adds the public key to the parent zone and propagates it to other servers, verify that the server sets the authenticated data (ad) flag on queries to the signed zone: 

    # dig @localhost example.com +dnssec
    Copy to Clipboard Toggle word wrap 
    ...
;; flags: qr rd ra **ad**; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
...
    Copy to Clipboard Toggle word wrap

2.6. Configuring zone transfers among BIND DNS servers
Copiar enlace

To ensure that all DNS servers that have a copy of the zone to have up-to-date data, configure zone transfers among BIND DNS servers.

Prerequisites

  • You have the administrative privileges.
  • On the future primary server, the zone for which you want to set up zone transfers is already configured.
  • On the future secondary server, BIND is already configured as a caching name server.
  • On both servers, the named or named-chroot service is running.

Procedure

  1. On the existing primary server:

    1. Generate a shared key and append it to the /etc/named.conf file: 

      # tsig-keygen example-transfer-key | tee -a /etc/named.conf
      Copy to Clipboard Toggle word wrap 
      key "__example-transfer-key__" {
        algorithm hmac-sha256;
        secret "__q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=__";
};
      Copy to Clipboard Toggle word wrap

      Output appends to the /etc/named.conf file.

      You will require this output later on the secondary server as well.

    2. In the allow-transfer statement, configure the zone in the /etc/named.conf file to require the key for transfers: 

      zone "example.com" {
    ...
    allow-transfer { key example-transfer-key; };
};
      Copy to Clipboard Toggle word wrap

      Define that servers must have the key specified in the example-transfer-key statement to transfer a zone. However, you can use BIND access control list (ACL) nicknames in the allow-transfer statement.

    3. Configure the zone to display the secondary server IP addresses: 

      zone "example.com" {
    ...
    also-notify { 192.0.2.2; 2001:db8:1::2; };
};
      Copy to Clipboard Toggle word wrap

      By default, after updating a zone, BIND notifies all name servers that have a name server (NS) record in this zone. If you do not plan to add an NS record for the secondary server to the zone, you can configure that BIND notifies this server anyway. For that, add the also-notify statement with the IP addresses of this secondary server to the zone:

    4. Verify the syntax of the /etc/named.conf file: 

      # named-checkconf
      Copy to Clipboard Toggle word wrap

      If the command displays no output, the syntax is correct.

    5. Reload BIND: 

      # systemctl reload named
      Copy to Clipboard Toggle word wrap

      If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

  2. On the future secondary server:

    1. Add the shared key block to /etc/named.conf (same as the primary server): 

      key "example-transfer-key" {
        algorithm hmac-sha256;
        secret "q7ANbnyliDMuvWgnKOxMLi313JGcTZB5ydMW5CyUGXQ=";
};
      Copy to Clipboard Toggle word wrap

      1. Add the secondary zone definition to the /etc/named.conf file: 

        zone "example.com" {
    type slave;
    file "slaves/example.com.zone";
    allow-query { any; };
    allow-transfer { none; };
    masters {
      192.0.2.1 key example-transfer-key;
      2001:db8:1::1 key example-transfer-key;
    };
};
        Copy to Clipboard Toggle word wrap
        • This server is a secondary server (type slave) for the example.com zone.
        • The /var/named/slaves/example.com.zone file is the zone file. If you set a relative path, as in this example, this path is relative to the directory you set in directory in the options statement. To separate zone files for which this server is secondary from primary ones, you can store them, for example, in the /var/named/slaves/ directory.
        • Any host can query this zone. However, you can specify IP ranges or ACL nicknames to limit the access.
        • No host can transfer the zone from this server.
        • The IP addresses of the primary server of this zone are 192.0.2.1 and 2001:db8:1::2. However, you can specify ACL nicknames. This secondary server will use the key named example-transfer-key to authenticate to the primary server.

    2. Verify the syntax of the /etc/named.conf file: 

      # named-checkconf
      Copy to Clipboard Toggle word wrap

    3. Reload BIND: 

      # systemctl reload named
      Copy to Clipboard Toggle word wrap

      If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

  3. Optional: Add an NS record for the new secondary server to the zone file on the primary server.

Verification

  • On the secondary server:

    • Display the systemd journal entries of the named service: 

      # journalctl -u named
      Copy to Clipboard Toggle word wrap 
      ...
Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: Transfer started.
Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: connected using 192.0.2.2#45803
Jul 06 15:08:51 ns2.example.com named[2024]: zone example.com/IN: transferred serial 2022070101
Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer status: success
Jul 06 15:08:51 ns2.example.com named[2024]: transfer of 'example.com/IN' from 192.0.2.1#53: Transfer completed: 1 messages, 29 records, 2002 bytes, 0.003 secs (667333 bytes/sec)
      Copy to Clipboard Toggle word wrap

      If you run BIND in a change-root environment, use the journalctl -u named-chroot command to display the journal entries.

    • Verify that BIND created the zone file: 

      # ls -l /var/named/slaves/
      Copy to Clipboard Toggle word wrap 
      total 4
-rw-r--r--. 1 named named 2736 Jul  6 15:08 example.com.zone
      Copy to Clipboard Toggle word wrap

      Note that, by default, secondary servers store zone files in a binary raw format.

    • Query a record of the transferred zone from the secondary server: 

      # dig +short @192.0.2.2 AAAA www.example.com
      Copy to Clipboard Toggle word wrap 
      2001:db8:1::30
      Copy to Clipboard Toggle word wrap

      This example assumes that the secondary server you set up in this procedure listens on IP address 192.0.2.2.

To rewrite a DNS response to block access to certain domains or hosts by using DNS blocking and filtering, configure response policy zones (RPZ) in BIND. You can configure different actions for blocked entries, such as returning an NXDOMAIN error or not responding to the query.

If you have several DNS servers, configure the RPZ on the primary server, and later configure zone transfers to make the RPZ available on the secondary servers.

Prerequisites

  • You have configured BIND as a caching name server.
  • The named or named-chroot service is running.
  • You have administrative privileges.

Procedure

  1. Edit the /etc/named.conf file to add a response-policy definition to the options statement: 

    options {
    ...

    response-policy {
        zone "rpz.local";
    };

    ...
}
    Copy to Clipboard Toggle word wrap

    You can set a custom name for the RPZ in the zone statement in response-policy. However, you must use the same name in the zone definition in the next step.

  2. Add a zone definition for the RPZ you set in the last step: 

    zone "rpz.local" {
    type master;
    file "rpz.local";
    allow-query { localhost; 192.0.2.0/24; 2001:db8:1::/64; };
    allow-transfer { none; };
};
    Copy to Clipboard Toggle word wrap
    • This server is the primary server (type master) for the RPZ named rpz.local.
    • The /var/named/rpz.local file is the zone file. In this example, if you set a relative path, this path is relative to the directory you set in directory in the options statement.
    • Any hosts defined in allow-query can query this RPZ. However, specify IP ranges or BIND access control list (ACL) nicknames to limit the access.
    • No host can transfer the zone. Allow zone transfers only when you set up secondary servers and only for the IP addresses of the secondary servers.

  3. Verify the syntax of the /etc/named.conf file: 

    # named-checkconf
    Copy to Clipboard Toggle word wrap

    If the command displays no output, the syntax is correct.

  4. Create the /var/named/rpz.local file with the following content: 

    $TTL 10m
@ IN SOA ns1.example.com. hostmaster.example.com. (
                          2022070601 ; serial number
                          1h         ; refresh period
                          1m         ; retry period
                          3d         ; expire time
                          1m )       ; minimum TTL

                 IN NS    ns1.example.com.

example.org      IN CNAME .
pass:[].example.org IN CNAME .example.net IN CNAME rpz-drop.pass:[].example.net    IN CNAME rpz-drop.
    Copy to Clipboard Toggle word wrap

    This zone file:

    • Sets the default time-to-live (TTL) value for resource records to 10 minutes. Without a time suffix, such as h for hour, BIND interprets the value as seconds.
    • Has the required start of authority (SOA) resource record with details about the zone.
    • Sets ns1.example.com as an authoritative DNS server for this zone. To be functional, a zone requires at least one name server (NS) record. However, to be compliant with RFC 1912, you require at least two name servers.
    • Return an NXDOMAIN error for queries to example.org and hosts in this domain.
    • Drop queries to example.net and hosts in this domain.

  5. Verify the syntax of the /var/named/rpz.local file: 

    # named-checkzone rpz.local /var/named/rpz.local
    Copy to Clipboard Toggle word wrap 
    zone __rpz.local/IN__: loaded serial __2022070601__
OK
    Copy to Clipboard Toggle word wrap

  6. Reload BIND: 

    # systemctl reload named
    Copy to Clipboard Toggle word wrap

    If you run BIND in a change-root environment, use the systemctl reload named-chroot command to reload the service.

Verification

  1. Try to resolve a host in the example.org domain that the RPZ is configured to return an NXDOMAIN error: 

    # dig @localhost www.example.org
    Copy to Clipboard Toggle word wrap 
    ...
;; ->>HEADER<<- opcode: QUERY, status: **NXDOMAIN**, id: 30286
...
    Copy to Clipboard Toggle word wrap

    This example assumes that BIND runs on the same host and responds to queries on the localhost interface.

  2. Try to resolve a host in the example.net domain that the RPZ is configured to drop queries: 

    # dig @localhost www.example.net
    Copy to Clipboard Toggle word wrap 
    ...
;; connection timed out; no servers could be reached
...
    Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2026 Red HatVolver arriba