blechschmidt

AFAIK, there are even companies that own hundreds of registrars to just do that [1]. Just scroll through [2].

[1]: https://domainnamewire.com/2015/10/09/wow-dropcatch-adds-300...

[2]: https://www.iana.org/assignments/registrar-ids/registrar-ids...

Blocking a /64 is not even enough in many cases. I know a couple of server providers handing out a /48 per server. If routing is done the right way, you can pretty easily randomize your source address by making use of features like AnyIP and add a whole prefix to your network interface. I have written a small tool to demonstrate this: https://github.com/blechschmidt/freebind

Solutions to this problem that try to avoid penalizing other users sharing a prefix will certainly be interesting. Some approaches ban per /128 and extend this ban to a /64 if two or three addresses within the /64 got banned.

In my opinion, it is dangerous to draw conclusions about responsibility from phone usage only. Even if the conclusions may be correct in 95% of all cases, what about the other five percent? To me, the imagination of a company that does not provide any or only superficial customer support which will not help me in case their algorithms do not match is creepy.

In this case it might not be a big deal because you might be able to find another loan provider but it might become one if this kind of automated scoring gets more common.

I find the title confusing. At first I thought the post was about DNS hijacking or something similar. However, the phishing attack does not make use of identical domains but homographs.

You could use libnetfilter_queue and some DNS library like ldns to parse the packets and drop them if the DNS question contains "xn--".

A possibility to break these might consist in using Google's image reverse search and check whether the word which you are supposed to identify images for appears on the result pages. However, the Google search is protected by reCaptcha - so you could build your own image reverse search or you use one implementing captchas which are easier to break.

Otherwise, if you own a highly frequented website, you could ask your users to solve the captchas for you by proxying the challenges to them.

This might already filter out legitimate users.

  dig MX io.

Also, you don't know what new TLDs ICANN might come up with at some point. I am pretty sure there are service providers that do and did limit the TLD length and then TLDs like xn--vermgensberatung-pwb came up.

This is probably a better approach if your domain provider supports wildcard DNS records. My old provider did not and I am very glad I switched.

I do not use Gmail but a self-hosted Postfix instance. I have configured an alias for tagged use only and configured Postfix to reject all emails to this alias without a tag. This means that currently any tag will be delivered but luckily, I am not receiving any spam to this address at all.

Originally, I wanted to create a Postfix filter based on an HMAC together with a browser extension which would simply let me generate new valid email addresses in the form of prefix.HMAC(secret, prefix)@example.com but I have never implemented it.

Yes, the + is incredibly useful for tagging emails. When I register new web accounts, I always specify a new unique tag so that I can track down the source in case I receive spam. Furthermore, they help my mail server when filtering out junk mail.

Ah, that would mean that I would have the libraries handle the resolving. I was currently only thinking about keeping the single socket which is used in order to only use the parsing functions from the libraries.

A look at https://archive.is/https://petition.parliament.uk/petitions/... supports the claim. Although, of course, one cannot really tell how many fraudulent signatures have remained undetected.

I have not yet managed to setup a single local recursor, such as PowerDNS recursor, to deliver the same performance as the list consisting of multiple open resolvers, although bandwidth does not seem to be the limiting factor. Testing with dnsperf, the best result I am currently getting is about 6,000 resolves per second with bind, for PDNS the figure is even lower for some reason. I will have to dig a bit deeper in order to find the reason for that cap.

Not yet. I have had a quick look at ldns (https://www.nlnetlabs.nl/projects/ldns/) which supports parsing DNS packets from wire. I will probably replace the DNS implementation with either libldns or c-ares.

You are correct. Has been fixed.

This is the line of code that pre-checks whether an incoming packet should be parsed at all. If it is not a response packet or if the number of questions is not one, it should not be parsed, simply because the packet parsing function expects a reply packet with exactly one question, namely the one that has been queried for.

I have not heard about tindydns before but it seems to be a DNS server, not a client.

The tool has mainly been tested on a Hetzner EX41 server. (Ubuntu, Intel® Core™ i7-6700, 32 GB RAM)

For DNS cache snooping the usage would of course be different. You would supply the tool with one resolver which does not reject non-recursive queries. Theoretically, one could even perform traffic analyses of DNS resolvers by snooping.

Having implemented the --norecurse option, the title is at least not wrong anymore. One can have non-recursive, non-iterative resolver (which is what you use when you want to perform DNS cache snooping) and the title does not suggest that the tool supports iterative lookups.

Handling multiple questions within one packet is difficult because response codes such as NXDOMAIN are only included once per packet. AFAIK, bind does not support handling such queries.

Why should that matter in this case? The worst case would have been the output of a wrong value and it was some commented out debug output which I have used in a very specific case.

Well, in order to make it correct, I have implemented a --norecurse option.

This is already discussed below and you are right. It was an issue with the perspective of the term recursion from my side. Unfortunately, I cannot change the HN title anymore. (Maybe some moderator can?) The GitHub project description has been changed.

Some of the resolvers might ban/rate-limit you indeed and even send abuse complaints to your ISP.

EDIT: You might have a look at the newly implemented --norecurse option.

Thank you for pointing this out. This file actually contained some unused code that was not supposed to make it into the repository so I just removed it. The "%x" format specifiers were located in debug comments that have been commented out. They have also been removed now.

Malloc results are checked by the safe_malloc function in security.h. Could you point out a line that is prone to integer overflows?

What I mean by non-recursive in this case is that the program does not perform recursion by itself as it relies on a list of DNS resolvers. When querying these resolvers, the recursion bit is actually set. However, I agree that the title might be misleading but I am not sure how I could express that better.