Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IBDNS: Intentionally Broken DNS server

afnic.fr

Post reply on HN
Print view View original

21–30 of 30 posts

Re: IBDNS: Intentionally Broken DNS server

#21

Post by Operyl »

notarealllama wrote: post #20
tonetegeatinst wrote: post #15

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.

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.

Re: IBDNS: Intentionally Broken DNS server

#22

Post by [deleted] »

maicro wrote: post #10
Severian wrote: post #8

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

[deleted]

Re: IBDNS: Intentionally Broken DNS server

#23

Post by jimbobthrowawy »

maicro wrote: post #10
Severian wrote: post #8

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.

Re: IBDNS: Intentionally Broken DNS server

#24

Post by podunkPDX »

Art9681 wrote: post #18

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

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.

Re: IBDNS: Intentionally Broken DNS server

#25

Post by wolletd »

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.

Re: IBDNS: Intentionally Broken DNS server

#26

Post by citrin_ru »

tonetegeatinst wrote: post #15

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.

Re: IBDNS: Intentionally Broken DNS server

#28

Post by maicro »

jimbobthrowawy wrote: post #23
maicro wrote: post #10

Earlier quoted context omitted.

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"...

Re: IBDNS: Intentionally Broken DNS server

#30

Post by jimbobthrowawy »

maicro wrote: post #28
jimbobthrowawy wrote: post #23

Earlier quoted context omitted.

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 mor…

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.
Post reply on HN