Re: [qubes-users] DNS -- good practice ?

[David Hobach]

Hi Bernhard,

nice to see you're still around. :-)
I hadn't seen you active for a long time, probably I just don't know your nick 
on the forum.


And I ignore if TOR does use "cross checking requests" to detect
manipulation? The question of " best practice " seems non-trivial to me.
Setting up a DNS qube seems a good idea as such, but what kind of
software can trustworthily be run on such a qube??


Personally I use unbound as recursive DNS resolver, but I guess everyone may 
have different trust choices. Anyway that's not specific to Qubes OS.

I also use systemd-resolved in firewall VMs for caching [1].

[1] https://github.com/3hhh/qubes-dns

Best Regards
David


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7723207e-1df1-3542-512c-3cba1c61eeb3%40hackingthe.net.


OpenPGP_0x08DEA51AE90C3780.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] DNS -- good practice ?

[haaber]

Hi all,

I have the impression that DNS questions should get more attention than
the often attract, with the purpose of caching, anonymity, censorship
prvention  & securing against DNS manipulation. Let me start my question
with a citation, that  -at the end- is not that surprising:

"more than two-thirds of the encrypted DNS resolvers manipulate at least
one domain’s DNS response, showing that the DNS manipulation in the
encrypted DNS is even more prevalent than that in the traditional DNS,
where only 11% of the resolvers have been identified to manipulate DNS
responses."

source:
https://digitalcommons.odu.edu/cgi/viewcontent.cgi?article=1195=computerscience_fac_pubs

Somehow, people who feel that their traffic should be anonymous are
surveilled / manipulated with higher energy :) Of course you may answer
to use TOR at all times, but at the end of the day, that does not work
-- many sites either block or limit TOR traffic, etc.

And I ignore if TOR does use "cross checking requests" to detect
manipulation? The question of " best practice " seems non-trivial to me.
Setting up a DNS qube seems a good idea as such, but what kind of
software can trustworthily be run on such a qube??

Thank you for any helpful comment, Bernhard

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f87b2bf1-b87b-1dc3-337a-5b7c284ab67b%40web.de.

[qubes-users] DNS problem with fedora 33 and local addresses (vpn)

[Magali Bardet]

Hello,

I upgraded my fedora templates to fedora 33 recently, but I have 
sometimes a problem with the DNS when I use a vpn (it's a vpn just for 
local addresses under univ-rouen.fr). I first disabled systemd-resolved 
and enabled NetworkManager in the TemplateVM, and when I start the vpn 
everything works fine.


My vpn stops automatically every 2 hours. In that cases, addresses under 
univ-rouen.fr are resolved by their public address (if they have one). 
But if I start again the vpn, local addresses are still resolved by 
their public address in all VM's but sys-net, at least when I use 
nslookup, firefox or thunderbird:


in sys-net:
$ nslookup www.univ-rouen.fr
Server: 10.0.130.11
Address:10.0.130.11#53

www.univ-rouen.fr   canonical name = woel.univ-rouen.fr.
Name:   woel.univ-rouen.fr
Address: 10.0.128.52

in sys-firewall (or other VM connected to syst-firewall):
$ nslookup www.univ-rouen.fr
Server: 10.139.1.1
Address:10.139.1.1#53

Non-authoritative answer:
www.univ-rouen.fr   canonical name = woel.univ-rouen.fr.
Name:   woel.univ-rouen.fr
Address: 193.52.152.49

do you have any idea how I could fix that ?

To get everything working again, I need to restart sys-net and the vpn, 
and sometimes just open the qubes settings for the VMs and validate 
(without changing any parameters) to get the dns working again (without 
this edit I get

$ nslookup imap.univ-rouen.fr
;; connection timed out; no servers could be reached

Thanks

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/56562712-0730-63e4-0856-e42ce95820d2%40univ-rouen.fr.

Re: [qubes-users] DNS issues: servfail on selected subdomains, Qubes modifying DNS replies by stripping IPv6?

[unman]

On Tue, May 11, 2021 at 11:47:50PM +0200, 'qtpie' via qubes-users wrote:
> I have a very annoying issue with DNS recently. I'm using the standard DNS
> device and servers provided by my internetprovider which runs a full
> dual-stack IPv4/6. Other non-qubes devices have no issues. I think this
> might be a Qubes bug but I want to ask for help first to rule out an error
> on my side.
> 
> Selected domainnames (all subdomains, eg www.qubes.org, so not qubes.org)
> get a SERVFAIL when trying to resolve them within applications, and on the
> commandline with 'host' and 'nslookup'. Strangely enough, 'dig' has no
> issues, (querying the same default resolver ip of course). At times, the
> domainname will resolve inside sys-net and certain app-vm's, and not in
> another app-vm. At other times, it resolves nowhere. When quering resolvers
> directly (like my isp's resolvers or 1.1.1.1) the issue does not occur.
> 
> What can be happening here? One of the only consistent hints I found is that
> Qubes does not seem to pass the full nslookup response from sys-net to the
> appvm (compare nslookup examples below). My router gives a servfail when
> quering it via ipv4, nslookup then tries it's ipv6 address, where it does
> get a reply, but this reply is not passed to the appvm. The servfail might
> be an ipv6 issue or an issue with my router, but I think still Qubes should
> pass the full response, right?
> 

Do you have ipv6 enabled across every part of the Qubes networking
chain?

Just to be clear - this is an intermittent issue, intermittent in time
and as it affects qubes?
The fact that dig has no issues is interesting - can you test dig with
IPv4 and IPv6 separately?
Do you see the same behaviour if you set the resolver in sys-net to use
9.9.9.9?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20210512131540.GA3746%40thirdeyesecurity.org.

[qubes-users] DNS issues: servfail on selected subdomains, Qubes modifying DNS replies by stripping IPv6?

['qtpie' via qubes-users]

I have a very annoying issue with DNS recently. I'm using the standard 
DNS device and servers provided by my internetprovider which runs a full 
dual-stack IPv4/6. Other non-qubes devices have no issues. I think this 
might be a Qubes bug but I want to ask for help first to rule out an 
error on my side.


Selected domainnames (all subdomains, eg www.qubes.org, so not 
qubes.org) get a SERVFAIL when trying to resolve them within 
applications, and on the commandline with 'host' and 'nslookup'. 
Strangely enough, 'dig' has no issues, (querying the same default 
resolver ip of course). At times, the domainname will resolve inside 
sys-net and certain app-vm's, and not in another app-vm. At other times, 
it resolves nowhere. When quering resolvers directly (like my isp's 
resolvers or 1.1.1.1) the issue does not occur.


What can be happening here? One of the only consistent hints I found is 
that Qubes does not seem to pass the full nslookup response from sys-net 
to the appvm (compare nslookup examples below). My router gives a 
servfail when quering it via ipv4, nslookup then tries it's ipv6 
address, where it does get a reply, but this reply is not passed to the 
appvm. The servfail might be an ipv6 issue or an issue with my router, 
but I think still Qubes should pass the full response, right?



some affected domainnames:
www.duckduckgo.com
www.startpage.com
textsecure-service.whispersystems.org



user@chat-1:~$ host -v www.startpage.com
Trying "www.startpage.com"
Host www.startpage.com not found: 2(SERVFAIL)
Received 35 bytes from 10.139.1.2#53 in 2 ms

-

user@chat-1:~$ nslookup  www.startpage.com
;; Got SERVFAIL reply from 10.139.1.1, trying next server
Server:        10.139.1.2
Address:    10.139.1.2#53

** server can't find www.startpage.com: SERVFAIL



user@sys-net:~$ host -v www.startpage.com
Trying "www.startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22135
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.startpage.com.        IN    A

;; ANSWER SECTION:
www.startpage.com.    2393    IN    CNAME    startpage.com.
startpage.com.        10    IN    A    145.131.132.72

Received 65 bytes from 192.168.0.1#53 in 4 ms
Trying "startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8508
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;startpage.com.            IN    

;; AUTHORITY SECTION:
startpage.com.        2598    
IN    SOA    dns1.p01.nsone.net. 
hostmaster.nsone.net. 1619470914 3600 600 1209600 3600


Received 96 bytes from 192.168.0.1#53 in 3 ms
Trying "startpage.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;startpage.com.            IN    MX

;; ANSWER SECTION:
startpage.com.        2598    
IN    MX    10 mx2.startmail.com.
startpage.com.        2598    
IN    MX    10 mx1.startmail.com.


Received 81 bytes from 192.168.0.1#53 in 1 ms




user@sys-net:~$ nslookup  www.startpage.com
;; Got SERVFAIL reply from 192.168.0.1, trying next server
Server:        fd00::(redacted):ee5e
Address:    fd00::(redacted):ee5e#53

Non-authoritative answer:
www.startpage.com    canonical name = startpage.com.
Name:    startpage.com
Address: 37.0.87.39



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cf58fe9c-c3f8-be3c-42be-1e40fd64b135%40disroot.org.

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 10/27/19 6:33 AM, gas...@gmail.com wrote:

Is there a clear guide of how to set up a DNS VM in Qubes OS?

I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with
NetworkManager and as a standalone service.  It didn't work.  I also tried
on another VM behind the VPN VM.

All I got working is making DNS requests to the specific VM.  E.g.

$ dig example.com @10.137.0.23

But I wasn't able to hijack the DNS requests with iptables for general
requests without "@".  tcpdump seems to indicate that the DNS queries don't
even get routed through the VPN VM, which doesn't make sense to me, so I
might be missing something.

Any clear step-by-step guide anywhere?


I randomly found
https://blog.tufarolo.eu/how-to-configure-pihole-in-qubesos-proxyvm/

It looks reasonable, but I didn't test it. Use it at your own risk.
Depending on your chain of VMs the Qubes firewall may or may not work 
for DNS - just test it if it matters to you.



--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4f7f6490-7d5c-3a08-ab56-1bf8060edc87%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[gasull]

Is there a clear guide of how to set up a DNS VM in Qubes OS?

I tried setting up dnsmasq in the VPN VM behind sys-firewall, both with 
NetworkManager and as a standalone service.  It didn't work.  I also tried 
on another VM behind the VPN VM.  

All I got working is making DNS requests to the specific VM.  E.g. 

$ dig example.com @10.137.0.23

But I wasn't able to hijack the DNS requests with iptables for general 
requests without "@".  tcpdump seems to indicate that the DNS queries don't 
even get routed through the VPN VM, which doesn't make sense to me, so I 
might be missing something.

Any clear step-by-step guide anywhere?

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/984347f8-29f0-4436-860a-7dd7fba4237c%40googlegroups.com.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, July 3, 2019 5:24 AM, Sphere  wrote:

> You're welcome and good luck!
> In any case, I was reminded that any sort of communication between 
> non-interconnected qubes are not allowed. So even if both of your AppVM qubes 
> and sys-dns qube are connected to sys-firewall then they won't be able to 
> communicate with each other by default. Additional iptables rules must be 
> added to allow it according to what's written here:
> https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes

Hello! Here I am again as promised.
In summary: I managed to create a sys-dns qube running DoT. Long story short, 
it is far from usable. Here are the steps I followed.

0. qvm-clone debian-10-minimal d10-minimal-dns.

1. Create a sys-dns qube which provides network and is based on 
d10-minimal-dns. This qube is behind sys-firewall.

2. qvm-run -u root d10-minimal-dns 'apt install qubes-core-agent-networking 
stubby'

3. In d10-minimal-dns 'nano /etc/stubby/stubby.yml' and add the following 
option >

listen_addresses:
  - 127.0.0.1
  - 0::1
  - 10.137.0.xx # this is sys-dns IP address.


4. In d10-minimal-dns 'nano /etc/resolv.conf >
nameserver 127.0.0.1
namerserver ::1

5. qvm-shutdown d10-minimal-dns

6. qvm-start sys-dns

7. In sys-dns 'nano /rw/config/rc.local' >

iptables -I INPUT -p udp --dport 53 -j ACCEPT
iptables -I INPUT -p tcp --dport 53 -j ACCEPT

8. qvm-shutdown sys-dns

9. Set sys-dns as the network qube of a random app qubes (i.e. 'firefox')

firefox => sys-dns => sys-firewall => sys-net

10. In firefox 'nano /etc/resolv.conf' >
nameserver 10.137.xx # this is sys-dns IP address.

Check with dnsleaktest.com: DoT is working fine and firefox is resolving with 
the standard stubby provider.

Until step 9 every step is easily doable. However step 10 is kind of issue. 
Without step 10, the qube behind sys-dns is using the DNS of my Internet 
provider in order to resolv any address. I can't change resolv.conf everytime I 
open a qube, nor I think is a good idea to change resolv.conf in the template.

Thanks for any suggestions. I am just trying to find a suitable way to run DoT 
on Qubes.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/HEvBH8L79wZgaorSx0TzJlWmFmgRfoh6cA7OM7rlQjxtktzcN9n2XFY3t-b05WHZa8eak4r1SwbxniI56h1zpXzjPLBjK5Q9g7p6LJz91VU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Sphere]

You're welcome and good luck!
In any case, I was reminded that any sort of communication between 
non-interconnected qubes are not allowed. So even if both of your AppVM qubes 
and sys-dns qube are connected to sys-firewall then they won't be able to 
communicate with each other by default. Additional iptables rules must be added 
to allow it according to what's written here:
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8795f202-8452-493d-810d-bbaa973282ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Tuesday, July 2, 2019 7:34 AM, Sphere  wrote:

> With my experience of using DNSCrypt I actually think that Qubes' has some 
> unique way of handling DNS queries given how the nameservers automatically 
> put into /etc/resolv.conf are on a different subnet.
>
> I actually think there must be some sort of bind or unbound being ran in 
> there that resolves all the DNS queries for you by using sys-net or your 
> netvm as a proxy.
>
> In order to make a sys-dns qube or to turn any other qube into a sys-dns qube 
> you must ensure that it is listening on port 53 UDP for any DNS queries.
>
> This command alone given by Chris should be enough.
> iptables -I INPUT -p udp --dport 53 -j ACCEPT
>
> Afterwards you should change your /etc/resolv.conf to the IP address of your 
> sys-dns qube. The IP address can be found out using Qubes Manager and try to 
> ping that ip address first to verify if it is reachable by your AppVM in the 
> first place.
>
> If your sys-dns qube is not your sys-net or netvm then you should ensure that 
> TCP port 853 outbound is allowed through if your firewall rules do not 
> explicitly allow all outbound (all outbound is allowed by default for each 
> qube)
>
> (In dom0 terminal)
> qvm-firewall [sys-firewall or/and sys-dns] add action=accept proto=tcp 
> dstports=853 --before 0
>
> If this doesn't solve it then it may be best to provide us with some logs of 
> your stubby
>

Hi both,
thanks for your suggestions. I am a kind of busy for a couple of days. Once 
things get better I will try to set up a sys-dns qube running DoT following 
your indications and write a report for the mailing list.

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68GHBYcztx2oOiBx0vCqnB91ytiqMTna2vROHcVgs9e0p0R2a0giMiBRck63N-EcFBNqGONoOugI6c4TwNRvTl2wuafEZ7WJgJDlHwX3BGk%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Sphere]

