blechschmidt's comments

blechschmidt | 8 years ago | on: Five years of IPv6: whither the next five?

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.

blechschmidt | 9 years ago | on: Want a Loan in China? Keep Your Phone Charged

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.

blechschmidt | 9 years ago | on: Geohot tries to break Google's recaptcha

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.

blechschmidt | 9 years ago | on: The Correct Way to Validate Email Addresses

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.

blechschmidt | 9 years ago | on: The Correct Way to Validate Email Addresses

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.

blechschmidt | 9 years ago | on: The Correct Way to Validate Email Addresses

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.

blechschmidt | 9 years ago | on: Show HN: MassDNS – A high-performance DNS stub resolver in C

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.

blechschmidt | 9 years ago | on: Show HN: MassDNS – A high-performance DNS stub resolver in C

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.

blechschmidt | 9 years ago | on: Show HN: MassDNS – A high-performance DNS stub resolver in C

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.

page 1