Tag Archives: dns

Perfect DHCP configuration for Solaris

4 Replies

I've already posted on configuring DHCP + Dynamic DNS for some operating systems.

I still claim that that's the only way to go for dynamic, trusted networks.

So after RedHat, Debian/Ubuntu, Windows, it's about time to stop the IP suffering with Solaris as well:

  1. Make sure /etc/nodename contains the FQDN, e.g. "snoopy.ac.uk"
  2. touch /etc/dhcp.<interface name> . There are two peculiar parameters I'm not fully sure about their meaning (how come they're not needed in other OSes?) - but here is what I used:
    1. add "primary" (a separate line) if it's the primary interface.
    2. Add "wait <seconds>" (a separate line) - I put "wait 60" to be on the safe side.
  3. /etc/hostname.<interface name> should have the hostname inside. NOTE! It's the hostname dhcp client would send (Option 12) to the server for Dynamic DNS registration. According to /etc/defaults/dhcpagent, the format is "inet name", e.g. "inet snoopy"

That should be it, then. Please add your comments and corrections.

Make DHCP auto-update the DNS

8 Replies

Update: added a new post on configuring Solaris, link below.

Motivation

In today's dynamic R&D network environments, it's not easy to keep the DNS records up-to-date: hosts are reinstalled/renamed/added frequently, virtual machines are so easy to deploy and destroy, DHCP allocates different IPs..

This even leads to pitiful situations, in which people get used to referring to computer by their IPs (or using /etc/hosts), because the DNS cannot be trusted to reflect the reality.

Solution

DHCP servers have the ability to send dynamic DNS updates, as they allocate IPs to clients. The great thing, is that it even works out-of-the-box on some operating systems. Still, if it doesn't, here are 3 things to care about, so to enable this feature: Continue reading →

DNS SRV records (or: why Google Talk doesn't connect through this network)

5 Replies

[ There is some blabla here about SRV records, See last paragraph for the direct solution ]

Recently, the bus home was replaced with a shiny new one, which also provides Wi-Fi access. That's brilliant - as long as I have a seat, I don't mind how long the ride home takes. I just hope it doesn't radiate too much =)

Anyway, I've noticed that I fail to connect to Google talk through my favorite client, Pidgin, when connected to this Bus' wireless LAN. It's really fun to do some debugging with xterm and wireshark with passengers watching with curiosity.

And to the point - I'm not sure where this standard is defined (XMPP?), but Google recommends setting the Google Talk "domain" as gmail.com. But where is the XMPP server ip/name taken from? It's not gmail.com, as the telnet gmail.com 5222 fails.

Quick sniffing tells that my pidgin (and probably other clients) use DNS SRV records. SRV records (RFC2782) are a pretty neat idea: it lets you query your domain for services. Why remember (or worse: guess) what's the name of the SMTP server? Instead, SRV records suggest a way to ask a domain what's the IP of the domain's major SMTP service.

The DNS name is of the following structure: _<service name>._<protocol>.domain.

In our case: _xmpp-client._tcp.gmail.com. Let's run this nice command line:

# host -t SRV _xmpp-client._tcp.gmail.com

_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk2.l.google.com.
_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk3.l.google.com.
_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk4.l.google.com.
_xmpp-client._tcp.gmail.com has SRV record 5 0 5222 talk.l.google.com.
_xmpp-client._tcp.gmail.com has SRV record 20 0 5222 talk1.l.google.com.

So briefly, each SRV record holds host name, port number, priority and weight. A single service may have several records, thus providing some kind of high availability and load balancing.

SRV records are intensively used in Microsoft Domains since Windows 2000, and it's even possible that they invented it (they're signed in the RFC after some non-microsoft guy). In that case, kudos to Microsoft for either inventing or pushing forward a good technological standard. Haven't seen this frequently.

So, it seems that the DNS in this bus disrespects my SRV queries, and thus my Pidgin can't figure out who is the Google Talk server. Setting another DNS server solved the problem.

hostupd v0.92 is out: [DNS-updating helper tool]

2 Replies

Hostupd is a very simple perl script, which makes use of the Net::DNS module, to assist in updating DNS records dynamically.

Here's a sample hostupd command which adds both A and PTR records:

hostupd add myhost myip

on complex environments, it might not autodetect the zone and server ip:

hostupd add -s mynameserver -z myzone myhost myip

The the last commit took place on 2002 (when I was a perl newbie, it shows..). Today, 7 years later (wahhh!), I've found and fixed an annoying bug by a adding a single line.

A global ZoneEdit DNS update problem?

2 Replies

Update: Manually updating it in the web gui seems to fix the issue. I wonder if it's a temporary issue that was solved..

yet another an Is-it-just-me-or-is-it-a-global-problem? post:

A lightning had struck nearby and killed the power at around 03:00UTC. I've turned the computer back on at 09:22UTC (yes I know, I slept too much), and ddclient updated zoneedit.com with my new IP.

According to zoneedit's web gui, my IP got updated. But their DNS servers still give the old IP. (It's been 10hrs since my update, for it's 17:00UTC now)

I mailed their support, no reply yet (I'll update in this post, when there's news). Is anybody else experiencing the same problem?

14hrs without a functioning mail. Everything is so quiet and peaceful 🙂

DDClient: Problem updating Zoneedit

10 Replies

I use Zoneedit for DNS "hosting". They give great, free service, with additional features at small costs.

For updating my Dynamic IP, I use the DDClient script (supports zoneedit, dyndns.org and many other providers)

A few days ago (according to my logs: 30/05/08 18:15:00 UTC) DDClient stopped updating my IP in Zoneedit. Apparently Zoneedit changed the URL, and ddclient.conf should be updated accordingly:

server=www.zoneedit.com

should become

server=dynamic.zoneedit.com

It probably hurt many users.. I hope I didn't lose too many emails =)

Update: I notified ddclient developers and it was fixed (in SVN only currently).

Update 2: According to wimpunk (ddclient developer), the "server=www.zoneedit.com" can be simply commented-out from ddclient.conf (it's an optional parameter!); when commented-out, default already uses the correct address (dynamic.zoneedit.com), even in 3.7.3 or earlier.