Advanced DNS/DHCP for
eDirectory™ Environments
Allan Hurst
Partner and Director of Enterprise Strategy
KIS
allanh@kiscc.com
Terry DeFreese
Engineer, Worldwide Support
Novell
tdefreese@novell.com
Version 1.5

© Novell, Inc. All rights reserved.2
• Cell phones, pagers, Treos, Blackberries, etc.,
set them all to stun, please. No noise is
good noise.
• If you have a question, it’s absolutely OK to
ask. It’ll help if you raise your hand first to get
my attention. I’ll try to answer on the fly.
• It’s OK to have fun in here. Honest.
Housekeeping

Who are these guys, anyway?
Allan Hurst
• Works for KIS (“Keep IT Simple”)
• Partner and Director of Enterprise Strategy
• Master CNE
SM
working with Novell® products since 1988 (2.0a)
• One of four partners at KIS, a Novell Platinum Partner and Novell Gold
Training Partner in Fremont, CA, Kansas City, MO, and Cleveland, OH.
• Runs the Enterprise Strategy Practice (network planning, migrations,
upgrades, moves, re-architecting, and clean-up)
• Also runs “The WAP Squad.” (“WAP” stands for …)
• Author of the classic BrainShare presentations, Demystifying DNS and
SLP Made Easy

Who are these guys, anyway?
Terry DeFreese
• Works for Novell® Worldwide Support
• Backline Engineer
• Specializes in DNS/DHCP Issues

Who are you?
• Novell® Open Enterprise Server 2 (OES2)
administrator and/or network manager
• You already know the basics of DNS and DHCP
• Have moved/are moving to OES, and have some
concerns about maintaining Novell DNS/DHCP on a
Linux-based OES2 server
• Some workstations on your network may have odd
resolving problems
• You may be struggling with integrating both Novell
DNS/DHCP into a network which also contains
Active Directory DNS

Where did this session come from?
• This session is the follow-up to Allan’s session from
previous years, entitled “Demystifying DNS”. Every
year the session was presented, people asked for a
second session with more advanced material.
• Many people are still embarrassed to publicly ask about
the basics of DNS or DHCP.
• It’s OK for you to ask anything about DNS/DHCP that
you wish – that’s what this session is for!
(We may not always have the answers, but this is
how sessions get revised to better meet your needs.)

About This Session
• Resolving DNS Requests
• Why Johnny Can't Read
Resolve
• Short vs. Long DNS
Names
• Suffering With Suffixes
• Resolving DNS Problems
• DNS on OES2
DNS• DHCP on OES2
• DNS & DHCP
• DNS & eDirectory™
• DNS, eDirectory and
Active Directory
• Adminstering DNS
using eDirectory
• Tips & Tricks

Issues in DNS Resolution
• Workstations can’t find server during login
• Workstations can't resolve a "short" DNS name
• Workstations append the wrong DNS suffix to a “short”
DNS name
• Web browsing produces strange errors and results
DNS
D
DNS
Let’s review how DNS resolution works...

How a PC Resolves DNS Requests
PC’s local hosts file doesn’t contain the entry, so
the PC asks the LAN’s internal DNS server
Internal DNS
Server doesn’t
know, so it
queries the
ISP’s DNS
ISP’s DNS Server has no
earthly idea, so it queries
the root server to find the
“.ca” TLD server
(NOT SHOWN HERE)
INTERNAL
DNS SERVER
ISP'S DNS
SERVER
TOP LEVEL
DOMAIN
SERVER
FOR “.CA”
ISP queries “.ca”
TLD server to
see who handles
“novell.ca”
“What is the
IP address of
http://www.novell.ca?” 1
2
34
Hosts

How a PC Resolves DNS Requests
PC’s local hosts file doesn’t contain the entry, so
the PC asks the LAN’s internal DNS server
Internal DNS
Server doesn’t
know, so it
queries the
ISP’s DNS
ISP’s DNS Server has no
earthly idea, so it queries
the root server to find the
“.ca” TLD server
(NOT SHOWN HERE)
INTERNAL
DNS SERVER
ISP'S DNS
SERVER
TOP LEVEL
DOMAIN
SERVER
FOR “.CA”
ISP queries “.ca”
TLD server to
see who handles
“novell.ca”
“What is the
IP address of
http://www.novell.ca?”
“.ca” TLD server gives out
location of server(s) handling
NS duties for “novell.ca”
(NOT SHOWN HERE)
5
ISP queries the name server
for “novell.ca” (NOT SHOWN HERE)
“www.novell.ca = 130.57.4.70”
and passes that information
back to internal DNS.
6
Internal DNS server tells PC,
“www.novell.ca = 130.57.4.70”
7
1
2
34
Hosts

