DIG Info Request
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 h.root-servers.new. . 348510 IN NS l.root-servers.new. . 348510 IN NS f.root-servers.new. . 348510 IN NS m.root-servers.new. . 348510 IN NS k.root-servers.new. . 348510 IN NS i.root-servers.new. . 348510 IN NS e.root-servers.new. . 348510 IN NS g.root-servers.new. . 348510 IN NS j.root-servers.new. . 348510 IN NS c.root-servers.new. . 348510 IN NS d.root-servers.new. ;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms ;; connection timed out; no servers could be reached ___ 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: DIG Info Request
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.ROOT-SERVERS.NET. . 518400 IN NS L.ROOT-SERVERS.NET. . 518400 IN NS D.ROOT-SERVERS.NET. . 518400 IN NS J.ROOT-SERVERS.NET. . 518400 IN NS K.ROOT-SERVERS.NET. . 518400 IN NS E.ROOT-SERVERS.NET. . 518400 IN NS A.ROOT-SERVERS.NET. . 518400 IN NS M.ROOT-SERVERS.NET. . 518400 IN NS G.ROOT-SERVERS.NET. . 518400 IN NS H.ROOT-SERVERS.NET. On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese wrote: > 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 h.root-servers.new. > . 348510 IN NS l.root-servers.new. > . 348510 IN NS f.root-servers.new. > . 348510 IN NS m.root-servers.new. > . 348510 IN NS k.root-servers.new. > . 348510 IN NS i.root-servers.new. > . 348510 IN NS e.root-servers.new. > . 348510 IN NS g.root-servers.new. > . 348510 IN NS j.root-servers.new. > . 348510 IN NS c.root-servers.new. > . 348510 IN NS d.root-servers.new. > ;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms > > ;; connection timed out; no servers could be reached > > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing > listbind-us...@lists.isc.orghttps://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 > ___ 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: DIG Info Request
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 NS C.ROOT-SERVERS.NET. > . 518400 IN NS I.ROOT-SERVERS.NET. > . 518400 IN NS F.ROOT-SERVERS.NET. > . 518400 IN NS B.ROOT-SERVERS.NET. > . 518400 IN NS L.ROOT-SERVERS.NET. > . 518400 IN NS D.ROOT-SERVERS.NET. > . 518400 IN NS J.ROOT-SERVERS.NET. > . 518400 IN NS K.ROOT-SERVERS.NET. > . 518400 IN NS E.ROOT-SERVERS.NET. > . 518400 IN NS A.ROOT-SERVERS.NET. > . 518400 IN NS M.ROOT-SERVERS.NET. > . 518400 IN NS G.ROOT-SERVERS.NET. > . 518400 IN NS H.ROOT-SERVERS.NET. > > > > On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese wrote: > >> 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 h.root-servers.new. >> . 348510 IN NS l.root-servers.new. >> . 348510 IN NS f.root-servers.new. >> . 348510 IN NS m.root-servers.new. >> . 348510 IN NS k.root-servers.new. >> . 348510 IN NS i.root-servers.new. >> . 348510 IN NS e.root-servers.new. >> . 348510 IN NS g.root-servers.new. >> . 348510 IN NS j.root-servers.new. >> . 348510 IN NS c.root-servers.new. >> . 348510 IN NS d.root-servers.new. >> ;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms >> >> ;; connection timed out; no servers could be reached >> >> >> >> ___ >> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >> unsubscribe from this list >> >> bind-users mailing >> listbind-us...@lists.isc.orghttps://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 >> > > ___ 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: DIG Info Request
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.root-servers.new. . 346239 IN NS b.root-servers.new. . 346239 IN NS e.root-servers.new. . 346239 IN NS d.root-servers.new. . 346239 IN NS l.root-servers.new. . 346239 IN NS f.root-servers.new. . 346239 IN NS j.root-servers.new. . 346239 IN NS h.root-servers.new. . 346239 IN NS k.root-servers.new. . 346239 IN NS m.root-servers.new. . 346239 IN NS g.root-servers.new. ;; Received 405 bytes from localhost#53(localhost) in 1 ms On Tue, Feb 3, 2015 at 2:19 PM, Lyle Giese wrote: > 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: 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 NS C.ROOT-SERVERS.NET. >> . 518400 IN NS I.ROOT-SERVERS.NET. >> . 518400 IN NS F.ROOT-SERVERS.NET. >> . 518400 IN NS B.ROOT-SERVERS.NET. >> . 518400 IN NS L.ROOT-SERVERS.NET. >> . 518400 IN NS D.ROOT-SERVERS.NET. >> . 518400 IN NS J.ROOT-SERVERS.NET. >> . 518400 IN NS K.ROOT-SERVERS.NET. >> . 518400 IN NS E.ROOT-SERVERS.NET. >> . 518400 IN NS A.ROOT-SERVERS.NET. >> . 518400 IN NS M.ROOT-SERVERS.NET. >> . 518400 IN NS G.ROOT-SERVERS.NET. >> . 518400 IN NS H.ROOT-SERVERS.NET. >> >> >> >> On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese wrote: >> >>> 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 h.root-servers.new. >>> . 348510 IN NS l.root-servers.new. >>> . 348510 IN NS f.root-servers.new. >>> . 348510 IN NS m.root-servers.new. >>> . 348510 IN NS k.root-servers.new. >>> . 348510 IN NS i.root-servers.new. >>> . 348510 IN NS e.root-servers.new. >>> . 348510 IN NS g.root-servers.new. >>> . 348510 IN NS j.root-servers.new. >>> . 348510 IN NS c.root-servers.new. >>> . 348510 IN NS d.root-servers.new. >>> ;; Received 405 bytes from 172.27.254.11#53(172.27.254.11) in 1 ms >>> >>> ;; connection timed out; no servers could be reached >>> >>> >>> >>> ___ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe fr
Re: DIG Info Request
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 . +trace @localhost" > > > ; <<>> DiG 9.7.0-P1 <<>> . +trace @localhost > ;; global options: +cmd > . 346239 IN NS i.root-servers.new. > . 346239 IN NS c.root-servers.new. > . 346239 IN NS b.root-servers.new. > . 346239 IN NS e.root-servers.new. > . 346239 IN NS d.root-servers.new. > . 346239 IN NS l.root-servers.new. > . 346239 IN NS f.root-servers.new. > . 346239 IN NS j.root-servers.new. > . 346239 IN NS h.root-servers.new. > . 346239 IN NS k.root-servers.new. > . 346239 IN NS m.root-servers.new. > . 346239 IN NS g.root-servers.new. > ;; Received 405 bytes from localhost#53(localhost) in 1 ms > > > On Tue, Feb 3, 2015 at 2:19 PM, Lyle Giese wrote: > >> 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: 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 NS C.ROOT-SERVERS.NET. >>> . 518400 IN NS I.ROOT-SERVERS.NET. >>> . 518400 IN NS F.ROOT-SERVERS.NET. >>> . 518400 IN NS B.ROOT-SERVERS.NET. >>> . 518400 IN NS L.ROOT-SERVERS.NET. >>> . 518400 IN NS D.ROOT-SERVERS.NET. >>> . 518400 IN NS J.ROOT-SERVERS.NET. >>> . 518400 IN NS K.ROOT-SERVERS.NET. >>> . 518400 IN NS E.ROOT-SERVERS.NET. >>> . 518400 IN NS A.ROOT-SERVERS.NET. >>> . 518400 IN NS M.ROOT-SERVERS.NET. >>> . 518400 IN NS G.ROOT-SERVERS.NET. >>> . 518400 IN NS H.ROOT-SERVERS.NET. >>> >>> >>> >>> On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese wrote: >>> >>>> 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 h.root-servers.new. >>>> . 348510 IN NS l.root-servers.new. >>>> . 348510 IN NS f.root-servers.new. >>>> . 348510 IN NS m.root-servers.new. >>>> . 348510 IN NS k.root-servers.new. >>>> . 348510 IN NS i.root-servers.new. >>>> . 348510 IN NS e.root-servers.new. >>>> . 348510 IN NS g.root-servers.new.
Re: DIG Info Request
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 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 local) DNS toolset. > > HTH, > Len > > > > On Tuesday, February 3, 2015 11:47 AM, Linux Addict < > linuxaddi...@gmail.com> wrote: > > > 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.root-servers.new. > . 346239 IN NS b.root-servers.new. > . 346239 IN NS e.root-servers.new. > . 346239 IN NS d.root-servers.new. > . 346239 IN NS l.root-servers.new. > . 346239 IN NS f.root-servers.new. > . 346239 IN NS j.root-servers.new. > . 346239 IN NS h.root-servers.new. > . 346239 IN NS k.root-servers.new. > . 346239 IN NS m.root-servers.new. > . 346239 IN NS g.root-servers.new. > ;; Received 405 bytes from localhost#53(localhost) in 1 ms > > > On Tue, Feb 3, 2015 at 2:19 PM, Lyle Giese wrote: > > 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: 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 NS C.ROOT-SERVERS.NET > <http://c.root-servers.net/>. > . 518400 IN NS I.ROOT-SERVERS.NET > <http://i.root-servers.net/>. > . 518400 IN NS F.ROOT-SERVERS.NET > <http://f.root-servers.net/>. > . 518400 IN NS B.ROOT-SERVERS.NET > <http://b.root-servers.net/>. > . 518400 IN NS L.ROOT-SERVERS.NET > <http://l.root-servers.net/>. > . 518400 IN NS D.ROOT-SERVERS.NET > <http://d.root-servers.net/>. > . 518400 IN NS J.ROOT-SERVERS.NET > <http://j.root-servers.net/>. > . 518400 IN NS K.ROOT-SERVERS.NET > <http://k.root-servers.net/>. > . 518400 IN NS E.ROOT-SERVERS.NET > <http://e.root-servers.net/>. > . 518400 IN NS A.ROOT-SERVERS.NET > <http://a.root-servers.net/>. > . 518400 IN NS M.ROOT-SERVERS.NET > <http://m.root-servers.net/>. > . 518400 IN NS G.ROOT-SERVERS.NET > <http://g.root-servers.net/>. > . 518400 IN NS H.ROOT-SERVERS.NET > <http://h.root-servers.net/>. > > > > On Tue, Feb 3, 2015 at 2:02 PM, Lyle Giese wrote: > > 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 h.root-servers.new. &g
Re: DIG Info Request
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? > > > > > > dig . +trace > > > > Contact the person who runs the resolver at 172.27.254.11 and report the > > problem about the root hints. dig +trace uses the configured resolver to > > only find the root nameservers, and directly does lookups afterwards. > > Also note that there are only two bits different between ascii 't' > (01110100) and ascii 'w' (01110111). Most likely the root cause is > memory corruption somewhere, rather than any sort of intentional or > unintentional misconfiguration. > > See, e.g.: > > http://dinaburg.org/bitsquatting.html > > https://www.verisigninc.com/assets/VRSN_Bitsquatting_TR_20120320.pdf > > > http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html > > -- > Robert Edmonds > ___ > 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
External Resolution
Folks, I have BIND 9 running. For some reason, the external resolution is not working. I can telnet to root servers on port 53. Recursion is on. What are the other requiremnts for the server to reesolve the external records. Please help!! ~LA ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: External Resolution
Dmitry Rybin wrote: Linux Addict wrote: Folks, I have BIND 9 running. For some reason, the external resolution is not working. I can telnet to root servers on port 53. Recursion is on. What are the other requiremnts for the server to reesolve the external records. Please help!! TCP? You must open in firewall: allow tcp,udp from me to any 53 allow tcp,udp from any 53 to me Thank you. I will test. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamic update of TXT record?
On Mon, Jan 5, 2009 at 5:03 PM, JINMEI Tatuya / 神明達哉 wrote: > At Thu, 1 Jan 2009 12:23:02 +0100, > Michelle Konzack wrote: > > > Q 1:Which setting is missing? > > > > Q2: Can someone tell me how to update a TXT record? > > Please show named.conf of the authoritative server (the one accepting > dynamic updates). It's also helpful to debug it to show log messages > of the server when it refused the request. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > allow-update ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split DNS, internal/external
On Tue, Feb 3, 2009 at 5:19 PM, Jeff Howard wrote:
> Hi all,
>
> Having a problem setting up split DNS for the purpose of separating
> internal, recursive, caching responses vs external, non caching, non
> recusrive responses. First off, can views be used to do this?
>
> If yes, here are the relevant (I hope) portions of named.conf, which I've
> set up based on http://www.cymru.com/Documents/secure-bind-template.html:
>
> acl trusted {
> 8.8.8.0/24;
> };
> ..snip..
> view internal-in in {
> match clients { trusted };
> recursion yes;
> additional-from-auth yes;
> additional-from-cache yes;
>
> zone "." in {
> // Link in the root server hint file.
> type hint;
> file "db.cache";
> };
>
> zone "ournetwork.com" in {
> // Our internal A RR zone. There may be several of these.
> type master;
> file "ournetwork.com.db";
> };
>
> zone "8.8.8.in-addr.arpa" in {
> // Our internal PTR RR zone. Again, there may be several of
> these.
> type master;
> file "8.8.8.in-addr.arpa.db";
> };
>
> };
>
> view external-in in {
> match-clients { any; };
> recursion no;
> additional-from-auth no;
> additional-from-cache no;
>
> zone "8.8.8.in-addr.arpa" in {
> // Our internal PTR RR zone. Again, there may be several of
> these.
> type master;
> file "8.8.8.in-addr.arpa.db";
> allow-query { any; };
> };
>
> zone "ournetwork.com" in {
> // Our internal A RR zone. There may be several of these.
> type master;
> file "ournetwork.com.db";
> allow-query { any; };
> };
>
> zone "." in {
> // Link in the root server hint file.
> type hint;
> file "db.cache";
> };
>
> };
>
> The result is that all requests outside the trusted IP range are being
> REFUSED. Not sure why that is, though; anyone?
>
> Thanks a bunch!
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
Can you please post one of the REFUSED message? I doubt the clients are
outside the trusted.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS server can resolve some domains - BIND 9.4.2-P1
On Thu, Feb 26, 2009 at 1:11 PM, Prabhat Rana wrote: > > Also you may want to increase the File descriptor limits in /etc/service > file > * Set File descriptor (FD) limits > set rlim_fd_max= > Its /etc/system > > > --- On Thu, 2/26/09, JINMEI Tatuya / 神明達哉 wrote: > > > From: JINMEI Tatuya / 神明達哉 > > Subject: Re: DNS server can resolve some domains - BIND 9.4.2-P1 > > To: comp-protocols-dns-b...@isc.org > > Cc: sergiot...@gmail.com > > Date: Thursday, February 26, 2009, 11:49 AM > > At Wed, 25 Feb 2009 12:27:29 -0800 (PST), > > sergiot...@gmail.com wrote: > > > > > > I have a server installed, with Solaris 9 and BIND > > 9.4.2-P1, 1 week > > > ago, i began to receive some messages in the message > > logs: > > > > > > 25-Feb-2009 15:30:35.826 general: error: socket: too > > many open file > > > descriptors > > > 25-Feb-2009 15:30:35.827 general: error: socket: too > > many open file > > > descriptors > > > 25-Feb-2009 15:30:36.210 general: error: socket: too > > many open file > > > descriptors > > > 25-Feb-2009 15:30:36.228 general: error: socket: too > > many open file > > > descriptors > > > > > > I guess that's why my server is working abnormally > > right now and > > > cannot resolve some domains, i've read a lots of > > posts that there is a > > > patch for this issue, and also some people try to fix > > the problem > > > increasing the FTD_Size value, but i don't know > > what exactly can i > > > aply, could you help me please, because our dns server > > is the master > > > and it cannot be stay with this kind a problems a long > > time. > > > > 9.4.2-P1 has known scalability issues. Please upgrade to > > 9.4.3-P1. > > > > --- > > JINMEI, Tatuya > > Internet Systems Consortium, Inc. > > ___ > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > > > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dig +trace
Hello Folks, I got a strange issue going on.. I dig for a specific record against a ISP cache server , and the cache server doesn't seem to see it, but When I do dig +any, then the record stays in the cache for say 5minutes and then vanishes. any idea? ~LA ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC
On Tue, May 4, 2010 at 10:43 AM, Stephane Bortzmeyer wrote: > On Tue, May 04, 2010 at 10:27:25AM -0400, > Linux Addict wrote > a message of 89 lines which said: > > > lacks EDNS, defaults to 512" > > DNS reply size limit is at least 490" > > "Tested at 2010-05-04 14:21:02 UTC" > > You edited the responses (which includes an IP address). Is it the IP > address of your resolver? There is may be a forwarder which does not > have EDNS. > > Second possibility, a middlebox mangles your packets and deletes EDNS > options. > > Actually that IP was our external NAT. One information I neglected to mention is bind forwards to a tinydns appliance which of course does not support DNSSEC for obvious reasons. So what are my options now? Will the internet work for me tomorrow? At least I have company in Google.. dig +short rs.dns-oarc.net txt @8.8.8.8 rst.x476.rs.dns-oarc.net. rst.x485.x476.rs.dns-oarc.net. rst.x490.x485.x476.rs.dns-oarc.net. "64.233.168.94 DNS reply size limit is at least 490" "64.233.168.94 lacks EDNS, defaults to 512" "Tested at 2010-05-04 15:00:07 UTC" ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC
On Wed, May 5, 2010 at 11:53 AM, Warren Kumari wrote: > > On May 4, 2010, at 11:01 AM, Linux Addict wrote: > > On Tue, May 4, 2010 at 10:43 AM, Stephane Bortzmeyer wrote: > >> On Tue, May 04, 2010 at 10:27:25AM -0400, >> Linux Addict wrote >> a message of 89 lines which said: >> >> > lacks EDNS, defaults to 512" >> > DNS reply size limit is at least 490" >> > "Tested at 2010-05-04 14:21:02 UTC" >> >> You edited the responses (which includes an IP address). Is it the IP >> address of your resolver? There is may be a forwarder which does not >> have EDNS. >> >> Second possibility, a middlebox mangles your packets and deletes EDNS >> options. >> >> > Actually that IP was our external NAT. One information I neglected to > mention is bind forwards to a tinydns appliance which of course does not > support DNSSEC for obvious reasons. > > So what are my options now? Will the internet work for me tomorrow? > At least I have company in Google.. > > dig +short rs.dns-oarc.net txt @8.8.8.8 > rst.x476.rs.dns-oarc.net. > rst.x485.x476.rs.dns-oarc.net. > rst.x490.x485.x476.rs.dns-oarc.net. > "64.233.168.94 DNS reply size limit is at least 490" > "64.233.168.94 lacks EDNS, defaults to 512" > "Tested at 2010-05-04 15:00:07 UTC" > > > > > Actually, we do support EDNS0, but usually only advertise larger buffers > if needed. > > For example, if you retry this with +dnssec you should get: > > wkum...@colon:/$ dig +dnssec +short rs.dns-oarc.net txt @8.8.8.8 > rst.x1247.rs.dns-oarc.net. > rst.x1257.x1247.rs.dns-oarc.net. > rst.x1228.x1257.x1247.rs.dns-oarc.net. > "74.125.44.94 DNS reply size limit is at least 1257" > "74.125.44.94 sent EDNS buffer size 1280" > "Tested at 2010-05-05 15:51:16 UTC" > wkum...@colon:/$ > > > W > > thanks for the clarification, I learned that after sometime. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Multi-mastering with dynamic updates
On Mon, May 17, 2010 at 12:48 PM, Phil Mayers wrote: > On 17/05/10 16:59, Arcan_- wrote: > >> Thanks for the reply. >> >> Interesting. What's the use-case for this? >>> >> >> I have a few hundreds of dhcp clients and a two nodes pseudo cluster (for >> the VIP). >> I need a solution that enable high availability on the same level of >> service. >> >> That way, if one node fails, the other can fully take over. >> >> You are presumably aware that you can do "allow-update-forwarding" on >>> slaves and they'll forward UPDATE packets to the master (and >>> presumably >>> then receive NOTIFY and do an IXFR to receive the updated zone)? >>> >> >> If the master fails I'm screwd :/ >> > > Ah. Sorry, no idea then. > > Is it possible to put couple of BIND Servers behind a load balancer and both of them act as authoritative to accept DDNS? Question to BIND Engineering? Is there a plan to add Multi-Master functionality to BIND in future? It may not be big deal for people who don't use BIND as Active Directory DNS Server, but its single point of failure, if BIND is used in an AD Environment since DDNS requests will be send to single master. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
