Re: return address for failed DNSSEC validation
On 11.03.10 08:54, Gilles Massen wrote: 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. I believe that SERVFAIL rewriting would lead to the same kind of problems NXDOMAIN rewriting leads to. Imho, simply DON'T. -- 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. Save the whales. Collect the whole set. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: return address for failed DNSSEC validation
In message 4b98a1a6.9070...@restena.lu, Gilles Massen writes: 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. 99.9% of the time SERVFAIL means the owner of the zone stuffed up, go figure. Doing DNSSEC wrong is just another way the owner of the zone can stuff up. It doesn't need special handling. Gilles -- 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
Re: return address for failed DNSSEC validation
Gilles Massen wrote: 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. The problem is that to correctly protect non-DNSSEC aware applications, a return code had to be chosen that even the lowliest of clients would understand as STOP! YOU MUST NOT USE THIS INFORMATION to which SERVFAIL is the only correct response. I also would like to see a result that somehow says Hey, DNSSEC broke this response, you need to figure out what happened. However, this is not really possible considering the constraint of supporting resolvers that (as the humans in your example) don't have any idea what DNSSEC is, nor how to deal with anything beyond very simple responses. 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: dnsquery for Solaris
On 03/10/10 11:59, Chris Thompson wrote: 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* ... :-) For what its worth, with vintage support patch install BIND 9 dig is supplied in /usr/lib/dns/dig (yes, /usr/lib - sorry about that). Stace ___ 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 Andrews wrote: 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. 99.9% of the time SERVFAIL means the owner of the zone stuffed up, go figure. Doing DNSSEC wrong is just another way the owner of the zone can stuff up. It doesn't need special handling. From a purely technical point of view, I agree. However there is a significant difference: until now SERVFAIL means I wasn't able to wrestle an information out of the DNS despite it's extraordinary resilience to stupid configurations. In case of a validation error it is rather I don't want to show you. Not even that there was answer and that my warnings could be ignored. The DNS protocol is not equipped to signal that. But a resolver could give help - with shortcomings, but still something. Best, 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
Split View DNS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When using split view, can one point to the same file in both views?
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type slave;
file /var/named/slave/10.10.10.reverse;
masters { ipaddress; };
};
};
view blah-external {
match-clients { any; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type master;
file /var/named/view/10.10.10.reverse;
};
};
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuZBtkACgkQ3BaZWzk6Q2cm6wCgt8/qogkzaM4SosMpS9o+PT9k
qugAoIwHOmvsZyrHDfbZEDsY1Rp1/tFZ
=aL9s
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Split View DNS
Yes, assuming you want them to both have the same zone data.
We use a naming convention so we know when we're sharing a file. Each
view gets their zonefiles with -viewname (ie: example.com-internal)
appended. Common zones get -common. This keeps us from modifying the
wrong file, and lets us remember which ones are shared easily.
Todd.
-Original Message-
From: bind-users-bounces+tsnyder=rim@lists.isc.org
[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of
Jason Gates
Sent: Thursday, March 11, 2010 10:06 AM
To: bind-users@lists.isc.org
Subject: Split View DNS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When using split view, can one point to the same file in both views?
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type slave;
file /var/named/slave/10.10.10.reverse;
masters { ipaddress; };
};
};
view blah-external {
match-clients { any; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type master;
file /var/named/view/10.10.10.reverse;
};
};
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuZBtkACgkQ3BaZWzk6Q2cm6wCgt8/qogkzaM4SosMpS9o+PT9k
qugAoIwHOmvsZyrHDfbZEDsY1Rp1/tFZ
=aL9s
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute non-public
information. Any use of this information by anyone other than the intended
recipient is prohibited. If you have received this transmission in error,
please immediately reply to the sender and delete this information from your
system. Use, dissemination, distribution, or reproduction of this transmission
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Split View DNS
I tried this and noticed that the first view will IXFR the file from the
master, then the second view will try to IXFR and fail because the file
has already been updated. Then the second view does a complete AXFR. I
ended up with errors in the log file. With busy DDNS zones the errors
were very plentiful.
I found it best to just have separate files for each view even if they
have the same information in them. It works either way, just a personal
preference I guess.
-Christopher
-Original Message-
From: bind-users-bounces+christopher-howard=utc@lists.isc.org
[mailto:bind-users-bounces+christopher-howard=utc@lists.isc.org] On
Behalf Of Todd Snyder
Sent: Thursday, March 11, 2010 10:10 AM
To: Jason Gates; bind-users@lists.isc.org
Subject: RE: Split View DNS
Yes, assuming you want them to both have the same zone data.
We use a naming convention so we know when we're sharing a file. Each
view gets their zonefiles with -viewname (ie: example.com-internal)
appended. Common zones get -common. This keeps us from modifying the
wrong file, and lets us remember which ones are shared easily.
Todd.
-Original Message-
From: bind-users-bounces+tsnyder=rim@lists.isc.org
[mailto:bind-users-bounces+tsnyder=rim@lists.isc.org] On Behalf Of
Jason Gates
Sent: Thursday, March 11, 2010 10:06 AM
To: bind-users@lists.isc.org
Subject: Split View DNS
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When using split view, can one point to the same file in both views?
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type slave;
file /var/named/slave/10.10.10.reverse;
masters { ipaddress; };
};
};
view blah-external {
match-clients { any; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type master;
file /var/named/view/10.10.10.reverse;
};
};
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuZBtkACgkQ3BaZWzk6Q2cm6wCgt8/qogkzaM4SosMpS9o+PT9k
qugAoIwHOmvsZyrHDfbZEDsY1Rp1/tFZ
=aL9s
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
___
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: Split View DNS
On 11.03.10 10:06, Jason Gates wrote:
When using split view, can one point to the same file in both views?
for master zones, yes, but you will have to reload it in all views
explicitly (I think that server reload should take care of that)
for slave zones, I'm afraid it's not possible. You will have either to fetch
it two times from the master, or fetch from one view to another one...
(or create third view which will have ti as slave and create forward zones
in other views to this one).
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type slave;
file /var/named/slave/10.10.10.reverse;
masters { ipaddress; };
};
};
view blah-external {
match-clients { any; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type master;
file /var/named/view/10.10.10.reverse;
};
};
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuZBtkACgkQ3BaZWzk6Q2cm6wCgt8/qogkzaM4SosMpS9o+PT9k
qugAoIwHOmvsZyrHDfbZEDsY1Rp1/tFZ
=aL9s
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
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.
99 percent of lawyers give the rest a bad name.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
RE: Split View DNS
I too found it best to have them be separate even if they contain the
same data. For me I had an internal and external view - the external
was my original zone so I made that my external view then simply
prepended internal- to the zone file name in the internal view. That
way all my intenal view zones files can be found quickly (as can
external by grepping out the internal-). If they have the same
content you can simply copy the original zone file to the other zone and
prepend. I did that with a for loop when I originally introduced views
and creating the zones files took less time than updating named.conf.
-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
Of Matus UHLAR - fantomas
Sent: Thursday, March 11, 2010 10:18 AM
To: bind-users@lists.isc.org
Subject: Re: Split View DNS
On 11.03.10 10:06, Jason Gates wrote:
When using split view, can one point to the same file in both views?
for master zones, yes, but you will have to reload it in all views
explicitly (I think that server reload should take care of that)
for slave zones, I'm afraid it's not possible. You will have either to
fetch
it two times from the master, or fetch from one view to another one...
(or create third view which will have ti as slave and create forward
zones
in other views to this one).
example:
view blah-internal {
match-clients { internal-users; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type slave;
file /var/named/slave/10.10.10.reverse;
masters { ipaddress; };
};
};
view blah-external {
match-clients { any; };
zone blah.org in {
type slave;
file /var/named/slave/blah.org;
masters { ipaddress; };
};
zone 10.10.10.in-addr.arpa in {
type master;
file /var/named/view/10.10.10.reverse;
};
};
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
iEYEARECAAYFAkuZBtkACgkQ3BaZWzk6Q2cm6wCgt8/qogkzaM4SosMpS9o+PT9k
qugAoIwHOmvsZyrHDfbZEDsY1Rp1/tFZ
=aL9s
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
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.
99 percent of lawyers give the rest a bad name.
___
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: recursion
Hi Kevin,
I followed your advice and I explicitly added:
recursion yes;
allow-recursion { custnets; };
I'm using MRTG for interface bandwidth monitoring and Smokeping for time
response on queries and all look the same as before. So, so far so good!
Thank you!
Julian
- Original Message -
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Sent: Wednesday, March 10, 2010 4:54 PM
Subject: 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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Split View DNS
On Thu, 11 Mar 2010, Matus UHLAR - fantomas wrote: On 11.03.10 10:06, Jason Gates wrote: When using split view, can one point to the same file in both views? for master zones, yes, but you will have to reload it in all views explicitly (I think that server reload should take care of that) Right. A server reload will load all zones in all views. You can also reload individual zones in individual zones: rndc reload zone class view such as: rndc reload example.com in internal rndc reload example.com in external to load zone example com in view internal zone example com in view external. For split zones with common data, I like to have a (usually small) zone file for each view with the SOA RR any view-specific data, each including a (usually larger) file of data common to all views. This avoids duplication of data which are supposed to be the same could otherwise get out of sync. The common file doesn't have an SOA RR, so it's not a complete zone file, so you have to refer to the view-specific files for the master files when doing named-checkzone. (Pay attention to the origin in the included file, explicitly specifying it with @ if the first RR applies to the bare zone name.) I use directories for managing the files in each view. On the master: Primary.internal for internal view files Primary.external for external view files Primary.common for files common to both views On the slave: Secondary.internal for internal backup files Secondary.external for external backup files (There is no Secondary.common because the slave tranfers whole zones in each view, having no knowledge of how the zones were assembled on the master.) for slave zones, I'm afraid it's not possible. You will have either to fetch it two times from the master, or fetch from one view to another one... Yes, if you want slaves to have the same split-view behavior, they will need to transfer the zones in all views independently. I use special TSIG keys for this: the slaves use the special key for the view they want to get from the master, while the master uses the special key to present the corresponding view. It's a little complicated, but it does the trick for me. Note that the zones in each view are independent of zones in other views, even if they happen to have the same zone name. The master files are just loaded by named not messed with (unless you're doing dynamic update, in which case what I'm saying might not apply). Thus, you can have multiple zones loaded from the same file on the master. (This applies to other cases than just split-view, such is if you want the same data in multiple IPv6 prefixes because they're laid onto the same net.) The backup files on the slaves are written by named, so each (zone,view) instance has to have its own file. Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dynamic update in IPv6 environment
aihua zhang wrote: [...] 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! Dynamic updates work correctly in an IPv6 environment to the best of my knowledge, however, nsupdate does not at this point have support for the RANGI RR type. Is this a modified version of BIND? If so, where is it available? Are you able to post the configuration file (named.conf) and the zone file in question? Thanks, 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: return address for failed DNSSEC validation
In message 4b98fd2d.5080...@restena.lu, Gilles Massen writes: Mark Andrews wrote: 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. 99.9% of the time SERVFAIL means the owner of the zone stuffed up, go figure. Doing DNSSEC wrong is just another way the owner of the zone can stuff up. It doesn't need special handling. From a purely technical point of view, I agree. However there is a significant difference: until now SERVFAIL means I wasn't able to wrestle an information out of the DNS despite it's extraordinary resilience to stupid configurations. In case of a validation error it is rather I don't want to show you. Not even that there was answer and that my warnings could be ignored. No. It's I've tried real hard to get you a answer which is not a forgery but I can't. The DNS protocol is not equipped to signal that. But a resolver could give help - with shortcomings, but still something. Best, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 -- 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
Reminder about DLV, BIND 9.6.0 and BIND 9.6.0-P1
DLV records for TLD's signed using RASSHA256 (and RSASHA512) will be added DLV.ISC.ORG in the next few days. BIND 9.6.0 and BIND 9.6.0-P1 do not correctly handle these records and it is recommended that you upgrade to BIND 9.6.1 or later. This was originally announced here https://www.isc.org/software/bind/dlv11March2009Announcement The following test zones are available to check if you have a problem. rsasha256.island.dlvtest.dns-oarc.net rsasha512.island.dlvtest.dns-oarc.net 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
Re: dynamic update in IPv6 environment
Some suggestions: 1) always use -d with nsupdate, otherwise you get almost no indication of what it's doing under the covers 2) look in your query logs to see what queries nsupdate is generating 3) when you say change [...] to IPv6 environment, am I to understand that you're actually bringing up an IPv6 interface on the device? Because I don't think nsupdate will search for records unless it does a probe and finds an IPv6 interface configured locally. (Caveat: my hands-on experience with IPv6 is very limited.) - Kevin On 3/11/2010 2:28 AM, aihua zhang wrote: 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 mailto:aih...@bupt.cn ___ 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: return address for failed DNSSEC validation
On 3/11/2010 2:54 AM, Gilles Massen wrote: 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. The fundamental requirement is that the requestor needs to know that their query FAILED. When you send back a helpful, answerful response for a failure, either under NXDOMAIN redirection or your proposal, then you essentially deceive the client and confuse any troubleshooting efforts. SERVFAIL may not be as specific as we'd like for this particular failure mode, but it takes many years to define and get a new RCODE implemented, and DNSSEC can't wait for that. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Split View DNS
Yes and no. Yes for static masters. No for everything else, i.e. slaves, dynamic masters, stubs. 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
Re: rndc
In message af5cd12999f848089ceada384be2e...@internal.corp.ds, ic.nssip writ es: I had some problems with versions prior 9.7.0, when the response time = dramatically increased for hours after two or 3 days after cache reached = the maximum size in the memory. I used to restart named process and = everything was good for few days again. I have 9.7.0 up for the last = week and it didn't runned into this issue... yet. Anyway, I tried to preventive flush the cache using rndc flush but = nothing happened in terms of memory used by named. Named doesn't release memory back to the OS. The memory is still freed and is available for reuse. If I kill the process = the cache start building again, but with rndc flush there are no = changes on the size of used memory. Also anytime I use rndc flush I'm = getting a Warning: # rndc flush WARNING: key file (/etc/rndc.key) exists, but using default = configuration file (/etc/rndc.conf) # Is any chance I can figure out why rndc flush is not purging the cache = and eventually fix the WARNING message? Thank you, Julian -- 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
Re: return address for failed DNSSEC validation
In article mailman.792.1268343500.21153.bind-us...@lists.isc.org, Mark Andrews ma...@isc.org wrote: No. It's I've tried real hard to get you a answer which is not a forgery but I can't. Not really. It's I've tried real hard to get you an answer that I can *tell* is not a forgery, but I can't. When validation fails, which is really more likely, that it's a forgery or that the DNS administrator screwed up? When website admins mess up certificates, the browser alerts the user and gives them the option of ignoring the error. DNSSEC validation doesn't have the same kind of continuation option. -- 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: return address for failed DNSSEC validation
Kevin Darcy wrote: The fundamental requirement is that the requestor needs to know that their query FAILED. When you send back a helpful, answerful response for a failure, either under NXDOMAIN redirection or your proposal, then you essentially deceive the client and confuse any troubleshooting efforts. DNS messages should never be rewritten on transit. The NXDOMAIN rewriting is evil: NXDOMAIN is an *answer* from the authoritative zone about it's content (or lack thereof). Rewriting that is altering the message - that's a lie. The SERVFAIL as response to a validation error is *generated* on the validator - who might also generate something else. The validator is the only one having accurate information about the failure (and could even have distinctive behaviour depending on the failure (like shortly expired signatures vs wrong keys)). Sure, the behaviour would no longer be RFC compliant - but as a help to clients who aren't yet either. With the hope of hatching the the DNSSEC-egg quicker by easying the adoption and as a result getting quicker rid of the workaround. Troubleshooting would indeed suffer. You could help the manual troubleshooter by throwing in a TXT record with information. Non browser applications will expose unaccurate behaviour. But considering the general user group it could still be worth it (ideally you would offer opt-out, inform the non-dummy users, etc...but that's operational best practices). SERVFAIL may not be as specific as we'd like for this particular failure mode, but it takes many years to define and get a new RCODE implemented, and DNSSEC can't wait for that. Definetely. What I'm hoping for is a tool to smoothen the way until end systems validate. No further. The DNS protocol should not be touched for that. 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