Why Johnny Can’t Read Resolve

Four things must be configured on each workstation:
1. Host name. (e.g., “offissa-ws”)
2. Primary DNS suffix. (e.g., “coconino.co.az.us”)
3. List of DNS servers to use for resolution.
4. DNS suffix search list or search method (for “short”, or “unqualified”
names, meaning the name has no DNS domain attached).
If any of these things aren’t set up correctly, the
workstation will probably not be able to resolve.
Why Johnny Can’t Read Resolve
Example: offissa-ws.cocnino.co.az.us

Short vs. Long DNS Names
DNS names can be specified in a relative (short) or fully
qualified (long) format. For example:
Relative: fs1
Fully Qualified: fs1.hq.xyzzy.com
With relative names, the workstation (or server) will
append the default DNS suffix.

Short vs. Long DNS Names
Assuming the workstation in the prior example has a
(correct) DNS suffix of “hq.xyzzy.com”, it will interpret a
short name of “fs1” as equivalent to the fully qualified
name, so that:
fs1[.hq.xyzzy.com] = fs1.hq.xyzzy.com
This will only work, however, if the workstation has the
correct DNS suffix.
Much of the DNS troubleshooting work I’ve performed in
the past couple of years has centered around networks
handing out an incorrect DNS suffix.

Where Do DNS Suffixes Come From?
Contrary to popular belief, DNS suffixes do not come
from under a cabbage leaf. They can be assigned to
workstations in various ways.
– DHCP (The preferred method at 90% of my customers)
– ZCM / GPO / AD (For complex installations)
– Manual Assignment (Try to avoid if possible)
When a workstation can’t resolve, the trick is finding out
what the DNS suffix is, and where it’s coming from.

What are My DNS Suffixes?
If your workstations aren’t able to resolve short DNS
names, then you need to know two things:
1. What DNS suffix(es) do I want my workstations to use?
2. What DNS suffix(es) are my workstations actually using?
Hopefully, you already know the answer to question #1.
To determine the answer to question #2, we need to turn
to our old friend, the ipconfig /all command.
Let’s look at a “vanilla” configuration, with no DNS
suffixes explicitly set up on the workstation except for
what it got from DHCP...

“Normal” DHCP-enabled Workstation
C:>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : offisa-ws
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : coconino.co.az.us
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : coconino.co.az.us
Description . . . . . . . . . . . : NETGEAR GA311 Gigabit Adapter
Physical Address. . . . . . . . . : 00-0F-B5-43-0A-E5
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.129.203
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.129.1
DHCP Server . . . . . . . . . . . : 192.168.129.1
DNS Servers . . . . . . . . . . . : 192.168.129.2
192.168.129.20
Lease Obtained. . . . . . . . . . : Saturday, January 30, 2010 4:03:14 PM
Lease Expires . . . . . . . . . . : Sunday, January 31, 2010 4:03:14 PM

C:>ipconfig /all
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.129.203
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.129.1
DHCP Server . . . . . . . . . . . : 192.168.129.1
DNS Servers . . . . . . . . . . . : 192.168.129.2
192.168.129.20
This field shows you what DNS
suffix will be added to short names
by default. If it’s blank or wrong,
you’ll have problems.
This is the DNS suffix assigned to this
network adapter.

C:>ipconfig /all
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.129.203
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.129.1
DHCP Server . . . . . . . . . . . : 192.168.129.1
DNS Servers . . . . . . . . . . . : 192.168.129.2
192.168.129.20
Watch what happens
to these fields when
we try different types
of configurations

Where are DNS Suffixes Changed?
1. Local Area Connection Properties
Internet Protocol (TCP/IP) Properties
“Advanced” Button
“DNS” Tab
2. My Computer
Properties
Computer Name
"Change" Button
"More" Button

Changing DNS Suffix:
LAN Properties
So what happens
if a DNS suffix is
added here?

Changing DNS Suffix:
Computer Properties
And what happens if
we explicitly define a
DNS suffix here, too?

