15 ms·

Please do not put IP addresses into DNS MX records

228 points by hannob 6y ago

chrisseaton 6y ago
> I happen to use a mail server that is less forgiving (Courier), and every now and then I cannot send a mail due to this. It’s rare, but it does happen. If your mail server has such a configuration you may not receive some legitimate e-mails. Why not fix Courier? Seems easier than trying to convince others to change how they configure their DNS. Be forgiving in what you accept and disciplined in what you send.
- tinus_hn 6y ago
  Why not follow the standards? The standard states a MX record contains a domain name that does not point to a CNAME record. If you don’t follow the standards things might fail. That’s not someone else’s fault, it’s your fault.
  - 8ytecoder 6y ago
    >> There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. https://tools.ietf.org/html/rfc974 https://tools.ietf.org/html/rfc974 (Page 3) In general, we expect systems to be forgiving.
  - DaiPlusPlus 6y ago
    In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be liberal in what you accept, and conservative in what you send." Courier is failing to be liberal in input-handling.
    - corndoge 6y ago
      Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.
      - young_unixer 6y ago
        I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
        yjftsjthsd-h 6y ago
        JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
        woodruffw 6y ago
        > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
        DaiPlusPlus 6y ago
        Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
        woodruffw 6y ago
    - hannob 6y ago
      I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.
    - chrisseaton 6y ago
      Do you want to send people email? Then you'll need to be liberal in what you accept.
      - tedunangst 6y ago
        Why can't the other party be conservative in what they send?
        chokeartist 6y ago
        Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
        chrisseaton 6y ago
        > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.
    - jeff-davis 6y ago
      I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.
    - JdeBP 6y ago
      It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...
      - chrisseaton 6y ago
        > "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
      - DonHopkins 6y ago
        Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.
  - eznzt 6y ago
    Unless I'm missing something, the standard sounds pretty stupid
    - tsimionescu 6y ago
      You're missing something: IPv4 is not the only type of physical address supported by DNS. There is also IPv6, and historically there were others. Instead of trying to parse the address and guess what protocol it might be, DNS tries to make that unambiguous: you ask it for the A or AAAA records for a domain name you are interested in, and you know for sure that you are getting an IPv4 or IPv6 address respectively. The only clean alternative would have been to make an MXMXMXMX record type to hold a domain name OR an IPv6 address.
    - JdeBP 6y ago
      You are missing a lot, including the fact mentioned several times in this discussion that the data portion of an MX resource record simply is not an IP address. The data structure is a wire-format domain name (plus an integer). Even in BIND's "zone" file format, a human-format IP address isn't a fully qualified human-format domain name. But yes, the DNS RFCs are not as good as they could have been. However, you have reached that conclusion by the wrong route. (-:
  - andy_ppp 6y ago
    Domain names and IP addresses are interchangeable almost everywhere else right? There already is a standard here and the spec is breaking it, not the other way around.
    - apple4ever 6y ago
      That's how I feel. Specific records should not specify if its a domain name or an IP. They both should be accepted.
      - tsimionescu 6y ago
        So an A record should also hold domain names? Or IPv6 addresses? In DNS, there is actually a single record type that should hold a physical address, for each supported protocol address. We have A records for IPv4, and AAAA records for IPv6. Anything else should be a domain name. Adding both IPv4 and IPv6 support to every other record type would be a waste. Note: ignoring other protocol addresses above to keep it focused on what is currently is large scale use.
      - teddyh 6y ago
        DNS records are statically typed. An “A” record can only contain an IPv4 address, just like a variable of type “int” in the C programming language only can contain an integer. An MX record, just like CNAME, SRV, and others, can only contain a domain name, not an IP address of any kind. You can input a domain name which looks like an IPv4 address, but this is simply a syntax overlap; it happens to be that the normal textual representation of IPv4 addresses are also valid syntax for an unrelated domain name. Tellingly, the syntax for IPv6 addresses does not overlap with domain names, so you cannot make this error with IPv6 addresses.
    - bawolff 6y ago
      Not really when it comes to dns. You cant put a domain name in an A record or an ip address in a CNAME.
      - andy_ppp 6y ago
  - chrisseaton 6y ago
    > Why not follow the standards? Because they can't send email when they follow the standard? What are you trying to achieve? Following a standard for the sake of it, or are you actually trying to send email? And what's the point or use of a standard that people aren't following? What's the point of following such a standard?
    - tinus_hn 6y ago
      No, it’s the other way around. You can’t receive mail from standards-compliant servers if you don’t follow the standard. What the point is of the standard requiring you to use a name instead of an IP address is a reasonable question but not the same question as whether you should follow the standards. Note this is a standard made by people who knew what they were doing and it has stood for 35 years. There’s always room for improvement but it would be a bit silly to think you can just handwave it away with arguments you can come up with in a few seconds. There is bound to be a catch. In this case the catch of course is that there are more address types than IPv4 addresses, so the system requires you to specify what kind of address you are talking about. The mechanism for that is the A record, which only holds IPv4 addresses.
  - Tomte 6y ago
    Because you can't send mail everywhere, obviously. It's nice that it's the other person's fault. Still doesn't make your mail arrive.
  - osrec 6y ago
    But does the standard make sense? What's the rationale for not using an IP address?
    - tsimionescu 6y ago
      Because DNS works with many kinds of addresses, not just IPv4, and you shouldn't have to guess what type of address a record holds based on format. When you see an MX record with the value 1::8, how should you interpret it? Is it a malformed value? Is it an IPv6? Is it some other protocol that you don't know about? DNS clients shouldn't have to guess. Instead, the MX record should point to a domain name, and the client should look up the corresponding address record for the protocols it knows how to speak (A or AAAA or whatever else will exist).
      - DonHopkins 6y ago
        That is the best most irrefutable answer for why it's impossible I've seen so far. Better than "because it's physically impossible". (Is it electrically prevented at the Physical Layer, otherwise the router would catch fire if you tried to do that?)
        teddyh 6y ago
        To be precise, it’s logically impossible, since MX records are defined by the relevant standards to consist of a number of bytes which are to be interpreted as a priority integer followed by a series of DNS domain name labels. There is no defined way for an MX record to contain an IP address. You could make up some such way, but then it wouldn’t be an MX record as commonly defined, it would be your private extension of the standards.
        DonHopkins 6y ago
        "The standard definition tells you not to" isn't as deep and complete and useful an explanation as "the standard definition tells you not to, because networking protocols should not have ambiguities or make guesses". https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman To be precise instead of tautological (which you should be when arguing the pedantic nuances of networking protocols), when you use a word like "physically", you're implying that it has something to do with the "Physical Layer", and that there could not exist another networking protocol in the same universe that DID allow IP addresses in MX records, because it's forbidden by the physical laws of nature, not by the logical laws of networking protocols. It's literally like using the word "literally" to mean "figuratively". (And I mean "literally" literally, not figuratively.) Obviously it's not physically impossible, because sometimes people do it, and sometimes it even works. I will agree that it's unwise and scandalous and logically impossible, just not "physically" impossible, and that a better explanation is needed. That's probably why the first reply to your comment was "Out of curiosity though: why is it like this?" A networking protocol that operates faster than the speed of light, or sends information backwards in time, could be physically impossible, according to the currently known laws of physics. Although it would be super cool and convenient if you could specify a "Date:" field in the past or the future to send email at the specified time.
  - sneak 6y ago
    Because if you follow the standards, you can't send mail to some destinations, the issue the author is complaining about. It's the author's "fault" they can't send mail to those destinations when others can.
  - js2 6y ago
    There's a de jure standard (the RFC) and a de facto standard (the real world). The question then becomes whether you want to be right or whether you want to be able to send mail.
- brey 6y ago
  That does seem the better outcome - there’s no downside in being lenient here. > I did a quick scan of the Alexa Top 1 Million list. Currently around 0,06 % are affected Only affects a small minority of mailservers, and even then only 0.06% of domains.
- zxcvbn4038 6y ago
  I’d make the same argument, especially when it concerns smtp or dns as both standards are full of contradictions, caveats, and errata and there are plenty of real world implementations that deviate from the specs.
- jlgaddis 6y ago
  > Why not fix Courier? It isn't "broken".
nvr219 6y ago
I've been janitoring email for years and have never seen someone put an IP address in an MX record.
- leephillips 6y ago
  He gathered some data and found 0.06% were doing this.
  - hobofan 6y ago
    Which is so little, that I'm surprised that he even bothered to write a blog post about it. Clicking through the links it looks like a lot of the pages are blogspam/secondary language versions of bigger websites, so I doubt that a lot of those webmasters are even trying to have a properly set up MX record (or care about that).
  - nvr219 6y ago
    Yeah that percentage is really close to 0%. What are the odds of the 0.06% who do it see this blog post? Let it go.
- lucb1e 6y ago
  raises hand I did that because it worked and nobody told me not to until years later. Not sure if that's an effect of self-teaching or just not properly reading configuration guides (or both), it's about ten years ago now. And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use. I thought the mail server just had to have certs for all the domains it wished to serve. Again, though, it worked and nobody told me otherwise until the topic came up a few weeks ago (a friend of mine is building a mail server). Back when I set the thing up, StartCom was still popular, and while I use LE now, I didn't know I had a reason to change configs to better accommodate transport encryption.
  - jlgaddis 6y ago
    > I did that because it worked ... These things tend to -- until they don't (by which time you don't notice). > ... and nobody told me not to until years later. Instead of trying to enumerate all of the wrong ways to do things, the RFCs -- the authoritative documents -- will describe the right way to do things (although, in some cases, they do explicitly identify some things one must not do). If an RFC is ambiguous or unclear, that's a deficiency which should be addressed. -- > And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use. In general, the following has worked quite well for a long time: 1. Choose the "one true name" that your mail server will be known as. foo.example.com 2. Create an A RR for the hostname that points to the IP address of the server. foo.example.com. -> 192.0.2.25 3. Ensure that the PTR RR for the IP address of the server resolves to the chosen name (cf. "forward-confirmed reverse DNS"). 25.2.0.192.in-addr.arpa. -> foo.example.com 4. Configure your MTA to use foo.example.com as its "official" name (in EHLO/HELO greetings, Received: headers, and so on). If you run POP3/IMAP4 daemons on the same host, configure them to also use the same name. 5. Ensure that the MX RR for any hosted domains reference the one true name. 6. If you wish to use additional hostnames to refer to this server ("mail.example.com", a "mail" subdomain for each of your hosted customer domains, etc.), create CNAME RRs for them that point to the one true name. 7. Acquire and install a certificate for the one true name of the server ("foo.example.com") AND any other names that the server is known by (i.e., any hostnames from step six) and configure your MTA (and POP3/IMAP4 servers) to use it. -- A few related points: Notice the common theme: use the "one true name". The above steps assume that everything is running on a single host that has a single IP address. If it has multiple IP addresses available, you can "get more creative" and use "multiple true names" (this is almost done for "cosmetic" purposes, however; there are no technical reasons to do so). I did not mention SPF, DKIM, or DMARC, but you'll want to configure them all - and they should all use the "one true name" of your mail server. Some mail clients nowadays can make use of the "autoconfig" [0] and/or "autodiscovery" [1] methods, eliminating the need for the end user to manually set up their MUA. Additional RRs will need to be created to support these methods; "autoconfig" will also require a web server and some additional configuration. Postfix added support for SNI a few years ago (I can't speak to other MTAs). As with HTTPS, this allows using multiple "per-domain" certificates instead of a single certificate with all names. I don't know which, if any, mail clients currently support and, I have no firsthand experience using it. I mention it just in case it may be something you want to look into. -- [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird... [1]: https://tools.ietf.org/html/rfc6186 https://tools.ietf.org/html/rfc6186
VWWHFSfQ 6y ago
> Many mail servers are lenient when it comes to this misconfiguration and will deliver mails nevertheless, so this may stay undetected. I happen to use a mail server that is less forgiving (Courier), and every now and then I cannot send a mail due to this. Sorry man but this sounds like a "you" problem. You probably need to fix your mail server or get a new one.
- tuwtuwtuwtuw 6y ago
  I agree. But if all email servers ignore the rfc to cater for real world issues then at some point a new rfc would also make sense.
- treve 6y ago
  There's two ideal ways to deal with this: 1. Accept that the new standard is that ip addresses should be supported, and write a new rfc document with that change. 2. Encourage people to not support this. Simply asking all mailservers to support this non-standard feature (or de facto standard) is arguable the worst outcome, because now every mail server implementer is expected to implement the standard + a bunch of institutional knowledge. Luckily with mail there's a lot of incentive to set things up correctly, because getting parts of it wrong likely results in a higher number of emails going to spam.
  - SilasX 6y ago
    There’s also the option to tell them that “you shouldn’t do it this way, but I’m going to tolerate it ... for now.” I made up the tongue-in-cheek HTTP 397 for this case: https://pastebin.com/TPj9RwuZ https://pastebin.com/TPj9RwuZ
    - treve 6y ago
      The problem with this is if a few popular servers are lenient, people are going to start relying on this lenient behavior. More people relying on this means more servers will have to start supporting this bug and you end up with the 'worst case' again. Being strict if you can tolerate it is usually the better option.
scandox 6y ago
Another one to avoid is using a CNAME in the MX. It will work until it doesn't.
- t0mas88 6y ago
  Jup that one looks like it works for basic test cases but then breaks unexpectedly in the real world. Can't remember the exact problem but I have remembered to never point MX at a CNAME.
  - JdeBP 6y ago
    The SMTP standard specifies a loop prevention algorithm that ensures that fallback SMTP Relay servers don't end up forwarding back to themselves or even their own fallback servers. This loop prevention relies upon looking at the domain names in the MX resource records, and breaks if such a name is an (unknown by the fallback server itself) alias for the true domain name via a CNAME resource record.
- lucb1e 6y ago
  Doing a mail server project, you don't want to know how many people have recursive cnames configured on their mx records. At least now I know that ruby has a stack size of over ten thousand.
momszack 6y ago
> However some mail servers do configure an IP address. That the interpretation of the MX record is overly pedantic, makes the above statement from the article a wee bit ironic.
cadence- 6y ago
I would be interested to know why the RFC 1035 forbids using IP addresses in MX records. What was the original concern with doing this?
- geocrasher 6y ago
  DNS standards tend to favor using aliases rather than IP's. My observation is that the overall goal is to have the IP listed as few times as possible. Otherwise there'd be no need for CNAME's in general, and everything would be an A record or an IP. But, MX records are supposed to refer to an A record not an IP. The author is correct- if somebody is doing this, they're simply doing it wrong. Standards exist so that we can say "This configuration is wrong" instead of "Lets complicate software to allow people to use any configuration they want."
  - mlyle 6y ago
    > But, MX records are supposed to refer to a CNAME not an IP. To be clear, MX records are supposed to point to an A record. Pointing to a CNAME record is not legal.
    - DaiPlusPlus 6y ago
      What if it's an AAAA record?
      - stonesweep 6y ago
        In my travels there's a significant portion of the internet which is not IPv6 capable; for example the World Community Grid failed for me when trying to use pure IPv6, and they send emails about things. I'd currently not risk using an IPv6 record for my MX, I suspect a high failure rate delivering email from every service on the planet will follow.
        deleted 6y ago
        [deleted]
tlb 6y ago
Does someone run a DNS server that will return an IP address directly from the name? I think once upon a time in-addr.arpa. did this, so you could use http://4.3.2.1.in-addr.arpa/ http://4.3.2.1.in-addr.arpa/ and it'd resolve to 1.2.3.4. But not now.
- 1_player 6y ago
  http://xip.io/ http://xip.io/ does, until it's turned off.
  - sofixa 6y ago
    What do you mean turned off?
    - lucb1e 6y ago
      It's not as if it's built into the protocol, operated decentrally and guaranteed to work. Someone generously operates the service. At least that's what I assume GP meant.
    - chtitux 6y ago
      When using an external service like this one, you have no guarantee: - this service will last forever - this service won't be acquired by someone else with evil intention and will never lie Do not use this service. It has the power to steal your traffic.
      - strenholme 6y ago
        It’s also possible to run it yourself, as I point out elsewhere in the thread (complete with the Lua script to run the code). To summarize: git clone https://git.sr.ht/~samiam/MaraDNS cd MaraDNS/deadwood-github/tools/coLunacyDNS make sudo cp coLunacyDNS /usr/local/bin And the script to do the name-to-IP conversion is one of the examples included in the docs: https://github.com/samboy/MaraDNS/blob/master/deadwood-github/tools/coLunacyDNS/README.md https://github.com/samboy/MaraDNS/blob/master/deadwood-githu...
Daviey 6y ago
Sort of related, i've always appreciated Postfix error 221 "I can break rules, too. Goodbye." Nobody would normally see this curt attitude as it is hidden in the protocol, but I find it cute. $ nc 127.0.0.1 25 220 localhost ESMTP Postfix (Ubuntu) GET 221 2.7.0 Error: I can break rules, too. Goodbye. Where: 221 = - 2XX = "(Positive Completion Reply): The requested action has been successfully completed." - 221 specifically, "Service closing transmission channel" 2.7.0 = (class.subject.detail) - 2.X = "Success: Report of a positive delivery action." - X.7 = "Security or Policy Status"
strenholme 6y ago
Oh, DNS is full of these kinds of “not in a RFC but needed to resolve names” corner cases. I will show just one: (While .foo is a real top level domain, Google doesn’t let the public register names in it. It would be nice if there was a “.example” TLD; “.invalid” looks wrong and using “example.(com|org|net)” is awkward when using multiple domains in an example. 10.X.X.X should not be resolved at the internet-wide DNS level in the real world, but these are examples, not real-world cases) We get this packet when asking the domain1.foo nameserver for blog.domain1.foo blog.domain1.foo CNAME blog.domain2.foo blog.domain2.foo A 10.1.2.3 Should we use this A record? BIND, about 20 years ago, did use this A record. DJB rightfully screamed bloody murder (since BIND allowed domain1.foo to alter the cache for domain2.foo), and would not accept the IP. MaraDNS (Deadwood, these days), on the other hand, accepts the IP, but stores it in the domain1.foo record (so domain1.foo does not affect cache entries for domain2.foo). Now, the correct thing to do is to not accept the domain2.foo record at all unless it comes from a server in domain2.foo’s bailiwick, since that is how modern versions of BIND do it. Otherwise, there are a small number of poorly configured corner cases (where domain1.foo has an outdated IP for domain2.foo) which will resolve incorrectly. Now, back to the article, I believe DJB had a way of handling this: If it saw “domain2.foo MX 10.2.3.4”, it would then, if asked for the IP for the domain “10.2.3.4”, return the A record (IP) 10.2.3.4 (or was it Qmail which did the expected thing if it saw a dotted decimal domain name? Or both? There are enough old school DJB advocates here that someone should be able to clarify) I know this much: DJB made some noise two decades ago that this is a real-world misconfiguration which should be accounted for and handled the expected way, calling them dotted decimal IPs.
- teddyh 6y ago
  > Should we use this CNAME record? I think you mean “Should we use this A record?”? > calling them dotted decimal IPs. Thankfully, with IPv6 we don’t have to worry about it, since the syntax for IPv6 addresses are invalid as domain names.
  - strenholme 6y ago
    Thank you for pointing out the typo; I have corrected the grandparent.
teddyh 6y ago
I agree with the article, but I would go even further. This whole thing is stupid. You physically can’t put an IP address into an MX DNS record. What the syntax (perhaps misleadingly) allows is to put a domain name there with labels consisting of only digits. That is, the “IP adress” 1.2.3.4 you wrote in your MX record is actually the domain name "1.2.3.4.yourdomain.com" with “1”, “2”, “3”, “4”, “yourdomain”, and “com” as the individual domain labels. There is no way to actually store an IP address in an MX DNS record. It just so happens that the usual syntax for IPv4 addresses turns out to be valid syntax for an (unrelated) domain name as well. And, of course, if you try to write an IPv6 address, it will naturally fail, since IPv6 addresses uses colon “:” characters, which are not allowed in domain names. Therefore, it would be beyond silly for programs to actually use these invalid domain names in MX records. MX records which point to domain names which cannot be resolved are simply broken.
- bombcar 6y ago
  At some point someone’s going to get the .0 to .255 TLD somehow and cause a security fuffle.
  - teddyh 6y ago
    As luck would have it, that’s probably not going to affect most people, because people who write an “IP address” in an MX record probably also didn’t put the terminating period at the end. Therefore, the MX record to “1.2.3.4” resolves to the local name “1.2.3.4.example.com” and not a domain in the hypothetical “.4” TLD.
    - bombcar 6y ago
      Now I wonder how many of these might have the ability for users to create subdomains ... shades of being able to make "webmaster@" addresses for email sites and get an SSL cert or whatever.
    - TheCraiggers 6y ago
      Some software / sites put one there for you. Which is annoying when you don't want it.
dwd 6y ago
I have come across companies who are hosting their mail via a provider (usually cPanel-based) and don't have MX records in their DNS at all; the provider has a failover to route them to the naked domain IP. Absolutely insane because soon as you change the naked domain IP to point elsewhere, their email stops working.
- gog 6y ago
  I think it is not the providers fault. This is in the spec, if MX record does not exist for a domain try to deliver to the host behind the A record of the domain (naked IP).
- jlgaddis 6y ago
  This is by design. If an MX RR isn't present, the spec says MTAs are to try to deliver majl to the host that the A RR points at. If you don't want that, create the appropriate MX RR. If you don't want e-mail for a given domain, create a null record.
  - dwd 6y ago
    Thank, wasn't aware that was in the spec. Makes sense, unfortunately allows for businesses (generally SMEs) to be relying on very sketchy setups.
baby 6y ago
Don't you have to if you use cloudflare to protect your domain?
qwerty456127 6y ago
> Notably, according to the respective RFC 1035 the MX record must contain a domain name and may not directly point to an IP address. Why?
- eknshow 6y ago
  DNS uses a binary format on the wire. MX records are defined as a 16-bit integer followed by a domain name. On the wire a domain name is a series of length prefixed octets or a pointer to another set of octets. IP addresses in A and AAAA are represented as a fixed length series of octets. It's apples and oranges.
userbinator 6y ago
Perhaps one should think about why people put IP addresses in there in the first place --- because in an overwhelmingly large number of usages, an IP is perfectly acceptable instead of a domain name (while a domain name is not always acceptable instead of an IP.) In that sense, RFC 1035 is an aberration.
sally1620 6y ago
With IP addresses, it is not possible to validate TLS certificate as well. This should not work at all. Also we have HTTPS everywhere, but DKIM is still not supported by most domains. That is a more serious issue and it also covers this as well.
- gog 6y ago
  You can get an IP address as a SAN, but that doesn't mean much because unless configured to do so, most email servers will not validate and reject invalid certificates on a destination mail server.
- judge2020 6y ago
  > With IP addresses, it is not possible to validate TLS certificate as well. This should not work at all. Technically the CA/B forum hasn't outlawed TLS certificates for IP addresses, and a few live ones exist. https://1.1.1.1 https://1.1.1.1 plus https://[2606:4700:4700::1111]/ https://[2606:4700:4700::1111]/ https://crt.sh/?q=8.8.8.8 https://crt.sh/?q=8.8.8.8
  - judge2020 6y ago
    https://8.8.8.8/test https://8.8.8.8/test
monkaiju 6y ago
If you need a way to keep tabs on a bunch of DNS records check out dug: https://github.com/unfrl/dug https://github.com/unfrl/dug
ratsbane 6y ago
dig myspecialdomainwhatever.com MX for anyone like me who had to look that up. (And I'm far from competent on DNS matters so please correct if there's a better way)
kureikain 6y ago
I run an email forwarding services so I understand mail system quite well. IMHO, no one seems to use IP in DNS record, probably someone just do quick and dirty and forgot config. Because when putting IP, when you change your server you have to tell all people to update MX records. So you usually see service use mx1 mx2 style domain. Nowadays, peolple rarel setup mail server and use 3rd solution and they usually alreayd use domain name in their DNS record. So this advice is for people who run their own server who really should know their stuff already.
bullen 6y ago
2 DNS requests per mail is not efficient. You should recompile Courier!

228 points by hannob 6y ago

> I happen to use a mail server that is less forgiving (Courier), and every now and then I cannot send a mail due to this. It’s rare, but it does happen. If your mail server has such a configuration you may not receive some legitimate e-mails. Why not fix Courier? Seems easier than trying to convince others to change how they configure their DNS. Be forgiving in what you accept and disciplined in what you send.

tinus_hn 6y ago
Why not follow the standards? The standard states a MX record contains a domain name that does not point to a CNAME record. If you don’t follow the standards things might fail. That’s not someone else’s fault, it’s your fault.
- 8ytecoder 6y ago
  >> There is one other special case. If the response contains an answer which is a CNAME RR, it indicates that REMOTE is actually an alias for some other domain name. The query should be repeated with the canonical domain name. https://tools.ietf.org/html/rfc974 https://tools.ietf.org/html/rfc974 (Page 3) In general, we expect systems to be forgiving.
- DaiPlusPlus 6y ago
  In this case, Courier is following the standard and it's failing, and it's the "fault" of the software. Courier is breaking (the aptly named) Postel's Law: "Be liberal in what you accept, and conservative in what you send." Courier is failing to be liberal in input-handling.
  - corndoge 6y ago
    Postel's law was a good rule of thumb in the early wild west internet. In modern times I think it's largely anachronistic. Being liberal in what you accept leads to security problems, erosion of standards, growth of edge cases, etc.
    - young_unixer 6y ago
      I don't think anachronistic is the right description, but I agree that in some contexts Postel's law should not be followed. Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security.
      - yjftsjthsd-h 6y ago
        JSON libraries are security-sensitive, though; they tend to get used on content coming from 3rd parties over the internet.
      - woodruffw 6y ago
        > Postel's law is a good rule of thumb if you're writing a JSON library, but not if you're writing anything that has to do with security. I'm a big fan of Postel's law in the context of UNIX tools, but I think that JSON is exactly the wrong example: JSON parsing is a security/format boundary, and I don't want my JSON (or any other parser) trying to suss structure out of something that's under- or unspecified. That way lies input confusion vulnerabilities.
        DaiPlusPlus 6y ago
        Well, one example is having a JSON object property that is nominally typed as `number` but a JSON parser/library would also accept a number-in-a-string, so both `{ "foo": "123" }` and `{ "foo": 123 }` would be accepted. Storing numbers inside strings can be necessary if you're encountering JavaScript's 2^56 limit on integers, for example.
        woodruffw 6y ago
  - hannob 6y ago
    I thought about adding that, I should've... It's widely believed these days that postel's law was a mistake.
  - chrisseaton 6y ago
    Do you want to send people email? Then you'll need to be liberal in what you accept.
    - tedunangst 6y ago
      Why can't the other party be conservative in what they send?
      - chokeartist 6y ago
        Go back to reddit. RFCs are standards but real life requires acceptance of divergence from the exact letter of the law.
      - chrisseaton 6y ago
        > Why can't the other party be conservative in what they send? Because they don't want to be? Because they don't know that they should be? Because they don't know how? Because they think they are but they're mistaken? Because the specification is ambiguous? Any number of reasons. But you can't control what they do. You can only control what you do. If you want to send an email to them, you need to be compatible with their email server.
  - jeff-davis 6y ago
    I think there's some nuance here. Being liberal in what you accept is good for the growth and connectedness of a network. It's so powerful that it's not so much a suggestion as an inevitability -- if you're trying to be perfectly strict, then you will be excluded from the network and other people will find a way to be included. A party will always be bigger when you are less strict about the invitation/rsvp protocol. But it has obvious downsides. One is that the protocol keeps evolving, because people find novel ways to be non-conforming senders. This means an implementation is never "done". Another is that it becomes so hard to create a new implementation that accounts for all the non-conforming behavior, that the "standard" essentially becomes defined by a few of the big implementations.
  - JdeBP 6y ago
    It is important to remember what Marc Crispin had to say about this: > Actually, Postel's principle is misstated. I knew Jon personally. He never advocated forcing implementations to accept bogus protocol, and it is a perverson of Jon's legacy to claim otherwise. > "Be liberal in what you accept" referred to accepting a wide range of valid protocol, as opposed to accepting only the most common form. If you consider the early protocols, such as Telnet and FTP, it was all too easy to create two compliant and non-interoperable implementations due to each implementation choosing a different subset. -- https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7ypU/m/--E_3AQB5QcJ https://groups.google.com/g/alt.comp.mail.qmail/c/dcwx0Wc7yp... > This statement is based upon a terrible misunderstand of Postel's robustness principle. I knew Jon Postel. He was quite unhappy with how his robustness principle was abused to cover up non-compliant behavior, and to criticize compliant software. -- https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/iYunDY6h_xMJ https://groups.google.com/g/comp.mail.pine/c/E5ojND1L4u8/m/i...
    - chrisseaton 6y ago
      > "Be liberal in what you accept" referred to accepting a wide range of valid protocol Have you considered that after some point you need to accept the de facto protocol as a valid protocol? If everyone else is using unnamed but extant protocol X, why fight that? What do you gain from it?
    - DonHopkins 6y ago
      Marc "MM Is Not At Fault" Crispin was also the author of the "infamous" RFC 748: Telnet Randomly-Lose Option. https://en.wikipedia.org/wiki/Mark_Crispin https://en.wikipedia.org/wiki/Mark_Crispin https://tools.ietf.org/html/rfc748 https://tools.ietf.org/html/rfc748 4. Motivation for the option. Several hosts appear to provide random lossage, such as system crashes, lost data, incorrectly functioning programs, etc., as part of their services. These services are often undocumented and are in general quite confusing to the novice user. A general means is needed to allow the user to disable these features.
- eznzt 6y ago
  Unless I'm missing something, the standard sounds pretty stupid
  - tsimionescu 6y ago
    You're missing something: IPv4 is not the only type of physical address supported by DNS. There is also IPv6, and historically there were others. Instead of trying to parse the address and guess what protocol it might be, DNS tries to make that unambiguous: you ask it for the A or AAAA records for a domain name you are interested in, and you know for sure that you are getting an IPv4 or IPv6 address respectively. The only clean alternative would have been to make an MXMXMXMX record type to hold a domain name OR an IPv6 address.
  - JdeBP 6y ago
    You are missing a lot, including the fact mentioned several times in this discussion that the data portion of an MX resource record simply is not an IP address. The data structure is a wire-format domain name (plus an integer). Even in BIND's "zone" file format, a human-format IP address isn't a fully qualified human-format domain name. But yes, the DNS RFCs are not as good as they could have been. However, you have reached that conclusion by the wrong route. (-:
- andy_ppp 6y ago
  Domain names and IP addresses are interchangeable almost everywhere else right? There already is a standard here and the spec is breaking it, not the other way around.
  - apple4ever 6y ago
    That's how I feel. Specific records should not specify if its a domain name or an IP. They both should be accepted.
    - tsimionescu 6y ago
      So an A record should also hold domain names? Or IPv6 addresses? In DNS, there is actually a single record type that should hold a physical address, for each supported protocol address. We have A records for IPv4, and AAAA records for IPv6. Anything else should be a domain name. Adding both IPv4 and IPv6 support to every other record type would be a waste. Note: ignoring other protocol addresses above to keep it focused on what is currently is large scale use.
    - teddyh 6y ago
      DNS records are statically typed. An “A” record can only contain an IPv4 address, just like a variable of type “int” in the C programming language only can contain an integer. An MX record, just like CNAME, SRV, and others, can only contain a domain name, not an IP address of any kind. You can input a domain name which looks like an IPv4 address, but this is simply a syntax overlap; it happens to be that the normal textual representation of IPv4 addresses are also valid syntax for an unrelated domain name. Tellingly, the syntax for IPv6 addresses does not overlap with domain names, so you cannot make this error with IPv6 addresses.
  - bawolff 6y ago
    Not really when it comes to dns. You cant put a domain name in an A record or an ip address in a CNAME.
    - andy_ppp 6y ago
- chrisseaton 6y ago
  > Why not follow the standards? Because they can't send email when they follow the standard? What are you trying to achieve? Following a standard for the sake of it, or are you actually trying to send email? And what's the point or use of a standard that people aren't following? What's the point of following such a standard?
  - tinus_hn 6y ago
    No, it’s the other way around. You can’t receive mail from standards-compliant servers if you don’t follow the standard. What the point is of the standard requiring you to use a name instead of an IP address is a reasonable question but not the same question as whether you should follow the standards. Note this is a standard made by people who knew what they were doing and it has stood for 35 years. There’s always room for improvement but it would be a bit silly to think you can just handwave it away with arguments you can come up with in a few seconds. There is bound to be a catch. In this case the catch of course is that there are more address types than IPv4 addresses, so the system requires you to specify what kind of address you are talking about. The mechanism for that is the A record, which only holds IPv4 addresses.
- Tomte 6y ago
  Because you can't send mail everywhere, obviously. It's nice that it's the other person's fault. Still doesn't make your mail arrive.
- osrec 6y ago
  But does the standard make sense? What's the rationale for not using an IP address?
  - tsimionescu 6y ago
    Because DNS works with many kinds of addresses, not just IPv4, and you shouldn't have to guess what type of address a record holds based on format. When you see an MX record with the value 1::8, how should you interpret it? Is it a malformed value? Is it an IPv6? Is it some other protocol that you don't know about? DNS clients shouldn't have to guess. Instead, the MX record should point to a domain name, and the client should look up the corresponding address record for the protocols it knows how to speak (A or AAAA or whatever else will exist).
    - DonHopkins 6y ago
      That is the best most irrefutable answer for why it's impossible I've seen so far. Better than "because it's physically impossible". (Is it electrically prevented at the Physical Layer, otherwise the router would catch fire if you tried to do that?)
      - teddyh 6y ago
        To be precise, it’s logically impossible, since MX records are defined by the relevant standards to consist of a number of bytes which are to be interpreted as a priority integer followed by a series of DNS domain name labels. There is no defined way for an MX record to contain an IP address. You could make up some such way, but then it wouldn’t be an MX record as commonly defined, it would be your private extension of the standards.
        DonHopkins 6y ago
        "The standard definition tells you not to" isn't as deep and complete and useful an explanation as "the standard definition tells you not to, because networking protocols should not have ambiguities or make guesses". https://en.wikipedia.org/wiki/No_true_Scotsman https://en.wikipedia.org/wiki/No_true_Scotsman To be precise instead of tautological (which you should be when arguing the pedantic nuances of networking protocols), when you use a word like "physically", you're implying that it has something to do with the "Physical Layer", and that there could not exist another networking protocol in the same universe that DID allow IP addresses in MX records, because it's forbidden by the physical laws of nature, not by the logical laws of networking protocols. It's literally like using the word "literally" to mean "figuratively". (And I mean "literally" literally, not figuratively.) Obviously it's not physically impossible, because sometimes people do it, and sometimes it even works. I will agree that it's unwise and scandalous and logically impossible, just not "physically" impossible, and that a better explanation is needed. That's probably why the first reply to your comment was "Out of curiosity though: why is it like this?" A networking protocol that operates faster than the speed of light, or sends information backwards in time, could be physically impossible, according to the currently known laws of physics. Although it would be super cool and convenient if you could specify a "Date:" field in the past or the future to send email at the specified time.
- sneak 6y ago
  Because if you follow the standards, you can't send mail to some destinations, the issue the author is complaining about. It's the author's "fault" they can't send mail to those destinations when others can.
- js2 6y ago
  There's a de jure standard (the RFC) and a de facto standard (the real world). The question then becomes whether you want to be right or whether you want to be able to send mail.
brey 6y ago
That does seem the better outcome - there’s no downside in being lenient here. > I did a quick scan of the Alexa Top 1 Million list. Currently around 0,06 % are affected Only affects a small minority of mailservers, and even then only 0.06% of domains.
zxcvbn4038 6y ago
I’d make the same argument, especially when it concerns smtp or dns as both standards are full of contradictions, caveats, and errata and there are plenty of real world implementations that deviate from the specs.
jlgaddis 6y ago
> Why not fix Courier? It isn't "broken".

nvr219 6y ago

I've been janitoring email for years and have never seen someone put an IP address in an MX record.

leephillips 6y ago
He gathered some data and found 0.06% were doing this.
- hobofan 6y ago
  Which is so little, that I'm surprised that he even bothered to write a blog post about it. Clicking through the links it looks like a lot of the pages are blogspam/secondary language versions of bigger websites, so I doubt that a lot of those webmasters are even trying to have a properly set up MX record (or care about that).
- nvr219 6y ago
  Yeah that percentage is really close to 0%. What are the odds of the 0.06% who do it see this blog post? Let it go.
lucb1e 6y ago
raises hand I did that because it worked and nobody told me not to until years later. Not sure if that's an effect of self-teaching or just not properly reading configuration guides (or both), it's about ten years ago now. And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use. I thought the mail server just had to have certs for all the domains it wished to serve. Again, though, it worked and nobody told me otherwise until the topic came up a few weeks ago (a friend of mine is building a mail server). Back when I set the thing up, StartCom was still popular, and while I use LE now, I didn't know I had a reason to change configs to better accommodate transport encryption.
- jlgaddis 6y ago
  > I did that because it worked ... These things tend to -- until they don't (by which time you don't notice). > ... and nobody told me not to until years later. Instead of trying to enumerate all of the wrong ways to do things, the RFCs -- the authoritative documents -- will describe the right way to do things (although, in some cases, they do explicitly identify some things one must not do). If an RFC is ambiguous or unclear, that's a deficiency which should be addressed. -- > And apparently I'm still doing it wrong, I recently learned I'm supposed to point the MX of the various domains to whatever certificate the mail server will use. In general, the following has worked quite well for a long time: 1. Choose the "one true name" that your mail server will be known as. foo.example.com 2. Create an A RR for the hostname that points to the IP address of the server. foo.example.com. -> 192.0.2.25 3. Ensure that the PTR RR for the IP address of the server resolves to the chosen name (cf. "forward-confirmed reverse DNS"). 25.2.0.192.in-addr.arpa. -> foo.example.com 4. Configure your MTA to use foo.example.com as its "official" name (in EHLO/HELO greetings, Received: headers, and so on). If you run POP3/IMAP4 daemons on the same host, configure them to also use the same name. 5. Ensure that the MX RR for any hosted domains reference the one true name. 6. If you wish to use additional hostnames to refer to this server ("mail.example.com", a "mail" subdomain for each of your hosted customer domains, etc.), create CNAME RRs for them that point to the one true name. 7. Acquire and install a certificate for the one true name of the server ("foo.example.com") AND any other names that the server is known by (i.e., any hostnames from step six) and configure your MTA (and POP3/IMAP4 servers) to use it. -- A few related points: Notice the common theme: use the "one true name". The above steps assume that everything is running on a single host that has a single IP address. If it has multiple IP addresses available, you can "get more creative" and use "multiple true names" (this is almost done for "cosmetic" purposes, however; there are no technical reasons to do so). I did not mention SPF, DKIM, or DMARC, but you'll want to configure them all - and they should all use the "one true name" of your mail server. Some mail clients nowadays can make use of the "autoconfig" [0] and/or "autodiscovery" [1] methods, eliminating the need for the end user to manually set up their MUA. Additional RRs will need to be created to support these methods; "autoconfig" will also require a web server and some additional configuration. Postfix added support for SNI a few years ago (I can't speak to other MTAs). As with HTTPS, this allows using multiple "per-domain" certificates instead of a single certificate with all names. I don't know which, if any, mail clients currently support and, I have no firsthand experience using it. I mention it just in case it may be something you want to look into. -- [0]: https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird... [1]: https://tools.ietf.org/html/rfc6186 https://tools.ietf.org/html/rfc6186

VWWHFSfQ 6y ago

> Many mail servers are lenient when it comes to this misconfiguration and will deliver mails nevertheless, so this may stay undetected. I happen to use a mail server that is less forgiving (Courier), and every now and then I cannot send a mail due to this. Sorry man but this sounds like a "you" problem. You probably need to fix your mail server or get a new one.

tuwtuwtuwtuw 6y ago
I agree. But if all email servers ignore the rfc to cater for real world issues then at some point a new rfc would also make sense.
treve 6y ago
There's two ideal ways to deal with this: 1. Accept that the new standard is that ip addresses should be supported, and write a new rfc document with that change. 2. Encourage people to not support this. Simply asking all mailservers to support this non-standard feature (or de facto standard) is arguable the worst outcome, because now every mail server implementer is expected to implement the standard + a bunch of institutional knowledge. Luckily with mail there's a lot of incentive to set things up correctly, because getting parts of it wrong likely results in a higher number of emails going to spam.
- SilasX 6y ago
  There’s also the option to tell them that “you shouldn’t do it this way, but I’m going to tolerate it ... for now.” I made up the tongue-in-cheek HTTP 397 for this case: https://pastebin.com/TPj9RwuZ https://pastebin.com/TPj9RwuZ
  - treve 6y ago
    The problem with this is if a few popular servers are lenient, people are going to start relying on this lenient behavior. More people relying on this means more servers will have to start supporting this bug and you end up with the 'worst case' again. Being strict if you can tolerate it is usually the better option.

scandox 6y ago

Another one to avoid is using a CNAME in the MX. It will work until it doesn't.

t0mas88 6y ago
Jup that one looks like it works for basic test cases but then breaks unexpectedly in the real world. Can't remember the exact problem but I have remembered to never point MX at a CNAME.
- JdeBP 6y ago
  The SMTP standard specifies a loop prevention algorithm that ensures that fallback SMTP Relay servers don't end up forwarding back to themselves or even their own fallback servers. This loop prevention relies upon looking at the domain names in the MX resource records, and breaks if such a name is an (unknown by the fallback server itself) alias for the true domain name via a CNAME resource record.
lucb1e 6y ago
Doing a mail server project, you don't want to know how many people have recursive cnames configured on their mx records. At least now I know that ruby has a stack size of over ten thousand.

momszack 6y ago

> However some mail servers do configure an IP address. That the interpretation of the MX record is overly pedantic, makes the above statement from the article a wee bit ironic.

cadence- 6y ago

I would be interested to know why the RFC 1035 forbids using IP addresses in MX records. What was the original concern with doing this?

geocrasher 6y ago
DNS standards tend to favor using aliases rather than IP's. My observation is that the overall goal is to have the IP listed as few times as possible. Otherwise there'd be no need for CNAME's in general, and everything would be an A record or an IP. But, MX records are supposed to refer to an A record not an IP. The author is correct- if somebody is doing this, they're simply doing it wrong. Standards exist so that we can say "This configuration is wrong" instead of "Lets complicate software to allow people to use any configuration they want."
- mlyle 6y ago
  > But, MX records are supposed to refer to a CNAME not an IP. To be clear, MX records are supposed to point to an A record. Pointing to a CNAME record is not legal.
  - DaiPlusPlus 6y ago
    What if it's an AAAA record?
    - stonesweep 6y ago
      In my travels there's a significant portion of the internet which is not IPv6 capable; for example the World Community Grid failed for me when trying to use pure IPv6, and they send emails about things. I'd currently not risk using an IPv6 record for my MX, I suspect a high failure rate delivering email from every service on the planet will follow.
      - deleted 6y ago
        [deleted]

tlb 6y ago

Does someone run a DNS server that will return an IP address directly from the name? I think once upon a time in-addr.arpa. did this, so you could use http://4.3.2.1.in-addr.arpa/ http://4.3.2.1.in-addr.arpa/ and it'd resolve to 1.2.3.4. But not now.

1_player 6y ago
http://xip.io/ http://xip.io/ does, until it's turned off.
- sofixa 6y ago
  What do you mean turned off?
  - lucb1e 6y ago
    It's not as if it's built into the protocol, operated decentrally and guaranteed to work. Someone generously operates the service. At least that's what I assume GP meant.
  - chtitux 6y ago
    When using an external service like this one, you have no guarantee: - this service will last forever - this service won't be acquired by someone else with evil intention and will never lie Do not use this service. It has the power to steal your traffic.
    - strenholme 6y ago
      It’s also possible to run it yourself, as I point out elsewhere in the thread (complete with the Lua script to run the code). To summarize: git clone https://git.sr.ht/~samiam/MaraDNS cd MaraDNS/deadwood-github/tools/coLunacyDNS make sudo cp coLunacyDNS /usr/local/bin And the script to do the name-to-IP conversion is one of the examples included in the docs: https://github.com/samboy/MaraDNS/blob/master/deadwood-github/tools/coLunacyDNS/README.md https://github.com/samboy/MaraDNS/blob/master/deadwood-githu...

Daviey 6y ago

Sort of related, i've always appreciated Postfix error 221 "I can break rules, too. Goodbye." Nobody would normally see this curt attitude as it is hidden in the protocol, but I find it cute. $ nc 127.0.0.1 25 220 localhost ESMTP Postfix (Ubuntu) GET 221 2.7.0 Error: I can break rules, too. Goodbye. Where: 221 = - 2XX = "(Positive Completion Reply): The requested action has been successfully completed." - 221 specifically, "Service closing transmission channel" 2.7.0 = (class.subject.detail) - 2.X = "Success: Report of a positive delivery action." - X.7 = "Security or Policy Status"

strenholme 6y ago

Oh, DNS is full of these kinds of “not in a RFC but needed to resolve names” corner cases. I will show just one: (While .foo is a real top level domain, Google doesn’t let the public register names in it. It would be nice if there was a “.example” TLD; “.invalid” looks wrong and using “example.(com|org|net)” is awkward when using multiple domains in an example. 10.X.X.X should not be resolved at the internet-wide DNS level in the real world, but these are examples, not real-world cases) We get this packet when asking the domain1.foo nameserver for blog.domain1.foo blog.domain1.foo CNAME blog.domain2.foo blog.domain2.foo A 10.1.2.3 Should we use this A record? BIND, about 20 years ago, did use this A record. DJB rightfully screamed bloody murder (since BIND allowed domain1.foo to alter the cache for domain2.foo), and would not accept the IP. MaraDNS (Deadwood, these days), on the other hand, accepts the IP, but stores it in the domain1.foo record (so domain1.foo does not affect cache entries for domain2.foo). Now, the correct thing to do is to not accept the domain2.foo record at all unless it comes from a server in domain2.foo’s bailiwick, since that is how modern versions of BIND do it. Otherwise, there are a small number of poorly configured corner cases (where domain1.foo has an outdated IP for domain2.foo) which will resolve incorrectly. Now, back to the article, I believe DJB had a way of handling this: If it saw “domain2.foo MX 10.2.3.4”, it would then, if asked for the IP for the domain “10.2.3.4”, return the A record (IP) 10.2.3.4 (or was it Qmail which did the expected thing if it saw a dotted decimal domain name? Or both? There are enough old school DJB advocates here that someone should be able to clarify) I know this much: DJB made some noise two decades ago that this is a real-world misconfiguration which should be accounted for and handled the expected way, calling them dotted decimal IPs.

teddyh 6y ago
> Should we use this CNAME record? I think you mean “Should we use this A record?”? > calling them dotted decimal IPs. Thankfully, with IPv6 we don’t have to worry about it, since the syntax for IPv6 addresses are invalid as domain names.
- strenholme 6y ago
  Thank you for pointing out the typo; I have corrected the grandparent.

teddyh 6y ago

I agree with the article, but I would go even further. This whole thing is stupid. You physically can’t put an IP address into an MX DNS record. What the syntax (perhaps misleadingly) allows is to put a domain name there with labels consisting of only digits. That is, the “IP adress” 1.2.3.4 you wrote in your MX record is actually the domain name "1.2.3.4.yourdomain.com" with “1”, “2”, “3”, “4”, “yourdomain”, and “com” as the individual domain labels. There is no way to actually store an IP address in an MX DNS record. It just so happens that the usual syntax for IPv4 addresses turns out to be valid syntax for an (unrelated) domain name as well. And, of course, if you try to write an IPv6 address, it will naturally fail, since IPv6 addresses uses colon “:” characters, which are not allowed in domain names. Therefore, it would be beyond silly for programs to actually use these invalid domain names in MX records. MX records which point to domain names which cannot be resolved are simply broken.

bombcar 6y ago
At some point someone’s going to get the .0 to .255 TLD somehow and cause a security fuffle.
- teddyh 6y ago
  As luck would have it, that’s probably not going to affect most people, because people who write an “IP address” in an MX record probably also didn’t put the terminating period at the end. Therefore, the MX record to “1.2.3.4” resolves to the local name “1.2.3.4.example.com” and not a domain in the hypothetical “.4” TLD.
  - bombcar 6y ago
    Now I wonder how many of these might have the ability for users to create subdomains ... shades of being able to make "webmaster@" addresses for email sites and get an SSL cert or whatever.
  - TheCraiggers 6y ago
    Some software / sites put one there for you. Which is annoying when you don't want it.

dwd 6y ago

I have come across companies who are hosting their mail via a provider (usually cPanel-based) and don't have MX records in their DNS at all; the provider has a failover to route them to the naked domain IP. Absolutely insane because soon as you change the naked domain IP to point elsewhere, their email stops working.

gog 6y ago
I think it is not the providers fault. This is in the spec, if MX record does not exist for a domain try to deliver to the host behind the A record of the domain (naked IP).
jlgaddis 6y ago
This is by design. If an MX RR isn't present, the spec says MTAs are to try to deliver majl to the host that the A RR points at. If you don't want that, create the appropriate MX RR. If you don't want e-mail for a given domain, create a null record.
- dwd 6y ago
  Thank, wasn't aware that was in the spec. Makes sense, unfortunately allows for businesses (generally SMEs) to be relying on very sketchy setups.

baby 6y ago

Don't you have to if you use cloudflare to protect your domain?

qwerty456127 6y ago

> Notably, according to the respective RFC 1035 the MX record must contain a domain name and may not directly point to an IP address. Why?

eknshow 6y ago
DNS uses a binary format on the wire. MX records are defined as a 16-bit integer followed by a domain name. On the wire a domain name is a series of length prefixed octets or a pointer to another set of octets. IP addresses in A and AAAA are represented as a fixed length series of octets. It's apples and oranges.

userbinator 6y ago

Perhaps one should think about why people put IP addresses in there in the first place --- because in an overwhelmingly large number of usages, an IP is perfectly acceptable instead of a domain name (while a domain name is not always acceptable instead of an IP.) In that sense, RFC 1035 is an aberration.

sally1620 6y ago

With IP addresses, it is not possible to validate TLS certificate as well. This should not work at all. Also we have HTTPS everywhere, but DKIM is still not supported by most domains. That is a more serious issue and it also covers this as well.

gog 6y ago
You can get an IP address as a SAN, but that doesn't mean much because unless configured to do so, most email servers will not validate and reject invalid certificates on a destination mail server.
judge2020 6y ago
> With IP addresses, it is not possible to validate TLS certificate as well. This should not work at all. Technically the CA/B forum hasn't outlawed TLS certificates for IP addresses, and a few live ones exist. https://1.1.1.1 https://1.1.1.1 plus https://[2606:4700:4700::1111]/ https://[2606:4700:4700::1111]/ https://crt.sh/?q=8.8.8.8 https://crt.sh/?q=8.8.8.8
- judge2020 6y ago
  https://8.8.8.8/test https://8.8.8.8/test

monkaiju 6y ago

If you need a way to keep tabs on a bunch of DNS records check out dug: https://github.com/unfrl/dug https://github.com/unfrl/dug

ratsbane 6y ago

dig myspecialdomainwhatever.com MX for anyone like me who had to look that up. (And I'm far from competent on DNS matters so please correct if there's a better way)

kureikain 6y ago

I run an email forwarding services so I understand mail system quite well. IMHO, no one seems to use IP in DNS record, probably someone just do quick and dirty and forgot config. Because when putting IP, when you change your server you have to tell all people to update MX records. So you usually see service use mx1 mx2 style domain. Nowadays, peolple rarel setup mail server and use 3rd solution and they usually alreayd use domain name in their DNS record. So this advice is for people who run their own server who really should know their stuff already.

bullen 6y ago

2 DNS requests per mail is not efficient. You should recompile Courier!