Re: dnsquery for Solaris
In article mailman.750.1268169970.21153.bind-us...@lists.isc.org, jcarrol...@cfl.rr.com 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 c...@cam.ac.uk 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 mailman.751.1268170620.21153.bind-us...@lists.isc.org, Mark Andrews ma...@isc.org wrote: In message 20100309154017.4801c...@the-damian.de, Torsten writes: Am Wed, 10 Mar 2010 00:44:46 +1100 schrieb Mark Andrews ma...@isc.org: 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 mailman.750.1268169970.21153.bind-us...@lists.isc.org, jcarrol...@cfl.rr.com 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: zone name4.3.2.1.e164.arpa/IN/name rdataclassIN/rdataclass serial3/serial counters Requestv40/Requestv4 Requestv60/Requestv6 ReqEdns00/ReqEdns0 ReqBadEDNSVer0/ReqBadEDNSVer ReqTSIG0/ReqTSIG ReqSIG00/ReqSIG0 ReqBadSIG0/ReqBadSIG ReqTCP0/ReqTCP AuthQryRej0/AuthQryRej RecQryRej0/RecQryRej XfrRej0/XfrRej UpdateRej0/UpdateRej Response0/Response TruncatedResp0/TruncatedResp RespEDNS00/RespEDNS0 RespTSIG0/RespTSIG RespSIG00/RespSIG0 QrySuccess2/QrySuccess QryAuthAns4/QryAuthAns QryNoauthAns0/QryNoauthAns QryReferral0/QryReferral QryNxrrset0/QryNxrrset QrySERVFAIL0/QrySERVFAIL QryFORMERR0/QryFORMERR QryNXDOMAIN2/QryNXDOMAIN QryRecursion0/QryRecursion QryDuplicate0/QryDuplicate QryDropped0/QryDropped QryFailure0/QryFailure XfrReqDone1/XfrReqDone UpdateReqFwd0/UpdateReqFwd UpdateRespFwd0/UpdateRespFwd UpdateFwdFail0/UpdateFwdFail UpdateDone0/UpdateDone UpdateFail0/UpdateFail UpdateBadPrereq0/UpdateBadPrereq /counters /zone Now with Bind9.7.0 it only covers zone name4.3.2.1.e164.arpa/IN/name rdataclassIN/rdataclass serial8/serial /zone 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
