Getting FQDN hostname registered in central company DNS, DC02.AD.COMPANY.COM (OpenBSD works, but Debian+FreeBSD does not)

[rusma]

Dear FreeBSD users,

how can I get my FreeBSD hostname registered in the central dns (DC02.AD.COMPANY.COM) at my workplace? My FreeBSD box gets an ip from the dhcp, but it's hostname is not registered at the central dns (so others can look up the ip by knowing the domain name).

But when I install a bhyve instance with OpenBSD 6.9 on it (just a standard install) it's hostname gets magically registered at obsd.ad.company.com. I was so surprised to see this effect.

Another bhyve instance of Debian 10 (pretty standard install), also does not get a hostname (only a dhcp ip).

Is it possible to analyze what is the difference between OpenBSD and FreeBSD networking here, to try to get the hostname registered?

I thought it might be something to do with Kerberos and Active Directory, but I do not think so; OpenBSD just does this little trick that I do not know what is.

I wanted to achieve this to help a colleague migrating some databases from MS Access using R through rapache (libapache2-mod-r-base) in the debian instance.

When installing OpenBSD in the bhyve, I think I saw some blue letters noticing an «ack!» had happened, but I took no futher not of it. It might be that ack ...

Best,
Rasmus

 

[SirDice]

I thought it might be something to do with Kerberos and Active Directory, but I do not think so; OpenBSD just does this little trick that I do not know what is.

I'd check with the maintainers of the AD/DNS/DHCP. It's likely they've used a specific setting there.

A "normal" DHCP request from FreeBSD sends the machine's hostname along with the request, I use it to couple DHCP and DNS (the ISC DHCP server registers the IP address and hostname with BIND's named). There's no reason why the MS AD/DNS/DHCP can't do the same. It's just a matter of configuring it that way.

I thought it might be something to do with Kerberos and Active Directory

Nope. You would need those if you want to use an active directory account to login on a FreeBSD or Linux machine. Then you need to register the machine in active directory to make that work ( net ads join ...).

Is it possible to analyze what is the difference between OpenBSD and FreeBSD networking here, to try to get the hostname registered?

Sure, just run tcpdump(1) and capture the DHCP request and responses. Then look for the differences (if there are any).

When installing OpenBSD in the bhyve, I think I saw some blue letters noticing an «ack!» had happened, but I took no futher not of it. It might be that ack ...

It's probably just the acknowledgement the DHCP request was successful.

 

[rusma]

Hey SirDice! Thanks for replying.

I'd check with the maintainers of the AD/DNS/DHCP. It's likely they've used a specific setting there.

No, I don't think so. I'm an analyst that is allowed to work using Linux (and FreeBSD) there (in a Windows only environment), but then I cannot ask about anything, because the IT department only uses Windows, which I think is such a bummer. I'm on my own here, which I think is a fairly normal way of living for many BSD people ...

A "normal" DHCP request from FreeBSD sends the machine's hostname along with the request, I use it to couple DHCP and DNS (the ISC DHCP server registers the IP address and hostname with BIND's named). There's no reason why the MS AD/DNS/DHCP can't do the same. It's just a matter of configuring it that way.

I looked into the /etc/resolv.conf of the OpenBSD bhyve instance. It does a lookup file bind and search on the ad.company.com domain. I thought that might be the additional thing that is happening. But it also seems to simple ... I wish it was that simple ...

Nope. You would need those if you want to use an active directory account to login on a FreeBSD or Linux machine. Then you need to register the machine in active directory to make that work ( net ads join ...).

Thanks for that explaination. It is something unneccessary at this point, I think. So not something I would do ...

Sure, just run tcpdump(1) and capture the DHCP request and responses. Then look for the differences (if there are any).

I have not done it before ... Could I just run tcpdump on the tap1 and tap2 interfaces of the debian and obsd instances ... Do you know of a way to do some filtering on types of dumps here in case a ton of lines is going to fly by?

 

[SirDice]

