reject_rbl_client

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

reject_rbl_client

Frank Kirschner

Hallo liebe Postfix Freunde,

Man nutzt ja den Postfix Konfigurationsparameter "reject_rbl_client" so z.B.:

reject_rbl_client ix.dnsbl.manitu.net

Wenn ich nun einen eigenen RBL DNS Server im lokalen Netz betreibe, kann ich den anstatt mit seinem Namen direkt mir seiner IP ansprechen?:

reject_rbl_client 172.16.123.101

Aktuell frage ich mit "reject_rbl_client rbl.intern" ab, sehe aber oft im Logfile:
warning: 191.82.81.63.rbl.intern: RBL lookup error: Host or domain name not found. Name service error for name=191.82.81.63.rbl.intern type=A: Host not found, try again

Ich nutze rbldnsd und möchte gern ausschließen, dass es ein sporadisch auftretendes Problem mit der Namensauflösung rbl.intern => 172.16.123.101 gibt.
Der Dienst selbst läuft stabil:

Active: active (running) since Sun 2020-09-20 09:56:12 CEST; 1 months 27 days ago


Viele Grüße,
Frank Kirschner

Reply | Threaded
Open this post in threaded view
|

AW: reject_rbl_client

Uwe Drießen
Im Auftrag von [hidden email]
> Wenn ich nun einen eigenen RBL DNS Server im lokalen Netz betreibe, kann
> ich den anstatt mit seinem Namen direkt mir seiner IP ansprechen?:
>
> reject_rbl_client 172.16.123.101

Testen (wüste nicht was dagegen sprechen sollte)

>
> Aktuell frage ich mit "reject_rbl_client rbl.intern" ab, sehe aber oft im Logfile:
> warning: 191.82.81.63.rbl.intern: RBL lookup error: Host or domain name not
> found. Name service error for name=191.82.81.63.rbl.intern type=A: Host
> not found, try again
>
> Ich nutze rbldnsd und möchte gern ausschließen, dass es ein sporadisch
> auftretendes Problem mit der Namensauflösung rbl.intern => 172.16.123.101
> gibt.

Ist der Domainname intern bekannt ?
Was bringt dir host rbl.intern  bzw. dig @127.0.0.1 short rbl.intern

Trag es bei deinem internen DNS-Server richtig  ein



Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server.
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045

"wenn Digitalisierung den Aufwand im Vergleich zur Analogen Arbeitsweise dermaßen erhöht, das wir nur noch am PC sitzen müssten,
 dann wird es Zeit sich zu überlegen zur Analogen Arbeitsweise zurückzukehren"
"Programmierer müssen lernen wie Menschen denken. "



Reply | Threaded
Open this post in threaded view
|

Re: reject_rbl_client

Frank Kirschner
Am 17.11.2020 um 09:43 schrieb Uwe Drießen:

>
> Ist der Domainname intern bekannt ?
> Was bringt dir host rbl.intern  bzw. dig @127.0.0.1 short rbl.intern

eigentlich schon, nur passiert etwas für mich unerklärliches eben:

teste ich mit dem host Befehl bekomme ich kein Ergebnis,
teste ich jedoch meine RBL (die IP 1.2.3.4 habe ich zum testen in der
Zone hinterlegt);
wird diese korrekt mit 127.0.0.2 beantwortet:

# host rbl.intern
# dig 4.3.2.1.rbl.intern

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> 4.3.2.1.rbl.intern
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46064
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;4.3.2.1.rbl.intern.            IN      A

;; ANSWER SECTION:
4.3.2.1.rbl.intern.     1914    IN      A       127.0.0.2

;; Query time: 0 msec
;; SERVER: 192.168.130.254#53(192.168.130.254)
;; WHEN: Tue Nov 17 10:45:00 CET 2020
;; MSG SIZE  rcvd: 63

Wo habe ich den Denkfehler?


Reply | Threaded
Open this post in threaded view
|

AW: reject_rbl_client

Uwe Drießen
Im Auftrag von [hidden email]

>
> Am 17.11.2020 um 09:43 schrieb Uwe Drießen:
>
> >
> > Ist der Domainname intern bekannt ?
> > Was bringt dir host rbl.intern  bzw. dig @127.0.0.1 short rbl.intern
>
> eigentlich schon, nur passiert etwas für mich unerklärliches eben:
>
> teste ich mit dem host Befehl bekomme ich kein Ergebnis,
> teste ich jedoch meine RBL (die IP 1.2.3.4 habe ich zum testen in der
> Zone hinterlegt);
> wird diese korrekt mit 127.0.0.2 beantwortet:
>
> # host rbl.intern
> # dig 4.3.2.1.rbl.intern
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> 4.3.2.1.rbl.intern
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46064
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;4.3.2.1.rbl.intern.            IN      A
>
> ;; ANSWER SECTION:
> 4.3.2.1.rbl.intern.     1914    IN      A       127.0.0.2
>
> ;; Query time: 0 msec
> ;; SERVER: 192.168.130.254#53(192.168.130.254)
> ;; WHEN: Tue Nov 17 10:45:00 CET 2020
> ;; MSG SIZE  rcvd: 63
>
> Wo habe ich den Denkfehler?

DNS != RBL
RBL funktioniert im groben aber als/wie eine DNS Abfrage
       
Wenn du eine Namensauflösung möchtest dann musst du auch den korrekten Namen und IP in der Zone hinterlegen
Dann muss auch der Befehl host eine IP zurückliefern sofern du den Programmen dig und host dieselbe Frage stellst.
 
