Re: MX Record Theories
On Wed, 27 May 2009 09:48:39 -0400, gb10hkzo-na...@yahoo.co.uk wrote: Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long records such as fc00:836b:4917::a180:4179. You do realize DNS queries aren't passing around addresses in ASCII? 3 additional bytes per address isn't going to break the bank. I think you might have missed the point of my post. It was a tounge in cheek reply to the poster who suggested bad things happen if the DNS message size exceeds 512 bytes. He was commenting about AOL's MX records which currently weigh in at 507 bytes. Therefore if we were to hypothesise that the world ends at 512 bytes, then companies doing things the way AOL does, but using IPv6 addresses rather than IPv4 addresses for their MX records could run into problems. Hope that clarifies :)
Re: MX Record Theories
Not entirely on subject but I thought that allowing DNS queries to occur via TCP is mission critical for simple mail routing. We ran across this back in the day at @Home Network. Firewall rules were changed to not allow port 53 TCP. This severely affected sending mail to large distribution lists. Here is what we found and forgive me if I don't go into too much detail as it was almost 10 years a go. If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. DNS by default starts with UDP which has a limit to the datagram size (64bit). A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. -BobbyJim On Tue, May 26, 2009 at 2:01 PM, valdis.kletni...@vt.edu wrote: On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-na...@yahoo.co.uk said: would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? The trick here is that it isn't always *exactly* the same goal. There's multiple mail system architectures and design philosophies. One often overlooked but very important design point for the *large* providers: % dig aol.com mx ;; ANSWER SECTION: aol.com.2805IN MX 15 mailin-01.mx.aol.com. aol.com.2805IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507 That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;)
Re: MX Record Theories
On May 28, 2009, at 5:04 AM, Bobby Mac wrote: If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. Well, it needs to resolve to an A RR somehow, but for each domain name, you get a different query. DNS by default starts with UDP which has a limit to the datagram size (64bit). The UDP minimum datagram size that must be supported by DNS implementations is 512 bytes. The maximum is 64K bytes. Obviously if you try to send a 64K byte packet, it's going to fragment and as we all know, fragments are bad. A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). If the response to a query won't fit in the UDP buffer (512 by default, although modern client implementations can advertise a larger buffer with EDNS0), the server will signal truncation in the response (with the TC bit), typically resulting in the client retransmitting the request via TCP. Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. IPv6 packets are a bit larger, but not that much. DNSSEC is where the fun starts. Regards, -drc
Re: MX Record Theories
In message c3de0a330905280804t56ca87dapd94281399202...@mail.gmail.com, Bobby Mac writes: Not entirely on subject but I thought that allowing DNS queries to occur via TCP is mission critical for simple mail routing. We ran across this back in the day at @Home Network. Firewall rules were changed to not allow port 53 TCP. This severely affected sending mail to large distribution lists. Here is what we found and forgive me if I don't go into too much detail as it was almost 10 years a go. As I said, sites just don't do this as it causes serious problems. Sites that disable TCP/53 outbound just end up re-enabling it. Nameservers and stub resolvers automatically retry with TCP and the client applications just don't get answers returned when you start blocking TCP/53 outbound. It doesn't take long for said stupidity to be reversed. If you add enough recipients to an email, each domain within the send line needs to have an associated MX record. DNS by default starts with UDP which has a limit to the datagram size (64bit). A flag is placed in the header which then requires the request to be sent via TCP (160bit V4). Now that single query can be split up into many different packets providing that the request is more than the 160 bit and obviously IPV6 offers even more information contained in a single packet. The number of recipients has no impact on the size of the DNS responses. It will have a impact on the number of DNS queries made iff the receipents are in multiple mail domains. Mark -BobbyJim -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: MX Record Theories
Mark, A EDNS referral from the root servers to the COM servers already exceeded 512 bytes. The world hasn't fallen over. Actually, I was thinking to myself yesterday that the email world is going to be awfully fun when IPv6 sets in and we're all running mail servers with nice long records such as fc00:836b:4917::a180:4179. :)
Re: MX Record Theories
I don't think there is no real answer for your question. It depends on each company's business objective, the cost, network topology, and their policy. MX record is the the mechanism for mail delivery procotol. It doesn't dictate how to implement. Depending on mail volume, and network policy, you can implement actual mail servers within DNS/SMTP protocol. There are multiple ways to get things done. Depending on budget, business objective, network resource/policy, you can choose the way that fits to your need. It is same as Microsoft Windows operating system. Microsoft release the Windows, but it doesn't say you have to run it as cluster or not. Depending on your need, and your own analysis/decision, you can run whatever you like. Alex gb10hkzo-na...@yahoo.co.uk wrote: Hello all, First, I hope this is not off-topic for NANOG, please be gentle with me as this is my first post. I would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? Do you have experience in more than one of these methods and which do you favour ? To illustrate my question : (1) If you query the MX records for, Hotmail or AOL you will receive 4 equal weight MX records, each of the MX records having a round-robin set of IPs. e.g. hotmail.com.2706INMX5 mx4.hotmail.com. hotmail.com.2706INMX5 mx1.hotmail.com. hotmail.com.2706INMX5 mx2.hotmail.com. hotmail.com.2706INMX5 mx3.hotmail.com. -and- mx3.hotmail.com.1926INA65.xxx mx3.hotmail.com.1926INA65.xxx mx3.hotmail.com.1926INA65.xxx etc.etc. (2) Alternatively, some people, particularly the ones that use hosted filtering, tend to have one MX record, which as multiple round robin IPs. e.g. microsoft.com.780INMX10 mail.global.frontbridge.com. -and- mail.global.frontbridge.com. 1728 INA65.xxx mail.global.frontbridge.com. 1728 INA207.xxx etc. etc. (3) And others simply have a more traditional setup using multiple MX records and only one IP per MX record with no round robin apple.com.931INMX10 mail-in14.apple.com. apple.com.931INMX20 mail-in3.apple.com. apple.com.931INMX20 eg-mail-in2.apple.com. etc.etc. So what's the big deal ? Please note I'm not asking which is better ... I am just curious and interested to hear your professional opinions and experiences. Personally, I favour the simple option 3, multiple MX records. Thanks y'all.
Re: MX Record Theories
On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-na...@yahoo.co.uk said: would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? The trick here is that it isn't always *exactly* the same goal. There's multiple mail system architectures and design philosophies. One often overlooked but very important design point for the *large* providers: % dig aol.com mx ;; ANSWER SECTION: aol.com.2805IN MX 15 mailin-01.mx.aol.com. aol.com.2805IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507 That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;) pgpVa3ctskTZ8.pgp Description: PGP signature
Re: MX Record Theories
On Tue, May 26, 2009 at 2:03 PM, gb10hkzo-na...@yahoo.co.uk wrote: I would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? Do you have experience in more than one of these methods and which do you favour ? apple.com.931INMX10 mail-in14.apple.com. apple.com.931INMX20 mail-in3.apple.com. apple.com.931INMX20 eg-mail-in2.apple.com. etc.etc. Use this when only the front server is fully capable of processing the mail into the domain. The other servers will have to hold some or all of the mail until the first server or its cold spare returns to service. Or perhaps the secondary servers are fully capable but undesirable for some other reason, such as slower hardware or older versions of the software. microsoft.com.780INMX10 mail.global.frontbridge.com. -and- mail.global.frontbridge.com. 1728 INA65.xxx mail.global.frontbridge.com. 1728 INA207.xxx Use this when you have multiple front-end servers any of which is fully capable of handling all messages entering the system. Free load balancer built into the protocol. hotmail.com. 2706 IN MX 5 mx4.hotmail.com. hotmail.com. 2706 IN MX 5 mx1.hotmail.com. hotmail.com. 2706 IN MX 5 mx2.hotmail.com. hotmail.com. 2706 IN MX 5 mx3.hotmail.com. -and- mx3.hotmail.com. 1926 IN A 65.xxx mx3.hotmail.com. 1926 IN A 65.xxx mx3.hotmail.com. 1926 IN A 65.xxx Use this when you have a large number of front-end servers fully capable of handling messages entering the system -and- you're somewhat clueful. The difference is that you want the IP addresses of the servers to be included as additional information in the DNS response. If you have a large number of addresses, they're all under the same name and including them all would make the DNS response packet larger than a few hundred bytes, the server will drop the additional information, requiring a second DNS lookup and possibly a third TCP-based DNS lookup in order to get it. By splitting them up, the DNS server will pack as many sets of addresses as it can into the original response packet. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: MX Record Theories
Hi, I thought i'd give you a quick response (and welcome to NANOG) :). Thanks. I can't believe that I've already received three very interesting responses in just over an hour ! I've been quietly lurking on NANOG for a while, just plucked up the courage to post . and might now even find a bit more courage to attempt to contribute to some threads ! Glad to see the community spirit still exists ! Keep the replies coming if there are any still on their way . :) Tim P.S. Valdis Kletnieks . I've got the feeling that this That 507 is critically important if it's true, might potentially explain a few intermittent unexplicable issues we've been seeing at some sites time for some research me thinks :)
Re: MX Record Theories
In message 163001.1243364...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: --==_Exmh_1243364471_3846P Content-Type: text/plain; charset=us-ascii On Tue, 26 May 2009 11:03:59 PDT, gb10hkzo-na...@yahoo.co.uk said: would be most interested to hear NANOG theories on the variety of MX record practices out there, namely, how come there seem to be so many ways employed to achieve the same goal ? The trick here is that it isn't always *exactly* the same goal. There's multiple mail system architectures and design philosophies. One often overlooked but very important design point for the *large* provider s: % dig aol.com mx ;; ANSWER SECTION: aol.com.2805IN MX 15 mailin-01.mx.aol.com. aol.com.2805IN MX 15 mailin-02.mx.aol.com. ... ;; WHEN: Tue May 26 14:40:41 2009 ;; MSG SIZE rcvd: 507 That 507 is critically important if you want to receive e-mail from sites with fascist firewalls that block EDNS0 and/or TCP/53. 5 bytes left. ;) Actually TCP/53 out is almost always allowed. Too many things break if you block TCP/53 out. Similarly TCP to recursive servers is almost always allowed because blocking it breaks too many things. Recursive nameservers generally deal with stupid firewalls by adjusting how they make their queries. ed...@4096 - ed...@512 - plain DNS. Stub resolvers generally don't do EDNS so the are not impacted by stupid firewalls. This will changes as DNSSEC processing moves into the application. A EDNS referral from the root servers to the COM servers already exceeded 512 bytes. The world hasn't fallen over. That's dealt with that myth. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
