Men & Mice Community

AndrewGillies wrote:

Carsten, thank you again, for both the explanation and example.

When I attempt to add the @ A 70.168.75.5 record through the web interface I am met with the error: Illegal Record Name, and am unable to save the changes.

Hello Andrew,

the "@" sign is what appears in the zone file on disk, in the Men & Mice GUI or Web-UI you type in either the name of you zone, or leave the name field empty (the name of the zone is then filled in).

Best regards

Carsten Strotmann
Men & Mice

AndrewGillies wrote:

I currently have the following entered for the website:

Name: www, Type: A, Data: 70.168.75.5

What would the correct record be to access the site without the www?

I guess what one of the things I don't understand is what "the zone name (@)" means in your response.

Hello Andrew,

for solution 1) you remove the record
Name: www, Type: A, Data: 70.168.75.5

and then you enter

Name: @, Type: A, Data: 70.168.75.5
and
Name: www, Type: CNAME, Data: @

Every zone has a zone name. For example the zone "menandmice.com" has the zone name "menandmice.com". In domain names in a zone, the zone name can be either typed in as a normal name, or there is a special "macro" type character in DNS zone files, the "@". The "@" char in a zonefile gets expanded to the so called origin of the zone. By default (unless re-defined in the zone with an $ORIGIN statement), the value of this origin is the name of the zone. So where you write the name "@", this will be replaced by the name of the zone internally.

If you name of the zone is "example.com", you can also write:

Name: example.com., Type: A, Data: 70.168.75.5
and
Name: www.example.com., Type: CNAME, Data: example.com.

For solution 2, you keep your existing A record for "www" and you add another address (A) record for
Name: @, Type: A, Data: 70.168.75.5

-- Carsten

jcgalvez wrote:

Copy and Paste this config (Option 1)

@ IN NS ns2.domain.org.
@ IN NS ns4.domain.org.
mail IN CNAME @
ftp IN CNAME www
@ 300 IN MX 20 @
www IN A 10.10.10.10 ;webserver
@ IN A 10.10.10.10 ;mailserver

(Option 2) simple one single server.

@ IN NS ns2.domain.org.
@ IN NS ns4.domain.org.
@ 300 IN MX 20 @
mail IN CNAME @
ftp IN CNAME @
www IN CNAME @
@ IN A 10.10.10.10 ; single web, ftp, mailserver

One note on this:

A MX-Record should always point to a name (on the right side of the MX) that resolves to an direct A or AAAA record. It should not resolve to a CNAME.

It is correct in the example above (the MX record points to the zone name, which has an direct A-Record).

However there is a CNAME entry for the name "mail". That name should not be used on the right side of an MX record, as it is a CNAME and not an address record.

The reasons for this is that there is mail software deployed in the Internet that does not work correctly with CNAME. Also see RFC 1912 for details.

The same rule holds true for NS records. the right side name of an NS record should always resolve to a direct A/AAAA record.

Hello Javier,

I've send a personal mail (PM) on the topic.

AndrewGillies wrote:

would the name of the cname record be domain.org pointing to www.domain.org?

My initial thought was to leave the cname name blank and point it to www.domain.org, but thats not acepted

A CNAME must always have a unique name, it is not allowed to have any other record (except DNSSEC RRSIG) with the same domain name as the CNAME record.

A CNAME record with an empty owner-name in a zonefile would have the name of the zone. There is always one SOA record and at least one NS record (one per autoritative name server) for the zone name, so that CNAME would not have a unique name. See section 2.4 of RFC 1912 (ftp://ftp.rfc-editor.org/in-notes/rfc1912.txt).

There are two possible solutions:

1) the address record (A/AAAA) on the zone name (@) and have the CNAME for "www" point to that name. This is what Javier suggested.

2) two address (A/AAAA) records, one for the zone name (@), one for the "www" name, both pointing to the same IP address.

both work fine. Solution number 2 usually would create two PTR records for the IP address, pointing to the different names. This solution should not be used if the machine is also a mail server, as the PTR for a mail server must be unique.

-- Carsten

To question 1: DNS maps names to addresses, but it is not possible to map addresses to other addresses.

You can have multiple names that map all to the same IP Address, so you can have different names for "websites" that all point to the same webserver.

in zone "example.com":
www.example.com. IN A 192.0.2.10

in zone "example.org":
www.example.org. IN A 192.0.2.10

A HTTP 1.1 complient webserver can then serve different content (webpages) based on the domain name used by the URL and send in the HTTP 1.1 header.

Translating "one public IP Address" to "multiple private IP Addresses" is outside the scope of DNS. DNS just returns a IPv4 or IPv6 address for a name.

It is possible to deploy a so called "reverse http proxy" system on the public IP Address that then dispatches the requests to multiple private IP addresses based on the domain-name in the http request. A reverse http proxy can be build with the Apache webserver or the NGNIX webserver. However care must be taken so that the reverse http proxy is not the single point of failure (usually some kind of load-distribution/fail over system).