I'm an analyst that is allowed to work using Linux (and FreeBSD) there (in a Windows only environment), but then I cannot ask about anything, because the IT department only uses Windows, which I think is such a bummer. I'm on my own here, which I think is a fairly normal way of living for many BSD people ...

I constantly work in environments where it's a mix of Windows and Linux servers, of course you can ask Windows admins these questions, DNS and DHCP have nothing to do with the OS. They're common network protocols that are used by all sorts of different operating systems.

I looked into the /etc/resolv.conf of the OpenBSD bhyve instance. It does a lookup file bind and search on the ad.company.com domain. I thought that might be the additional thing that is happening. But it also seems to simple ... I wish it was that simple ...

That file has nothing to do with DHCP, only with the way DNS requests on that system is done. It actually gets that information from DHCP in most cases. A DHCP offer usually has one or more DNS servers the client can use and some domain or search specific options. This just tells the client how and where to send their DNS requests to. However this has nothing to do with the registration of the hostname and IP address of said client in DNS.

Do you know of a way to do some filtering on types of dumps here in case a ton of lines is going to fly by?

Lookup how the DHCP protocol works. It starts off by sending a broadcast to port 67 (DHCP request). The DHCP server picks this up and will respond with a DHCP offer message. Then you will get a few more back and forth messages between the client and the server to negotiate the offer. There's a fairly simple but clear explanation in the DHCP wikipedia article.

Packet captures made with tcpdump(1) (-w option) can be read by tools like Wireshark, that'll make it easier for you to analyze the actual packet contents. It will do a lot of the decoding for you.

 

[rusma]

Hello! By comparing the tcpdumps on port 67 and 68, I thought it might be the Parameter-Request Option 55 that is the important difference between the OpenBSD and Debian clients?

OpenBSD bhyve instance:

    Parameter-Request Option 55, length 11:
        Subnet-Mask, BR, Time-Zone, Classless-Static-Route
        Default-Gateway, Domain-Name, Option 119, Domain-Name-Server
        Hostname, BF, TFTP

Debian bhyve instance:

    Parameter-Request Option 55, length 11:
        Subnet-Mask, BR, Time-Zone, Default-Gateway
        Domain-Name-Server, Option 119, Netbios-Name-Server, Netbios-Scope
        MTU, Classless-Static-Route, NTP

A colleagues Windows machine:

    Parameter-Request Option 55, length 14:
        Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name
        Router-Discovery, Static-Route, Vendor-Option, Netbios-Name-Server
        Netbios-Node, Netbios-Scope, Option 119, Classless-Static-Route
        Classless-Static-Route-Microsoft, Option 252

I split and reshaped those lines into this table to compare it in an easier way:

Parameter-Request Option 55	obsd	debian	MSFT 5.0
Subnet-Mask	x	x	x
BR	x	x
Time-Zone	x	x
Classless-Static-Route	x	x	x
Default-Gateway	x	x	x
Domain-Name	x		x
Option 119	x	x	x
Domain-Name-Server	x	x	x
Hostname	x
BF	x
TFTP	x
Netbios-Name-Server		x	x
Netbios-Scope		x	x
MTU		x
NTP		x
Router-Discovery			x
Static-Route			x
Vendor-Option			x
Netbios-Node			x
Classless-Static-Route-Microsoft			x
Option 252			x

How can I make the client use the Domain-Name option? Also, perhaps BF and Hostname are important?

 

[SirDice]

The domain-name just requests in what domain the machine is in. The DHCP server will respond with an appropriate domain, that's then stored in /etc/resolv.conf (domain). It's used when requesting so-called 'short' names with DNS. For example, if the domain is example.com and I want to ping myhost (short name), DNS will query for a host called 'myhost.example.com'.

A hostname can be requested from DHCP too, this is mainly used for things like diskless systems that don't know their own hostname when booting. As the hostname is typically already configured it's sent to the DHCP server. In my setup for example that hostname is used by the DHCP server to register that host in DNS.