- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
The predecessor created an abhorrent way to bypass DNS Over HTTPS.
Admin
You say abhorrent I say "tell me more".
Admin
Too lazy to look... but there might be a difference in behavior under various circumstances... What if the domain is in the hosts file? What if there are multiple DNS sources [I think this only checks the first].... so many questions...
Admin
It's worth noting that this method also obtains the wrong address, and might even, in certain cases, give the wrong answer.
Finding the correct address involves an initial search for the name's MX (Mail eXchanger, I think) record, and then falling back to the A or AAAA record if there's no MX record. (Noteworthy: It probably searches only for the A record, so it won't work correctly for an IPv6-only mailserver, although there probably aren't many of those yet.)
And if there's an MX record but no A record, it will say "No" when it should say "Yes".
Addendum 2024-01-23 06:53: Observation: there probably aren't many places with an MX but no A, but ...
Admin
I searched in the Microsoft documentation it appears Dns.GetHostEntry was added with .NET Framework 2.0 and IPEndPoint first appeared in .NET Framework 1.1. This means that if the code was written after April 2003 and before November 2005. Arguably it could even be several years later because most developers will not immediately start using new features the day they're released and there might not be many solutions on sites such as Stack Overflow (which was created in 2008) from day one. Alternatively, developers could be stuck for whatever good (or bad) reason on older Framework versions.
In my job I frequently run into WTF that are only there because back in the day they were reasonable solutions.
Admin
Actually, I think that
Convert.ToByte("15")is trying to look for an MC record type. So it will fail on sites which have an A or AAAA but no MX.Addendum 2024-01-23 07:56: s/MC/MX/
Addendum 2024-01-23 07:56: s/MC/MX/
Admin
Yeah, now if a string contains exactly one '@' it's pretty much a valid mail address. Any other validation is pretty much useless, especially since the host part can now contains basically every character.
BTW the correct way to validate an email is by sending a mail to given address with a confirmation link and give the user a day to respond. Everything else is useless.
Admin
"Built in" or "built-in." Not "build in."
Admin
this depends on a specific version of DNS and will fail in many cases
Admin
Haven't heard anyone pile on with this nugget: some DNS records don't fit in a UDP packet, so every modern DNS server will also respond to a TCP request to get the full story. That's why you have to let both UDP 53 and TCP 53 through your firewalls. Ever wonder why sometimes things work, and not others? :)
Admin
An A record may exist, but it may not respond to a UDP package. Or behind a firewall rule which drops all UDP packages, except for a few selected port numbers. Or it's just a vanity domain, where the A record point to an unreachable host, and the MX record to a mail handler.
Admin
The local part can be a quote string which itself can contain @ and other special characters. For example "@"@mydomain.com is a valid email address. Evil, but valid.
Admin
If you look at the packet the code is constructing, it's a DNS packet with a single Query for an MX record for that domain name.
Taking a look at the first part: ByteList.AddRange(new byte[] { 88, 89, 1, 0, 0, 1, 0, 0, 0, 0, 0, 0 }); The first two bytes set a static ID of 0x8889 (which can be a security concern if you're worried about an active attacker trying to spoof your DNS cache). The next two bytes (1, 0) set flags; in this case just Recursion Desired, instructing the DNS server you're asking to try to ask other servers if it doesn't have the answer. The next two (0, 1) set the number of Questions (in this case, 1). The rest say we have 0 Answers, 0 Authority records, and 0 extra Resource records.
Now we start constructing the Query. The first part is the domain name in DNS format, which we generate with the foreach loop across HostName.Split('.'). Each label in the domain name gets a length byte and then the label.
But we're not done with encoding the domain name yet, because the last label has to be a 0-length label to indicate the end of the domain name. So the final piece: ByteList.AddRange(new byte[] { 0, 0, Convert.ToByte("15"), 0, 1 }); adds a 0 byte to show the end of the domain name. Then we add a 0 and a 15 (0x000F) to say that our QTYPE is 15 (MX, or Mail eXchange), and finally a 0 and a 1 (0x0001) to say that our QCLASS is 1 (IN, or INternet).
Now the response checking is very rudimentary. First we check if byte 3 of the response is 128 (0x80); having that high bit set means it's a Response, but requiring that all the other bits are 0 means among other things that the Authoritative Answer bit is clear, which means this code will fail if the server you're asking happens to be authoritative for that domain (like if you're asking your own domain). But this is unlikely to fail in practice. Then we check if byte 7 (which is the low byte of the "number of Answers" count) and fail if it's 0 (we should be checking bytes 6 and 7 for 0x0000 instead).
Admin
But you know it's really because they just wanted to make the compiler error go away.
Admin
I am the original poster. Of course the day after deploying the simplified code , we ran into the problem pointed out by stoborrobots: Validating an email for a domain with no A record fails. So, the original code was more correct than my replacement. I fixed it by replacing the whole mess with the DnsClient nuget package, which will also handle a lot of the other issues pointed out.
Admin
Maybe not, but it is allowed. The MX record can point to any server with an A record it likes. There may not be a server, for example, that has a DNS name of
jeremyp.net(there is in this case, as it turns out but ignore that). However, the MX record forjeremyp.netpints atmx.supanames.co.ukwhich, I presume is the mail server that handles my inbound mail.Not only that, but you can have multiple MX records all pointing at different A records to provide redundancy.
Even if you get a valid domain, there's no guarantee that the bit before the
@is valid. The only way to truly validate an email address is to send an email to it that asks the recipient to respond in some way e.g. by clicking a one use web link. My rule is that, if you are not prepared to go that far, there's no real point in doing any validation beyond making sure it has an@and the bit after the last@is well formed.Admin
Furthermore: it's entirely plausible for a host record to have an IP address via an A (or a quad A) record, as well as an MX record that points to a host with a completely different address. Meaning that the IP address you get from an A or quad A lookup may actually be for a host that doesn't handle mail for that specific hostname.
It would be viciously evil to set up one's network in that way, but it's entirely legitimate by the rules of MX lookups. And come to think of it, that could be a mildly useful anti-spam measure. Perhaps. Probably not (I am not a mail admin.)
Admin
Having the MX record point to a different server than a domain's main A (or AAAA) record is common practice for a lot of shared web hosts.
Admin
ONLY TODAY! 50% discount on bases for XRumer and GSA SER + activation keys for GSA Search Engine Ranker! https://en.xrumerbasee.ru/ To contact us, write to telegram https://t.me/DropDeadStudio, When contacting, mention promo code DDS50.