See
http://en.wikipedia.org/wiki/Reverse_proxy
for more information on reverse proxy implementations.

I first try to answer question 2:

Aliasing a whole domain would be possible with the DNAME Record (RFC 2672), but that needs to be done on the parent delegation point (in your example that would be on the .ORG level. That is usually not possible. Also, DNAME is not implemented in all resolvers out in the Internet.

If both "dns zones" are stored on the same BIND DNS Server, there are two options:

on the filesystem level, link the zonefile of the 2nd zone with a hardlink or a softlink onto the file of the 1st zone

im the zones options, after creating the 2nd zone, edit the "file" statement to point to the zonefile of the 1st zone.

Starting from Men & Mice Version 6.1 onwards, this can be done from the Management GUI Console. In older versions, it can be done on the commandline of the DNS Server. Don't forget to do the same "trick" on each secondary server.

In the Men & Mice Suite, you should then adjust the access permissions of the 2nd zone to be "read only".

ISC asked BIND users to vote for the mascor of the new BIND 10 nameserver:

http://www.isc.org/announcement/vote-your-favorite-bind-10-mascot

Hurry, polling closes on September 3rd.

Hello citizen7,

there seems to be some fundamental issue with the machine (like harddisk full or harddisk defekt).

The Men & Mice System does not prevent the webserver to start. It loos more that something is wrong which stops both the webserver and the Men & Mice System from functioning.

This message indicates
Jul 22 15:55:20 ns1 Men and Mice Central[215]: Login: user info for "admin" not found

that the Men & Mice Central cannot find the user information for "admin" in its database. Maybe the database is corrupted or not readable.

Can you check the webservers error log to see why the webserver does not start:
Jul 22 16:10:30 ns1 servermgrd: servermgr_web: Could not start httpd. Check httpd error log..

I'm not sure from which service this message is, it is not Men & Mice related, but might be another service that fails on the system:
Jul 22 15:15:07 ns1 ARDAgent [355]: ValidDHEXAdmin unexpected error -14136

Best regards

Carsten Strotmann

citizen7 wrote:

I upgraded our server to 10.4.11 and everything seemed to be working fine. Web sites came up without problem. I thought...GREAT!....IT WORKED!

2 DAYS LATER..........OOOOOPS!

Our Men and Mice DNS Server which sits on the same machine as the webserver is no longer functioning. NO WEBSITES WORK!

I have tried to connect using the Men and Mice Management Console...but keep getting "Invalid username or password." I am using the 5.0.3 version of the Men and Mice Management Console on Mac OSX 10.5.6 booting up on an intel mac...MacBook Air!

I also cannot start the webserver and get the following messages in the console.log

Jul 22 14:33:43 ns1 Men and Mice Central[215]: Unable to locate the server "ns1.myserver.com.".
Jul 22 15:28:15 ns1 servermgrd: servermgr_dns: gethostname() doesn't match the configured name - use changeip to repair
Jul 22 15:55:05 ns1 Men and Mice Central[215]: Login: invalid password for user "administrator"
Jul 22 15:55:20 ns1 Men and Mice Central[215]: Login: user info for "admin" not found
Jul 22 15:55:36 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Jul 22 15:58:15 ns1 servermgrd: servermgr_dns: configured name and reverse DNS name do not match (reverse.abccompany.net != citizen2.myispcompany.com), various services may not function properly - use changeip to repair and/or correct DNS
Jul 22 15:58:15 ns1 servermgrd: servermgr_dns: gethostname() doesn't match the configured name - use changeip to repair
Jul 22 16:00:58 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Jul 22 16:06:46 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Jul 22 16:06:53 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Jul 22 16:07:19 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Jul 22 16:07:52 ns1 Men and Mice Central[215]: Login: user info for "Admin" not found
Can't load ///usr/standalone/i386/boot.efi
Error while getting file ID of /System/Library/CoreServices/boot.efi. Ignoring...
Jul 22 16:10:30 ns1 servermgrd: servermgr_web: Could not start httpd. Check httpd error log..

also

Jul 22 15:15:07 ns1 ARDAgent [355]: ValidDHEXAdmin unexpected error -14136

Should I be able to start the webserver without the Men and Mice DNS server working because I cannot start the webserver in the Server Admin?

Any help would be greatly appreciated.

thanks,

citizen7

keywerks wrote:

Hello Carsten,

thanks a lot for your reply. I did some tests in the meantime and figured out what happened. The trouble I have had was caused by the Mac OS X Server Server-Admin. Whenever MaM is installed MOSXS 10.6 and higher, you have to make sure to never touch the DNS entry, nor to save any changes the Server-Admin has made by just clicking on it. If you do so, MaM will stop responding or will not allow any zone transfers. Unfortunately it is not possible to remove the DNS entry from the Server-Admin panel in 10.6.x.

The only solution is to reinstall the MaM Server Controller and never touch the DNS entry again.

Maybe you and your colleagues will find a solution in the near future.

Best wishes,
Wolfgang Neikes

Hi Wolfgang,

the Men & Mice DNS Controller uses a special layout of the BIND DNS Server configuration files (documented in the User Guide). This layout is created when the DNS Server Controller is installed.

The MacOS X Server DNS Server Admin is not aware of this special layout and will write out a new file, basically destroying the configuration created by the Men & Mice DNS Server Controller.

I'm not sure what we can do about it, as the MacOS X Server Admin cannot be disabled to my knowledge. I will take a look at it.

Hello Wolfgang,

a DNS Server will only load a zone from a other DNS Server if the other DNS Server is signaling that it is authoritative for the zone.

This signalling is being done with the "AA" flag in the header of a DNS packet. We see the "AA" flag when using the "dig" tool (in the header, rigt of "flags"):

Code:

 $ dig @dns1.menandmice.com menandmice.com soa
 
 ; <<>> DiG 9.7.1-P2 <<>> @dns1.menandmice.com menandmice.com soa
 ; (1 server found)
 ;; global options: +cmd
 ;; Got answer:
 ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48769
 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 3
 
 ;; QUESTION SECTION:
 ;menandmice.com.			IN	SOA
 
 ;; ANSWER SECTION:
 menandmice.com.		86400	IN	SOA	dns1.menandmice.com. hostmaster.menandmice.com. 2010050501 900 300 604800 900
 
 ;; AUTHORITY SECTION:
 menandmice.com.		86400	IN	NS	ns0.c.is.
 menandmice.com.		86400	IN	NS	ns1.c.is.
 menandmice.com.		86400	IN	NS	ns2.c.is.
 menandmice.com.		86400	IN	NS	dns1.menandmice.com.
 
 ;; ADDITIONAL SECTION:
 ns0.c.is.		54608	IN	A	213.176.128.100
 ns1.c.is.		54608	IN	A	193.4.194.100
 dns1.menandmice.com.	86400	IN	A	217.151.171.7
 
 ;; Query time: 75 msec
 ;; SERVER: 217.151.171.7#53(217.151.171.7)
 ;; WHEN: Thu Jul 22 15:45:34 2010
 ;; MSG SIZE  rcvd: 204

See error message your seeing on the DNS Server that is hosting the slave zone indicates that the master is not authoritative for this zone. This can have multiple causes, but most often it is an illegal character in the zonefile (such as a underscore). Or the zone is completely missing on the master. This is then marked in the logfile of the DNS Server hosting the master copy of the zone.

Hello Mike,

can you tell us what version of the Men & Mice software you are using? Is the Windows 2008 System a 32bit or 64bit system?

You can try to start the Men & Mice Central process in debug mode, that should print out the root cause of this issue:

Open a command line window, navigate to the Men & Mice Central installation directory, then start the Men & Mice Central with this line

Code:

 mmcentral.exe -debug -ll5

where the last parameter is two times the lowercase letter "L" and then the digit five (for Log-Level 5).

Hello Jason,

this might happen if the DNS Zone is an AD integrated zone, or is an special Microsoft infrastructure zone (used for Active Directory). If there is an AD running using the zone content, the AD Domain Controller will recreate certain records if they have been removed.

It might also be possible that another tool in your system is recreating the zones. If a zone appears, the Men & Mice suite will pick up the zone and will display it.

Please check the Event lo on your DNS Servers if there is a hint who or what is recreating the DNS Zones.

RIPE NCC together with ICANN has developed a useful reference sheet that lists the IPv4 and IPv6 Address types.

The document can be downloaded from the ICANN Blog page or from this formum page.

The OpenDNSSEC integration scripts send some debug messages with level "info" to the syslog system. The MacOS X syslog does not write these messages to a file (unlike Ubuntu Linux).

In order to see the Syslog messages, add the following line to your /etc/syslog.conf

Code:

 *.*                                                     /var/log/messages

then restart the Syslog service:

Code:

 sudo killall syslogd

Now the new file /var/log/messages can be monited with the "Console" Application. If you filter on "ods", you will see all OpenDNSSEC related messages.

The script below can be used to test the syslog system:

Code:

 #!/usr/bin/ruby
 # (c) 2009-2010 by Men & Mice
 # 2010.07.15 Carsten Strotmann
 # OpenDNSSEC Syslog Tester
 
 require 'syslog'
 
 Syslog.open('ods-test')
 
 Syslog.debug("Syslog debug message test")
 Syslog.info("Syslog info message test")
 Syslog.warning("Syslog warning message test")
 Syslog.err("Syslog error message test")
 Syslog.alert("Syslog alert message test")
 Syslog.emerg("Syslog emergency message test")
 Syslog.crit("Syslog critical message test")
 
 Syslog.close