With my experience of using DNSCrypt I actually think that Qubes' has some 
unique way of handling DNS queries given how the nameservers automatically put 
into /etc/resolv.conf are on a different subnet.

I actually think there must be some sort of bind or unbound being ran in there 
that resolves all the DNS queries for you by using sys-net or your netvm as a 
proxy.

In order to make a sys-dns qube or to turn any other qube into a sys-dns qube 
you must ensure that it is listening on port 53 UDP for any DNS queries.

This command alone given by Chris should be enough.
iptables -I INPUT -p udp --dport 53 -j ACCEPT

Afterwards you should change your /etc/resolv.conf to the IP address of your 
sys-dns qube. The IP address can be found out using Qubes Manager and try to 
ping that ip address first to verify if it is reachable by your AppVM in the 
first place.

If your sys-dns qube is not your sys-net or netvm then you should ensure that 
TCP port 853 outbound is allowed through if your firewall rules do not 
explicitly allow all outbound (all outbound is allowed by default for each qube)

(In dom0 terminal)
qvm-firewall [sys-firewall or/and sys-dns] add action=accept proto=tcp 
dstports=853 --before 0

If this doesn't solve it then it may be best to provide us with some logs of 
your stubby

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/24d42a1d-b5cc-4d92-9aed-a5f209b1195a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Chris Laprise]

On 7/1/19 3:40 PM, 'qubeslover' via qubes-users wrote:

Hello,

I tried but without results.

1. dnf install getdns-stubby in fedora-30-firewall (template).

2. servicectl enable stubby in fedora-30-firewall.

3. Shutdown fedora-30-firewall.

4. Restart sys-firewall

4. Sudo nano /etc/resolv.conf and change nameserver in 127.0.0.1 and ::1

5. Run /usr/lib/qubes/qubes-setup-dnat-to-ns as root.

I can ping the outside world and sys-firewall can resolve hostnames. However, 
the qubes behind it can't.


Hmmm. I hate to keep tossing suggestions at you without having tried DoT 
myself (though I hope to make time for it in the next couple weeks).


But... if 127.0.0.1/localhost is the dnat target, then the INPUT chain 
comes into the picture. By default, Qubes configures INPUT to reject any 
new requests (packets that don't satisfy 'related' or 'established' 
conditions). As a quick workaround, you could try allowing DNS packets 
in sys-firewall:


iptables -I INPUT -p udp --dport 53 -j ACCEPT
iptables -I INPUT -p tcp --dport 53 -j ACCEPT



For sure, I am messing up somewhere. It is a sin: I would like to have a 
sys-dns qube running DoT or DoH.

Thanks a lot for your attention, interest and help. Again, very much 
appreciated.



--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/58595ece-a717-4315-eabd-12ba5dee76fa%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Sunday, June 30, 2019 11:20 PM, 'qubeslover' via qubes-users 
 wrote:

> ‐‐‐ Original Message ‐‐‐
> On Sunday, June 30, 2019 10:36 PM, Chris Laprise tas...@posteo.net wrote:
>
> > On 6/30/19 4:10 PM, Chris Laprise wrote:
> >
> > > > > A shortcut you can take to setting up iptables for DNS is to populate
> > > > > /etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
> > > > > This should configure the nat/PR-QBS chain with the DNS addresses you
> > > > > set.
> > >
> > > So check that your DoT setup is updating /etc/resolv.conf, then run
> > > '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
>
> Thanks for you suggestion. Apparently, it does not work in sys-net.
>
> Stubby is up, working and connected to its default DoT providers (as lsof -i 
> asserts):
>
> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
> stubby 534 stubby 3u IPv4 17946 0t0 UDP localhost:domain
> stubby 534 stubby 4u IPv4 17947 0t0 TCP localhost:domain (LISTEN)
> stubby 534 stubby 5u IPv6 17948 0t0 UDP localhost:domain
> stubby 534 stubby 6u IPv6 17949 0t0 TCP localhost:domain (LISTEN)
> stubby 534 stubby 7u IPv4 35444 0t0 TCP 
> sys-net:46006->145.100.185.16:domain-s (ESTABLISHED)
> stubby 534 stubby 8u IPv4 35447 0t0 TCP sys-net:45550->getdnsapi.net:domain-s 
> (ESTABLISHED)
> NetworkMa 564 root 17u IPv4 31022 0t0 UDP sys-net:bootpc
> systemd-r 647 systemd-resolve 11u IPv4 19350 0t0 UDP *:hostmon
> systemd-r 647 systemd-resolve 12u IPv4 19351 0t0 TCP *:hostmon (LISTEN)
> systemd-r 647 systemd-resolve 13u IPv6 19353 0t0 UDP *:hostmon
> systemd-r 647 systemd-resolve 14u IPv6 19354 0t0 TCP *:hostmon (LISTEN)
> systemd-r 647 systemd-resolve 16u IPv4 19358 0t0 UDP 127.0.0.53:domain
> systemd-r 647 systemd-resolve 17u IPv4 19359 0t0 TCP 127.0.0.53:domain 
> (LISTEN)
> tinyproxy 1547 tinyproxy 4u IPv4 32068 0t0 TCP *:us-cli (LISTEN)
> tinyproxy 1547 tinyproxy 5u IPv6 32069 0t0 TCP *:us-cli (LISTEN)
> tinyproxy 1548 tinyproxy 4u IPv4 32068 0t0 TCP *:us-cli (LISTEN)
> tinyproxy 1548 tinyproxy 5u IPv6 32069 0t0 TCP *:us-cli (LISTEN)
> tinyproxy 1549 tinyproxy 4u IPv4 32068 0t0 TCP *:us-cli (LISTEN)
>
> Also, nano claims that everything is right in /etc/resolv.conf
>
> Generated by NetworkManager
>
> 
>
> nameserver 127.0.0.1
> nameserver ::1
>
> As root, I run /usr/lib/qubes/qubes-setup-dnat-to-ns . Everything looks fine.
>
> I can ping the outside world but sys-net does not receive any request from my 
> qubes :-(
>
> > Additional thought: The sys-net VM may not be the best place to secure
> > any data, DNS included. Putting DoT in sys-firewall or similar proxyVM
> > (and using qubes-setup-dnat-to-ns there) would be a better choice and
> > has a fair chance of working.
>
> OK, will try tomorrow with sys-firewall and see what happens.
>

Hello,

I tried but without results.

1. dnf install getdns-stubby in fedora-30-firewall (template).

2. servicectl enable stubby in fedora-30-firewall.

3. Shutdown fedora-30-firewall.

4. Restart sys-firewall

4. Sudo nano /etc/resolv.conf and change nameserver in 127.0.0.1 and ::1

5. Run /usr/lib/qubes/qubes-setup-dnat-to-ns as root.

I can ping the outside world and sys-firewall can resolve hostnames. However, 
the qubes behind it can't.

For sure, I am messing up somewhere. It is a sin: I would like to have a 
sys-dns qube running DoT or DoH.

Thanks a lot for your attention, interest and help. Again, very much 
appreciated.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bP-yHOHB2lzMcPmqC9oiymt22tnm2EAechJ9Q9dXylzEGbWhD4Ik8CqGkdOj6iHVggbzCX46wjR1j-u217UC9ZnudW-kmWRn6VtNa1jXptQ%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

‐‐‐ Original Message ‐‐‐
On Sunday, June 30, 2019 10:36 PM, Chris Laprise  wrote:

> On 6/30/19 4:10 PM, Chris Laprise wrote:
>
> > > > A shortcut you can take to setting up iptables for DNS is to populate
> > > > /etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
> > > > This should configure the nat/PR-QBS chain with the DNS addresses you
> > > > set.
> >
> > So check that your DoT setup is updating /etc/resolv.conf, then run
> > '/usr/lib/qubes/qubes-setup-dnat-to-ns'.


Thanks for you suggestion. Apparently, it does not work in sys-net.

Stubby is up, working and connected to its default DoT providers (as lsof -i 
asserts):


COMMANDPIDUSER   FD   TYPE DEVICE SIZE/OFF NODE NAME
stubby 534  stubby3u  IPv4  17946  0t0  UDP localhost:domain
stubby 534  stubby4u  IPv4  17947  0t0  TCP 
localhost:domain (LISTEN)
stubby 534  stubby5u  IPv6  17948  0t0  UDP localhost:domain
stubby 534  stubby6u  IPv6  17949  0t0  TCP 
localhost:domain (LISTEN)
stubby 534  stubby7u  IPv4  35444  0t0  TCP 
sys-net:46006->145.100.185.16:domain-s (ESTABLISHED)
stubby 534  stubby8u  IPv4  35447  0t0  TCP 
sys-net:45550->getdnsapi.net:domain-s (ESTABLISHED)
NetworkMa  564root   17u  IPv4  31022  0t0  UDP sys-net:bootpc
systemd-r  647 systemd-resolve   11u  IPv4  19350  0t0  UDP *:hostmon
systemd-r  647 systemd-resolve   12u  IPv4  19351  0t0  TCP *:hostmon 
(LISTEN)
systemd-r  647 systemd-resolve   13u  IPv6  19353  0t0  UDP *:hostmon
systemd-r  647 systemd-resolve   14u  IPv6  19354  0t0  TCP *:hostmon 
(LISTEN)
systemd-r  647 systemd-resolve   16u  IPv4  19358  0t0  UDP 
127.0.0.53:domain
systemd-r  647 systemd-resolve   17u  IPv4  19359  0t0  TCP 
127.0.0.53:domain (LISTEN)
tinyproxy 1547   tinyproxy4u  IPv4  32068  0t0  TCP *:us-cli 
(LISTEN)
tinyproxy 1547   tinyproxy5u  IPv6  32069  0t0  TCP *:us-cli 
(LISTEN)
tinyproxy 1548   tinyproxy4u  IPv4  32068  0t0  TCP *:us-cli 
(LISTEN)
tinyproxy 1548   tinyproxy5u  IPv6  32069  0t0  TCP *:us-cli 
(LISTEN)
tinyproxy 1549   tinyproxy4u  IPv4  32068  0t0  TCP *:us-cli 
(LISTEN)


Also, nano claims that everything is right in /etc/resolv.conf

# Generated by NetworkManager
nameserver 127.0.0.1
nameserver ::1


As root, I run /usr/lib/qubes/qubes-setup-dnat-to-ns . Everything looks fine.

I can ping the outside world but sys-net does not receive any request from my 
qubes :-(

> Additional thought: The sys-net VM may not be the best place to secure
> any data, DNS included. Putting DoT in sys-firewall or similar proxyVM
> (and using qubes-setup-dnat-to-ns there) would be a better choice and
> has a fair chance of working.

OK, will try tomorrow with sys-firewall and see what happens.

>
> There is also a chance that configuring DoT to run in your AppVMs,
> instead, could work and without any special Qubes steps.
>


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1Tx8lU2t-zeR8NRc1t3tmQe2GM4aPITcooW2ZdkkeI_Hj2oOTD-3UCGlrtUImviqz8OL0w22jzUbmP2-kbKxNNRcqBqP_nErvMZLnAyZxZg%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Chris Laprise]

On 6/30/19 4:10 PM, Chris Laprise wrote:

A shortcut you can take to setting up iptables for DNS is to populate
/etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
This should configure the nat/PR-QBS chain with the DNS addresses you 
set.


So check that your DoT setup is updating /etc/resolv.conf, then run 
'/usr/lib/qubes/qubes-setup-dnat-to-ns'.


Additional thought: The sys-net VM may not be the best place to secure 
any data, DNS included. Putting DoT in sys-firewall or similar proxyVM 
(and using qubes-setup-dnat-to-ns there) would be a better choice and 
has a fair chance of working.


There is also a chance that configuring DoT to run in your AppVMs, 
instead, could work and without any special Qubes steps.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9625b54f-2711-cddd-3095-4fbdd99e5f65%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Chris Laprise]

