[HN Gopher] Please do not put IP addresses into DNS MX records
___________________________________________________________________
Please do not put IP addresses into DNS MX records
Author : hannob
Score : 128 points
Date : 2021-02-21 17:07 UTC (5 hours ago)
(HTM) web link (blog.hboeck.de)
(TXT) w3m dump (blog.hboeck.de)
| dwd wrote:
| 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.
| tlb wrote:
| 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/ and it'd resolve to 1.2.3.4. But not
| now.
| strenholme wrote:
| I have written a very simple (IPv4/IPv6 addresses only) DNS
| server which can use Lua to determine the IPs to return to the
| user (It was my big "do cool open source during the pandemic"
| project). To implement this particular problem, I whipped up
| this Lua script: -- This script is to be run by
| coLunacyDNS -- This script takes a query like
| 10.1.2.3.ip4.invalid. and returns the -- corresponding IP
| (e.g. 10.1.2.3 here) -- Change these IPs to the
| actual IPs the DNS server will run on bindIp =
| "127.0.0.1" -- We bind the server to the IP 127.0.0.1
| bindIp6 = "::1" -- Localhost for IPv6 function
| processQuery(Q) -- Called for every DNS query received
| if Q.coQtype == 1 then local query = Q.coQuery
| if query:match("^%d+%.%d+%.%d+%.%d+%.ip4%.invalid%.$") then
| local ip = query:gsub("%.ip4%.invalid%.$","")
| return {co1Type = "A", co1Data = ip} end else
| return {co1Type = "notThere"} end return
| {co1Type = "notThere"} end
|
| One will need coLunacyDNS to run this script:
| git clone https://github.com/samboy/MaraDNS cd
| MaraDNS/deadwood-github/tools/coLunacyDNS make sudo
| cp coLunacyDNS /usr/local/bin
|
| Full documentation for coLunacyDNS is available:
|
| https://github.com/samboy/MaraDNS/blob/master/deadwood-githu...
| 1_player wrote:
| http://xip.io/ does, until it's turned off.
| sofixa wrote:
| What do you mean turned off?
| lucb1e wrote:
| 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 wrote:
| 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 wrote:
| 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-
| githu...
| gnfargbl wrote:
| addr.host, e.g. https://209.216.230.240.addr.host/
| enduser wrote:
| in-addr.arpa is for reverse lookups. It is how IPs resolve to
| names. The address is reversed to allow delegation of IP ranges
| to DNS servers that are "closer" to the IP address.
|
| Only the absence of a matching in-addr.arpa record would "look
| up" to the IP itself (by failing to look up to a name).
| tlb wrote:
| Sure, the PTR record gives the name. But I seem to remember
| it also returning A records with the corresponding IP
| address.
| baby wrote:
| Don't you have to if you use cloudflare to protect your domain?
| chrisseaton wrote:
| > 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.
| brey wrote:
| 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 wrote:
| 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.
| tinus_hn wrote:
| 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 wrote:
| >> 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 (Page 3)
|
| In general, we expect systems to be forgiving.
| DaiPlusPlus wrote:
| 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.
| chrisseaton wrote:
| Do you want to send people email?
|
| Then you'll need to be liberal in what you accept.
| tedunangst wrote:
| Why can't the other party be conservative in what they
| send?
| chokeartist wrote:
| Go back to reddit. RFCs are standards but real life
| requires acceptance of divergence from the exact letter
| of the law.
| chrisseaton wrote:
| > 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.
| hannob wrote:
| I thought about adding that, I should've...
|
| It's widely believed these days that postel's law was a
| mistake.
| jeff-davis wrote:
| 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.
| corndoge wrote:
| 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 wrote:
| 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.
| jeff-davis wrote:
| Everything has to do with security. Especially message
| formats like JSON.
|
| Accepting a non-conforming message could easily lead to
| injection.
| yjftsjthsd-h wrote:
| JSON libraries _are_ security-sensitive, though; they
| tend to get used on content coming from 3rd parties over
| the internet.
| woodruffw wrote:
| > 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 wrote:
| 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 wrote:
| > 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.
|
| This is a _great_ example of "paving over bad behavior
| with worse behavior."
|
| If JSON is specified to only represent numbers that fit
| within a JavaScript double, then a correct parser must
| fail on numeric literals that don't fit into that type.
| It's up to me as a consumer to _interpret_ strings that
| represent larger numbers.
|
| I've had this _exact_ kind of "helpful" behavior cause
| potentially exploitable bugs in programs before: a
| complex system was using more than one JSON parser, and
| parser Foo would accept numeric inputs that parser Bar
| would silently fail on (mangling large numbers into
| garbage). The result was a potential arbitrary read
| primitive.
| deathanatos wrote:
| > _If JSON is specified to only represent numbers that
| fit within a JavaScript double,_
|
| It isn't / doesn't make that restriction. For example,
| 100000000000000000000000000000000000000000000000000000000
| 00000000 000000000000000000000000000000000000000000
| 00000000000000000000000 000000000000000000000000000
| 00000000000000000000000000000000000000 000000000000
| 00000000000000000000000000000000000000000000000000000
| 000000000000000000000000000000000000000000000000000000000
| 00000000 000000000000000000000000000000000000000
|
| is a valid JSON value. Python will decode it to an
| integer with the equivalent value; JavaScript will decode
| it to "Infinity", as it exceeds the limits of Number.
| (Despite nowadays having a bigint type that _could_
| represent it.)
|
| It is possible to write a JSON parser in JavaScript that
| would handle decoding large numbers to BigInts. Most
| people just don't bother, as it's pretty rare to need to
| go above the 2 * 53 limit of JS's number.
| dang wrote:
| I added some newlines to your number because it was
| borking the page layout. Sorry; it's our bug.
| woodruffw wrote:
| You're absolutely right about that, and that's _even
| worse_ than I had remembered! Not only can two parsers
| not be trusted to have equivalent acceptance contracts
| (in the absence of bugs), but they can _correctly_
| disagree on the acceptance of a single input!
|
| The actual RFC language[1]:
|
| > This specification allows implementations to set limits
| on the range and precision of numbers accepted. Since
| software that implements IEEE 754-2008 binary64 (double
| precision) numbers [IEEE754] is generally available and
| widely used, good interoperability can be achieved by
| implementations that expect no more precision or range
| than these provide, in the sense that implementations
| will approximate JSON numbers within the expected
| precision.
|
| [1]: https://tools.ietf.org/html/rfc7159#section-6
| josefx wrote:
| I prefer not having to maintain code that is overly
| flexible with its input. Last time I ran into half a page
| of workarounds for bad input I spend a day tracking down
| all affected files and making sure I could either ignore
| or fix them. The result was a neat little string
| comparison that didn't have half a dozen unpredictable
| edge cases.
| mytailorisrich wrote:
| It's important to consider each decision. Sometimes it is
| not fine to be liberal, sometimes it is.
|
| In this case, I'd say that an MX record containing an IP
| address is not a big deal versus an MX pointing to an A
| record that contains an IP address, so one may consider
| that it makes sense to favour successful delivery of
| emails over strict enforcement of the standard and to
| accept it. That's pretty much what Postel's law is about
| and why many servers do accept it (though it also makes
| sense for a server to refuse to be configured that way
| even if it accepts it externally for robustness).
|
| Postel's law is not an anachronistic concept. This sort
| of design consideration applies everywhere in the real
| world.
| JdeBP wrote:
| 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/dcwx0W
| c7yp...
|
| > 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/i...
| sneak wrote:
| 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.
| eznzt wrote:
| Unless I'm missing something, the standard sounds pretty
| stupid
| JdeBP wrote:
| 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. (-:
| tsimionescu wrote:
| 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.
| js2 wrote:
| 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.
| andy_ppp wrote:
| 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.
| eknshow wrote:
| I don't think you appreciate how old DNS is or why it uses
| the data structures it does.
| apple4ever wrote:
| That's how I feel. Specific records should not specify if
| its a domain name or an IP. They both should be accepted.
| tsimionescu wrote:
| 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.
| bawolff wrote:
| 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 wrote:
| And that causes problems too right?
| bawolff wrote:
| Does it? I've never heard anyone complain
| chrisseaton wrote:
| > 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?
| osrec wrote:
| But does the standard make sense? What's the rationale for
| not using an IP address?
| tsimionescu wrote:
| 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).
| Tomte wrote:
| 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.
| qwerty456127 wrote:
| > 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 wrote:
| 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.
| strenholme wrote:
| 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 wrote:
| > _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 wrote:
| Thank you for pointing out the typo; I have corrected the
| grandparent.
| Svip wrote:
| > While .foo is a real top level domain, Google doesn't let the
| public register names in it.
|
| For the record, example.com, example.net and example.org are
| reserved domains, that cannot be used. So you can always use
| those as safe examples.
| https://en.wikipedia.org/wiki/Example.com
| https://tools.ietf.org/html/rfc2606
| eknshow wrote:
| > Oh, DNS is full of these kinds of "not in a RFC but needed to
| resolve names" corner cases.
|
| What? It's in RFC 1035, and that's noted in the article. There
| is lots of corner cases in the DNS. This is not one.
| JdeBP wrote:
| It was dnscache.
|
| *
| http://jdebp.uk./Softwares/djbwares/guide/commands/dnscache....
|
| * http://cr.yp.to/djbdns/dnscache.html
|
| And it wasn't to do with bailiwick at all. It was to do with
| the fact that many softwares allowed users to enter either IP
| addresses or domain names; but either left recognizing IP
| addresses up to the DNS client libraries, some of which would
| in turn fail to do so and just treat them as domain names, or
| recognized IP addresses in a form that users would forget to
| use, such as having them enclosed in square brackets. M.
| Berstein's own DNS client library, and several others, do the
| same thing that dnscache did, in the client library itself,
| implementing this same defence at multiple layers of the
| system.
|
| * https://cr.yp.to/djbdns/dns.html
|
| A related scenario: Some Unix/Linux softwares allow one to
| specify users by either ID or name, but fail to take advantage
| of the fact that the colon is prohibited in account names, and
| so can be used as a syntax for unequivocally distinguishing
| between the twain. As a result, strings like "0" can
| potentially be mapped to something other than the superuser if
| someone goes and creates a user account with the name "0"
| (whereas ":0", as in the syntax for some tools, is
| unequivocally user ID zero and "0" generates an error unless
| there is actually an account by that name). This in turn leads
| to people arbitrarily banning account names with digits, and
| security holes resulting when the action upon encountering
| attempts to use such a name is to just ignore them. Recall the
| "User=0pointer" kerfuffle in systemd.
| sally1620 wrote:
| 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.
| nvr219 wrote:
| I've been janitoring email for years and have never seen someone
| put an IP address in an MX record.
| leephillips wrote:
| He gathered some data and found 0.06% were doing this.
| hobofan wrote:
| 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).
| lucb1e wrote:
| _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.
| Daviey wrote:
| 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"
| VWWHFSfQ wrote:
| > 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.
| JdeBP wrote:
| And here we see someone exemplifying why Gresham's Law trumps
| Postel's Principle. Bad protocol implementation drives out the
| good because of exactly this sentiment.
| treve wrote:
| 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 wrote:
| 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
| tuwtuwtuwtuw wrote:
| 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.
| LocalH wrote:
| It's valid to choose to use strict standards-conforming
| software. It's quite arguable that such lenient mail servers
| are broken in this fashion, since the spec requires a domain
| (and thus IP addresses are not valid in MX records).
| scandox wrote:
| Another one to avoid is using a CNAME in the MX. It will work
| until it doesn't.
| lucb1e wrote:
| 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.
| t0mas88 wrote:
| 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.
| momszack wrote:
| > 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.
| teddyh wrote:
| 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 wrote:
| At some point someone's going to get the .0 to .255 TLD somehow
| and cause a security fuffle.
| teddyh wrote:
| 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 wrote:
| 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.
| userbinator wrote:
| According to RFC 1123:
|
| _However, a valid host name can never have the dotted-
| decimal form #.#.#.#, since at least the highest-level
| component label will be alphabetic_
|
| https://tools.ietf.org/html/rfc1123#page-13
| Dylan16807 wrote:
| Finally, 359.33.9.234 can be real.
| cadence- wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| What if it's an AAAA record?
| stonesweep wrote:
| 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]
| s800 wrote:
| > set qu=mx > gmail.com. Server: 10.1.1.1 Address:
| 10.1.1.1#53
|
| Non-authoritative answer: gmail.com mail exchanger = 20
| alt2.gmail-smtp-in.l.google.com. gmail.com mail exchanger
| = 5 gmail-smtp-in.l.google.com. gmail.com mail exchanger
| = 40 alt4.gmail-smtp-in.l.google.com. gmail.com mail
| exchanger = 10 alt1.gmail-smtp-in.l.google.com. gmail.com
| mail exchanger = 30 alt3.gmail-smtp-in.l.google.com.
|
| Authoritative answers can be found from: > set qu=aaaa >
| gmail-smtp-in.l.google.com. Server: 10.1.1.1 Address:
| 10.1.1.1#53
|
| Non-authoritative answer: gmail-smtp-in.l.google.com has
| AAAA address 2607:f8b0:4001:c05::1a
| mlyle wrote:
| Sure, but it has A records _too_.
| jeffbee wrote:
| RFC 5321 is ambivalent of A vs. AAAA. When discussing the
| matter, 5321 says "A or AAAA RR". It later says about
| IPv6 that "The appropriate actions to be taken either
| will depend on local circumstances." When I re-wrote
| Gmail's DNS libraries about 6 years ago, I wrote it to
| start with AAAA and fall back to A. So if you have an MX
| and AAAA records for those names, you should notice all
| your inbound from Google comes via IPv6.
| [deleted]
| jcims wrote:
| I can see the value in pointing at a name so TLS can
| validate correctly, but I don't see any value in limiting
| it to an A record.
| geocrasher wrote:
| I fixed it, that was a brain fart.
| quotemstr wrote:
| Pointing to a CNAME isn't legal, but it should be. This
| particular limitation never made any sense to me and it
| should be lifted.
| vetinari wrote:
| That would require updating too much software in the
| field.
|
| Meanwhile you can use ALIAS record and get the same
| result, without others noticing.
| fred256 wrote:
| Sorry to be pedantic, but there is no such thing as an
| ALIAS record. It's just the DNS server doing the
| indirection for you.
| teddyh wrote:
| There is no such thing as an ALIAS record. That's
| something your DNS provider made up and shows to you in
| the interface, but behind the scenes they are providing
| the same old AAAA and A records as always, along with
| some sort of auto-updating feature which they will run to
| detect changes in the address of the name in the "ALIAS
| record". How often this will update is anyone's guess as
| it's up to the DNS provider.
|
| See:
| https://en.wikipedia.org/wiki/CNAME_record#ANAME_record
| teddyh wrote:
| The RFC doesn't "forbid" using IP addresses in MX records -
| it's physically impossible to have them. The fact that the IPv4
| address syntax is also parseable as a domain name is unrelated;
| what is physically stored inside the MX record is a textual
| domain name.
| chrismorgan wrote:
| If it's an IP address, you're restricting it to IPv4 or IPv6.
| If it's a name, then it can work on both IPv4 and IPv6.
|
| You want pretty much everything but A and AAAA records to use
| domain names for pointing, so that they're not tied to a
| particular version of IP. Keep the IP resolution to the last
| step only, and let everything else use domain names.
| gorgoiler wrote:
| So you can have multiple address for the same MX, eg IN A
| 10.77.0.1 and IN AAAA fd77::1.
| jpalomaki wrote:
| Looks like this goes back to the days when Internet with TCP/IP
| was not yet the only option and when there was also other
| networks available (Chaosnet). [1]
|
| For the A records you can different classes of addresses.
| Nowadays we are using the "IN", but the spec also supports
| others like "CH" (Chaos) and "HS" (Hesiod).[2]
|
| MX record points to mail.example.org (A-record).
| mail.example.org could then point to two different addresses in
| the different networks, using the different classes. Depending
| on what network the client is connected to, it can request
| specify the class in the query and get address on the correct
| network.
|
| I guess they could have baked this in to the MX records as
| well, but that would have made it more complicated.
|
| Disclaimer: Just googled this up.
|
| [1] https://serverfault.com/questions/663112/why-cant-mx-
| records... [2] https://serverfault.com/questions/220775/what-
| does-the-in-me...
| Natsu wrote:
| I guess nowadays that should still be useful to give both an
| IPv4 and IPv6 address for the mail server?
| [deleted]
| monkaiju wrote:
| If you need a way to keep tabs on a bunch of DNS records check
| out dug: https://github.com/unfrl/dug
| userbinator wrote:
| 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.
___________________________________________________________________
(page generated 2021-02-21 23:00 UTC)