DNS-Server without OpNav

From Try-AS/400
Jump to navigation Jump to search

The DNS-Server of OS/400 is to be configured via OpNav exclusively. There's another way, though…

OpNav is part of the Client access for Windows package from IBM, often included in the installation of a machine. With old OS/400 releases, the Client Access package is also equally old. Sometimes it's just not possible to get the thing running with current Windows OS's. Besides that, the integrated SMB Server within OS/400 is also most likely too old to successfully establish a drive mapping from current Windows releases. That said, the remaining option to transfer data is FTP.

Actual configuration

The DNS of OS/400 Release V4R2 to V4R5 is based on BIND 4.9.3 from the ISC. Thus, configuration file syntax is exactly the same as known from common platforms. After starting the job (aka: process), the main configuration file /QIBM/USERDATA/OS400/DNS/BOOT is opened. One can easily create this file from a green screen:

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

Example content:

; 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 and SEU SEU are very similar to use. Alternatively, this file can be created elsewhere (outside the AS/400) and uploaded via FTP to the path mentioned above.

I recommend to import a current root zone file. One can download it from Internic and should be uploaded to QDNS/QATOCDNSRV.ROOT or /QIBM/USERDATA/OS400/DNS/ROOT.HINT, depending on the configuration directive used earlier.[1]

Before starting BIND, permissions should be adjusted:

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

One can change automatic start of BIND at TCP start time with CHGDNSA. The desired debug level can also be specified there. Afterwards, start the server with STRTCPSVR *DNS.

Unfortunately, a test run with the old BIND as a slave DNS in the local LAN yielded errors. The old code isn't compatible with current BIND 9.10.3 running on Debian Linux. According to the 9.10.3 logs, BIND reacts to AXFR requests and pushes out the zone data. The slave BIND on OS/400 refuses to accept this data. The job log of an individual AXFR job on OS/400 states that there has been more bytes expected in a transfer then received.

Footnotes

  1. BIND can't cope with a file in a Library.

Weblinks