- Original Message -
On 18.6.2015 13:14, Bastien Nocera wrote:
- Original Message -
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution. Vague claims
that something is missing or something needs to be done, without clear
reasoning is not helping anyone.
- Original Message -
On 18.06.2015 13:14, Bastien Nocera wrote:
- Original Message -
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the
On 18.6.2015 13:14, Bastien Nocera wrote:
- Original Message -
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could add the
On 18.06.2015 13:14, Bastien Nocera wrote:
- Original Message -
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could add the
VPNs... done like 2 years ago. From what we discussed the connectivity
checking is not really perfect in NM, since it assumes that DHCP
provided resolvers are in resolv.conf because NM obviously uses system's
stub resolver.
If there are any valid integration pieces, please be
- Original Message -
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could add the dns=unbound stuff (which Pavel
contributed) but
- Original Message -
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution. Vague claims
that something is missing or something needs to be done, without
- Original Message -
VPNs... done like 2 years ago. From what we discussed the connectivity
checking is not really perfect in NM, since it assumes that DHCP
provided resolvers are in resolv.conf because NM obviously uses system's
stub resolver.
If there are any valid
Am 18.06.2015 um 17:17 schrieb Bastien Nocera:
- Original Message -
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution. Vague claims
that something is missing
- Original Message -
Am 18.06.2015 um 17:17 schrieb Bastien Nocera:
- Original Message -
Am 18.06.2015 um 15:29 schrieb Bastien Nocera:
I would love to see more will for cooperation from GNOME people, so we
can converge to the working and well integrated solution.
On Mon, 2015-06-15 at 14:57 +0200, Petr Spacek wrote:
On 12.6.2015 18:53, Dan Williams wrote:
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then
On Fri, 2015-06-12 at 14:32 -0400, Paul Wouters wrote:
On Fri, 12 Jun 2015, Dan Williams wrote:
That is why HTTP redirection and DNS failure have to be detected by
whatever is the hot spot detector. Both items weigh in on triggering
a hotspot logon window.
Agreed. But how does the
On Wed, 2015-06-17 at 13:17 +0200, Tomas Hozza wrote:
On 12.06.2015 18:58, Dan Williams wrote:
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
On 11.06.2015 22:48, Dan Williams wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400,
On Thu, 18 Jun 2015, Dan Williams wrote:
True. In fact with unbound it is pretty trivial to do. The equivalent
unbound python code for that would be:
import unbound
ctx = unbound.ub_ctx()
ctx.resolvconf(/this/networks/respresentation/of/resolv.conf)
Hmm, that doesn't really allow for split
On Thu, 18 Jun 2015, Dan Williams wrote:
The drawbacks I see to dnssec-trigger here are:
2) provides only HTTPS IPC, perhaps because it works on all platforms.
But a Linux-only solution would typically use a unix socket or D-Bus and
be secured by Unix or D-Bus permissions instead of using
On 17.06.2015 16:22, Paul Wouters wrote:
On Wed, 17 Jun 2015, Tomas Hozza wrote:
While I don't actually care, this might well be a sticking point for
many people since their DNS information is going to an untrusted (to
them) DNS server. Yeah, I tend to trust Fedora, but not everyone will.
On 12.06.2015 19:17, Paul Wouters wrote:
On 06/12/2015 12:53 PM, Dan Williams wrote:
b) Broken networks:
Some networks are so broken that even without captive portal they are not
able
to deliver DNSSEC data to the clients.
In that case will try tunnel to other DNS servers on the Internet
On 12.06.2015 18:58, Dan Williams wrote:
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
On 11.06.2015 22:48, Dan Williams wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the
On 12.06.2015 16:58, Paul Wouters wrote:
On Fri, 12 Jun 2015, Matthew Miller wrote:
Another integration concern: the network config GUI (and ifcfg files,
for that matter) let me list specific DNS servers. With this
feature, are those used (and if so, how)? If not, is my configuration
just
On 12.06.2015 18:53, Dan Williams wrote:
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due
On 12.06.2015 19:00, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could add the dns=unbound stuff (which Pavel
contributed) but less on the NM connectivity checking,
On Wed, 17 Jun 2015, Tomas Hozza wrote:
While I don't actually care, this might well be a sticking point for
many people since their DNS information is going to an untrusted (to
them) DNS server. Yeah, I tend to trust Fedora, but not everyone will.
If you don't trust fedora infrastructure,
On Tue, 16 Jun 2015, Bastien Nocera wrote:
That’s what dnssec-trigger ideally _should_ do. What would it _actually_
do, e.g. with the current code?
That's defined by login-command: in /etc/dnssec-trigger/dnssec-trigger.conf
which we did not change from the default xdg-open.
It uses the URL
- Original Message -
On Mon, 15 Jun 2015, Miloslav Trmač wrote:
Detect it and show the sandboxed browser. If that means that the user
has to type their Facebook password again, then the user is welcome to
do that. I don't see why we should make it easier to track users,
On 12.6.2015 16:55, Dan Williams wrote:
On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
NetworkManager is pure network configuration manager in this scenario.
We don't expect nor want NM to handle /etc/resolv.conf. We will
On 12.6.2015 18:53, Dan Williams wrote:
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due
On Mon, 15 Jun 2015, Miloslav Trmač wrote:
Detect it and show the sandboxed browser. If that means that the user
has to type their Facebook password again, then the user is welcome to
do that. I don't see why we should make it easier to track users,
though.
That’s what dnssec-trigger
On 13 June 2015 at 17:10, Michael Catanzaro mcatanz...@gnome.org wrote:
On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
If the captive portal uses the system's DNS, and the system has
cached
www.gnome.org from when you were on a previous network, your captive
portal check might use a
On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
Is the code on how ChromeOS or Android detects captivity part of the
'public' code? It seems to do a 'good' job in finding many captive
portals so might be something to get an idea on how many weird ways
things are out there.
I think everyone
On 15 June 2015 at 13:07, Paul Wouters p...@nohats.ca wrote:
On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
Is the code on how ChromeOS or Android detects captivity part of the
'public' code? It seems to do a 'good' job in finding many captive
portals so might be something to get an idea on
On Mon, Jun 15, 2015 at 12:07 PM, Paul Wouters p...@nohats.ca wrote:
On Mon, 15 Jun 2015, Stephen John Smoogen wrote:
Is the code on how ChromeOS or Android detects captivity part of the
'public' code? It seems to do a 'good' job in finding many captive
portals so might be something to get an
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote:
What would dnssec-trigger do if an attacker^Wlegitimate hotspot provider
deliberately let the hotspot probe lookup and connection through, but kept
redirecting everything else?
Detect it and show the sandboxed
Generally the problem is that resolv.conf is quite limited and cannot express
lot of things, like trust levels and per-domain forwarding (using different
servers for queries related to different domains).
One possibility how to solve this is to port applications to use different
library/API
Hello,
On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
But that's not even right. Suppose you have a captive portal that
wants you to log in via your Google account. It can send you do
On Mon, Jun 15, 2015 at 3:02 PM, Miloslav Trmač m...@redhat.com wrote:
Hello,
On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
But that's not even right. Suppose you have a captive portal that
wants you
Apple (foolishly) used to use something like http://apple.com/hotspot
on their main site itself, which meant that using a VPN on demand could
never protect apple.com because the iphone had to leave that domain out
of the vpn trigger list or else all hotspot detection would be broken. It
seems
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
There is one thing I don't understand. Surely the above is exactly what
will happen if you were to get stuck behind a captive portal with
Firefox or any normal browser? But portals still work reliably for
users.
You should visit more hotels. The
On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
If the captive portal uses the system's DNS, and the system has
cached
www.gnome.org from when you were on a previous network, your captive
portal check might use a cached DNS resolve and try to use an HTTP
connection to a blocked IP
On Jun 13, 2015 4:28 AM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
But that's not even right. Suppose you have a captive portal that
wants you to log in via your Google account. It can send you do
On Fri, 2015-06-12 at 15:49 -0700, Andrew Lutomirski wrote:
But that's not even right. Suppose you have a captive portal that
wants you to log in via your Google account. It can send you do
https://accounts.google.com, and your browser can verify the
certificate and show you an indication
Am 13.06.2015 um 21:01 schrieb Michael Catanzaro:
There is a good reason we started hotspot-nocache.fedoraproject.org.
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build
On Sat, 13 Jun 2015, Michael Catanzaro wrote:
Hm... the captive portal helper loads www.gnome.org but it only runs
after NetworkManager has decided there is a captive portal. We can make
this URL configurable at build time if there's really a problem, but
I'm not sure there is, since it's not
On Sat, 13 Jun 2015, Andrew Lutomirski wrote:
It'd be nice to not show
http://www.gnome.org (the test URL we load, expecting to be hijacked)
if the portal decides not to redirect you to a new URI (not sure how
common that is), but I think we will have to or we can't fix this
It could
On Sat, 2015-06-13 at 14:36 -0400, Paul Wouters wrote:
using www.gnome.org is wrong. For one, you cannot guarantee they
won't
end up using some redirect and than the captive portal would fail.
I don't get it: what is wrong, what would fail? We expect them to
replace the contents of
On 11.06.2015 22:48, Dan Williams wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the various parties to sit down and
On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote:
It wouldn't really have to be Firefox, but getting the browser chrome
right to avoid trivial phishing attacks is critical, and all real
browsers already do that fairly well, whereas the simple embedded web
views (e.g.
On Fri, Jun 12, 2015 at 3:32 PM, Michael Catanzaro mcatanz...@gnome.org wrote:
On Fri, 2015-06-12 at 11:19 -0700, Andrew Lutomirski wrote:
It wouldn't really have to be Firefox, but getting the browser chrome
right to avoid trivial phishing attacks is critical, and all real
browsers already do
On Fri, 12 Jun 2015, Matthew Miller wrote:
Another integration concern: the network config GUI (and ifcfg files,
for that matter) let me list specific DNS servers. With this
feature, are those used (and if so, how)? If not, is my configuration
just silently ignored?
I do not know if it is
On Fri, 2015-06-12 at 09:57 -0400, Paul Wouters wrote:
On Fri, 12 Jun 2015, Matthias Clasen wrote:
I've just installed dnssec-trigger on rawhide to try this out, and
found that it breaks networking on my Workstation. I used to get a
network connection on login, now I get a question mark
On Fri, 2015-06-12 at 10:20 -0400, Matthew Miller wrote:
On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
NetworkManager is pure network configuration manager in this scenario.
We don't expect nor want NM to handle /etc/resolv.conf. We will only get
the current network
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the various parties to sit down and
plan and then program this further.
On 06/12/2015 11:10 AM, Petr Spacek wrote:
HERE we need to coordinate with other parties who might want to write into the
/etc/resolv.conf file. These include (but might not be limited to):
NetworkManager
initscripts
dhclient
libreswan ?
resolved
connman
Option
On Fri, 2015-06-12 at 17:10 +0200, Petr Spacek wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the various
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
On 11.06.2015 22:48, Dan Williams wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly
On Fri, 2015-06-12 at 13:00 -0400, Matthew Miller wrote:
I hope we can get a design for this which integrates better with
GNOME
Shell and the existing network icon there.
Well we're just not going to ship this in Workstation if it breaks
NetworkManager's connectivity checking, nor will we
On 06/12/2015 12:53 PM, Dan Williams wrote:
b) Broken networks:
Some networks are so broken that even without captive portal they are not
able
to deliver DNSSEC data to the clients.
In that case will try tunnel to other DNS servers on the Internet (Fedora
Infra or public DNS root) and use
On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
On Thu, 11 Jun 2015, Dan Williams wrote:
Unfortunately the Proposal doesn't say anything about how this will
actually work, which is something NetworkManager needs to know. It also
fails to address the failure cases where your local
On Fri, Jun 12, 2015 at 11:53:32AM -0500, Dan Williams wrote:
Yeah, we did. From my recollection, most of that focused on the unbound
parts and how NM could add the dns=unbound stuff (which Pavel
contributed) but less on the NM connectivity checking, becuase Fedora
hadn't turned that on by
On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the
On Fri, Jun 12, 2015 at 10:58:14AM +0200, Tomas Hozza wrote:
NetworkManager is pure network configuration manager in this scenario.
We don't expect nor want NM to handle /etc/resolv.conf. We will only get
the current network configuration from it and act upon it. NM
configuration will contain
On Fri, 12 Jun 2015, Matthias Clasen wrote:
I've just installed dnssec-trigger on rawhide to try this out, and
found that it breaks networking on my Workstation. I used to get a
network connection on login, now I get a question mark in top bar, and
a status icon with obsure menu options
On Fri, 2015-06-12 at 12:17 -0500, Dan Williams wrote:
dnssec-trigger prompts the user with a choice of allow insecure
DNS or
cache only mode. The latter means no new DNS and use what's
already
in the cache only.
Yeah, and the interaction story here has been controversial for a
On Fri, 12 Jun 2015, Matthew Miller wrote:
I personally find the anchor icon very confusing. As a non-expert in
this area, it doesn't represent anything which seems relevant to me,
and all of the right click menu options, once I figured out to right
click, are obscure to me.
Agreed.
I don't
On Fri, Jun 12, 2015 at 10:17 AM, Dan Williams d...@redhat.com wrote:
On Fri, 2015-06-12 at 00:48 -0400, Paul Wouters wrote:
2) NM/dnssec-trigger does the HTTP and DNS probing and prompting using
a dedicated container and any DNS requests in that container are
thrown away with the
On Fri, Jun 12, 2015 at 10:33 AM, Dan Williams d...@redhat.com wrote:
On Thu, 2015-06-11 at 14:41 -0700, Andrew Lutomirski wrote:
On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM
On Fri, 12 Jun 2015, Andrew Lutomirski wrote:
All that makes sense. Thanks.
FWIW, I think that a little C program to spin up a namespace that's
good enough to point a stateless Firefox instance at a captive portal
login with overridden DNS nameserver settings would only be a couple
of hundred
On Fri, 12 Jun 2015, Dan Williams wrote:
That is why HTTP redirection and DNS failure have to be detected by
whatever is the hot spot detector. Both items weigh in on triggering
a hotspot logon window.
Agreed. But how does the DNS failure actually get relayed to the thing
doing the HTTP
On Fri, 2015-06-12 at 10:58 +0200, Tomas Hozza wrote:
3. NM waits for some signal from unbound/dnssec-trigger about the
trustability of the DNS server
If you think NM needs to do some action (as I don't), we don't have
problem with notifying NM (if you provide some API).
This is your
On Fri, Jun 12, 2015 at 09:57:38AM -0400, Paul Wouters wrote:
Did your networking actually break, or just the notification icon status?
It will definitely break on F22 without the updated SELinux or SELinux
in permissive mode.
--
Matthew Miller
mat...@fedoraproject.org
Fedora Project Leader
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the various parties to sit down and
plan and then program this further.
On Thu, Jun 11, 2015 at 1:48 PM, Dan Williams d...@redhat.com wrote:
On Tue, 2015-06-09 at 12:30 -0400, Matthew Miller wrote:
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the
On Thu, 11 Jun 2015, Dan Williams wrote:
Unfortunately the Proposal doesn't say anything about how this will
actually work, which is something NetworkManager needs to know. It also
fails to address the failure cases where your local DNS doesn't support
DNSSEC or is otherwise broken here out of
On 11.6.2015 07:39, P J P wrote:
Hello Miloslav,
On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač m...@redhat.com wrote:
We’ve had earlier conversations about whether the resolver being used (local,
remote, container host) is trusted to perform DNSSEC validation. How is this
resolved?
Hello Miloslav,
On Wednesday, 10 June 2015 8:55 PM, Miloslav Trmač m...@redhat.com wrote:
We’ve had earlier conversations about whether the resolver being used (local,
remote, container host) is trusted to perform DNSSEC validation. How is this
resolved? The Change page AFAICS doesn’t say.
Hello,
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
Install a local DNS resolver trusted for the DNSSEC validation running on
127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf.
We’ve
Hello Vit,
On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote:
I hope that I won't need to do this steps manually after F23
installation, otherwise it could be hardly called default. So when
there will be available final version which does not need any additional
configuration available
Dne 9.6.2015 v 13:18 P J P napsal(a):
Hello Vit,
On Tuesday, 9 June 2015 12:22 PM, Vít Ondruch wrote:
I hope that I won't need to do this steps manually after F23
installation, otherwise it could be hardly called default. So when
there will be available final version which does not need
Dne 1.6.2015 v 14:03 Jan Kurik napsal(a):
= Proposed System Wide Change: Default Local DNS Resolver =
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver
The How To Test section now contains a lot of steps such as configure
NM, enable/disable service, but when there will be
On Tue, 9 Jun 2015, Matthew Miller wrote:
One (new!) thing I'm concerned with, now that I've enabled it on my
system, is the persistant tray notification. This is... confusing and
ugly. Can we (for F23 if possible, and F24 if not) get better GNOME
Shell integration here?
That's been on the
On Tue, Jun 09, 2015 at 11:34:39AM -0400, Paul Wouters wrote:
decision needs to then be made by the system. I believe that's been
mostly due to lack of time for the various parties to sit down and
plan and then program this further.
We should try to make that happen.
I see that there's a
On Tue, Jun 09, 2015 at 01:23:22PM +0200, Vít Ondruch wrote:
As per F23 schedule, it's post 28 Jul 2015
- https://fedoraproject.org/wiki/Releases/23/Schedule
That is the latst possible date when it should be definitely available.
I can't see any reason why it should not be possible
On 3.6.2015 10:58, Reindl Harald wrote:
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your network
because you introduce the same negative TTL caching affecting OSX clients
for
years now
Please let me clarify few things:
1)
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your network
because you introduce the same negative TTL caching affecting OSX clients for
years now
Please let me clarify few things:
1) Negative caching is controlled by zone owner.
Am 03.06.2015 um 13:39 schrieb Petr Spacek:
On 3.6.2015 10:58, Reindl Harald wrote:
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your network
because you introduce the same negative TTL caching affecting OSX clients for
years now
On 06/02/2015 08:36 PM, Paul Wouters wrote:
On Tue, 2 Jun 2015, Simo Sorce wrote:
and just because you have a local resolver firefox won't stop it's
behavior
It can, w/o a local resolver FF developers will definitely keep caching
on their own, with a decent local resolver they can allow
On 1.6.2015 20:58, Reindl Harald wrote:
Am 01.06.2015 um 20:30 schrieb Andrew Lutomirski:
On Mon, Jun 1, 2015 at 11:02 AM, Reindl Harald h.rei...@thelounge.net
wrote:
Am 01.06.2015 um 19:55 schrieb Jason L Tibbitts III:
RSB == Ryan S Brown rya...@redhat.com writes:
RSB I disagree; for
On 3.6.2015 12:04, Florian Weimer wrote:
On 06/02/2015 08:36 PM, Paul Wouters wrote:
On Tue, 2 Jun 2015, Simo Sorce wrote:
and just because you have a local resolver firefox won't stop it's
behavior
It can, w/o a local resolver FF developers will definitely keep caching
on their own, with
On Wed, 2015-06-03 at 14:07 +0200, Reindl Harald wrote:
Am 03.06.2015 um 14:02 schrieb Petr Spacek:
On 3.6.2015 13:45, Reindl Harald wrote:
I'm sorry for disappointing you.
The behavior I describe is standard for last ~ 20 years 1987 (RFCs
1034/1035/2308). If you don't agree with
On 3.6.2015 13:45, Reindl Harald wrote:
Am 03.06.2015 um 13:39 schrieb Petr Spacek:
On 3.6.2015 10:58, Reindl Harald wrote:
Am 03.06.2015 um 09:14 schrieb Petr Spacek:
so with setup a dns cache on each and every machine you fuckup your
network
because you introduce the same negative TTL
On Wed, 3 Jun 2015, Petr Spacek wrote:
It is somewhat questionable whether DNS rebinding vulnerabilities are,
in fact, a problem which should be solved at the client side. But
Oh yes. DNS pinning in browser is just a band-aid and not proper solution. I
would argue that DNS rebinding attack
Am 03.06.2015 um 14:02 schrieb Petr Spacek:
On 3.6.2015 13:45, Reindl Harald wrote:
I'm sorry for disappointing you.
The behavior I describe is standard for last ~ 20 years 1987 (RFCs
1034/1035/2308). If you don't agree with standard then you cannot use DNS
technology as standardized. Here
On Wed, 3 Jun 2015, Petr Spacek wrote:
???On 3.6.2015 13:45, Reindl Harald wrote:
If you feel that the standard is broken then *please* continue with discussion
on IETF's dnsop mailing list:
https://www.ietf.org/mailman/listinfo/dnsop
come on stop trolling that way because you know exactly
Le Lun 1 juin 2015 21:25, Reindl Harald a écrit :
surely there are many environments beside mine and *that* is why it's
not smart to consider a local dns cache on each and every server
There are many environments that benefit from a local DNS cache (for
example FAI with flacky DNS, people
On 06/01/2015 10:57 PM, Andrew Lutomirski wrote:
This is glibc we're talking about, though. Have you tried to get a
glibc bug fixed? It's not a pleasant experience.
It is possible, but it requires effort. Admittedly, sometimes that
effort appears disproportionate to what is being fixed.
In
Ryan S. Brown rya...@redhat.com wrote:
I disagree; for server cloud deployments it doesn't make sense to
duplicate a DNS server on *every* host, and if you care about DNSSEC
you likely already run a trusted resolver.
The trust and management models for Server are fundamentally different
On 06/01/2015 09:33 PM, Reindl Harald wrote:
Am 01.06.2015 um 21:28 schrieb Andrew Lutomirski:
On Mon, Jun 1, 2015 at 12:25 PM, Ryan S. Brown rya...@redhat.com wrote:
A local DNS resolver would certainly be a surprise to me. Again, this
comes back to the expectation that a server isn't
On Tue, 2 Jun 2015, Simo Sorce wrote:
and just because you have a local resolver firefox won't stop it's behavior
It can, w/o a local resolver FF developers will definitely keep caching
on their own, with a decent local resolver they can allow themselves to
disable their own and go back to
Am 02.06.2015 um 19:49 schrieb Simo Sorce:
On Mon, 2015-06-01 at 23:15 +0200, Reindl Harald wrote:
a sane system should be as simple as possible so that *one* human is
able to determine what is happening without hire 10 specialists for
each
layer
There is no human able to understand a
On 06/02/2015 06:44 PM, Paul Wouters wrote:
On Tue, 2 Jun 2015, David Howells wrote:
Install a local DNS resolver trusted for the DNSSEC validation
running on
127.0.0.1:53. This must be the only name server entry in
/etc/resolv.conf.
The automatic name server entries received via
1 - 100 of 138 matches
Mail list logo
