I have seen a few different ISP’s block unbound from working.
How do you think they do it.
I had a US ISP this morning, block it from on their network nationwide.
It looks like DNSSEC traffic was blocked…what do you think happened?
intercept messages it does not understand. I've also seen an ISP who
DNATed all udp/53 to 8.8.8.8 with an explanation that: “our customers
often misconfigure their DNS addresses and then complain that internet
is not working for them.”
Anyway, forwarding to a trusted DoH upstream should solve the issue.
Anyway, forwarding to a trusted DoH upstream should solve the issue.
This is a valid reason to use DoH, escaping commercial or well-intended
stupid filters. Never thought I'd think there was a use for DoH, but
here it is. Don't go around thinking DoH will hide your queries from
more than casual blocking/inspection, though.
/Måns
I think this comment needs clarification:
1) DoH protocol itself, similarly to any other DNS-only-encryption protocols, does not provide protection from determined attackers. This is not fault of DoH/DoT, it is simply property of IP protocol and current web deployment model. For more details read article Simran Patil and Nikita Borisov. 2019. What can you learn from an IP?
- - slides: https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
- - the article itself: https://dl.acm.org/authorize?N687437
2) DoH does not provide a lot of benefits over DoT or other DNS-encryption-protocols, unless it is co-hosted with content. Hosting DoH endpoint e.g. on a big CDN would make DoH hard to block without big "collateral damage". This is where DoH in theory has advantage in un-blockability over other protocols but centralizing DNS and everything else has its own set of problems, see article:
https://labs.ripe.net/Members/bert_hubert/centralised-doh-is-bad-for-privacy-in-2019-and-beyond
In short, if you care about privacy go for full VPN and do not waste time on DNS-only encryption.
- --
Petr Špaček @ CZ.NIC
Hi,
It was never promising. It used transport security for data origin protection, so it would have to bypass all dns caching.
It was misrepresented by djb, and overhyped.
Paul
It may not be censorship. Consumer IOT devices have been more infected by bot-nets according to recent reports. DNS and DNSSEC are documented tools for amplification attacks. It may be a counter measure deployed during an attack. US ISP also engage in "snoop-vertising." Most are happy to collect analytics from customers with rented modems in stock configuration, and they do not harm basic internet function. A few dig deeper and cause problems like NXDOMAIN substitution and port 53/853 diversion. It may be one of these undesirable implementations.
Thoughts to consider in your analysis.
- Eric
My local ISP, at least until very recently, always delivered doctored
answers, but taken from who-knows-where. I run my own authoritative name
servers, and when I tried to query them, I got stale answers with a
bogus, uniform TTL of 1 minute, everytime. I also wouldn't get any
updates until hours later. They also have a nanny filter which I can't
really disable.
Unfortunately, I don't have an influence over what kind of Internet I
get in here. =8-(
Cheers,
Toni
Toni Mueller via Unbound-users writes:
>
> My local ISP, at least until very recently, always delivered doctored
> answers, but taken from who-knows-where. I run my own authoritative name
> servers, and when I tried to query them, I got stale answers with a
> bogus, uniform TTL of 1 minute, everytime. I also wouldn't get any
> updates until hours later. They also have a nanny filter which I can't
> really disable.
Such a problem can of course not be fixed by unbound alone.
Have a look at <https://nlnetlabs.nl/projects/dnssec-trigger/about/>
for a one idea to deal with that. Another popular method is using
"Stubby" (See <https://getdnsapi.net/> where some solutions are
mentioned.
jaap