From bry8star at inventati.org Fri Nov 1 06:30:53 2013 From: bry8star at inventati.org (Bry8 Star) Date: Thu, 31 Oct 2013 23:30:53 -0700 Subject: [Dnssec-trigger] Dnssec-Trigger and MacOSX 10.8.3 In-Reply-To: <523A5B5A.3020203@inventati.org> References: <52394C86.4030504@inventati.org> <52395F01.8060608@nlnetlabs.nl> <5239774C.90905@inventati.org> <523A5B5A.3020203@inventati.org> Message-ID: <52734A9D.2060803@inventati.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 A follow-up. On that/mentioned Mac OS X 10.8.3 computer, when i applied same temporary solution from 10.6.8 (mentioned in last email), unbound still didn't work. And, i had to set these below 3 additional lines: username: "" chroot: "" directory: "" ... for unbound to start and stay running. Unbound's script file need to be fixed so it can create "unbound" username correctly on correct time, and null/erase it when not needed. By the way, i forgot to place a double-quote symbol at the end of this/below essential line in previous email, so correct line for default level installation cases, is: auto-trust-anchor-file: "/etc/unbound/root.key" And few other extra & optional configuration lines (and few corrected lines) which were also helpful, are: interface: 127.0.0.1 port: 53 access-control: 127.0.0.0/8 allow dlv-anchor-file: "/etc/unbound/dlv.isc.org.key" # Above ISC DLV helps domain-names, when owner added # their DNSSEC related DNS record there, as Domain's # Registry company/entity do not yet fully support DNSSEC. server: # domain-insecure: "42" # domain-insecure: "bit" # domain-insecure: "ovh" # TLDs which are still not yet DNSSEC signed, # needs to be added like above, for accessing. # Forwarding/Stub zone related to above insecure domains, # are not shown/included here. server: local-zone: "onion." refuse local-zone: "exit." refuse local-zone: "noconnect." refuse local-zone: "i2p." refuse # Above 4 lines, block above TLD types of DNS leaks. server: remote-control: control-enable: yes control-interface: 127.0.0.1 control-port: 8953 server-key-file: "/etc/unbound/unbound_server.key" server-cert-file: "/etc/unbound/unbound_server.pem" control-key-file: "/etc/unbound/unbound_control.key" control-cert-file: "/etc/unbound/unbound_control.pem" The file "dlv.isc.org.key" is not present in Mac OS X by default, so i had to copy from another (Windows) computer into it. And, to see all hidden files try both below commands, as newer OSX changed few parameter's case: defaults write com.apple.Finder AppleShowAllFiles TRUE defaults write com.apple.finder AppleShowAllFiles TRUE After setting above configuration, and restarting Mac computer once, "unbound" started to work (in Mac OSX 10.8.3). Thanks, - -- Bright Star. Received from Bry8 Star, on 2013-09-18 7:03 PM: > Another test on another Apple-Mac OSX 10.6.8 (Snow Leopard): > > (I have intentionally described some steps/stages in detail, so that > its easier for those users who are new or comparatively new to > MacOSX or these type of enhancements). > > Initially, Firefox(FF) already have these addons/extensions: (1) > DNSSEC Validator (2) Extended DNSSEC Validator. > FF ext (1) is configured to use "Without Resolver" (default). And > no DNS server ip-address is specified inside FF ext (2) settings, so > its using its own internal pre-settings. > Wi-Fi Network adapter (connected to router/internet) showing DNS > 192.168.0.1. > > With such as above settings, when site like www.StatDNS.net is > visited using HTTPS scheme in firefox, then firefox's url bar's > right side icon (from DNSSEC Validator, icon which shows different > colored 'key' shapes) shows a green colored 'key' and when icon is > clicked-on it shows "Site is Secured by DNSSEC". DNSSEC Validator > uses a separate Firefox Plugin Process. I think it runs libunbound > based own dns-resolving functions inside that plugin process. > Firefox's URL bar's left side icon (from Extended DNSSEC Validator, > which shows ether a 'World' or 'Lock' image/picture) shows a 'Lock' > shape and when clicked-on, shows info, that, "Site is secured by > DNSSEC and SSL cert is verified by (both) DNSSEC (TLSA) and CA." or > it shows "Your connection to this website is encrypted to prevent > evesdropiing" and "Verified by StartCom Ltd". Other apps like "App > Store" can retrieve content from apple website and show it. In > Terminal: ping statdns.net <- works, dig @192.168.0.1 -t any > statdns.net. and dig any statdns.net. <- works. > > dig @192.168.0.1 -t any statdns.net. +dnssec <- do not shows "ad" > flags, as 192.168.0.1 is not a DNSSEC-based Validating DNS-Resolver. > > > - - - - - - - > > PROBLEMS WHICH I FACED: > > After installing DnssecTrigger 0.11 in MacOSX: > > DNS in WiFi adapter is changed into 127.0.0.1. > > When icon of DnssecTrigger in top menu bar is clicked-on and "Probe > Results" option is selected, then it shows info such as: http > fedoraproject.org (140.211.169.197): OK. cache 192.168.0.1: OK. > DNSSEC results fetched from (DHCP) cache(s). > > Apps like "App Store" can retrieve content from apple website and > show it, ping to statdns.net works. dig @127.0.0.1 any statdns.net. > +dnssec shows SERVFAIL. > > Firefox's two DNSSEC related icons stops working properly. > > I can indeed see OSX process named "unbound" and "dnssec-triggerd" > running. > > - - - - - - - > > > (Temporary) SOLUTION PROCESS/STEPS: > > So this is what i did on that MacOSX 10.6.8: > (In brief: only Unbound will run, DnssecTrigger portion will be > disabled, all apps will always use local 127.0.0.1 unbound as a > local validating DNS Resolver/Server. But by doing these, i (or who > will follow, he/she/they), will loose ability to use DnssecTrigger > which have advanced features to switch between different regular and > encrypted DNS-Servers on different scenario. I'm doing this now, > because DNSSEC-trigger portion causing Unbound to not work properly). > > Enabled viewing all hidden files & folders, by running below > command-line inside Terminal: > > defaults write com.apple.Finder AppleShowAllFiles TRUE > > Then restarted OSX machine once. > > List of TextEditor type of software: > http://technologytosoftware.com/best-free-mac-os-text-editors-for-web-developers-2.html > > Edited /etc/unbound/unbound.conf file to have these lines only, all > other lines have # symbol at left most side, (later i added other > lines for tuning unbound further): > > server: > verbosity: 1 > do-udp: yes > do-tcp: yes > do-daemonize: yes > # use-syslog: yes > hide-identity: yes > hide-version: yes > module-config: "validator iterator" > auto-trust-anchor-file: "/etc/unbound/root.key > python: > remote-control: > control-enable: yes > control-interface: 127.0.0.1 > control-port: 8953 > > > Edited /etc/dnssec-trigger/dnssec-trigger.conf file, and made sure, > all lines are Disabled, that is all lines have the "#" symbol at > left most side. > > Then went into /Library/LaunchDaemons folder and 1st made backup > copy of below two files into > /Users/[my-user-name]/Documents/bkup/Lib/LaunchDaemons folder: > nl.nlnetlabs.dnsec-trigger-hook.plist > nl.nlnetlabs.dnsec-triggerd.plist > And then trashed/deleted those two from /Library/LaunchDaemons folder. > > (You may use a software like Lingon for this step. And if you use > different OSX then you may need to also look for above two files > inside any one of these folders/directories : > /Library/LaunchDaemons, /Library/LaunchAgents, > /System/Library/LaunchAgents, /System/Library/LaunchDaemons, > ~/Library/LaunchDaemons, ~/Library/LaunchAgents, > ~/Library/StartupItems, and /Library/StartupItems). > > Similarly like above, made backup copy and removed below file: > /Library/LaunchAgents/nl.nlnetlabs.dnssec-trigger-panel.plist > > And, made sure /etc/resolv.conf file showing following line in it: > nameserver 127.0.0.1 > > And made sure two extensions/addons related to DNSSEC in Firefox is > using 127.0.0.1 specifically. > > By the way, can someone pls let us/users know, what this file by > default contains ? Thanks. > > OSX machine must have to be restarted. > > - - - - - - - - - - > > RESULT: > > Finally now, Firefox url bar's two icons related to DNSSEC working & > displaying properly. Pre-known DNSSEC signed sites and known DANE > based sites, showed fairly and better icon than before. Those two > addons definitely need more improvements. > Other/system apps are also able to access internet and working. > ping statdns.net etc working. > dig @127.0.0.1 -t any statdns.net. +dnssec (working, showed > "NOERROR" and "ad") > :) > > - - - - - - - - - - > > I'm sure i can now apply this process on that 10.8.3 machine and > there should be NO reason for that local Unbound to not work. > > And when a new dnssec-trigger will for sure work, then i can get > that new dnssectrigger pkg from NLnetLabs website and install that > over the older one. > > I'm now happy with at-least a working DNSSEC based Validating > DNS-Resolver/DNS-Server. :) > > Thanks, > -- Bright Star. > > > > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJSc0qdAAoJEID2ikYfWSP6maYP/3LcQ1Eq2DBPfXUnuYSGNixk Vc02uyJoJQzI4BPnoRcOS3CBPKaIiqr0WXd8YV9iiNJw87qagWswvvTm9xrRjzI5 prAodn2iharvv9SvBEYAbxrWb8pNMLklYD6sxBYfqEPbIzxe0XIuWpGpheheIqeJ anZL3yj/EjRuNjd7NvydIbddkETb1RlXOJuMvbG9Xbx8dBfZPPgfzDkqIX8lRFIS HijWQmlsWT0ibkIDpQv87cER/YygnD8x5/qxZp4fc8vmK4RnsDSLjVTubKpvuxBD HBeJ0Lo+m1rfeGnND+5KzJRjTEWb9y4bQpuHda+Ldtpu0haXnyanQp4BLNT5MbFU THSFEOmhmh+rOVoUUjENgVX6JicnVN1pGd0fB3Oclct06V+1GUCjRlqE/4r1UME2 DIGtztokSnzRPQzyRChO5MhGqTHKmp2K0d1Us7GKF7juqy5kuntLDSXTtaLzEWBc Gm9bTDyclN+4HwAnntf37QmjrWHfKMj9JiNJSQeC/PQjxN3Jinb56tLKTrul2g/a n9ijRT0RYV/ANW0nSQOCIp+8ezRYGYgOSgtULB8cciEJjdF4QqFWcs8Sxvq89uXP SCGYnbvcYauZvEtF1d/vI4BaMt4XO+zaYD2CtuVeEfb1R+4kq/TqobB2847Snrk5 i51oRRUqdVZ1XFs9h/xh =YFua -----END PGP SIGNATURE----- From thozza at redhat.com Tue Nov 12 15:12:24 2013 From: thozza at redhat.com (Tomas Hozza) Date: Tue, 12 Nov 2013 10:12:24 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] Fix NM dispatcher script to work with NM >= 0.9.9.0 In-Reply-To: <1347980442.14735283.1384268963353.JavaMail.root@redhat.com> Message-ID: <65689065.14736676.1384269144900.JavaMail.root@redhat.com> Hi. I'm sending you a patch for NM dispatcher script so it works OK with NM version >= 0.9.9.0. The script now checks the nmcli version and based on it uses appropriate syntax. Regards, Tomas Hozza -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-NM-dispatcher-script-to-work-with-NM-0.9.9.0.patch Type: text/x-patch Size: 1484 bytes Desc: not available URL: From wouter at nlnetlabs.nl Thu Nov 14 09:20:08 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Thu, 14 Nov 2013 10:20:08 +0100 Subject: [Dnssec-trigger] [PATCH] Fix NM dispatcher script to work with NM >= 0.9.9.0 In-Reply-To: <65689065.14736676.1384269144900.JavaMail.root@redhat.com> References: <65689065.14736676.1384269144900.JavaMail.root@redhat.com> Message-ID: <528495C8.50208@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tomas, Thanks for the patch. Applied. Best regards, Wouter On 11/12/2013 04:12 PM, Tomas Hozza wrote: > Hi. > > I'm sending you a patch for NM dispatcher script so it works OK > with NM version >= 0.9.9.0. > > The script now checks the nmcli version and based on it uses > appropriate syntax. > > Regards, > > Tomas Hozza > > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShJXAAAoJEJ9vHC1+BF+Nd0gQAJfSdJOl8SJ6JqJq26LN9wjc O2HD5oG3Pr7i9xZd1tNgCB9UrA8REdAVTs++A7pfv+gFuSF8K8XCvbYd6I/mdA+L NR4SnTBEtbcRjpvzvtxez2xs1A/F1gRaBNjPJaEOmjvyxwKyeOHXO10Pu5kH/rzU rPD9s/ir35xW0uOvacMuqFZYaTf7oKHLgshizr627ct2C3/H7bIJYP/inQaEFBSn xGLFix3SlexxGIQ1vFGKN9gJaKM9Dlt3KaOvNHwMnUYSnUBAEzQrw6iv7dg4wA88 wbx/dZcOZ/OtqPlQ0FCMHjhJ3Ih1tVMbZj/7whh/zRD8c5HugtD0OJ+zaoDVQ7ur LBuHqdH+06x6Oxnu+QuVQa11b2sZcpF/P2XEV2kJhqtm9/EapV8BciQclolSpcWt liOK7rd+VtGFKTBLVIouIkK0NGvqE9tz8wqKty2fkEtWTes6nBAW6zZdtd/Jr1uy X3NTNE24NdBvnlMC1u6UTOl/r89A2Pc/7jOWZWStAMvWVh58UTora6fHNF6MiFuv zYtyIgiB8B9GUBf2PLH65YlH/3wBLGS37E68ghPVhUcYZQExfYdYEvJM0tLnVTa5 WAYEBqhfzvlNZt80QfJbR9v9lkgJigAp92b9kIb9uOgiVRutKibUcxksn79fMCel ktiirpUtWIonFmee+SMt =9fsl -----END PGP SIGNATURE----- From thozza at redhat.com Fri Nov 15 13:31:40 2013 From: thozza at redhat.com (Tomas Hozza) Date: Fri, 15 Nov 2013 08:31:40 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] Improve texts in dialogs to be more clear In-Reply-To: <2066399895.15941209.1384521906651.JavaMail.root@redhat.com> Message-ID: <1860002449.15943032.1384522300753.JavaMail.root@redhat.com> Hello. I'm sending you a patch that improves texts in most of dnssec-trigger dialogs and also some dialogs labels and pop-up panel button label, to describe the situation more clearly. And to be more formal and consistent. Regards, Tomas Hozza -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Improve-texts-in-dialogs-to-be-more-clear.patch Type: text/x-patch Size: 7175 bytes Desc: not available URL: From wouter at nlnetlabs.nl Fri Nov 15 14:08:58 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Fri, 15 Nov 2013 15:08:58 +0100 Subject: [Dnssec-trigger] [PATCH] Improve texts in dialogs to be more clear In-Reply-To: <1860002449.15943032.1384522300753.JavaMail.root@redhat.com> References: <1860002449.15943032.1384522300753.JavaMail.root@redhat.com> Message-ID: <52862AFA.40201@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tomas, Thanks, Committed. Best regards, Wouter On 11/15/2013 02:31 PM, Tomas Hozza wrote: > Hello. > > I'm sending you a patch that improves texts in most of > dnssec-trigger dialogs and also some dialogs labels and pop-up > panel button label, to describe the situation more clearly. And to > be more formal and consistent. > > Regards, > > Tomas Hozza > > > > _______________________________________________ dnssec-trigger > mailing list dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJShir6AAoJEJ9vHC1+BF+NywIQAKiOwMtY36Nxi96r+/WuNyeq 044Le7DEZpEh2DAnn2VO4e9nUmvPKnVejWOW3Bl5e/+Y+MmnRQsUBsVNcNT297/J LrXEtF+GVHFP0nPOl2hFKmgFWEsgnejjKHqaFy9J5xOHiToW4M3JJywuIEgpc21l vJJRsbXI6aMyo0DXyp/jPQcyFYAiDf6yRwrlzcc/EbZQHIAyi2qqNqVov0fNomSN dgH2mZHdHbAKb786KAVpyjdd07d0hcoGXy0C2LULEB2IkYrJXx6nWMo0lC52z0Qz zz49u7ICPph06WD4KOtargihB07JbPEMGbzfVBoHk+nNJpKwnDeSiifpDhyAMeLW RLEXpBnfv708r1yIwi8u33jIGbpdHAlYLPqj1VQICh3z4XvPMsM0JeZxKr1cUGsF asYEjNjXgM58QWCaMqo42AL7lm9tWLcl21yO6e+6VjyHU5dAJaZLwP76x6EPIOq+ wdTrXPaJ+bWH20yLQLxnGuI2oCJwgOcEtbF0aT5lGgZXJWj87yJk0ImlyjGsgLiR eLOcVN0vjRAuk1sr0wvmcW0wS7t65ttcxkk1eQ9Drk1mMAw/1cNrWMkWpD4NIgLi kORgvcrUGcieA1h0SHpYmapKqo1pOyxPrBTaWPwYBu8a1kO5tjh4Zv4XY0eIvLnx evTXTrIxg/sYv8+BfF8U =45WU -----END PGP SIGNATURE----- From thozza at redhat.com Mon Nov 18 08:27:11 2013 From: thozza at redhat.com (Tomas Hozza) Date: Mon, 18 Nov 2013 03:27:11 -0500 (EST) Subject: [Dnssec-trigger] [PATCH] Improve texts in dialogs to be more clear In-Reply-To: <52862AFA.40201@nlnetlabs.nl> References: <1860002449.15943032.1384522300753.JavaMail.root@redhat.com> <52862AFA.40201@nlnetlabs.nl> Message-ID: <564165261.16281597.1384763231366.JavaMail.root@redhat.com> Hi Wouter. Thank you for accepting my changes. Unfortunately I missed one sentence in "unsafe_dialog" so I'm sending you one more small patch with correction. Regards, Tomas Hozza ----- Original Message ----- > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Tomas, > > Thanks, Committed. > > Best regards, Wouter > > On 11/15/2013 02:31 PM, Tomas Hozza wrote: > > Hello. > > > > I'm sending you a patch that improves texts in most of > > dnssec-trigger dialogs and also some dialogs labels and pop-up > > panel button label, to describe the situation more clearly. And to > > be more formal and consistent. > > > > Regards, > > > > Tomas Hozza > > > > > > > > _______________________________________________ dnssec-trigger > > mailing list dnssec-trigger at NLnetLabs.nl > > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.15 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJShir6AAoJEJ9vHC1+BF+NywIQAKiOwMtY36Nxi96r+/WuNyeq > 044Le7DEZpEh2DAnn2VO4e9nUmvPKnVejWOW3Bl5e/+Y+MmnRQsUBsVNcNT297/J > LrXEtF+GVHFP0nPOl2hFKmgFWEsgnejjKHqaFy9J5xOHiToW4M3JJywuIEgpc21l > vJJRsbXI6aMyo0DXyp/jPQcyFYAiDf6yRwrlzcc/EbZQHIAyi2qqNqVov0fNomSN > dgH2mZHdHbAKb786KAVpyjdd07d0hcoGXy0C2LULEB2IkYrJXx6nWMo0lC52z0Qz > zz49u7ICPph06WD4KOtargihB07JbPEMGbzfVBoHk+nNJpKwnDeSiifpDhyAMeLW > RLEXpBnfv708r1yIwi8u33jIGbpdHAlYLPqj1VQICh3z4XvPMsM0JeZxKr1cUGsF > asYEjNjXgM58QWCaMqo42AL7lm9tWLcl21yO6e+6VjyHU5dAJaZLwP76x6EPIOq+ > wdTrXPaJ+bWH20yLQLxnGuI2oCJwgOcEtbF0aT5lGgZXJWj87yJk0ImlyjGsgLiR > eLOcVN0vjRAuk1sr0wvmcW0wS7t65ttcxkk1eQ9Drk1mMAw/1cNrWMkWpD4NIgLi > kORgvcrUGcieA1h0SHpYmapKqo1pOyxPrBTaWPwYBu8a1kO5tjh4Zv4XY0eIvLnx > evTXTrIxg/sYv8+BfF8U > =45WU > -----END PGP SIGNATURE----- > _______________________________________________ > dnssec-trigger mailing list > dnssec-trigger at NLnetLabs.nl > http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-One-more-text-modification-in-the-unsafe_dialog.patch Type: text/x-patch Size: 1056 bytes Desc: not available URL: From thozza at redhat.com Thu Nov 21 16:09:53 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 21 Nov 2013 11:09:53 -0500 (EST) Subject: [Dnssec-trigger] resolv.conf content after dnssec-trigger stop In-Reply-To: <528A2A94.9050807@redhat.com> References: <442498919.16292393.1384765109187.JavaMail.root@redhat.com> <497769219.16307895.1384768759646.JavaMail.root@redhat.com> <528A2A94.9050807@redhat.com> Message-ID: <361630970.17740768.1385050193374.JavaMail.root@redhat.com> Hi. I finished and successfully tested the script for backing-up and restoring resolv.conf. Its behaviour was consulted with QE and it works as follows: 1. if called as "dnssec-trigger-resolvconf-handle.sh backup" - if NM is configured with "dns=none" it copies resolv.conf into /var/run/dnssec-trigger 2. if called as "dnssec-trigger-resolvconf-handle.sh restore" - if backup in /var/run/dnssec-trigger exists and NM is configured with "dns=none" it will restore the resolv.conf - else it will obtain current list of nameservers and writes them into resolv.conf until NM rewrites it. I'm working with systemd guys on the right systemd.service file, because systemd had some problems with creating transaction. But this is for sure doable, since I have couple of other ways how to make it work. I'm CCing also dnssec-trigger mailing-list, since I think such script should be included in the upstream repo if agreed that it is good. Thanks. Regards, Tomas Hozza ----- Original Message ----- > > [ ExecStop script ] > > Good idea. Note that an unrelated bug sometimes causes dnssec-triggerd > to write a resolv.conf without any nameserver entry. I've filed that as > bug upstream and they confirmed it. We might need to poke them a few > times to get it fixed though. > > >> I was recently thinking about the situation that happens > >> if you stop dnssec-trigger on the system. dnssec-trigger > >> will leave most probably (depending on the state it was in) > >> "127.0.0.1" in resolv.conf. This can cause a really > >> frustrating user experience, since NM will not write DNS > >> servers IP addresses into it until next network change. > >> > >> Currently there is no way how to tell NM to write the > >> configuration into the resolv.conf besides restarting > >> it. > > This should get folded into a NM plugin, so NM can fully > control resolv.conf and we can restrict selinux to only > allow NM to write /etc/resolv.conf. It would also remove > the need for making it immutable. Problem is, we are all > busy people.... > > Paul > > -------------- next part -------------- A non-text attachment was scrubbed... Name: dnssec-trigger-resolvconf-handle.sh Type: application/x-shellscript Size: 2321 bytes Desc: not available URL: From paul at nohats.ca Thu Nov 21 17:17:14 2013 From: paul at nohats.ca (Paul Wouters) Date: Thu, 21 Nov 2013 12:17:14 -0500 (EST) Subject: [Dnssec-trigger] resolv.conf content after dnssec-trigger stop In-Reply-To: <361630970.17740768.1385050193374.JavaMail.root@redhat.com> References: <442498919.16292393.1384765109187.JavaMail.root@redhat.com> <497769219.16307895.1384768759646.JavaMail.root@redhat.com> <528A2A94.9050807@redhat.com> <361630970.17740768.1385050193374.JavaMail.root@redhat.com> Message-ID: On Thu, 21 Nov 2013, Tomas Hozza wrote: > I finished and successfully tested the script for backing-up > and restoring resolv.conf. Its behaviour was consulted with QE > and it works as follows: > > 1. if called as "dnssec-trigger-resolvconf-handle.sh backup" > - if NM is configured with "dns=none" it copies resolv.conf > into /var/run/dnssec-trigger > > 2. if called as "dnssec-trigger-resolvconf-handle.sh restore" > - if backup in /var/run/dnssec-trigger exists and NM is configured > with "dns=none" it will restore the resolv.conf > - else it will obtain current list of nameservers and writes them > into resolv.conf until NM rewrites it. > > I'm working with systemd guys on the right systemd.service file, because > systemd had some problems with creating transaction. But this is for sure > doable, since I have couple of other ways how to make it work. > > I'm CCing also dnssec-trigger mailing-list, since I think such script > should be included in the upstream repo if agreed that it is good. I would really prefer _less_ programs touching /etc/resolv.conf, not more (vpn software, systemd, scripts,... etc) Perhaps dnssec-triggerd should have a method where it only probes and reports the results, without rewriting /etc/resolv.conf so that can be done by NM itself, which can then be restricted by SElinux, and we can block every other program from writing /etc/resolv.conf without requiring the immutable file hack. VPN software can then just tell NM what the new DNS entries and domain are, and NM can run unbound-control to reconfigure unbound on the fly. And when the network changes, NM can call dnssec-triggerd to get a report, and then make the /etc/resolv.conf changes itself. Paul From thozza at redhat.com Thu Nov 21 22:44:16 2013 From: thozza at redhat.com (Tomas Hozza) Date: Thu, 21 Nov 2013 17:44:16 -0500 (EST) Subject: [Dnssec-trigger] resolv.conf content after dnssec-trigger stop In-Reply-To: References: <442498919.16292393.1384765109187.JavaMail.root@redhat.com> <497769219.16307895.1384768759646.JavaMail.root@redhat.com> <528A2A94.9050807@redhat.com> <361630970.17740768.1385050193374.JavaMail.root@redhat.com> Message-ID: <1165477256.17885422.1385073856693.JavaMail.root@redhat.com> ----- Original Message ----- > On Thu, 21 Nov 2013, Tomas Hozza wrote: > > I finished and successfully tested the script for backing-up > > and restoring resolv.conf. Its behaviour was consulted with QE > > and it works as follows: > > > > 1. if called as "dnssec-trigger-resolvconf-handle.sh backup" > > - if NM is configured with "dns=none" it copies resolv.conf > > into /var/run/dnssec-trigger > > > > 2. if called as "dnssec-trigger-resolvconf-handle.sh restore" > > - if backup in /var/run/dnssec-trigger exists and NM is configured > > with "dns=none" it will restore the resolv.conf > > - else it will obtain current list of nameservers and writes them > > into resolv.conf until NM rewrites it. > > > > I'm working with systemd guys on the right systemd.service file, because > > systemd had some problems with creating transaction. But this is for sure > > doable, since I have couple of other ways how to make it work. > > > > I'm CCing also dnssec-trigger mailing-list, since I think such script > > should be included in the upstream repo if agreed that it is good. > > I would really prefer _less_ programs touching /etc/resolv.conf, not > more (vpn software, systemd, scripts,... etc) > > Perhaps dnssec-triggerd should have a method where it only probes and > reports the results, without rewriting /etc/resolv.conf so that can be > done by NM itself, which can then be restricted by SElinux, and we can > block every other program from writing /etc/resolv.conf without requiring > the immutable file hack. > > VPN software can then just tell NM what the new DNS entries and domain > are, and NM can run unbound-control to reconfigure unbound on the fly. > And when the network changes, NM can call dnssec-triggerd to get a > report, and then make the /etc/resolv.conf changes itself. > > Paul I know that the NM plugin is the ultimate solution. However it does not exist yet. I'm trying to make the DNSSEC client validation using dnssec-trigger more robust, so it works OK in every possible scenario, until some NM plugin is created. Tomas From wouter at nlnetlabs.nl Mon Nov 25 13:39:59 2013 From: wouter at nlnetlabs.nl (W.C.A. Wijngaards) Date: Mon, 25 Nov 2013 14:39:59 +0100 Subject: [Dnssec-trigger] resolv.conf content after dnssec-trigger stop In-Reply-To: <361630970.17740768.1385050193374.JavaMail.root@redhat.com> References: <442498919.16292393.1384765109187.JavaMail.root@redhat.com> <497769219.16307895.1384768759646.JavaMail.root@redhat.com> <528A2A94.9050807@redhat.com> <361630970.17740768.1385050193374.JavaMail.root@redhat.com> Message-ID: <5293532F.4080708@nlnetlabs.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tomas, Thanks for this and the one-more-line modification. I put it into the fedora/ subdirectory, but if you want it could be elsewhere (the main dir and installed somewhere?). Best regards, Wouter On 11/21/2013 05:09 PM, Tomas Hozza wrote: > Hi. > > I finished and successfully tested the script for backing-up and > restoring resolv.conf. Its behaviour was consulted with QE and it > works as follows: > > 1. if called as "dnssec-trigger-resolvconf-handle.sh backup" - if > NM is configured with "dns=none" it copies resolv.conf into > /var/run/dnssec-trigger > > 2. if called as "dnssec-trigger-resolvconf-handle.sh restore" - if > backup in /var/run/dnssec-trigger exists and NM is configured with > "dns=none" it will restore the resolv.conf - else it will obtain > current list of nameservers and writes them into resolv.conf until > NM rewrites it. > > I'm working with systemd guys on the right systemd.service file, > because systemd had some problems with creating transaction. But > this is for sure doable, since I have couple of other ways how to > make it work. > > I'm CCing also dnssec-trigger mailing-list, since I think such > script should be included in the upstream repo if agreed that it is > good. > > > Thanks. > > Regards, > > Tomas Hozza > > ----- Original Message ----- >> >> [ ExecStop script ] >> >> Good idea. Note that an unrelated bug sometimes causes >> dnssec-triggerd to write a resolv.conf without any nameserver >> entry. I've filed that as bug upstream and they confirmed it. We >> might need to poke them a few times to get it fixed though. >> >>>> I was recently thinking about the situation that happens if >>>> you stop dnssec-trigger on the system. dnssec-trigger will >>>> leave most probably (depending on the state it was in) >>>> "127.0.0.1" in resolv.conf. This can cause a really >>>> frustrating user experience, since NM will not write DNS >>>> servers IP addresses into it until next network change. >>>> >>>> Currently there is no way how to tell NM to write the >>>> configuration into the resolv.conf besides restarting it. >> >> This should get folded into a NM plugin, so NM can fully control >> resolv.conf and we can restrict selinux to only allow NM to write >> /etc/resolv.conf. It would also remove the need for making it >> immutable. Problem is, we are all busy people.... >> >> Paul >> >> >> >> >> _______________________________________________ dnssec-trigger >> mailing list dnssec-trigger at NLnetLabs.nl >> http://open.nlnetlabs.nl/mailman/listinfo/dnssec-trigger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSk1MvAAoJEJ9vHC1+BF+N+d8QAKtIpnM4Ncc9Ubt7fqIaH8kf kzsbl/CVOZL//rNAMxQ4MY1X/6PQrfBAlc4w+TqmtefkCcKfzrKRgmexOK4bJArg Q+vezG8Be33owYilWblPJ89B/dfGvylDs/vDuzlf5sAHhu6tG78rydYaEJnOXI+u 3qiShapixkSX6nlUEcRrvpKjcnzmVA2Up9MmuH0O2PuaBzOVF7Ux6IFjJDhq8seE dqNSPX+xRUb0qpMGnCxcT876z/GC78KtRigtdYCIdxZHKLE1ucBWAdFONd5BjV7h B8JtnMMWt/1D6aN+TM4IkDHMLgZoIHFz2hUv5kItY5mJuao/Vaj2y5GrCVo2fLpb 3CP1t8+aInw/kTbTUsvzIf4VbVU8AU35m4HbWRoDZLsZ+r22snw0537L1EG4vN4h Xf0rTCyEFIYhwmIfHpPVjMIh/60T8Vb6ouc2AvcghaGwHivxb8uqrCdBqlrnaWtN K8HaOcwy3BWCikaTYVJis8tuORmqB+G0LR0jFLmkjpiRe5KTEYaaVYv68lXdxvte TYz1TiGUba0IzC6x5nFCCEPxeJqjsVQvlsJIbqGMGbDq6dzLCelbtv9idPocbltX Nu6PwW27F9QxXuQ1Qc47K+eQzzUM7Ji2dQNpLXDtfAGBmi1bEbvpy3p5CExhtoIT gViUdymG7uLgJza4yy+A =3h7g -----END PGP SIGNATURE-----