Result Of Changing DNS Suffix
C:>ipconfig /all
Host Name . . . . . . . . . . . . : offissa-ws
Primary Dns Suffix . . . . . . . : set-under-system-properties.com
DNS Suffix Search List. . . . . . : set-under-system-properties.com
dns-suffix-for-this-connection
Connection-specific DNS Suffix . : dns-suffix-for-this-connection
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.129.203
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.129.1
DHCP Server . . . . . . . . . . . : 192.168.129.1
DNS Servers . . . . . . . . . . . : 192.168.129.2
192.168.129.20
Lease Obtained. . . . . . . . . . : Saturday, January 30, 2010 11:33:02 AM
Lease Expires . . . . . . . . . . : Sunday, January 31, 2010 11:33:02 AM

Adding Multiple DNS Suffixes
Notice that we haven’t
explicitly specified a
DNS suffix for this
connection; that’s
normally picked up
automatically via DHCP.
So what
happens if a
couple of DNS
suffixes are
added here?
Here's what: If a DNS
search order is
specified, it will
override the primary
and connection
specific DNS suffixes.

Result Of Adding Multiple Suffixes
C:>ipconfig /all
Host Name . . . . . . . . . . . . : offissa-ws
Primary Dns Suffix . . . . . . . : [blank; we didn’t set this explicitly]
DNS Suffix Search List. . . . . . : appended-dns-suffix-1
appended-dns-suffix-2
Connection-specific DNS Suffix . : this-dns-suffix-came-from-dhcp
Dhcp Enabled. . . . . . . . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.129.203
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.129.1
DHCP Server . . . . . . . . . . . : 192.168.129.1
DNS Servers . . . . . . . . . . . : 192.168.129.2
192.168.129.20
Lease Obtained. . . . . . . . . . : Saturday, January 30, 2010 11:33:02 AM
Lease Expires . . . . . . . . . . : Sunday, January 31, 2010 11:33:02 AM
These will be searched instead of the
primary or connection specific DNS suffixes

Troubleshooting Tools for DNS
nslookup
• “Built-in” to Windows and Linux.
• Linux version is deprecated, succeeded by “dig”.
dig
• Preferred tool in Linux.
• Has been ported to Windows; Google “dig for windows”.

Basic nslookup Commands
[hostname] ... Resolve [name] to IP address
[IP address] ... Resolve IP address to hostname
server [hostname or IP] ... Use this DNS server
set type = [mx|a|ns|any] ... Filter for (mx, a, ns, any) records
[domain name] ... List records (filtered results if “set type” used)
exit ... Exit program

Query a Single Name Using nslookup
C:>nslookup
Default Server: ignatz.allanh.com
Address: 192.168.129.2
> server krazy.allanh.com
Default Server: krazy.allanh.com
Address: 192.168.129.20
> www.novell.com
Server: krazy.allanh.com
Address: 192.168.129.20
Non-authoritative answer:
Name: www.novell.com
Address: 130.57.5.25
> 130.57.5.25
•Server: krazy.allanh.com
Address: 192.168.129.20
Name: www.novell.com
Address: 130.57.5.25
Indicates that this reply
came from a server other
than the authoritative
name server on record
This is the server that
was queried
The answer to the query

Query Name Servers Using nslookup
> set type=ns
> kiscc.com
Server: ignatz.allanh.com
Address: 192.168.129.2
kiscc.com nameserver = ns41.domaincontrol.com
ns41.domaincontrol.com internet address = 216.69.185.21
Answer
to Query
List of authoritative
name servers

Query MX Records Using nslookup
> set type=mx
> kiscc.com
Server: ignatz.allanh.com
Address: 192.168.129.2
kiscc.com MX preference = 10, mail exchanger = mail.kiscc.com
Answer
to Query
List of authoritative
name servers

Basic Problem Resolution
Check the hosts file for spurious entries
Run
NSLOOKUP
against the
internal DNS
server (or
whatever DNS
server the
workstation is
pointing to)
Run NSLOOKUP against
the ISP's DNS server
INTERNAL
DNS SERVER
ISP'S DNS
SERVER
Run NSLOOKUP
against the NS of
record for the
domain
I can't resolve
“krazy.fubar.com”
1
2
3
4
Hosts
NAME
SERVER FOR
DOMAIN
HAVING
PROBLEMS
Basic DNS Troubleshooting:
1. Work from one end to the other, one segment at a
time. Don't skip segments.
2. Learn to use NSLOOKUP (or DIG).
3. Don't rely on PING to test DNS resolution; you
never know what it's talking to for information.

DNS on OES2
DNS under NetWare® and OES2 are quite compatible,
right down to the (current version of) management tools
such as iManager and/or the Java-based DNS/DHCP
Console.
However, the DNS module on OES2 is not the same as
on “vanilla” SUSE® Linux Enterprise Server 10:
OES2 SLES 10 (not OES2)
rcnovell-named named

