Time and Date Issue and mDNSResponder and configd messages

The date was set to December 31, 2000. When I clicked on the calendar at the bottom of the screen, I saw the following window:

I clicked on Open Date & Time and changed the date from December 31, 2000 to today's date and the time from 7:15 P.M. to the current time. I had to first uncheck "Set date and time automatically." The time servers listed were ntp.mydomain.com, time.apple.com

I then closed the window and saved the time changes.

I also saw two windows open with messages about programs needing permissions for incoming messages. The first was mDNSResponder.

I then saw a window open with a similar message for configd.

I found someone reporting the same messages regarding configd and MDNSResponder at mdnsrespnder and configd. His system was running Mac OS X Leopard, i.e. version 10.5; the laptop I was using has Mac OS X Snow Leopard, specifically version 10.6.8, on it. Someone responding to the poster, stated that the problem occurred for him after he removed the battery from his G4 Powerbook to clean the screen and keyboard. Others alo posted that they had the problem after the battery in their systems died. As others mentioned, my laptop wasn't establishing a connection to the available wireless network as it had previously.

I also found someone reporting the exact problem I encountered with the date and time issue and the configd and mDNSResponder messages at mdnsresonder and configd??. A responder there stated that the problem can occur when new items are added to the firewall list.

I searched the system's hard drive to locate the two programs referenced in the messages about incoming connection. Note: don't expect Finder to find them if you try searching for them with it.

$ sudo find / -name configd
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
/usr/libexec/configd
$ sudo find / -name mDNSResponder
Password:
find: /dev/fd/3: Not a directory
find: /dev/fd/4: Not a directory
/private/var/run/mDNSResponder
/usr/sbin/mDNSResponder

I didn't respond to the two windows asking whether configd and mDNSResponder should be allowed incoming connections. In my case, I simply rebooted. When I logged in again, I didn't see the messages and the date and time remained correct (I had the laptop plugged into a wall outlet). I was able to establish my wireless network connection as I normally could.

I reset the Date & Time preferences to use Network Time Protocol (NTP) servers again by clicking on the Apple icon at the top left-hand corner of the screen, then selecting System Preferences, Date & Time, clicking on the lock icon to make changes, and then rechchecking "Set date and time automatically."

I checked the system's firewall settings by going to System Preferences, Security, which is beneath the Personal section of System Preferences, clicking on "Click the lock to make changes", then clicking on the Advanced button. I didn't see configd nor mDNSResponder in the list of applications allowed to accept incoming connections.

But the "Automatically allow signed software to receive incoming connections" checkbox was checked.

The firewall in Mac OS X 10.5.1 and later is an application firewall, i.e. connections are allowed and diallowed by application rather than port number.

I checked the security certificates for both the configd and mDNSResponder applications to verify that they were Apple applications. Apple, like other companies, such as cell phone companies and video game console companies, provides a mechanism for software developers to "sign" software they have developed to verify it was created by them and hasn't been modified subsequently by malware since it was created. If you are interested in how code signing works for software deployed on Apple systems (the process is similar for other systems), I'd refer you to the following webpages:

• Code Signing - Get Used to It!
  Digitally signed applications and you
  By: Scott Corley
  MacTech
• Real Security in Mac OS X Requires Apple-Signed Certificates
  By: Wil Shipley
  Date: November 3, 2011
  Call Me Fishmeal

To check the signatures for applications, you can use the codesign utility by getting a shell prompt, which you can do by running the Terminal application found under Applications/Utilities. You can use codedesign --display --verbose application to get details about the certificate for an application.

$ codesign --display --verbose /usr/libexec/configd
Executable=/usr/libexec/configd
Identifier=com.apple.configd
Format=Mach-O universal (i386 ppc7400 x86_64)
CodeDirectory v=20100 size=1186 flags=0x0(none) hashes=54+2 location=embedded
Signature size=4064
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=104

The identifier of com.apple.configd shows the application was developed and signed by Apple.

You can obtain additional details, i.e., more verbosity, by using -verbose twice or by using -vv (-v can be used in place of --verbose)

$ codesign --display --verbose --verbose /usr/libexec/configd
Executable=/usr/libexec/configd
Identifier=com.apple.configd
Format=Mach-O universal (i386 ppc7400 x86_64)
CodeDirectory v=20100 size=1186 flags=0x0(none) hashes=54+2 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=104

The signer's information for mDNSResponder also shows the developer of the application is Apple itself. Note: the /private/var/run/mDNSResponder file is a socket file created by the application and so is not signed. The application itself is at /usr/sbin/mDNSResponder

$ codesign --display -vv /private/var/run/mDNSResponder
/private/var/run/mDNSResponder: Operation not supported on socket
$ ls -l /private/var/run/mDNSResponder
srw-rw-rw-  1 root  daemon  0 May  3 11:26 /private/var/run/mDNSResponder
$ codesign --display -vv /usr/sbin/mDNSResponder
Executable=/usr/sbin/mDNSResponder
Identifier=com.apple.mDNSResponder
Format=Mach-O universal (i386 ppc7400 x86_64)
CodeDirectory v=20100 size=2732 flags=0x0(none) hashes=131+2 location=embedded
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist=not bound
Sealed Resources=none
Internal requirements count=1 size=108

An example of an application signed by a third-party developer is the Adobe Acrobat Reader application (the -vv option provides information about the signing "Authority").

$ codesign --display -vv "/Applications/Adobe Reader.app"
Executable=/Applications/Adobe Reader.app/Contents/MacOS/AdobeReader
Identifier=com.adobe.Reader
Format=bundle with Mach-O thin (i386)
CodeDirectory v=20100 size=205 flags=0x0(none) hashes=4+3 location=embedded
Signature size=3701
Authority=Adobe Systems, Incorporated
Authority=VeriSign Class 3 Code Signing 2009-2 CA
Authority=
Signed Time=Apr 4, 2012 3:10:16 AM
Info.plist entries=26
Sealed Resources rules=4 files=364
Internal requirements count=1 size=188

If an application isn't signed, codesign will report something like "code object is not signed." Note: if you haven't identified the name and location of an application correctly, you will see "cannot find code object on disk."

$ codesign --display -v /Applications/Firefox.app
/Applications/Firefox.app: code object is not signed

I am surmising that the reason I saw messages about allowing configd and mDNSResponder to run when the time was wrong that the signing time for the applications was after the December 31, 2000 date that the system had until I set the date to the current date.

What is the purpose of configd and mDNSResponder? According to Mac OS X: What Are All Those Processes?, which lists the functions of many processes running on Mac OS X systems:

 

Justdeals Daily Electronics Deals

Created: Thursday May 3, 2012