Zuerst muss postfix wissen auf welcher IP der Dienst läuft (DNS abfrage für rbl.intern) dann wird mit der IP des einliefernden Client eine "DNS" anfrage an die RBL (dig @rbl.intern 195.80.10.12 oder sowas in der art :-)) ) gestellt
kommt da etwas außer NXDOMAIN zurück wird das entsprechende ausgeführt, kann ein White oder auch Blacklist sein.


Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server.
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045

"wenn Digitalisierung den Aufwand im Vergleich zur Analogen Arbeitsweise dermaßen erhöht, das wir nur noch am PC sitzen müssten,
 dann wird es Zeit sich zu überlegen zur Analogen Arbeitsweise zurückzukehren"
"Programmierer müssen lernen wie Menschen denken. "


Reply | Threaded
Open this post in threaded view
|

Re: reject_rbl_client

Frank Kirschner
Am 17.11.2020 um 11:36 schrieb Uwe Drießen:

> Im Auftrag von [hidden email]
>> Am 17.11.2020 um 09:43 schrieb Uwe Drießen:
>>
>>> Ist der Domainname intern bekannt ?
>>> Was bringt dir host rbl.intern  bzw. dig @127.0.0.1 short rbl.intern
>> eigentlich schon, nur passiert etwas für mich unerklärliches eben:
>>
>> teste ich mit dem host Befehl bekomme ich kein Ergebnis,
>> teste ich jedoch meine RBL (die IP 1.2.3.4 habe ich zum testen in der
>> Zone hinterlegt);
>> wird diese korrekt mit 127.0.0.2 beantwortet:
>>
>> # host rbl.intern
>> # dig 4.3.2.1.rbl.intern
>>
>> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.6 <<>> 4.3.2.1.rbl.intern
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46064
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;4.3.2.1.rbl.intern.            IN      A
>>
>> ;; ANSWER SECTION:
>> 4.3.2.1.rbl.intern.     1914    IN      A       127.0.0.2
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 192.168.130.254#53(192.168.130.254)
>> ;; WHEN: Tue Nov 17 10:45:00 CET 2020
>> ;; MSG SIZE  rcvd: 63
>>
>> Wo habe ich den Denkfehler?
> DNS != RBL
> RBL funktioniert im groben aber als/wie eine DNS Abfrage
>
> Wenn du eine Namensauflösung möchtest dann musst du auch den korrekten Namen und IP in der Zone hinterlegen
> Dann muss auch der Befehl host eine IP zurückliefern sofern du den Programmen dig und host dieselbe Frage stellst.
>  
> Zuerst muss postfix wissen auf welcher IP der Dienst läuft (DNS abfrage für rbl.intern) dann wird mit der IP des einliefernden Client eine "DNS" anfrage an die RBL (dig @rbl.intern 195.80.10.12 oder sowas in der art :-)) ) gestellt
> kommt da etwas außer NXDOMAIN zurück wird das entsprechende ausgeführt, kann ein White oder auch Blacklist sein.

Stimmt, habe mich etwas verkehrt ausgedrückt. Das Problem ist gefunden.
Zur Namensauflösung wird unbound in der Firewall verwendet.
Durch ein Update gibt es einen Bug, er kommt mit .intern nicht zurecht
und delegiert es weiter, was keinen Sinn ergibt.
Ich habe nun rbldns an localhost gebunden und greife auch mit Postfix an
localhost darauf zu. Funktioniert.

Danke für die Hinweise,
Frank



Reply | Threaded
Open this post in threaded view
|

Re: reject_rbl_client

Max Grobecker
Moin,

Am 17.11.2020 um 17:37 schrieb [hidden email]:

> Stimmt, habe mich etwas verkehrt ausgedrückt. Das Problem ist gefunden. Zur Namensauflösung wird unbound in der Firewall verwendet.
> Durch ein Update gibt es einen Bug, er kommt mit .intern nicht zurecht und delegiert es weiter, was keinen Sinn ergibt.


".intern" ist auch kein für interne Zwecke reservierter Name. Für sowas solltest du dann lieber eine offizielle Special-Use TLD nehmen,
wie bspw. "home.arpa". Oder man delegiert das als Subzone unterhalb seiner eigenen bestehenden Domain.

Komplette Liste der reservierten Namen:
 -> https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml

Die TLD ".local" sollte man aber tunlichst nicht verwenden, die ist für mDNS reserviert.



Viele Grüße
 Max
Reply | Threaded
Open this post in threaded view
|

AW: reject_rbl_client

Uwe Drießen
In reply to this post by Frank Kirschner
Im Auftrag von [hidden email]
>
>
> Stimmt, habe mich etwas verkehrt ausgedrückt. Das Problem ist gefunden.
> Zur Namensauflösung wird unbound in der Firewall verwendet.
> Durch ein Update gibt es einen Bug, er kommt mit .intern nicht zurecht
> und delegiert es weiter, was keinen Sinn ergibt.
> Ich habe nun rbldns an localhost gebunden und greife auch mit Postfix an
> localhost darauf zu. Funktioniert.

Eigentlich ist unbound völlig egal welche buchstaben wo stehen ist left bei right hand

Links wird gesucht und rechts wird zurückgeliefert :-)

Schau da mal rein

https://www.raspberry-pi-geek.de/ausgaben/rpg/2017/06/unbound-als-zentraler-dns-server-und-adblocker/



Mit freundlichen Grüßen

Uwe Drießen
--
Software & Computer

Netzwerke, Server.
Wir vernetzen Sie und Ihre Rechner !

Uwe Drießen
Lembergstraße 33
67824 Feilbingert

Tel.: 06708660045

"wenn Digitalisierung den Aufwand im Vergleich zur Analogen Arbeitsweise dermaßen erhöht, das wir nur noch am PC sitzen müssten,
 dann wird es Zeit sich zu überlegen zur Analogen Arbeitsweise zurückzukehren"
"Programmierer müssen lernen wie Menschen denken. "