Correct, the SPF record doesn't return an private IP (how did you find out it was goteborg.se mail server as I didn't mention it lol?) However, the A record in question is intended for SPF record (which can be found out by the SPF in the label) which means, it should not return a private IP adress for ANY reason.
Even if a private adress is syntaxically valid, why bother with private adresses, when ANY IP-adress has SAME meaning. Then you could aswell return a public IP to be on the safe side. The problem with your argument that firewalls shouldn't touch DNS response packets, is problematic, as DNS rebinding is a new threat, where a malicious actor on the internet, have a link, lets say, 039840684084.example.org for which a malicious DNS server first will respond with the real IP adress, and then it will respond with for example, 127.0.0.1 Then it bypasses CORS protection in the browser, and the malicious site, is able to edit for example settings in local devices (for example many 4G modems are managed through localhost) but also, it can respond with another private adress to access routers and such. The reason it bypasses CORS protection in browser is because, from the browser's point of view, 039840684084.example.org is same as 039840684084.example.org, regardless which IP it actually resolves to, giving the malicious actor same-origin access to the local host and the malicious actor can use a malicious javascript to edit local settings or access devices. The firewall's job is to protect the network against threats, and thus, its totally legit to drop DNS response packets from WAN side which contains unrouteable IP adresses. -----Ursprungligt meddelande----- Från: Gellner, Oliver via mailop <[email protected]> Skickat: den 17 juni 2025 22:23 Till: Mailing List <[email protected]> Ämne: Re: [mailop] iphmx.com - who owns that server (SPF fault) > On 17.06.2025 at 14:26 sebastian via mailop wrote: > > >>RFC 5782 states: > > Thats for DNSBL/DNSWL, where its easy to tell the firewall that, don't touch > any response packets from dnswl.org and then it don't matter. My take on this: A firewall should not touch *any* DNS packets. Reasons on why not to do that can be seen in this thread. Middleboxes which do not understand what‘s going on and prefer to break traffic flows to be on the safe side are not a good argument to restrict or change the way how protocols and technologies are being used. I wouldn’t say that Goteborgs SPF record returns private IP addresses. It does actually not return any IP address at all, but only a syntactically valid representation for „match“ or „true“. >>> RFC 7208 states: > > Yes that applies to the SPF client. A firewall between the SPF client and > server cant know the packet is meant for a RFC 7208 client. > >>> Presumably, a mail server should not consult a DNS hacked for browsers? > > Presumably, a firewall located between LAN and WAN has no way to know if the > UDP packet is for a SPF client or browser. It sees a DNS response packet > coming from a server on the WAN side that is not in the firewall's list of > servers permitted to bypass DNS Rebinding orotection, finds a private IP in > the response, and throws the UDP packet in the dustbin. — BR Oliver ________________________________ dmTECH GmbH Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe Telefon 0721 5592-2500 Telefax 0721 5592-2777 [email protected]<mailto:[email protected]> * www.dmTECH.de<http://www.dmtech.de> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927 Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher ________________________________ Datenschutzrechtliche Informationen Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie hier<https://www.dm.de/datenschutzerklaerung-kommunikation-mit-externen-493832>. _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
