IBDNS: Intentionally Broken DNS server | Hacker News Reader

IBDNS: Intentionally Broken DNS server

afnic.fr

237 pointspatadune25 comments

The purpose of this tool is testing if a domain name system follows (or does not follow) the correct specifications:

IBDNS fills a gap in the universe of DNS test tools by offering the possibility of deviating intentionally and on demand from the DNS specifications, and thus simulating incorrect behaviour of authoritative name servers.

To be pedantic, its purpose is for verification testing of systems that allow for testing of the type you describe

I absolutely love this. This will be amazing to trigger unexpected behavior in CoreDNS when working with dnsmasq pods that are resolved via wireguard.

I've had so many issues where I'd lose DNS inside pods and had to reschedule CoreDNS in order for it to start working again, hopefully I can finally trigger this on demand and find a solution for it.

Somewhat related....I think that while fiber needs to become faster and more affordable and accessable, the other big factor is speed is the latency in DNS. DNS is such a pain to troubleshoot personally,and factors like how fast DNS takes plays a big role in network speed.

Also, for the love that all that is holy, some ISP DNS servers just break if you try using ipv6 only which is just saddening.

> DNS is such a pain to troubleshoot personally

I have a different experience - you can query each authoritative server directly to troubleshoot a problem (which makes it easier compare to systems when you have a single endpoint and cannot see beyond it).

Poorly configured by ISP recursive servers though is a common pain - it is relatively easy to create and maintain a well working recursive caching DNS but it looks like ISP just don't care.

Got off that 75.75.75.75 (Comcast) train years ago. Just wait until you have an ISP that does port 53 blackholing / redirecting. No bueno.

At least DoH is available still for the most part on those ISPs.

Slides from a talk in 2022: https://indico.dns-oarc.net/event/44/contributions/949/attac...

As opposed to all of the other unintentionally broken DNS servers. SK

Perfect addition for me. I use with badssl.com in my toolbox for training and coding tests. Need more "bad example" tools to cover corner cases and understand common failure modes.

In case anyone is looking for similar tools needs one for HTTP status codes:

https://httpstat.us https://httpstat.us/404

Cool website. Can't tell if requests for nonsensical codes like 108 are supposed to return 500 or if that's an error on my side. Returns things like 707 just fine.

Not affiliated with the site at all, but just confirmed in Vivaldi that https://httpstat.us/108 returns a 500 "This page isn't working" error, while Firefox just shows a blank page (and a 500 error in the Network inspection tab). Even get a 500 error with wget ("GNU Wget 1.16 built on linux-gnueabihf.")

Looked through the source briefly but couldn't understand exactly how it's working, so I'm not sure yet if it's more likely an issue on the server or "browser"...

Looking into it further, they seem to be using Kestral web server on an azure app service. I assume the server doesn't like serving those status codes for some (understandable) reason. My first guess was that it was some reverse proxy causing the problem.

Name resolution problems are the most bizarre.

And they happen at every level and can combine beautifully. I had a DNS server flooded with Format Error messages, because NTP Pool DNS sent an invalid response for a specific query and two (yet to be identified) clients sent (and still send) that query every second or so, because the response never reaches them. And as the upstream query failed, the DNS server would send the same query every second again to a bunch of other DNS servers, every single response generating another Format Error. Dozens of log lines per second.

Those two generate about 1GB of waste traffic per month. And that's the two buggy machines talking to a small DNS server I manage. I wonder how many junk traffic public DNS servers generate.

Excellent!

This is core infrastructure testing at its finest. I'm sure it will reveal bugs and behaviors noone expected.

At first glance I thought this was a randomizer, like writing facebook and landing on X.

Alas, https certificates prevent this idea from being possible.

Which is a good thing! It's great that we've eliminated certain classes of bugs through protocol design.

Very happy to see another Elixir application doing work.

Writing servers like this is a joy using Erlang and OTP. I assume the same holds for Elixir though I have not used it.

If I were to declare a religion on my Census or other data - it would be "OTP"

Elixir to some extent is just syntactic sugar on top of Erlang.

Elixir is to Erlang as Kotlin is to Java. At the end of the day, it's the same thing. There are some conveniences added, like less verbose ways to deal with GenServer or other abstractions on top of it - but all-in-all it is pretty similar aside from the syntax parts.

You might consider taking it for a spin.

My employer’s DNS has been innovating in this space for 20 years. Find a worst practice, and we’ve done it.

All DNS is broken. It's always f'n DNS. Always. Call me when you've deployed DNS that actually works.

I have! BIND 9.11.x, as pairs of caching recursive resolvers advertised over BGP. We have a pair in every data center (12 dcs at last count) Each with one of two IPs (anycasting). Every time I get hit up for a “problem” with this it turns out the problem is with an authoritative AD server. I really love it as it’s been in place for almost four years and it has never been the source of any problems.

Reply on news.ycombinator.com