rdns: NGINX HTTP rDNS-Modul

Erfordert den Pro-Plan (oder höher) des GetPageSpeed NGINX Extras-Abonnements.

Installation

Sie können dieses Modul in jeder RHEL-basierten Distribution installieren, einschließlich, aber nicht beschränkt auf:

RedHat Enterprise Linux 7, 8, 9 und 10
CentOS 7, 8, 9
AlmaLinux 8, 9
Rocky Linux 8, 9
Amazon Linux 2 und Amazon Linux 2023

CentOS/RHEL 8+, Fedora Linux, Amazon Linux 2023+CentOS/RHEL 7 und Amazon Linux 2

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install nginx-module-rdns

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install nginx-module-rdns

Aktivieren Sie das Modul, indem Sie Folgendes an den Anfang von /etc/nginx/nginx.conf hinzufügen:

load_module modules/ngx_http_rdns_module.so;

Dieses Dokument beschreibt nginx-module-rdns v1.2.1, veröffentlicht am 08. Mai 2026.

Reverse DNS-Lookup-Modul für NGINX mit hostname-basiertem Zugriffskontroll.

Führen Sie asynchrone Reverse-DNS (PTR)-Abfragen zu Client-IP-Adressen durch und verwenden Sie den aufgelösten Hostnamen für Entscheidungen zur Zugriffskontrolle, Protokollierung oder bedingte Anfragebehandlung.

Funktionen

Asynchrone DNS-Auflösung - Nicht-blockierende PTR-Abfragen mit NGINX's Kern-Resolver
Doppelte Überprüfungsmodus - Optionale Vorwärts-DNS-Überprüfung zur Verhinderung von DNS-Spoofing
Regex-basierte Zugriffskontrolle - Erlauben oder verweigern Sie Anfragen basierend auf Hostnamenmustern
Vollständige Kontextunterstützung - Funktioniert in http, server, location und if-Blöcken
Effizientes Caching - Nutzt den Resolver-Cache von NGINX (bis zu 30 Sekunden oder DNS TTL)
Unterstützung für dynamische Module - Als statisches oder dynamisches Modul bauen
IPv4- und IPv6-Unterstützung - Funktioniert mit beiden Adressfamilien

Schnellstart

http {
    # Definieren Sie einen DNS-Resolver (erforderlich)
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    server {
        listen 80;

        location / {
            # Aktivieren Sie den Reverse-DNS-Lookup
            rdns on;

            # Erlauben Sie nur Anfragen von *.google.com
            rdns_allow \.google\.com$;

            # Verweigern Sie Anfragen von bekannten schlechten Akteuren
            rdns_deny \.spam\.example\.com$;

            # Verwenden Sie den Hostnamen in Ihrer Anwendung
            proxy_set_header X-Client-Hostname $rdns_hostname;
            proxy_pass http://backend;
        }
    }
}

Direktiven

`rdns`

Aktiviert oder deaktiviert Reverse-DNS-Lookups.


Syntax	`rdns on` \| `off` \| `double`
Standard	`off`
Kontext	`http`, `server`, `location`, `if`
Phase	rewrite

Werte:

Wert	Beschreibung
`off`	Deaktiviert rDNS-Lookup. `$rdns_hostname` wird `-` sein
`on`	Führt eine einzelne PTR-Abfrage durch
`double`	Führt eine PTR-Abfrage durch und überprüft dann mit einer Vorwärts-A/AAAA-Abfrage

Doppelter Modus bietet Schutz gegen DNS-Spoofing, indem überprüft wird, dass der aufgelöste Hostname zurück zur ursprünglichen Client-IP-Adresse zeigt. Wenn die Überprüfung fehlschlägt, wird $rdns_hostname auf not found gesetzt.

`rdns_allow`

Erlaubt den Zugriff, wenn der aufgelöste Hostname mit dem Muster übereinstimmt.


Syntax	`rdns_allow` regex
Standard	-
Kontext	`http`, `server`, `location`
Phase	access

Das Muster ist ein Groß-/Kleinschreibung-empfindlicher PCRE-Regulärer Ausdruck.

`rdns_deny`

Verweigert den Zugriff (gibt 403 zurück), wenn der aufgelöste Hostname mit dem Muster übereinstimmt.


Syntax	`rdns_deny` regex
Standard	-
Kontext	`http`, `server`, `location`
Phase	access

Das Muster ist ein Groß-/Kleinschreibung-empfindlicher PCRE-Regulärer Ausdruck.

Variablen

`$rdns_hostname`

Enthält das Ergebnis des Reverse-DNS-Lookups.

Wert	Bedeutung
hostname	Erfolgreich aufgelöster Hostname
`not found`	Lookup fehlgeschlagen, Zeitüberschreitung oder doppelte Überprüfung fehlgeschlagen
`-`	rDNS ist in diesem Kontext deaktiviert

Anwendungsbeispiele

Überprüfen von Suchmaschinen-Crawlern

Stellen Sie sicher, dass Anfragen, die behaupten, von Googlebot zu stammen, tatsächlich von Google stammen:

location / {
    resolver 8.8.8.8;

    # Führen Sie rDNS nur für Anfragen durch, die behaupten, Googlebot zu sein
    if ($http_user_agent ~* "Googlebot") {
        rdns double;
    }

    # Erlauben Sie verifiziertes Googlebot
    rdns_allow \.googlebot\.com$;
    rdns_allow \.google\.com$;

    # Ihre normale Konfiguration
    proxy_pass http://backend;
}

Blockieren von Anfragen nach Hostname

