Re: ipv6 BIND reverse lookup question/problem
Bryce, The following format is correct: 2.5.0.0.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa Webmin is formatting the entry incorrectly. Regards, David Dr David Holder CEng FIET MIEEE Erion Ltd, Oakleigh, Upper Sutherland Road, Halifax, HX3 8NT Reception: +44 (0)1422 207000 Direct Dial: +44 (0)131 2026317 Cell: +44 (0) 7768 456831 Registered in England and Wales. Registered Number 3521142 VAT Number: GB 698 3633 78 Bryce Burgess (bburgess) wrote: > I don't get an "ANSWER SECTION" part of the response to a 'dig -x' cmd > for the reverse lookup for IPV6 addresses. I do for IPV4. > Is the format of the reverse ipv6 not correct? > Webmin automatically gen's the green and will not allow the blue data > below to be entered (complains of invalid data when attempting to > save). I'd assume this green format is correct (since the webmin util > gen'd it), but the 'dig -x' does not return an "ANSWER" section. > Shouldn't it? or is this normal? > The green seems to be a mix of two formats, the full fwd ipv6 address > and appended with the partial reverse arpa data) > > all the forward lookups seem to be fine (for both ipv4 and ipv6). > > Should I direct my questions to webmin community? > > thx, > ice.burge > > Shouldn't the reverse table entry contain the following: > [ > 2.5.0.0.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa > ] > and not the following: > [ > :0fd6:000a:::::0011:0052.0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa. > > ] > > from Fedore Linux 7 install and webmin 1.441 > BIND version 9.4.0, > > from "BIND DNS Server" within Webmin, went to "module config" and set > IPV6 to yes, applied changes. > created (fwd) domain se070.com > created (rev) domain 10.11.11.0 > created (rev) domain fd6:a::/64 > assigned dns address 10.11.11.52 and 'yes' to rev update. noted new > entry in reverse table > [ 52.11.11.10.in-addr.arpa. ] > > assigned dns address 10.11.11.52 and 'yes' to rev update. noted new > entry in reverse table > [ > :0fd6:000a:::::0011:0052.0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa. > > ] > > from root, I type in: > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > [r...@a024 bryce]# dig -x fd6:a::11:52 > > ; <<>> DiG 9.4.0 <<>> -x fd6:a::11:52 > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1342 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;2.5.0.0.1.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa. > IN PTR > > ;; AUTHORITY SECTION: > 0.0.0.0.0.0.0.0.a.0.0.0.6.d.f.0.ip6.arpa. 38400 IN SOA a024.se070.com. > bburgess.cisco.com. 1232145084 10800 3600 604800 38400 > > ;; Query time: 0 msec > ;; SERVER: 10.11.11.24#53(10.11.11.24) > ;; WHEN: Fri Jan 16 16:53:38 2009 > ;; MSG SIZE rcvd: 155 > > [r...@a024 bryce]# dig -x 10.11.11.52 > > ; <<>> DiG 9.4.0 <<>> -x 10.11.11.52 > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9534 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;52.11.11.10.in-addr.arpa. IN PTR > > ;; ANSWER SECTION: > 52.11.11.10.in-addr.arpa. 3600 IN PTR se070-cm13-02.se070.com. > > ;; Query time: 0 msec > ;; SERVER: 10.89.114.40#53(10.89.114.40) > ;; WHEN: Fri Jan 16 16:53:50 2009 > ;; MSG SIZE rcvd: 79 > > [r...@a024 bryce]# > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > [r...@a024 bryce]# dig se070-cm13-02.se070.com > > ; <<>> DiG 9.4.0 <<>> se070-cm13-02.se070.com > ;; global options: printcmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51165 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 > > ;; QUESTION SECTION: > ;se070-cm13-04.se070.com. IN > > ;; ANSWER SECTION: > se070-cm13-02.se070.com. 38400 IN fd6:a::11:52 > > ;; AUTHORITY SECTION: > se070.com. 38400 IN NS a024.se070.com. > > ;; Query time: 0 msec > ;; SERVER: 10.11.11.24#53(10.11.11.24) > ;; WHEN: Fri Jan 16 16:39:33 2009 > ;; MSG SIZE rcvd: 88 > > [r...@a024 bryce]# > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > ___ > 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
Re: Avoiding being used as DDoS reflector.
Nathan Ollerenshaw escreveu: I have an Authoritative BIND server. It is configured to only allow recursive queries from localhost, with recursion disabled for any remote clients. If you attempt to perform a recursive query against this server, it will respond with a "query refused" packet, as this is what BIND does if you try to recursively query a server configured to disallow recursive queries. [ ] Any ideas? Anyone facing this same problem found a solution? I'd be glad to hear it :) if you're running authoritative only for localhost and is not answering network requests at all, then you could probably firewall incoming packets to UDP 53 port !!! Let the responses in, let the new requests out. i cant imagine anything simplier than that. -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email gertru...@solutti.com.br My SPAMTRAP, do not email it ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Avoiding being used as DDoS reflector.
Leonardo Rodrigues Magalhães escreveu:
Nathan Ollerenshaw escreveu:
I have an Authoritative BIND server. It is configured to only allow
recursive queries from localhost, with recursion disabled for any
remote clients.
If you attempt to perform a recursive query against this server, it
will respond with a "query refused" packet, as this is what BIND does
if you try to recursively query a server configured to disallow
recursive queries.
[ ]
Any ideas? Anyone facing this same problem found a solution? I'd be
glad to hear it :)
if you're running authoritative only for localhost and is not
answering network requests at all, then you could probably firewall
incoming packets to UDP 53 port !!! Let the responses in, let the new
requests out.
i cant imagine anything simplier than that.
even simplier than that would be:
options {
...
listen-on { 127.0.0.1; };
};
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertru...@solutti.com.br
My SPAMTRAP, do not email it
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Conflicting glue records?
On Thu, Jan 08, 2009 at 02:46:44AM -0800, Milo Hyson wrote a message of 127 lines which said: > stale glue records for our name-servers that appear to be coming > from a domain we host that is owned by someone else. I don't really like to work on hypothetical situations. Either you post the relevant domain name, or I would not believe you. > This raises a scary question. If this is really an undefined > situation, could it be used as an attack vector? Although our > particular situation involves no component of fraud, what is to stop > someone from registering a domain and listing our server name with a > bogus IP? For someone to "register a domain and listing our server name with a bogus IP", the registry has to be incredibly careless (and, as Matthew Pounsett mentioned, with EPP, it would be impossible). A registry must not accept to register host records for domains outside of the client's control. Otherwise, it would indeed be an attack vector. A weakness in ".com" is that the registrar, not only the registry, has to enforce this rule since the registry apparently only checks that the two domains are in the same registrar. So, if the security procedures of the registrar are unsound, one client of this registrar can attack another client of the same registrar. Choose your registrar carefully. (Or choose a TLD where control is per-holder, not per-registrar.) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Avoiding being used as DDoS reflector.
On Jan 19, 2009, at 5:02 AM, Leonardo Rodrigues Magalhães wrote: Nathan Ollerenshaw escreveu: I have an Authoritative BIND server. It is configured to only allow recursive queries from localhost, with recursion disabled for any remote clients. If you attempt to perform a recursive query against this server, it will respond with a "query refused" packet, as this is what BIND does if you try to recursively query a server configured to disallow recursive queries. [ ] Any ideas? Anyone facing this same problem found a solution? I'd be glad to hear it :) if you're running authoritative only for localhost and is not answering network requests at all, then you could probably firewall incoming packets to UDP 53 port !!! Let the responses in, let the new requests out. i cant imagine anything simplier than that. If you need 53 to answer for authoritative zones, you could run two bind instances, one for your caching server, the other for the authoritative data. Then a firewall or instance-wide black-hole config would take care of it. Not too inspired a solution, but it's all I can think of. I fear that what you are seeing is difficult to handle, thus may well become only more popular as time passes, especially if it really does cause trouble for the victim. If the traffic is negligible for you, then does it really hurt the victim? How would they be harmed? Is the victim someone who queries your authoritative server enough to get some confusing "hits" of matching port, ID, and server of outstanding queries? Even if you block recursive error returns, would an attack using valid authoritative answers be equally harmful to the victim? John ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unified Root - Domain Configuration Issue
Well - like I said below - it is not recommended to simply use http://tld/ - however there are a few IANA TLDs that in fact are setup with A records associated with TLDs. Just did a test out of curiosity and found the following ccTLDs with A records. AC. 86400 IN A 193.223.78.210 AF. 86400 IN A 65.219.4.91 AI. 14400 IN A 209.59.119.34 BI. 38400 IN A 196.2.8.205 CM. 3600 IN A 195.24.192.17 DK. 86400 IN A 193.163.102.23 HK. 604800 IN A 203.119.2.28 IO. 604800 IN A 193.223.78.212 PH. 86400 IN A 203.119.4.7 PN. 43200 IN A 80.68.93.100 PW. 600 IN A 203.199.114.33 SH. 86400 IN A 64.251.31.234 TM. 86400 IN A 193.223.78.213 UZ. 14400 IN A 195.158.1.25 WS. 21600 IN A 63.101.245.10 Cheers Joe Baptista On Sun, Jan 18, 2009 at 9:49 PM, Joe Baptista wrote: > > > On Sun, Jan 18, 2009 at 9:39 PM, Mark Andrews wrote: > >> >> >> http://tld and u...@tld can *never* work *reliably* as they >>would cause namespace clashes. Single label represent local >>names not global names. > > > Thats incorrect. It does work but is not recommended because it does not > always work depending on the application. If the application relies solely > on gethostbyname then it will probably work - but some applications do a bit > more checking of the domain name and not all applications will allow it. > > cheers > joe baptista > > -- > Joe Baptista > www.publicroot.org > PublicRoot Consortium > > The future of the Internet is Open, Transparent, Inclusive, Representative > & Accountable to the Internet community @large. > > Office: +1 (360) 526-6077 (extension 052) > Fax: +1 (509) 479-0084 > > -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unified Root - Domain Configuration Issue
So a little more testing using firefox as an application gives us some interesting results. Using the .TM TLD I entered http://tm/ into my browsers. It did not work. Firefox replaced http://tm/ with http://www.tm.com/ - which is not the web site I wanted to reach. However - if we qualify the TLD by adding a "." to the end, i.e. http://tm./it does work under firefox and I get connected to the correct site. The same applies to ping. If we just use TM we get this result: bapti...@baptista-laptop:/tmp/test.temp$ ping tm ping: unknown host tm however if we add the "." to the end of TM - it works, example: bapti...@baptista-laptop:/tmp/test.temp$ ping tm. PING tm (193.223.78.213) 56(84) bytes of data. 64 bytes from serv213.icb.co.uk (193.223.78.213): icmp_seq=1 ttl=51 time=96.2 ms Like I said - not recommended - but it does work - sort of. regards joe baptista On Mon, Jan 19, 2009 at 11:02 AM, Joe Baptista wrote: > Well - like I said below - it is not recommended to simply use http://tld/- > however there are a few IANA TLDs that in fact are setup with A records > associated with TLDs. Just did a test out of curiosity and found the > following ccTLDs with A records. > > AC. 86400 IN A 193.223.78.210 > AF. 86400 IN A 65.219.4.91 > AI. 14400 IN A 209.59.119.34 > BI. 38400 IN A 196.2.8.205 > CM. 3600 IN A 195.24.192.17 > DK. 86400 IN A 193.163.102.23 > HK. 604800 IN A 203.119.2.28 > IO. 604800 IN A 193.223.78.212 > PH. 86400 IN A 203.119.4.7 > PN. 43200 IN A 80.68.93.100 > PW. 600 IN A 203.199.114.33 > SH. 86400 IN A 64.251.31.234 > TM. 86400 IN A 193.223.78.213 > UZ. 14400 IN A 195.158.1.25 > WS. 21600 IN A 63.101.245.10 > > Cheers > Joe Baptista > > > On Sun, Jan 18, 2009 at 9:49 PM, Joe Baptista wrote: > >> >> >> On Sun, Jan 18, 2009 at 9:39 PM, Mark Andrews wrote: >> >>> >>> >>> http://tld and u...@tld can *never* work *reliably* as they >>>would cause namespace clashes. Single label represent local >>>names not global names. >> >> >> Thats incorrect. It does work but is not recommended because it does not >> always work depending on the application. If the application relies solely >> on gethostbyname then it will probably work - but some applications do a bit >> more checking of the domain name and not all applications will allow it. >> >> cheers >> joe baptista >> >> -- >> Joe Baptista >> www.publicroot.org >> PublicRoot Consortium >> >> The future of the Internet is Open, Transparent, Inclusive, Representative >> & Accountable to the Internet community @large. >> >> Office: +1 (360) 526-6077 (extension 052) >> Fax: +1 (509) 479-0084 >> >> > > > -- > Joe Baptista > www.publicroot.org > PublicRoot Consortium > > The future of the Internet is Open, Transparent, Inclusive, Representative > & Accountable to the Internet community @large. > > Office: +1 (360) 526-6077 (extension 052) > Fax: +1 (509) 479-0084 > > -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Unified Root - Domain Configuration Issue
On Jan 19 2009, Joe Baptista wrote: So a little more testing using firefox as an application gives us some interesting results. Using the .TM TLD I entered http://tm/ into my browsers. It did not work. Firefox replaced http://tm/ with http://www.tm.com/ - which is not the web site I wanted to reach. However - if we qualify the TLD by adding a "." to the end, i.e. http://tm./it does work under firefox and I get connected to the correct site. This depends on the behavior of your local resolver, and probably on how Firefox is configured as well. http://tm/ works fine for me. The same applies to ping. If we just use TM we get this result: bapti...@baptista-laptop:/tmp/test.temp$ ping tm ping: unknown host tm however if we add the "." to the end of TM - it works, $ /usr/sbin/ping tm tm is alive (and yes, that really is 193.223.78.213 it is pinging, not a local tm.[some-domain]). Like I said - not recommended - but it does work - sort of. Why does this remind me of the chap whose vanity e-mail address was "s...@tc"? (Yes, that was the complete fully expanded address.) -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Avoiding being used as DDoS reflector.
On Jan 19, 2009, at 7:48 AM, John Wobus wrote: Nathan Ollerenshaw escreveu: I have an Authoritative BIND server. It is configured to only allow recursive queries from localhost, with recursion disabled for any remote clients. If you attempt to perform a recursive query against this server, it will respond with a "query refused" packet, as this is what BIND does if you try to recursively query a server configured to disallow recursive queries. [ ] Any ideas? Anyone facing this same problem found a solution? I'd be glad to hear it :) If you need 53 to answer for authoritative zones, you could run two bind instances, one for your caching server, the other for the authoritative data. Then a firewall or instance- wide black-hole config would take care of it. Not too inspired a solution, but it's all I can think of. I fear that what you are seeing is difficult to handle, thus may well become only more popular as time passes, especially if it really does cause trouble for the victim. If the traffic is negligible for you, then does it really hurt the victim? How would they be harmed? Is the victim someone who queries your authoritative server enough to get some confusing "hits" of matching port, ID, and server of outstanding queries? Even if you block recursive error returns, would an attack using valid authoritative answers be equally harmful to the victim? What's happening is, the attacker uses a botnet to send recursive packets for ./IN/NS (or any other query likely to get a large response) to a large number "reflectors", using a spoofed source address (the address of the target). one controller 10 bots 100 reflectors (per second - they can change from one second to another) one target The controller (the bot herder) already has an efficient way to control his botnet. Each bot (a compromised machine, usually running Windows, that's owned by an unsuspecting normal person) sends 10 DNS packets per second to 10 different servers - not very much traffic. Each reflector, a DNS server that accepts any kind of query from the Internet, sees 1 query per second (or less) - a very small amount of traffic. So none of these machines are seeing much load. The target gets one million bogus responses per second. Chris Buxton Professional Services Men & Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Unified Root - Domain Configuration Issue
This issue of how applications and operating systems resolve single-word TLDs and host names was discussed on NANOG some time ago: http://www.mail-archive.com/na...@nanog.org/msg03092.html Regards, Frank -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris Thompson Sent: Monday, January 19, 2009 11:56 AM To: Bind Users Mailing List Subject: Re: Unified Root - Domain Configuration Issue On Jan 19 2009, Joe Baptista wrote: >So a little more testing using firefox as an application gives us some >interesting results. Using the .TM TLD I entered http://tm/ into my >browsers. It did not work. Firefox replaced http://tm/ with >http://www.tm.com/ - which is not the web site I wanted to reach. > >However - if we qualify the TLD by adding a "." to the end, i.e. >http://tm./it does work under firefox and I get connected to the >correct site. This depends on the behavior of your local resolver, and probably on how Firefox is configured as well. http://tm/ works fine for me. >The same applies to ping. If we just use TM we get this result: > >bapti...@baptista-laptop:/tmp/test.temp$ ping tm >ping: unknown host tm > >however if we add the "." to the end of TM - it works, $ /usr/sbin/ping tm tm is alive (and yes, that really is 193.223.78.213 it is pinging, not a local tm.[some-domain]). >Like I said - not recommended - but it does work - sort of. Why does this remind me of the chap whose vanity e-mail address was "s...@tc"? (Yes, that was the complete fully expanded address.) -- Chris Thompson Email: c...@cam.ac.uk ___ 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
Re: SERVFAIL issues
At Sat, 17 Jan 2009 00:37:25 -0600, "Frank Bulk" wrote: > Thanks for the info -- is there a way that there can be feature parity, at > least in terms of stats reported, between ARM and "rndc stats"? I don't understand the question...what do you mean by 'feature parity between ARM and "rndc stats"'? Anyway, the fact is that the ARM describes both the output of 'rndc stats' and the output from a HTTML statistics channel (to some extent). In general, what is described in the ARM should be consistent with the actual behavior. Of course, there can always be a discrepancy between a manual (ARM) and the software behavior as long as it's done by a human. Please file a bug report if you find one. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: max open files vs max sockets
At Sat, 17 Jan 2009 12:06:13 -0600 (CST), David Forrest wrote: > On startup of named 9.6.0 I get the following message: > > Jan 17 11:55:20 maplepark named[13014]: max open files (1024) is smaller than > max sockets (4096) > > Is this a problem for a small internal network dns server? It depends on the definition of 'a small internal network dns server', but I'd say 'no, it's not a problem per se' unless you see run-time warning messages like a failure of opening a socket. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9.5.1 Multithreading
At Sat, 17 Jan 2009 23:18:59 +0330, "Bind" wrote: > I have worked with bind 9 in single thread,but i want to upgrade my server > to solaris 10 and bind 9.5.1-P1(my machine has 4Gig Ram and 2 cpu(900mhz)) > Based on practical experience: > does enable multithreading for Bind 9.5.1 is good or not? > (with considering stability and simple management) In general, it should be good, especially your environment supports machine (+ compiler) dependent atomic operations. You can detect it from the output of the "configure" script. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Avoiding being used as DDoS reflector.
At Mon, 19 Jan 2009 16:40:28 +1100, Nathan Ollerenshaw wrote: > I have an Authoritative BIND server. It is configured to only allow > recursive queries from localhost, with recursion disabled for any > remote clients. [snip] > The ideal solution for me, would be a bind configuration option that > could rate limit responses based on type; so you could specify that a > "REFUSED" reply will only be sent to a given host once per hour, or > something like that. Rate-limiting REFUSED responses doesn't make much sense in this context, because the response messages are not (that) amplified in packet size. Even if you rate-limited REFUSED responses, the attacker could exploit other attack vectors. Especially in your case where the server also acts as an authoritative server, the attacker would just send a valid non-recursive query for a name in the authoritative zone with a forged address. IMO, it's not worth considering a counter measure for a non-amplifying DoS attacks, especially if it can make the implementation complicated. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Stub Zones...
Hi,
I have what I hope is an easy question:
When settingup a 'stub' zone, is it only valid to list the primary
server for the zone in the 'masters {...};' config line?
Or is it OK to list secondary servers in that list also?
-Kyle
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Stub Zones...
It's perfectly valid to list any or all of the zone's authoritative
servers, whether they are primary master or slave.
Chris Buxton
Professional Services
Men & Mice
On Jan 19, 2009, at 1:40 PM, Kyle McDonald wrote:
Hi,
I have what I hope is an easy question:
When settingup a 'stub' zone, is it only valid to list the primary
server for the zone in the 'masters {...};' config line?
Or is it OK to list secondary servers in that list also?
-Kyle
___
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
Re: max open files vs max sockets
On Mon, 19 Jan 2009, JINMEI Tatuya / 神明達哉 wrote: At Sat, 17 Jan 2009 12:06:13 -0600 (CST), David Forrest wrote: On startup of named 9.6.0 I get the following message: Jan 17 11:55:20 maplepark named[13014]: max open files (1024) is smaller than max sockets (4096) Is this a problem for a small internal network dns server? It depends on the definition of 'a small internal network dns server', but I'd say 'no, it's not a problem per se' unless you see run-time warning messages like a failure of opening a socket. --- Good. Thanks. It appears to be a kernel bug fixed in 2.6.28. I'm running 2.6.27.9 now and will update as soon as F9 releases it. -- David Forrest St. Louis, Missouri___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: SERVFAIL issues
Sorry for not being more clear. It's my understanding that "rndc stats" dumps only a subset of what ARM provides. Regards, Frank -Original Message- From: JINMEI Tatuya / 神明達哉 [mailto:jinmei_tat...@isc.org] Sent: Monday, January 19, 2009 1:38 PM To: Frank Bulk Cc: bind-us...@isc.org Subject: Re: SERVFAIL issues At Sat, 17 Jan 2009 00:37:25 -0600, "Frank Bulk" wrote: > Thanks for the info -- is there a way that there can be feature parity, at > least in terms of stats reported, between ARM and "rndc stats"? I don't understand the question...what do you mean by 'feature parity between ARM and "rndc stats"'? Anyway, the fact is that the ARM describes both the output of 'rndc stats' and the output from a HTML statistics channel (to some extent). In general, what is described in the ARM should be consistent with the actual behavior. Of course, there can always be a discrepancy between a manual (ARM) and the software behavior as long as it's done by a human. Please file a bug report if you find one. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SERVFAIL issues
In article , "Frank Bulk" wrote: > Sorry for not being more clear. It's my understanding that "rndc stats" > dumps only a subset of what ARM provides. You still don't make sense. ARM is documentation, it doesn't provide any statistics. ARM = Administrator's Reference Manual for BIND. > > Regards, > > Frank > > -Original Message- > From: JINMEI Tatuya / ...@l@C#:H(B [mailto:jinmei_tat...@isc.org] > Sent: Monday, January 19, 2009 1:38 PM > To: Frank Bulk > Cc: bind-us...@isc.org > Subject: Re: SERVFAIL issues > > At Sat, 17 Jan 2009 00:37:25 -0600, > "Frank Bulk" wrote: > > > Thanks for the info -- is there a way that there can be feature parity, at > > least in terms of stats reported, between ARM and "rndc stats"? > > I don't understand the question...what do you mean by 'feature parity > between ARM and "rndc stats"'? > > Anyway, the fact is that the ARM describes both the output of 'rndc > stats' and the output from a HTML statistics channel (to some > extent). In general, what is described in the ARM should be > consistent with the actual behavior. Of course, there can always be > a discrepancy between a manual (ARM) and the software behavior as long > as it's done by a human. Please file a bug report if you find one. > > --- > JINMEI, Tatuya > Internet Systems Consortium, Inc. > > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Barry Margolin, bar...@alum.mit.edu Arlington, MA *** PLEASE don't copy me on replies, I'll read them in the group *** ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
