Re: [mailop] contact at google
In article <20200411183502.ga31...@hesketh.com> you write: >And yet, for years, Google has been doing reverse-octet lookups against >it. ... Can you provide a list of IPs that are sending the queries? I'd think that would be a lot more likely to identify the culprint than "Google". Remember that Google is also a big cloud hoster so it may be clueless customers. >1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: NOERROR/0/50 ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
On 2020-04-13 15:00, Steven Champeon via mailop wrote: on Mon, Apr 13, 2020 at 11:54:17AM -0700, Brandon Long wrote: Are you sure this isn't just the Google Public DNS servers? Why would a DNS server be querying our mirrors? it's kinda the obvious use-case innit? I can guarantee that Gmail/Google doesn't do external rbl queries for live traffic[1]. There might be some dashboard around that someone uses to see if any of our addresses are on various rbls, though I haven't seen those used in a long time and I don't see that hostname at all in our configs. Doesn't rule out someone having their own script, I guess. That's kind of what I figure, but it's still epically stupid to do reverse octet style queries against a server that is customized to handle a completely different style of lookup. None of them will ever return a useful result, period, because that's not what those zones are for. I'd really like it if they would knock it off. This sounds very much like seriously clueless lusers using google public DNS servers. "ooh blacklist, shiny!". Firewall it. ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
> Why would a DNS server be querying our mirrors? Have you ever seen anyone instruct anyone else to use 8.8.8.8 or 8.8.4.4 as the DNS server configured on their platform? I might even go so far as to surmise that would be a default configuration in the VPSes of more than one provider. -- Atro Tossavainen, Chairman of the Board Infinite Mho Oy, Helsinki, Finland tel. +358-44-5000 600, http://www.infinitemho.fi/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
on Mon, Apr 13, 2020 at 11:54:17AM -0700, Brandon Long wrote: > Are you sure this isn't just the Google Public DNS servers? Why would a DNS server be querying our mirrors? > I can guarantee that Gmail/Google doesn't do external rbl queries for live > traffic[1]. There might be some dashboard around that someone uses to see > if any of our addresses are on various rbls, though I haven't seen those > used in a long time and I don't see that hostname at all in our configs. > Doesn't rule out someone having their own script, I guess. That's kind of what I figure, but it's still epically stupid to do reverse octet style queries against a server that is customized to handle a completely different style of lookup. None of them will ever return a useful result, period, because that's not what those zones are for. I'd really like it if they would knock it off. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ Internet security and antispam hostname intelligence: http://enemieslist.com/ ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
Are you sure this isn't just the Google Public DNS servers? I can guarantee that Gmail/Google doesn't do external rbl queries for live traffic[1]. There might be some dashboard around that someone uses to see if any of our addresses are on various rbls, though I haven't seen those used in a long time and I don't see that hostname at all in our configs. Doesn't rule out someone having their own script, I guess. Blocking the public dns servers from your rbl seems like a fairly common thing for people to do so you can properly attribute who is using your RBL. Oh, and although we mostly don't allow mail sending on GCE, there are some mail receivers, so we it's possible it's a cloud customer, the IPs for GCE are fairly separate (ie, not in _netblocks.google.com) Brandon [1] Us querying an external RBL in real-time would be a great way to DoS an RBL, especially one with a sparse matrix like yours On Sat, Apr 11, 2020 at 11:37 AM Steven Champeon via mailop < mailop@mailop.org> wrote: > > Are there any Google folks here? > > We have a few rbldnsd mirrors, hosting a custom DNSBL for Enemieslist > which is not your standard reverse-octet IP-based lookup (instead, you > pre-pend a PTR record or HELO to the zones before you query, and get a > reply that lets you know how we've classified that naming convention). > An A query gets you the class and TXT gets you the "tech" (eg, "dsl", > "dialup" "cable", etc.) > > And yet, for years, Google has been doing reverse-octet lookups against > it. I'd rather they don't, but don't know who at Google is doing it. > It's dumb, because they will never receive a useful response, and it's > just adding to the load on our mirrors. And we actually have people who > want to use it for the proper purpose. > > eg: > > 1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: > NOERROR/0/50 > > So, if anyone at Google can figure out who controls whatever experiment > is epically failing and has been for a long time, I'd appreciate a hand in > making it stop. > > Thanks, and stay safe, > Steve > > -- > hesketh.com/inc. v: +1(919)834-2552 <(919)%20834-2552> f: +1(919)834-2553 > <(919)%20834-2553> w: http://hesketh.com/ > Internet security and antispam hostname intelligence: > http://enemieslist.com/ > > ___ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] contact at google
I should point out, _spf.google.com actually includes three netblocks sub records, _netblocks is not all of them. Brandon On Mon, Apr 13, 2020 at 11:54 AM Brandon Long wrote: > Are you sure this isn't just the Google Public DNS servers? > > I can guarantee that Gmail/Google doesn't do external rbl queries for live > traffic[1]. There might be some dashboard around that someone uses to see > if any of our addresses are on various rbls, though I haven't seen those > used in a long time and I don't see that hostname at all in our configs. > Doesn't rule out someone having their own script, I guess. > > Blocking the public dns servers from your rbl seems like a fairly common > thing for people to do so you can properly attribute who is using your RBL. > > Oh, and although we mostly don't allow mail sending on GCE, there are some > mail receivers, so we it's possible it's a cloud customer, the IPs for GCE > are fairly separate (ie, not in _netblocks.google.com) > > Brandon > > [1] Us querying an external RBL in real-time would be a great way to DoS > an RBL, especially one with a sparse matrix like yours > > On Sat, Apr 11, 2020 at 11:37 AM Steven Champeon via mailop < > mailop@mailop.org> wrote: > >> >> Are there any Google folks here? >> >> We have a few rbldnsd mirrors, hosting a custom DNSBL for Enemieslist >> which is not your standard reverse-octet IP-based lookup (instead, you >> pre-pend a PTR record or HELO to the zones before you query, and get a >> reply that lets you know how we've classified that naming convention). >> An A query gets you the class and TXT gets you the "tech" (eg, "dsl", >> "dialup" "cable", etc.) >> >> And yet, for years, Google has been doing reverse-octet lookups against >> it. I'd rather they don't, but don't know who at Google is doing it. >> It's dumb, because they will never receive a useful response, and it's >> just adding to the load on our mirrors. And we actually have people who >> want to use it for the proper purpose. >> >> eg: >> >> 1586629389 172.253.12.1 198.211.246.23.g.enemieslist.com A IN: >> NOERROR/0/50 >> >> So, if anyone at Google can figure out who controls whatever experiment >> is epically failing and has been for a long time, I'd appreciate a hand in >> making it stop. >> >> Thanks, and stay safe, >> Steve >> >> -- >> hesketh.com/inc. v: +1(919)834-2552 <(919)%20834-2552> f: +1(919)834-2553 >> <(919)%20834-2553> w: http://hesketh.com/ >> Internet security and antispam hostname intelligence: >> http://enemieslist.com/ >> >> ___ >> mailop mailing list >> mailop@mailop.org >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