location / {
    resolver 8.8.8.8;
    rdns on;

    # Blockieren Sie bekannte Spam-Quellen
    rdns_deny \.spam\.example\.com$;
    rdns_deny \.malicious\.net$;

    proxy_pass http://backend;
}

Protokollieren von Client-Hostnamen

http {
    resolver 8.8.8.8;

    log_format with_hostname '$remote_addr - $rdns_hostname - $remote_user [$time_local] '
                             '"$request" $status $body_bytes_sent '
                             '"$http_referer" "$http_user_agent"';

    server {
        access_log /var/log/nginx/access.log with_hostname;

        location / {
            rdns on;
            proxy_pass http://backend;
        }
    }
}

Bedingte Logik basierend auf Hostname

location / {
    resolver 8.8.8.8;
    rdns on;

    # Setzen Sie eine Variable basierend auf dem Hostnamen
    set $is_internal "no";
    if ($rdns_hostname ~ \.internal\.company\.com$) {
        set $is_internal "yes";
    }

    # Verwenden Sie in Proxy-Headern
    proxy_set_header X-Is-Internal $is_internal;
    proxy_set_header X-Client-Hostname $rdns_hostname;
    proxy_pass http://backend;
}

Unterschiedliche Regeln für verschiedene Standorte

server {
    resolver 8.8.8.8;

    # Öffentliche API - kein rDNS
    location /api/public {
        proxy_pass http://api-backend;
    }

    # Admin-Bereich - strenge Hostnamenüberprüfung
    location /admin {
        rdns double;
        rdns_allow \.admin\.company\.com$;
        proxy_pass http://admin-backend;
    }

    # Allgemeine Inhalte - Hostnamen protokollieren
    location / {
        rdns on;
        proxy_pass http://web-backend;
    }
}

Zugriffskontrollverhalten

Regelbewertung

Regeln werden in der Reihenfolge bewertet, in der sie in der Konfiguration erscheinen
Die erste übereinstimmende Regel bestimmt das Ergebnis:
rdns_allow Übereinstimmung: Anfrage wird erlaubt (Verarbeitung wird fortgesetzt)
rdns_deny Übereinstimmung: Anfrage wird mit 403 Forbidden verweigert
Wenn keine Regeln übereinstimmen, wird die Anfrage erlaubt

Regelvererbung

Kindkontexte (Standorte) erben Regeln von übergeordneten Kontexten nur, wenn sie keine eigenen Regeln definieren
Sobald ein Kind eine eigene rdns_allow oder rdns_deny Regel definiert, werden die Regeln der Eltern nicht mehr vererbt

server {
    rdns_allow \.trusted\.com$;  # Regel auf Serverebene

    location /public {
        # Erbt die Regel rdns_allow auf Serverebene
    }

    location /private {
        rdns_deny \.untrusted\.com$;  # Hat eigene Regel
        # Erbt NICHT die Regel rdns_allow auf Serverebene
    }
}

Wichtige Hinweise

Resolver-Konfiguration

Eine resolver-Direktive muss im selben Kontext oder einem übergeordneten Kontext definiert werden, wenn rdns on oder rdns double verwendet wird. NGINX wird mit dem Fehler no core resolver defined for rdns nicht starten, wenn diese Anforderung nicht erfüllt ist.

# Gut: Resolver definiert
server {
    resolver 8.8.8.8;
    location / {
        rdns on;  # Funktioniert
    }
}

# Schlecht: kein Resolver
server {
    location / {
        rdns on;  # Fehler: kein Kernresolver definiert
    }
}

Problematische Konfiguration

server { rdns on;

location / {
    error_page 404 = @fallback;
}

location @fallback {
    # Schleife! Der rDNS-Lookup startet die Anfrageverarbeitung neu
}

}

Korrigierte Konfiguration

server { rdns on;

location / {
    error_page 404 = @fallback;
}

location @fallback {
    rdns off;  # Deaktivieren Sie rDNS im benannten Standort
    # ...
}

} ```

Leistungsüberlegungen

Jeder rDNS-Lookup fügt der Anfrageverarbeitung Latenz hinzu
Verwenden Sie bedingte Aktivierung (über if-Blöcke), um Abfragen auf bestimmte Benutzeragenten oder Bedingungen zu beschränken
Der Resolver-Cache hilft, wiederholte Abfragen für dieselbe IP zu reduzieren
Erwägen Sie den double-Modus nur, wenn Spoofing-Schutz erforderlich ist

Fehlersuche

"no core resolver defined for rdns"

Fügen Sie eine resolver-Direktive im selben oder übergeordneten Kontext hinzu: nginx resolver 8.8.8.8;

$rdns_hostname ist immer "not found"

Überprüfen Sie, ob der Resolver von Ihrem Server aus erreichbar ist
Überprüfen Sie die Timeout-Einstellungen des Resolvers
Wenn Sie rdns double verwenden, stellen Sie sicher, dass der PTR-Datensatz-Hostname einen gültigen A/AAAA-Datensatz hat, der zurück zur Client-IP zeigt
Überprüfen Sie die NGINX-Fehlerprotokolle auf Resolver-Fehler

$rdns_hostname ist immer "-"

Die rdns-Direktive ist entweder: - Im aktuellen Kontext nicht aktiviert - Auf off gesetzt - Innerhalb eines if-Blocks, dessen Bedingung falsch ist

403 Forbidden-Antworten

Eine rdns_deny-Regel hat mit dem Hostnamen des Clients übereingestimmt. Überprüfen Sie Ihre Verweigerungsmuster und den tatsächlich aufgelösten Hostnamen.