On 6/30/19 2:46 PM, 'qubeslover' via qubes-users wrote:


Dear tasket,
today here is so hot that I feel like I am drunk. I typed the wrong title. The 
topic actually was

"Dns-over-TLS in *sys-net*. Is it possible? How?"

Obviously, as you correctly (and politely) pointed out, it doesn't make sense 
at all to run DoT over VPN. Actually, I want to run DoT in sys-net since my 
link is insecure.

Apologies for mistake. Suggestions are still appreciated.

Off Topic P.S: I use and love your scripts and extensions for Qubes. You made 
my life much easier. Look forward to test sparsebak once encryption will be 
deployed into it.


Cool. Then this part still applies in sys-net:


A shortcut you can take to setting up iptables for DNS is to populate
/etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
This should configure the nat/PR-QBS chain with the DNS addresses you set.


So check that your DoT setup is updating /etc/resolv.conf, then run 
'/usr/lib/qubes/qubes-setup-dnat-to-ns'.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5e060b4a-4561-9123-1077-a109971c7a9e%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

Dear tasket,
today here is so hot that I feel like I am drunk. I typed the wrong title. The 
topic actually was

"Dns-over-TLS in *sys-net*. Is it possible? How?"

Obviously, as you correctly (and politely) pointed out, it doesn't make sense 
at all to run DoT over VPN. Actually, I want to run DoT in sys-net since my 
link is insecure.

Apologies for mistake. Suggestions are still appreciated.

Off Topic P.S: I use and love your scripts and extensions for Qubes. You made 
my life much easier. Look forward to test sparsebak once encryption will be 
deployed into it.



Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Sunday, June 30, 2019 7:12 PM, Chris Laprise  wrote:

> On 6/30/19 9:17 AM, 'qubeslover' via qubes-users wrote:
>
> > Dear qubes users,
> > I wish you a good Sunday.
> > I'd like to use DoT on my qubes laptop. However, I am not sure how to do. I 
> > have followed a couple of pretty straightforward tutorials 
> > (https://www.techrepublic.com/article/how-to-use-dns-over-tls-on-ubuntu-linux/
> >  and 
> > https://techrevelations.de/2019/01/11/encrypted-dns-and-how-to-use-it-in-linux/),
> >  installed stubby and configured NetworkManager - /etc/resolv.conf properly 
> > in sys-net.
> > Stubby connects to its default DoT servers and I can ping google from 
> > sys-net. However, I can't resolve addresses from other qubes (like 
> > sys-firewall etc). Has somebody managed to use DoT in Qubes? Which 
> > documents should I read in order to understand how networking, routing and 
> > name resolution work in QubesOS so that I can use DoT?
>
> Hi,
>
> The vpn doc (step 3) has a good example of setting up DNS for a VPN
> "proxy VM": The iptables nat/PR-QBS chain must be populated with dnat
> rules for your DNS ips.
>
> (A proxy VM is just like sys-firewall: Its an appVM created with the
> 'provides network' option set and acts like a router.)
>
> https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts
>
> A version of this with more automatic setup is here:
>
> https://github.com/tasket/Qubes-vpn-support
>
> A shortcut you can take to setting up iptables for DNS is to populate
> /etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'.
> This should configure the nat/PR-QBS chain with the DNS addresses you set.
>
> A final note: There doesn't seem to be much demand for DoT over a VPN, I
> think because VPN providers usually have their own DNS servers which are
> protected by the VPN protocol. Something like DoT becomes useful only
> when your link is generally insecure or you need to use a third-party
> DNS for some other reason (i.e. you set up your own VPN server but not a
> DNS server to go with it).
>
> -
>
> Chris Laprise,tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9WXrT765SQgqQPM0yc8YXEL36bN9ua56wIZZTlRnhhKew8Nl0d6z9GHaoCpnCavs3zHH0AUQe4CxmPOwNFy33LDBXX8kZrkU6prqPEgSQW8%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

[Chris Laprise]

On 6/30/19 9:17 AM, 'qubeslover' via qubes-users wrote:

Dear qubes users,
I wish you a good Sunday.

I'd like to use DoT on my qubes laptop. However, I am not sure how to do. I 
have followed a couple of pretty straightforward tutorials 
(https://www.techrepublic.com/article/how-to-use-dns-over-tls-on-ubuntu-linux/ 
and 
https://techrevelations.de/2019/01/11/encrypted-dns-and-how-to-use-it-in-linux/),
  installed stubby and configured NetworkManager - /etc/resolv.conf properly in 
sys-net.

Stubby connects to its default DoT servers and I can ping google from sys-net. 
However, I can't resolve addresses from other qubes (like sys-firewall etc). 
Has somebody managed to use DoT in Qubes? Which documents should I read in 
order to understand how networking, routing and name resolution work in QubesOS 
so that I can use DoT?


Hi,

The vpn doc (step 3) has a good example of setting up DNS for a VPN 
"proxy VM": The iptables nat/PR-QBS chain must be populated with dnat 
rules for your DNS ips.


(A proxy VM is just like sys-firewall: Its an appVM created with the 
'provides network' option set and acts like a router.)


https://www.qubes-os.org/doc/vpn/#set-up-a-proxyvm-as-a-vpn-gateway-using-iptables-and-cli-scripts

A version of this with more automatic setup is here:

https://github.com/tasket/Qubes-vpn-support

A shortcut you can take to setting up iptables for DNS is to populate 
/etc/resolv.conf and then run '/usr/lib/qubes/qubes-setup-dnat-to-ns'. 
This should configure the nat/PR-QBS chain with the DNS addresses you set.


A final note: There doesn't seem to be much demand for DoT over a VPN, I 
think because VPN providers usually have their own DNS servers which are 
protected by the VPN protocol. Something like DoT becomes useful only 
when your link is generally insecure or you need to use a third-party 
DNS for some other reason (i.e. you set up your own VPN server but not a 
DNS server to go with it).


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/075a360f-4778-d951-8702-d4541cee6654%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Dns-over-TLS in sys-vpn. Is it possible? How?

['qubeslover' via qubes-users]

Dear qubes users,
I wish you a good Sunday.

I'd like to use DoT on my qubes laptop. However, I am not sure how to do. I 
have followed a couple of pretty straightforward tutorials 
(https://www.techrepublic.com/article/how-to-use-dns-over-tls-on-ubuntu-linux/ 
and 
https://techrevelations.de/2019/01/11/encrypted-dns-and-how-to-use-it-in-linux/),
  installed stubby and configured NetworkManager - /etc/resolv.conf properly in 
sys-net.

Stubby connects to its default DoT servers and I can ping google from sys-net. 
However, I can't resolve addresses from other qubes (like sys-firewall etc). 
Has somebody managed to use DoT in Qubes? Which documents should I read in 
order to understand how networking, routing and name resolution work in QubesOS 
so that I can use DoT?

Sent with ProtonMail Secure Email.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/SBAX64xhQOEhwho-FUjlyW_7X0LuzMc-1yhFpatd1JzZmZP5J852In-9b8SFZk4hpmSQXnFVOxb_cnFQrPowQDQOwbk5mrOkeTnsJcu7yXM%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 13 Mar 2018, at 18:49, David Hobach  wrote:
> 
> On 03/13/2018 07:14 AM, Alex Dubois wrote:
>>> On 12 Mar 2018, at 18:40, David Hobach  wrote:
>>> 
 On 03/11/2018 03:15 PM, David Hobach wrote:
 An alternative might be to setup the local DNS service in a VM closer to 
 the Internet, i.e. not in the proxy VM which also implements the qubes 
 firewall.
 Something like
 Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
 qubes-fw <-- client VM
 I didn't test that though.
>>> 
>>> I just tested that as well now and it works as expected without any of the 
>>> aforementioned caveats.
>>> 
>>> So I'd recommend the one above over the previously discussed
>>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
>>> (at least I was talking about that architecture - maybe the others were 
>>> talking about something different...).
>>> The same holds true for VPN users.
>> This type of architecture is bad practice as the attack surface of DNS is 
>> bigger than Qubes firewall, and an attack on this daemon compromise all 
>> traffic, not just DNS.
>> A better arch is
>> Internet
>> - netVM
>> - - firewallVM
>> - - - Service (ie DNS or VPN)
>> - - - clientVM1
>> - - - clientVM2
> 
> I believe your essential point was not to use proxy VMs for services at all.
> 
> My main point was not to mix a Qubes Firewall VM with local services. I think 
> you basically agree with that.

Yes agree

> 
> I however also disagree with your point wrt proxy VM usage as there's no 
> attack vector for E2E encrypted traffic on proxy VMs except for DoS which 
> you'll notice.

Let’s agree to disagree;). This is possibly true client to VPN, but the attack 
surface VPN to internetVPN is not small, there are a substantial number of line 
of code for the support of various protocols, with negotiation phases, parsing 
of data stream into such control flow. (I.e. some of the long list of OpenSSL 
vuln lead to remote code exec I suspect). 
So my point is you can use proxy if all the clients are going to use the VPN. 
And this apply also only if all the traffic would flow through the service (VPN 
use case OK, dns or http proxy not OK).

> If you're using non-E2E encrypted traffic (except for maybe DNS) you have a 
> different problem altogether and even then I'd trust my proxy VM a lot more 
> than any other hop (your Wifi provider? the 4+ backbone providers you pass?) 
> on the route to the destination.
I may have misunderstood you, but this is outside the subject of the discussion 
or please clarify. 

> 
> Moreover it is rather inconvenient to configure each and every client VM to 
> use that service VM which can also lead to unexpected misconfigurations & 
> leakages.
I agree that it is less trivial to setup but you lower your attack surface 
significantly.

So I agree that it depends on the circumstances, but I think my statement is 
preferable as a general rule, and I think Qubes should move toward supporting 
such setup, making it easier to configure. 

Best Regards
Alex
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/14B0F388-B653-4981-A8B6-D0901E3B5B18%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 03/13/2018 07:14 AM, Alex Dubois wrote:

On 12 Mar 2018, at 18:40, David Hobach  wrote:


On 03/11/2018 03:15 PM, David Hobach wrote:
An alternative might be to setup the local DNS service in a VM closer to the 
Internet, i.e. not in the proxy VM which also implements the qubes firewall.
Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with qubes-fw 
<-- client VM
I didn't test that though.


I just tested that as well now and it works as expected without any of the 
aforementioned caveats.

So I'd recommend the one above over the previously discussed
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
(at least I was talking about that architecture - maybe the others were talking 
about something different...).
The same holds true for VPN users.


This type of architecture is bad practice as the attack surface of DNS is 
bigger than Qubes firewall, and an attack on this daemon compromise all 
traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2


I believe your essential point was not to use proxy VMs for services at all.

My main point was not to mix a Qubes Firewall VM with local services. I 
think you basically agree with that.


I however also disagree with your point wrt proxy VM usage as there's no 
attack vector for E2E encrypted traffic on proxy VMs except for DoS 
which you'll notice.
If you're using non-E2E encrypted traffic (except for maybe DNS) you 
have a different problem altogether and even then I'd trust my proxy VM 
a lot more than any other hop (your Wifi provider? the 4+ backbone 
providers you pass?) on the route to the destination.


Moreover it is rather inconvenient to configure each and every client VM 
to use that service VM which can also lead to unexpected 
misconfigurations & leakages.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e117d09a-974c-904d-2532-b890b2c77008%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 12 Mar 2018, at 18:40, David Hobach  wrote:
> 
>> On 03/11/2018 03:15 PM, David Hobach wrote:
>> An alternative might be to setup the local DNS service in a VM closer to the 
>> Internet, i.e. not in the proxy VM which also implements the qubes firewall.
>> Something like
>> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM with 
>> qubes-fw <-- client VM
>> I didn't test that though.
> 
> I just tested that as well now and it works as expected without any of the 
> aforementioned caveats.
> 
> So I'd recommend the one above over the previously discussed
> Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
> (at least I was talking about that architecture - maybe the others were 
> talking about something different...).
> The same holds true for VPN users.

This type of architecture is bad practice as the attack surface of DNS is 
bigger than Qubes firewall, and an attack on this daemon compromise all 
traffic, not just DNS.

A better arch is
Internet
- netVM
- - firewallVM
- - - Service (ie DNS or VPN)
- - - clientVM1
- - - clientVM2

And firewallVM intercept the traffic for the VM that needs it.
Note that a service can also be a client for another service.
Note2 that does not mean that the arch should be flat, if you are worried that 
a mis conf of firewallVM could put you at risk you could do
Internet
- NetVM
- - FirewallVM
- - - FirewallVPN
- - - - clientVPNVM
- - - - vpmServiceVM
- - - firewallDNS
- - - - clientDNSVM
- - - - dnsServiceVM
- - - firewallWebServer
- - - - ReverseProxyAuthVMservice
- - - - - webServerVMservice
- - - - - - webDMserviceVM
- - - - ClientWebVM

> 
> I also documented this at https://github.com/QubesOS/qubes-issues/issues/3051
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/C3D0CBC3-8C5A-4BB5-B866-866E9B3144D9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 03/11/2018 03:15 PM, David Hobach wrote:
An alternative might be to setup the local DNS service in a VM closer to 
the Internet, i.e. not in the proxy VM which also implements the qubes 
firewall.


Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM 
with qubes-fw <-- client VM


I didn't test that though.


I just tested that as well now and it works as expected without any of 
the aforementioned caveats.


So I'd recommend the one above over the previously discussed
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- client VM
(at least I was talking about that architecture - maybe the others were 
talking about something different...).

The same holds true for VPN users.

I also documented this at 
https://github.com/QubesOS/qubes-issues/issues/3051


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b1482304-c9c8-11d6-c988-4adcc737380b%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

Sent from my mobile phone.

> On 11 Mar 2018, at 10:21, Chris Laprise  wrote:
> 
>> On 03/10/2018 04:43 PM, Alex Dubois wrote:
>>> On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
>>> ‐‐‐ Original Message ‐‐‐
>>> 
 On March 8, 2018 11:26 AM, Chris Laprise  wrote:
 
 ​​
 
>>> \> \[1\] https://dnsprivacy.org/wiki/
 
 \[2\] https://www.qubes-os.org/doc/networking/
 
 Micah,
 
 If you have any specific instructions on how to setup the forwarder
 
 you're using, I'd be happy to try it myself and post a solution for use
 
 with qubes-firewall.
 
 I found the dnsprivacy wiki to be a bit scattered and not very specific.
 
 Their video "tutorial" is really a lecture on the concept.
>>> 
>>> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
>>> -- I'm traveling right now and haven't spent a lot of time on it, and might 
>>> not for the next week or two. But once I figure it out I'd like to write a 
>>> blog post or something with instructions. But maybe I should sent it to 
>>> this list first for people to test and give feedback.
>> For your info, I have a wiki on how to use dns-crypt here: 
>> https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
>> It is supposed to be exposed via blog.bowabos.com but github changed 
>> something and the static site does not get automatically generated at the 
>> moment...
> 
> Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy and 
> unbound.
> 
> One problem is that the howto assumes particular Qubes 10.137.2.x and 
> 10.138.2.x nets for unbound.

Yes I need to rewrite it for Qubes 4.

The other blog post on Atlassian stack also needs a rewrite and I have now a 
better network topology (more secure) for it. Time is my problem

> 
> Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all share 
> the same IP address. This isn't explained in the Qubes networking or firewall 
> docs, so it may be a bug...
> 
> To keep unbound.service from failing I changed unbound.conf to this:
> 
>> interface: 
>> access-control: 10.137.0.0/24 allow
>> harden-large-queries: yes
>> private-address: 10.0.0.0/8
>> private-address: 192.168.0.0/16
>> val-permissive-mode: yes
>> do-not-query-localhost: no
> 
> ...and for now omitted the '-d' destination part in iptables.
> 
> Then if I issue:
> 
>> sudo iptables -t nat -F PR-QBS
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
>> $eth0_address
>> sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
>> $eth0_address
> 
> it appears to work from a downstream appVM. But I haven't checked yet to see 
> if its really using the dnscrypt proxy; even if it is, the config may need to 
> be adjusted for better security.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8ECF3140-FD4B-400C-AB7D-A459F74327AC%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Chris Laprise]