OES2 DNS Command Differences
Here are the basic command differences, taken from the
OES2 DNS/DHCP documentation:

OES2 DHCP ≠ NetWare DHCP
DHCP on OES is different than the NetWare® version
• The OES2 DHCP uses different dhcpLocator and
dhcpGroup objects than NetWare. Please don’t point to
the NetWare objects when installing and configuring
OES2 DHCP
• You’ll also need to download a new version of the Java
console, which should be available from the OES2
server’s default web page

But...ZOMG! Where’s the Java Console?

DHCP on OES2
As with the DNS server, the DHCP server on OES2 uses
different commands than you’re probably used to:

DNS and DHCP
If DHCP has been set up correctly, workstations will pick
up a default domain name (“DNS suffix”) that way:

DNS and DHCP – Things To Remember
• When creating a DHCP subnet, a common error is
forgetting to fill out the Domain Name field in iManager.
• If you have more than one DHCP subnet, you may
have more than one subdomain. Make sure each
DHCP subnet is passing the correct subdomain
information to workstation DNS. For example:
192.168.1.x = fubar.com
192.168.2.x = shipping.fubar.com
192.168.3.x = accounting.fubar.com

DNS and eDirectory™
• Service Location Protocol (SLP) uses DNS to resolve
server and directory agent (DA) names
• If SLP isn’t working, workstations will use DNS to locate
their default server and/or tree
• Servers can synchronize time and eDirectory more
quickly if your network has good internal DNS
• Good internal DNS is critical for moving to OES2

Special Internal DNS “A” Records
Useful for Novell® Environments
• eDirectory™
Servers
– Each eDirectory server needs an “A” record. This
includes any server running eDirectory.
– This is required for proper SLP operation.
• eDirectory Tree
– SLP requires that the eDirectory tree must have
its own “A” record. This should point to the
server hosting the Master Replica of [Root].

