Sender verify failed with incorrect reverse DNS record

Posted on By Mark Wilson
This content is 18 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

What a week! Switching hosting providers, setting up a new content management system for this blog (more on that as soon as it’s ready) and all at the same time as suffering e-mail problems as, since the middle of the week, every e-mail that I’ve sent to a particular contact has bounced back with the following message:

This is an automatically generated Delivery Status Notification.

Delivery to the following recipients failed.

someone@somewhere.net

Reporting-MTA: dns;mymailserver.markwilson.co.uk

Final-Recipient: rfc822;someone@somewhere.net
Action: failed
Status: 5.5.0
Diagnostic-Code: smtp;550-Verification failed for <myalias@markwilson.co.uk>
550-No Such User Here
550 Sender verify failed

I have various anti-spam measures on my mail server, but this appeared to be a problem when sending mail to a particular external host – e-mail sent to the same contact via a different mail server was received with no problems.

I set about researching the 550 Sender verify failed message and found various suggestions as to what might cause such an error – the most useful of which was a message on a newsgroup post which suggested it may be caused by an incorrect reverse DNS (PTR) record (thanks to Ben Winzenz for replying to that group a couple of years ago).

Even though much of my mail was being delivered successfully, that seemed like a perfectly reasonable explanation – the reverse lookup for my IP address would have returned a hostname in the format username.myisp.co.uk, rather than mymailserver.markwilson.co.uk (as confirmed by a DNS report on my domain, which also commented that “RFC1912 2.1 says you should have a reverse DNS for all your mail servers. It is strongly urged that you have them, as many mailservers will not accept mail from mailservers with no reverse DNS entry”), so I set about getting the record updated by my ISP (it has to be done by the owner of the IP address block).

Initially I asked my ISP to add my mail server’s DNS name as a second PTR record for my IP address but in practice I found that DNS responded in a round robin pattern (rather than returning all the matching records) so I couldn’t rely on a consistent response and was still experiencing mail delivery failures. Finally, after reverting to a single PTR record for my IP address and waiting for DNS propagation (again), I was able to successfully send e-mail to the contact with whom I’d previously experienced issues (phew!).

As more and more hosts take action to prevent unsolicited commercial e-mail (UCE – also known as spam), this is likely to be a more common occurrence and it just underlines how important a correct DNS configuration is.

DNS and operations master roles placement with Active Directory

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I had a call last night from a client who is implementing Active Directory (AD) in his organisation and was trying to resolve some replication issues. Like so many problems in AD the issue was related to the DNS configuration and once I had made a few configuration changes on the DNS servers to build a forwarding hierarchy from the remote sites to the head office and then on to the ISP, everything started to work.

Whilst I was looking over his domain I also noticed that there was only a single global catalog (GC) server – the first domain controller that he’d installed (the same DC that was holding all the operations master roles, although in his single domain forest the co-hosting of the infrastructure master and GC roles will not cause problems with phantom indexes as described in Microsoft knowledge base article 248047).

Microsoft knowledge base article 825036 describes best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003 whilst Microsoft knowledge base article 223346 discusses the placement and optimisation of operations master roles.

Migrating SMTP e-mail from my ISP’s servers to an internally-hosted Exchange server

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Over the last couple of days, I migrated my e-mail service to Microsoft Exchange Server. I’ve been meaning to do this since I first bought my own domain name in the late 1990s but a lack of suitable hardware to dedicate to the task has meant that until now it’s been easier to leave the service with my ISP and download it to Outlook using POP3. Using virtualisation technology has enabled me to build an e-mail infrastructure without using any extra hardware.

Phase 1 of the project was installing the mail service and connecting to my ISP’s servers. I wanted to use Microsoft Exchange Server 2003 but for various reasons I didn’t want to extend the schema for my Active Directory (AD), so I created a separate resource forest with an outgoing trust to the original domain and installed Exchange Server there. Following this, I was able to create disabled user accounts and associate the mailboxes with external accounts in the original forest, allowing me to authenticate to my mailbox in the resource forest using my normal account credentials from the original domain (as described in Marc Grote’s article on the MSExchange.org site, although assigning the external associated account is now much simplified using the Exchange Task wizard).

Next, I needed to tell my ISP’s servers to allow messages for my domain to be routed to my server. The ADSL connection that I use is not associated with my domain but it does have a static IP address (an alternative is to use a dynamic DNS service), so after opening up TCP port 25 on the firewall to allow inbound SMTP traffic I created two DNS records for each domain that I own:

  • Host (A) record to define a server name that resolves to my IP address.
  • Mail exchanger (MX) record for the domain that resolves to the A record created previously.

With the appropriate DNS records in place, that was all the configuration needed at the ISP’s end, but Exchange still needed to be configured to forward e-mail to the ISP’s SMTP relay – easily accomplished using the Exchange Server 2003 Internet Mail Wizard. The important thing to be sure of is that the server is not configured as an open relay (recent versions of Exchange Server lock this down by default). Once the SMTP connection was in place, e-mail started to flow (although for a while some mail was still being delivered to my ISP’s servers until the DNS entries had completely propagated around the Internet).

DNS Stuff is a mine of useful information, so I ran a DNS report on my domain name. This turned up various warnings about my ISP’s DNS configuration (which I can’t really do much about) but also a warning that my server’s SMTP greeting included an non-existent host name (the internal DNS name for the Exchange server):

220 hostname.internaldnsdomainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 12:30:31 +0100

