Re: error (broken trust chain) resolving
Casey Deccio deccio.net> writes:
>
> There is a difference between a "broken" trust chain and a trust chain
> that securely "ends" before reaching the name being queried.
Ahhh. That makes sense.
> However, a broken chain means that the validating resolver expects a
> chain to exist, but the chain does not extend properly.
How does a resolver come to this expectation? What is happening that makes
this situation any different than an insecure delegation? If we take one of
the examples from my original post:
named error (broken trust chain) resolving '133.168.163.66.sa-
trusted.bondedsender.org/TXT/IN': 173.45.100.146#53
Where/why does it break? Who's is breaking it? I can see that org. is rife
with DNSSEC data but that bondedsender.org. is completely void of it. But
surely that would be the case of a plain insecure delegation, yes?
> I'm assuming the error above refers to a broken chain, but it's hard
> to tell why without looking at the context, including cache contents
> at the time of the failure, etc. The DNSSEC configuration (resulting
> in insecure answer) looks okay from my perspective. Is the error
> persistent or was it a one-time deal?
Well given the particular one above is a dnsbl lookup it's difficult to say if
I've even looked it up more than once.
Looking at the various occurrences I have it seems to be pervasive for reverse
addr lookups in bb.barracudacentral.org, sa-accredit.habeas.com, sa-
trusted.bondedsender.org, rbl-plus.mail-abuse.org, relays.mail-abuse.org,
dialups.mail-abuse.org, blackholes.mail-abuse.org looking for A and TXT records.
It also seems to occur quite frequently for lookups to domains like
{seal,ocsp}.verisign.net, login.facebook.com, *.slashdot.org,
newswww.bbc.net.uk, and others.
Apart from that there are a few domains in which A, MX and PTR lookups return a
broken chain, but nowhere near as much as the reverse addr lookups and the
lookups above.
Cheers,
b.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
On Wed, Nov 03, 2010 at 11:44:18AM +, Brian J. Murrell wrote a message of 46 lines which said: > named error (broken trust chain) resolving '133.168.163.66.sa- > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53 > > Where/why does it break? Who's is breaking it? I can see that > org. is rife with DNSSEC data but that bondedsender.org. is > completely void of it. But surely that would be the case of a plain > insecure delegation, yes? Indeed. Your analysis seems right. May be you have somewhere another trust anchor (for d...@isc or directly for bondedsender.org?) Another possibility: sa-trusted.bondedsender.org is badly lame (none of the name servers reply), so it may trigger a bad error message from BIND. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNSSEC and Bind 9.3.6
Hi. Some people here have said that the option 'managed-keys' only exists in the bind 9.7 version. That's ok, that's right, I'm going to upgrade my Bind. But at this time would be very nice if it would be possible to use DNSSEC with Bind 9.3.6 version, just to test some particular parameters here. So, is that possible in any way to use DNSSEC with Bind 9.3.6? Is there any documentation to follow? What are the general important DNSSEC differences in these versions (9.3 and 9.7)? Is that a really good idea install the Bind newer version considering these differences? Sorry the basic questions... it's just because I think it's a good idea share my worries in this case. []s Alexander Brazil ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: DNSSEC and Bind 9.3.6
Some OSes provide an "official" BIND package and maintain it. (e.g. RHEL 5.x uses BIND 9.3.x). This package while initially based on 9.3 from ISC may have security and/or functionality updates backported into it from later versions of BIND. If you are using such an "official" package from your OS provider the question becomes whether it is more important to you to have the OS provider support your BIND or whether you want to have the latest/greatest and be community supported. If you want a feature in your OS vendor's "official" package you need to check what is included because it is possible that it already is. Failing that you can ask the vendor to add the feature. If they won't do it then you need to think about rolling your own (i.e. download the ISC BIND source and build it on your system). -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of alexan...@nautae.eti.br Sent: Wednesday, November 03, 2010 9:24 AM To: bind-users@lists.isc.org Subject: DNSSEC and Bind 9.3.6 Hi. Some people here have said that the option 'managed-keys' only exists in the bind 9.7 version. That's ok, that's right, I'm going to upgrade my Bind. But at this time would be very nice if it would be possible to use DNSSEC with Bind 9.3.6 version, just to test some particular parameters here. So, is that possible in any way to use DNSSEC with Bind 9.3.6? Is there any documentation to follow? What are the general important DNSSEC differences in these versions (9.3 and 9.7)? Is that a really good idea install the Bind newer version considering these differences? Sorry the basic questions... it's just because I think it's a good idea share my worries in this case. []s Alexander Brazil ___ 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: DNSSEC and Bind 9.3.6
On Wed, Nov 03, 2010 at 11:24:03AM -0200, alexan...@nautae.eti.br wrote a message of 31 lines which said: > So, is that possible in any way to use DNSSEC with Bind 9.3.6? Yes. DNSSEC appeared in BIND 9.0. > Is there any documentation to follow? The ARM. > What are the general important DNSSEC differences in these versions (9.3 > and 9.7)? NSEC3 (used for the root, for .ORG, .FR, .COM.BR and several others, appeared in, I believe, 9.6) SHA-2 (used for the root, for .FR and for several others, appeared in 9.7) Auto-resign (appeared in 9.7) Many bug fixes (older versions are really problematic, sometimes) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and Bind 9.3.6
On Wed, 3 Nov 2010, Stephane Bortzmeyer wrote: > On Wed, Nov 03, 2010 at 11:24:03AM -0200, > alexan...@nautae.eti.br wrote > a message of 31 lines which said: > > > So, is that possible in any way to use DNSSEC with Bind 9.3.6? > > Yes. DNSSEC appeared in BIND 9.0. DNSSEC has changed a lot since then. I would not run anything older than the most recent releases of 9.6 or 9.7 with DNSSEC. Tony. -- f.anthony.n.finchhttp://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC and Bind 9.3.6
On Nov 3 2010, Stephane Bortzmeyer wrote: On Wed, Nov 03, 2010 at 11:24:03AM -0200, alexan...@nautae.eti.br wrote a message of 31 lines which said: So, is that possible in any way to use DNSSEC with Bind 9.3.6? Yes. DNSSEC appeared in BIND 9.0. After a fashion. You really don't want to use the early versions with DNSSEC, though. (Well you don't want to use them at all, actually, as they are out of support.) BIND 9.3 can be used on an official slave for signed zones with NSEC (not NSEC3) provided you set "dnssec-enable yes;" - it wasn't the default back then. But I wouldn't try and use it as a validating recursive resolver under any circumstances. Is there any documentation to follow? The ARM. What are the general important DNSSEC differences in these versions (9.3 and 9.7)? NSEC3 (used for the root, for .ORG, .FR, .COM.BR and several others, appeared in, I believe, 9.6) 9.6 is right, but NSEC3 is not used in the root zone. On the other hand, 25 of the 47 TLDs that are currently registered in either the root zone or in dlv.isc.org or both use NSEC3 - it cannot be considered optional in a serious validating resolver now. SHA-2 (used for the root, for .FR and for several others, appeared in 9.7) 9.6.2 also supports RSASHA256 and RSASHA512. Only 13 of the 47 TLDs mentioned use one of these, but as RSASHA256 used in the root zone, support for it really cannot be considered optional either. Auto-resign (appeared in 9.7) Automated resigning within named appeared in BIND 9.6. 9.7 has more facilities for automated key management, though. Many bug fixes (older versions are really problematic, sometimes) As has been pointed out, OS distributors often supply BIND with an old version number to which security and sometimes other fixes from later releases have applied. But I very much doubt that you will find anyone distributing a "9.3" version that has anything like modern support for DNSSEC. -- Chris Thompson Email: c...@cam.ac.uk ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Stephane Bortzmeyer nic.fr> writes: > > Indeed. Your analysis seems right. May be you have somewhere another > trust anchor (for DLV ISC or directly for bondedsender.org?) Hrm. I'm not sure TBH. I know I didn't install any trust anchor specifically for bondedsender.org, but I do have "dnssec-lookaside auto;" configured in my bind options. I don't know how to do the same verification of bondedsender.org given that however. > Another possibility: sa-trusted.bondedsender.org is badly lame (none > of the name servers reply), so it may trigger a bad error message from > BIND. Both s0.rpdns.net. and s1.rpdns.net. seem to be responsive. The number of high- profile domains involved seems to reduce the probability of this option. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
On Wed, Nov 03, 2010 at 04:00:48PM +, Brian J. Murrell wrote a message of 19 lines which said: > > Another possibility: sa-trusted.bondedsender.org is badly lame (none > > of the name servers reply), so it may trigger a bad error message from > > BIND. > > Both s0.rpdns.net. and s1.rpdns.net. seem to be responsive. They are not name servers of sa-trusted.bondedsender.org: % dig +short NS sa-trusted.bondedsender.org spns1.rpdns.net. ltns3.rpdns.net. spns4.rpdns.net. spns2.rpdns.net. spns3.rpdns.net. xlns17.rpdns.net. xlns1.rpdns.net. spns5.rpdns.net. xlns11.rpdns.net. eukns1.rpdns.net. xlns18.rpdns.net. ltns4.rpdns.net. xlns19.rpdns.net. xlns12.rpdns.net. ltns2.rpdns.net. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Stephane Bortzmeyer nic.fr> writes: > > They are not name servers of sa-trusted.bondedsender.org: Damn. Yes, you are correct. I forgot it was sa-trusted.bondedsender.org. in our example and stopped at bondedsender.org. However going that one more sub- domain deeper and testing it's NSes, they are all responsive. And per my previous message, the number of domains affected makes the idea that it's lame servers lower probability. Thanx for keeping me honest. :-) b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND - Declare variable?
I do not think this is possible, but would like to confirm.
I would like to declar a variable, and then use that variable elsewhere
within the named.conf file.
I have multiple "channel" definitions with "file" options. I want a
variable for the path so I can change it once and update all entries:
Example:
channel config_log {
file "/var/log/dns/config"
versions 7
size 20m
;
channel config_log {
file "/var/log/dns/config"
versions 7
size 20m
;
I would like:
FQPN=/var/log/dns
channel config_log (
File "$FQPN/config"
Version 7
Size 20m
;
channel database_log {
file "$FQPN/database"
versions 7
size 20m
;
Obviously, I could take it even further with the version and size
parameters. It would be great to reduce this down to:
FQPN=/var/log/dns
Ch_Opts=Version 7 Size 20m
channel config_log (
File "$FQPN/config" $Ch_Opts ;
channel database_log {
file "$FQPN/database" $Ch_Opts ;
Thanks,
Mike C
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
On Wed, Nov 3, 2010 at 4:44 AM, Brian J. Murrell wrote: > Casey Deccio deccio.net> writes: >> >> However, a broken chain means that the validating resolver expects a >> chain to exist, but the chain does not extend properly. > > How does a resolver come to this expectation? What is happening that makes > this situation any different than an insecure delegation? If we take one of > the examples from my original post: > This can happen in a number of different ways: If any RRSIGs in the chain of trust are bogus, expired, or missing. If NSEC/NSEC3 records are not provided or are insufficient to prove that no DS records exist for an insecure delegation. If DS RRs do exist, but none correspond to any self-signing DNSKEYs in the child zone. If DNSKEYs are not returned by the resolver. > named error (broken trust chain) resolving '133.168.163.66.sa- > trusted.bondedsender.org/TXT/IN': 173.45.100.146#53 > > Where/why does it break? Who's is breaking it? I can see that org. is rife > with DNSSEC data but that bondedsender.org. is completely void of it. But > surely that would be the case of a plain insecure delegation, yes? > Yes, bondedsender.org is an insecure delegation. Reproducing these errors and analyzing the debug-level log messages would be helpful since everything looks consistent from a DNSSEC perspective, as far as I can see. Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: error (broken trust chain) resolving
Casey Deccio deccio.net> writes: > > This can happen in a number of different ways: If any RRSIGs in the > chain of trust are bogus, expired, or missing. If NSEC/NSEC3 records > are not provided or are insufficient to prove that no DS records exist > for an insecure delegation. If DS RRs do exist, but none correspond > to any self-signing DNSKEYs in the child zone. If DNSKEYs are not > returned by the resolver. None of which appear to be the case for this example-case domain "sa- trusted.bondedsender.org" as far as I have been able to determine with my "green" DNSSEC skills. > Yes, bondedsender.org is an insecure delegation. So from what I have been able to learn so far, there shouldn't be any legitimate reason why one should be getting broken trust chain errors about a domain that has been insecurely delegated, yes? I mean there is no security in the delegation to be broken, right? > Reproducing these errors and analyzing the debug-level log messages > would be helpful since everything looks consistent from a DNSSEC > perspective, as far as I can see. I might be able to set up a shadow bind installation that mirrors the configuration of primary resolver here to do some debugging. Do you have any suggestions as to which debug flags/levels to set to get some meaningful information? Once set up, simply doing some digs with +dnssec against the configured server should suffice, yes? b. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
