AS/400 DNS-Server ohne OpNav: Unterschied zwischen den Versionen

Aus Knowledgebase
Zur Navigation springen Zur Suche springen
(Backport der Verbesserungen nach Übersetzung in try-as400.pocnet.net)
K (Typo)
 
Zeile 25: Zeile 25:
Mit <code>CHGDNSA</code> kann der Autostart beim TCP-Start als auch der Debuglevel festgelegt und danach der Server mit <code>STRTCPSVR *DNS</code> gestartet werden.
Mit <code>CHGDNSA</code> kann der Autostart beim TCP-Start als auch der Debuglevel festgelegt und danach der Server mit <code>STRTCPSVR *DNS</code> gestartet werden.


Weniger erfreulich ist die Tatsache, dass sich beim Test des DNS als Secondary zu einem BIND 9.10.3 unter Debian Linux keine Sekundärzonen laden lassen. Der Primärserver schiebt die Zonen via AXFR raus, der Slave auf der AS/400 nimmt diese leider nicht an. Gemäß Joblog der AXFRs erwartet BIND mehr Datenbytes als er geliefert bekommt.
Weniger erfreulich ist die Tatsache, dass sich beim Test des DNS als Secondary zu einem BIND 9.10.3 unter Debian Linux keine Sekundärzonen laden lassen. Der Primärserver schiebt die Zonen via AXFR raus, der Slave auf der AS/400 nimmt diese leider nicht an. Gemäß Job Log der AXFRs erwartet BIND mehr Datenbytes als er geliefert bekommt.


== Weblinks ==
== Weblinks ==

Aktuelle Version vom 23. Januar 2023, 17:52 Uhr

Der DNS-Server von OS/400 kann offiziell nur via OpNav konfiguriert werden. Es geht aber auch anders…

OpNav ist ein Bestandteil von ClientAccess für Windows, was bei einer OS/400-Installation mit installiert wird. Bei alten OS/400-Versionen wird eine entsprechend alte ClientAccess-Version mitgeliefert, die unter aktuellen Windows-Versionen nicht oder nicht mehr sauber läuft. Erschwerend kommt hinzu, dass der SMB-Server dieser alten Versionen nicht mehr mit dem neueren Client-Code in neueren Windows-Versionen harmoniert — Zugriff leider nicht möglich. Somit bleibt nur FTP zum Datenaustausch.

Konfiguration

Dns DNS von OS/400 V4R2 bis einschliesslich V4R5 basiert auf BIND 4.9.3 vom ISC. Somit gelten auch die Konfigurationsdirektiven unmittelbar. Beim Start wird nach der Hauptkonfiguratiosndatei /QIBM/USERDATA/OS400/DNS/BOOT gesucht. Diese kann man bequem selbst erstellen:

EDTF '/QIBM/USERDATA/OS400/DNS/BOOT'

Beispiel:

; Working Directory
directory /QIBM/USERDATA/OS400/DNS
; Root-DNS-File
cache . NAMED.ROOT
; Zone Statements
secondary myzone.com 192.168.1.11 db.myzone.com

EDTF ist in der Bedienung sehr ähnlich zu SEU. Alternativ kann man diese Datei auch woanders erstellen und im ASCII-Mode per FTP an die passende Stelle laden.

Es empfiehlt sich, eine aktuelle Rootzonen-Datei zu importieren. Diese erhält man z. B. bei Internic und kann per FTP nach QDNS/QATOCDNSRV.ROOT als auch nach — wie in der entsprechenden Direktive angegeben — nach /QIBM/USERDATA/OS400/DNS/ROOT.HINT übertragen werden.[1]

Vor dem Start des DNS-Servers sollten die Verzeichnisrechte angepasst werden:

STRQSH CMD('CHOWN QTCP /QIBM/USERDATA/OS400/DNS')

Mit CHGDNSA kann der Autostart beim TCP-Start als auch der Debuglevel festgelegt und danach der Server mit STRTCPSVR *DNS gestartet werden.

Weniger erfreulich ist die Tatsache, dass sich beim Test des DNS als Secondary zu einem BIND 9.10.3 unter Debian Linux keine Sekundärzonen laden lassen. Der Primärserver schiebt die Zonen via AXFR raus, der Slave auf der AS/400 nimmt diese leider nicht an. Gemäß Job Log der AXFRs erwartet BIND mehr Datenbytes als er geliefert bekommt.

Weblinks

  1. Der BIND kann mit einer Datei in einer Library nichts anfangen.