I've been embroiled in my first house-move in 28 years, and just got back to the table. I don't see any threads here about whatever this thing-which- appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it? Is there an official name for it I should be searching for? Is it in fact not a monstrosity, and I'm just not smart enough? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
DNS over HTTPS. And yes....DNS over TLS would be better in my opinion. -- Greg Grimes Senior Network Analyst Information Technology Services Mississippi State University 662-325-9311(w) ________________________________ From: NANOG <nanog-bounces@nanog.org> on behalf of Jay R. Ashworth <jra@baylink.com> Sent: Monday, September 30, 2019 9:25:07 PM To: North American Network Operators' Group <nanog@nanog.org> Subject: This DNS over HTTP thing I've been embroiled in my first house-move in 28 years, and just got back to the table. I don't see any threads here about whatever this thing-which- appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it? Is there an official name for it I should be searching for? Is it in fact not a monstrosity, and I'm just not smart enough? :-) Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://secure-web.cisco.com/1vEcpsLgAGJkFDMQebtpSHArLROwG5eAPeyR0_tVM-DvbzRe... 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Sep 30, 2019, at 10:25 PM, Jay R. Ashworth <jra@baylink.com> wrote:
Is there an official name for it I should be searching for?
The IETF calls it "DoH", pronounced like "Dough". https://datatracker.ietf.org/wg/doh/about/ There are a number of such services from Google, Amazon, and others. Firefox and Chrome now reportedly use it unless you tell them not to. It is also in use by at least one botnet, per reports. https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-d... https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-... https://www.bleepingcomputer.com/news/security/psixbot-modular-malware-gets-... One thing that bothers me about the Google implementation is that they apparently download the IANA zone and, in effect, operate as an informal root server. Not that I am protective of the root per se, but the root operators operate by an ethos described in RSSAC001 (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectati....). If Google wants to promote itself into those ranks, I would expect it to shoulder the ethos and responsibility implied. The articles I pointed to above would suggest that it does not.
On Mon, Sep 30, 2019 at 11:46:04PM -0400, Fred Baker <fredbaker.ietf@gmail.com> wrote a message of 28 lines which said:
Is there an official name for it I should be searching for?
The IETF calls it "DoH", pronounced like "Dough". https://datatracker.ietf.org/wg/doh/about/
And it is standardized in RFC 8484, which was published one year ago.
There are a number of such services from Google, Amazon, and others.
And you can build your own quite easily, these days, to avoid being dependent on a few US corporations.
One thing that bothers me about the Google implementation is that they apparently download the IANA zone and, in effect, operate as an informal root server. Not that I am protective of the root per se, but the root operators operate by an ethos described in RSSAC001 (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectati....).
This is in line with RFC 7706 "Decreasing Access Time to Root Servers by Running One on Loopback", and the root zone operators explicitely authorize zone transfer, partially for this purpose.
----- On Sep 30, 2019, at 8:46 PM, Fred Baker fredbaker.ietf@gmail.com wrote:
Firefox and Chrome now reportedly use it unless you tell them not to.
Just imagine how this list would explode if BGP implementations would all of a sudden have their default behavior changed to include auto-negotiated MD5 passwords. Thanks, Sabri
On Wednesday, 2 October, 2019 10:55, Sabri Berisha <sabri@cluecentral.net> wrote:
Firefox and Chrome now reportedly use it unless you tell them not to.
Just imagine how this list would explode if BGP implementations would all of a sudden have their default behavior changed to include auto- negotiated MD5 passwords.
Bad analogy. A correct analogy would be that all the BGP implementations suddenly decided to get enter into a priority remote peering session with SpiesAreUs.com ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On 9/30/19 10:25 PM, Jay R. Ashworth wrote:
Is there an official name for it I should be searching for?
Aside from "DoH" (smacks Homer's head), you might find searching for the Mozilla (et. al.) "canary domain" useful. It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual. -- Brandon Martin
On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin <lists.nanog@monmotha.net> wrote a message of 10 lines which said:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual.
Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
On 10/1/19 3:38 AM, Stephane Bortzmeyer wrote:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual. Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
Indeed. It seemed like a glaring hole in the implementation. The Mozilla page on the topic implies it's temporary until some sort of "standard" solution can be found, but since you will always have folks who control DNS and want/need to enforce something like this (enterprises, for example), I'm not sure how you'd go about this without resorting to e.g. group policy-like things which is messy in its own right. There are some additional checks for "enterprise" networks including checking whether "enterprise roots" is enabled which I guess is different from simply loading in extra root certificates. Why Mozilla and Google are SO insistent that I must not have control over my root certificate list is beyond me. But yes, there's a Firefox pref to force it (or completely disable it regardless of the canary). Amusingly, unlike most of the actually-useful Firefox prefs, this one is apparently in the GUI [1]. It also allows you to pick the provider (Cloudflare or "custom", of course). The bare about:config pref you want is "network.trr.mode". Short and sweet of it, set to 5 (off by choice), and it should disable the function entirely. 3 would be the opposite: always use it. [1] https://support.mozilla.org/en-US/kb/firefox-dns-over-https -- Brandon Martin
The bare about:config pref you want is "network.trr.mode". Short and sweet of it, set to 5 (off by choice), and it should disable the function entirely. 3 would be the opposite: always use it.
Thank you, IMO this is by far the most useful piece of information on the subject! Robert
On 2019-10-01 09:38, Stephane Bortzmeyer wrote:
On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin <lists.nanog@monmotha.net> wrote a message of 10 lines which said:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual.
Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
The goal is centralization of DNS and being to see more what users (or at least the aggregate stats, so that they can claim "we do not keep your data/IP/lookups") do, the goal is not that of 'security' or 'privacy'. While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this. Also keep a split between the protocol and the implementation. DoT and DoH both serve the same goal of "encryption", but that is not being used here: they also want to move the recursor to another entity... At least the use-application-dns.net zone is now not DNSSEC signed anymore as it was before, thus at least a NXDOMAIN can now be caused instead of SERVFAIL as .net indicated a signature, while one overrode that locally... Greets, Jeroen
On Tue, Oct 01, 2019 at 09:55:54AM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 26 lines which said:
(Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
The goal is centralization of DNS
Hmmm, no, read RFC 8484 (section 1).
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
On 2019-10-01 10:08, Stephane Bortzmeyer wrote:
On Tue, Oct 01, 2019 at 09:55:54AM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 26 lines which said:
(Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
The goal is centralization of DNS
Hmmm, no, read RFC 8484 (section 1).
Correct: for the DoH protocol it is not that goal, there it solely is "encryption". But DoT already solves that. For the implementation though of DoH (what most people have a problem with), the sole goal is centralization and moving the information collection from the ISP to single entities that are already collection so much data, this just gives them more and for properties they do not even operate.
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
The point is that the claimed goal (for the deployment) is that it gives users 'privacy', but in the end that 'privacy' just moves from the ISP that the user pays to an unrelated company that wants to see it all... False advertising anyone? Greets, Jeroen
On Tue, Oct 01, 2019 at 10:35:31AM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 29 lines which said:
Correct: for the DoH protocol it is not that goal, there it solely is "encryption". But DoT already solves that.
DoT is fine, (and my own public resolver activates it) but, as you know, it is too easy to block, either explicitely, or as a by-product of a "only port 443" policy. Also, most of the complaints (for instance by the lobby who wrote to the US congress) about DoH apply also to DoT (for instance, like DoH, it prevents the ISP to modify or even to see the DNS requests and responses, so the lobbies who don't like DoH won't like DoT either).
For the implementation though of DoH (what most people have a problem with), the sole goal is centralization
This is your personal opinion, not a fact. (Speaking as someone who deployed a DoH resolver.)
and moving the information collection from the ISP to single entities that are already collection so much data,
That's why we need more DoH resolvers. Install one!
The point is that the claimed goal (for the deployment) is that it gives users 'privacy', but in the end that 'privacy' just moves from the ISP that the user pays to an unrelated company that wants to see it all...
Security is often moving stuff to a different trusted party (think of VPNs, for instance).
TDLR: - Using DoT or DoH as a protocol is fine, though the recursor still controls/views the DNS queries - Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53 is does not improve security or privacy... Getting that forced fed by the monopolies controlling the browser.... bad for the Internet. - Use a VPN if you do not trust your network provider. - Use Tor if you really want 'privacy'. On 2019-10-01 11:57, Stephane Bortzmeyer wrote:
On Tue, Oct 01, 2019 at 10:35:31AM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 29 lines which said:
Correct: for the DoH protocol it is not that goal, there it solely is "encryption". But DoT already solves that.
DoT is fine, (and my own public resolver activates it) but, as you know, it is too easy to block, either explicitely, or as a by-product of a "only port 443" policy.
Sounds like you don't trust the network you get access from (and possibly pay). Use a VPN to get out of there. Though then you also move your trust point of course, but at least you do it for everything. Just doing this for your webbrowser is not solving your problem (till encrypted SNI is a thing *everywhere*), there are other services on the Internet than this "HTTP" thing... You might also want to look into this amazing thing called Tor if you really want privacy.
Also, most of the complaints (for instance by the lobby who wrote to the US congress) about DoH apply also to DoT (for instance, like DoH, it prevents the ISP to modify or even to see the DNS requests and responses, so the lobbies who don't like DoH won't like DoT either).
You just moved your problem to the entity that now runs your DNS recursor. Before "encryption" the network and the recursor could view/change your requests. Likely these where both your ISP. Encrypting to the recursor will still allow that recursor to see and modify answers. Btw enabling DNSSEC only allows you to verify that there was a lie (or no answer). Most users currently use their network provided DNS server. As such, they are likely using the one from the ISP... The question is: who do you trust, in this question: the one that offers the recursive service. If you do not trust your local network, VPN/Tor out of there. If you trust your local network (as you pay them, just trust them, or live in a country with strong privacy enforcement and data collection policies), then just use them. Browsers forcing upon a user per default a DNS provider does not address any of these things.
For the implementation though of DoH (what most people have a problem with), the sole goal is centralization
This is your personal opinion, not a fact. (Speaking as someone who deployed a DoH resolver.)
You are mixing things. A) Anybody can deploy DoT or DoH for their recursors (I have too). B) Browser vendors are doing this "DoH" thing to centralize DNS to their recursors. Noting that many ISPs are deploying both DoT and DoH next to Do53. And Mozilla claims that suddenly that is a good thing as 'it is encrypted', while it does not change the adversary: recursor still run by an ISP, that apparently one does not trust...
and moving the information collection from the ISP to single entities that are already collection so much data,
That's why we need more DoH resolvers. Install one!
Installed a whole bunch of them.... But not using them myself. DoT is the technically better version.
The point is that the claimed goal (for the deployment) is that it gives users 'privacy', but in the end that 'privacy' just moves from the ISP that the user pays to an unrelated company that wants to see it all...
Security is often moving stuff to a different trusted party (think of VPNs, for instance).
See above. Moving only your DNS to Cloudflare or Google does not solve the security stance, even though that is what people are marketing this whole DoH move for.... Greets, Jeroen
On Oct 1, 2019, at 6:11 AM, Jeroen Massar <jeroen@massar.ch> wrote:
TDLR: - Using DoT or DoH as a protocol is fine, though the recursor still controls/views the DNS queries - Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53 is does not improve security or privacy... Getting that forced fed by the monopolies controlling the browser.... bad for the Internet. - Use a VPN if you do not trust your network provider. - Use Tor if you really want 'privacy’.
I would also be concerned about the lock-in this creates. Cloudflare (at previous DNS-OARC meetings) has said their main reason for paying Mozilla & 1.1.1.1 is to improve the performance for their customers. I think this is a great thing for their customers, but is also an issue - if you take it to the privacy extreme here it harm not only their competitors but the end-users involved as well. I’m personally very concerned about the very extreme stance taken by some people & organizations with the overall protocols and how they will harm the internet of the future. I for one am awaiting the DoHoToQUICo53 overlords to appear. - jared
On Tue, Oct 01, 2019 at 12:11:32PM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation) over UDP is quite an old thing and nobody complained. I really wonder why there was so little reaction against OpenDNS or Google Public DNS and suddently a lot of outcry against DoH...
You might also want to look into this amazing thing called Tor if you really want privacy.
I know it, and use it and it is awfully slow. Telling to people who want privacy that they need to adopt the difficult and costly (in performance) solutions made for iranian opponents won't help to improve security.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
Fact-checking: could you name some? (I do not know even one.)
On Oct 1, 2019, at 9:22 AM, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Oct 01, 2019 at 12:11:32PM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation) over UDP is quite an old thing and nobody complained. I really wonder why there was so little reaction against OpenDNS or Google Public DNS and suddently a lot of outcry against DoH…
I get people not wanting to use 8.8.8.8 1.1.1.1 4.2.2.1 or even their local DNS resolver because various people have tried to treat it as a revenue stream at times. There needs to be more middle ground here than people have drawn with their battle lines.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
Fact-checking: could you name some? (I do not know even one.)
I’ve gone and enabled DoTLS on my server and (wow, the number is finally non-zero!) haven’t seen a lot of TLS adoption. I see a lot more IPv6 than TLS at my authority server. num.edns=433691276 num.ednserr=96 num.udp=299934993 num.udp6=154946379 num.tcp=820001 num.tcp6=292693 num.tls=15 num.tls6=0 num.answer_wo_aa=1117887 num.rxerr=0 num.txerr=6 num.raxfr=49 num.truncated=1420526 num.dropped=86596 - Jared
On Tue, Oct 1, 2019 at 6:23 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Oct 01, 2019 at 12:11:32PM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation) over UDP is quite an old thing and nobody complained. I really wonder why there was so little reaction against OpenDNS or Google Public DNS and suddently a lot of outcry against DoH...
There is only a reaction to changing the defaults of millions of users to key internet infrastructure. As Mao Zedong said, let a thousand flowers bloom. It only got messy when it turned out everyone effectively could only have 1.
You might also want to look into this amazing thing called Tor if you really want privacy.
I know it, and use it and it is awfully slow. Telling to people who want privacy that they need to adopt the difficult and costly (in performance) solutions made for iranian opponents won't help to improve security.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
Fact-checking: could you name some? (I do not know even one.)
On 2019-10-01 15:22, Stephane Bortzmeyer wrote:
On Tue, Oct 01, 2019 at 12:11:32PM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation) over UDP is quite an old thing and nobody complained. I really wonder why there was so little reaction against OpenDNS or Google Public DNS and suddently a lot of outcry against DoH...
Those services the user decides on themselves. It is not a default in the browser.
You might also want to look into this amazing thing called Tor if you really want privacy.
I know it, and use it and it is awfully slow. Telling to people who want privacy that they need to adopt the difficult and costly (in performance) solutions made for iranian opponents won't help to improve security.
Then Tor is not for your purpose indeed. Use a VPN, or better switch ISP so that you do not keep paying an entity that you do not trust.
Noting that many ISPs are deploying both DoT and DoH next to Do53.
Fact-checking: could you name some? (I do not know even one.)
https://www.as15600.net/ And there are many others who have announced it. Greets, Jeroen
On Tue, Oct 1, 2019 at 8:22 AM Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Tue, Oct 01, 2019 at 12:11:32PM +0200, Jeroen Massar <jeroen@massar.ch> wrote a message of 101 lines which said:
- Using a centralized/forced-upon DNS service (be that over DoT/DoH or even plain old Do53
Yes, but people using a public DNS resolver (of a big US corporation) over UDP is quite an old thing and nobody complained. I really wonder why there was so little reaction against OpenDNS or Google Public DNS and suddently a lot of outcry against DoH...
Mainly because no one was ever forcibly-defaulted to those, while browser makers are now going to be defaulting to sending queries to a specific set of DoH servers not set by dhcp/etc locally, but rather chosen by the browser maker, in a way that most users won't even realize/notice, hence allowing the browser maker to determine who gets to see the queries the user is making while surfing the web in that browser. This is a major change from how browsers and other applications have historically behaved, where DNS servers were set either locally on the host, or via dhcp or somesuch at the LAN level. This change will almost certainly be made without the user explicitly consenting to it. Effectively, there is no outcry against DoH. There is outcry against how some browser makers are implementing some configuration changes. It wouldn't matter what protocol they were using, even if they simply skipped local/LAN resolver configs and went straight to udp/tcp 53 on their chosen servers for recursive queries. Browser makers rule the world in a number of ways already, like choosing which TLS root certificates to include, and setting default search engines and settings (sometimes on update, even overriding explicit user settings, as was the case when Firefox switched to a paid arrangement with Yahoo.) There's a lot of potential for abuse here, and so oversight in the form of "outcry" seems entirely justified when such changes occur.
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Jeroen Massar" <jeroen@massar.ch>
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
I'm still assimilating this, but based on what I've read this half hour, his point is that "*it's none of Alphabet's damn business* where I go that isn't Google". I concur. I see no reasonable justification for this from a network engineering standpoint, and I'll be stomping on it wherever necessary. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Jeroen Massar" <jeroen@massar.ch>
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
I'm still assimilating this, but based on what I've read this half hour, his point is that "*it's none of Alphabet's damn business* where I go that isn't Google".
What's missing from this discussion are some basic facts, like "is Google going to change your DNS settings to 8.8.8.8?" The opening paragraph of https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html reads: "This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active." Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart? Damian
They almost have to change the default since there are (comparatively) very few DoH providers compared to DNS providers. On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG <nanog@nanog.org> wrote:
On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Jeroen Massar" <jeroen@massar.ch>
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
I'm still assimilating this, but based on what I've read this half hour, his point is that "*it's none of Alphabet's damn business* where I go that isn't Google".
What's missing from this discussion are some basic facts, like "is Google going to change your DNS settings to 8.8.8.8?"
The opening paragraph of https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html reads:
"This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active."
Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
Damian
On Tue, Oct 1, 2019 at 3:42 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
They almost have to change the default since there are (comparatively) very few DoH providers compared to DNS providers.
From the link that Damian sent (emphasis mine): "More concretely, the experiment in Chrome 78 will **check if the user’s current DNS provider** is among a list of DoH-compatible
providers, and upgrade to the equivalent DoH service **from the same provider**. If the DNS provider isn’t in the list, Chrome will **continue to operate as it does today.**" W
On Tue, Oct 1, 2019, 2:40 PM Damian Menscher via NANOG <nanog@nanog.org> wrote:
On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Jeroen Massar" <jeroen@massar.ch>
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
I'm still assimilating this, but based on what I've read this half hour, his point is that "*it's none of Alphabet's damn business* where I go that isn't Google".
What's missing from this discussion are some basic facts, like "is Google going to change your DNS settings to 8.8.8.8?"
The opening paragraph of https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html reads:
"This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active."
Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
Damian
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:
"More concretely, the experiment in Chrome 78 will **check if the user’s current DNS provider** is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service **from the same provider**. If the DNS provider isn’t in the list, Chrome will **continue to operate as it does today.**"
I suppose this is the point somebody has to put the words "nostrils", "tent", and "camel" in the same sentence? I'd not say it, except.. All the articles on how to disable this in Chrome say stuff like: If users don't want to be included in the Chrome DoH experiment, they can use a DNS provider that's not on Google's list (which most of the Chrome userbase already does), or they can disable DoH support by modifying the chrome://flags/#dns-over-https flag. However, the Linux build of "Version 79.0.3921.0 (Official Build) unknown (64-bit)" does not have that flag in chrome://flags (or at least Chrome can't find ot with control-F dns-over and the in-page search box returns 1 result for 'dns' Anonymize local IPs exposed by WebRTC. Conceal local IP addresses with mDNS hostnames. Mac, Windows, Linux, Chrome OS #enable-webrtc-hide-local-ips-with-mdns There are still 3 occurrences of the string 'dns-over-http' in the binary, but none of them seem to be wired up to the chrome://flags page. It may be a bug - I was unable to find mention of it, but I may not have had the right keywords to scare up a search hit. If it *is* a bug, I'd appreciate if somebody pointed me at the support page for it....
In article <146431.1569964368@turing-police> you write:
-=-=-=-=-=-
On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:
"More concretely, the experiment in Chrome 78 will **check if the user’s current DNS provider** is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service **from the same provider**. If the DNS provider isn’t in the list, Chrome will **continue to operate as it does today.**"
I suppose this is the point somebody has to put the words "nostrils", "tent", and "camel" in the same sentence?
This looks to me more like the tail end of the caravan. Users have always been at the mercy of their browsers, which have always done unexpected things. Assuming we agree that automatically upgrading http requests to https is OK, how is this any different? Same endpoints, encrypted channel. The Google people I've talked to are quite aware of the implications of using a different DNS resolver and I would be surprised if they ever did it without a very explicit request from the user. In this regard they are quite different from Mozilla who are impervious to the reasons that sending random users' traffic to Cloudflare is not a good idea. R's, John
Well, 1 think for sure. An application bypassing the OS and auto deciding where to resolve an address will break our DNS views for private versus public resolution of the same hostname. I see fun times to be had in the Security world... At least make it optional, not enabled by default. PS: I know it is not Friday, but gratz to Alphabet for systemd'ing DNS. ----- Alain Hebert ahebert@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 2019-10-02 13:14, John Levine wrote:
In article <146431.1569964368@turing-police> you write:
-=-=-=-=-=-
On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said:
"More concretely, the experiment in Chrome 78 will **check if the user’s current DNS provider** is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service **from the same provider**. If the DNS provider isn’t in the list, Chrome will **continue to operate as it does today.**" I suppose this is the point somebody has to put the words "nostrils", "tent", and "camel" in the same sentence? This looks to me more like the tail end of the caravan. Users have always been at the mercy of their browsers, which have always done unexpected things.
Assuming we agree that automatically upgrading http requests to https is OK, how is this any different? Same endpoints, encrypted channel.
The Google people I've talked to are quite aware of the implications of using a different DNS resolver and I would be surprised if they ever did it without a very explicit request from the user. In this regard they are quite different from Mozilla who are impervious to the reasons that sending random users' traffic to Cloudflare is not a good idea.
R's, John
Hi, On 01/10/2019 23:24, Warren Kumari wrote:
On Tue, Oct 1, 2019 at 3:42 PM K. Scott Helms <kscott.helms@gmail.com> wrote:
They almost have to change the default since there are (comparatively) very few DoH providers compared to DNS providers.
From the link that Damian sent (emphasis mine): "More concretely, the experiment in Chrome 78 will **check if the user’s current DNS provider** is among a list of DoH-compatible providers, and upgrade to the equivalent DoH service **from the same provider**. If the DNS provider isn’t in the list, Chrome will **continue to operate as it does today.**"
can we not also understand this as testing the waters in terms of changes of browser behaviour without user knowledge? and once one's browser uses DoH, how will we be sure that not half of queries (DoH) are going to another server - maybe even google's? slippery slope? PS: in my opinion it would look a lot more not-evil-doing if the same would be done with s/DoH/DoT/ Frank
I’m not sure that google has announced any plans to, but Firefox has announced plans to switch everyone to Cloudflare’s DNS. Hope none of y’all are running competing CDNs, cause they’re about to get real slow on Firefox. Matt
On Oct 1, 2019, at 12:38, Damian Menscher via NANOG <nanog@nanog.org> wrote:
On Tue, Oct 1, 2019 at 12:24 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Jeroen Massar" <jeroen@massar.ch>
While the 'connection to the recursor' is 'encrypted', the recursor is still in clear text... one just moves who can see what you are doing with this.
As with any cryptographic protocol. Same thing with VPNs, SSH and whatever: the remote end can see what you do. What's your point?
I'm still assimilating this, but based on what I've read this half hour, his point is that "*it's none of Alphabet's damn business* where I go that isn't Google".
What's missing from this discussion are some basic facts, like "is Google going to change your DNS settings to 8.8.8.8?"
The opening paragraph of https://blog.chromium.org/2019/09/experimenting-with-same-provider-dns.html reads:
"This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active."
Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
Damian
----- Original Message -----
From: "Matt Corallo" <nanog@as397444.net>
I’m not sure that google has announced any plans to, but Firefox has announced plans to switch everyone to Cloudflare’s DNS.
Hope none of y’all are running competing CDNs, cause they’re about to get real slow on Firefox.
But wait! I was told we didn't *need* regs or laws to enforce Net Neutrality... Cheers, -- jr 'paging Mr Oliver, Mr John Oliver' a -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 2019-10-01 21:38, Damian Menscher wrote:
Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
While I stated:
Moving only your DNS to Cloudflare or Google does not solve the security stance, even though that is what people are marketing this whole DoH move for....
I did not state what you write above ("Changing the default nameserver"). (Noting also, that the 'default nameserver' is the system one, not the one being just being used by the browser...) But, likely in the long run that will happen won't it? As Firefox is already being used as a test base if it works... Noting also, that none of my arguments fall apart with that. But hey, just skip over the whole thread, or even the TLDR... kthx! Greets, Jeroen
On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar <jeroen@massar.ch> wrote:
On 2019-10-01 21:38, Damian Menscher wrote:
Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
While I stated:
Moving only your DNS to Cloudflare or Google does not solve the security stance, even though that is what people are marketing this whole DoH move for....
I did not state what you write above ("Changing the default nameserver"). (Noting also, that the 'default nameserver' is the system one, not the one being just being used by the browser...)
Heh, nice troll -- I wasted a few minutes writing a long response about how you did, in fact, say that multiple times in this thread. Should be obvious to non-trolls that I was referring to Google changing the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host. But, likely in the long run that will happen won't it? As Firefox is
already being used as a test base if it works...
My crystal ball stopped working when I dropped it last week. Need to get it repaired before I can answer. Damian Noting also, that none of my arguments fall apart with that. But hey, just
skip over the whole thread, or even the TLDR... kthx!
Greets, Jeroen
On 2019-10-01 23:03, Damian Menscher wrote:
On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar <jeroen@massar.ch <mailto:jeroen@massar.ch>> wrote:
On 2019-10-01 21:38, Damian Menscher wrote:
> Could someone provide a reference of Google saying they'll change the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
While I stated:
>> Moving only your DNS to Cloudflare or Google does not solve the security stance, >> even though that is what people are marketing this whole DoH move for....
I did not state what you write above ("Changing the default nameserver"). (Noting also, that the 'default nameserver' is the system one, not the one being just being used by the browser...)
Heh, nice troll -- I wasted a few minutes writing a long response about how you did, in fact, say that multiple times in this thread.
Should be obvious to non-trolls that I was referring to Google changing the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host.
Fortunately list archives exist. Thanks for playing.. and name calling. Apologies that these problems that your company are causing are hurting you personally so much that you need to resort to that. Greets, Jeroen
On Tue, Oct 1, 2019 at 2:06 PM Jeroen Massar <jeroen@massar.ch> wrote:
On Tue, Oct 1, 2019 at 1:22 PM Jeroen Massar <jeroen@massar.ch <mailto: jeroen@massar.ch>> wrote:
On 2019-10-01 21:38, Damian Menscher wrote:
> Could someone provide a reference of Google saying they'll change
On 2019-10-01 23:03, Damian Menscher wrote: the default nameserver? Without that, I think all of Jeroen's arguments fall apart?
While I stated:
>> Moving only your DNS to Cloudflare or Google does not solve the
security stance,
>> even though that is what people are marketing this whole DoH move
for....
I did not state what you write above ("Changing the default
nameserver").
(Noting also, that the 'default nameserver' is the system one, not
the one being just being used by the browser...)
Heh, nice troll -- I wasted a few minutes writing a long response about
how you did, in fact, say that multiple times in this thread.
Should be obvious to non-trolls that I was referring to Google changing
the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host.
Fortunately list archives exist.
Thanks for playing.. and name calling.
I apologize for calling you a troll, if that was not your intent. (It's seriously hard to tell sometimes.) Apologies that these problems that your company are causing are hurting you
personally so much that you need to resort to that.
I'm also sorry that the facts do not match your preconceived world-view. Damian
* nanog@nanog.org (Damian Menscher via NANOG) [Tue 01 Oct 2019, 23:04 CEST]:
Should be obvious to non-trolls that I was referring to Google changing the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host.
Funny because just last week there was a Google Chrome update that removed /var on macOS (on systems with SIP disabled). -- Niels.
Damian Menscher via NANOG <nanog@nanog.org> writes:
"This experiment will be done in collaboration with DNS providers who already support DoH, with the goal of improving our mutual users’ security and privacy by upgrading them to the DoH version of their current DNS service. With our approach, the DNS service used will not change, only the protocol will. As a result, existing content controls of your current DNS provider, including any existing protections for children, will remain active."
That sounds useful, actually, as long as the browser can check, on every startup, which recursive name server its host is configured to use, and whether it is known that that server offers an equivalent DoH service, and that the entity operating said service explicitly wants clients to use that in preference to its regular port 53 or 853 service. One could imagine a local, special, domain, containing a record that the browser could look for, and which, in effect, says: "we run an equivalent DoH service; here's the URL; please use that". This redirection would then be valid for the TTL of that record. Ideally, of course. the browser, like any other application, should just use the host's local resolving mechanism, which, in turn, should be using whatever the host is configured to use as a recursor, and this mechanism should be secure, i.e. both trustworthy and private. However: because the browser cannot know for sure that the DNS traffic is being routed over a secure channel, and browsers are being used for all sorts of sensitive communication, it could check, and try to assist the user. This means detecting whether communication with the recursor is using port 53, and, if so, checking whether DoT and/or DoH is available from that same service provider, possibly in the fashion previously described. It could also check that DNSSEC validation is in use and working, and whether said DoT and/or DoH service is properly secured, by certificates that have a valid chain from a trusted root, or that can be verified from DNSSEC protected TLSA records. Any problems found could then be reported to the user, along with suggestions for how to fix them (or get them fixed). As a last resort, the user could be offered reconfiguration of the browser itself to directly use a better mechanism offered by the already used resolving name server, if possible. Bottom line: those of us who provide DNS services to end users need to make sure that we do so in a secure fashion, which means offering encrypted DNS with DNSSEC validation. If we don't, we can't blame the browser makers for trying to help our users remedy our faults. They want to protect their users from poor sysadmins. Let's not be that. -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay
On Wednesday, 2 October, 2019 03:55, Tom Ivar Helbekkmo <tih@hamartun.priv.no> wrote:
However: because the browser cannot know for sure that the DNS traffic is being routed over a secure channel, and browsers are being used for all sorts of sensitive communication, it could check, and try to assist the user.
Sensitive communications? Browsers? ROTFLMAO! -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Tuesday, 1 October, 2019 01:39, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin <lists.nanog@monmotha.net> wrote
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual.
Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
According to Mozilla: https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-ov er-https Network administrators may configure their networks to treat DNS requests for a canary domain differently, to signal that their local DNS resolver implements special features that make the network unsuitable for DoH. In addition to the canary domain signal described above, Firefox will perform some checks for network features that are incompatible with DoH before enabling it for a user. These checks will be performed at browser startup, and each time the browser detects that it has moved to a different network, such as when a laptop is used at home, work, and a coffee shop. When any of these checks indicates a potential issue, Firefox will disable DoH for the remainder of the network session, unless the user has enabled the "DoH always" preference as mentioned above. The additional checks that will be performed for content filtering are: Resolve canary domains of certain known DNS providers to detect content filtering Resolve the "safe-search" variants of google.com and youtube.com to determine if the network redirects to them On Windows and macOS, detect parental controls enabled in the operating system The additional checks that will be performed for private "enterprise" networks are: Is the Firefox security.enterprise_roots.enabled preference set to true? Is any enterprise policy configured? -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>
On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin <lists.nanog@monmotha.net> wrote a message of 10 lines which said:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual.
Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.)
Security? This is thought to be about security? Didn't we already *fix* DNS SECurity? No, I tend to buy the "Alphabet looking over your shoulder" argument a lot more than 'security', here, so far. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 10/1/19 12:18 PM, Jay R. Ashworth wrote:
----- Original Message -----
From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> On Mon, Sep 30, 2019 at 11:56:33PM -0400, Brandon Martin <lists.nanog@monmotha.net> wrote a message of 10 lines which said:
It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual. Unless, I hope, the user explicitely overrides this. (Because this canary domain contradicts DoH's goals, by allowing the very party you don't trust to remotely disable security.) Security?
This is thought to be about security?
Didn't we already *fix* DNS SECurity?
DNSSEC only deals with authentication, not confidentiality...
No, I tend to buy the "Alphabet looking over your shoulder" argument a lot more than 'security', here, so far.
...of course the main people you'd like to keep this confidential from are the ones on the other end of the DNS pipe, be it ISP's or Google, et al. So i'm not exactly sure what problem this solves, beyond giving Google and the rest a shot at seeing all of that yummy data. Mike
Jay, On Oct 1, 2019, at 12:18 PM, Jay R. Ashworth <jra@baylink.com> wrote:
This is thought to be about security?
Didn't we already *fix* DNS SECurity?
No. DNSSEC solves a different problem (being able to verify what you get is what the domain owner published). DoH (and DoT) encrypt (and authenticate) the application <-> recursive resolver channel (NOT the DNS data) which I gather some view as an attack vector. Mozilla has decided to _also_ redefine the default resolver (unless use-application-dns.net <http://use-application-dns.net/> NXDOMAINs), instead of the resolver (typically) assigned by the ISP, for browser queries. That last bit is generating a bit of ‘discussion’ as it can bypass efforts by network operators to modify DNS responses for whatever reason (e.g., protect customers from phishing sites, censoring domain names due in response to court orders, monetizing typos, etc.). Regards, -drc
On Tuesday, 1 October, 2019 22:15, David Conrad <drc@virtualized.org> wrote:
DoH (and DoT) encrypt (and authenticate) the application <-> recursive resolver channel (NOT the DNS data) which I gather some view as an attack vector.
Actually no. DoH and DoT encrypt the application <-> recursive resolver application channel. Some people may wish to believe that the current CA system provides some sort of meaningful "authentication" of the endpoint, but unless you have specifically acquired the remote endpoint's certificate through secure means and added it specifically to your verification store (and disabled the CA root), the endpoint is *not* authenticated. (Though it is possible that you have very lax authentication requirements and treat "authentication" based on the hearsay of a third-party that yet another third-party is trustworthy as being valid "authentication") IF AND ONLY IF the party to whom you have connected has kept their private key private THEN AND ONLY THEN is the conversation between the two applications protected from being decrypted by eavesdroppers between, but not at or beyond, each of those communicating applications. It is a common fallacy that TLS connections are authenticated. The vast majority of them are not authenticated in any meaningful fashion and all that can be said about TLS is that it provides an encrypted connection between the two communicating applications. This is perhaps why it is call *transport* layer security ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said:
It is a common fallacy that TLS connections are authenticated. The vast majority of them are not authenticated in any meaningful fashion and all that can be said about TLS is that it provides an encrypted connection between the two communicating applications. This is perhaps why it is call *transport* layer security ...
Another major disconnect is that TLS validates the hostname that the browser decided to connect to, not the host you thought you were connecting to.. The end result is that if a phish directs you to nan0g.org, it can still show a padlock and the user is none the wiser....
The thing is: People were conditioned for years to look for the padlock, because padlock means secure. How will we ever get this out of their minds.. Jan SMTP: jan@philippi.pw XMPP: jan@himbeere.pw GPG: 45F3 2DF0 4D55 C4B4 2083 14C5 5727 D54F *E4E2 2A3C* Am 02.10.19 um 11:45 schrieb Valdis Klētnieks:
On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said:
It is a common fallacy that TLS connections are authenticated. The vast majority of them are not authenticated in any meaningful fashion and all that can be said about TLS is that it provides an encrypted connection between the two communicating applications. This is perhaps why it is call *transport* layer security ...
Another major disconnect is that TLS validates the hostname that the browser decided to connect to, not the host you thought you were connecting to..
The end result is that if a phish directs you to nan0g.org, it can still show a padlock and the user is none the wiser....
On Wed, Oct 02, 2019 at 05:45:57AM -0400, Valdis Klētnieks wrote:
On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said:
It is a common fallacy that TLS connections are authenticated. The vast majority of them are not authenticated in any meaningful fashion and all that can be said about TLS is that it provides an encrypted connection between the two communicating applications. This is perhaps why it is call *transport* layer security ...
Another major disconnect is that TLS validates the hostname that the browser decided to connect to, not the host you thought you were connecting to..
Sadly, the W3C is stonewalling on the WebMindReading API. - Matt
The simple fix is to add a new DNS record. Call it ULS, Use Local Server or something else relevant. The record would contain the CIDR network addresses of clients that need to use the internal DNS servers. If the DNS request comes from an IP in matching a CIDR network address in the ULS record, then the server would respond with an error message telling the application to use the configured local DNS server. Thoughts? Thank you, Kevin McCormick -----Original Message----- From: NANOG <nanog-bounces@nanog.org> On Behalf Of Brandon Martin Sent: Monday, September 30, 2019 10:57 PM To: nanog@nanog.org Subject: Re: This DNS over HTTP thing On 9/30/19 10:25 PM, Jay R. Ashworth wrote:
Is there an official name for it I should be searching for?
Aside from "DoH" (smacks Homer's head), you might find searching for the Mozilla (et. al.) "canary domain" useful. It's use-application-dns.net. NXDOMAIN it, and Mozilla (at least) will go back to using your local DNS server list as per usual. -- Brandon Martin
On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick <kmccormick@mdtc.net> wrote:
If the DNS request comes from an IP in matching a CIDR network address in the ULS record, then the server would respond with an error message telling the application to use the configured local DNS server.
All if this is ultimately falsifiable by a malicious or rogue DNS operator. My suggestion would be ultimately that DNS Clients implement DNSSEC validation themself to avoid tampering by a malicious client on their network for phishing purposes or a malicious recursive DNS Resolver server --- Such a DNS proxy service in a home router corrupted by malware that modifies DNS resposes for an attacker, or those rogue DNS servers of ISPs that typically sometimes replace NXDOMAIN replies with A records attempting to collect typo queries for advertising or that redirect A records to other hosts designed to intercept and monitor or proxy traffic with advertisements inserted. A secure administrative selection of local DNS server could be supported by allowing a TXT record to be placed in the reverse DNS zone for the IP address which is the IP address configured on the client's IP network interface alongside PTR records. The client software would then be required to perform a DNSSEC signature check to ensure that the reverse DNS zone is signed and has the proper chain of signed DS records ultimately coming from the IP6.ARPA or IN-ADDR.ARPA zone. * Clients using RFC1918 IP addresses would not be able to support this; Because, there is no way of establishing WHO is authorized to sign locally on behalf of the "operator" of a RFC1918 or link-local IP address... The latter seems more like a system administration problem however -- The DHCP software running on a client ought to have some way of indicating whether the network being connected to is Secure and "Managed" by the same entity that owns and configures the client device: I.E. Same company manages the LAN and the entire path up to recursive DNS servers are secure, Or whether the PC is owned and managed by different entities -- such as a mobile PC user connected to someone else's network, or a Home user connected to their own ISP, and the network is, therefore, untrusted. (Untrusted in the sense that DNS Servers are controlled by a 3rd party who is not the owner or operator of the personal computer or client device which is connecting for the supposed purpose of accessing the public internet --- therefore no legitimate authority exists for having clients tolerate tampering with private traffic between that device and another internet host, content in DNS or other IP traffic content, and so on)
Thoughts? Thank you, Kevin McCormick -- -JH
So a malicious or rogue DNS operator... 1.1.1.1 or 8.8.8.8 is going to tell your application to use the locally configured DNS for domain lookups rather give an normal response? Not sure how this malice would really affect you as your local DNS should be functional. The idea to make DoH and DoT, or even unencrypted DNS with external DNS servers play nicely with environments that require internal users to local DNS for local domains. The point is having a record to tell severs like 1.1.1.1 and 8.8.8.8 when they should not respond normally to specific clients from a specific source for specific domains. You will always have malicious cases and scenarios, but a browser configured to use DoH or Dot to 1.1.1.1 and 8.8.8.8, I do not see how they would be affected when they do use DNSSEC. Worst case would a user configured network DNS manually rather than using DHCP, but still they would be broken as the would be getting a non-working external address for a local server. Thank you, Kevin McCormick -----Original Message----- From: Jim <mysidia@gmail.com> Sent: Monday, October 7, 2019 12:45 PM To: Kevin McCormick <kmccormick@mdtc.net> Cc: Brandon Martin <lists.nanog@monmotha.net>; nanog@nanog.org Subject: Re: This DNS over HTTP thing On Mon, Oct 7, 2019 at 11:44 AM Kevin McCormick <kmccormick@mdtc.net> wrote:
If the DNS request comes from an IP in matching a CIDR network address in the ULS record, then the server would respond with an error message telling the application to use the configured local DNS server.
All if this is ultimately falsifiable by a malicious or rogue DNS operator. My suggestion would be ultimately that DNS Clients implement DNSSEC validation themself to avoid tampering by a malicious client on their network for phishing purposes or a malicious recursive DNS Resolver server --- Such a DNS proxy service in a home router corrupted by malware that modifies DNS resposes for an attacker, or those rogue DNS servers of ISPs that typically sometimes replace NXDOMAIN replies with A records attempting to collect typo queries for advertising or that redirect A records to other hosts designed to intercept and monitor or proxy traffic with advertisements inserted. A secure administrative selection of local DNS server could be supported by allowing a TXT record to be placed in the reverse DNS zone for the IP address which is the IP address configured on the client's IP network interface alongside PTR records. The client software would then be required to perform a DNSSEC signature check to ensure that the reverse DNS zone is signed and has the proper chain of signed DS records ultimately coming from the IP6.ARPA or IN-ADDR.ARPA zone. * Clients using RFC1918 IP addresses would not be able to support this; Because, there is no way of establishing WHO is authorized to sign locally on behalf of the "operator" of a RFC1918 or link-local IP address... The latter seems more like a system administration problem however -- The DHCP software running on a client ought to have some way of indicating whether the network being connected to is Secure and "Managed" by the same entity that owns and configures the client device: I.E. Same company manages the LAN and the entire path up to recursive DNS servers are secure, Or whether the PC is owned and managed by different entities -- such as a mobile PC user connected to someone else's network, or a Home user connected to their own ISP, and the network is, therefore, untrusted. (Untrusted in the sense that DNS Servers are controlled by a 3rd party who is not the owner or operator of the personal computer or client device which is connecting for the supposed purpose of accessing the public internet --- therefore no legitimate authority exists for having clients tolerate tampering with private traffic between that device and another internet host, content in DNS or other IP traffic content, and so on)
Thoughts? Thank you, Kevin McCormick -- -JH
On Oct 7, 2019, at 10:45 AM, Jim <mysidia@gmail.com> wrote:
My suggestion would be ultimately that DNS Clients implement DNSSEC
validation themself to avoid tampering by a malicious client on their network for phishing purposes or a malicious recursive DNS Resolver server
Yep. That is (IMHO) the right (only) answer to actually fix the ‘lying’ problem instead of making it “someone else’s problem", although that turns lies into DoS when all you get back from your resolver is unvalidatable answers. To solve this problem, browser vendors really should implement validation in their stub resolvers. This would have the benefit that if validation fails, a useful error message could be presented to the user (e.g., “the website name you looked up has been tampered with!”). Instead, they have chosen to rely on their “trusted recursive resolvers” to not lie to them and use agreements rather than code. This, of course, doesn’t stop the snooping/metadata collection problem. Regards, -drc
It was mentioned in this (partially related) thread, with all the responses being the predictable “lol these folks in Silicon Valley need to lay off the drugs”. https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html Matt
On Sep 30, 2019, at 19:25, Jay R. Ashworth <jra@baylink.com> wrote:
I've been embroiled in my first house-move in 28 years, and just got back to the table. I don't see any threads here about whatever this thing-which- appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it?
Is there an official name for it I should be searching for?
Is it in fact not a monstrosity, and I'm just not smart enough? :-)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Mon Sep 30, 2019 at 10:38:31PM -0700, Matt Corallo wrote:
It was mentioned in this (partially related) thread, with all the responses being the predictable ???lol these folks in Silicon Valley need to lay off the drugs???.
https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html
Here are some UKNOF presentations on it - UKNOF43 - Potential ISP challenges with DNS over HTTPS https://youtu.be/wRtpb7VRhGQ UKNOF44 - The latest news in the DNS resolution https://youtu.be/iDQ9axaaREU UKNOF44 - Update on DoH and emerging IETF / IRTF standards https://youtu.be/4SS9kEBgX1k UKNOF44 - Panel: Operational Considerations of DoH Deployment https://youtu.be/FqVX8WplEPg
On Sep 30, 2019, at 19:25, Jay R. Ashworth <jra@baylink.com> wrote:
???I've been embroiled in my first house-move in 28 years, and just got back to the table. I don't see any threads here about whatever this thing-which- appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it?
Is there an official name for it I should be searching for?
Is it in fact not a monstrosity, and I'm just not smart enough? :-)
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Tue, Oct 01, 2019 at 08:22:58AM +0100, Brandon Butterworth <brandon@rd.bbc.co.uk> wrote a message of 37 lines which said:
Here are some UKNOF presentations on it -
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
On 01/10/2019 08:40, Stephane Bortzmeyer wrote:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Do you have a (reputable) source to go with that claim? :) -- Tom
In article <20191001074011.n4xjouqg6lhsvti7@nic.fr> you write:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Most UK ISPs use the Internet Watch Foundation's advice intended to block child sexual abuse material. Circumventing it enables people to access that material. We can shout CHILD PORNOGRAPHY just as loud as you can shout CENSORSHIP so perhaps we should both stop now. There are plenty of valid reasons for a DNS resolver to block some results. R's, John
"For the children!" "Stop resisting!" "I was in fear for my life!" The age-old cries of the oppressor. The problem is that children are being kidnapped, trafficked, and abused. DNS blocking doesn't solve that. It's not a technical problem. Go to the source--the kidnappers, traffickers, and abusers and give them 50 years in the electric chair. Go to the consumers and do the same. That will solve the problem. -A On Tue, Oct 1, 2019 at 11:33 AM John Levine <johnl@iecc.com> wrote:
In article <20191001074011.n4xjouqg6lhsvti7@nic.fr> you write:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Most UK ISPs use the Internet Watch Foundation's advice intended to block child sexual abuse material.
Circumventing it enables people to access that material.
We can shout CHILD PORNOGRAPHY just as loud as you can shout CENSORSHIP so perhaps we should both stop now. There are plenty of valid reasons for a DNS resolver to block some results.
R's, John
I assumed my point was obvious but evidently I overestimated my audience. While it is stupid to assert that the only reason to circumvent DNS filters is to look at child abuse material, it is equally stupid to assert that the only reason to filter is to lie, or to censor. There are plenty of good reasons to filter DNS responses, with the most obvious being to block malware sites whose links are sent out in spam (a whole lot of spam these days.) There are also reasons that enterprises filter DNS on their networks, to block stuff that creates a hostile work environment, or is obviously unrelated to what employees are hired to do (i.e., facebook.) R's, John On Tue, 1 Oct 2019, Aaron C. de Bruyn wrote:
"For the children!" "Stop resisting!" "I was in fear for my life!"
The age-old cries of the oppressor. ...
On Tue, Oct 1, 2019 at 11:33 AM John Levine <johnl@iecc.com> wrote:
In article <20191001074011.n4xjouqg6lhsvti7@nic.fr> you write:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Most UK ISPs use the Internet Watch Foundation's advice intended to block child sexual abuse material.
Circumventing it enables people to access that material.
We can shout CHILD PORNOGRAPHY just as loud as you can shout CENSORSHIP so perhaps we should both stop now. There are plenty of valid reasons for a DNS resolver to block some results.
Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
Everyone's (who's anyone) is looking for free curation of the net! Maybe one more law or regulation will do it. Look at how well it stomped out spam! Put more grimly: For over 100 years Europe, and others, have imagined the path to paradise is paved with new and improved censorship. Results have been sub-optimal. Perhaps one really needs to go after the perps rather than their digital images. -- -Barry Shein Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
From a corporate standpoint, this is exactly correct. There are also some regulatory issues involved (FINRA, SEC, etc...)
We are required to block access to web based email (gmail, etc...) in our corporate network (please don't ask why, ours is not to reason why...), so every method to "bypass" normal network operations creates headaches for us. -----Original Message----- From: NANOG <nanog-bounces+mhuff=ox.com@nanog.org> On Behalf Of John R. Levine Sent: Tuesday, October 1, 2019 4:06 PM To: Aaron C. de Bruyn <aaron@heyaaron.com> Cc: NANOG mailing list <nanog@nanog.org> Subject: Re: This DNS over HTTP thing I assumed my point was obvious but evidently I overestimated my audience. While it is stupid to assert that the only reason to circumvent DNS filters is to look at child abuse material, it is equally stupid to assert that the only reason to filter is to lie, or to censor. There are plenty of good reasons to filter DNS responses, with the most obvious being to block malware sites whose links are sent out in spam (a whole lot of spam these days.) There are also reasons that enterprises filter DNS on their networks, to block stuff that creates a hostile work environment, or is obviously unrelated to what employees are hired to do (i.e., facebook.) R's, John On Tue, 1 Oct 2019, Aaron C. de Bruyn wrote:
"For the children!" "Stop resisting!" "I was in fear for my life!"
The age-old cries of the oppressor. ...
On Tue, Oct 1, 2019 at 11:33 AM John Levine <johnl@iecc.com> wrote:
In article <20191001074011.n4xjouqg6lhsvti7@nic.fr> you write:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Most UK ISPs use the Internet Watch Foundation's advice intended to block child sexual abuse material.
Circumventing it enables people to access that material.
We can shout CHILD PORNOGRAPHY just as loud as you can shout CENSORSHIP so perhaps we should both stop now. There are plenty of valid reasons for a DNS resolver to block some results.
Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of child exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to interrupt the online tools that they may use or that might fund/support them, etc. So they don’t approach it as a binary choice between trying these ecosystem measures vs going to the source – they are working all the levers. It is unfortunately a very difficult problem. FWIW, a recent NYT article on this was interesting – see https://www.nytimes.com/interactive/2019/09/28/us/child-sex-abuse.html Headline is “The Internet Is Overrun With Images of Child Sexual Abuse. What Went Wrong? Online predators create and share the illegal material, which is increasingly cloaked by technology. Tech companies, the government and the authorities are no match.” JL From: NANOG <nanog-bounces@nanog.org> on behalf of "Aaron C. de Bruyn via NANOG" <nanog@nanog.org> Reply-To: "Aaron C. de Bruyn" <aaron@heyaaron.com> Date: Tuesday, October 1, 2019 at 2:53 PM To: John Levine <johnl@iecc.com> Cc: NANOG mailing list <nanog@nanog.org> Subject: Re: This DNS over HTTP thing "For the children!" "Stop resisting!" "I was in fear for my life!" The age-old cries of the oppressor. The problem is that children are being kidnapped, trafficked, and abused. DNS blocking doesn't solve that. It's not a technical problem. Go to the source--the kidnappers, traffickers, and abusers and give them 50 years in the electric chair. Go to the consumers and do the same. That will solve the problem. -A On Tue, Oct 1, 2019 at 11:33 AM John Levine <johnl@iecc.com<mailto:johnl@iecc.com>> wrote: In article <20191001074011.n4xjouqg6lhsvti7@nic.fr<mailto:20191001074011.n4xjouqg6lhsvti7@nic.fr>> you write:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. No wonder that the people who censor don't like anti-censorship techniques.
Most UK ISPs use the Internet Watch Foundation's advice intended to block child sexual abuse material. Circumventing it enables people to access that material. We can shout CHILD PORNOGRAPHY just as loud as you can shout CENSORSHIP so perhaps we should both stop now. There are plenty of valid reasons for a DNS resolver to block some results. R's, John
----- Original Message -----
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of child exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to interrupt the online tools that they may use or that might fund/support them, etc. So they don’t approach it as a binary choice between trying these ecosystem measures vs going to the source – they are working all the levers.
It is unfortunately a very difficult problem. FWIW, a recent NYT article on this was interesting – see https://www.nytimes.com/interactive/2019/09/28/us/child-sex-abuse.html Headline is “The Internet Is Overrun With Images of Child Sexual Abuse. What Went Wrong? Online predators create and share the illegal material, which is increasingly cloaked by technology. Tech companies, the government and the authorities are no match.”
Ah yes; the "proxies for evil" problem. Same problem as "getting the guns" (to quote President Andrew Shepard) as a solution for mass shootings. (And note here that I'm a lefty; we're not *required* to be gun-negative paranoids.) Child molesters also make use of houses, vans, and phonecams, so lets get all of *those* off the streets, too. Tools are *inherently* neutral, regardless of how partisans on either side want to paint them; even lockpicks -- or haven't you had to call a locksmith to get you back into your car/house without breaking a window. Tools. Are. Neutral. Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken. Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
I expect I would. But this is not "filtering DNS". It's "making a bodge-handed attempt to REPLACE DNS (well, proxy it) for only one application/layer". My problem isn't what they're using it for; it's that they've implemented it so poorly. I live down here in the trenches, John, where "it doesn't work" is the calibre of problem reports I get. When my tools say that "yes, it does", *I'm* the one who takes it in the nads because Mozilla had a Better Fuckin' Idea. That it will likely cause lots of 50,000ft problems to is just a cherry on the top. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Power DNS has a ha proxy/load balancer that does dns over https. That way you're not limited to google's and cloudflare's dns servers which exist to drive advertising to you and give a single shource for tracking. dns over https: feh On Wed, Oct 2, 2019 at 5:28 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
I expect I would.
But this is not "filtering DNS". It's "making a bodge-handed attempt to REPLACE DNS (well, proxy it) for only one application/layer".
My problem isn't what they're using it for; it's that they've implemented it so poorly.
I live down here in the trenches, John, where "it doesn't work" is the calibre of problem reports I get. When my tools say that "yes, it does", *I'm* the one who takes it in the nads because Mozilla had a Better Fuckin' Idea.
That it will likely cause lots of 50,000ft problems to is just a cherry on the top.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- --Curtis
Might I suggest using PowerDNS's dinsdist. it's an ha proxy that you can put in front of your recursors and It implements dns over https if you want it to. It's open sources and ensures that you're not limited to Google's or Cloudflare's servers which exist to drive advertising at you (I've seen infected ads pwn machines). I have much more paranoid reasons for implementing, namely preventing 3rd parties from getting my histories. On Wed, Oct 2, 2019 at 5:28 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
I expect I would.
But this is not "filtering DNS". It's "making a bodge-handed attempt to REPLACE DNS (well, proxy it) for only one application/layer".
My problem isn't what they're using it for; it's that they've implemented it so poorly.
I live down here in the trenches, John, where "it doesn't work" is the calibre of problem reports I get. When my tools say that "yes, it does", *I'm* the one who takes it in the nads because Mozilla had a Better Fuckin' Idea.
That it will likely cause lots of 50,000ft problems to is just a cherry on the top.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- --Curtis
You might recommend that to me if running DNS tunnelled through another protocol was a thing I wanted to do. But it's not. I think it's horrible Internet engineering hygiene, and I don't just not want to do it myself, I don't think anybody else ought to do it either. And I think that if end-users understood all of the concerns, they would agree with me on that - I get paid to know what end users would think. On October 3, 2019 10:28:37 AM EDT, Curtis Maurand <cmaurand@gmail.com> wrote:
Might I suggest using PowerDNS's dinsdist. it's an ha proxy that you can put in front of your recursors and It implements dns over https if you want it to. It's open sources and ensures that you're not limited to Google's or Cloudflare's servers which exist to drive advertising at you (I've seen infected ads pwn machines). I have much more paranoid reasons for implementing, namely preventing 3rd parties from getting my histories.
On Wed, Oct 2, 2019 at 5:28 PM Jay R. Ashworth <jra@baylink.com> wrote:
----- Original Message -----
From: "John Levine" <johnl@iecc.com>
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
I expect I would.
But this is not "filtering DNS". It's "making a bodge-handed attempt to REPLACE DNS (well, proxy it) for only one application/layer".
My problem isn't what they're using it for; it's that they've implemented it so poorly.
I live down here in the trenches, John, where "it doesn't work" is the calibre of problem reports I get. When my tools say that "yes, it does", *I'm* the one who takes it in the nads because Mozilla had a Better Fuckin' Idea.
That it will likely cause lots of 50,000ft problems to is just a cherry on the top.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
-- --Curtis
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, Oct 2, 2019 at 1:54 PM John Levine <johnl@iecc.com> wrote:
In article <804699748.1254612.1570037049931.JavaMail.zimbra@baylink.com> you write:
Tools. Are. Neutral.
Any solution to a problem that involves outlawing or breaking tools will. Not. Solve. Your. Problem.
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
+1 that dns tricks serve a real netops / secops purpose.
Also, google and its paid friends Firefox and Cloudflare — while offering service to the public, are not contractually liable to provide any meaningful SLA to subscribers of DoH or DoT. Customer service at 8.8.8.8 is what? That said, it is the ISP that takes the call $ when these “free” services go down. And, google and Cloudflare have gone down at large scale in recent memory. Thats all fine and dandy today for 1.1.1.1 and 8.8.8.8, since you need to dig pretty deep in your network config to set it. The blast radius is global for this type of default dns. I know FF has said they want DoH to be default, but Google have simply said “we’ll see” — which is a cause for concern. Finally, whenever it is free, YOU are the PRODUCT.
On Wednesday, 2 October, 2019 14:52, John Levine <johnl@iecc.com> wrote:
I think in the outside world you'll find very little support for an argument that filtering DNS is fundamentally broken.
Well, it is certainly trivial to bypass. Therefore it is a fantastic tools for tyrants and other fuckwads -- just as long as they think they are being effective, who really gives a rats ass.
Sure, you can do it in broken ways, but it's going to be really hard to persuade anyone that their lives are better if they have unfiltered access to the malware links in their spam.
Having unfiltered access to the malware installed by links in spam is a self-limiting problem. Remove the DNS blocks and in rather short order the problem will go away as all the idiots click their way to oblivion. -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
In article <6533015105f2d548812b4a445275bc56@mail.dessus.com> you write:
Having unfiltered access to the malware installed by links in spam is a self-limiting problem. Remove the DNS blocks and in rather short order the problem will go away as all the idiots click their way to oblivion.
It must be wonderful to live in the world you live in. Here in this world, that ain't how it works. R's, John
Livingood, Jason wrote:
The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of childsorship exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to interrupt the online tools that they may use or that might fund/support them, etc.
The Internet was working very well to suppress child porn by making video freely distributed, which made child porn industry a lot less profitable. Freely distributed video also makes investigation of victims easier. So, people who want to make money from child porn has been trying to have censorship of various degree. In UK, they are very successful. Masataka Ohta
On 02/10/2019 21:44, Masataka Ohta wrote:
The Internet was working very well to suppress child porn by making video freely distributed, which made child porn industry a lot less profitable.
I will say this very clearly: abusing children for sexual gratification doesn't stop when it is unprofitable.
Freely distributed video also makes investigation of victims easier.
It also aides the normalisation of an entirely detestable practice.
So, people who want to make money from child porn has been trying to have censorship of various degree.
In UK, they are very successful.
Sources, please. (Disclaimer: I'm in the UK.) -- Tom
Tom Hill wrote:
The Internet was working very well to suppress child porn by making video freely distributed, which made child porn industry a lot less profitable.
I will say this very clearly: abusing children for sexual gratification doesn't stop when it is unprofitable.
Sorry that the Internet is merely a golden bullet not effective to all kinds of werewolves.
Freely distributed video also makes investigation of victims easier.
It also aides the normalisation of an entirely detestable practice.
By helping to arrest kidnappers and abusers?
In UK, they are very successful.
Sources, please. (Disclaimer: I'm in the UK.)
John Levine already mentioned "Internet Watch Foundation". Or, am I expected to confess personal experience that, when in UK, I was not be able to access child porno site? :) Masataka Ohta
On 03/10/2019 12:11, Masataka Ohta wrote:
Sources, please. (Disclaimer: I'm in the UK.)
John Levine already mentioned "Internet Watch Foundation".
Sure, but the IWF was always intended to stop people accessing paedophilia accidentally. It has always been well understood for there to be many ways around that filtering. The IWF's more important role is to identify these sources and to work with the authorities against them. There's more here: https://www.iwf.org.uk/what-we-do/why-we-exist/our-remit-and-vision
So, people who want to make money from child porn has been trying to have censorship of various degree.
In UK, they are very successful.
Importantly, and I am happy to accept this was simply a translation issue, but what you said here with both paragraphs together, made it look as if you were suggesting that in the UK we are very successful in making money from child pornography *by censoring* child pornography? -- Tom
Tom Hill wrote:
Sure, but the IWF was always intended to stop people accessing paedophilia accidentally.
Then, though you wrote:
It also aides the normalisation of an entirely detestable practice.
IWF does not aide so.
look as if you were suggesting that in the UK we are very successful in making money from child pornography *by censoring* child pornography?
"they" means those who are likely to be guests of Epstein. Masataka Ohta
On 03/10/2019 13:36, Masataka Ohta wrote:
It also aides the normalisation of an entirely detestable practice.
IWF does not aide so.
No, the normalisation of an entirely detestable practice comes from the opposite of IWF involvement; you suggested that we should permit child pornography on the Web/Internet, as opposed to censoring it? To catch criminals, and to make it unprofitable? I had stated that a lack of profit does not stop those inclined to abuse children for sexual gratification, and also that doing absolutely nothing to prohibit child pornography serves to normalise its existence.
look as if you were suggesting that in the UK we are very successful in making money from child pornography *by censoring* child pornography?
"they" means those who are likely to be guests of Epstein.
Oh yes, I forgot that the possibility that one member of the Royal Family sharing the alleged inclination of Epstein to abuse underage children, made the whole United Kingdom a profiteering empire of child pornography. If you're going to call out the whole of the UK for something defamatory, at the very least take the time to think about it without your tinfoil hat. ;) -- Tom
On Wed, Oct 2, 2019 at 9:13 AM Livingood, Jason <Jason_Livingood@comcast.com> wrote:
The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of child exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to interrupt the online tools that they may use or that might fund/support them, etc. So they don’t approach it as a binary choice between trying these ecosystem measures vs going to the source – they are working all the levers.
Yes, obviously they are trying multiple levers--but who gets to draw the line, where are they going to draw it, and why do they get to decide for me? What prevents an absurd 'solution' like "We can not only stop child molestation, but rape in general if we just castrate everyone" from being one of the levers, but intentionally breaking tools like DNS is acceptible? People who are determined enough will find ways to circumvent the system--something along the lines of "the internet treats policy blocks as damage and routes around it". How many times has The Pirate Bay been blocked only to pop up under a similar domain name hosted out of a new country?
It is unfortunately a very difficult problem. FWIW, a recent NYT article on this was interesting – see https://www.nytimes.com/interactive/2019/09/28/us/child-sex-abuse.html Headline is “The Internet Is Overrun With Images of Child Sexual Abuse. What Went Wrong? Online predators create and share the illegal material, which is increasingly cloaked by technology. Tech companies, the government and the authorities are no match.”
I completely agree--it's a difficult problem, and I wish I had a solution. That article turns my stomach. I have kids, and I worry about it every day. -A
Yes, obviously they are trying multiple levers--but who gets to draw the line, where are they going to draw it, and why do they get to decide for me? What prevents an absurd 'solution' like "We can not only stop child molestation, but rape in general if we just castrate everyone" from being one of the levers, but intentionally breaking tools like DNS is acceptible?
The same reason we don't punish littering with a firing squad. Slippery slope arguments like this are counterproductive, since you're admitting that whatever is on your end of the alleged slope isn't really that bad.
People who are determined enough will find ways to circumvent the system--something along the lines of "the internet treats policy blocks as damage and routes around it".
Everyone knows that it's easy to circumvent DNS blocks, but in practice few people do, not knowing how to do it or not wanting to. To dredge up my favorite example, why would any normal person want to circumvent blocks against malware? Regulators are concerned about DoH not so much because the traffic is encrypted, but that it circumvents existing blocks, in Mozilla's case without the permission or knowledge of the users. If that becomes widespread, the countermeasures will be ugly. This isn't to argue that DNS blocking is a magic bullet, but it's a tool and you're not going to persuade anyone that the DNS is so sacred that nobody can touch it. Let's save that argument for strong encryption, where it's actually true. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On 10/1/19, 3:44 AM, "NANOG on behalf of Stephane Bortzmeyer" <nanog-bounces@nanog.org on behalf of bortzmeyer@nic.fr> wrote:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship.
What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
----- Original Message -----
From: "Livingood, Jason" <Jason_Livingood@comcast.com>
On 10/1/19, 3:44 AM, "NANOG on behalf of Stephane Bortzmeyer" <nanog-bounces@nanog.org on behalf of bortzmeyer@nic.fr> wrote:
Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship.
What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
HTTP/451 Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]:
From: "Livingood, Jason" <Jason_Livingood@comcast.com> What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
HTTP/451
Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work. -- Niels.
----- Original Message -----
From: "Niels Bakker" <niels=nanog@bakker.net> To: nanog@nanog.org Sent: Wednesday, October 2, 2019 1:42:08 PM Subject: Re: This DNS over HTTP thing
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]:
From: "Livingood, Jason" <Jason_Livingood@comcast.com> What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
HTTP/451
Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work.
Closed captioned for the analogy-impaired: "The idea you're talking about, Jason, is analogous to that embodied in the 451 error code in HTTP." Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Wednesday, 2 October, 2019 15:21, Jay R. Ashworth <jra@baylink.com> wrote:
HTTP/451
Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work.
Closed captioned for the analogy-impaired:
"The idea you're talking about, Jason, is analogous to that embodied in the 451 error code in HTTP."
And here I thought it was about the temperature at which the paper on which it was written spontaneously combusted ... -- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume.
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 23:21 CEST]:
----- Original Message -----
From: "Niels Bakker" <niels=nanog@bakker.net> To: nanog@nanog.org Sent: Wednesday, October 2, 2019 1:42:08 PM Subject: Re: This DNS over HTTP thing
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]:
From: "Livingood, Jason" <Jason_Livingood@comcast.com> What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
HTTP/451
Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work.
Closed captioned for the analogy-impaired:
"The idea you're talking about, Jason, is analogous to that embodied in the 451 error code in HTTP."
Oh, you weren't proposing a technical solution to a social problem? -- Niels.
----- Original Message -----
From: "Niels Bakker" <niels=nanog@bakker.net>
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 23:21 CEST]:
----- Original Message -----
From: "Niels Bakker" <niels=nanog@bakker.net>
* jra@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]:
From: "Livingood, Jason" <Jason_Livingood@comcast.com> What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are criticized for the actions they have no option but to undertake. IMO any such criticisms should more correctly be directed at the laws themselves or the governments that put them in place.
HTTP/451
Completely different protocol than what the rest of this thread is about, much more invasive wrt possibility of logging, and requires a lot more infrastructure and actual lying in DNS to make work.
Closed captioned for the analogy-impaired:
"The idea you're talking about, Jason, is analogous to that embodied in the 451 error code in HTTP."
Oh, you weren't proposing a technical solution to a social problem?
*I* wasn't proposing any solutions to any problems, at that particular twist, Neils, as I thought was obvious. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 01/10/2019 09:22, Brandon Butterworth wrote:
Here are some UKNOF presentations on it - Also very interesting from NLNOG (but in English):
https://www.youtube.com/watch?v=pjin3nv8jAo -- Grzegorz Janoszka
----- Original Message -----
From: "Matt Corallo" <nanog@as397444.net>
It was mentioned in this (partially related) thread, with all the responses being the predictable “lol these folks in Silicon Valley need to lay off the drugs”.
https://mailman.nanog.org/pipermail/nanog/2019-September/103059.html
Well, the parent message there seems to think it's inevitable that Firefox is going to do that, whereas my view is 1) Firefox will do as I damn well tell it, or 2) Firefox will be removed. They continue to expand past the size of what we coloquially call "their britches", and it's gotten about as tiresome as I -- for the seats under my responsibility -- propose to let it get. If there isn't a knob I can turn off, they're gone; no appeal. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On Mon, Sep 30, 2019 at 7:27 PM Jay R. Ashworth <jra@baylink.com> wrote:
I've been embroiled in my first house-move in 28 years, and just got back to the table. I don't see any threads here about whatever this thing-which- appears-to-me-to-be-a-monstrosity; has it been discussed here and I missed it?
Is there an official name for it I should be searching for?
Is it in fact not a monstrosity, and I'm just not smart enough? :-)
Oof. It is a bit of a mess. 1. For most PEOPLE in North America, DNS hacking, clear text dns is not a legit threat in their threat model. So, in short, encrypted dns is not solving a major hacker vector. It is not materially making the web more secure since on-path attacks from hackers are hard. Spare me the coffee shop wifi case. It’s definitely not an issue on mobile. 2. For GOOGLE (And it’s minions Cloudflare, which GOOG owns a chunk of, and Firefox [which is dominantly funded by GOOG] — data is key in their billion dollars ad game. 3. The billion dollar ad game has heated up. FB and Amazon are becoming a real threat to Google’s dollars. Apple too, is a threat with their focus on apps. https://www.google.com/amp/s/fortune.com/2019/06/25/amazon-ad-business/amp/ 4. GOOG tracks you all around the web with their ad platform. But GOOG cannot see what you do when you are on FB, Amazon, Apple..: because these companies are enemies fighting over the same ad bucks. Your computer will leak to GOOG what / when you do thing on FB and Amazon 5. To make the world better, Google needs to see ALL your traffic, not just their ad network cookie traffic. Hence they launched these efforts 1. Chrome with a FREE proxy for all your traffic https://developer.chrome.com/multidevice/data-compression 2. Android with a FREE vpn https://support.google.com/nexus/answer/6327199?hl=en 3. Google Fiber 4. 8.8.8.8 5. AMP for websites 6. Gmail https://www.google.com/amp/s/www.theverge.com/platform/amp/2019/5/17/1862978... But these things were not really getting into enough high end Apple hands, there was a dark spot in their view of all the Apple traffic. Also, some telcos had ham-fisted attempts to be ad business (vz bought yahoo, aol, and tumbr...), but Google wanted to further ice them out. Who needs another competitor for all your data, right ? https://www.google.com/amp/s/www.washingtonpost.com/technology/2019/09/06/go... So: 6. Using it’s “paid friends” Cloudflare and Mozilla, as it usually does, Google pushes them over the cliff to be the canaries and test public reaction to centralize more of your data and normalize the google data grab... and hiding that data from competitors. Google pushes firefox and cloudflare in to the public ... just like they did with centralize dns (1.1.1.1) and funny vpns that are not VPNs https://twitter.com/notdan/status/1178339685795598336?s=21 , they now want to make chrome and firefox DoH by default. Why? Because 1 they want all your data 2 they can, they control the browser and dont need to coordinate with anyone else to do it (unlike DoT) Ps. Yes, i know i sent AMP links from my gmail account, this is my real world internet experience.
Cheers, -- jra
-- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
participants (39)
-
Aaron C. de Bruyn -
Alain Hebert -
Brandon Butterworth -
Brandon Martin -
bzs＠theworld.com -
Ca By -
Curtis Maurand -
Damian Menscher -
David Conrad -
Frank Habicht -
Fred Baker -
Grimes, Greg -
Grzegorz Janoszka -
Jan Philippi -
Jared Mauch -
Jay Ashworth -
Jay R. Ashworth
-
Jeroen Massar -
Jim -
John Levine -
John R. Levine
-
K. Scott Helms -
Keith Medcalf -
Kevin McCormick -
Livingood, Jason -
Masataka Ohta -
Matt Corallo -
Matt Harris -
Matt Palmer -
Matthew Huff -
Michael Thomas -
Niels Bakker -
Robert Kisteleki -
Sabri Berisha -
Stephane Bortzmeyer -
Tom Hill -
Tom Ivar Helbekkmo -
Valdis Klētnieks -
Warren Kumari