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
[mailto:bin
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 4:43
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=domain&&value=4.254.253.50.i
n-addr.arpa&&recordType=PTR
But that does not give me the SOA for the comcast NS that is
authoritative for the r
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=domain&&value=4.254.253.50.i
n-addr.arpa&&recordType=PTR
Frank
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Rob
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 m
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 cha
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
Thanks all for your inputs!!
On Tue, Feb 3, 2015 at 4:39 PM, Robert Edmonds 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. Any ideas?
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 rep
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 wrote:
> >Let me take a step back. The original problem is "dig ."
> > would give SERVFA
>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
(possib
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 wrote:
> Actually I tried +trace from BIND server itself and still get the same
> answer. I did "dig .
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 c
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:
In message , 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 all bad situations and therefore I
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 wrote:
> The named.ca seems good.
>
> ;; ANSWER SECTION:
> . 518400 IN
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.
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 B.
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 wrote
I do dig . +trace and the results seem show .new servers. This is causing
SERVFAIL for root query. Any ideas?
dig . +trace
; <<>> DiG 9.7.0-P1 <<>> . +trace
;; global options: +cmd
. 348510 IN NS b.root-servers.new.
. 348510 IN NS
Which way did you configure your EDNS buffer size? I think there's a
not-so-subtle difference between doing it in "options" _versus_ in a "server"
clause (despite the "server" being defined as 0.0.0.0/0 or ::/0). "server"
seems to only affect queries that named itself generates to nameservers,
Bob Harold 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 more
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
> As example, if 1.2.
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 provisi
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 wi
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 VPN
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.
This
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
Stuart Henderson 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 that the
> > p
Enrico Scholz 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 our 31-24 range. This wil
Mark Andrews 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 now by dec
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 h
33 matches
Mail list logo