On 03/11/2018 10:03 AM, David Hobach wrote:

On 03/11/2018 11:21 AM, Chris Laprise wrote:

...and for now omitted the '-d' destination part in iptables.

Then if I issue:


sudo iptables -t nat -F PR-QBS
sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT 
--to $eth0_address
sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT 
--to $eth0_address


it appears to work from a downstream appVM. But I haven't checked yet 
to see if its really using the dnscrypt proxy; even if it is, the 
config may need to be adjusted for better security.


I just tested that one (my implementation was also doing pretty much 
exactly that + a local INPUT chain firewall so it was a 5 min test 
removing the INPUT firewall):


Since you'll need something like

-I INPUT -p udp -m udp --dport 53 -j ACCEPT
-I INPUT -p tcp -m tcp --dport 53 -j ACCEPT


I used this, which is Alex's example without '-d':

iptables -I INPUT 3 -j ACCEPT -p udp --sport 1024:65535 --dport 53 -m 
conntrack --ctstate NEW




it makes DNS accessible for all downstream VMs regardless of the 
qubes-firewall settings, i.e. apprently the nft FORWARD rules are not 
applied for DNAT to localhost.


That's probably why I had opened that github issue & implemented a local 
firewall back then...


You can verify my findings by using the dom0 qvm-firewall command line 
to revoke DNS access for a downstream VM & then use e.g. dig in that VM. 
The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always 
allowed.


So yes, if one is aware of that issue, one can certainly use it the way 
you described. If you rely on the qubes-firewall to work as expected, 
you shouldn't use it.


Thanks for the specific caveat.

Qubes 3.2 firewall had a dns incompatibility when you configured a 
tunnel such as openvpn. I was able to fix that problem (pretty 
seamlessly) with sed :) .


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a802b5cd-0b42-c548-716b-3eaf3519f17d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 03/11/2018 03:03 PM, David Hobach wrote:
So yes, if one is aware of that issue, one can certainly use it the way 
you described. If you rely on the qubes-firewall to work as expected, 
you shouldn't use it.


P.S.:
An alternative might be to setup the local DNS service in a VM closer to 
the Internet, i.e. not in the proxy VM which also implements the qubes 
firewall.


Something like
Internet <-- sys-net <-- sys-firewall <-- DNS server VM <-- proxy VM 
with qubes-fw <-- client VM


I didn't test that though.

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ec054435-0c3c-9517-f02f-f9c2c50c19a8%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 03/11/2018 11:21 AM, Chris Laprise wrote:

...and for now omitted the '-d' destination part in iptables.

Then if I issue:


sudo iptables -t nat -F PR-QBS
sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
$eth0_address
sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
$eth0_address


it appears to work from a downstream appVM. But I haven't checked yet to 
see if its really using the dnscrypt proxy; even if it is, the config 
may need to be adjusted for better security.


I just tested that one (my implementation was also doing pretty much 
exactly that + a local INPUT chain firewall so it was a 5 min test 
removing the INPUT firewall):


Since you'll need something like

-I INPUT -p udp -m udp --dport 53 -j ACCEPT
-I INPUT -p tcp -m tcp --dport 53 -j ACCEPT

it makes DNS accessible for all downstream VMs regardless of the 
qubes-firewall settings, i.e. apprently the nft FORWARD rules are not 
applied for DNAT to localhost.


That's probably why I had opened that github issue & implemented a local 
firewall back then...


You can verify my findings by using the dom0 qvm-firewall command line 
to revoke DNS access for a downstream VM & then use e.g. dig in that VM. 
The qubes-vm-settings GUI won't work as in 4.0 DNS & ICMP is always allowed.


So yes, if one is aware of that issue, one can certainly use it the way 
you described. If you rely on the qubes-firewall to work as expected, 
you shouldn't use it.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ba33e227-187d-4945-6b51-d1ef0093d21a%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[Chris Laprise]

On 03/10/2018 04:43 PM, Alex Dubois wrote:

On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:

‐‐‐ Original Message ‐‐‐

On March 8, 2018 11:26 AM, Chris Laprise  wrote:


​​


\> \[1\] https://dnsprivacy.org/wiki/



\[2\] https://www.qubes-os.org/doc/networking/


Micah,

If you have any specific instructions on how to setup the forwarder

you're using, I'd be happy to try it myself and post a solution for use

with qubes-firewall.

I found the dnsprivacy wiki to be a bit scattered and not very specific.

Their video "tutorial" is really a lecture on the concept.


Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- 
I'm traveling right now and haven't spent a lot of time on it, and might not 
for the next week or two. But once I figure it out I'd like to write a blog 
post or something with instructions. But maybe I should sent it to this list 
first for people to test and give feedback.


For your info, I have a wiki on how to use dns-crypt here: 
https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
It is supposed to be exposed via blog.bowabos.com but github changed something 
and the static site does not get automatically generated at the moment...



Nice. I gave this a try on debian-9, using apt to install dnscrypt-proxy 
and unbound.


One problem is that the howto assumes particular Qubes 10.137.2.x and 
10.138.2.x nets for unbound.


Another problem is that on Qubes 4.0 the vif interfaces plus eth0 all 
share the same IP address. This isn't explained in the Qubes networking 
or firewall docs, so it may be a bug...


To keep unbound.service from failing I changed unbound.conf to this:


interface: 
access-control: 10.137.0.0/24 allow
harden-large-queries: yes
private-address: 10.0.0.0/8
private-address: 192.168.0.0/16
val-permissive-mode: yes
do-not-query-localhost: no


...and for now omitted the '-d' destination part in iptables.

Then if I issue:


sudo iptables -t nat -F PR-QBS
sudo iptables -t nat -A PR-QBS  -i vif+ -p udp --dport 53 -j DNAT --to 
$eth0_address
sudo iptables -t nat -A PR-QBS  -i vif+ -p tcp --dport 53 -j DNAT --to 
$eth0_address


it appears to work from a downstream appVM. But I haven't checked yet to 
see if its really using the dnscrypt proxy; even if it is, the config 
may need to be adjusted for better security.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6be04a34-d79d-df7f-cd64-68d098613df6%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Alex Dubois]

On Saturday, 10 March 2018 13:16:37 UTC, Micah Lee  wrote:
> ‐‐‐ Original Message ‐‐‐
> 
> On March 8, 2018 11:26 AM, Chris Laprise  wrote:
> 
> > ​​
> > 
> > >>>\> \[1\] https://dnsprivacy.org/wiki/
> > 
> > > > > > \[2\] https://www.qubes-os.org/doc/networking/
> > 
> > Micah,
> > 
> > If you have any specific instructions on how to setup the forwarder
> > 
> > you're using, I'd be happy to try it myself and post a solution for use
> > 
> > with qubes-firewall.
> > 
> > I found the dnsprivacy wiki to be a bit scattered and not very specific.
> > 
> > Their video "tutorial" is really a lecture on the concept.
> 
> Thanks, yes I'd love to share instructions. I haven't gotten it working yet 
> -- I'm traveling right now and haven't spent a lot of time on it, and might 
> not for the next week or two. But once I figure it out I'd like to write a 
> blog post or something with instructions. But maybe I should sent it to this 
> list first for people to test and give feedback.

For your info, I have a wiki on how to use dns-crypt here: 
https://github.com/adubois/adubois.github.io/blob/master/_posts/2013-11-19-setup-dnscrypt-unbound.md
It is supposed to be exposed via blog.bowabos.com but github changed something 
and the static site does not get automatically generated at the moment...

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/11825052-26fe-48a8-bd08-7da3f15b7787%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Micah Lee]

‐‐‐ Original Message ‐‐‐

On March 8, 2018 11:26 AM, Chris Laprise  wrote:

> ​​
> 
> >>>\> \[1\] https://dnsprivacy.org/wiki/
> 
> > > > > \[2\] https://www.qubes-os.org/doc/networking/
> 
> Micah,
> 
> If you have any specific instructions on how to setup the forwarder
> 
> you're using, I'd be happy to try it myself and post a solution for use
> 
> with qubes-firewall.
> 
> I found the dnsprivacy wiki to be a bit scattered and not very specific.
> 
> Their video "tutorial" is really a lecture on the concept.

Thanks, yes I'd love to share instructions. I haven't gotten it working yet -- 
I'm traveling right now and haven't spent a lot of time on it, and might not 
for the next week or two. But once I figure it out I'd like to write a blog 
post or something with instructions. But maybe I should sent it to this list 
first for people to test and give feedback.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/pPIWHaxl0Lwz4sF1qRHn34jz0i4_oDljtkWk8CQMPNnOtFFKBsOS7gaUGQqLXC9ZFprlaPHpcPW_4IX_LKKwm9no1c-DO7byugnObo8aXzY%3D%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Chris Laprise]

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/


Micah,

If you have any specific instructions on how to setup the forwarder 
you're using, I'd be happy to try it myself and post a solution for use 
with qubes-firewall.


I found the dnsprivacy wiki to be a bit scattered and not very specific. 
Their video "tutorial" is really a lecture on the concept.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cbdcbcac-00c8-9476-3e94-04a4a6b9e9bc%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Chris Laprise]

On 03/08/2018 01:16 PM, David Hobach wrote:

On 03/07/2018 06:40 PM, Unman wrote:

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
I'm trying to make all DNS requests in Qubes go over TLS (more 
information about this [1]).


I've got this successfully working in sys-net by running a local DNS 
server on udp 53 that forwards DNS requests to a remote DNS server 
over TLS, and then setting my only nameserver in /etc/resolv.conf to 
127.0.0.1. I've confirmed that this works great in sys-net -- all of 
my DNS requests are encrypted to my remote DNS server, and none are 
plaintext.


The problem is when I do this, DNS in other downstream VMs all fail. 
The Qubes networking docs [2] explain how DNS works in Qubes, but I'm 
confused about how to make this set up work. Any ideas? Thanks!


