Re: Bind sometimes SERVFAIL
From: Pawel Rutkowski rut...@freelance-worker.net To: bind-users@lists.isc.org Subject: Bind sometimes SERVFAIL Date: Wed, 11 Nov 2009 07:42:14 +0100 Hello, My Internet ISP give two nameservers address. But when I'm asking those two servers sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: Host d.yimg.com not found: 2(SERVFAIL) I just saw the same thing: metis% host d.timg.com Host d.timg.com not found: 3(NXDOMAIN) metis% !! host d.timg.com Host d.timg.com not found: 3(NXDOMAIN) metis% host d.yimg.com d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net. geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net. fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.88.88 metis% named -v BIND 9.6.1-P1 Above executed in the space of about a minute... but sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net. geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net. fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54 He explain me this thats a normal because of this: http://www.faqs.org/rfcs/rfc2308.html Some resolvers incorrectly continue processing if the authoritative answer flag is not set, looping until the query retry threshold is exceeded and then returning SERVFAIL. This is a problem when your nameserver is listed as a FORWARDER for such resolvers. If the nameserver is used as a FORWARDER by such resolver, the authority flag will have to be forced on for NXDOMAIN responses to these resolvers. In practice this causes no problems even if turned on always, and has been the default behaviour in BIND from 4.9.3 onwards. Is this true ? Thanks Pawel R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Bind sometimes SERVFAIL
Hello, My Internet ISP give two nameservers address. But when I'm asking those two servers sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: Host d.yimg.com not found: 2(SERVFAIL) I just saw the same thing: metis% host d.timg.com Host d.timg.com not found: 3(NXDOMAIN) metis% !! host d.timg.com Host d.timg.com not found: 3(NXDOMAIN) metis% host d.yimg.com d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net. geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net. fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.88.88 metis% named -v BIND 9.6.1-P1 Above executed in the space of about a minute... --- timg yimg but sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net. geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net. fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54 He explain me this thats a normal because of this: http://www.faqs.org/rfcs/rfc2308.html Some resolvers incorrectly continue processing if the authoritative answer flag is not set, looping until the query retry threshold is exceeded and then returning SERVFAIL. This is a problem when your nameserver is listed as a FORWARDER for such resolvers. If the nameserver is used as a FORWARDER by such resolver, the authority flag will have to be forced on for NXDOMAIN responses to these resolvers. In practice this causes no problems even if turned on always, and has been the default behaviour in BIND from 4.9.3 onwards. Is this true ? Thanks Pawel R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users - Gregory Hicks | Principal Systems Engineer | Direct: 408.569.7928 People sleep peaceably in their beds at night only because rough men stand ready to do violence on their behalf -- George Orwell The price of freedom is eternal vigilance. -- Thomas Jefferson The best we can hope for concerning the people at large is that they be properly armed. --Alexander Hamilton ___ 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: bind configuration help
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or allow
any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: bind configuration help
From: Holger Honert [mailto:holger.hon...@signal-iduna.org]
..
*Please be carefull when quoting, this was not me:
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON mailto:lca...@lncsa.com
lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
*This was mine:
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind configuration help
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones for
doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
attachment: holger_honert.vcf___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS Dig returning PTR results only with trace option
Raj Adhikari wrote: Thanks Chris for the reply. Actually, let me put my question the other way. How can one delegate the classless subnet to other DNS? Actually, one of our ISP could not delegate classless subnet to our server ns1.cyzap.net. I am trying to help them in delegating the classless subnet to us. So this scenario is simulating our ISP and us. I was just testing with one of our other subnets checking if delegation will work. Unfortunately, we both are using windows DNS. Windows just have RFC 2317 way on configuring the delegation on it KB article using CNAME, which I think has lots of problems. But I am following this BIND way for delegation. I think, in windows the DNS configuration is more or less similar to BIND. On 10.11.09 17:23, Kevin Darcy wrote: There is no BIND way versus Windows way. For a range smaller than /24 you either need to host all the records in the /24 zone, delegate each entry individually (as /32 zones), or use CNAMEs. This is determined by the protocol, regardless of whether you're using Microsoft DNS, BIND or any other implementation. Note that each domain that is delegated SHOULD have proper SOA and NS records, otherwise strange things (like the one you have envcountered) may happen. If you delegate by adding NS records for each PTR, you create different domains for them. The same applies to forward domains (I've seen examples of single record delegations and related problems) It's much easier and safer to do CNAME delegations. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. My mind is like a steel trap - rusty and illegal in 37 states. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind sometimes SERVFAIL
On Wed, Nov 11, 2009 at 01:27:30PM +0200, Jukka Pakkanen jukka.pakka...@qnet.fi wrote a message of 94 lines which said: I just saw the same thing: There are no less than *four* CNAMEs to resolve to get to the result, while even two is discouraged. It is not suprising that it may fails with resolvers which limit the number of chained CNAME (to avoid endless loops). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind sometimes SERVFAIL
Hello again, I just saw the same thing: Please look below, it's normal ? Sometime servfail, sometimes nxdomain. [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 2(SERVFAIL) [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN) [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN) Thanks Pawel R. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind sometimes SERVFAIL
On 11.11.09 16:05, Pawel Rutkowski wrote: Please look below, it's normal ? Sometime servfail, sometimes nxdomain. [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 2(SERVFAIL) [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN) [r...@linux ~]# host 209.85.255.187 ns1.isp Using domain server: Name: ns1.isp Address: ns1.isp#53 Aliases: Host 187.255.85.209.in-addr.arpa not found: 3(NXDOMAIN) Use 'dig -x 209.85.255.187 @ns1.isp' and look at NS records and TTLs. Invalid delegations and inconsistent NS records (domain is delegated from parent to different servers than those listed in the domain) often cause these kinds of problems. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Emacs is a complicated operating system without good text editor. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse DNS Dig returning PTR results only with trace option
In message 4afa0555.6070...@cyzap.com, Raj Adhikari writes:
Kevin Wrote: {QUOTE} There is no BIND way versus Windows way. For a
range smaller than /24 you either need to host all the records in the
/24 zone, delegate each entry individually (as /32 zones), or use
CNAMEs. This is determined by the protocol, regardless of whether you're
using Microsoft DNS, BIND or any other implementation.
Note that many thousands (tens of thouands? hundreds of thousands?) or
organizations use RFC 2317 for their reverse DNS without issues. So, on
what do you base your assessment of this approach as having lots of
problems? The folks who published RFC 2317 actually know what they're
talking about. People complaining on forums about having botched their
RFC 2317 configs, probably *don't*.
{QUOTE}
Ok, moving to RFC 2317, I may not have configured them correctly. If RFC
2317 will work for me then that would be great. This time I took the
subnet 64.253.134.176/28. This block needs to be delegated from
ns1.cyzap.net to ns1.moneytreesystems.com
I followed this for the configuration and naming convention from
http://support.microsoft.com/kb/174419.
I configured at ns1.cyzap.net as:
; Database file 134.254.63.in-addr.arpa.dns for 134.254.63.in-addr.arpa
zone.
; Zone version:
;
@ IN SOA ns1.cyzap.net. .. (
...
;
; Zone NS records
;
@ NSns1.cyzap.net.
@ NSns2.cyzap.net.
; Delegated sub-zone: 176-28.134.254.63.in-addr.arpa.
;
176-28 NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
ns1.moneytreesystems.com. A63.254.134.214
; End delegation
177 CNAME177.176-28.134.254.63.in-addr.arpa.
And at ns1.moneytreesystems.com, the configuration is as:
;
; Database file 176-28.134.254.63.in-addr.arpa.dns for
176-28.134.254.63.in-addr.arpa zone.
; Zone version: xx
;
@ IN SOA ns1.moneytreesystems.com.
hostmaster.moneytreesystems.com. (
.
.
;
; Zone NS records
;
@ NSns1.moneytreesystems.com.
ns1.moneytreesystems.com. A63.254.134.213
;
; Zone records
;
177 PTRtestnew177.cyzap.net.
My dig output for this are:
$ dig @ns1.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns1.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 50666
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 60 IN PTR testnew177.cyzap.net.
;; Query time: 3 msec
;; SERVER: 172.30.111.3#53(172.30.111.3)
;; WHEN: Tue Nov 10 18:06:59 2009
;; MSG SIZE rcvd: 104
$ dig @ns2.cyzap.net -x 63.254.134.177
; DiG 9.4.2 @ns2.cyzap.net -x 63.254.134.177
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 58836
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 3600 INCNAME
177.176-28.134.254.63.in-addr.arpa.
177.176-28.134.254.63.in-addr.arpa. 55 IN PTR testnew177.cyzap.net.
;; Query time: 0 msec
;; SERVER: 172.30.111.53#53(172.30.111.53)
;; WHEN: Tue Nov 10 18:20:13 2009
;; MSG SIZE rcvd: 104
==
$ dig -x 63.254.134.177
; DiG 9.4.2 -x 63.254.134.177
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 60512
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;177.134.254.63.in-addr.arpa. IN PTR
;; ANSWER SECTION:
177.134.254.63.in-addr.arpa. 2985 INCNAME
177.176-28.134.254.63.in-addr.arpa.
;; Query time: 0 msec
;; SERVER: 172.30.111.254#53(172.30.111.254)
;; WHEN: Tue Nov 10 18:07:18 2009
;; MSG SIZE rcvd: 70
===
$ dig -x 63.254.134.177 +trace
; DiG 9.4.2 -x 63.254.134.177 +trace
;; global options: printcmd
. 54948 IN NS j.root-servers.net.
. 54948 IN NS c.root-servers.net.
. 54948 IN NS k.root-servers.net.
. 54948 IN NS b.root-servers.net.
. 54948
Re: Bind sometimes SERVFAIL
Generally speaking, it's not a good idea to use RFCs to diagnose operational issues, unless you've already narrowed the problem down to some sort of standard-conformance or interoperability issue. What is described below is merely one of potentially *dozens* of different causes of a SERVFAIL result. Follow normal root-cause analysis. Eliminate variables/causes. Understand and test dependencies. Get to the heart of the matter. If you don't know how to do that personally, escalate to someone who does. - Kevin Pawel Rutkowski wrote: Hello, My Internet ISP give two nameservers address. But when I'm asking those two servers sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: Host d.yimg.com not found: 2(SERVFAIL) but sometimes I get: [r...@linux ~]# host d.yimg.com ns.my.isp Using domain server: Name: ns.my.isp Address: ns.my.isp#53 Aliases: d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net. geoycs-d.gy1.b.yahoodns.net is an alias for fo-anyycs-d.ay1.b.yahoodns.net. fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54 He explain me this thats a normal because of this: http://www.faqs.org/rfcs/rfc2308.html Some resolvers incorrectly continue processing if the authoritative answer flag is not set, looping until the query retry threshold is exceeded and then returning SERVFAIL. This is a problem when your nameserver is listed as a FORWARDER for such resolvers. If the nameserver is used as a FORWARDER by such resolver, the authority flag will have to be forced on for NXDOMAIN responses to these resolvers. In practice this causes no problems even if turned on always, and has been the default behaviour in BIND from 4.9.3 onwards. Is this true ? Thanks Pawel R. ___ 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: bind configuration help
Holger Honert wrote:
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones
for doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
If the infos are public, they're public, the only difference is that
zone transfers are a more efficient way of fetching more than about 2 or
3 records in a single transaction, compared to querying each one
individually.
If you want your network and infrastructure infos to be private, then
put them in a private zone that can't be queried from the Internet at all.
- Kevin
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or allow any
transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
___
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: bind configuration help
I can't quite agree with that.
While public information is indeed public it is intended to be so for specific
lookups not for zone transfers. Someone external to you asking get a zone
transfer may be looking for what he can exploit. Maybe he can find that
information anyway with enough digging but why make it easy for him?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Wednesday, November 11, 2009 12:53 PM
To: bind-users@lists.isc.org
Subject: Re: bind configuration help
Holger Honert wrote:
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones
for doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
If the infos are public, they're public, the only difference is that
zone transfers are a more efficient way of fetching more than about 2 or
3 records in a single transaction, compared to querying each one
individually.
If you want your network and infrastructure infos to be private, then
put them in a private zone that can't be queried from the Internet at all.
- Kevin
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
___
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
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
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.
--
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind configuration help
Jeff Lightner wrote:
I can't quite agree with that.
While public information is indeed public it is intended to be so for specific lookups not for zone transfers.
Circular argument: allowing zone transfers is bad if one didn't intend
to allow zone transfers.
Someone external to you asking get a zone transfer may be looking for what he can exploit.
Speculative argument: someone may do something bad with information that
was intentionally made public.
Maybe he can find that information anyway with enough digging but why make it easy for him?
On the other hand, why make it harder for good and bad folks alike?
Superfluous concealment often raises curiosity and attracts probing.
(Don't even get me started on whether BIND version numbers should be
suppressed/spoofed; I think you might be able to guess where I stand on
that too).
Why not allow knowledgeable experts to diagnose problems with your
external-facing zones, or business partners to set up stealth slaves,
if they wish, for architectural, performance and/or availability
reasons, without having to reconfigure one's nameserver, and/or
generate/distribute a TSIG key, every time they want to?
Consider long and deep how much configuration complexity and churn
raises opportunities for infrastructure breakins and/or denials of
service, perhaps far more than simple information disclosures ever could...
- Kevin
P.S. I've already lost this argument in our own organization, so don't
even bother with the practice what you preach observation. I can but
offer advice to others to avoid such a ridiculous state of affairs.
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Wednesday, November 11, 2009 12:53 PM
To: bind-users@lists.isc.org
Subject: Re: bind configuration help
Holger Honert wrote:
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones
for doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
If the infos are public, they're public, the only difference is that
zone transfers are a more efficient way of fetching more than about 2 or
3 records in a single transaction, compared to querying each one
individually.
If you want your network and infrastructure infos to be private, then
put them in a private zone that can't be queried from the Internet at all.
- Kevin
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or allow any
transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
___
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
Proud partner. Susan G. Komen for the Cure.
Please consider our environment before printing this e-mail or attachments.
--
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential
System Resolver Test App?
All, It has been a long day so please excuse me if I am over looking something trivial. I am wondering if anyone knows of an app similar to nslookup or dig that actually uses the system resolver. I spent a decent amount of time this morning trouble shooting an issue where a third invalid nameserver entry within the /etc/resolv.conf (CentOS) cause me much grief. My trusty tools nslookup dig failed me because they worked as expected while the system resolver did not. I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first. Thanks, David Porsche___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind configuration help
Hi,
first of all thanks to everyone for the interest and for pointing me
out my mistakes :) I've already changed recursion and transfer to
trusted acls. But unfortunately, I've been administering this server
for a short time and as I'm reading more and more through the
configuration, I'm starting to think that this DNS server is
completely misconfigured. Before I ask my next question, I'll try to
explain my situation a little:
The server I'am administering is one of nine, let's say, units,
which are parts of bigger organization (let's say organization.com, it
doesn't really matter). They units are given domain names from
first.organization.com to ninth.organization.com. Each unit's server
is responsible for their subdomains, i.e. a.first.organization.com,
b.first.organization.com, and so on... At the same time, they should
be synchronized with the main dns server of the organization, let's
say dns.organization.com, and also act as a dns server of it's own,
providing information about i.e. for first, *.first.organization.com.
I think my name cannot be resolved after some time problem
(NXDOMAIN, I've checked it) lies somewhere in the synchronization
part. I'll post a part of my zone file, which is responsible for the
domain and which is, I think, the source of this problem:
***
$TTL604800
@ IN SOA dns.organization.com. first.organization.com. (
2006120508 ; Serial
3600 ; Refresh
86400 ; Retry
2419200 ; Expire
604800); Negative Cache TTL
;
NS first.organization.com.
NS dns.organization.com.
***
The problem is, I don't even know if *I* should synchronize with
*them* (the main dns server) or vice versa, maybe it's not my problem
at all. Also, who should I allow-update {} the zone, should the zone
be of type master and what is the authoritative server for the zone:
the one I'm administering or the main dns server or maybe both are ok?
Thanks in advance:)
On Wed, Nov 11, 2009 at 7:09 PM, Jeff Lightner jlight...@water.com wrote:
I can't quite agree with that.
While public information is indeed public it is intended to be so for
specific lookups not for zone transfers. Someone external to you asking get
a zone transfer may be looking for what he can exploit. Maybe he can find
that information anyway with enough digging but why make it easy for him?
-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Kevin Darcy
Sent: Wednesday, November 11, 2009 12:53 PM
To: bind-users@lists.isc.org
Subject: Re: bind configuration help
Holger Honert wrote:
Security issues!
Usually you only want *trusted* clients to use your server recursively.
And you don't really want to allow *any* fetching your hosted zones
for doing something bad, i.e. getting (unwanted!) infos
over your network and infrastructure.
If the infos are public, they're public, the only difference is that
zone transfers are a more efficient way of fetching more than about 2 or
3 records in a single transaction, compared to querying each one
individually.
If you want your network and infrastructure infos to be private, then
put them in a private zone that can't be queried from the Internet at all.
- Kevin
Regards
Holger
Jukka Pakkanen schrieb:
Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
allow-recursion { any; };
bad
allow-transfer { any; };
bad
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
SIGNAL Krankenversicherung a. G., Sitz: Dortmund, HR B 2405, AG Dortmund
IDUNA Vereinigte Lebensversicherung aG für Handwerk, Handel und Gewerbe,
Sitz: Hamburg, HR B 2740, AG Hamburg
Deutscher Ring Krankenversicherungsverein a.G., Sitz: Hamburg,
HR B 4673, AG Hamburg,
SIGNAL IDUNA Allgemeine Versicherung AG, Sitz: Dortmund, HR B 19108,
AG Dortmund
Vorstände: Reinhold Schulte (Vorsitzender),
Wolfgang Fauter (stellv. Vorsitzender), Dr. Karl-Josef Bierth,
Jens O. Geldmacher, Marlies Hirschberg-Tafel,
Michael Johnigk, Ulrich Leitermann, Michael Petmecky,
Dr. Klaus Sticker, Prof. Dr. Markus Warg
Vorsitzender der Aufsichtsräte: Günter Kutz
SIGNAL IDUNA Gruppe Hauptverwaltungen, Internet: www.signal-iduna.de
44121 Dortmund, Hausanschrift: Joseph-Scherer-Str. 3, 44139 Dortmund
20351 Hamburg, Hausanschrift: Neue Rabenstraße 15-19, 20354 Hamburg
___
bind-users mailing list
Re: System Resolver Test App?
In article mailman.961.1257980410.14796.bind-us...@lists.isc.org, da...@from525.com da...@from525.com wrote: All, It has been a long day so please excuse me if I am over looking something trivial. I am wondering if anyone knows of an app similar to nslookup or dig that actually uses the system resolver. I spent a decent amount of time this morning trouble shooting an issue where a third invalid nameserver entry within the /etc/resolv.conf (CentOS) cause me much grief. My trusty tools nslookup dig failed me because they worked as expected while the system resolver did not. I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first. I'm not sure if there is one, but it should be pretty easy to write a program that calls res_query(). But it doesn't seem like this would be much help in troubleshooting, because when it gets an error you won't be able to tell why. There's no way for it to indicate that the error is because it was stuck on the third server. -- 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
Re: System Resolver Test App?
On Wed, Nov 11, 2009 at 05:00:03PM -0600, da...@from525.com da...@from525.com wrote a message of 60 lines which said: I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first. tcpdump ? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
On Wed, Nov 11, 2009 at 07:44:05PM -0500, Barry Margolin bar...@alum.mit.edu wrote a message of 27 lines which said: I'm not sure if there is one, but it should be pretty easy to write a program that calls res_query(). But this calls directly the DNS. The OP wanted something which called the system resolver, which means getaddrinfo(), not res_query(). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
On Wed, Nov 11, 2009 at 05:00:03PM -0600,
da...@from525.com da...@from525.com wrote
a message of 60 lines which said:
I am wondering if anyone knows of an app similar to nslookup or
dig that actually uses the system resolver.
C source attached. Compile, for instance, with:
gcc -o resolve-name resolve-name.c
I am basically trying to uinderstand why the system resolver was
getting stuck on the third entry within the resolv.conf while it
should have tried one of the first two working DNS servers first.
Not sure it will help.
#include stdbool.h
#include stdlib.h
#include unistd.h
#include stdio.h
#include string.h
#include sys/types.h
#include sys/socket.h
#include netdb.h
#include arpa/inet.h
#include errno.h
#include netinet/in.h
#include netinet/ip.h
#include netinet/ip6.h
#define MAXHOSTNAMELEN 256
charprogname[MAXHOSTNAMELEN + 1];
void
usage()
{
fprintf(stderr, Usage: %s hostname\n, progname);
}
char *
text_of(struct sockaddr *address)
{
char *text = malloc(INET6_ADDRSTRLEN);
struct sockaddr_in6 *address_v6;
struct sockaddr_in *address_v4;
if (address-sa_family == AF_INET6) {
address_v6 = (struct sockaddr_in6 *) address;
inet_ntop(AF_INET6, address_v6-sin6_addr, text, INET6_ADDRSTRLEN);
} else if (address-sa_family == AF_INET) {
address_v4 = (struct sockaddr_in *) address;
inet_ntop(AF_INET, address_v4-sin_addr, text, INET_ADDRSTRLEN);
} else {
return ([Unknown family address]);
}
return text;
}
int
main(int argc, char **argv)
{
charhostname[MAXHOSTNAMELEN + 1];
struct addrinfo hints_numeric, hints;
struct addrinfo *result, *hostref;
int status;
strncpy(progname, argv[0], MAXHOSTNAMELEN);
progname[MAXHOSTNAMELEN] = 0;
if (argc != 2) {
usage();
exit(1);
}
strncpy(hostname, argv[1], MAXHOSTNAMELEN);
hostname[MAXHOSTNAMELEN] = 0;
/* RFC 1123 says we must try IP addresses first */
memset(hints_numeric, 0, sizeof(hints_numeric));
hints_numeric.ai_flags = AI_NUMERICHOST;
hints_numeric.ai_socktype = SOCK_STREAM;
result = malloc(sizeof(struct addrinfo));
status = getaddrinfo(hostname, NULL, hints_numeric, result);
if (!status) {
fprintf(stdout, %s is an IP address\n, hostname);
} else {
if (status == EAI_NONAME) {
/* Not an IP address */
memset(hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
result = malloc(sizeof(struct addrinfo));
status = getaddrinfo(hostname, NULL, hints, result);
if (status) {
fprintf(stderr, Nothing found about host name %s\n, hostname);
abort();
}
} else {
fprintf(stderr, Internal error, cannot resolve %s (error %i)\n,
hostname, status);
abort();
}
fprintf(stdout, Address(es) of %s is(are):, hostname);
fprintf(stdout, %s , text_of(result-ai_addr));
for (hostref = result-ai_next; hostref != NULL; hostref = hostref-ai_next) {
fprintf(stdout, %s , text_of(hostref-ai_addr));
}
fprintf(stdout, \n);
}
exit(0);
}
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
In article mailman.966.1257988033.14796.bind-us...@lists.isc.org, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Nov 11, 2009 at 07:44:05PM -0500, Barry Margolin bar...@alum.mit.edu wrote a message of 27 lines which said: I'm not sure if there is one, but it should be pretty easy to write a program that calls res_query(). But this calls directly the DNS. The OP wanted something which called the system resolver, which means getaddrinfo(), not res_query(). Considering the problem he was trying to solve, I didn't think he cared about things like /etc/hosts, he just wants to exercise the DNS stub resolver. If you just want to do a hostname lookup, you can use practically any network application, e.g. ping. And how would you use getaddrinfo() to test MX lookups, for instance? -- 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
Re: System Resolver Test App?
On Wed, Nov 11, 2009 at 08:14:02PM -0500, Barry Margolin bar...@alum.mit.edu wrote a message of 24 lines which said: If you just want to do a hostname lookup, you can use practically any network application, e.g. ping. It gives you less information than the program I posted. 1) On typical OS, ping forces you to choose explicitely IPv4 or IPv6. In that respect, telnet is better than ping for this test. 2) You see only the first IP address, not the full list. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
On Thu, 12 Nov 2009 10:01:38 +0900, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Nov 11, 2009 at 05:00:03PM -0600, da...@from525.com da...@from525.com wrote a message of 60 lines which said: I am wondering if anyone knows of an app similar to nslookup or dig that actually uses the system resolver. C source attached. Compile, for instance, with: gcc -o resolve-name resolve-name.c I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first. Not sure it will help. Stephane, Thanks for that bit of c it works great and does just what I was hoping for. I was able to reproduce the almost 13 second delay while looking up a specific hostname. Funny thing is, when I perform other queries for other hostnames the third invalid DNS server mentioned in the resolv.conf does not seem to be a problem. When I remove the third invalid entry and perform the same query with your application the delay is non existent. I have captured previous tcpdumps and didn't notice anything out of the norm, but there was alot of other network chatter. The app should let me capture a more concise tcpdump for further examination. Is there any way you could incorporate resolver errors being sent to stdout? Thanks, David Porsche ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
http://www.reedmedia.net/software/gethost/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
On Wed, 11 Nov 2009 20:06:11 -0600, da...@from525.com da...@from525.com wrote: On Thu, 12 Nov 2009 10:01:38 +0900, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Nov 11, 2009 at 05:00:03PM -0600, da...@from525.com da...@from525.com wrote a message of 60 lines which said: I am wondering if anyone knows of an app similar to nslookup or dig that actually uses the system resolver. C source attached. Compile, for instance, with: gcc -o resolve-name resolve-name.c I am basically trying to uinderstand why the system resolver was getting stuck on the third entry within the resolv.conf while it should have tried one of the first two working DNS servers first. Not sure it will help. Stephane, Thanks for that bit of c it works great and does just what I was hoping for. I was able to reproduce the almost 13 second delay while looking up a specific hostname. Funny thing is, when I perform other queries for other hostnames the third invalid DNS server mentioned in the resolv.conf does not seem to be a problem. When I remove the third invalid entry and perform the same query with your application the delay is non existent. I have captured previous tcpdumps and didn't notice anything out of the norm, but there was alot of other network chatter. The app should let me capture a more concise tcpdump for further examination. Is there any way you could incorporate resolver errors being sent to stdout? Thanks, David Porsche ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users Thanks All, I think between Stephane's test app and some snoop data I have a better idea of what is going on. It seems as if the local resolver starts by issuing ipv6 requests to the three name servers mentioned in resolv.conf. The first two valid DNS servers (not configured for ipv6) each respond back stating they are not authoritative for the domain in question causing the subsequent servers to be queried. The resolver finds itself querying the third bogus name server and has to wait for the 5 second time out. The resolver then repeats the whole process for ipv6 adding another 5 seconds to the delay (total of 10 now). The resolver then finally starts the whole process again for ipv4 and gets the proper answer with the first query. Thanks, David Porsche ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: System Resolver Test App?
In article mailman.971.1257996722.14796.bind-us...@lists.isc.org, da...@from525.com da...@from525.com wrote: I think between Stephane's test app and some snoop data I have a better idea of what is going on. It seems as if the local resolver starts by issuing ipv6 requests to the three name servers mentioned in resolv.conf. Do you mean that it's issuing requests using IPv6, or it's using IPv4 to send requests for records? The first two valid DNS servers (not configured for ipv6) each respond back stating they are not authoritative for the domain in question causing the subsequent servers to be queried. The resolver finds itself querying Which servers are you talking about now, the servers in resolv.conf, or the servers for the domain you're querying? The latter should not respond that they're not authoritative. Authority is not specific to IP versions, it just goes by names. A server is either authoritative for foo.com or it isn't, it can't be authoritative for foo.com's IPv4 data but not for its IPv6 data. the third bogus name server and has to wait for the 5 second time out. The resolver then repeats the whole process for ipv6 adding another 5 seconds to the delay (total of 10 now). The resolver then finally starts the whole process again for ipv4 and gets the proper answer with the first query. If you're not actually using IPv6, you might consider disabling it on your system. That should stop all the unnecessary v6 lookups. -- 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
