> On 8 Mar 2024, at 07:39, Michael D. Setzer II via users
> wrote:
>
> Long ago use to use multiple name servers including 8.8.8.8, but
> then at somepoint it changed to the 127.0.0.53 thing.
That means that systemd-resolved is being used.
Have you configured systemd-resolved?
That is where y
Currently in Nevada accessing 4 of my computers back in Guam.
Has been working fine, until earlier today.
VNC into the machines using same name of router, but different
ports mapped to machines.
Generally login to each one, and then next with no problem.
But today, got error messages that couldn
Tim wrote:
> Realising you don't really want two configurations to have to do, but
> if it's your intention that *some* things should use 127.0.0.1, and
> other things should not, then I think you're stuck having to *manage*
> that.
I'm on the trail of a possible solution. Further ideas welcome.
as the nameserver
>> address for these machines.
>>
>> Of course, that is also what kickstart is told when it connects and
>> begins operation. But, of course, kickstart is not running a local
>> nameserver. This means that name resolution for the "repo&quo
Allegedly, on or about 06 October 2014, CLOSE Dave sent:
> The difficulty is that, during kickstart the DHCP configuration is
> wrong. I'd much rather not have to use a different configuration for
> kickstart than for normal operation. While I can do that for an
> initial installation, it is far tr
also what kickstart is told when it connects and
> begins operation. But, of course, kickstart is not running a local
> nameserver. This means that name resolution for the "repo" lines in
> the kickstart file doesn't work and installations fail.
>
> The only work
s for
> these machines.
>
> Of course, that is also what kickstart is told when it connects and
> begins operation. But, of course, kickstart is not running a local
> nameserver. This means that name resolution for the "repo" lines in the
> kickstart file doesn&#x
en it connects and
begins operation. But, of course, kickstart is not running a local
nameserver. This means that name resolution for the "repo" lines in the
kickstart file doesn't work and installations fail.
The only workaround I've found is to use IP addresses in the "re
On 6 July 2011 15:24, Patrick O'Callaghan wrote:
> On Tue, 2011-07-05 at 23:32 -0400, Genes MailLists wrote:
>> On 07/05/2011 11:23 PM, 夜神 岩男 wrote:
>>
>> >
>> > The footprint of a user by Google's way of doing things is quite a bit
>> > larger than cookies or IP tracking. They do not rely on any
On Tue, 2011-07-05 at 23:32 -0400, Genes MailLists wrote:
> On 07/05/2011 11:23 PM, 夜神 岩男 wrote:
>
> >
> > The footprint of a user by Google's way of doing things is quite a bit
> > larger than cookies or IP tracking. They do not rely on any one set of
>
> >
>
> This conspiracy opinion stuff
On Tue, 2011-07-05 at 22:55 -0400, Tom H wrote:
> So, until there's an official complaint of some sort in this regard,
> you're just spreading FUD - unless you have a relevant URL to a valid
> news report.
i.e. Do not query that something may be happening, until someone else
says so...
--
[tim@l
On 07/05/2011 11:23 PM, 夜神 岩男 wrote:
>
> The footprint of a user by Google's way of doing things is quite a bit
> larger than cookies or IP tracking. They do not rely on any one set of
>
This conspiracy opinion stuff has nothing to do with fedora - please
take this discussion out of the mail
On Tue, 2011-07-05 at 13:28 -0700, Joe Zeff wrote:
> On 07/05/2011 11:31 AM, 夜神 岩男 wrote:
> > DNS query history would be the single most potent addition to Google's
> > profiling tags (as in naked profiling, on subjects who are not logged in
> > to a Google service or accepting tracking cookies or
2011/7/5 夜神 岩男 :
>
>> >> yeah... I just can't be bothered to set up BIND. That's what things like
>> >> Google Public DNS is for. :D
>> >
>> > No, the purpose of Google Public DNS is to give Google insight into
>> > every network query you make. Your filterbubble is heavily influenced by
>> > your
夜神 岩男:
>> DNS query history would be the single most potent addition to Google's
>> profiling tags (as in naked profiling, on subjects who are not logged in
>> to a Google service or accepting tracking cookies or other devices).
Joe Zeff:
> How do they keep track of people like me who have dynamic
On 07/05/2011 11:31 AM, 夜神 岩男 wrote:
> DNS query history would be the single most potent addition to Google's
> profiling tags (as in naked profiling, on subjects who are not logged in
> to a Google service or accepting tracking cookies or other devices).
How do they keep track of people like me w
On Wed, 2011-07-06 at 03:31 +0900, 夜神 岩男 wrote:
> The filter bubble issue is very real. If you and I do a search on
> Google for any given string, logged in to a Google account of any sort
> or not, we will receive different results. This is a fact.
Something they can do perfectly easily with cook
Joe Zeff zeff.us> writes:
>
> On 07/05/2011 07:40 AM, JB wrote:
> > Not only that !
> > She claimed to have smoked but not inhaled too ...
>
> Obviously you've never smoked either a pipe or a cigar. The only form
> of tobacco you inhale is a cigarette.
>
> Oh, wait, you probably weren't tal
On 07/05/2011 07:40 AM, JB wrote:
> Not only that !
> She claimed to have smoked but not inhaled too ... :-)
Obviously you've never smoked either a pipe or a cigar. The only form
of tobacco you inhale is a cigarette.
Oh, wait, you probably weren't talking about tobacco, were you? Never mind!
-
> >> yeah... I just can't be bothered to set up BIND. That's what things like
> >> Google Public DNS is for. :D
> >
> > No, the purpose of Google Public DNS is to give Google insight into
> > every network query you make. Your filterbubble is heavily influenced by
> > your history record in Google
On Tue, 05 Jul 2011 20:45:13 +0900
夜神 岩男 wrote:
...
> Your filterbubble is heavily influenced
> by your history record in Google's DNS system if you have dodged the
> other ways of tracking.
>
> http://dontbubble.us/
...
ixquick ( https://www.ixquick.com/ ) is another privacy search option.
It
Am 05.07.2011 17:17, schrieb John Aldrich:
> On Tue July 5 2011, 夜神 岩男 wrote:
>>
>> No, the purpose of Google Public DNS is to give Google insight into
>> every network query you make. Your filterbubble is heavily influenced by
>> your history record in Google's DNS system if you have dodged the
On Tue July 5 2011, 夜神 岩男 wrote:
> No, the purpose of Google Public DNS is to give Google insight into
> every network query you make. Your filterbubble is heavily influenced by
> your history record in Google's DNS system if you have dodged the other
> ways of tracking. This sort of profiling goe
On Tue July 5 2011, 夜神 岩男 wrote:
>
> No, the purpose of Google Public DNS is to give Google insight into
> every network query you make. Your filterbubble is heavily influenced by
> your history record in Google's DNS system if you have dodged the other
> ways of tracking. This sort of profiling g
Tim yahoo.com.au> writes:
> ...
> Want an example? There's the president who "did not have sex with that
> woman." Well, he apparently did have some sexually intimate relations,
> just not conjoined genitals. So the denial is correct, but incorrect.
> ...
Not only that !
She claimed to have
On Tue, 2011-07-05 at 08:16 -0400, Tom H wrote:
> Do you have any proof that Google's using queries to its Public DNS
> service to profile anyone (in spite of its FAQ clarifying that it
> isn't)?
I'd certainly have my doubts. I tend to have little faith in the public
declarations of what corporat
Tim:
>> I run my own DNS server, for a similar reason: Every ISP I've tried
>> has a crappy DNS server. Before I did that, I had to put some
>> domain's IP into my hosts file, because their DNS server usually gave
>> no answer.
John Aldrich:
> yeah... I just can't be bothered to set up BIND. Tha
On 07/05/2011 08:16 AM, Tom H wrote:
>>
>> http://dontbubble.us/
>>
>> Avoiding Google entirely has brought a great deal of standardization and
>> rationality back to my organization -- that we didn't realize was
>> beginning to get shaky until just recently. Such an insidious thing,
>> filtered a
2011/7/5 夜神 岩男 :
> On Tue, 2011-07-05 at 06:34 -0400, John Aldrich wrote:
>> On Tue July 5 2011, Tim wrote:
>> > On Mon, 2011-07-04 at 12:52 -0400, John Aldrich wrote:
>> > > might I suggest trying Google Public DNS servers? 8.8.8.8 and 8.8.8.4
>> > > are the IP addresses. My ISP apparently runs so
On Tue, 2011-07-05 at 06:34 -0400, John Aldrich wrote:
> On Tue July 5 2011, Tim wrote:
> > On Mon, 2011-07-04 at 12:52 -0400, John Aldrich wrote:
> > > might I suggest trying Google Public DNS servers? 8.8.8.8 and 8.8.8.4
> > > are the IP addresses. My ISP apparently runs some sort of filtering
>
> I finish my mail : i just try 3 times to send the mail because
> thunderbid failed to send it due to configuration problem on the server
> smtp.googlemail.com I open a CLI and run ping smtp.googlemail.com the
> server answer fine and i achieve to send my email.
> ??
> Eric
Perhaps a bogus DNS
On Tue July 5 2011, Tim wrote:
> On Mon, 2011-07-04 at 12:52 -0400, John Aldrich wrote:
> > might I suggest trying Google Public DNS servers? 8.8.8.8 and 8.8.8.4
> > are the IP addresses. My ISP apparently runs some sort of filtering
> > and occasionally I have problems with their DNS, so I switche
On Mon, 2011-07-04 at 12:52 -0400, John Aldrich wrote:
> might I suggest trying Google Public DNS servers? 8.8.8.8 and 8.8.8.4
> are the IP addresses. My ISP apparently runs some sort of filtering
> and occasionally I have problems with their DNS, so I switched to
> Google and that pretty much reso
On Mon, 2011-07-04 at 18:56 +0200, Eric Tanguy wrote:
> > nameserver 1.2 3.4
> >
> > then try:
> >
> > $ dig @1.2.3.4 mit.edu
> >
> > Do the same on your other machines. Are they all using the same
> > nameserver?
> >
> > poc
> >
> Yes i mean my router's ip.
>
> $ cat /etc/resolv.conf
> # Generate
On Mon, Jul 04, 2011 at 06:59:34PM +0200, Eric Tanguy wrote:
> Le 04/07/2011 18:56, Eric Tanguy a écrit :
> > Le 04/07/2011 16:29, Patrick O'Callaghan a écrit :
> >> On Mon, 2011-07-04 at 16:26 +0200, Eric Tanguy wrote:
> >>> Since few days now i have a name res
Le 04/07/2011 18:56, Eric Tanguy a écrit :
> Le 04/07/2011 16:29, Patrick O'Callaghan a écrit :
>> On Mon, 2011-07-04 at 16:26 +0200, Eric Tanguy wrote:
>>> Since few days now i have a name resolution problem. For example when i
>>> entrer a new address in firefox i
Le 04/07/2011 16:29, Patrick O'Callaghan a écrit :
> On Mon, 2011-07-04 at 16:26 +0200, Eric Tanguy wrote:
>> Since few days now i have a name resolution problem. For example when i
>> entrer a new address in firefox it returns that the name can't be
>> resolved.
On Mon July 4 2011, Eric Tanguy wrote:
> Since few days now i have a name resolution problem. For example when i
> entrer a new address in firefox it returns that the name can't be
> resolved. Reloading the page and firefox display fine the page. I have
> the same problem from t
--raw
- traceroute: this is very useful for tracking down the cause
of disappearing packages
a example: traceroute host_name
3- You have to check the /etc/nsswitch.conf, which is the main
responsible of the name resolution in Solaris and Linux. You will
check too the nscd daemon
I hope that's ca
On Mon, 2011-07-04 at 16:26 +0200, Eric Tanguy wrote:
> Since few days now i have a name resolution problem. For example when i
> entrer a new address in firefox it returns that the name can't be
> resolved. Reloading the page and firefox display fine the page. I have
> the
Since few days now i have a name resolution problem. For example when i
entrer a new address in firefox it returns that the name can't be
resolved. Reloading the page and firefox display fine the page. I have
the same problem from thunderbird or cli using yum.
The network is up using ne
Around 08:14pm on Sunday, June 20, 2010 (UK time), Karl-Olov Serrander scrawled:
> I would guess that the network interface is not up yet.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=595386 might help.
Good call. Making the NETWORKWAIT=yes fix sugested there fixed it, and
is much better than
hen the problem occurs the following message
> is displayed four times, at the "Mounting NFS filesystems:" point:
> mount.nfs: Failed to resolve server albacore: Temporary failure in
> name resolution.
>
> However, even when the messages are displayed, the nfs shares are a
Around 05:41pm on Saturday, June 19, 2010 (UK time), Bill Davidsen scrawled:
> One possibility is that DHCP hasn't run yet, and "albacore" didn't map to
> "albacore.your.domain" because /etc/resolv.conf didn't have the search path
> set.
> Try using the FQDN instead of just the node name and se
Around 04:30pm on Saturday, June 19, 2010 (UK time), Tom Horsley scrawled:
> On Sat, 19 Jun 2010 16:03:44 +0100
> Steve Searle wrote:
>
> > Does anyone have any ideas?
>
> Does this machine also run bind as a local nameserver?
> I found that the first lookups I do during boot always
> fail. I as
s the following message
> is displayed four times, at the "Mounting NFS filesystems:" point:
> mount.nfs: Failed to resolve server albacore: Temporary failure in
> name resolution.
>
> However, even when the messages are displayed, the nfs shares are always
> mo
mounts and when the problem occurs the following message
> is displayed four times, at the "Mounting NFS filesystems:" point:
> mount.nfs: Failed to resolve server albacore: Temporary failure in
> name resolution.
>
>
Are you using NetworkManager?
I've had a similar
On Sat, 19 Jun 2010 16:03:44 +0100
Steve Searle wrote:
> Does anyone have any ideas?
Does this machine also run bind as a local nameserver?
I found that the first lookups I do during boot always
fail. I assume because bind takes "too long" to get
started and prime the cache (or something :-).
I
times, at the "Mounting NFS filesystems:" point:
mount.nfs: Failed to resolve server albacore: Temporary failure in
name resolution.
However, even when the messages are displayed, the nfs shares are always
mounted.
Although this means it is not a serious problem, it is anoying becasue
th
Hi all,
Digging around I think the issue is a bug in Fedora 12.
I wrote some C code that performs the DNS lookup by two different
system calls: gethostbyname2 and getaddrinfo. the later system call
always returns the error message 'Temporary failure in name
resolution'.
Running the
try telnet IP of www.site.com
2010/2/10 Tim Long
> On Tue, Feb 9, 2010 at 6:53 PM, August wrote:
> > First, you can try ping the IP of the host
> > As you can require IP address from DNS, that is not represent the
> IP(host)
> > is activing.
> >
>
> Pinging the host is disabled by the firewall.
On Tue, Feb 9, 2010 at 7:16 PM, Tim wrote:
>
> Wild guess: Look at your resolv.conf files.
It is very simple (I think):
; generated by /sbin/dhclient-script
search bom.gov.au
nameserver 134.178.14.1
nameserver 134.178.14.3
> But, with the amount of blanking out of details in your reports, t
On Tue, Feb 9, 2010 at 6:53 PM, August wrote:
> First, you can try ping the IP of the host
> As you can require IP address from DNS, that is not represent the IP(host)
> is activing.
>
Pinging the host is disabled by the firewall. I am almost certain
there is no connectivty problem between me and
Address: ***.***.***.***
>
> ~]$ telnet www.site.com 80
> telnet: www.site.com: Temporary failure in name resolution
> www.site.com: Host name lookup failure
Wild guess: Look at your resolv.conf files.
But, with the amount of blanking out of details in your reports, they're
next to
; Address:###.###.###.53
>
> Non-authoritative answer:
> Name: www.site.com
> Address: ***.***.***.***
>
> ~]$ telnet www.site.com 80
> telnet: www.site.com: Temporary failure in name resolution
> www.site.com: Host name lookup failure
>
>
&
and IP numbers are scrubbed)
-
~]$ nslookup www.site.com
Server: ###.###.###.###
Address:###.###.###.53
Non-authoritative answer:
Name: www.site.com
Address: ***.***.***.***
~]$ telnet www.site.com 80
telnet: www.site.com: Temporary failure in name resolution
www.site.com
56 matches
Mail list logo