Special Internal DNS “A” Records
Needed for Novell® Environments
• GroupWise®
– Helps GW clients find the POA quickly
(See TID #10063483)
– “ngwnameserver” = Most accessible* POA’s IP address.
– “ngwnameserver2” = Alternate POA’s IP address.
• ZENworks® 7 (not needed for ZCM 10)
– Imports workstations automatically.
– (See TID #10056752)
– “zenwsimport” = ZFD inventory server’s IP.
*Which I define as the POA able to respond to a client most quickly.

DNS, eDirectory™
and Active Directory

Keep your Active Directory DNS domain separate from
your “real” domain name
• I suggest using a “fake” TLD for Active Directory
integrated domains, such as yourdomain.corp, .internal,
or .ad (Warning: Don’t use .local)
You must use Active Directory’s built-in DNS on all AD-
participating servers
• There must be “A” records for all AD-participating
servers in an AD integrated domain
• Only AD-connected devices should be in an integrated
domain
DNS and Active Directory

For political reasons, some shops maintain separate
systems for normal DNS and AD (integrated) DNS.
If you need to do this:
– Create your MS network’s integrated DNS using Active
Directory. (e.g., “fubar.corp”)
1. Create your network's “real” DNS domain using NetWare® or
Linux. (e.g., “fubar.com”)
2. Point Microsoft's DNS to your OES 2 DNS server for
resolution of your “real” DNS domain (e.g., “fubar.com”)
Keeping eDirectory™
/AD DNS Separate

Keeping eDirectory™
/AD DNS Separate
Internet
OES 2 Servers
hosting “fubar.com”
Windows Servers
hosting “fubar.corp”
DNS queries for anything
except “fubar.corp”
Active Directory
workstations
DNS Queries for all domains
Answer fubar.corp, pass all
else upstream to OES DNS

If you’re one of the shops that maintains separate DNS
using eDirectory and Active Directory, improve your
DNS fault tolerance by pointing the two systems at
each other.
If for any reason your Active Directory domain
controllers go down, workstations (and servers) can
resolve through eDirectory...and vice-versa for non-AD
systems.
This is more easily explained with a diagram...
eDirectory™
/AD DNS Fault Tolerance

eDirectory™
/AD DNS Fault Tolerance
Primary: “fubar.com”
Secondary: “fubar.corp”
OES2 Windows
Secondary: “fubar.com”
Primary: “fubar.corp” [AD Integrated)
Regardless of
whether or not
it’s in AD, any
device in this
configuration
can resolve for
either domain.
Non-AD
Device
AD-Based
Device
Non-AD
Device
AD-Based
Device

Administering DNS using eDirectory™

• Create a separate eDirectory container … such as
“DNSDHCP”. Place the container high in the tree,
preferably above where your servers are kept
• Install all DNS and DHCP objects and services inside
this new DNSDHCP container
• In large/busy networks, split off the DNSDHCP
container as a separate partition
• Place replicas of the DNSDHCP partition on each DNS
and/or DHCP server, plus whatever is needed for at
least 3 copies
Classic Best Practices
for eDirectory™
DNS

iManager can be used for DNS/DHCP creation and
management
Be aware! iManager has separate plug-ins for NetWare®
vs. Linux DHCP
The (Java-based) DNS/DHCP Console will manage
either platform...assuming you’re running the most
current version
Similar to iManager, the DNS/DHCP Console has
separate tabs for NetWare vs. Linux
DNS Administration

When creating an IN-ADDR-ARPA zone in the
DNS/DHCP Console, enter only the network octets
“My Reverse DNS Doesn’t Work”
Example: For
192.168.129.0,
leave this blank.

Internal DNS for External Devices
Internal DNS must also contain “A” records for your
external services, or your internal workstations won’t be
able to resolve them
Not adding “www” internally is a common error

DNS for DMZ Devices
Internet
gw.xyzzy.com
243.128.24.1
DMZ
“Where is
gw.xyzzy.com?”
LAN
“It’s at
243.128.24.1”
“Where is
gw.xyzzy.com?”
“It’s at
243.128.24.1”
Internal DNS
Server
External DNS
Server

Internal/External DNS Records
If you have a publicly-available server inside your firewall
using NAT, remember to add an internal “A” record
pointing to the internal IP address

DNS for Internal/Exernal Devices
Internet
“Where is
gw.xyzzy.com?”
LAN
“It’s at
10.2.0.43”
“Where is
gw.xyzzy.com?”
“It’s at
243.128.24.1”
Internal
DNS Server
External
DNS Server
Firewall
using NAT
243.128.24.1
gw.xyzzy.com
10.2.0.43
10.2.0.43

DNS/DHCP Resources
http://tinyurl.com/oes2dnsdhcp
Quick link to OES2 DNS/DHCP Documentation (PDF)
http://tinyurl.com/nw-to-oes2-lessons-learned
Great article (not by me) on NetWare/OES2 migration pitfalls
http://www.zytrax.com/books/dns/
“DNS For Rocket Scientists”... my favorite DNS reference text

Got Reference?
If you would like an updated copy of this presentation,
please pass me your business card.
On the back, please write any or all of:
Advanced DNS … for this presentation.
Basic DNS … for the classic presentation, Demystifying DNS
SLP … for the classic presentation, SLP Made Easy

Thank You!
Very special thanks to David Powell, my Senior
Network Engineer at KIS, for his invaluable assistance
in proofing this presentation and gently pointing out all
of the things I forgot to add in the first couple of drafts.
Thanks also to NOBUG - the “Novell® Oakland Bay Area
User Group” (http://www.nobug.us) - for their invaluable
support and feedback in creating, testing,
and refining this presentation.
Support your local NUI & LUG chapters!

Unpublished Work of Novell, Inc. All Rights Reserved.
This work is an unpublished work and contains confidential, proprietary, and trade secret information of Novell, Inc.
Access to this work is restricted to Novell employees who have a need to know to perform tasks within the scope
of their assignments. No part of this work may be practiced, performed, copied, distributed, revised, modified,
translated, abridged, condensed, expanded, collected, or adapted without the prior written consent of Novell, Inc.
Any use or exploitation of this work without authorization could subject the perpetrator to criminal and civil liability.
General Disclaimer
This document is not to be construed as a promise by any participating company to develop, deliver, or market a
product. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in
making purchasing decisions. Novell, Inc. makes no representations or warranties with respect to the contents
of this document, and specifically disclaims any express or implied warranties of merchantability or fitness for any
particular purpose. The development, release, and timing of features or functionality described for Novell products
remains at the sole discretion of Novell. Further, Novell, Inc. reserves the right to revise this document and to
make changes to its content, at any time, without obligation to notify any person or entity of such revisions or
changes. All Novell marks referenced in this presentation are trademarks or registered trademarks of Novell, Inc.
in the United States and other countries. All third-party trademarks are the property of their respective owners.

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (17)

Destaque

Destaque (20)

Mais de Novell

Mais de Novell (20)