According to the warning, if the server sends e-mail using a non-existent host name in its EHLO or HELO, e-mail could be blocked by anti-spam software, as well as being a technical violation of RFC 821 section 4.3 and RFC 2821 section 4.3.1.

A spot of Googling turned up a forum post on changing the SMTP greeting which pointed me in the direction of Microsoft knowledge base article 266686, allowing me to change the fully qualified domain name for the SMTP virtual server so that the SMTP greeting now reads as follows:

220 mailserver.domainname Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at Thu, 25 May 2006 13:18:44 +0100

Note that the hostname given in the SMTP greeting doesn’t have to be precise – it doesn’t matter that the SMTP server may handle e-mail for multiple domains (as mine does), as long as the host name given resolves to the correct IP address.

Phase 2 of the project will be to configure the intelligent message filter for Exchange Server 2003 (included as part of Exchange Server 2003 service pack 2) and hopefully cut out most of the spam that I receive (as the volume of spam hitting my server is much greater than the previous levels which were mostly handled by the Outlook junk e-mail filter). I’ll also be looking at enabling RPC over HTTP (see Microsoft knowledge base article 833401) to allow Outlook to access my mail servers using HTTP from behind my employer’s firewall.

Redirecting web proxy access when the server name changes

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Despite the problems I experienced migrating from Proxy Server 2.0 to ISA Server 2004 last night, I did have some success using a little DNS trickery to avoid changing the proxy settings on all clients (the new web proxy server has a different name to the old one). Here’s how it works:

  1. In DNS, delete the original host address (A) record for the old server.
  2. Next, create a host address record for the new server and an alias (CNAME) record with the name of the old server, pointing to the fully qualified domain name of the new server.

All DNS lookups for the old server should be redirected to the new server (via the DNS alias), allowing the proxy settings in the web browser to be updated at leisure (of course, in an Active Directory environment, they could also be updated via group policy).

Configuring a Solaris 10 DHCP client to register with a Windows Server 2003 DNS server

Posted on By Mark Wilson
This content is 19 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week, I wrote about configuring a hostname for a Solaris 10 DHCP client. Alan Thompson very kindly left a comment on that post about using DHCP to set the hostname on the network (i.e. in the DNS) and I’m pleased to say that it works a treat on my Windows network.

I have a Windows Server 2003 server which acts as my domain controller, DNS server and DHCP server. DHCP is configured to update DNS (always dynamically update DNS A and PTR records, discard them on lease deletion, and to do this for clients that do not request updates) and this was working well for my Windows clients but although my Solaris client (laptop3) had been retrieving IP information from the DHCP server, the DHCP console showed no name for the lease (and so couldn’t update DNS).

By following Sun’s instructions for enabling a Solaris client to request a specific hostname, DHCP was able to register the client’s name in DNS, using the fully qualified domain name as set in the DHCP scope options (option 015 DNS Domain Name).

I tested this using the nslookup laptop3 command, which returned:

Server: dnsserveripaddress
Address: dnsserveripaddress#53

Name: laptop3.domainname
Address: laptop3ipaddress

It’s worth pointing out that Sun’s instructions are not quite correct for Solaris 10 x86, as step 1 is not necessary (the comments in the /etc/default/dhcpagent file explain that, by default, the DHCP agent will try to request the hostname currently associated with the interface performing DHCP); however the other steps were spot on (add inet hostname to /etc/hostname/interface, flush cached DHCP data using pkill dhcpagent and rm /etc/dhcp/ interface.dhc, then reboot), meaning that my Solaris client now participates in my Windows network name resolution.

Troubleshooting DNS on a Windows server

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Earlier today, I blogged about some of the tools that are available for monitoring Active Directory (AD) enterprise replication and troubleshooting Windows authentication. Given that AD is so heavily reliant on the domain name system (DNS), it seems logical that I also list some of the tools available for monitoring and troubleshooting DNS issues.

The first port of call is the Windows version of the original Unix DNS lookup tool (nslookup.exe). Typing nslookup at a command prompt enters the nslookup shell, from where issuing the help command will list all of the available options.

The DNS server troubleshooting tool (dnscmd.exe) is a support tool for Windows 2000 Server and Windows Server 2003 (available on the Windows installation media) which allows administration of DNS from a command prompt. It extends and replaces the earlier dnsstat.exe tool provided as part of the Windows NT resource kit. The DNS server troubleshooting tool displays and changes the properties of DNS servers, zones, and resource records, manually modifying properties, creating and deleting zones and resource records, and forcing replication events between DNS server physical memory and DNS databases and data files. Some operations of the tool work at the DNS server level while others work at the zone level. Simply type dnscmd for usage information.

DNS has its own set of performance counters available under the performance monitor DNS object.

The domain controller diagnostic tool (dcdiag.exe) checks DNS functionality as part of its diagnostic tests but the command to specifically test DNS registration (which does not need to be run from a domain controller) is dcdiag /test:registerindns /dnsdomain:domainname.

The network connectivity tester (netdiag.exe) helps to isolate networking and connectivity problems by performing a series of tests to determine the state of a network client to identify and isolate network problems. Parsing the output for “DNS test” will give DNS-specific results. Type netdiag /? for usage information.

DNS debug logging may be set in the DNS server properties and creates a log file at %systemroot%\system32\dns\dns.log for further diagnosis of DNS activity.

Finally, the dnslint.exe support tool allows verification of DNS records for a specified domain name to help diagnose potential causes of incorrect delegation and other common DNS problems, producing an HTML report. Usage information can be obtained by issuing the dnslint /? command.