[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/



In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server.
You'll also need to open the udp port to inbound traffic.


If you do that, you'll lose any qubes firewall-based control on DNS 
traffic though. I.e. all of your downstream VMs will have DNS access.


Essentially you'll have to implement your own local version of the qubes 
firewall to achieve qubes-firewall support. I happened to have done that 
some time ago, but the code quality is not good enough to share it 
(sorry). nft usage in 4.0 further complicates it from my point of view. 
You could try to move the forward chain rules to the input chain on 
every firewall change...


Maybe qubes will support it one day; here's the feature request: 
https://github.com/QubesOS/qubes-issues/issues/3051
I'm not sure why it got tagged as doc though - maybe I didn't see the 
obvious solution.




If this is about changing the iptables rules in a proxyVM, then you're 
allowed to do so with qubes-firewall-user-script and the new 
qubes-firewall.d in /rw/config. Just be mindful of what the default 
rules are and Insert/Append as needed.


For example, if you don't want DNS requests to be routed elsewhere you 
can flush the PR-QBS chain in the nat table and maybe add another dnat 
rule there redirecting to localhost (this would catch all DNS requests, 
not just the ones sent to the Qubes internal DNS addresses). Then you 
can add an INPUT rule for port 53.


Maybe I'm missing something but this doesn't look hard. As another 
possible avenue if the above fails, you could look for a guide to 
setting up 'stubby' on a local router; this has the best chance of 
working as proxyVMs are much like routers.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/599cfc5e-d7e8-b2c0-88f0-a1ace3064cff%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Yuraeitha]

@David

On Thursday, March 8, 2018 at 7:18:04 PM UTC+1, David Hobach wrote:
> On 03/07/2018 06:40 PM, Unman wrote:
> > On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> >> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> >> about this [1]).
> >>
> >> I've got this successfully working in sys-net by running a local DNS 
> >> server on udp 53 that forwards DNS requests to a remote DNS server over 
> >> TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. 
> >> I've confirmed that this works great in sys-net -- all of my DNS requests 
> >> are encrypted to my remote DNS server, and none are plaintext.
> >>
> >> The problem is when I do this, DNS in other downstream VMs all fail. The 
> >> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> >> about how to make this set up work. Any ideas? Thanks!
> >>
> >> [1] https://dnsprivacy.org/wiki/
> >> [2] https://www.qubes-os.org/doc/networking/
> >>
> > 
> > In sys-net you have PR-QBS chain in nat table that redirects DNS
> > requests to the network DNS server.
> > 
> > You'll need to remove that chain and replace it with one directing DNS
> > traffic to the local server.
> > You'll also need to open the udp port to inbound traffic.
> 
> If you do that, you'll lose any qubes firewall-based control on DNS 
> traffic though. I.e. all of your downstream VMs will have DNS access.
> 
> Essentially you'll have to implement your own local version of the qubes 
> firewall to achieve qubes-firewall support. I happened to have done that 
> some time ago, but the code quality is not good enough to share it 
> (sorry). nft usage in 4.0 further complicates it from my point of view. 
> You could try to move the forward chain rules to the input chain on 
> every firewall change...
> 
> Maybe qubes will support it one day; here's the feature request: 
> https://github.com/QubesOS/qubes-issues/issues/3051
> I'm not sure why it got tagged as doc though - maybe I didn't see the 
> obvious solution.

We're currently trying to start a Qubes Community doc guide collection at the 
moment, which is thought to be entirely run by volunteers on day-to-day in 
order to help save the Qubes staff time. Nothing official yet though, but here 
one of the ideas being worked on is so you can open up your script to allow 
others to help you finish it and review it. Basically, if this comes to 
fruition, then it allows you to publish unfinished scripts, either to work with 
others and finish it together, or let others takeover if you don't want to 
continue it. Kinda something like that, of course credits should be put like 
always. If this comes to fruition, maybe you can start up a collaboration to 
have people with the right background review it and quality check it?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c20a76d2-dcb5-4e5b-8fbe-7f83510e6e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[David Hobach]

On 03/07/2018 06:40 PM, Unman wrote:

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:

I'm trying to make all DNS requests in Qubes go over TLS (more information 
about this [1]).

I've got this successfully working in sys-net by running a local DNS server on 
udp 53 that forwards DNS requests to a remote DNS server over TLS, and then 
setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed 
that this works great in sys-net -- all of my DNS requests are encrypted to my 
remote DNS server, and none are plaintext.

The problem is when I do this, DNS in other downstream VMs all fail. The Qubes 
networking docs [2] explain how DNS works in Qubes, but I'm confused about how 
to make this set up work. Any ideas? Thanks!

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/



In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server.
You'll also need to open the udp port to inbound traffic.


If you do that, you'll lose any qubes firewall-based control on DNS 
traffic though. I.e. all of your downstream VMs will have DNS access.


Essentially you'll have to implement your own local version of the qubes 
firewall to achieve qubes-firewall support. I happened to have done that 
some time ago, but the code quality is not good enough to share it 
(sorry). nft usage in 4.0 further complicates it from my point of view. 
You could try to move the forward chain rules to the input chain on 
every firewall change...


Maybe qubes will support it one day; here's the feature request: 
https://github.com/QubesOS/qubes-issues/issues/3051
I'm not sure why it got tagged as doc though - maybe I didn't see the 
obvious solution.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e60f357b-99ed-fa8d-8909-978200662b95%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] DNS propagation in Qubes

[Unman]

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> about this [1]).
> 
> I've got this successfully working in sys-net by running a local DNS server 
> on udp 53 that forwards DNS requests to a remote DNS server over TLS, and 
> then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've 
> confirmed that this works great in sys-net -- all of my DNS requests are 
> encrypted to my remote DNS server, and none are plaintext.
> 
> The problem is when I do this, DNS in other downstream VMs all fail. The 
> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> about how to make this set up work. Any ideas? Thanks!
> 
> [1] https://dnsprivacy.org/wiki/
> [2] https://www.qubes-os.org/doc/networking/
> 

In sys-net you have PR-QBS chain in nat table that redirects DNS
requests to the network DNS server.

You'll need to remove that chain and replace it with one directing DNS
traffic to the local server. 
You'll also need to open the udp port to inbound traffic.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180307174022.u5dknqjh3oimwfq3%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Micah Lee]

Qubes 4.0.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/X1juIg1dY5HqEdgRRiliD8belJfZZE8Zt-UAwN3VNsQETPt6oVLAVSRCgd8H0Zq_LvFJz6fWTeYPMKPGjolws8qqCHF8RsbhrtuNz1FpOVc%3D%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS propagation in Qubes

[Unman]

On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> about this [1]).
> 
> I've got this successfully working in sys-net by running a local DNS server 
> on udp 53 that forwards DNS requests to a remote DNS server over TLS, and 
> then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've 
> confirmed that this works great in sys-net -- all of my DNS requests are 
> encrypted to my remote DNS server, and none are plaintext.
> 
> The problem is when I do this, DNS in other downstream VMs all fail. The 
> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> about how to make this set up work. Any ideas? Thanks!
> 
> [1] https://dnsprivacy.org/wiki/
> [2] https://www.qubes-os.org/doc/networking/
> 

Which Qubes version are you using Micah?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2018030717.hawe2u54neblst5q%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DNS propagation in Qubes

[Micah Lee]

I'm trying to make all DNS requests in Qubes go over TLS (more information 
about this [1]).

I've got this successfully working in sys-net by running a local DNS server on 
udp 53 that forwards DNS requests to a remote DNS server over TLS, and then 
setting my only nameserver in /etc/resolv.conf to 127.0.0.1. I've confirmed 
that this works great in sys-net -- all of my DNS requests are encrypted to my 
remote DNS server, and none are plaintext.

The problem is when I do this, DNS in other downstream VMs all fail. The Qubes 
networking docs [2] explain how DNS works in Qubes, but I'm confused about how 
to make this set up work. Any ideas? Thanks!

[1] https://dnsprivacy.org/wiki/
[2] https://www.qubes-os.org/doc/networking/

​​


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9XVz-7viQEqd-6MPx8NvR4Fnk502VgBDJUYogFE056xaFr-k76ApY7WmEbi3oH6yQZQ7MEHbuqYbwCZInJ8LE9lysw_e3w8Dw93FrISL2hU%3D%40micahflee.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dns in qubes

['Tom Zander' via qubes-users]

On Friday, 5 January 2018 15:37:37 GMT Unman wrote:
> Look at the nat table in the upstream netvm.
> You'll see that sys-net NATs these requests to the NS used by sys-net.

Ah, that hint was enough, I didn't expect NAT, thanks!

Got it working now.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1933751.YPqAdZ1Hvv%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] dns in qubes

[Unman]

On Fri, Jan 05, 2018 at 03:17:38PM +, 'Tom Zander' via qubes-users wrote:
> I'm trying to figure out how this works, and I am stuck.
> 
> In every qube (except sys-net) there is  a resolv.conf that points to two 
> name servers.
> 10.139.1.1 and .2
> 
> This raises two questions;
> 
> * how does sys-net handle these requests on this odd address. No 'ip ad' 
> network seems to listen on this address.
> 
> * how can I change this in indidivual qubes in the correct matter.
> I have some qubes routing through sys-vpn and I adjusted the vpn VM to find 
> the DNS, but users of the vpn can't find any DNS service now.
> 
> Any help appreciated.
> 

Hi Tom,

You don't say which Qubes version you're using, or how the sys-vpn is
configured. 
Look at the nat table in the upstream netvm.
You'll see that sys-net NATs these requests to the NS used by sys-net.

You should be able to change name servers in a qube using bind-dirs on
/etc/resolv.conf. Or, (somewhat better since it allows you to switch
qubes in and out of vpn), just change the NAT rules on sys-vpn to
capture DNS traffic and send it down the tunnel.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20180105153737.iwf2gmhad2m36f2j%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] dns in qubes

['Tom Zander' via qubes-users]

I'm trying to figure out how this works, and I am stuck.

In every qube (except sys-net) there is  a resolv.conf that points to two 
name servers.
10.139.1.1 and .2

This raises two questions;

* how does sys-net handle these requests on this odd address. No 'ip ad' 
network seems to listen on this address.

* how can I change this in indidivual qubes in the correct matter.
I have some qubes routing through sys-vpn and I adjusted the vpn VM to find 
the DNS, but users of the vpn can't find any DNS service now.

Any help appreciated.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/65877894.cAG3c6iG4f%40mail.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS over TLS

[Unman]

On Mon, Nov 27, 2017 at 09:27:16PM +0100, CF wrote:
> Dear Users,
> 
> A few (simple) questions as I was reading about DNS servers:
> 
> 1 - Any feedback on using your own DNS server directly on your Qubes
> machine (using unbound for instance)? Is it straightforward to have your
> DNS cache persistent across reboots?
> 
> 2 - Any feedback on the DNS over TLS provided by quad 9?
> https://www.quad9.net/
> https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security/
> 
> 3 - Are you aware of any other similar public server available? (IPV4 /
> IPV6 + DNS over TLS)
> 
> 4 - Last but not least, it is not very clear how to set up Qubes to use
> a given DNS server. Should we modify each VM? Or only the net VM? Or the
> firewall VM?
> 
> Thanks

You can, if you wish, set up a qube to provide DNS - you can either set
this on one of the proxyVMs or use a dedicated qube (in which case you
will need to manipulate iptables to allow inter-qube traffic). 
Look at https://www.qubes-os.org/doc/firewall to help with this.

To make the cache persistent, either store it in /usr/local or use the
bind-dirs facility:
https://www.qubes-os.org/doc/bind-dirs/

To understand the standard Qubes DNS in 3.2, note that each qube has in
/etc/resolv.conf nameserver entries for the network segment relating to
the network relating to the  proxy to which it is connected.
If you examine the iptables rules in the proxy you will see that the NAT
table contains a chain which effectively redirects DNS traffic upstream,
using the same .1 and .254 addresses.
At sys-net, the iptables rules redirect to the external DNS server(s)

If you want to use a particular server, change the iptables DNAT rules in
sys-net - you can do this from /rw/config/rc.local - again look at the
docs of the firewall.
OR if you want just SOME qubes to use a different DNS server, make
changes to the PR-QBS chain in the proxy to redirect DNS traffic to the chosen
server.
You can see that ALL of the methods proposed in your final question will
work: which you choose will depend on how many qubes you want to use
the given DNS server.

unman

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20171129010058.lbuy7ffa6efgelow%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DNS over TLS

[CF]

Dear Users,

A few (simple) questions as I was reading about DNS servers:

1 - Any feedback on using your own DNS server directly on your Qubes
machine (using unbound for instance)? Is it straightforward to have your
DNS cache persistent across reboots?

2 - Any feedback on the DNS over TLS provided by quad 9?
https://www.quad9.net/
https://labs.ripe.net/Members/stephane_bortzmeyer/quad9-a-public-dns-resolver-with-security/

3 - Are you aware of any other similar public server available? (IPV4 /
IPV6 + DNS over TLS)

4 - Last but not least, it is not very clear how to set up Qubes to use
a given DNS server. Should we modify each VM? Or only the net VM? Or the
firewall VM?

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ovhsev%24uh3%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] DNS issues after Debian template update

[Unman]

