Re: dnsquery for Solaris
In article , wrote: > dig was added to Solaris 9. It is not native to Solaris 8 or older. That would explain why it's only where Chris found it on some of our range of Solarises (vintage or only slightly worn). > Chris Thompson wrote: > > On Mar 9 2010, Sam Wilson wrote: > > > > ... I don't know whether [dig is] there [/usr/local/bin] if you use the > > >Solaris-supplied BIND. > > > > Sure it is: > > > > $ ls -l /usr/sbin/dig > > -r-xr-xr-x 1 root bin75208 Jul 29 2008 /usr/sbin/dig > > $ fgrep /usr/sbin/dig /var/sadm/install/contents > > /usr/sbin/dig f none 0555 root bin 75208 48119 121715 SUNWbind > > > > (that's a 9.3.5-P1 dig, from a not very up-to-date Solaris 10 installation, > > but it's been around in Solaris distributions much longer than that). Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: strange behaviour of resolving nameserver
In article , Mark Andrews wrote: > In message <20100309154017.4801c...@the-damian.de>, Torsten writes: > > Am Wed, 10 Mar 2010 00:44:46 +1100 > > schrieb Mark Andrews : > > > > > > > > In message <20100309142153.016c7...@the-damian.de>, Torsten writes: > > > > Hi, > > > > > > > > I'm a bit clueless about what's happening here exactly. > > > > I have a server (9.6.1-P3) that tries resolving > > > > ws.mobilecdn.verisign.com. Queries for this host permanently fail > > > > with SERVFAIL. > > > > > > > > I've narrowed the problem down to answers from c2.nstld.net > > > > > > > > > > > > dig @c2.nstld.com mobilecdn.verisign.com > > > > ;; Got referral reply from 192.26.92.31, trying next server > > > > > > Fix /etc/resolv.conf to point to recursive nameservers. 192.26.92.31 > > > is not a recursive nameserver. > > > > /etc/resolv.conf already points to recursive nameservers. Since these > > nameservers can't resolve ws.mobilecdn.verisign.com I tried every > > single nameserver found by dig +trace and ended up with the behaviour > > of c2.nstld.net. > > I mis-read. 192.26.92.31 is c2.nstld.net so someone at RedHat has > hacked dig to return " ;; Got referral reply from 192.26.92.31, > trying next server" when it see a referral and move onto the next > address which is a IPv6 addresss which presumably you don't have > connectivity for. > > Try "dig -4 @c2.nstld.com mobilecdn.verisign.com". Then yell at > RedHat. Dig is not supposed to move on when it sees a referral. > Dig is a diagnostic tool first and foremost, not a general hostname > lookup tool. One needs to see the answers to queries in a diagnostic > tool not have them skipped. There's also a lame delegation. Here's an extract from "dig ws.mobilecdn.verisign.com +trace": : : mobilecdn.verisign.com. 900 IN NS dns2-auth.m-qube.com. mobilecdn.verisign.com. 900 IN NS dns1-auth.m-qube.com. ;; Received 98 bytes from 192.5.6.31#53(a2.nstld.com) in 119 ms ws.mobilecdn.verisign.com. 1800 IN A 64.14.95.24 mobilecdn.verisign.com. 1800IN NS dns2-auth.m-qube.com. mobilecdn.verisign.com. 1800IN NS dns3-auth.m-qube.com. mobilecdn.verisign.com. 1800IN NS ns1.savvis.net. mobilecdn.verisign.com. 1800IN NS ns2.savvis.net. mobilecdn.verisign.com. 1800IN NS ns3.savvis.net. ;; Received 178 bytes from 64.14.95.64#53(dns2-auth.m-qube.com) in 90 ms dns1-auth.m-qube.com does not respond, at least to me, and will also cause delays or failures because it is a CNAME for dns1.m-qube.com. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnsquery for Solaris
On Mar 10 2010, Sam Wilson wrote: In article , wrote: dig was added to Solaris 9. It is not native to Solaris 8 or older. That would explain why it's only where Chris found it on some of our range of Solarises (vintage or only slightly worn). Yes, I did overestimate how long it's been there. (Also, of course, some people will exclude/remove package SUNWbind so that they can use the same path names for their own BIND installations.) But if you are still using Solaris 8 or earlier... well it's not quite as bad as still running BIND 8. Not *quite* ... :-) -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Zone Statistics in Bind9.7.0
Hello, in Bind 9.6.2 the zone statistics looked like that: 4.3.2.1.e164.arpa/IN IN 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 0 0 0 0 0 2 0 0 0 0 1 0 0 0 0 0 0 Now with Bind9.7.0 it only covers 4.3.2.1.e164.arpa/IN IN 8 Is there some way to get the full scope of counters that came with the Bind9.6.2? I tried activating zone-statistics in each zone statement, but that didnt change anything. Best regards Thomas Dangl ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
recursion
If there is no option "recursion yes (or no);" specified in named.conf, is the server still recursive? Is "recursion" activated by default if option recursion (yes|no) is missing in named.conf? Thank you, Julian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
On 3/10/2010 11:37 AM, ic.nssip wrote:
If there is no option "recursion yes (or no);" specified in
named.conf, is the server still recursive?
Is "recursion" activated by default if option recursion (yes|no) is
missing in named.conf?
Yes, recursion is "activated" by default, but who is or is not allowed
to recurse in a default configuration, depends on the version of BIND
you're running. Older versions allow *open* recursion by default. The
default for modern versions of BIND, if none of the following are set:
recursion
allow-recursion
allow-query-cache
allow-query
is to restrict recursion to { localnets; localhost; }.
But there is cross-inheritance and override behavior among the options
mentioned above. All of this is explained in the ARM.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
ic.nssip wrote:
> If there is no option "recursion yes (or no);" specified in named.conf,
> is the server still recursive?
> Is "recursion" activated by default if option recursion (yes|no) is
> missing in named.conf?
In modern BIND, "allow-recursion" defaults to:
"{ localhost; localnets; };"
so, yes it is enabled and no, it's not available to everyone.
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: recursion
Modern being?
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Alan Clegg
Sent: Wednesday, March 10, 2010 2:25 PM
To: bind-users@lists.isc.org
Subject: Re: recursion
ic.nssip wrote:
> If there is no option "recursion yes (or no);" specified in
named.conf,
> is the server still recursive?
> Is "recursion" activated by default if option recursion (yes|no) is
> missing in named.conf?
In modern BIND, "allow-recursion" defaults to:
"{ localhost; localnets; };"
so, yes it is enabled and no, it's not available to everyone.
AlanC
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: recursion
Lightner, Jeff wrote: > Modern being? According to CHANGES file: --- 9.5.0a6 released --- 2206. [security] "allow-query-cache" and "allow-recursion" now cross inherit from each other. If allow-query-cache is not set in named.conf then allow-recursion is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used. If allow-recursion is not set in named.conf then allow-query-cache is used if set, otherwise allow-query is used if set, otherwise the default (localnets; localhost;) is used. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
Lightner, Jeff wrote: > Modern being? Actually In the 9.4 CHANGES file I find: --- 9.4.0a4 released --- [...] 2006. [security]Allow-query-cache and allow-recursion now default to the builtin acls "localnets" and "localhost". This is being done to make caching servers less attractive as reflective amplifying targets for spoofed traffic. This still leave authoritative servers exposed. The best fix is for full BCP 38 deployment to remove spoofed traffic. So, "modern" (in this case) is any currently supported version of BIND. 9.4, 9.5, 9.6, 9.7 AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
return address for failed DNSSEC validation
Hello all, If a the validation of a signed RR fails, the answer from the validating resolver to the requestor is SERVFAIL, if I understood correctly. To the average end user who isn't aware that DNS exists this translates to "it's broken". Possibly even "my ISP is broken" if the neighbor's ISP does not validate. So wouldn't a be an interesting option to allow Bind to be configured to return an IP address in case of failed validation (if a A/ record was queried). This would allow the provider to set up a webpage with a small explanation on what went wrong. The obvious limitation of this feature would be that it assumes internet=http, even though you could go as far as set up a few services reacting appropriately on that "fail-host". On the other hand it would allow to lessen the fear from the unexplainable failure and return something to a large part of the users (if only who is to blame). Thoughts? Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursion
I've got the idea!
So even I have no statement "recursion yes", the server is still recursive
as time I dont specify "recursion no;"
It is going to make no difference if I'll add "recursion yes;" on options.
Is "localnets" a term I really need to use?
Currently I'm using an ACL defined for "acl custnets { x.x.x.x; };" and
"allow-query { custnets; };"
Should I change the name "custnets" to "localnets"?
Is my customized name "custnets" going to affect recursion in any way if I
use it instead of "localnets"?
It sounds to me that is fine using "custnets" too.
Thank you!
Julian
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: return address for failed DNSSEC validation
Hi Gilles, this question came up as well at a DNSSEC workshop I attended recently. IMHO redirecting to a website will cause similar misuse to what wildcard records have caused. One might argue a new RCODE would be the right thing but really, the SERVFAIL is actually correct. The server at the other end did actually fail by not passing DNSSEC validation. End users will get confused by this, but then there are plenty of other possibilities with and without DNS they may get confused about. I think providing help to them should be dealt with by the OS instead of bloating DNS. Upon return of any error by DNS (or any other subsystem) it can show them a useful, platform-dependent message how to fix it. -mat On Mar 10, 2010, at 10:31 PM, Gilles Massen wrote: > Hello all, > > If a the validation of a signed RR fails, the answer from the validating > resolver to the requestor is SERVFAIL, if I understood correctly. To the > average end user who isn't aware that DNS exists this translates to > "it's broken". Possibly even "my ISP is broken" if the neighbor's ISP > does not validate. > > So wouldn't a be an interesting option to allow Bind to be configured to > return an IP address in case of failed validation (if a A/ record > was queried). This would allow the provider to set up a webpage with a > small explanation on what went wrong. > > The obvious limitation of this feature would be that it assumes > internet=http, even though you could go as far as set up a few services > reacting appropriately on that "fail-host". On the other hand it would > allow to lessen the fear from the unexplainable failure and return > something to a large part of the users (if only who is to blame). > > Thoughts? > > > Best regards, > Gilles > > > -- > Fondation RESTENA - DNS-LU > 6, rue Coudenhove-Kalergi > L-1359 Luxembourg > tel: (+352) 424409 > fax: (+352) 422473 > ___ > 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: recursion
On 3/10/2010 4:45 PM, ic.nssip wrote:
I've got the idea!
So even I have no statement "recursion yes", the server is still
recursive as time I dont specify "recursion no;"
It is going to make no difference if I'll add "recursion yes;" on
options.
No difference.
Is "localnets" a term I really need to use?
It's predefined. Read the ARM.
Currently I'm using an ACL defined for "acl custnets { x.x.x.x; };"
and "allow-query { custnets; };"
Should I change the name "custnets" to "localnets"?
If they're numerically the same thing, then it would just be a matter
of personal preference. If they're different, then it would depend on
one's implementation requirements whether it's ok to switch one for the
other. We don't have enough information about your implementation
requirements to give a definitive answer one way or the other.
Note that both "localnets" and "localhost" can change dynamically, if
network interfaces are brought up and/or taken down.
Is my customized name "custnets" going to affect recursion in any way
if I use it instead of "localnets"?
If running BIND 9.4.x or higher, "allow-query { custnets; }" will affect
one's allow-recursion default if "custnets" is (or _becomes_, as a
result of interfaces being brought up and/or taken down) in any way
numerically different from "{ localnets; localhost; }".
(Of course, a query that's REFUSED will never get a chance to recurse,
but one can override a *global* allow-query at the zone level, so it
still makes sense for allow-recursion to cross-inherit from allow-query)
If all of this is confusing, then I would recommend explicitly setting
all of them -- allow-query, allow-query-cache, allow-recursion. Then you
don't need to constantly guess at what is inheriting from where.
- Kevin
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: return address for failed DNSSEC validation
Additionally you can detect a DNSSEC failure by asking queries with and without the CD bit set. Most DNSSEC failures can be diagnosed with dig, knowing the current time and date and access to named.conf for the trust anchors. There are actually easier to diagnose than most other DNS failure issues. Most DNSSEC failure fall into these categories: * failure to re-sign, check the dates in the RRSIG records. * failute to roll a key correctly. check the key id match. dig +multi will print out the key id for KEY and DNSKEY records. To find the failure you ask the failing server for the records in the trust chain until you find the break point. record -> dnskey [ [ -> ds/dlv -> dnskey ] . ] -> trusted-key. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dynamic update in IPv6 environment
hi, when i was in IPv4 environment test the dynamic update ,the result is completely sucess,there is the result(rangi type is the new type i added): [r...@localhost named]# host -t rangi 4086:0002:0010:::1 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800::1 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800::2 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800:20c:29ff:fe32:572a [r...@localhost named]# nsupdate > update add 0001.0010.0002.4086.rangiid.arpa 3001 IN rangi 2001:da8:215:1800::3 quit [r...@localhost named]# host -t rangi 4086:0002:0010:::1 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800::2 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800::3 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800:20c:29ff:fe32:572a 0001.0010.0002.4086.rangiid.arpa has RANGI record 2001:da8:215:1800::1 [r...@localhost named]# nslookup -type=A ns.0010.0002.4086.rangiid.arpa. Server: 127.0.0.1 Address: 127.0.0.1#53 Name: ns.0010.0002.4086.rangiid.arpa Address: 127.0.0.1 But,when i change the environment to IPv6 environment ,update always error!! [r...@localhost named]# host -t ns.0010.0002.4086.rangiid.arpa ns.0010.0002.4086.rangiid.arpa has IPv6 address ::1 [r...@localhost named]# nsupdate > update add 0001.0010.0002.4086.rangiid.arpa. 2001 IN rangi 2001:da8:215:1800::5 couldn't get address for 'ns.0010.0002.4086.rangiid.arpa': failure the BIND version is BIND-9.6.1,my install process is :./configure;make ;make install, is there any wrong with my install or others problem ? thanks! -- Best regards! Sincerely, aiHua Zhang State Key Lab. of Networking Technology Research Institute, BeiJing University of Posts and Telecommunications, 100876, P.R.China Email ：aih...@bupt.cn ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: return address for failed DNSSEC validation
Mark, Mat, Mat wrote: > End users will get confused by this, but then there are plenty of > other possibilities with and without DNS they may get confused about. > I think providing help to them should be dealt with by the OS instead > of bloating DNS. Upon return of any error by DNS (or any other > subsystem) it can show them a useful, platform-dependent message how > to fix it. Mark Andrews wrote: > Additionally you can detect a DNSSEC failure by asking > queries with and without the CD bit set. > > Most DNSSEC failures can be diagnosed with dig, knowing the > current time and date and access to named.conf for the trust > anchors. There are actually easier to diagnose than most > other DNS failure issues. I agree with both of you, but you are missing the point. The problem space is users that don't know about DNS, and that don't have a local validating resolver. So there is no point of even considering dig. As soon as applications (or local stub resolvers) are validating, that would be the place to generate a "user compatible" error. But in the best case this will take years. In the mean term we are stuck with dummy users, and ISPs that might want to enable validation, but might also be kept off by the cost that unexplainable (or rather unexplained) failures will produce (Helpdesk). Being able to return 'something' in case of validation failures (and only them, not any SERVFAIL!) looks as it were in the interest of the adoption of DNSSEC. Obviously there are parallels to NXDOMAIN rewriting. However, the major difference I see is that NXDOMAIN is a clear message, known by the OSs and applications, that has basically one meaning. SERVFAIL is more like 'didn't work. go figure.' And the good thing is that 'validation error rewriting' could be abandoned again if DNSSEC arrives at the OS/applications. Gilles ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
