Re: Basic info on interfaces file
Chris Buxton wrote: > > The BIND name server will not read /etc/resolv.conf (which is what that > dns-nameserver line refers to), so set it to '::1'. Or whatever makes > sense to you. However! Since you are configuring BIND to be an authoritative-only server, you want the local resolver to point to some other recursive name server, not to the name server on localhost. If your network was previously configured with DHCP then you can probably get the correct IP address from the nameserver line(s) in /etc/resolv.conf or /var/run/resolvconf/resolv.conf Tony. -- f.anthony.n.finchhttp://dotat.at/ Irish Sea: West 6 to gale 8, veering northwest 3 or 4 later. Moderate or rough becoming slight or moderate. Rain or showers. Moderate or good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
subdomain with domain
The other day I found that my secondary name servers running bind
where not dishing out
_msdcs. SRV records
This was causing join issues. It turned out that the Domain controller
had 2 different scopes one for
_msdcs.
and one for
so I shared the second _msdcs. scope with all my bind secondary servers.
All servers are running Fedora 21 with
bind.i686 32:9.9.6-8.P1.fc21
I had
zone "" {
type slave;
# the ip address of my dc
masters {192.168.1.2;};
file "data/db.192.168.1.2.slave";
};
entry in all my secondary name servers. Now I have
zone "_msdcs." {
type slave;
# the ip address of my dc
masters {192.168.1.2;};
file "data/db.192.168.1.2.slave";
};
zone "" {
type slave;
# the ip address of my dc
masters {192.168.1.2;};
file "data/db.192.168.1.2.slave";
};
entries on all my secondary name servers. I restarted named on all my
secondary name servers and half of my secondary servers are
working(explained below) half are not. I am certain that I allowed
zone transfers to all of my secondary name servers and that I am
pushing changes to my secondary servers.
Working being that they dish out the _msdcs entries.
examples:
nslookup -type=SRV _ldap._tcp.dc._msdcs. 192.168.1.254
Server: 192.168.1.254
Address:192.168.1.254#53
_ldap._tcp.dc._msdcs. service = 0 100 389 pdc..
nslookup -type=SRV _ldap._tcp.dc._msdcs. 192.168.2.254
Server: 192.168.2.254
Address:192.168.2.254#53
** server can't find _ldap._tcp.dc._msdcs.: SERVFAIL
nslookup -type=SRV _ldap._tcp.dc._msdcs. 192.168.3.254
Server: 192.168.3.254
Address:192.168.3.254#53
_ldap._tcp.dc._msdcs. service = 0 100 389 pdc..
nslookup -type=SRV _ldap._tcp.dc._msdcs. 192.168.4.254
Server: 192.168.4.254
Address:192.168.4.254#53
** server can't find _ldap._tcp.dc._msdcs.: SERVFAIL
All servers still dish out records in the old scope. I have more
secondaries and there doesn't seem to be rime or reason to why half
work and half do not.
I made certain that 192.168.1.254 and 192.168.2.254 both had all the
same packages and double checked all named config files where
Identical.
If anyone could give me a clue on what to check next it would be
greatly appreciated.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
> zone "_msdcs." {
> [..]
> file "data/db.192.168.1.2.slave";
> };
> zone "" {
> [..]
> file "data/db.192.168.1.2.slave";
> };
Both zones are being backed by the same file, so one will be overwriting
the other. This may not be the cause of the half-working situation, but
it won't be helping. Do the bind logs (not sure where Fedora puts them
though - /var/log/messages?) contain any errors?
Unless is really '192.168.1.2', I would suggest naming your
file after the zone that it is going to contain - e.g.
file "data/db._msdcs.";
and
file "data/db.";
Graham
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
com.google how did they do that
As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? Tom Schulz Applied Dynamics Intl. sch...@adi.com ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
Am 01.04.2015 um 20:42 schrieb Thomas Schulz: As of the time I am sending this, you can point your browser to http://com.google and get a web page. How did they get com.google to resolve? .google is just another new TLD signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
On Wed, Apr 01, 2015 at 02:42:04PM -0400, Thomas Schulz wrote: > As of the time I am sending this, you can point your browser > to http://com.google and get a web page. How did they get > com.google to resolve? I'm sure it was not cheap. Brace yourself! There are many here now, and more coming. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
> I'm sure it was not cheap. Peanuts compared to their buying .app for $25m. [1] Here's a list of the other TLDs they've got so far: [2] > Brace yourself! There are many here now, and more coming. The list of delegated strings [3] increases almost daily, yes. (And I can't stop laughing.) -JP [1] http://www.wired.com/2015/02/is-googles-latest-tld-purchase-a-game-changer/ [2] http://www.google.com/registry/ [3] http://newgtlds.icann.org/en/program-status/delegated-strings ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: subdomain with domain
You can do subdomains with the one zone file rather than having separate zones
you just have to put a new ORIGIN for the subdomain.
In the domain file for after the SOA and existing records (NS, A,
CNAME etc...) add a line:
$ORIGIN _msdcs..; New subdomain
Then add the records (A, CNAME, SRV etc...) that you want for that subdomain.
(You don't need to add SOA, NS etc... unless they're different for the
subdomain)
Jeffrey C. Lightner
Sr. UNIX Administrator
DS Services of America, Inc.
2300 Windy Ridge
Suite 600 N
Atlanta, GA 30339
P: 770-933-1400 ext.3516
C: 678-772-0018
F: 678-460-3603
E: jlight...@dsservices.com
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Graham Clinch
Sent: Wednesday, April 01, 2015 11:56 AM
To: Jeff Sadowski; bind-users@lists.isc.org
Subject: Re: subdomain with domain
> zone "_msdcs." {
> [..]
> file "data/db.192.168.1.2.slave";
> };
> zone "" {
> [..]
> file "data/db.192.168.1.2.slave";
> };
Both zones are being backed by the same file, so one will be overwriting the
other. This may not be the cause of the half-working situation, but it won't
be helping. Do the bind logs (not sure where Fedora puts them though -
/var/log/messages?) contain any errors?
Unless is really '192.168.1.2', I would suggest naming your file after
the zone that it is going to contain - e.g.
file "data/db._msdcs.";
and
file "data/db.";
Graham
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Recall: subdomain with domain
Lightner, Jeff would like to recall the message, "subdomain with domain". CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
In article , Jan-Piet Mens wrote: > > I'm sure it was not cheap. > > Peanuts compared to their buying .app for $25m. [1] Here's a list of the > other TLDs they've got so far: [2] Some of them sound like more April Fools jokes. > > > Brace yourself! There are many here now, and more coming. > > The list of delegated strings [3] increases almost daily, yes. (And I > can't stop laughing.) > > -JP > > [1] > http://www.wired.com/2015/02/is-googles-latest-tld-purchase-a-game-changer/ > [2] http://www.google.com/registry/ > [3] http://newgtlds.icann.org/en/program-status/delegated-strings -- Barry Margolin Arlington, MA ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
On 4/1/2015, Jeff Sadowski wrote The other day I found that my secondary name servers running bind where not dishing out _msdcs. SRV records This was causing join issues. It turned out that the Domain controller had 2 different scopes one for _msdcs. and one for so I shared the second _msdcs. scope with all my bind secondary servers. It would be a good idea to also have the other Active Directory "underscore" zones: __sites. _tcp. _udp. on your slave server. --Barry Finkel ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
Remember to put check-names ignore to use underlined zones. > On Apr 1, 2015, at 4:53 PM, Barry S. Finkel wrote: > > On 4/1/2015, Jeff Sadowski wrote >> The other day I found that my secondary name servers running bind >> where not dishing out >> >> _msdcs. SRV records >> >> This was causing join issues. It turned out that the Domain controller >> had 2 different scopes one for >> >> _msdcs. >> and one for >> >> >> so I shared the second _msdcs. scope with all my bind secondary >> servers. > > It would be a good idea to also have the other Active Directory > "underscore" zones: > > __sites. > _tcp. > _udp. > > on your slave server. > > --Barry Finkel > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: subdomain with domain
On 1 April 2015 at 20:53, Barry S. Finkel wrote: > It would be a good idea to also have the other Active Directory > "underscore" zones: > > __sites. > _tcp. > _udp. > > on your slave server. >From what I've seen in the field, in most AD installations those aren't actual subdomains, Microsoft just uses dotted host names in the main domain. The only subdomain that is always created is the _msdcs subdomain, the rest usually need manual intervention to create them. (The MMC tricks you as it shows folders for subdomains on the dotted host names when they don't actually exist.) To see what domains you actually have configured in Microsoft DNS use "dnscmd /enumzones", then replicate those in your secondary. Steve ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND not loading into memory on first transfer
On Fri, Mar 27, 2015 at 8:25 AM, Barry Margolin wrote: > In article , > /dev/rob0 wrote: > >> On Thu, Mar 26, 2015 at 11:34:42AM -0700, Frank Even wrote: >> > In this particular instance, the masters ended up under maintenance >> > shortly after these boxes rebooted, so they were unable to transfer >> > the zone from them for another 2 hours. These boxes were serving >> > stale data after boot despite being able to accomplish one zone >> > transfer after boot. It seems that failing the first zone transfer >> > did NOT load the zone into memory (but subsequent zone transfers >> > while still failing to write the tmp file DID load the zone into >> > memory). >> > >> > I guess the question really is, is this expected behavior or a bug? >> >> The bug is a misconfiguration bug, where contrary to documented >> requirements, you have not given named write privilege in its >> directory. >> >> I think you're saying named should fail to load the stale zones, >> which at startup it cannot know are stale. That does not sound >> correct to me. >> >> Perhaps you're suggesting that named should SERVFAIL the zone when >> the first zone transfer has happened, and while this sounds more >> reasonable, I am not sure that the zone transfer actually does take >> place if named is unable to open a temporary file to write. (What >> would be the point in talking to the master when you know you are >> unable to handle the data?) > > He's not suggesting either of these. He's saying that when it > successfully transferred the zone, it should update the in-memory > version, and serve that, even though it wasn't able to save it to disk. > That's what it does on the SECOND transfer, it just doesn't do it on the > FIRST transfer. ^^^ THIS! Exactly! I REALIZE I had a configuration problem that prevented writing the zone file locally that snuck in as it turns out on the bind-chroot package update. That's irrelevant to the issue I noticed after that. It DOES load up in memory and serve it up generally. It's just that what I've seen in this particular instance is that it failed to do this on the first successful zone transfer, then loaded it up in memory on the 2nd try (which sadly in this instance, was 2 hours later due to other issues, which of course caused it to be noticed in this instance where it might not have been in previous instances). Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Variable in name of file for named.conf
I have a number of slave domains that I would like a naming scheme and
not have to go to each and change the filename.
I have the following zones
zone "1.168.192.in-addr.arpa" {
include "named.slave";
};
zone "2.168.192.in-addr.arpa" {
include "named.slave";
};
zone "3.168.192.in-addr.arpa" {
include "named.slave";
};
zone "4.168.192.in-addr.arpa" {
include "named.slave";
};
zone "5.168.192.in-addr.arpa" {
include "named.slave";
};
zone "6.168.192.in-addr.arpa" {
include "named.slave";
};
zone "7.168.192.in-addr.arpa" {
include "named.slave";
};
zone "8.168.192.in-addr.arpa" {
include "named.slave";
};
zone "9.168.192.in-addr.arpa" {
include "named.slave";
};
zone "10.168.192.in-addr.arpa" {
include "named.slave";
};
named.slave looks as follows
type slave;
masters {192.168.1.2;};
file "data/db.@.slave";
It appears to work on my queries.
nslookup 192.168.1.2
2.1.168.192.in-addr.arpa name = pdc.
nslookup 192.168.1.1
1.1.168.192.in-addr.arpa name = gw1.
nslookup 192.168.2.1
1.2.168.192.in-addr.arpa name = gw2.
the only file created in my data directory seems to be db.@.slave
with the at sign.
Do I really need to have each zone with its own file?
Is there a special syntax to get what I expect?
expected files:
data/db.1.168.192.in-addr.arpa.slave
data/db.2.168.192.in-addr.arpa.slave
data/db.3.168.192.in-addr.arpa.slave
...
data/db.10.168.192.in-addr.arpa.slave
if not I can have Make do it and build some scripts to do what I want
but if there is syntax to do what I want it would be nice.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: com.google how did they do that
-Original Message- From: Reindl Harald Organization: the lounge interactive design Date: Wednesday, April 1, 2015 at 2:44 PM To: "bind-users@lists.isc.org" Subject: Re: com.google how did they do that >Am 01.04.2015 um 20:42 schrieb Thomas Schulz: >> As of the time I am sending this, you can point your browser to >> http://com.google and get a web page. How did they get com.google >> to resolve? > >.google is just another new TLD Wow. I see the trend now -- .hp, .ibm, .cisco -- everyone will now have www.company. (Please, let's not.) ..then again, I'd claim .evil if I had a few billions. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
[OFF-TOPIC] RE: com.google how did they do that
.ibm, .cisco, .apple, .google, .sucks, .melbourne and many hundreds of others have been applied for and hundreds already delegated into the root. '.hp' was deemed too short (must be at least 3 characters). See https://gtldresult.icann.org/application-result/applicationstatus for the new TLD's and where they are up to (or http://newgtlds.icann.org/en/ for details about the program in general). -Original Message- >Am 01.04.2015 um 20:42 schrieb Thomas Schulz: >> As of the time I am sending this, you can point your browser to >> http://com.google and get a web page. How did they get com.google >> to resolve? > >.google is just another new TLD Wow. I see the trend now -- .hp, .ibm, .cisco -- everyone will now have www.company. (Please, let's not.) ..then again, I'd claim .evil if I had a few billions. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Variable in name of file for named.conf
In article ,
Jeff Sadowski wrote:
> I have a number of slave domains that I would like a naming scheme and
> not have to go to each and change the filename.
>
> I have the following zones
>
> zone "1.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "2.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "3.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "4.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "5.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "6.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "7.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "8.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "9.168.192.in-addr.arpa" {
> include "named.slave";
> };
> zone "10.168.192.in-addr.arpa" {
> include "named.slave";
> };
>
> named.slave looks as follows
>
> type slave;
> masters {192.168.1.2;};
> file "data/db.@.slave";
>
> It appears to work on my queries.
>
> nslookup 192.168.1.2
>
> 2.1.168.192.in-addr.arpa name = pdc.
>
> nslookup 192.168.1.1
>
> 1.1.168.192.in-addr.arpa name = gw1.
>
> nslookup 192.168.2.1
>
> 1.2.168.192.in-addr.arpa name = gw2.
>
> the only file created in my data directory seems to be db.@.slave
> with the at sign.
Why would you expect anything different? @ only has special meaning
inside zone files, it's not special in named.conf.
>
> Do I really need to have each zone with its own file?
Yes, you do. What's happening is that every time one of the reverse
zones is transferred, it's overwriting that file. But the files are only
used when initializing the zones when named starts up; you get the
correct answers because the in-memory versions of the zones are
distinct. But try restarting named and then see what happens when you do
those nslookups. You'll see that 192.168.1.1 and 192.168.2.1 both return
the same name.
>
> Is there a special syntax to get what I expect?
> expected files:
> data/db.1.168.192.in-addr.arpa.slave
> data/db.2.168.192.in-addr.arpa.slave
> data/db.3.168.192.in-addr.arpa.slave
> ...
> data/db.10.168.192.in-addr.arpa.slave
>
> if not I can have Make do it and build some scripts to do what I want
> but if there is syntax to do what I want it would be nice.
No, there's no built-in syntax to create the filename based on the zone
name.
--
Barry Margolin
Arlington, MA
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
NAMED try to solve domain from old authoritative server
Hi List, I have faced the problem. Firstly, I have 2 nameserver, the first nameserver is the authoritative nameserver and not allow the recursive. The second one is the recursive nameserver, and also store zonefile as the same with the first server. I have remove zonefile from the first server and reload named process. It can work normally, I got the SERVFAIL response when I try to query from it. And at the second server, after it remove zone from named.conf and `rndc reload`, it also can query from the new authoritative nameserver. But after a few hours, new TTL is 600, it go back to query from my first server which give me below log. lame-servers: error (unexpected RCODE REFUSED) resolving 'www.domain.tld/A/IN': 192.168.1.1#53 lame-servers: lame server resolving 'www.domain.tld' (in 'domain.tld'?): 2001:db8:0:1::101#53 I must do the `rndc flushname domain.tld` to flush the cache. However a few hours after I flush cache, the problem occur again. Does anyone ever face this problem? My named version is below. #named -V BIND 9.9.2-P1 built with '--localstatedir=/var' '--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' '--without-python' '--with-openssl=/usr' '--with-libxml2=/usr/local' '--without-idn' '--enable-ipv6' '--enable-threads' '--sysconfdir=/etc/namedb' '--prefix=/usr/local' '--mandir=/usr/local/man' '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd8.2' 'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe -fno-strict-aliasing' 'LDFLAGS= -Wl,-rpath=/usr/lib:/usr/local/lib' 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe -fno-strict-aliasing' using OpenSSL version: OpenSSL 0.9.8q 2 Dec 2010 using libxml2 version: 2.7.8 BR, Te ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED try to solve domain from old authoritative server
Do you really want help? If so stop obscuring the details. Mark In message , Teerapatr Kittiratanachai writes: > Hi List, > > I have faced the problem. > Firstly, I have 2 nameserver, the first nameserver is the > authoritative nameserver and not allow the recursive. The second one > is the recursive nameserver, and also store zonefile as the same with > the first server. > > I have remove zonefile from the first server and reload named process. > It can work normally, I got the SERVFAIL response when I try to query > from it. > And at the second server, after it remove zone from named.conf and > `rndc reload`, it also can query from the new authoritative > nameserver. But after a few hours, new TTL is 600, it go back to query > from my first server which give me below log. > > lame-servers: error (unexpected RCODE REFUSED) resolving > 'www.domain.tld/A/IN': 192.168.1.1#53 > lame-servers: lame server resolving 'www.domain.tld' (in > 'domain.tld'?): 2001:db8:0:1::101#53 > > I must do the `rndc flushname domain.tld` to flush the cache. > However a few hours after I flush cache, the problem occur again. > > Does anyone ever face this problem? > > My named version is below. > > #named -V > BIND 9.9.2-P1 built with '--localstatedir=/var' '--disable-linux-caps' > '--disable-symtable' '--with-randomdev=/dev/random' '--without-python' > '--with-openssl=/usr' '--with-libxml2=/usr/local' '--without-idn' > '--enable-ipv6' '--enable-threads' '--sysconfdir=/etc/namedb' > '--prefix=/usr/local' '--mandir=/usr/local/man' > '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd8.2' > 'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe > -fno-strict-aliasing' 'LDFLAGS= -Wl,-rpath=/usr/lib:/usr/local/lib' > 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe > -fno-strict-aliasing' > using OpenSSL version: OpenSSL 0.9.8q 2 Dec 2010 > using libxml2 version: 2.7.8 > > BR, > Te > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: NAMED try to solve domain from old authoritative server
Mark, Unfortunately, due to my company's policy, i cannot provide you the information. Thank you for your help. Te On Thu, Apr 2, 2015 at 12:07 PM, Mark Andrews wrote: > > Do you really want help? If so stop obscuring the details. > > Mark > > In message > , > Teerapatr Kittiratanachai writes: >> Hi List, >> >> I have faced the problem. >> Firstly, I have 2 nameserver, the first nameserver is the >> authoritative nameserver and not allow the recursive. The second one >> is the recursive nameserver, and also store zonefile as the same with >> the first server. >> >> I have remove zonefile from the first server and reload named process. >> It can work normally, I got the SERVFAIL response when I try to query >> from it. >> And at the second server, after it remove zone from named.conf and >> `rndc reload`, it also can query from the new authoritative >> nameserver. But after a few hours, new TTL is 600, it go back to query >> from my first server which give me below log. >> >> lame-servers: error (unexpected RCODE REFUSED) resolving >> 'www.domain.tld/A/IN': 192.168.1.1#53 >> lame-servers: lame server resolving 'www.domain.tld' (in >> 'domain.tld'?): 2001:db8:0:1::101#53 >> >> I must do the `rndc flushname domain.tld` to flush the cache. >> However a few hours after I flush cache, the problem occur again. >> >> Does anyone ever face this problem? >> >> My named version is below. >> >> #named -V >> BIND 9.9.2-P1 built with '--localstatedir=/var' '--disable-linux-caps' >> '--disable-symtable' '--with-randomdev=/dev/random' '--without-python' >> '--with-openssl=/usr' '--with-libxml2=/usr/local' '--without-idn' >> '--enable-ipv6' '--enable-threads' '--sysconfdir=/etc/namedb' >> '--prefix=/usr/local' '--mandir=/usr/local/man' >> '--infodir=/usr/local/info/' '--build=x86_64-portbld-freebsd8.2' >> 'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe >> -fno-strict-aliasing' 'LDFLAGS= -Wl,-rpath=/usr/lib:/usr/local/lib' >> 'CPPFLAGS=' 'CPP=cpp' 'CXX=c++' 'CXXFLAGS=-O2 -pipe >> -fno-strict-aliasing' >> using OpenSSL version: OpenSSL 0.9.8q 2 Dec 2010 >> using libxml2 version: 2.7.8 >> >> BR, >> Te >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
