rdns: NGINX HTTP rDNS-Modul

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.0 veröffentlicht am 02. Februar 2026.

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

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

Funktionen

Asynchrone DNS-Auflösung - Nicht blockierende PTR-Abfragen mit dem Kernresolver von NGINX
Doppelverifizierungsmodus - Optionale Vorwärts-DNS-Verifizierung 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 erstellen
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 den rDNS-Lookup. `$rdns_hostname` wird `-` sein
`on`	Führt einen einzelnen PTR-Lookup durch
`double`	Führt einen PTR-Lookup durch und verifiziert dann mit einem Vorwärts-A/AAAA-Lookup

Doppelmodus bietet Schutz gegen DNS-Spoofing, indem überprüft wird, ob der aufgelöste Hostname auf die ursprüngliche Client-IP-Adresse zurückweist. 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 nicht groß-/kleinschreibungsabhängiger 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 nicht groß-/kleinschreibungsabhängiger 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 Verifizierung 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;
}

Anfragen nach Hostnamen blockieren

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

Client-Hostnamen protokollieren

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 Hostnamen

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 Hostnamenverifizierung
    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 übergeordneten Regeln 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 gleichen 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 Lookups auf bestimmte Benutzeragenten oder Bedingungen zu beschränken
Der Resolver-Cache hilft, wiederholte Lookups für dieselbe IP zu reduzieren
Berücksichtigen Sie den double-Modus nur, wenn Spoofing-Schutz erforderlich ist

Fehlersuche

"no core resolver defined for rdns"

Fügen Sie eine resolver-Direktive im gleichen 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 Einstellungen für die Resolver-Zeitüberschreitung
Wenn Sie rdns double verwenden, stellen Sie sicher, dass der PTR-Eintrag des Hostnamens einen gültigen A/AAAA-Eintrag hat, der auf die Client-IP zurückweist
Ü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.

GitHub

Sie finden möglicherweise zusätzliche Konfigurationstipps und Dokumentationen für dieses Modul im GitHub-Repository für nginx-module-rdns.