On Tue, Apr 25, 2017 at 08:30:17AM -0700, adonis28...@gmail.com wrote:
> On Monday, April 24, 2017 at 4:06:11 PM UTC-4, Unman wrote:
> > On Mon, Apr 24, 2017 at 11:33:58AM -0700 wrote:
> > > On Sunday, April 23, 2017 at 6:20:33 PM UTC-4, Chris Laprise wrote:
> > > > On 04/23/2017 05:50 PM,  wrote:
> > > > > Would you mind to share these files with me from your Debian 8 
> > > > > template to see if I can fin what the problem is?!
> > > > >
> > > > > Unman, no I haven't enabled anything. I got a Debian 8 template, 
> > > > > almost clean, and then a bunch of AppVMs using it as a template.
> > > > >
> > > > > Cheers.
> > > > >
> > > > 
> > > > It turns out those two scripts I mentioned were not changed in the 
> > > > latest update (although qubes-setup-dnat-to-ns was changed slightly in 
> > > > a 
> > > > way that should have no bearing here).
> > > > 
> > > > It appears that qubes-ns is not normally created in an appVM, anyway. 
> > > > Running 'setup-ip' and 'qubes-setup-dnat-to-ns' from a shell gives me 
> > > > the same errors you posted.
> > > > 
> > > > Perhaps the cause is simpler: You may have inadvertently set the netVM 
> > > > for that appVM to 'none' or enabled blocking in the firewall settings.
> > > > 
> > > > -- 
> > > > 
> > > > Chris Laprise, tas...@openmailbox.org
> > > > https://twitter.com/ttaskett
> > > > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > > 
> > > Hi,
> > > 
> > > The thing is that when I set up the DNS servers manually by modifying the 
> > > /etc/hosts file to let's say 8.8.8.8, everything works properly! I think 
> > > the problem is that for some reason the iptables rules are not being 
> > > created, so the appVM can't connect.
> > > 
> > > Cheers.
> > > 
> > 
> > It's still not entirely clear to me what's going on.
> > I assume that you are changing /etc/resolv.conf rather than hosts - if
> > the latter , what entry are you putting in there?
> > And you are doing this in the appVM.
> > 
> > But the iptables rules arent being created in the netvm to which the
> > appVM is connected.
> > Are you able to use DNS from the netVM? What is in resolv.conf there and
> > what is in iptables upstream?
> 
> Hi,
> 
> Sorry I replied from my phone in a rush, you are right what I'm modifying is 
> the resolv.conf file. When I add there let's say 8.8.8.8, it resolves, so the 
> problem seems to be that the template or appVMs cannot connect to sys-fw to 
> resolve DNS names, and this seems to be due to the lack of those iptables 
> rules that are not created for some reason.
> 
> The issues applies to both, the template VM and the app VM
> 

At this stage I would start again with a clean template, make sure it's
working and then run the update again. (You can always reinstall the
original template from your install medium, if you didnt clone it, which
I hope you did.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170425183123.GB30040%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS issues after Debian template update

[adonis28850]

On Monday, April 24, 2017 at 4:06:11 PM UTC-4, Unman wrote:
> On Mon, Apr 24, 2017 at 11:33:58AM -0700 wrote:
> > On Sunday, April 23, 2017 at 6:20:33 PM UTC-4, Chris Laprise wrote:
> > > On 04/23/2017 05:50 PM,  wrote:
> > > > Would you mind to share these files with me from your Debian 8 template 
> > > > to see if I can fin what the problem is?!
> > > >
> > > > Unman, no I haven't enabled anything. I got a Debian 8 template, almost 
> > > > clean, and then a bunch of AppVMs using it as a template.
> > > >
> > > > Cheers.
> > > >
> > > 
> > > It turns out those two scripts I mentioned were not changed in the 
> > > latest update (although qubes-setup-dnat-to-ns was changed slightly in a 
> > > way that should have no bearing here).
> > > 
> > > It appears that qubes-ns is not normally created in an appVM, anyway. 
> > > Running 'setup-ip' and 'qubes-setup-dnat-to-ns' from a shell gives me 
> > > the same errors you posted.
> > > 
> > > Perhaps the cause is simpler: You may have inadvertently set the netVM 
> > > for that appVM to 'none' or enabled blocking in the firewall settings.
> > > 
> > > -- 
> > > 
> > > Chris Laprise, tas...@openmailbox.org
> > > https://twitter.com/ttaskett
> > > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > 
> > Hi,
> > 
> > The thing is that when I set up the DNS servers manually by modifying the 
> > /etc/hosts file to let's say 8.8.8.8, everything works properly! I think 
> > the problem is that for some reason the iptables rules are not being 
> > created, so the appVM can't connect.
> > 
> > Cheers.
> > 
> 
> It's still not entirely clear to me what's going on.
> I assume that you are changing /etc/resolv.conf rather than hosts - if
> the latter , what entry are you putting in there?
> And you are doing this in the appVM.
> 
> But the iptables rules arent being created in the netvm to which the
> appVM is connected.
> Are you able to use DNS from the netVM? What is in resolv.conf there and
> what is in iptables upstream?

Hi,

Sorry I replied from my phone in a rush, you are right what I'm modifying is 
the resolv.conf file. When I add there let's say 8.8.8.8, it resolves, so the 
problem seems to be that the template or appVMs cannot connect to sys-fw to 
resolve DNS names, and this seems to be due to the lack of those iptables rules 
that are not created for some reason.

The issues applies to both, the template VM and the app VM

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/07980fc5-01f3-4e7b-a5fa-6cf18b40ed77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS issues after Debian template update

[Chris Laprise]

On 04/23/2017 05:50 PM, adonis28...@gmail.com wrote:

Would you mind to share these files with me from your Debian 8 template to see 
if I can fin what the problem is?!

Unman, no I haven't enabled anything. I got a Debian 8 template, almost clean, 
and then a bunch of AppVMs using it as a template.

Cheers.



It turns out those two scripts I mentioned were not changed in the 
latest update (although qubes-setup-dnat-to-ns was changed slightly in a 
way that should have no bearing here).


It appears that qubes-ns is not normally created in an appVM, anyway. 
Running 'setup-ip' and 'qubes-setup-dnat-to-ns' from a shell gives me 
the same errors you posted.


Perhaps the cause is simpler: You may have inadvertently set the netVM 
for that appVM to 'none' or enabled blocking in the firewall settings.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/b441c13f-12b6-c17e-99c9-760b910ea31d%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS issues after Debian template update

[Unman]

On Sun, Apr 23, 2017 at 02:40:12PM -0400, Chris Laprise wrote:
> On 04/23/2017 01:33 PM, adonis28...@gmail.com wrote:
> >Hi guys,
> >
> >I've updated my Debian 8 template, and for some reason it's messed up the 
> >DNS-related iptables rules.
> 
> This still works on my Debian 8 proxyVM. Haven't tried appVM yet as I
> normally use Debian 9.
> 
> >
> >I've narrowed the problem down to this script:
> >
> >/usr/lib/qubes/qubes-setup-dnat-to-ns
> >---
> 
> >When I run it as it is, I get the following error:
> >
> >user@debian-8:~$ sudo bash /usr/lib/qubes/qubes-setup-dnat-to-ns
> >
> >/usr/lib/qubes/qubes-setup-dnat-to-ns: line 17: /var/run/qubes/qubes-ns: No 
> >such file or directory
> 
> Two scripts that create /var/run/qubes/qubes-ns are:
>   setup-ip
>   network-proxy-setup.sh
> 
> If you have a snapshot of your Debian 8 template, you could diff those files
> to see if they changed (acquired a bug).
> 

Like Chris, I dont see this problem with my Debian qubes - 8 or 9
based.
/var/run/qubes/qubes-ns isn't a script, as OP suggested -it's a file
containing the NS1 and NS2 variables. In a qube it's written from
setup-ip

You haven't somehow enabled networkManager in that appVM have you?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170423214029.GB19193%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS issues after Debian template update

[Chris Laprise]

On 04/23/2017 01:33 PM, adonis28...@gmail.com wrote:

Hi guys,

I've updated my Debian 8 template, and for some reason it's messed up the 
DNS-related iptables rules.


This still works on my Debian 8 proxyVM. Haven't tried appVM yet as I 
normally use Debian 9.




I've narrowed the problem down to this script:

/usr/lib/qubes/qubes-setup-dnat-to-ns
---



When I run it as it is, I get the following error:

user@debian-8:~$ sudo bash /usr/lib/qubes/qubes-setup-dnat-to-ns

/usr/lib/qubes/qubes-setup-dnat-to-ns: line 17: /var/run/qubes/qubes-ns: No 
such file or directory


Two scripts that create /var/run/qubes/qubes-ns are:
  setup-ip
  network-proxy-setup.sh

If you have a snapshot of your Debian 8 template, you could diff those 
files to see if they changed (acquired a bug).


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/75b48b8f-42ba-2c96-7d66-66ddd59184af%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DNS issues after Debian template update

[adonis28850]

Hi guys,

I've updated my Debian 8 template, and for some reason it's messed up the 
DNS-related iptables rules.

I've narrowed the problem down to this script:

/usr/lib/qubes/qubes-setup-dnat-to-ns
---
#!/bin/sh
addrule()
{
if [ $FIRSTONE = yes ] ; then
FIRSTONE=no
RULE1="-A PR-QBS -d $NS1 -p udp --dport 53 -j DNAT --to $1
-A PR-QBS -d $NS1 -p tcp --dport 53 -j DNAT --to $1"
RULE2="-A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $1
-A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $1"
else
RULE2="-A PR-QBS -d $NS2 -p udp --dport 53 -j DNAT --to $1
-A PR-QBS -d $NS2 -p tcp --dport 53 -j DNAT --to $1"
NS=$NS2
fi
}
export PATH=$PATH:/sbin:/bin
. /var/run/qubes/qubes-ns
if [ "X"$NS1 = "X" ] ; then exit ; fi
iptables -t nat -F PR-QBS
FIRSTONE=yes
grep ^nameserver /etc/resolv.conf | grep -v ":.*:" | head -2 |
(
while read x y z ; do
addrule "$y"
done
(echo "*nat"; echo "$RULE1"; echo "$RULE2"; echo COMMIT) | 
iptables-restore -n
)
---

When I run it as it is, I get the following error:

user@debian-8:~$ sudo bash /usr/lib/qubes/qubes-setup-dnat-to-ns

/usr/lib/qubes/qubes-setup-dnat-to-ns: line 17: /var/run/qubes/qubes-ns: No 
such file or directory

I've commented the line that runs that script (which is not present in the 
system), and it doesn't do anything as this line exits the script ($NS1 is 
empty):

if [ "X"$NS1 = "X" ] ; then exit ; fi

So I've also commented out that line so the rules can get added, but, I get an 
error when the script adds the rules:

Bad argument `udp'
Error occurred at line: 2
Try `iptables-restore -h' or 'iptables-restore --help' for more information.

It complains about '[...] -p udp [...]'

I'm not sure why I'm running into all these errors, as everything worked just 
fine before! Any ideas or suggestions are appreciated

Cheers.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4b012e44-0936-4b39-b115-e11dcbdf441d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

['Antoine Sirinelli' via qubes-users]

On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> If you had two servers on your network, or your DHCP server gave out two
> addresses both would be used, I think.
> If you want to lose one, you could overwrite it from rc.local or use
> bind-dirs on resolv.conf: both methods are covered in the docs.  
> Look at www.qubes-os.org/doc/config-files
> 

On Sat, Mar 11, 2017 at 11:02:29PM +, Unman wrote:
> No the issue is that the 1 DNS server you use doesn't resolve some
> addresses. I assume this is how you like it so I'm not clear really on
> what the problem is.
> 
> I have suggested to you how you can easily remove the second listing if
> that bothers you. (You've cut that from my reply).
> Alternatively you could customise sys-net to provide
> DNS services from some other servers, or add a second redirect rule to
> the one server you have. I don't see why that would be an advantage -
> surely your applications would time out in exactly the same way that
> they do at present?
> And if you added a second server that *doesn't* filter requests, why have
> one that *does* as your primary server?

Thank you for spending time to answer me but I still do not understand
why Qubes configures 2 DNS servers in /etc/resolv.conf in the VMs.

To summarise, I have one DNS server on my network. My DHCP server passes
only this DNS server adresses (Option 6). I may have missed something on
Qubes behaviour but why does Qubes decides to use 2 DNS server?

I understand your workaround to remove the second DNS server in VMs but
I would like to understand why it appears.

On a side note, on this network, I have plenty of different devices
connected with OS and I never had any issue with a second DNS server
appearing in the auto-configuration.

Thank you again for your help,

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170312215619.mzfujwhpvrttkd6a%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] DNS

[Unman]

