On Sun, 13 Jul 2014, quickbooks office wrote:
DNS over SSL does NOT work - I get no connectivity whatsoever after
following the below steps. Tracking bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1119050
Can you please tell me what am I doing wrong?
There seems to be some regression with
DNS over SSL does NOT work - I get no connectivity whatsoever after
following the below steps. Tracking bug at
https://bugzilla.redhat.com/show_bug.cgi?id=1119050
Can you please tell me what am I doing wrong?
@ https://fedoraproject.org/wiki/Test_Day:2012-12-11_Network_Manager_and_DNSSEC
it say
On 25.4.2014 18:19, Simo Sorce wrote:
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
On Thu, 10 Apr 2014 10:41:54 -0400
Chuck Anderson wrote:
[...] We need an independent,
system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
solve this fundamental design problem with h
On Fri, 2014-04-25 at 09:56 -0600, Pete Zaitcev wrote:
> On Thu, 10 Apr 2014 10:41:54 -0400
> Chuck Anderson wrote:
>
> > [...] We need an independent,
> > system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> > solve this fundamental design problem with how name resolution works
On Thu, 10 Apr 2014 10:41:54 -0400
Chuck Anderson wrote:
> [...] We need an independent,
> system-wide DNS cache, and always point resolv.conf to 127.0.0.1 to
> solve this fundamental design problem with how name resolution works
> on a Linux system. Windows has had a default system-wide DNS ca
Hi,
> On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote:
> We need real data.
Please see -> https://www.piratepad.ca/p/dnssec-requisites-configurations
I've collected the major functionalities people wish to have with a default DNS
resolver along with couple of 'unbound' configurations th
Hello Petr,
> On Tuesday, 15 April 2014 4:02 PM, Petr Spacek wrote:
> Instructions for testing on Fedora 20+ are available on:
> https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver#How_To_Test
>
> Please, run dnssec-trigger and let exclamations like "It can't possibly
> work!"
On 12.4.2014 17:25, Reindl Harald wrote:
Am 12.04.2014 17:11, schrieb Paul Wouters:
On Sat, 12 Apr 2014, Reindl Harald wrote:
"we" should not do anything - because "we" don't have a clue about the
network of the enduser
We know and handle a lot more than you think already using unbound with
On Mon, 14 Apr 2014, Juan Orti Alcaine wrote:
One thing I would like to note is that in machines which don't have a
hardware clock, I had problems starting bind and unbound, because the date
was back to 1970 in each boot, so the root dns key was not yet valid and
there were no valid dns resolv
On Mon, Apr 14, 2014 at 9:06 AM, Dan Williams wrote:
> On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote:
>> On Mon, 14 Apr 2014, Dan Williams wrote:
>>
>> > But another scenario I've seen: older Netgear routers which intercept
>> > "www.routerlogin.net" as the setup page. The instructions l
On Mon, 14 Apr 2014, Dan Williams wrote:
Ok, that could be a problem. This is a user setting up wifi on a router
they just bought, so it has no upstream connection yet, is not yet
configured at all, and they are just following the directions in the
printed brochure they got with the router. Wh
On Tue, 15 Apr 2014, William Brown wrote:
How do you setup DNS over TLS?
Unbound has this capability already build in. unbound-control activates
via (currently via dnssec-triggerd, in the future via NM) using the
keywords tcp-upstream or ssl-upstream.
I meant for say bind, but okay.
bind d
On Mon, 2014-04-14 at 12:00 -0400, Paul Wouters wrote:
> On Mon, 14 Apr 2014, Dan Williams wrote:
>
> > But another scenario I've seen: older Netgear routers which intercept
> > "www.routerlogin.net" as the setup page. The instructions literally
> > are:
> >
> > 1) connect your computer to the r
On Mon, 14 Apr 2014, Dan Williams wrote:
But another scenario I've seen: older Netgear routers which intercept
"www.routerlogin.net" as the setup page. The instructions literally
are:
1) connect your computer to the router with a cable
2) go to www.routerlogin.net
3) follow the setup guide in
On Mon, 2014-04-14 at 10:21 -0400, Paul Wouters wrote:
> > Or how would you suggest this is solved. For arguments sake lets
> > say:
> >
> > SSID: myawesomeopenhotspot
> > DHCP provides no domain-name info.
> > I CNAME all records to my.hotspot. until authenticated.
>
> If this does not do http(s)
>
> >> unbound does not really care about transparent proxy's on port 53. As
> >> long as they don't break DNS (and DNSSEC). If they redirect port 53 to
> >> some broken DNS server, unbound will try to work around it. If port 53
> >> is broken it will attempt DNS over port 80 of various fedorapro
On Mon, 14 Apr 2014, William Brown wrote:
This seems like a sane(ish) method of doing this. What happens if the
hotspot page is down? Why not use a mirror-like setup with yum where you
try 2 or 3 mirrors and if they fail then you declare it to be a portal?
It has multiple A records matching th
On Mon, Apr 14, 2014 at 02:07:07PM +0200, Juan Orti Alcaine wrote:
> One thing I would like to note is that in machines which don't have
> a hardware clock, I had problems starting bind and unbound, because
> the date was back to 1970 in each boot, so the root dns key was not
> yet valid and there
One thing I would like to note is that in machines which don't have a
hardware clock, I had problems starting bind and unbound, because the
date was back to 1970 in each boot, so the root dns key was not yet
valid and there were no valid dns resolvers to update time by ntp. I had
to hardcode so
On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote:
> On Mon, 14 Apr 2014, William Brown wrote:
>
> > What is a "captivity-sign" as you so put it?
>
> Check for clean port 80. It fetches the url specified in
> dnssec-triggerd.conf's url: option
> (default http://fedoraproject.org/static/hotspo
On Mon, 14 Apr 2014, William Brown wrote:
What is a "captivity-sign" as you so put it?
Check for clean port 80. It fetches the url specified in
dnssec-triggerd.conf's url: option
(default http://fedoraproject.org/static/hotspot.txt)
If it returns a redirect or a page that does not contain the
> > But you can't account for every captive portal in the world. This is why
> > the cache is a bad idea, because you can't possibly account for every
> > system that is captive like this.
>
> Yes we can by monitoring for "captivity signs" when a new network is
> joined. Again, please yum install
On Sun, Apr 13, 2014 at 10:18 AM, Richard W.M. Jones
wrote:
Unfortunately NetworkManager can't handle brief network outages
without dropping the connection (RHBZ#1022954 comment 3). This isn't
desirable for servers that have ethernet and fixed IP addresses.
NetworkManager-config-server fixes
On Sun, 13 Apr 2014, Richard W.M. Jones wrote:
So you've gone out of your way to run a daemon but prevent it from
working as configured, instead of just reconfiguring it to do what you
need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixed IP address.
NM developer and never even contributed to the project with
patches (yet).
You don't like it, fine, but let's not come up with the old trite
anecdata every time someone mentions NM, it's not useful and derails the
conversation to useless bikeshedding.
I'd rather go back to th
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
> On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> >
> > > A system wide resolver I am not opposed to. I am against a system wide
> > > *caching* resolver.
> >
> > > In this
On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
> So you've gone out of your way to run a daemon but prevent it from
> working as configured, instead of just reconfiguring it to do what you
> need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixe
On Sun, 2014-04-13 at 16:29 +0930, William Brown wrote:
> > That depends. You need caching for DNSSEC validation, so really,
> every
> > device needs a cache, unless you want to outsource your DNSSEC
> > validation over an insecure transport (LAN). That seems like a very
> bad
> > idea.
>
> If you
On Sun, 13 Apr 2014, William Brown wrote:
PS: It also seemed like the proposal was to *bypass* the networks
provided forwarders from DHCP. This *is* a serious issue if it's the
case.
We only bypass DHCP provided forwarders that are broken. We actually
WANT to use them as much as possible, beca
On Sun, 13 Apr 2014, William Brown wrote:
Yes. It depends on the "trustworthiness" of the network and or
preconfiguration of some of your own networks you join.
Not really: Every network you join, you have to semi-trust. If you don't
trust it, why did you join it?
You don't always control wh
william wrote:
> [...]
> Internal and external zone views in a business. These records may
> different, and so would need flushing between network interface state
> changes.
Sure, let's make it easy to restart the cache upon such transitions.
> Additionally, local DNS caches may issues and dela
William Brown wrote:
>In businesses, it's also common place to have a low-ish ttl (Say 5
>minutes) and when a system is migrated, they swap the A/ records to
>the new system. The dns servers on the network are updated, but the
>workstation has the old record cached. Without a local cache, they
William Brown wrote:
>> The cache is never fully flushed. It is only flushed for the domain
>> obtained via DHCP or VPN, because those entries can change. They are
>> not changed for anything else. If the upstream ISP could have
>> spoofed them, so be it - the publisher of the domains could have
>>
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
> On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> >
> > > A system wide resolver I am not opposed to. I am against a system wide
> > > *caching* resolver.
> >
> > > In this
On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
>
> > A system wide resolver I am not opposed to. I am against a system wide
> > *caching* resolver.
>
> > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
> > c
>
> > Proposal is to add a local caching DNS server to fedora systems. This
> > may or may not accept a DHCP provided forwarder(?).
>
> Yes. It depends on the "trustworthiness" of the network and or
> preconfiguration of some of your own networks you join.
Not really: Every network you join, yo
Am 13.04.2014 08:42, schrieb Simo Sorce:
* DNS cache should be flushed on route or interface state change.
>
> I do not see why, the only reason to flush a cache is when there is a
> DNS change (new interface, eg VPN coming up, or going away)
because if i change my routing from ISP to VPN i
On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> A system wide resolver I am not opposed to. I am against a system wide
> *caching* resolver.
> In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
> cache is a severe detriment.
About the above 2, can you explain *w
On Sun, 2014-04-13 at 00:52 -0400, Felix Miata wrote:
> On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed:
> > On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:
> >> I've been doing that myself for years on installations that think my
> >> ethernet-only non-wireless LAN host connections need "
On Sun, 2014-04-13 at 06:35 +0200, Reindl Harald wrote:
> and if you believe that in a not trustable network you don't
> know if you get the signing informations at all - fine, but
> you hardly an enforce that with a local software
That is the WHOLE point of DNSSEC, really.
> if i control the ne
On Sat, 2014-04-12 at 17:46 -0700, Andrew Lutomirski wrote:
> On Sat, Apr 12, 2014 at 5:18 PM, William Brown
> wrote:
> >
> >> Now can we go back to actually discussion technical arguments again?
> >
> > Actually no.
> >
> > This whole thread has forgotten one major thing ... use cases.
> >
> > P
On 2014-04-12 16:12 (GMT-0400) Simo Sorce composed:
On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:
On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed:
> Chuck Anderson wrote:
>> Maybe we should set the file to be immutable after setting it to 127.0.0.1:
>> chattr +i /etc/res
Am 13.04.2014 03:07, schrieb Paul Wouters:
> On Sun, 13 Apr 2014, William Brown wrote:
>> When they change records in their local zones, they don't want
>> to have to flush caches etc. If their ISP is unreliable, or their own
>> DNS is unreliable, a DNS cache will potentially mask this issue dela
On Sun, 13 Apr 2014, William Brown wrote:
Now can we go back to actually discussion technical arguments again?
Actually no.
This whole thread has forgotten one major thing ... use cases.
That was in response to someone using appeal of authority statements, not
factual discussions.
Proposa
On Sat, Apr 12, 2014 at 5:18 PM, William Brown wrote:
>
>> Now can we go back to actually discussion technical arguments again?
>
> Actually no.
>
> This whole thread has forgotten one major thing ... use cases.
>
> Proposal is to add a local caching DNS server to fedora systems. This
> may or may
> Now can we go back to actually discussion technical arguments again?
Actually no.
This whole thread has forgotten one major thing ... use cases.
Proposal is to add a local caching DNS server to fedora systems. This
may or may not accept a DHCP provided forwarder(?).
Case 1: Standard home
On Sat, 2014-04-12 at 13:11 -0400, Felix Miata wrote:
> On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed:
>
> > Chuck Anderson wrote:
>
> >> Maybe we should set the file to be immutable after setting it to 127.0.0.1:
>
> >> chattr +i /etc/resolv.conf
>
> > That is the trick currently used b
On Sat, 2014-04-12 at 13:04 -0400, Chuck Anderson wrote:
> On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote:
> > On Sat, 12 Apr 2014, Chuck Anderson wrote:
> >
> > >Okay, so here is where you and I differ then. We need a solution to
> > >run everywhere, on every system, in every use c
On 2014-04-12 11:01 (GMT-0400) Paul Wouters composed:
Chuck Anderson wrote:
Maybe we should set the file to be immutable after setting it to 127.0.0.1:
chattr +i /etc/resolv.conf
That is the trick currently used by dnssec-triggerd to prevent other
applications from messing with that fil
On Sat, Apr 12, 2014 at 12:06:23PM -0400, Paul Wouters wrote:
> On Sat, 12 Apr 2014, Chuck Anderson wrote:
>
> >Okay, so here is where you and I differ then. We need a solution to
> >run everywhere, on every system, in every use case.
>
> Sounds like wanting ponies? Obviously I fully agree with
On Sat, 12 Apr 2014, Chuck Anderson wrote:
Okay, so here is where you and I differ then. We need a solution to
run everywhere, on every system, in every use case.
Sounds like wanting ponies? Obviously I fully agree with a solution that
works everywhere, all the time, for everyone, however the
On Sat, Apr 12, 2014 at 04:40:50PM +0100, Richard W.M. Jones wrote:
> On Sat, Apr 12, 2014 at 11:01:20AM -0400, Paul Wouters wrote:
> > On Sat, 12 Apr 2014, Chuck Anderson wrote:
> > >Maybe we should set the file to be immutable after setting it to 127.0.0.1:
> > >
> > >chattr +i /etc/resolv.conf
>
On Sat, Apr 12, 2014 at 11:05:21AM -0400, Paul Wouters wrote:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
>
> >nonsense - there are so much ISP nameservers broken out there
> >responding with wildcards and so on that you can not trust them
> >and you will realize that if not before after you start
On Sat, 12 Apr 2014, Richard W.M. Jones wrote:
chattr +i /etc/resolv.conf
That is the trick currently used by dnssec-triggerd to prevent other
applications from messing with that file.
Oh crap, that means I'm going to need a "really really don't touch
this file" flag, perhaps a one-way flag
On Sat, Apr 12, 2014 at 11:01:20AM -0400, Paul Wouters wrote:
> On Sat, 12 Apr 2014, Chuck Anderson wrote:
> >Maybe we should set the file to be immutable after setting it to 127.0.0.1:
> >
> >chattr +i /etc/resolv.conf
>
> That is the trick currently used by dnssec-triggerd to prevent other
> app
Am 12.04.2014 17:21, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
>
>>> That's wrong. a DNS server can use a forwareder for some or all of its
>>> recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
>>> full recursion but using the ISP nameserver as forward
Am 12.04.2014 17:11, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
>
>> "we" should not do anything - because "we" don't have a clue about the
>> network of the enduser
>
> We know and handle a lot more than you think already using unbound with
> dnssec-trigger and VPNs. Why
On Sat, 12 Apr 2014, Reindl Harald wrote:
That's wrong. a DNS server can use a forwareder for some or all of its
recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
full recursion but using the ISP nameserver as forward for all queries.
oh no - please try to understand what r
Am 12.04.2014 17:05, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
>
>> nonsense - there are so much ISP nameservers broken out there
>> responding with wildcards and so on that you can not trust them
>> and you will realize that if not before after you started to run
>> a pr
On Sat, 12 Apr 2014, Reindl Harald wrote:
"we" should not do anything - because "we" don't have a clue about the
network of the enduser
We know and handle a lot more than you think already using unbound with
dnssec-trigger and VPNs. Why don't you give it a shot and give us some
feedback on how
On Sat, 12 Apr 2014, Chuck Anderson wrote:
I don't disagree that there is lots of broken DNS out there. But
realistically, we still need to default to using the DHCP-provided DNS
servers as forwarders because there are unfortunately lots of
circumstances where this is required to resolve corpor
On Sat, 12 Apr 2014, Reindl Harald wrote:
nonsense - there are so much ISP nameservers broken out there
responding with wildcards and so on that you can not trust them
and you will realize that if not before after you started to run
a production mailserver which relies on NXDOMAIN responses for
Am 12.04.2014 16:55, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
>
>> a DNS server doing recursion don't ask any forwarder
>
> That's wrong. a DNS server can use a forwareder for some or all of its
> recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
> f
On Sat, 12 Apr 2014, Chuck Anderson wrote:
I'm proposing that /etc/resolv.conf is never re-written under any
circumstances. A local caching resolver should ALWAYS be used and
resolv.conf should ALWAYS say:
nameserver 127.0.0.1
Cheers. That's a goal I share with you, but...
All the "magic"
On Sat, 12 Apr 2014, Reindl Harald wrote:
a DNS server doing recursion don't ask any forwarder
That's wrong. a DNS server can use a forwareder for some or all of its
recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
full recursion but using the ISP nameserver as forward for
On Sat, 12 Apr 2014, William Brown wrote:
I should clarify. I cache the record foo.work.com from the office, and
it resolves differently externally. When I go home, it no longer
resolves to the external IP as I'm using the internally acquired record
from cache.
This currently works for the VPN
Am 12.04.2014 16:16, schrieb Chuck Anderson:
> On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote:
>> Am 12.04.2014 15:31, schrieb Chuck Anderson:
>>> I disagree. You can still do DNSSEC validation with a local caching
>>> resolver and configure that local resolver to forward all queri
On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote:
>
>
> Am 12.04.2014 15:31, schrieb Chuck Anderson:
> > On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:
> >>> On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
> >>> Say I have freshly installed my fedora system at home.
On Sat, Apr 12, 2014 at 09:38:03 -0400,
Chuck Anderson wrote:
You cannot rely on DNS2 and DNS3 to be queried UNLESS DNS1=127.0.0.1
fails to respond. This might be a way to mitigate failure of the
local caching resolver process, but it is not a way to ensure the
ability to resolve internal na
Am 12.04.2014 15:31, schrieb Chuck Anderson:
> On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:
>>> On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
>>> Say I have freshly installed my fedora system at home. I then boot it up
>>> and start to use it. My laptop is caching DNS result
On Sat, Apr 12, 2014 at 12:38:41PM +0930, William Brown wrote:
> I agree with the goal to add DNSSEC (Despite it's flaws). However, a
> caching DNS server can create many headaches without a number of
> considerations.
>
> First, it should be easily possible to clear / invalidate the cache for
> a
On Sat, Apr 12, 2014 at 01:22:32PM +0800, P J P wrote:
> > On Saturday, 12 April 2014 7:38 AM, Simo Sorce wrote:
> > Not true, in many networks you want it, for example in corporate
> > networks. You really want to be able to resolve the local resources and
> > they are only resolvable if you consu
On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:
> > On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
> > Say I have freshly installed my fedora system at home. I then boot it up
> > and start to use it. My laptop is caching DNS results all the while from
> > the "unreliable" ISP.
>
On Fri, Apr 11, 2014 at 10:44:31PM -0400, Paul Wouters wrote:
> On Fri, 11 Apr 2014, Simo Sorce wrote:
>
> >>I hope the NM integration will show up at some point. It's really a
> >>pretty nice setup.
> >
> >I am using it too successfully. Only occasionally unbound seem to get
> >confused, not clea
> On Saturday, 12 April 2014 4:55 PM, William Brown wrote:
> This isn't how DNS works . You populate your cache from the ISP, who
> queries above them and so on up to the root server.
> http://technet.microsoft.com/en-us/library/cc961401.aspx
Hmmn. There are two ways a local resolver can b
Am 12.04.2014 13:25, schrieb William Brown:
>>> Consider, I get home, and open my laptop. Cache is cleared,
>>> and I'm now populating that cache with the contents from the ISP.
>>
>> No, why contents from ISP? Local resolver will populate cache from root
>> servers, no?
>
> This isn't how DNS
>
> > Consider, I get home, and open my laptop. Cache is cleared,
> > and I'm now populating that cache with the contents from the ISP.
>
> No, why contents from ISP? Local resolver will populate cache from root
> servers, no?
This isn't how DNS works . You populate your cache from the I
> On Saturday, 12 April 2014 12:41 PM, William Brown wrote:
> PS: The unreliable ISP I perceive as:
> 1) They often return no query within an acceptable time period
> 2) They return invalid or incorrect zone data
> 3) They mess with TTLs or other zone data
Right.
> Consider, I get home, and ope
On Sat, 2014-04-12 at 14:09 +0800, P J P wrote:
> > On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
> > Say I have freshly installed my fedora system at home. I then boot it up
> > and start to use it. My laptop is caching DNS results all the while from
> > the "unreliable" ISP.
> >
PS:
On Sat, 2014-04-12 at 14:09 +0800, P J P wrote:
> > On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
> > Say I have freshly installed my fedora system at home. I then boot it up
> > and start to use it. My laptop is caching DNS results all the while from
> > the "unreliable" ISP.
> >
> >
> On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
> Say I have freshly installed my fedora system at home. I then boot it up
> and start to use it. My laptop is caching DNS results all the while from
> the "unreliable" ISP.
>
> I then go to work and suddenly things don't work.
>
> Havin
On Sat, Apr 12, 2014 at 15:11:35 +0930,
William Brown wrote:
That makes no sense.
Say I have freshly installed my fedora system at home. I then boot it up
and start to use it. My laptop is caching DNS results all the while from
the "unreliable" ISP.
I then go to work and suddenly things don
On Sat, 2014-04-12 at 13:35 +0800, P J P wrote:
> > On Saturday, 12 April 2014 10:33 AM, P J P wrote:
> > >> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:>
> >> It's rude to bypass the global DNS caching infrastructure. That would
> >> significantly load people's DNS servers with more qu
> On Saturday, 12 April 2014 10:33 AM, P J P wrote:
> >> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:>
>> It's rude to bypass the global DNS caching infrastructure. That would
>> significantly load people's DNS servers with more queries. There is no
>> reason not to try and use ISP's DN
> On Saturday, 12 April 2014 7:38 AM, Simo Sorce wrote:
> Not true, in many networks you want it, for example in corporate
> networks. You really want to be able to resolve the local resources and
> they are only resolvable if you consult the local DNS as provided to you
> by DHCP.
True. The loc
> On Saturday, 12 April 2014 3:55 AM, Chuck Anderson wrote:
> I think there needs to be more emphasis on the /other/ benefit, the
> whole reason I brought this up this time:
Sure; I tried to cover it in the detailed description as
===
...Apart from trust, these name servers are often known to b
Hello Kevin, Paul
> On Saturday, 12 April 2014 2:16 AM, Kevin Fenzi wrote:
>> I've been running this solution on fedora for about five years now. It
>> works reasonably well, and anyone who is on this list surely has could
>> try it out. Because of lack of NM integration I would not call it
>>
> On Saturday, 12 April 2014 2:13 AM, Paul Wouters wrote:>
> It's rude to bypass the global DNS caching infrastructure. That would
> significantly load people's DNS servers with more queries. There is no
> reason not to try and use ISP's DNS caches.
You mean let local resolver forward queries t
On Sat, 2014-04-12 at 02:33 +0800, P J P wrote:
> Hello,
>
> > On Thursday, 10 April 2014 11:39 PM, P J P wrote:
> > I plan to file a feature/change request for this one. I got caught up with
> > other
> > work this past week so could not do it. Will start with it right away.
>
> Please se
On Fri, 11 Apr 2014, Simo Sorce wrote:
I hope the NM integration will show up at some point. It's really a
pretty nice setup.
I am using it too successfully. Only occasionally unbound seem to get
confused, not clear when, it doesn't happen more than twice a month and
systemctl restart unbound.
On Fri, 2014-04-11 at 14:45 -0600, Kevin Fenzi wrote:
> On Fri, 11 Apr 2014 16:39:34 -0400 (EDT)
> Paul Wouters wrote:
>
> ...snip...
>
> > I've been running this solution on fedora for about five years now. It
> > works reasonably well, and anyone who is on this list surely has could
> > try it
On Fri, 2014-04-11 at 15:22 -0500, Bruno Wolff III wrote:
> On Fri, Apr 11, 2014 at 14:21:30 -0500,
>Dan Williams wrote:
> >
> >NM in F20+ already has a "dns=none" option that prevents NM from
> >touching resolv.conf, but obviously if NM isn't touching it, the DNS
> >information that NM gets f
On Fri, 11 Apr 2014, Bruno Wolff III wrote:
Second, I still don't understand the point. Are you suggesting it is
better to believe all DNS lies than to not know where the lies lead?
Not better. That DNSSEC doesn't really solve everythin one might want it to.
And hence one might want to avoid
On Fri, Apr 11, 2014 at 18:44:21 -0400,
Paul Wouters wrote:
First, TTLs you receive from a forwarder can always be manipulated, even
with DNSSEC - otherwise caching wouldn't work.
Second, I still don't understand the point. Are you suggesting it is
better to believe all DNS lies than to not
On Fri, 11 Apr 2014, Bruno Wolff III wrote:
I'm not sure what you are trying to say here.
It was a comment about ISPs changing TTLs (or other things). DNSSEC can be
used to tell you the data might not be authoritative, but doesn't tell you
what the correct information is.
First, TTLs you r
On Sat, Apr 12, 2014 at 02:33:59AM +0800, P J P wrote:
> Hello,
>
> > On Thursday, 10 April 2014 11:39 PM, P J P wrote:
> > I plan to file a feature/change request for this one. I got caught up with
> > other
> > work this past week so could not do it. Will start with it right away.
>
> Pl
On Fri, 2014-04-11 at 14:45 -0600, Kevin Fenzi wrote:
> On Fri, 11 Apr 2014 16:39:34 -0400 (EDT)
> Paul Wouters wrote:
>
> ...snip...
>
> > I've been running this solution on fedora for about five years now. It
> > works reasonably well, and anyone who is on this list surely has could
> > try it
On Fri, Apr 11, 2014 at 17:46:29 -0400,
Paul Wouters wrote:
I'm not sure what you are trying to say here.
It was a comment about ISPs changing TTLs (or other things). DNSSEC can
be used to tell you the data might not be authoritative, but doesn't tell
you what the correct information is.
On Fri, 11 Apr 2014, Bruno Wolff III wrote:
If you don't know there is an exception for a domain (eg at the other
end of a VPN) than you will get the public answers and might not get
where you need to go. Additionally, with DNSSEC there is the problem
that the public view cryptographically prove
On Fri, 11 Apr 2014, Chris Adams wrote:
Once upon a time, Bruno Wolff III said:
The advantage of using your dns server is that you know what you're
getting.
You'll also lose almost all content-delivery network advantages (most of
that is mapped to "close" servers with DNS).
Another reason
1 - 100 of 130 matches
Mail list logo
