Michael McNally wrote:
> On 5/8/13 9:33 AM, Jeremy P wrote:
> >
> > However, there are times where registering a real domain just isn't
> > practical. For example, I'm not going to ask all of the students in my
> > courses to go out and register a .com for the semester.
>
> The flip side of this
On 08/05/13 19:15, Tom Sommer wrote:
>
> On 5/8/13 12:25 PM, Cathy Almond wrote:
>> On 08/05/13 08:26, Tom Sommer wrote:
>>> Hi,
>>>
>>> I have a problem with one of 3 slave servers, all set up the exact same
>>> way, with the exact same bind version and configuration.
>>>
>>> One slave has a prob
On 5/9/13 11:36 AM, Cathy Almond wrote:
I don't think you solved the problem - I think you moved it (or made it
happen faster...)
The refresh errors indicate that the master isn't responding to your
slave for some reason. That's what you'll need to investigate. I would
suggest auditing the di
I don't know how it's done, I'm not a networking guru, but here we have 2
upstream providers and somehow we route out through both, and both can
route in to our /16 network. No messing with DNS changes depending on
which ISP is having problems,
As Clarke's third law states, "Any sufficiently
Tom,
What happens when you "dig +tcp example.com @1.2.3.4"? Specifically I'm
wondering here if the slave you're having problems with is blocking TCP port
53. Such a configuration would allow you to query the master server, but not
transfer to/from it.
Dan Luther
Operations Engineer
Systems Op
On 5/8/13 9:33 AM, Jeremy P wrote:
> However, there are times where registering a real domain just isn't
> practical. For example, I'm not going to ask all of the students in my
> courses to go out and register a .com for the semester.
Michael McNally wrote:
The flip side of this is that wha
Sounds like they are using BGP for routing. That's probably the way we are
going to go. That way we don't have to make any crazy changes in our bind
configurations. Thanks all for the replies.
-Original Message-
From: bind-users-bounces+mward=ssfcu@lists.isc.org
[mailto:bind-users-b
Matus UHLAR - fantomas wrote:
> On 09.05.13 10:21, Tony Finch wrote:
> > Right. Give each student a subdomain of some existing domain, even if the
> > subdomains aren't publicly delegated.
>
> yes, so they will start using it in their job and home.
They shouldn't do that if the teacher has proper
-Original Message-
From: Tony Finch
Date: Thursday, May 9, 2013 11:01 AM
To: Matus UHLAR - fantomas
Cc: "bind-users@lists.isc.org"
Subject: Re: architecture question
>Matus UHLAR - fantomas wrote:
>> On 09.05.13 10:21, Tony Finch wrote:
>> > Right. Give each student a subdomain of som
On 09.05.13 10:21, Tony Finch wrote:
> Right. Give each student a subdomain of some existing domain, even if the
> subdomains aren't publicly delegated.
Matus UHLAR - fantomas wrote:
yes, so they will start using it in their job and home.
On 09.05.13 16:01, Tony Finch wrote:
They shouldn't
Matus UHLAR - fantomas wrote:
> > > On 09.05.13 10:21, Tony Finch wrote:
> > > > Right. Give each student a subdomain of some existing domain, even
> > > > if the subdomains aren't publicly delegated.
>
> > Matus UHLAR - fantomas wrote:
> > > yes, so they will start using it in their job and hom
I certainly didn't intend to spark off such a firestorm with my original
question. I have learned a lot from the debate though.
On the question of what to use with students, it is a fine thing to say "we
should only do things the way they are done in real life so students don't
learn bad habits",
> From: Jeremy P
> In my experience the students who "get it" and comprehend the
> concepts are able to heed the warnings of "in real life, we would do
> this a little different". The students who don't "get it" are gonna
> misconfigure regardless of what TLD I tell them to use in the lab.
>
Too often its the corner office friend!
You are right, those other people may get hired, but not by people who know
how to interview. I ran an IT department for 10 years prior to teaching
and my goals of hiring were always first, don't hire jerks. Second, hire
people who know their stuff inside
My mail setup is as limited as my eyesight. As I mentioned, I have
emails in my inbox and filter afterwards in order to keep mbox size at
reasonable levels. In this way I don't forget to check this or that folder.
While on inbox I filter by looking at the tags. Works really well and I
know quite a
On 2013-05-09 11:27, Jeremy P wrote:
I certainly didn't intend to spark off such a firestorm with my
original question. I have learned a lot from the debate though.
On the question of what to use with students, it is a fine thing to
say "we should only do things the way they are done in real
On 5/9/2013 5:02 PM, Carlos M. martinez wrote:
My mail setup is as limited as my eyesight. As I mentioned, I have
emails in my inbox and filter afterwards in order to keep mbox size at
reasonable levels. In this way I don't forget to check this or that folder.
While on inbox I filter by looking
This is also the way I use mail, so +1.
On 09/05/13 23:02, Carlos M. martinez wrote:
> My mail setup is as limited as my eyesight. As I mentioned, I have
> emails in my inbox and filter afterwards in order to keep mbox size at
> reasonable levels. In this way I don't forget to check this or that
On May 9, 2013, at 4:02 PM, Carlos M. martinez wrote:
> My mail setup is as limited as my eyesight. As I mentioned, I have
> emails in my inbox and filter afterwards in order to keep mbox size at
> reasonable levels. In this way I don't forget to check this or that folder.
I'm sorry, but I have t
Seriously, can we stop discussing this now?
If you need subject line tags, or your mail client doesn't properly know
how to respond only to the list, or whatever -- please go work that out
on your own.
The majority of users on the list don't want or need these things, and
many of us find thi
On 2013-05-08 11:13, btb wrote:
it's also mildly humorous that they used to quite religiously endorse
.local, in some documents even categorizing use of the same domain
name on an internal and external network as a "security risk".
Keep in mind that this was before ubiquitous, always-on TCP/I
21 matches
Mail list logo