On Sat, Mar 11, 2017 at 10:05:50PM +0100, 'Antoine' via qubes-users wrote:
> On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> > > > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > > > 
> > > > > = Fedora 23 =
> > > > > [user@work ~]$ grep PRETTY /etc/os-release 
> > > > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > > > [user@work ~]$ cat /etc/resolv.conf 
> > > > > nameserver 10.137.2.1
> > > > > nameserver 10.137.2.254
> > > > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > > > 23.235.33.144
> > > > > 23.235.37.144
> > > > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > > > ;; connection timed out; no servers could be reached
> > > I have understood why I have this problem.
> > > 
> > > On my LAN, the DNS recursive server (unbound) has a blacklist: it
> > > refuses to answer queries for tracking/ad domains. The problem is that
> > > when a program receives a "REFUSED" packet from its DNS query, it tries
> > > to solve the same host on the second DNS server in resolv.conf.
> > > 
> > > I can see the pattern clearly using tcpdump: Query -> fast answer
> > > REFUSED -> Query on the second DNS server -> no answer.
> > > 
> > > On the DNS resolver:
> > > # grep facebook unbound-blacklist.conf 
> > > local-zone: "facebook.com" refuse
> > > 
> > > on any Qubes VM:
> > > $ host facebook.com 10.137.2.1
> > > Using domain server:
> > > Name: 10.137.2.1
> > > Address: 10.137.2.1#53
> > > Aliases: 
> > > 
> > > Host facebook.com not found: 5(REFUSED)
> > > $ host facebook.com 10.137.2.254
> > > [... 10s ...]
> > > ;; connection timed out; no servers could be reached
> > > $ host facebook.com
> > > Host facebook.com not found: 5(REFUSED)
> > > $ ping facebook.com
> > > [... 10s ...]
> > > ping: facebook.com: Temporary failure in name resolution
> > > 
> > > I do not understand why this second DNS server is populated in all Qubes
> > > VM. Is there a simple way to configure only 1 DNS server?
> > > 
> > > Antoine
> > > 
> > 
> > If you had two servers on your network, or your DHCP server gave out two
> > addresses both would be used, I think.
> 
> The issue is that my DHCP server is only giving 1 DNS server. I do not
> understand why Qubes thinks I have 2.
> 
> Antoine
> 

No the issue is that the 1 DNS server you use doesn't resolve some
addresses. I assume this is how you like it so I'm not clear really on
what the problem is.

I have suggested to you how you can easily remove the second listing if
that bothers you. (You've cut that from my reply).
Alternatively you could customise sys-net to provide
DNS services from some other servers, or add a second redirect rule to
the one server you have. I don't see why that would be an advantage -
surely your applications would time out in exactly the same way that
they do at present?
And if you added a second server that *doesn't* filter requests, why have
one that *does* as your primary server?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170311230229.GA25808%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

['Antoine' via qubes-users]

On Thu, Mar 09, 2017 at 12:30:21AM +, Unman wrote:
> > > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > > 
> > > > = Fedora 23 =
> > > > [user@work ~]$ grep PRETTY /etc/os-release 
> > > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > > [user@work ~]$ cat /etc/resolv.conf 
> > > > nameserver 10.137.2.1
> > > > nameserver 10.137.2.254
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > > 23.235.33.144
> > > > 23.235.37.144
> > > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > > ;; connection timed out; no servers could be reached
> > I have understood why I have this problem.
> > 
> > On my LAN, the DNS recursive server (unbound) has a blacklist: it
> > refuses to answer queries for tracking/ad domains. The problem is that
> > when a program receives a "REFUSED" packet from its DNS query, it tries
> > to solve the same host on the second DNS server in resolv.conf.
> > 
> > I can see the pattern clearly using tcpdump: Query -> fast answer
> > REFUSED -> Query on the second DNS server -> no answer.
> > 
> > On the DNS resolver:
> > # grep facebook unbound-blacklist.conf 
> > local-zone: "facebook.com" refuse
> > 
> > on any Qubes VM:
> > $ host facebook.com 10.137.2.1
> > Using domain server:
> > Name: 10.137.2.1
> > Address: 10.137.2.1#53
> > Aliases: 
> > 
> > Host facebook.com not found: 5(REFUSED)
> > $ host facebook.com 10.137.2.254
> > [... 10s ...]
> > ;; connection timed out; no servers could be reached
> > $ host facebook.com
> > Host facebook.com not found: 5(REFUSED)
> > $ ping facebook.com
> > [... 10s ...]
> > ping: facebook.com: Temporary failure in name resolution
> > 
> > I do not understand why this second DNS server is populated in all Qubes
> > VM. Is there a simple way to configure only 1 DNS server?
> > 
> > Antoine
> > 
> 
> If you had two servers on your network, or your DHCP server gave out two
> addresses both would be used, I think.

The issue is that my DHCP server is only giving 1 DNS server. I do not
understand why Qubes thinks I have 2.

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170311210550.uzoxnnr6dnglhteq%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] DNS

[Unman]

On Wed, Mar 08, 2017 at 11:55:17PM +0100, 'Antoine' via qubes-users wrote:
> On Tue, Mar 07, 2017 at 09:08:07PM +, Unman wrote:
> > On Tue, Mar 07, 2017 at 09:56:23PM +0100, 'Antoine' via qubes-users wrote:
> > > On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> > > > >> Filed a bug report:
> > > > >> 
> > > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > > 
> > > = Fedora 23 =
> > > [user@work ~]$ grep PRETTY /etc/os-release 
> > > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > > [user@work ~]$ cat /etc/resolv.conf 
> > > nameserver 10.137.2.1
> > > nameserver 10.137.2.254
> > > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > > 23.235.33.144
> > > 23.235.37.144
> > > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > > ;; connection timed out; no servers could be reached
> > > 
> > > = Debian 8 =
> > > user@cloud:~$ grep PRETTY /etc/os-release 
> > > PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> > > user@cloud:~$ cat /etc/resolv.conf 
> > > nameserver 10.137.2.1
> > > nameserver 10.137.2.254
> > > user@cloud:~$ dig +short gov.uk @10.137.2.1
> > > 23.235.33.144
> > > 23.235.37.144
> > > user@cloud:~$ dig +short gov.uk @10.137.2.254
> > > ;; connection timed out; no servers could be reached
> > > 
> > > = Debian 9 =
> > > user@Email:~$ grep PRETTY /etc/os-release 
> > > PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> > > user@Email:~$ cat /etc/resolv.conf 
> > > nameserver 10.137.2.1
> > > nameserver 10.137.2.254
> > > user@Email:~$ dig +short gov.uk @10.137.2.1
> > > 23.235.33.144
> > > 23.235.37.144
> > > user@Email:~$ dig +short gov.uk @10.137.2.254
> > > ;; connection timed out; no servers could be reached
> > > 
> > > Do you have an advise how to remove 10.137.2.254 from the list of
> > > default name servers?
> > 
> > Probaly more relevant would be for you to discover why the first
> > nameserver isnt reachable or isnt responding.
> > With multiple entries they are queried in the order given, so if the
> > first is working correctly the second entry wont be hit.
> > 
> > Thats the real problem.
> 
> I have understood why I have this problem.
> 
> On my LAN, the DNS recursive server (unbound) has a blacklist: it
> refuses to answer queries for tracking/ad domains. The problem is that
> when a program receives a "REFUSED" packet from its DNS query, it tries
> to solve the same host on the second DNS server in resolv.conf.
> 
> I can see the pattern clearly using tcpdump: Query -> fast answer
> REFUSED -> Query on the second DNS server -> no answer.
> 
> On the DNS resolver:
> # grep facebook unbound-blacklist.conf 
> local-zone: "facebook.com" refuse
> 
> on any Qubes VM:
> $ host facebook.com 10.137.2.1
> Using domain server:
> Name: 10.137.2.1
> Address: 10.137.2.1#53
> Aliases: 
> 
> Host facebook.com not found: 5(REFUSED)
> $ host facebook.com 10.137.2.254
> [... 10s ...]
> ;; connection timed out; no servers could be reached
> $ host facebook.com
> Host facebook.com not found: 5(REFUSED)
> $ ping facebook.com
> [... 10s ...]
> ping: facebook.com: Temporary failure in name resolution
> 
> I do not understand why this second DNS server is populated in all Qubes
> VM. Is there a simple way to configure only 1 DNS server?
> 
> Antoine
> 

If you had two servers on your network, or your DHCP server gave out two
addresses both would be used, I think.
If you want to lose one, you could overwrite it from rc.local or use
bind-dirs on resolv.conf: both methods are covered in the docs.  
Look at www.qubes-os.org/doc/config-files


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170309003021.GB5764%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

['Antoine' via qubes-users]

On Tue, Mar 07, 2017 at 09:08:07PM +, Unman wrote:
> On Tue, Mar 07, 2017 at 09:56:23PM +0100, 'Antoine' via qubes-users wrote:
> > On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> > > >> Filed a bug report:
> > > >> 
> > > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > I have the same problem with Fedora 23, Debian 8 and Debian 9:
> > 
> > = Fedora 23 =
> > [user@work ~]$ grep PRETTY /etc/os-release 
> > PRETTY_NAME="Fedora 23 (Workstation Edition)"
> > [user@work ~]$ cat /etc/resolv.conf 
> > nameserver 10.137.2.1
> > nameserver 10.137.2.254
> > [user@work ~]$ dig +short gov.uk @10.137.2.1
> > 23.235.33.144
> > 23.235.37.144
> > [user@work ~]$ dig +short gov.uk @10.137.2.254
> > ;; connection timed out; no servers could be reached
> > 
> > = Debian 8 =
> > user@cloud:~$ grep PRETTY /etc/os-release 
> > PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> > user@cloud:~$ cat /etc/resolv.conf 
> > nameserver 10.137.2.1
> > nameserver 10.137.2.254
> > user@cloud:~$ dig +short gov.uk @10.137.2.1
> > 23.235.33.144
> > 23.235.37.144
> > user@cloud:~$ dig +short gov.uk @10.137.2.254
> > ;; connection timed out; no servers could be reached
> > 
> > = Debian 9 =
> > user@Email:~$ grep PRETTY /etc/os-release 
> > PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> > user@Email:~$ cat /etc/resolv.conf 
> > nameserver 10.137.2.1
> > nameserver 10.137.2.254
> > user@Email:~$ dig +short gov.uk @10.137.2.1
> > 23.235.33.144
> > 23.235.37.144
> > user@Email:~$ dig +short gov.uk @10.137.2.254
> > ;; connection timed out; no servers could be reached
> > 
> > Do you have an advise how to remove 10.137.2.254 from the list of
> > default name servers?
> 
> Probaly more relevant would be for you to discover why the first
> nameserver isnt reachable or isnt responding.
> With multiple entries they are queried in the order given, so if the
> first is working correctly the second entry wont be hit.
> 
> Thats the real problem.

I have understood why I have this problem.

On my LAN, the DNS recursive server (unbound) has a blacklist: it
refuses to answer queries for tracking/ad domains. The problem is that
when a program receives a "REFUSED" packet from its DNS query, it tries
to solve the same host on the second DNS server in resolv.conf.

I can see the pattern clearly using tcpdump: Query -> fast answer
REFUSED -> Query on the second DNS server -> no answer.

On the DNS resolver:
# grep facebook unbound-blacklist.conf 
local-zone: "facebook.com" refuse

on any Qubes VM:
$ host facebook.com 10.137.2.1
Using domain server:
Name: 10.137.2.1
Address: 10.137.2.1#53
Aliases: 

Host facebook.com not found: 5(REFUSED)
$ host facebook.com 10.137.2.254
[... 10s ...]
;; connection timed out; no servers could be reached
$ host facebook.com
Host facebook.com not found: 5(REFUSED)
$ ping facebook.com
[... 10s ...]
ping: facebook.com: Temporary failure in name resolution

I do not understand why this second DNS server is populated in all Qubes
VM. Is there a simple way to configure only 1 DNS server?

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170308225516.3coxi2iautyfbfuj%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] DNS

[Unman]

On Tue, Mar 07, 2017 at 09:56:23PM +0100, 'Antoine' via qubes-users wrote:
> On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> > >> Filed a bug report:
> > >> 
> > >> https://github.com/QubesOS/qubes-issues/issues/2674
> > >> 
> > >> Antoine, you didn't mention which version of Qubes or Debian 
> > >> you're using, so I assumed Qubes 3.2 and the Debian 8 
> > >> TemplateVM.
> > > 
> > > In fact, I am using a Debian 9 TemplateVM.
> > > 
> > > Antoine
> > > 
> > 
> > Thanks. I've updated the bug report.
> > 
> > However, please note that Debian 8 has gone more extensive testing
> > than Debian 9 as a TemplateVM. You may wish to try Debian 8 to see
> > whether this resolves your problem.
> 
> I have the same problem with Fedora 23, Debian 8 and Debian 9:
> 
> = Fedora 23 =
> [user@work ~]$ grep PRETTY /etc/os-release 
> PRETTY_NAME="Fedora 23 (Workstation Edition)"
> [user@work ~]$ cat /etc/resolv.conf 
> nameserver 10.137.2.1
> nameserver 10.137.2.254
> [user@work ~]$ dig +short gov.uk @10.137.2.1
> 23.235.33.144
> 23.235.37.144
> [user@work ~]$ dig +short gov.uk @10.137.2.254
> ;; connection timed out; no servers could be reached
> 
> = Debian 8 =
> user@cloud:~$ grep PRETTY /etc/os-release 
> PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
> user@cloud:~$ cat /etc/resolv.conf 
> nameserver 10.137.2.1
> nameserver 10.137.2.254
> user@cloud:~$ dig +short gov.uk @10.137.2.1
> 23.235.33.144
> 23.235.37.144
> user@cloud:~$ dig +short gov.uk @10.137.2.254
> ;; connection timed out; no servers could be reached
> 
> = Debian 9 =
> user@Email:~$ grep PRETTY /etc/os-release 
> PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
> user@Email:~$ cat /etc/resolv.conf 
> nameserver 10.137.2.1
> nameserver 10.137.2.254
> user@Email:~$ dig +short gov.uk @10.137.2.1
> 23.235.33.144
> 23.235.37.144
> user@Email:~$ dig +short gov.uk @10.137.2.254
> ;; connection timed out; no servers could be reached
> 
> Do you have an advise how to remove 10.137.2.254 from the list of
> default name servers?

