>
> > 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
# Fedora Quality Assurance Meeting
# Date: 2014-04-14
# Time: 15:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net
Greetings testers!
It's meeting time again on Monday! Let's check in.
== Proposed Agenda Topics ==
1. Previous meeting
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 11/04/14 21:54, Richard W.M. Jones wrote:
On Thu, Apr 10, 2014 at 06:13:42PM +0100, Andrew Price wrote:
On 10/04/14 17:05, Bill Nottingham wrote:
James Antill (ja...@fedoraproject.org) said:
Not that I assume splitting lanauges and docs. into sub packages would
triple primary numbers, but
On Thu, Apr 10, 2014 at 2:30 AM, Daniel P. Berrange wrote:
> On Wed, Apr 09, 2014 at 10:20:36PM +0200, Lennart Poettering wrote:
>>
>> This sounds entirely backwards, and I'd instead vote for removing
>> securetty from the PAM stacks we ship altogether. The concept is
>> outdated. It was useful in
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 11:41:48AM +0200, Zoltan Boszormenyi wrote:
> Any project I tried with
>./configure CFLAGS="-fsanitize=undefined -fsanitize=address"
> fails with:
>
> checking for gcc... gcc
> checking whether the C compiler works... no
>
> config.log reveals that libasan.so and libub
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
2014-04-10 19:38 keltezéssel, Orion Poplawski írta:
On 04/10/2014 04:23 AM, Jakub Jelinek wrote:
Hi!
FYI, gcc in rawhide has been upgraded to 4.9.0 prerelease,
please visit http://gcc.gnu.org/gcc-4.9/porting_to.html if your
package no longer builds. To investigate runtime rather than compile t
> 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.
> >
> >
50 matches
Mail list logo
