Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

net: LookupMX does not consider IP addresses as valid records #56025

Open
horkhe opened this issue Oct 4, 2022 · 5 comments
Open

net: LookupMX does not consider IP addresses as valid records #56025

horkhe opened this issue Oct 4, 2022 · 5 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Backlog

Comments

@horkhe
Copy link

horkhe commented Oct 4, 2022

This is a followup to #46979. I found another case where https://golang.org/cl/322230 broke the original logic. Even though MX records MUST contain domain names, occasionally they contain IP addresses. And this change considers IP addresses as invalid records and returns an error making delivery to respective email service providers impossible. The number of such cases is minuscule in the great schema things, but still we at Mailgun handle a few thousand messages to such email providers per hour. So in the spirit of Robustness Principal I believe a change should be made to allow IP addresses in MX records.
@horkhe
Copy link
Author

horkhe commented Oct 6, 2022 •
edited

By the way we ran into similar issue: the LookupSRV function does not work well with Nomad/Consule that exposes instance ip:port via SRV records, but LookupSRV enforces domain names. So guys, maybe you should stop trying to "fix" the Internet and just make resolver methods return whatever DNS servers provide you with. Or at least provide us with a way to disable the annoying validation.

@cagedmantis cagedmantis changed the title net: LookupMX behaviour broken 2 (continuation of #46979) net: LookupMX does not consider IP addresses as valid records Oct 6, 2022
@cagedmantis cagedmantis added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Oct 6, 2022
@cagedmantis cagedmantis added this to the Backlog milestone Oct 6, 2022
@cagedmantis
Copy link
Contributor

@ianlancetaylor @neild

@dcormier
Copy link
Contributor

I've noticed this a bit, lately. Here's a handful of domains with MX records where at least one is an IP address (as of 2024-04-19):

  • testsys.com
  • eohu.ca
  • libertyhardware.com
  • sbc-holding.com
  • victoriafallshotel.com
  • lucelec.com
  • clearchannel.com.br
  • thefloow.com
  • cityofscottsboro.com

@ianlancetaylor
Copy link
Contributor

CC @rolandshoemaker @golang/security

@mateusz834
Copy link
Member

We currently support domain names that contain digits in arbitrary places, but it also has to contain at least one non-digit character (except dots).

go/src/net/dnsname_test.go

Line 22 in 903e0ff

{"26.0.0.73.com", true},

Also RFC 1123:

2.1 Host Names and Numbers
The syntax of a legal Internet host name was specified in RFC-952
[DNS:4]. One aspect of host name syntax is hereby changed: the
restriction on the first character is relaxed to allow either a
letter or a digit. Host software MUST support this more liberal
syntax.

RFC 8499:

Note that any label in a domain name can contain
any octet value; hostnames are generally considered to be domain
names where every label follows the rules in the "preferred name
syntax", with the amendment that labels can start with ASCII
digits (this amendment comes from Section 2.1 of [RFC1123]).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Backlog
Development

No branches or pull requests
5 participants
@cagedmantis @dcormier @horkhe @ianlancetaylor @mateusz834