Issues in Using Secondary MX and Nameserver

[redr]

I'm currently testing the addition of Rollernet's services into my websites and have some "newbie" questions:

• 1. From what I understood, secondary MX (rollernet's MX) kicks in in the case that the primary MX server is offline. However, I still see mails being redirected to the secondary MX even if the primary MX is online, as listed in the mail logs. Is it normal for secondary MX to behave as such?

• 2. I tried using the secondary nameserver service to some of my domains but I see error messages in the logs, apparently about the difficulty of copying the information from the master nameserver:

  Code: Select all

  transfer of domain.com/IN from xx.xx.xx.xx#53: failed to connect: timed out
  transfer of domain.com/IN from xx.xx.xx.xx#53: end of transfer
  transfer of domain.com/IN from xx.xx.xx.xx#53: failed to connect: timed out
  transfer of domain.com/IN from xx.xx.xx.xx#53: end of transfer
  zone domain.com/IN: Transfer started.
  zone domain.com/IN: Transfer started.
  

  I tried contacting my host and they said that they do not allow AXFR transfers. Here is their reply:

  In a typical configuration, the primary server is configured to only allow the addresses of secondary servers to retrieve the zone file from it. Often, however, even these basic address-based authentication mechanisms are not provided and any user can grab the complete zone file for a particular domain using a tool like dig, which can trigger a zone transfer and retrieve this information using its AXFR function.
  
  Of course, advertising a complete directory service for every single host in a network is dangerous, but more dangerous still is when a domain is configured with more information than is even required to perform basic resolution. Sometimes hosts are named after people or ongoing projects, which are useful to attackers in determining the purpose of a system.
  
  This allows a malicious party to perform name-based reconnaissance with great ease. This serves as a first step to gaining information about a target network, and often leads to more in-depth scanning of what the attacker may perceive to be interesting targets.

  I don't get it: if AXFR transfer in dangerous, is there any other way to transfer zone information in-between servers? If my server doesn't allow AXFR transfers, does that mean I don't have any chance in using secondary nameservers?
  
  Another thing is: if AXFR tansfer is dangerous, why do all other services providing secondary nameservers use it?

[RollerNetSupport]

1. This is normal. Secondary MX doesn't have any status and it's always active. The decision about which MX to send to is made by the original sender's mail server.

2. Ah, the old AXFR is insecure argument. It is our position that AXFR is suitable for public use, but we strongly recommend using access lists to restrict who can request a transfer. However, some DNS servers do not have the ability to do AXFR, and providers that use it will often say "AXFR is a security risk" rather than "we chose broken software." Most software like BIND defaults to allow transfers to the world, but you can easily lock it down to your known secondaries like so:

allow-transfer { 208.11.75.3/32; 216.90.171.3/32; };

In this example, AXFR/IXFR requests would only be allowed from our ns1 and ns2 servers. There is no other standard way to do zone transfers. You may notice that our secondary nameservers can support further AXFR requests, but they will refuse them unless you configure the domain to allow them through our account control center. Ultimately, there is no other way to transfer zone information than by using AXFR. There are ways to move zone files between servers you control using something like rsync or DNS out of LDAP/SQL, but these methods are only suitable for internal use. The best you can do with AXFR is to lock it down by IP address. We only send AXFR requests to an IP you specify as the master, and we recommend our customers only respond to AXFR requests from our IP addresses. Is AXFR ultimately dangerous? Not really.

[RollerNetSupport]

Just to expand on the reasons why you might see mail go from source->secondary->primary rather than source->primary when the primary is operational:

* The source may not be able to reach the primary for any number of routing-related reasons, so it will try to reach the secondaries. If it can see a secondary and the secondary can see the primary when the source can't, it's successfully routed the message, possibly around a network outage somewhere.

* The primary may not have responded fast enough to the liking of the source, so it will consider the primary unavailable and try a secondary. A common cause may be if the primary is on a low bandwidth link - even broadband - and the link is fully utilized for any reason, such as a large download.

* Spammers may ignore the primary and only go for the secondary since most secondary mail servers have little to no spam filtering, thus increasing the chance their spam will make it through. (We offer filtering to close this hole.)

* If the DNS information for the primary recently changed (i.e. dynamic DNS or you moved the server, etc.) the source may still be trying to use the old information.

[redr]

Hey, thanks for the extensive explanations! Aside from answering my questions, they furthered what I know with regards to the services you're offering.

Regarding the AXFR issue, I tried sending a final bid to try my luck and they didn't budge. Just to clear, I don't believe that they had the "we chose broken software" case; they are just too conservative with the server's security protocols as they are operating a shared (reseller) environment. I offered the suggestion of whitelisting the IP's just in case but still they didn't think that it was secure enough. They told me that I can configure AXFR if I got a VPS or a dedicated server.

Oh well. Anyway, I was really planning to buy a VPS account soon and by then I think I would be able to utilize secondary nameservers.

Thanks again for the help!

[RollerNetSupport]

While we don't agree that AXFR is an outright security risk, if they're running a lot of stuff on the same server, it might be a cause for concern. Ultimately, the security implications of letting a specific IP access port TCP/53 for AXFR is a function of whatever nameserver they're using. We choose to mitigate this risk by running dedicated servers for DNS.

In the end, AXFR is no more secure or insecure than asking for an A or MX record on the same zone. DNS is public access information and should never be assumed to be secret. If someone wants to keep internal-only information in DNS, we recommend using a nameserver that only answers to the local network or views in BIND with similar local-only rules.