I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
Centos 6.3.
I have and will run bind chrooted and on my test setup I noticed a 'new'
subdirectory in the chroot tree:
/var/named/chroot/etc/named/
I cannot find any documentation as what is indended to be placed in this
sub
On 02/13/2013 12:43 PM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Robert Moskowitz
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org"
Subject: chroot/etc/named/ directory?
I am upgrading my server from bind-9.3.6 via Centos 5.5 t
org
Subject: Re: chroot/etc/named/ directory?
-Original Message-
From: Robert Moskowitz
Date: Wednesday, February 13, 2013 10:53 AM
To: "bind-users@lists.isc.org"
Subject: chroot/etc/named/ directory?
I am upgrading my server from bind-9.3.6 via Centos 5.5 to 9.8.2 in
Centos
On 02/13/2013 03:40 PM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Robert Moskowitz
Date: Wednesday, February 13, 2013 2:15 PM
To: Mike Hoskins
Cc: "bind-users@lists.isc.org"
Subject: Re: chroot/etc/named/ directory?
Having said all that, you might search th
The Centos 6.3 bind and bind-chroot do not seem to come with a
named.root. Does have a named.ca, though.
So from my old named.root.hints include (also not provided; where did I
get this?) I tried:
wget ftp://ftp.rs.internic.net/domain/named.root
And got a nice looking named.root last updat
anything needed in the named.conf to actuate this if you do
have it?
W
On Feb 14, 2013, at 8:35 AM, Robert Moskowitz wrote:
The Centos 6.3 bind and bind-chroot do not seem to come with a named.root.
Does have a named.ca, though.
So from my old named.root.hints include (also not provided
Oops ignore that earlier send. Hit wrong button...
On 02/14/2013 08:42 AM, Steven Carr wrote:
On 14 February 2013 13:35, Robert Moskowitz wrote:
What went wrong here?
Which do I use?
Not sure what is up with your dig response (can you post the contents)
but it works for me and if your dig
with records.
Christian...
On 02/14/2013 08:35 AM, Robert Moskowitz wrote:
The Centos 6.3 bind and bind-chroot do not seem to come with a
named.root. Does have a named.ca, though.
So from my old named.root.hints include (also not provided; where did
I get this?) I tried:
On 02/14/2013 09:34 AM, Warren Kumari wrote:
On Feb 14, 2013, at 9:28 AM, Robert Moskowitz wrote:
On 02/14/2013 09:05 AM, Warren Kumari wrote:
BIND now comes with a baked in roots file (in the imaginatively named
lib/dns/rootns.c )
Not (at least by that name) in the Redhat/Centos 6.3 bind
On 02/14/2013 09:38 AM, Tony Finch wrote:
Robert Moskowitz wrote:
On 02/14/2013 09:05 AM, Warren Kumari wrote:
BIND now comes with a baked in roots file (in the imaginatively named
lib/dns/rootns.c )
Not (at least by that name) in the Redhat/Centos 6.3 bind 9.8.2.
That is a source file
On 02/14/2013 09:47 AM, Tony Finch wrote:
Robert Moskowitz wrote:
Which begs the next question I was going to ask. How often should I download
a fresh named.zone?
Never. If you keep BIND reasonably up-to-date its built-in hints will work
fine.
More records 1/3/2013 than in the
On 02/14/2013 10:18 AM, Tony Finch wrote:
Robert Moskowitz wrote:
More records 1/3/2013 than in the named.ca stub which IF my version has
it builtin raises the question about keeping current at this time in the
Internet (and trusting Redhat to roll in new builtin hints as they go).
No
On 02/14/2013 10:26 AM, Jaap Akkerhuis wrote:
You too are missing some A and records! Here is mine:
Use bufsize=4096 or at least something around 700, else the answer
doesn't fitand is truncated.
I was thinking it was something like that. Thanks.
jaap
dig +bu
On 02/15/2013 12:37 PM, Chris Buxton wrote:
On Feb 14, 2013, at 8:49 AM, Shawn Bakhtiar wrote:
Running bind rooted on FC 16 using the standard package.
The ca file is located in /var/named/chroot/var/named/named.ca
The hints are not built in.
[shawn@www ~]$ strings /usr/sbin/named | grepA.
I am now running without chroot and relying on selinux for protection.
I created a /etc/named.d/ directory for all my many includes in
named.conf which I know I have to keep in /etc/
My rndc.key is in /etc/named.d/ and is an include in my named.conf. When
I first started bind, it reported tha
So it is past time for me to only use port 53 and support port
randomization. But I do run iptables (and ip6tables) and the server
sits behind a Juniper SSG firewall.
Where are there instructions for setting up iptables for port randomization
and for general firewall rules (I doubt I will fin
I commented out include for the root.hints and things are working still
so obviously it is built in even though the string search is not working
on my binary.
On 02/15/2013 12:57 PM, Robert Moskowitz wrote:
On 02/15/2013 12:37 PM, Chris Buxton wrote:
On Feb 14, 2013, at 8:49 AM, Shawn
I have been getting this warning, and wonder why?
I have read:
https://kb.isc.org/.../Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html
I have a 128.168.192.in-addr.arpa.zone zone in my internal view. So
what might I be missing? Do I need to create my own deleg
On 02/15/2013 03:40 PM, Chris Buxton wrote:
On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote:
I will do some more testing with this to see if I can indeed remove the
root.hint includes. But I have a question. I have tried to dig in my server
for the root info like you can a root server
On 02/15/2013 03:40 PM, Chris Buxton wrote:
On Feb 15, 2013, at 9:57 AM, Robert Moskowitz wrote:
I will do some more testing with this to see if I can indeed remove the
root.hint includes. But I have a question. I have tried to dig in my server
for the root info like you can a root server
On 02/16/2013 07:25 PM, Tony Finch wrote:
Robert Moskowitz wrote:
I have been getting this warning, and wonder why?
I have read:
https://kb.isc.org/article/AA-00804/0/Why-does-named-log-an-error-disabling-RFC-1918-empty-zones-when-starting-up.html
named logs the message if there are any
Should I put a single entry for my /48 allocation or 16 /64 entries for
the nets I am currently using?
Does it make any difference for performance? Any other concerns? The
192.168 nets I use I have a /24 specified though typically I am only
using the lower /26.
In theory, no one out there c
I hope to roll out my DNS upgrade today, but without enabling DNSSEC;
that will take a bit longer.
One of my secondaries, though, does not support DNSSEC and it is the one
that gives me a bit of geographical diversity. So I am looking for
someplace that will accept my smallish domains.
than
On 02/17/2013 09:57 AM, David Forrest wrote:
On Sun, 17 Feb 2013, Vernon Schryver wrote:
In any case, some naming and shaming seems appropriate. Basic
Naming and shaming seems excessive for a "free" service.
Just like I am FINALLY moving to DNSSEC, the fellow running the system I
have be
On 02/17/2013 09:44 AM, Vernon Schryver wrote:
From: Robert Moskowitz
One of my secondaries, though, does not support DNSSEC
How does a secondary authoritative DNS server fail to support DNSSEC?
It's not as if it would be doing any signature checking or automagic
(re)signing. Does i
On 02/17/2013 11:48 AM, Vernon Schryver wrote:
From: David Forrest
In any case, some naming and shaming seems appropriate. Basic
Naming and shaming seems excessive for a "free" service.
Services that do not charge users money are often not really free.
This is my concern in coming out and
On 02/17/2013 12:11 PM, Vernon Schryver wrote:
From: Robert Moskowitz
The Redhat docs on bind had a warning about not implementing features,
like DNSSEC if your secondaries doesn't support it. That is all I am
going on. I think I also saw it in some isc.org doc.
In your position
On 02/17/2013 12:43 PM, Evan Hunt wrote:
Should I put a single entry for my /48 allocation or 16 /64 entries for
the nets I am currently using?
Both ways work.
Does it make any difference for performance?
Possibly, but I doubt you could measure it. (Unless you're using a
really ancent versio
Delving further into my challenges.
Right now I use Network Solutions as my registrar. Just never changes
as they were the only show in town back then.
But they don't seem to support DNSSEC protected domains, and even IPv6
glue records are special requests, it seems.
My registration is up
I am reading up on ISC DLV Registry.
www.isc.org/solutions/dlv states this is for recursive servers.
We are recommended to only use recursion for our internal view and have
our external view set to "recursion no;". That said, does it matter
where the bindkeys-file path is located: In the glo
Phase I is hopefully complete. A new onlo.htt-consult.com is up in
place of the old one.
This is a faster box with current software. I will 'leave it alone' for
a week, unless someone tells me something is wrong with it.
Next I unlock my domain from NetSol and choose my new registrar and
m
updates.
So I hope someone can point me to what I have missed.
On 02/20/2013 02:07 PM, Robert Moskowitz wrote:
Phase I is hopefully complete. A new onlo.htt-consult.com is up in
place of the old one.
This is a faster box with current software. I will 'leave it alone'
for a we
On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS on
my new server. IPTABLES was set for 53 both UDP and TCP. Firewall was
OK. In fact a local system on the same subnet, thus NOT going through
my firewall was denied access to
21/02/13 2:59, Robert Moskowitz wrote:
On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS
on my new server. IPTABLES was set for 53 both UDP and TCP.
Firewall was OK. In fact a local system on the same subnet, thus
NOT going
localhost.
On 21/02/13 2:59, Robert Moskowitz wrote:
On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS
on my new server. IPTABLES was set for 53 both UDP and TCP.
Firewall was OK. In fact a local system on the same subnet, thus
NOT
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and "allow-query-cache" '.
I am struggling here trying to match up the various access control
features, particularly when we are suppose to have different views for
different clients
On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and "allow-query-cache" '.
I am struggling here
On 02/21/2013 12:10 PM, Matus UHLAR - fantomas wrote:
On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has
changed in the behavior of "allow-recursion" and
"allow-query-cache" '.
I am struggling here
On 02/21/2013 11:50 AM, Vernon Schryver wrote:
correct, no external hosts should query your cache.
OK.
There is no substitute for testing assumptions, mailing list assurances,
understandings of documentation, etc. Test from outside your network
to see that your DNS servers don't answer reque
On 02/21/2013 12:58 PM, Mike Hoskins (michoski) wrote:
-Original Message-
From: Robert Moskowitz
Date: Thursday, February 21, 2013 12:53 PM
To: Vernon Schryver
Cc: "bind-users@lists.isc.org"
Subject: Re: allow-query and views
Whow... This is news. A hidden view? Whe
On 02/21/2013 01:54 PM, Matus UHLAR - fantomas wrote:
On 21.02.13 12:45, Robert Moskowitz wrote:
Fact:
No clients could access DNS from my server, both internal and
external (I have hotspot on my cellphone, so I can attach a client to
it to get external testing) UNTIL I added the allow
On 02/21/2013 02:04 PM, Vernon Schryver wrote:
From: Robert Moskowitz
Whow... This is news. A hidden view? Where is this documented.
The ARM says in part:
Built-in server information zones
The server provides some helpful diagnostic information through a
number of built-in
On 02/21/2013 02:16 PM, Vernon Schryver wrote:
The ARM says in part:
Built-in server information zones
The server provides some helpful diagnostic information through a
number of built-in zones under the pseudo-top-level-domain bind
in the CHAOS class. These zones are part of
On 02/21/2013 06:49 PM, Mark Andrews wrote:
In message
, Nikita
Koshiko
v writes:
Hello list,
I'm trying to "cut" /24 network from the scope of /8 network, here is
example:
zone "11.2.10.in-addr.arpa" {
type forward;
forwarders { 192.168.1.23; 192
On 02/22/2013 10:51 AM, Mike Hoskins (michoski) wrote:
I know this last bit from experience, having worked at CELECs back in
the day and running an ISP that was severely underfunded because the
Internet was "new" and couldn't be trusted like a telephone. Lots of
committed people working long h
Yes, I know lots of places don't have DNSSEC signed zones. **I** have
not done mine yet, but I turned on DNSSEC checking on my server and I am
getting all too many messages like:
validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature
found: 1 Time(s)
validating @0xb4247
On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz <mailto:r...@htt-consult.com>> wrote:
Yes, I know lots of places don't have DNSSEC signed zones. **I**
have not done mine yet, but I turned on DNSSEC checking on my
s
On 02/25/2013 02:33 PM, Robert Moskowitz wrote:
On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz
mailto:r...@htt-consult.com>> wrote:
Yes, I know lots of places don't have DNSSEC signed zones. **I**
have not done mine yet, b
On 02/25/2013 03:25 PM, Robert Moskowitz wrote:
On 02/25/2013 02:33 PM, Robert Moskowitz wrote:
On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz
mailto:r...@htt-consult.com>> wrote:
Yes, I know lots of places don't have DNSSEC s
On 02/25/2013 08:15 PM, Mark Andrews wrote:
In message <512c09f5.4040...@htt-consult.com>, Robert Moskowitz writes:
On 02/25/2013 03:25 PM, Robert Moskowitz wrote:
On 02/25/2013 02:33 PM, Robert Moskowitz wrote:
On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5
On 02/25/2013 08:38 PM, Mark Andrews wrote:
In message <512c1009.4060...@htt-consult.com>, Robert Moskowitz writes:
dnssec-enable yes;
dnssec-validation yes;
digging back in the archive here, I find out this should be
dnssec-validation auto;
Actually it can be
On 02/25/2013 09:36 PM, Mark Andrews wrote:
In message <512c18eb.2050...@htt-consult.com>, Robert Moskowitz writes:
On 02/25/2013 08:38 PM, Mark Andrews wrote:
In message <512c1009.4060...@htt-consult.com>, Robert Moskowitz writes:
dnssec-enable yes;
dnssec-va
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift that my server has been directed to a 'lame server' and
logs that fact. S
On 02/26/2013 08:38 AM, Robert Moskowitz wrote:
Continuing to 'clean up' my new server by reviewing logged messages.
Researching a common one:
Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL)
resolving 'foo.com/MX/IN': 1.2.3.4#53
I get the drift tha
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address of the lame server, not the requesting client
On 02/26/2013 09:25 AM, Robert Moskowitz wrote:
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups that
end up going to lame servers. I am assuming the IP address in the log
is the address
On 02/26/2013 09:37 AM, Phil Mayers wrote:
On 26/02/13 14:31, Robert Moskowitz wrote:
On 02/26/2013 09:25 AM, Robert Moskowitz wrote:
On 02/26/2013 09:13 AM, Phil Mayers wrote:
On 26/02/13 13:54, Robert Moskowitz wrote:
I would be interested in which client is requesting these lookups
So now I am working on adding a name caching service to my mailserver.
And I am reading up on namecaching. For RHEL/Centos, there is not much
to doing this as the default install of bind SEEMS to be a name caching
server. But I want it to NOT go out on the net for queries, but to
direct all
On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward option. It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching? And 'forward first' only lo
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around.
I don't need my mailserver to constantly be asking my name server
about
On 02/26/2013 12:58 PM, Sten Carlsen wrote:
On 26/02/13 18:06, Robert Moskowitz wrote:
On 02/26/2013 11:43 AM, Sten Carlsen wrote:
On 26/02/13 15:50, Robert Moskowitz wrote:
I would expect that a namecaching server on the mailserver would
reduce traffic and resources all the way around
On 02/26/2013 01:19 PM, Doug Barton wrote:
You want to set up your resolver on your mail server to forward to
your main resolver, using the forward only option. This will allow
your mail server resolver to benefit from the cache already populated
on your main resolver, while still maintaining
hey, Kevin, hope you are hanging well back at the old stomping ground!
On 02/26/2013 01:42 PM, Kevin Darcy wrote:
On 2/26/2013 11:39 AM, Robert Moskowitz wrote:
On 02/26/2013 11:14 AM, Phil Mayers wrote:
On 26/02/13 16:07, Robert Moskowitz wrote:
And I am having challenges with the forward
On 02/26/2013 01:57 PM, Doug Barton wrote:
On 02/26/2013 10:38 AM, Robert Moskowitz wrote:
I would like a scalpel for lame logging, but probably would not discover
any actionable data.
There is a logging category for lame-servers. It's in the ARM.
So far 2 reads and I am not getting o
For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal server. It cannot resolve any hosts in this tld and on the
server forwar
On 02/27/2013 08:34 PM, Mark Andrews wrote:
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes:
For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namec
Still not working even with htt. signed. See below. I guess what I
need for right now is to turn off DNSSEC checking of a branch in the
tree; in this case the tld htt.
On 02/27/2013 08:34 PM, Mark Andrews wrote:
In message <512e31ca.5030...@htt-consult.com>, Robert Moskowitz writes
On 02/28/2013 12:37 PM, Doug Barton wrote:
On 02/28/2013 09:34 AM, Robert Moskowitz wrote:
Only for my internal tld does the lookup fail.
Are you distributing the trust anchor for htt to all of the servers
that are doing validation?
No. Of course I did not think of that! I just ASSuMEd a
On 02/28/2013 12:57 PM, Vernon Schryver wrote:
From: Robert Moskowitz
Well one really shouldn't be creating one's own tlds.
As the instigator and a co-author of rfc 1918, I beg to differ.
Many people considered the notion in RFC 1918 harmful. See RFC 1627.
Um, I lived that de
On 02/28/2013 01:14 PM, Tony Finch wrote:
Robert Moskowitz wrote:
Feb 28 12:14:16 klovia named[22332]: validating @0xb421ba30: htt SOA: got
insecure response; parent indicates it should be secure
I think this suggests that one of the servers for htt doesn't have the
signed ve
On 02/28/2013 01:31 PM, Vernon Schryver wrote:
From: Tony Finch
Another reason not to use made-up domain names: CAs are going to stop
issuing X.509 certificates for them. (It baffles me why they ever did so.)
http://ssl.entrust.net/blog/?p=1831
That's another reason to publish your own DANE re
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt.INDNSKEY257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5g
On 02/28/2013 02:42 PM, Robert Moskowitz wrote:
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt. IN DNSKEY 257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ
On 02/28/2013 06:21 PM, Mark Andrews wrote:
In message <512fb319.7030...@htt-consult.com>, Robert Moskowitz writes:
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt.INDNSKEY257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbU
I got tipped off about this from logwatch report. On my public DNS
server had the following:
Feb 26 04:02:04 onlo named[19336]: validating @0xb2929ee0:
in-addr.arpa SOA: got insecure response; parent indicates it should be
secure
Feb 27 04:02:04 onlo named[32262]: validating @0xb37e25e0:
On 03/01/2013 08:57 AM, Tony Finch wrote:
Robert Moskowitz wrote:
I got tipped off about this from logwatch report. On my public DNS server had
the following:
Feb 26 04:02:04 onlo named[19336]: validating @0xb2929ee0: in-addr.arpa SOA:
got insecure response; parent indicates it should be
On 03/01/2013 09:22 AM, Michael W. Lucas wrote:
On Fri, Mar 01, 2013 at 09:19:42AM -0500, Robert Moskowitz wrote:
On 03/01/2013 08:57 AM, Tony Finch wrote:
Robert Moskowitz wrote:
I got tipped off about this from logwatch report. On my public DNS server had
the following:
Feb 26 04:02:04
On 03/01/2013 09:22 AM, Michael W. Lucas wrote:
On Fri, Mar 01, 2013 at 09:19:42AM -0500, Robert Moskowitz wrote:
On 03/01/2013 08:57 AM, Tony Finch wrote:
Robert Moskowitz wrote:
I got tipped off about this from logwatch report. On my public DNS server had
the following:
Feb 26 04:02:04
On 03/01/2013 09:19 AM, Robert Moskowitz wrote:
On 03/01/2013 08:57 AM, Tony Finch wrote:
Robert Moskowitz wrote:
I got tipped off about this from logwatch report. On my public DNS
server had
the following:
Feb 26 04:02:04 onlo named[19336]: validating @0xb2929ee0:
in-addr.arpa SOA
I get this for all my secondaries for my reverse domain:
client 63.68.132.50 view external: bad zone transfer request:
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone (NOTAUTH): 23
Time(s)
I don't get this for my forward domain and the SOA for both are
similarly structured. For t
On 03/01/2013 01:03 PM, Robert Moskowitz wrote:
I get this for all my secondaries for my reverse domain:
client 63.68.132.50 view external: bad zone transfer request:
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone (NOTAUTH):
23 Time(s)
I don't get this for my for
On 03/01/2013 01:50 PM, Jan-Piet Mens wrote:
I get this for all my secondaries for my reverse domain:
client 63.68.132.50 view external: bad zone transfer request:
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone
(NOTAUTH): 23 Time(s)
The zone is either not defined in the view the cl
On 03/01/2013 06:42 PM, Mark Andrews wrote:
In message <5130fba0.3020...@htt-consult.com>, Robert Moskowitz writes:
On 03/01/2013 01:50 PM, Jan-Piet Mens wrote:
I get this for all my secondaries for my reverse domain:
client 63.68.132.50 view external: bad zone transfer request
On 03/02/2013 09:14 PM, Robert Moskowitz wrote:
On 03/01/2013 06:42 PM, Mark Andrews wrote:
In message <5130fba0.3020...@htt-consult.com>, Robert Moskowitz writes:
On 03/01/2013 01:50 PM, Jan-Piet Mens wrote:
I get this for all my secondaries for my reverse domain:
client 63.68.132.5
I solve the EDNS problem, probably on my Juniper SSG5. This will
initially have to wait until Juniper gets back to me, or I corner some
of their developers at IETF in a couple weeks. Alternatively I replace
the SSG5...
And I change my registry to one that supports DNSSEC.
Commenting all the
On 03/03/2013 08:10 AM, Robert Moskowitz wrote:
I solve the EDNS problem, probably on my Juniper SSG5. This will
initially have to wait until Juniper gets back to me, or I corner some
of their developers at IETF in a couple weeks. Alternatively I
replace the SSG5...
And I change my
I have a server that is only running bind 9.8.2 (Centos 6.5). It has
2Gb memory and free reports ~1.7Gb used.
I am looking at replacing this server with an armv7 board running
Redsleeve (until Centos 7 is out and stable for armv7). I have a choice
of boards, one with 1Gb memory ($60) and one
I just found out that I had old garbage in my rgistrar setup for my
domain. To wit, an NS server that has not been an NS server for years.
And now that I use that host name for another usage on another address,
it was giving lots of problems. My bad, I should have caught this when
I moved Re
On 12/05/2014 12:30 PM, Casey Deccio wrote:
On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz <mailto:r...@htt-consult.com>> wrote:
I have 3 secondaries run by other domains. This was to give me
some geo-diversity. How do I create glue records for them? My
registrar onl
I am trying to find out which comcast server is authoritative for
4.254.253.50.in-addr.arpa
and when the zone file for the ptr rr was last updated.
I was told a week ago that the ptr would be updated, but I am still not
seeing any change...
I am not really good at keeping good notes on using
On 02/03/2015 05:09 PM, Jeremy C. Reed wrote:
On Tue, 3 Feb 2015, Robert Moskowitz wrote:
I am trying to find out which comcast server is authoritative for
4.254.253.50.in-addr.arpa
and when the zone file for the ptr rr was last updated.
I was told a week ago that the ptr would be updated
ritative for the rDNS. Or at least I don't see it on the results page.
but thanks for the tip.
Frank
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz
Sent: Tuesday, February 03, 2015 4:01 PM
To: bin
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz
Sent: Tuesday, February 03, 2015 4:43 PM
To: Jeremy C. Reed
Cc: bind-users@lists.isc.org
Subject: Re: Finding authoritative server and last update
On 02/03/2015 05:09 PM, Jeremy C. Reed wrote:
On Tue, 3 Feb 2015, Robert Moskowitz wrote
I have one nameserver running bind 9.8.2 and a new one running 9.9.4.
Both can resolve www.ietf.org
Only the 9.8.2 can resolve 0.centos.pool.ntp.org
I literally rsynced all the of the conf and zone files from the old to
the new, then changed all of the server name references. I have done
thi
esolving 0.centos.pool.ntp.org. So there is something about
that resolution that does not like the early date.
So I am caught in a time bind here!
Is there anyway to get bind not to be particular about system time at first?
John
On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz wrote:
I ha
On 09/01/2015 09:36 AM, Reindl Harald wrote:
Am 01.09.2015 um 15:31 schrieb Robert Moskowitz:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don't believ
On 09/01/2015 10:28 AM, John Miller wrote:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?
I don'
On 09/01/2015 10:38 AM, Reindl Harald wrote:
Am 01.09.2015 um 16:28 schrieb John Miller:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz
wrote:
On 09/01/2015 09:20 AM, John Miller wrote:
If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.nt
On 09/01/2015 12:16 PM, Sam Wilson wrote:
In article ,
Robert Moskowitz wrote:
I will be looking more into this. Obvious when you get ones nose
dragged into time wrong on boot. This is actually a broader problem on
arm SoC booting. Your logs all have the wrong time for the boot
is also systemd-timesync, but Fedora/redhat went the chrony route,
and I got more help figuring it out.
On to the next fun challenge.
On 09/01/2015 12:16 PM, Sam Wilson wrote:
In article ,
Robert Moskowitz wrote:
I will be looking more into this. Obvious when you get ones nose
dragged int
1 - 100 of 136 matches
Mail list logo
