Re: dnssec automatic signing
In message <102153bef555e7489ca5d54165c431a30139d...@exchbsi02.ttt.co.th>, "Jit tinan Suwanruengsri" writes: > Hi Mark > > If there are many RRSIGs expire at the same time, Which record will be > chosen? Any of them. It does not matter. Named just uses it as a triggering record. > Sincerely, > > Mr.Jittinan Suwanrueangsri -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: dnssec automatic signing
Hi Mark If there are many RRSIGs expire at the same time, Which record will be chosen? Sincerely, Mr.Jittinan Suwanrueangsri -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Friday, August 29, 2014 5:36 AM To: Jittinan Suwanruengsri Cc: bind-us...@isc.org Subject: Re: dnssec automatic signing The next node to be signed is based on RRSIG expire times. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec automatic signing
The next node to be signed is based on RRSIG expire times. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/28/14 10:55 AM, Timothe Litt wrote: Aside from the use of the word 'absurdity', I'm not offended. I am trying to educate. And while I recognize that I'm arguing pragmatism with a market purist, It's nice to be called "pure," in some context anyway. :) However as I pointed out I'm not simply arguing market forces, I'm also arguing the morality of rewarding those providers who do the right thing; and I'm quite specifically arguing the anti-pragmatist perspective that voting with your feet is important. Chris, I purposely did not invoke the spectre of Jim Reid because I did not agree with his violent opposition to the DLV when it was created. But now that we're in the "signed root" phase of DNSSEC deployment I think that argument has a lot more validity. hopefully the OP (and others) will learn why some of us have a slightly different view of how to get to the end goal. I agree that illuminating the different points of view is valuable, and I am happy to agree to disagree with you (and Chris Thompson) on this topic. And why my advice for resolvers is 'check DLV', while my advice for domain owners is 'take reasonable steps to stay/get out of DLV, but use it if you *must*'. We're actually not that far apart... ... I'm sorry to say that we are still quite far apart on specifics though. You continue to use the word "impossible" when what you mean is "outside of the constraints I have created for myself." I was trying not to devolve into a discussion of your specific situation, but one really simple solution to your particular use case would be to move your stuff to a colo facility where they provide proper reverse DNS, signed delegations, etc. There are a world of other options, but you have designated a set of parameters within which you wish to operate, and a provider that does DNSSEC is outside of your parameters. That doesn't make it "impossible," that makes it "something you're not willing to do." Chris' message was an excellent example of his particular value of "really, really hard," but even he points out that it's not the same as "impossible." His organization has done the cost/benefit analysis and determined that having a DNSSEC chain from the root for their reverse delegations is not worth the cost of moving away from JANET. I don't know the politics anywhere near as well as Chris does, but I know them well enough to know that his organization is probably correct in their analysis. In any case, their network, their rules. I have no problem with that. And I want to reiterate one last time that I'm NOT saying that no one should use the DLV, or that no one should put new entries into it. If you or Chris have people that need to validate your reverse DNS, they should be given the information they need about using the DLV to do that. What I AM saying is that people should not be routinely advised to use the DLV, and that resolver operators should only use it if they have a good reason to. And with that, I'll let others chime in, as I don't think I'm saying anything new here. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 27-Aug-14 20:35, Doug Barton wrote: > On 8/27/14 3:03 PM, Timothe Litt wrote: >> So you really meant that validating resolvers should only consult DLV if >> their administrator knows that users are looking-up names that are in >> the DLV? That's how I read your advice. > > You're correct. > >> I don't see how that can work; hence we'll disagree. I think the only >> viable strategy for*resolvers* is to consult the DLV - as long as it >> exists. > > So that leads to a Catch-22, as ISC has stated that they will continue > to provide the DLV as long as it is used. You're saying that people > should continue to consult it as long as it exists. > > Now that the root is signed the traditional argument against continued > indiscriminate use of the DLV is that it makes it easier for > registries, service providers, etc. to give DNSSEC a low priority. > "You don't need me to provide DNSSEC for you, you can use the DLV." > Based on my experience I think there is a lot of validity to that > argument, although I personally don't think it's persuasive on its own. > I don't want to see indiscriminate use of the DLV. See below. > While I appreciate the tone of reasoned discourse in the message I'm > responding to, what you have done is provide additional details to > support your thesis that changing providers is hard. I'm not arguing > the contrary position, so we can agree to agree on that. What you > haven't done is provide any evidence to refute my thesis that "It's > hard" != "It's impossible." I'll even go so far as to agree with you > that in some cases it's really, really hard. > For me, it's impossible. I've stated why. I am a very small player - I run a network for my extended (multi-state) family, and some free services for a few hundred former colleagues. I considered the options that you suggested - they are not practical, affordable or both. No ISP in my geography will provide DNSSEC for reverse DNS. I have asked (in dnssec-deployment) for help in pressuring the ISPs to solve this problem. Comcast (which is not in my geography) has acknowledged the issue, and has "had it on their list" for several years. None of the others have gone even that far. > What that leaves us with is your position (which I will state in an > admittedly uncharitable way), "Some of us would like to have the > benefits of protecting our authoritative data with DNSSEC without > having to endure the cost and inconvenience of migrating our resources > to providers that support it. Therefore the entire Internet should use > the DLV." In contrast, my position is that people and/or organizations > which need the protection of DNSSEC should vote with their feet. In > this way providers that offer DNSSEC will be rewarded, and those that > do not will be punished. I would vote with my feet if I could. I can't. The problem with your market driven approach is that ISPs are largely unregulated monopolies. At least, for those of us who are based in residences/small businesses. I'm fortunate to have 2 cables pass my house - fiber and cable TV. Only the fiber provider has enough outbound bandwidth for site-site backup, which I get for $/mo. The cable TV-based provider says 'yes since you have business class service (static IPs), we will provide a fiber to your premises. First, there's the engineering study for $<5 figures>, then a construction fee, then %<4 figures>/month...unless you want serious bandwidth, in whch case it's more." So there's no competition. Neither cares about DNSSEC. Neither is required to care by regulation, RFC, ICANN/IANA or organized community pressure. The answer is different when you're an enterprise with a large budget. I've been there. "Let us consolidate your voice & data networks; sure, we'll eat the engineering costs of switching you to a few OC-48 fibers; saves us money maintaining all those copper wires. You want a couple of dark fibers, and a couple of hundred PI IP addresses routed - no problem. Switch your phone system to VoIP too? Oh, you got a quote from them, including running new fiber from the highway to your plant for free? Let me re-work our numbers. Can we shine your shoes?" When you pay several $100K/mo for bandwidth per site, it's amazing how responsive vendors can be. So your approach works for some, according to the golden rule (she who has the gold, makes the rules.) > Completely aside from what I believe to be the absurdity of your > argument, the position I suggest will almost certainly result in > market forces which encourage the deployment of DNSSEC. At bare > minimum it has the moral value of rewarding providers who have done > the right thing. > I don't think it's absurd to note that people in my position - and there are a lot of us - are forced to use DLV for some cases. The most prominent is reverse DNS. We *can't* switch providers. We *can't* get IP addresses from other sources (and get them routed) without literally going bankrupt. Since no one ca
To DLV or not to DLV [was Re: recursive lookups for UNSECURE names ...]
On Aug 28 2014, Doug Barton wrote: On 8/27/14 3:03 PM, Timothe Litt wrote: So you really meant that validating resolvers should only consult DLV if their administrator knows that users are looking-up names that are in the DLV? That's how I read your advice. You're correct. I don't see how that can work; hence we'll disagree. I think the only viable strategy for*resolvers* is to consult the DLV - as long as it exists. So that leads to a Catch-22, as ISC has stated that they will continue to provide the DLV as long as it is used. You're saying that people should continue to consult it as long as it exists. I agree with that. The line I have been taking is that we will continue to use validation via dlv.isc.org (as well as via the root, of course) on our recursive nameservers as long as we have to register signed zones there ourselves. It is quite disappointing that we haven't reached that stage yet ... Now that the root is signed the traditional argument against continued indiscriminate use of the DLV is that it makes it easier for registries, service providers, etc. to give DNSSEC a low priority. "You don't need me to provide DNSSEC for you, you can use the DLV." Based on my experience I think there is a lot of validity to that argument, although I personally don't think it's persuasive on its own. Jim Reid used to make that point a lot (and probably still does) when arguing against the mere existence of DLV. However, the organisation blocking progress for us has never made an excuse as cogent as that. We just can't get any communication going with them on the subject at all. To come clean: as part of the UK higher education community, we really are stuck with using JANET. The political problems of disassociating ourselves from them (and it has been muttered about in the past, in the context of their network charges) are sufficiently horrific that we could never justify it simply on the basis of their absence of DNSSEC support in the reverse zone context. Which is where we are stuck. JANET did sign the primary forward zone ac.uk in early 2011, and provided methods for getting DS records for delegations into it. This was actually fairly good compared to many similar organisations. But having achieved this, and despite verbal assurances at the time that the other zones (including reverse ones) they were responsible would get signed as well, they seem to have taken their eye entirely off the DNSSEC ball now. What makes this even more frustrating is that, as early users of the Internet much of our IPv4 space is in "legacy" (ERX) allocations and the reverse zones for it are directly delegated from the reverse zones manged by the RIRs. Those got signed in early 2011 as well, and the mechanisms to maintain DS records in them (which involve the communication mechanisms between the RIRs) work well. (A lot of thanks are due to members of the RIPE DNS working group in that context.) So for these reverse zones we have had a chain of trust from the root for over 3 years now. But a significant chunk of IPv4 space, acquired later, and all of our IPv6 space, have reverse zones delegated from ones maintained by JANET, themselves delegated from the RIPE NCC ones. As the intermediate parent zones are unsigned, these are the ones we still have to register in dlv.isc.org. It is sometimes argued that validating reverse zone contents is unimportant, and that theyhave only the nature of hints in any case. I have always taken the converse line that if something is in the public DNS at all, it ought to be signed. But our tribulations summarised above (and believe me, I could go on about it at *much* greater length! you should be grateful) have occasionally made me regret that. -- Chris Thompson Email: c...@cam.ac.uk ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec automatic signing
Hi, This is example.com zone $ORIGIN . $TTL 86400 ; 1 day example.com 86400 IN SOA ns.example.com. hostmaster.example.com. ( 2013122402 ; serial 86400 ; refresh (1 day) 7200 ; retry (2 hours) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) 86400 NS ns.example.com. $ORIGIN example.com. ns 86400 A 10.10.10.10 sub 86400 NS ns.sub 86400 DS 19264 8 1 ( EA38AD65596500B2D6A4BC04478FFD5C13FF7600 ) 86400 DS 19264 8 2 ( A68BF3856CA9AF1A669EA10DEC8BA72E174108EEB5AA D1CF5A3C919E5AB9B60B ) 86400 DS 36579 7 1 ( 83F190FDEBF79DFEC93571D2C06240834C059414 ) 86400 DS 36579 7 2 ( EAFB90C1EB610CF566EC677A381D5F9DCAFB8B0E2B6D C78A7788E501D523187C ) $ORIGIN sub.example.com. ns 86400 A 10.10.10.11 $ORIGIN example.com. www 86400 A 2.2.2.2 This is zones status 1. [root@dnssec zone]# /opt/bind-9.10.0-P2/sbin/rndc -c /opt/bind-9.10.0-P2/etc/named-sld-rndc.conf -s 10.10.10.10 zonestatus example.com name: example.com type: master files: /usr/local/named/zone/example.com.zone serial: 2013122402 signed serial: 2013122402 nodes: 5 last loaded: Wed, 30 Jul 2014 17:00:34 GMT secure: no key maintenance: automatic next key event: Wed, 30 Jul 2014 18:00:34 GMT dynamic: yes frozen: no 2. [root@dnssec keys]# /opt/bind-9.10.0-P2/sbin/rndc -c /opt/bind-9.10.0-P2/etc/named-sld-rndc.conf -s 10.10.10.10 zonestatus example.com name: example.com type: master files: /usr/local/named/zone/example.com.zone serial: 2013122402 signed serial: 2013122404 nodes: 5 last loaded: Wed, 30 Jul 2014 17:00:34 GMT secure: yes inline signing: yes key maintenance: automatic next key event: Fri, 01 Aug 2014 02:00:00 GMT next resign node: ns.example.com/NSEC next resign time: Sat, 23 Aug 2014 12:30:46 GMT dynamic: yes frozen: no 3. [root@dnssec zone]# /opt/bind-9.10.0-P2/sbin/rndc -c /opt/bind-9.10.0-P2/etc/named-sld-rndc.conf -s 10.10.10.10 zonestatus example.com name: example.com type: master files: /usr/local/named/zone/example.com.zone serial: 2013122402 signed serial: 2013122405 nodes: 5 last loaded: Wed, 30 Jul 2014 17:00:34 GMT secure: yes inline signing: yes key maintenance: automatic next key event: Sat, 23 Aug 2014 13:30:46 GMT next resign node: example.com/DNSKEY next resign time: Sat, 23 Aug 2014 13:00:00 GMT dynamic: yes frozen: no 4. [root@dnssec zone]# /opt/bind-9.10.0-P2/sbin/rndc -c /opt/bind-9.10.0-P2/etc/named-sld-rndc.conf -s 10.10.10.10 zonestatus example.com name: example.com type: master files: /usr/local/named/zone/example.com.zone serial: 2013122402 signed serial: 2013122406 nodes: 5 last loaded: Wed, 30 Jul 2014 17:00:34 GMT secure: yes inline signing: yes key maintenance: automatic next key event: Sat, 23 Aug 2014 13:30:46 GMT next resign node: ns.example.com/NSEC next resign time: Mon, 15 Sep 2014 00:10:11 GMT dynamic: yes frozen: no I notice that next resign node are only ns.example.com/NSEC, example.com/DNSKEY but actually, in example.com there are 5 nodes. How dose bind choose a next resign node? What algorithm is it? Thank you Jittinan Suwanrueangsri ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
