3 ms·

I like and use it. However if you use it as fully recursive DNS (without upstream server), you may run into some things that resolve differently from BIND, caus

by rini17 3y ago

I like and use it. However if you use it as fully recursive DNS (without upstream server), you may run into some things that resolve differently from BIND, caused by different interpretation of the RFC. Sadly can't find the details right now and the github issue 56 was deleted.

Daviey 3y ago
Do you know why the issue was deleted? I find it a bit concerning a project would ever delete an issue unless it was spam or abusive in concept, especially a security critical project like DNS.
- duskwuff 3y ago
  > Do you know why the issue was deleted? It looks as though the entire issue tracker was deleted, not just that specific issue.
teddyh 3y ago
Still accessible here: <http://web.archive.org/web/20201029102523/https://github.com/samboy/MaraDNS/issues/56 http://web.archive.org/web/20201029102523/https://github.com...>
bogantech 3y ago
Doesn't support EDNS and doesn't implement truncated responses the way the RFCs specify it seems What is it about DNS that causes devs to build servers / libraries that incorrectly implement functionality purely based on their own opinion of how it should work? (musl only added tcp dns support recently because they thought it was not worth the effort) [1] https://web.archive.org/web/20201029102525/https://github.com/samboy/MaraDNS/issues/54 https://web.archive.org/web/20201029102525/https://github.co...
- joshcafe 3y ago
  It's because the RFC is fairly short but DNS as a live system is very very complicated. Plus not everything is BIND anyway and you'll find weird things even from large providers. I wrote https://github.com/jmhertlein/comfydns https://github.com/jmhertlein/comfydns from scratch, just using the RFCs, and what I got when I was "done" was something that mostly worked. Like surprisingly well. But then I just kept finding a small trickle of issues for certain sites. One that got me was console.aws.amazon.com. It has 4 CNAMEs in the resolution path and (iirc) one weird but was somewhere along there, you get an NXDOMAIN response but still get a CNAME record back. Is thus allowed by the rfc? IMO, no. I was discarding anything that came back with NXDOMAIN (really, NAME_ERROR - Nxdomain is bind parlance). But alas, it's AWS, and 8.8.8.8 resolves it fine, so what am I to do? So I added a heuristic thats similarly not-incorrect per the RFC where if I get a NAME_ERROR back, as long as the message has records that match my SNAME, I still treat it as a successful query, cache the records, and continue my search. So... yeah. Lots of weird shit like that. Just mixes of being too defensive in what you accept and then in some cases not defensive enough - I've found searches that resolve for 8.8.8.8 but if I comb through it manually in DIG, I get back results that are clearly a misconfiguration and then I have to come up with some heuristic that rejects them while still being universally applicable. So yeah. Fun times. I love DNS. (not sarcasm! I promise).

by rini17 3y ago

Daviey 3y ago

Do you know why the issue was deleted? I find it a bit concerning a project would ever delete an issue unless it was spam or abusive in concept, especially a security critical project like DNS.

duskwuff 3y ago
> Do you know why the issue was deleted? It looks as though the entire issue tracker was deleted, not just that specific issue.

teddyh 3y ago

Still accessible here: <http://web.archive.org/web/20201029102523/https://github.com/samboy/MaraDNS/issues/56 http://web.archive.org/web/20201029102523/https://github.com...>

bogantech 3y ago

Doesn't support EDNS and doesn't implement truncated responses the way the RFCs specify it seems What is it about DNS that causes devs to build servers / libraries that incorrectly implement functionality purely based on their own opinion of how it should work? (musl only added tcp dns support recently because they thought it was not worth the effort) [1] https://web.archive.org/web/20201029102525/https://github.com/samboy/MaraDNS/issues/54 https://web.archive.org/web/20201029102525/https://github.co...

joshcafe 3y ago
It's because the RFC is fairly short but DNS as a live system is very very complicated. Plus not everything is BIND anyway and you'll find weird things even from large providers. I wrote https://github.com/jmhertlein/comfydns https://github.com/jmhertlein/comfydns from scratch, just using the RFCs, and what I got when I was "done" was something that mostly worked. Like surprisingly well. But then I just kept finding a small trickle of issues for certain sites. One that got me was console.aws.amazon.com. It has 4 CNAMEs in the resolution path and (iirc) one weird but was somewhere along there, you get an NXDOMAIN response but still get a CNAME record back. Is thus allowed by the rfc? IMO, no. I was discarding anything that came back with NXDOMAIN (really, NAME_ERROR - Nxdomain is bind parlance). But alas, it's AWS, and 8.8.8.8 resolves it fine, so what am I to do? So I added a heuristic thats similarly not-incorrect per the RFC where if I get a NAME_ERROR back, as long as the message has records that match my SNAME, I still treat it as a successful query, cache the records, and continue my search. So... yeah. Lots of weird shit like that. Just mixes of being too defensive in what you accept and then in some cases not defensive enough - I've found searches that resolve for 8.8.8.8 but if I comb through it manually in DIG, I get back results that are clearly a misconfiguration and then I have to come up with some heuristic that rejects them while still being universally applicable. So yeah. Fun times. I love DNS. (not sarcasm! I promise).