3 posts tagged with "DHCP"

When people say "dynamic DNS", they often mean two different things. One is the home broadband pattern where a firewall tells a public DNS provider that its internet address changed. The other is the enterprise pattern where a host gets a lease from DHCP and then its name shows up in internal DNS a few seconds later. This post is about the second one.

The short version is simple: DHCP doesn't magically write to DNS. A client or a DHCP server sends a normal DNS UPDATE message to the authoritative DNS server, and a set of RFCs decides who is allowed to do it, what gets written, and how collisions are handled. The clever bit is not the packet. It's the ownership model around the packet. RFC 2136 defines the DNS update opcode, RFC 4702 and RFC 4704 define how DHCP negotiates update responsibility, and RFC 4701 plus RFC 4703 define the ownership token that stops one client from trampling another.

Infoblox have since resolved this and I have tested it successfully.

I wanted to settle down today in a particularly dull meeting and have a go at setting up an Infoblox NIOS instance in Azure using the Azure Marketplace offering. I have used Infoblox in anger before and I know it is a solid product so I was keen to get it up and running in the lab so that I could have a play with the Anycast DNS features with Azure Route Server.

I'm working on a DHCP migration and discovered the previous admins didn't clean up old scopes when sites closed. It's hard to identify dead scopes from lease numbers since some live sites are rarely used. So I've created a simple script to ping the default gateway to check if the subnet still exists.