Re: DNS handling
Paul Wouters wrote: Let me know how dnssec-trigger 0.11 works, with the additional hotspot port 80 manglign detection. I'm afraid my laptop isn't all that usable right now – https://bugzilla.redhat.com/show_bug.cgi?id=832723 – but I'll see what I can do. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling was Re: default DNS caching name server on Fedora ?
On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote: Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. [sgallagh@sgallagh520 ~]$ dnssec-trigger Gtk-Message: Failed to load module pk-gtk-module Jun 21 10:42:34 dnssec-trigger-panel[12742] fatal error: cannot setup ssl context: Error setting up SSL_CTX client key and cert error:02001002:system library:fopen:No such file or directory This was after a 'sudo yum install dnssec-trigger --enablerepo=rawhide' on a Fedora 17 x86_64 system. Are there other configuration steps I should be aware of? signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling was Re: default DNS caching name server on Fedora ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/21/2012 10:44 AM, Stephen Gallagher wrote: On Wed, 2012-06-20 at 16:42 -0400, Paul Wouters wrote: Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. [sgallagh@sgallagh520 ~]$ dnssec-trigger Gtk-Message: Failed to load module pk-gtk-module Jun 21 10:42:34 dnssec-trigger-panel[12742] fatal error: cannot setup ssl context: Error setting up SSL_CTX client key and cert error:02001002:system library:fopen:No such file or directory This was after a 'sudo yum install dnssec-trigger --enablerepo=rawhide' on a Fedora 17 x86_64 system. Are there other configuration steps I should be aware of? It looks like the dnssec-triggerd-keygen.service (and after that dnssec-triggerd.service) were not started yet. Either start these using systemctl or reboot. Paul -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJP4zyTAAoJEISzragz8T5uLhQH/1kPLgY9g34/AAsVwXiMx7tV rCfLJf9Zdo7c+Jfh6ZcHsahMh9uDdZDbSBfKlqNahQ5u7xFxvVAQ9j81192Xx/a3 eGXNM9RWAaKELcjpkxyuLayicO8QU6d6si/OzsgUBH75hsH0Wfz3IUxxTR/Ppm6e vVZQQeWYTPhfrujNLXBOO09dzQEjBSDhfHyFY+TNjD0cxrsC6XgvNOFFux35sdCL cKHXu6lV4csigmqpOOaobQKVs5a6p23d7cOpKo6dtJIPhAxOVwzsy3MygiMfxYj0 SS7fRxfMAl43nijo4cvnDgTy0cmjjP+TZLOrK7EsN/SRgcc8hD1pENBO3vRLiME= =h6eH -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling
Paul Wouters wrote: Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. I installed DNSsec-trigger a few months ago and tried it out in a few networks. It seemed to work as advertised in all cases. A hotspot run by a nearby shopping center turned out to be a very hostile network where pretty much everything except HTTPS was blocked or mangled, and DNSsec-trigger correctly detected that it had to mask DNS as HTTPS. The only problem I found was in how the local DNS cache interacts with internal domains on NATed networks. I have a DNS server at home that translates names in my own domain to private IPv4 addresses. Some of those names are also visible publicly, but then they all point to my one public IPv4 address. When I moved from my own network to another Unbound still remembered the private addresses, which were of course not reachable from the other network, and when I moved back to my own network Unbound remembered the public address, which is the wrong address to use there. (With IPv6 I don't have this problem but IPv6 isn't exactly available in every hotspot...) I'm not sure there is anything that DNSsec-trigger can do to work around this if you want it to be able to work from the cache when even HTTPS is blocked. Perhaps dual-view setups like mine should simply use a short TTL to minimize the problem. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DNS handling
On Thu, 21 Jun 2012, Björn Persson wrote: I installed DNSsec-trigger a few months ago and tried it out in a few networks. It seemed to work as advertised in all cases. A hotspot run by a nearby shopping center turned out to be a very hostile network where pretty much everything except HTTPS was blocked or mangled, and DNSsec-trigger correctly detected that it had to mask DNS as HTTPS. Great! Let me know how dnssec-trigger 0.11 works, with the additional hotspot port 80 manglign detection. The only problem I found was in how the local DNS cache interacts with internal domains on NATed networks. I have a DNS server at home that translates names in my own domain to private IPv4 addresses. Some of those names are also visible publicly, but then they all point to my one public IPv4 address. When I moved from my own network to another Unbound still remembered the private addresses, which were of course not reachable from the other network, and when I moved back to my own network Unbound remembered the public address, which is the wrong address to use there. (With IPv6 I don't have this problem but IPv6 isn't exactly available in every hotspot...) I'm not sure there is anything that DNSsec-trigger can do to work around this if you want it to be able to work from the cache when even HTTPS is blocked. Perhaps dual-view setups like mine should simply use a short TTL to minimize the problem. Openswan deals with this because it gets the domain from the IKE protocol, so it can flush the domain and everything under it from the cache. Currently there is no way to signal this with NM. However, if your domain is the search prefix in your home network, then perhaps it would be enough if NM/dnssec-trigger would flush everything of the previous search domain from the cache. Using TTL=0 or something fairly short should help you in your case though. Paul Björn Persson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
DNS handling was Re: default DNS caching name server on Fedora ?
People have might missed it before, but Fedora does a lot now with handling the various DNS manglings it can encounter in the wild. If you install dnssec-trigger from rawhide, then your DNS will be automatically configured using DNSSEC and with as much security as possible, while detecting hotspots and telling you when you are temporarilly using insecure DNS (eg to authenticate a hotspot) dnssec-trigger uses two web pages run by the fedora infrastructure team to do this. One page to trigger redirects on port 80, and one page to detect port 80 mangling. Upon connecting to a new network, dnssec-trigger performs a full test of the DNS server supplied by the DHCP server. If it supports DNSSEC, it is used to forward all queries. If not, then a free port 53 is probed to see if unbound should do all recursing itself. If that is broken or blocked, it will attempt to talk raw DNS over port 80, or DNS wrapped in SSL over port 443 to three DNS resolvers run by Fedora (you can see these configurations in /etc/dnssec-trigger/dnssec-triggerd.conf). If that also fails, then it will warn you and give you a choice between going insecure or only using already cached DNS. It will also try to connect to fedoraproject.org/static/hotspot.html and detect if you are hotspotted. It will popup a warning for you to login to the hotspot with a new browser window. Once the hotspot.html page looks normal, we know you authenticated (clicked OK, or paid) and DNS is reprobed to see if we now can do DNSSEC. We are trying to work under a lot of different scenario's, including hotspots that break DNS, hotspots intercepting all port 53, hotspots counting in you doing port 80 traffic to do an http redirect, etc etc. This is currently mostly done by dnssec-triggerd, which reconfigures unbound on the fly. When going insecure, it rewrites resolv.conf to point to the DHCP obtained DNS, but when it is secure, it will point DNS to 127.0.0.1 where unbound will answer. And as I said in my previous email, when you bring up a VPN using openswan, it deals with the specific domain and its name servers for you dynamically as well. But vpnc does not yet support this. What I would like to do next is to tie network manager and dnssec-trigger more closely together, so we don't have to do tricks like making resolv.conf immutable to prevent others from bypassing DNSSEC security by rewriting that file. Install dnssec-trigger, start the dnssec-trigger panel application and please give me feedback! Especially when you experience dns failures at hotspots. There are so many different kinds of broken dns out there, I'm sure we need to do more inventive things to make it work for everyone. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