Probaly more relevant would be for you to discover why the first
nameserver isnt reachable or isnt responding.
With multiple entries they are queried in the order given, so if the
first is working correctly the second entry wont be hit.

Thats the real problem.
.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170307210807.GA30418%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

['Antoine' via qubes-users]

On Mon, Mar 06, 2017 at 04:31:31PM -0800, Andrew David Wong wrote:
> >> Filed a bug report:
> >> 
> >> https://github.com/QubesOS/qubes-issues/issues/2674
> >> 
> >> Antoine, you didn't mention which version of Qubes or Debian 
> >> you're using, so I assumed Qubes 3.2 and the Debian 8 
> >> TemplateVM.
> > 
> > In fact, I am using a Debian 9 TemplateVM.
> > 
> > Antoine
> > 
> 
> Thanks. I've updated the bug report.
> 
> However, please note that Debian 8 has gone more extensive testing
> than Debian 9 as a TemplateVM. You may wish to try Debian 8 to see
> whether this resolves your problem.

I have the same problem with Fedora 23, Debian 8 and Debian 9:

= Fedora 23 =
[user@work ~]$ grep PRETTY /etc/os-release 
PRETTY_NAME="Fedora 23 (Workstation Edition)"
[user@work ~]$ cat /etc/resolv.conf 
nameserver 10.137.2.1
nameserver 10.137.2.254
[user@work ~]$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
[user@work ~]$ dig +short gov.uk @10.137.2.254
;; connection timed out; no servers could be reached

= Debian 8 =
user@cloud:~$ grep PRETTY /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
user@cloud:~$ cat /etc/resolv.conf 
nameserver 10.137.2.1
nameserver 10.137.2.254
user@cloud:~$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
user@cloud:~$ dig +short gov.uk @10.137.2.254
;; connection timed out; no servers could be reached

= Debian 9 =
user@Email:~$ grep PRETTY /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
user@Email:~$ cat /etc/resolv.conf 
nameserver 10.137.2.1
nameserver 10.137.2.254
user@Email:~$ dig +short gov.uk @10.137.2.1
23.235.33.144
23.235.37.144
user@Email:~$ dig +short gov.uk @10.137.2.254
;; connection timed out; no servers could be reached

Do you have an advise how to remove 10.137.2.254 from the list of
default name servers?

Many thanks,

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170307205623.bz6ibs44qcme6s2x%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] DNS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-06 14:22, Antoine wrote:
> On Sun, Mar 05, 2017 at 05:35:03PM -0800, Andrew David Wong wrote:
>> Filed a bug report:
>> 
>> https://github.com/QubesOS/qubes-issues/issues/2674
>> 
>> Antoine, you didn't mention which version of Qubes or Debian 
>> you're using, so I assumed Qubes 3.2 and the Debian 8 
>> TemplateVM.
> 
> In fact, I am using a Debian 9 TemplateVM.
> 
> Antoine
> 

Thanks. I've updated the bug report.

However, please note that Debian 8 has gone more extensive testing
than Debian 9 as a TemplateVM. You may wish to try Debian 8 to see
whether this resolves your problem.

https://www.qubes-os.org/doc/supported-versions/#templatevms

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYvf9hAAoJENtN07w5UDAwd4wP/iPxL+W+Skap6XzBRmNdPR2i
PuBbS6iLd46YiUaRR06jGG2Iha6g/jNkDPLeWBcWWFXxJnFiE3iJSTrElTZgPLEC
TZpdOhDftejZ8/7cLmXnLI8aec24cubB6bZBZUymUs9BgqQQgJiLJfwHg0TCOsRJ
skysZttUBYh0WZDlyHRecRNl7D6SikfD12OKGuxEy7I3kOZfuC37cai/mF5KHfRf
ypPkj7pkvr7FYdUd65SP8KNc8U5IsoBeyDXfjJ4UYbo2/+B9lUPicULB2oBuBNPQ
cYukQbHJTC03thHWr3OCkD3jfQlXDaJO9JsVMfrzaYuVONRPQhHIB0tKKhvI9kO/
05h7dMLdN5rjiX3bl9nHZMuJ3CrXMYjT9P1qL85EP2/Wamb4a/16XjX2bLftj6iK
peKG0zgGwnOaFjoBLFyhTcL6YMSyWzcxAkwLWhr0o8lEayztBFk/lQjP46DeLcFB
ZGS24S85K5s026i73bDQ+YAxhY/dgCPVt/APDyfXZ3HW0jQRN0WvFPdk6B0FGgWR
BBZaZDE+rXlpwJTyoZbflymjHk8I5JvC25cMXeZz2YBodmS8SCV0LKj0DwO5xSLc
9uhwZ6sLLDdopFXD7faFEZwzbn3WyAqGUF/6zvcec6LMW87IW1a3/XJENjaM2YQG
Ac+kZnIOp8zhShaHCwcK
=oAkz
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/66b0a2ee-677a-1308-885b-d22cfc013fbf%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

['Antoine' via qubes-users]

On Sun, Mar 05, 2017 at 05:35:03PM -0800, Andrew David Wong wrote:
> Filed a bug report:
> 
> https://github.com/QubesOS/qubes-issues/issues/2674
> 
> Antoine, you didn't mention which version of Qubes or Debian you're
> using, so I assumed Qubes 3.2 and the Debian 8 TemplateVM.

In fact, I am using a Debian 9 TemplateVM.

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2017030622.vzipj7ztpgcd6ezi%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: [qubes-users] DNS

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2017-03-05 13:07, Unman wrote:
> On Sun, Mar 05, 2017 at 09:25:07PM +0100, 'Antoine' via qubes-users wrote:
>> Hi,
>>
>> I have recently installed Qubes OS and I am experiencing some slow time
>> resolution in my debian VM. I have checked the /etc/resolv.conf file and
>> it contains the following lines:
>>
>> nameserver 10.137.2.1
>> nameserver 10.137.2.254
>>
>> Playing with dig I can realise that the first IP is working well while
>> all DNS queries sent to the second one finish in timeout:
>>
>> $ dig +short qubes-os.org @10.137.2.1
>> 104.25.152.101
>> 104.25.151.101
>> $ dig +short qubes-os.org @10.137.2.254
>> ;; connection timed out; no servers could be reached
>>
>> In sys-firewall, everything seems OK:
>>
>> $ iptables -S -t nat
>> [...]
>> -A PR-QBS -d 10.137.2.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
>> 10.137.1.1
>> -A PR-QBS -d 10.137.2.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
>> 10.137.1.1
>> -A PR-QBS -d 10.137.2.254/32 -p udp -m udp --dport 53 -j DNAT 
>> --to-destination 10.137.1.254
>> -A PR-QBS -d 10.137.2.254/32 -p tcp -m tcp --dport 53 -j DNAT 
>> --to-destination 10.137.1.254
>>
>> But I have the feeling something is missing in sys-net:
>>
>> $ iptables -S -t nat
>> [...]
>> -A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
>> 192.168.1.1
>> -A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
>> 192.168.1.1
>> [...]
>>
>> where 192.168.1.1 is the expected DNS server on my LAN.
>>
>> Do you have an idea why this DNAT rule is missing? (I am not sure to
>> understand why 2 different nameserver are filled in resolv.conf).
>>
>> Many thanks for your help,
>>
>> Antoine
>>
>> -- 
> 
> No idea - report it as a bug
> 

Filed a bug report:

https://github.com/QubesOS/qubes-issues/issues/2674

Antoine, you didn't mention which version of Qubes or Debian you're
using, so I assumed Qubes 3.2 and the Debian 8 TemplateVM.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJYvLzEAAoJENtN07w5UDAw+rsP/iOfRnkcfKfPONVv5ZjJwIIs
7CONV6Spmp69MK9SrnytzNRu1FXyimXY7/PyDYDkidwF8V/YTIjoxxKVdkCv9nMS
O8psTge4AdJXInQCiFtH8iMb6Qb7RnJ7YJYT+rrIGfKW+ThQolW8/yFnvFExlHor
15zMIifI5jqi+khD+iNY1X81Hv2vjiDxmzD0l6VjODb6Bdu1rQnBF/i73axFDyIZ
eXGjotqW3t7eAm4OBKjZcKWcKnrDrfItqH67CDwEDco837ECYQsjX/DvB7OQcTMY
GkAlNKkXmSMq9GTAyhdMNW4qNUF00vqJeohowlU2WTM0ihDS4rN71TfHnBFi1WRJ
MC3/QCBP4NxJpehz1iYTj4i+TDL1X6JWwcIvsyEPJ7yc3shAPF8WUY/GTwUCozly
VWF2j3gC46od27iO6RkXCKdpYNZjoN1bwRRgTAh/hnosNHuu4fy8Qj0v6Rj1ktVe
JBmdFBI5x2TBuBJatq+wF2SWdEMgu/ThhXelv2sn204P7mqqNa/DgktakGPVNE7X
+kxGsgIeMJUZ3npaNNI5As/WZ+EhNm6rC3KloBqNz5V2Aoq4DRbeOqbLSmCx/4mA
577++Ll4ixOzrh0Zpw1f7uOheVhLVI+VlCUxaoHujh+8a/MSxm0UI1v5kKkGqT0f
LdVJt02d1Rn96HADm/VF
=hp+e
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f0d19a0c-0e58-81a3-a58c-9771e4acf125%40qubes-os.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] DNS

[Unman]

On Sun, Mar 05, 2017 at 09:25:07PM +0100, 'Antoine' via qubes-users wrote:
> Hi,
> 
> I have recently installed Qubes OS and I am experiencing some slow time
> resolution in my debian VM. I have checked the /etc/resolv.conf file and
> it contains the following lines:
> 
> nameserver 10.137.2.1
> nameserver 10.137.2.254
> 
> Playing with dig I can realise that the first IP is working well while
> all DNS queries sent to the second one finish in timeout:
> 
> $ dig +short qubes-os.org @10.137.2.1
> 104.25.152.101
> 104.25.151.101
> $ dig +short qubes-os.org @10.137.2.254
> ;; connection timed out; no servers could be reached
> 
> In sys-firewall, everything seems OK:
> 
> $ iptables -S -t nat
> [...]
> -A PR-QBS -d 10.137.2.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
> 10.137.1.1
> -A PR-QBS -d 10.137.2.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
> 10.137.1.1
> -A PR-QBS -d 10.137.2.254/32 -p udp -m udp --dport 53 -j DNAT 
> --to-destination 10.137.1.254
> -A PR-QBS -d 10.137.2.254/32 -p tcp -m tcp --dport 53 -j DNAT 
> --to-destination 10.137.1.254
> 
> But I have the feeling something is missing in sys-net:
> 
> $ iptables -S -t nat
> [...]
> -A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
> 192.168.1.1
> -A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
> 192.168.1.1
> [...]
> 
> where 192.168.1.1 is the expected DNS server on my LAN.
> 
> Do you have an idea why this DNAT rule is missing? (I am not sure to
> understand why 2 different nameserver are filled in resolv.conf).
> 
> Many thanks for your help,
> 
> Antoine
> 
> -- 

No idea - report it as a bug

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170305210749.GC16686%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] DNS

['Antoine' via qubes-users]

Hi,

I have recently installed Qubes OS and I am experiencing some slow time
resolution in my debian VM. I have checked the /etc/resolv.conf file and
it contains the following lines:

nameserver 10.137.2.1
nameserver 10.137.2.254

Playing with dig I can realise that the first IP is working well while
all DNS queries sent to the second one finish in timeout:

$ dig +short qubes-os.org @10.137.2.1
104.25.152.101
104.25.151.101
$ dig +short qubes-os.org @10.137.2.254
;; connection timed out; no servers could be reached

In sys-firewall, everything seems OK:

$ iptables -S -t nat
[...]
-A PR-QBS -d 10.137.2.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
10.137.1.1
-A PR-QBS -d 10.137.2.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
10.137.1.1
-A PR-QBS -d 10.137.2.254/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
10.137.1.254
-A PR-QBS -d 10.137.2.254/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
10.137.1.254

But I have the feeling something is missing in sys-net:

$ iptables -S -t nat
[...]
-A PR-QBS -d 10.137.1.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 
192.168.1.1
-A PR-QBS -d 10.137.1.1/32 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
192.168.1.1
[...]

where 192.168.1.1 is the expected DNS server on my LAN.

Do you have an idea why this DNAT rule is missing? (I am not sure to
understand why 2 different nameserver are filled in resolv.conf).

Many thanks for your help,

Antoine

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20170305202507.sskvrkfd4ho6sea2%40fedora-23-dvm.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[qubes-users] DNS-handling script

[asdfgher]

Hello
I have setup a VPN in network-manager of my proxyVM. The guide about to
stop DNS leak says that initially I have to copy all the vpn configuration
files in a folder called openvpn, write the script in each one and after
create DNS-handling script.
I have used a different way, saved dns script in every configuration file
without copy them in openvpn folder and create a DNS-handling in config
folder (where there is also iptables script) because I think that the
guide is for those want to autostart VPN, right?

Regards

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9dfa5ba0995eca2c40ddfd4e32b9faf5.webmail%40localhost.
For more options, visit https://groups.google.com/d/optout.