Hello,
Can anybody help me?
I am using bind 9.8.2
Sometime my provisionning system provision a bad record ina zone.
Example A record with 1.2.3.4.5 value (just an example).
My provisioning system do not detect all bad situations and therefore I can
have a zone with only a bad record.
Two suggestions:
1. Don't stop/start named. Instead, do rndc freeze, update the zone
files, rndc thaw, rndc reload. If a zone is bad, I think BIND will
continue to server the old zone. Also there is no break in service since
BIND is never stopped.
or more complicated:
2. Have your provisioning
Bob Harold rharo...@umich.edu wrote:
Two suggestions:
1. Don't stop/start named. Instead, do rndc freeze, update the zone
files, rndc thaw, rndc reload. If a zone is bad, I think BIND will
continue to server the old zone. Also there is no break in service since
BIND is never stopped.
or
Hi Brown,
oops... excuse me! :) You are right!
Francesco
Da: wbr...@e1b.org [wbr...@e1b.org]
Inviato: martedì 3 febbraio 2015 15.37
A: Job
Cc: bind-users@lists.isc.org
Oggetto: Re: Blocking if resolved ip is geolicalized
From: Job
Enrico Scholz enrico.sch...@sigma-chemnitz.de wrote:
Unfortunately, our ISP (Deutsche Telekom) does not allow AXFR of the
/24 zone. I solved it now by declaring an external (non-recursive)
and internal (recursive) view, where the external one is a master
for 2.1.10.in-addr.arpa covering only
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
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, but I am still
not seeing any change...
By the way, it looks like the SOA MNAME has a misspelling typo in it. I
wonder if that is on purpose to foil automated/unintelligent spammers.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users
Hello,
i would like to ask this particular thing: i would like to block resolution if
RESOLVED IP is geolocated in some country.
As example, if 1.2.3.4 is geolocated in China and i want to block all Chinese
website, if a resolve www.site.ch (that is 1.2.3.4), bind should give me an
error or a
On 03.02.15 13:43, hugo hugoo wrote:
Can anybody help me?
I am using bind 9.8.2
Sometime my provisionning system provision a bad record ina zone.
Example A record with 1.2.3.4.5 value (just an example).
My provisioning system do not detect all bad situations and therefore I can
have a zone
On 03/02/15 05:51, Ray Van Dolson wrote:
We have a Lync 2013 environment with all of its DNS records living
within our primary domain (esri.com). I have a need to override all of
the Lync related DNS records so that they resolve differently for a set
of client IP's (clients which connect via
Stuart Henderson s...@spacehopper.org wrote:
On 2015/02/02 21:51, Ray Van Dolson wrote:
Unfortunately, the only solution I'm really seeing right now is an ugly
one -- setting up a new view for this set of clients and then creating
25+ zones -- one zone per record I want to override (so
Additional info - general: warning: checkhints: unable to find root NS
'b.root-servers.new' in hints
I cant seem to find where the .new coming from...
On Tue, Feb 3, 2015 at 2:07 PM, Linux Addict linuxaddi...@gmail.com wrote:
The named.ca seems good.
;; ANSWER SECTION:
.
Let me take a step back. The original problem is dig . would give
SERVFAIL instead of NOERROR. The . is pointed to named.ca which looks
normal.
On Tue, Feb 3, 2015 at 2:28 PM, Linux Addict linuxaddi...@gmail.com wrote:
Actually I tried +trace from BIND server itself and still get the same
Actually I tried +trace from BIND server itself and still get the same
answer. I did dig . +trace @localhost
; DiG 9.7.0-P1 . +trace @localhost
;; global options: +cmd
. 346239 IN NS i.root-servers.new.
. 346239 IN NS
There was nothing changed on the system since 2012. The behavior changed
all of sudden. I am just curious where dig got root servers like
b.root-servers.new..
On Tue, Feb 3, 2015 at 2:56 PM, Leonard Mills l...@yahoo.com wrote:
Let me take a step back. The original problem is dig .
would give
If I remember right, DIG does not know the root servers and asks the
local host to retrieve that information and a server at
172.27.254.11(which is RFC 1918 address space) gave you that answer.
Is your machine/shop setup with private root servers?
Lyle
On 2/3/2015 12:50 PM, Linux Addict
The named.ca seems good.
;; ANSWER SECTION:
. 518400 IN NS C.ROOT-SERVERS.NET.
. 518400 IN NS I.ROOT-SERVERS.NET.
. 518400 IN NS F.ROOT-SERVERS.NET.
. 518400 IN NS
On Tue, Feb 03, 2015 at 01:50:14PM -0500, Linux Addict wrote:
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
Contact the person who runs the resolver at 172.27.254.11 and report the
problem about the root hints. dig
In message dub131-w630a8c19b5efbd0cf5e975ac...@phx.gbl, hugo hugoo writes:
Hello,
Can anybody help me?
I am using bind 9.8.2
Sometime my provisionning system provision a bad record ina zone.
Example A record with 1.2.3.4.5 value (just an example).
My provisioning system do not detect
172.27.254.11 is giving you that info with the .new name servers. You
need to ask whomever manages that server.
Look at this line from your +trace output:
Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms
Lyle
On 2/3/2015 1:13 PM, Linux Addict wrote:
Additional info - general:
Let me take a step back. The original problem is dig .
would give SERVFAIL instead of NOERROR.
The . is pointed to named.ca which looks normal.
Without source code changes to your tools and/or replacement
hints files . invariably points to the root servers to be used by the
(possibly
There are free ones:
http://www.frankb.us/dns/
http://networking.ringofsaturn.com/Unix/freednsservers.php
Regards,
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
On 02/03/2015 05:42 PM, Frank Bulk wrote:
Rob,
I like to use DNSstuff because it can check each path:
http://www.dnsstuff.com/tools#dnsTraversal|type=domainvalue=4.254.253.50.i
n-addr.arparecordType=PTR
But that does not give me the SOA for the comcast NS that is
authoritative for the
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,
Rob,
I like to use DNSstuff because it can check each path:
http://www.dnsstuff.com/tools#dnsTraversal|type=domainvalue=4.254.253.50.i
n-addr.arparecordType=PTR
Frank
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert
On 02/03/2015 05:47 PM, Frank Bulk wrote:
There are free ones:
http://www.frankb.us/dns/
http://networking.ringofsaturn.com/Unix/freednsservers.php
Thanks! I will be following up on this shortly.
Regards,
Frank
-Original Message-
From: bind-users-boun...@lists.isc.org
On 2015/02/02 21:51, Ray Van Dolson wrote:
Unfortunately, the only solution I'm really seeing right now is an ugly
one -- setting up a new view for this set of clients and then creating
25+ zones -- one zone per record I want to override (so that the
primary domain -- esri.com, still gets
Mark Andrews ma...@isc.org writes:
Firstly allow-query on a static stub does nothing.
ok; thx for clarifying
You should be a master for 31-24.2.1.10.in-addr.arpa and a slave for
2.1.10.in-addr.arpa.
Unfortunately, our ISP (Deutsche Telekom) does not allow AXFR of the
/24 zone. I solved it
Mukund Sivaraman wrote:
On Tue, Feb 03, 2015 at 01:50:14PM -0500, Linux Addict wrote:
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query. Any ideas?
dig . +trace
Contact the person who runs the resolver at 172.27.254.11 and report the
Thanks all for your inputs!!
On Tue, Feb 3, 2015 at 4:39 PM, Robert Edmonds edmo...@mycre.ws wrote:
Mukund Sivaraman wrote:
On Tue, Feb 03, 2015 at 01:50:14PM -0500, Linux Addict wrote:
I do dig . +trace and the results seem show .new servers. This is
causing SERVFAIL for root query.
31 matches
Mail list logo
