requires at most two resolver lookups, one reverse and one forward.
        If there is a resolver problem with some address, it becomes only
        that client's problem.  A hypothetical alternative
        implementation that only did forward lookups would have to
        resolve every host name mentioned in
        <filename>pg_hba.conf</filename> during every connection attempt.
        That could be quite slow if many names are listed.
        And if there is a resolver problem with one of the host names,
        it becomes everyone's problem.
       </para>

       <para>
        Also, a reverse lookup is necessary to implement the suffix
        matching feature, because the actual client host name needs to
        be known in order to match it against the pattern.
       </para>

       <para>
        Note that this behavior is consistent with other popular
        implementations of host name-based access control, such as the
        Apache HTTP Server and TCP Wrappers.
       </para>
      </note>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>IP-address</replaceable></term>
     <term><replaceable>IP-mask</replaceable></term>
     <listitem>
      <para>
       These two fields can be used as an alternative to the
       <replaceable>IP-address</replaceable><literal>/</literal><replaceable>mask-length</replaceable>
       notation.  Instead of
       specifying the mask length, the actual mask is specified in a
       separate column. For example, <literal>255.0.0.0</literal> represents an IPv4
       CIDR mask length of 8, and <literal>255.255.255.255</literal> represents a
       CIDR mask length of 32.
      </para>

      <para>
       These fields do not apply to <literal>local</literal> records.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><replaceable>auth-method</replaceable></term>
     <listitem>
      <para>
       Specifies the authentication method to use when a connection matches
       this record. The possible choices are summarized here; details
       are in <xref linkend="auth-methods"/>.  All the options
       are lower case and treated case sensitively, so even acronyms like
       <literal>ldap</literal> must be specified as lower case.

       <variablelist>
        <varlistentry>
         <term><literal>trust</literal></term>
         <listitem>
         <para>
          Allow the connection unconditionally. This method
          allows anyone that can connect to the
          <productname>PostgreSQL</productname> database server to login as
          any <productname>PostgreSQL</productname> user they wish,
          without the need for a password or any other authentication.  See <xref
          linkend="auth-trust"/> for details.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>reject</literal></term>
        <listitem>
         <para>
          Reject the connection unconditionally. This is useful for
          <quote>filtering out</quote> certain hosts from a group, for example a
          <literal>reject</literal> line could block a specific host from connecting,
          while a later line allows the remaining hosts in a specific
          network to connect.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>scram-sha-256</literal></term>
        <listitem>
         <para>
          Perform SCRAM-SHA-256 authentication to verify the user's
          password. See <xref linkend="auth-password"/> for details.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>md5</literal></term>
        <listitem>
         <para>
          Perform SCRAM-SHA-256 or MD5 authentication to verify the
          user's password. See <xref linkend="auth-password"/>
          for details.
         </para>
         <warning>
          <para>
           Support for MD5-encrypted