Re: Create DS and DLV records
On Wed, May 05, 2010 at 11:59:23AM +0530, rams wrote a message of 36 lines which said: > could you please explain me, how to create DS and DLV records into my zone. If you want to add DS or DLV records in _your_ zone, you typically never create them. Managers of child zones do it and they send it to you and you just include them. However, I believe your question is not phrased properly and you want to create DS and DLV records to be included, not in your zone but in the _parent_ zone. Correct? If so, it depends on the signer you use. With BIND's dnssec-signzone, a file containing the DS (and named from the zone) is created by default: % cat dsset-example.org. example.org.IN DS 38078 7 1 48DC6B209ABB716549F833852141890DC99D4BCA example.org.IN DS 38078 7 2 30CC4B8F36687D3C2B7FD64448C167295875DE5486BBCCE4E36CDA52 6656C547 With option '-l dlv.isc.org', you can create DLV records as well: % cat dlvset-example.org. example.org.dlv.isc.org. IN DLV 38078 7 1 48DC6B209ABB716549F833852141890DC99D4BCA example.org.dlv.isc.org. IN DLV 38078 7 2 30CC4B8F36687D3C2B7FD64448C167295875DE5486BBCCE4E36CDA52 6656C547 (Note they have the same syntax so you could use an editor to create them as well...) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching to TCP in BIND.
In article , Stephane Bortzmeyer wrote: > On Wed, Apr 28, 2010 at 11:59:11AM -0400, > Kevin Darcy wrote > a message of 21 lines which said: > > > I know of no such feature. What do you mean by "spoofed" anyway? How > > would you expect named to detect "spoofing", and is that its job? > > It seems (not tested by me) that Nominum CNS does that: when many > responses arrive which do not match (src IP address, query ID, etc) > any pending answer, it switches to TCP, assuming someone tries to > poison it. > > This is supposed to be a protection against the Kaminsky attack. Interesting. "Switches" by what means? Returns TC responses to all UDP queries? Just for particular clients or particular domains? Is this documented at all (yes, I'm too lazy to Google :-) ). Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching to TCP in BIND.
> > > I know of no such feature. What do you mean by "spoofed" anyway? How > > > would you expect named to detect "spoofing", and is that its job? > > > > It seems (not tested by me) that Nominum CNS does that: when many > > responses arrive which do not match (src IP address, query ID, etc) > > any pending answer, it switches to TCP, assuming someone tries to > > poison it. > > > > This is supposed to be a protection against the Kaminsky attack. > > Interesting. "Switches" by what means? Returns TC responses to all UDP > queries? Just for particular clients or particular domains? Is this > documented at all (yes, I'm too lazy to Google :-) ). According to the Nominum CNS manual, "When a single query ID mismatch is detected in the expected DNS response, CNS switches the recursive query to the more reliable TCP protocol ..." So it is definitely documented - though I'm sure there are details of the implementation which are *not* documented in the regular user manual. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching to TCP in BIND.
On Wed, May 05, 2010 at 09:35:38AM +0100, Sam Wilson wrote a message of 22 lines which said: > > It seems (not tested by me) that Nominum CNS does that: when many > > responses arrive which do not match (src IP address, query ID, etc) > > any pending answer, it switches to TCP, assuming someone tries to > > poison it. > > > > This is supposed to be a protection against the Kaminsky attack. > > Interesting. "Switches" by what means? I don't understand the question. When detecting an attack, CNS decides to query the authoritative name servers with TCP instead of querying with UDP as it does by default, that's all. > Returns TC responses to all UDP queries? Why would it do that? The stub resolvers would not know what to do with it. > Just for particular clients or particular domains? Is this > documented at all I don't know. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching to TCP in BIND.
In article , sth...@nethelp.no wrote: > > > > I know of no such feature. What do you mean by "spoofed" anyway? How > > > > would you expect named to detect "spoofing", and is that its job? > > > > > > It seems (not tested by me) that Nominum CNS does that: when many > > > responses arrive which do not match (src IP address, query ID, etc) > > > any pending answer, it switches to TCP, assuming someone tries to > > > poison it. > > > > > > This is supposed to be a protection against the Kaminsky attack. > > > > Interesting. "Switches" by what means? Returns TC responses to all UDP > > queries? Just for particular clients or particular domains? Is this > > documented at all (yes, I'm too lazy to Google :-) ). > > According to the Nominum CNS manual, > > "When a single query ID mismatch is detected in the expected DNS > response, CNS switches the recursive query to the more reliable TCP > protocol ..." > > So it is definitely documented - though I'm sure there are details of > the implementation which are *not* documented in the regular user > manual. Oh, I see. It's the other way round from what I had (wrongly) assumed - if the response to a query looks suspect then CNS will retry the query using TCP to try to protect against spoofed answers coming back. Seems sensible. Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Switching to TCP in BIND.
In article , Stephane Bortzmeyer wrote: > On Wed, May 05, 2010 at 09:35:38AM +0100, > Sam Wilson wrote > a message of 22 lines which said: > > > > It seems (not tested by me) that Nominum CNS does that: when many > > > responses arrive which do not match (src IP address, query ID, etc) > > > any pending answer, it switches to TCP, assuming someone tries to > > > poison it. > > > > > > This is supposed to be a protection against the Kaminsky attack. > > > > Interesting. "Switches" by what means? > > I don't understand the question. When detecting an attack, CNS decides > to query the authoritative name servers with TCP instead of querying > with UDP as it does by default, that's all. Yeah - I misunderstood the original description and had in my mind CNS getting spoofed responses and causing the original querier to retry with TCP. I understand now. Thanks, Sam ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Preparing for upcoming DNSSEC changes on 5/5
8:30 EDT 05/05/2010 and the world hasn't ended here yet. We can celebrate Cinco de Mayo in peace. If only I didn't detest tequila. Side note: I've actually been to Puebla Mexico which is where the battle that Cinco de Mayo commemorates took place. -Original Message- From: bind-users-bounces+jlightner=water@lists.isc.org [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of Laws, Peter C. Sent: Tuesday, May 04, 2010 6:09 PM To: bind-us...@isc.org Subject: RE: Preparing for upcoming DNSSEC changes on 5/5 > It may be the person that suggested setting it was under the > misapprehension that the two values would be the same but the quote from > the Java testing tool made it clear that is NOT the case. I think this is it exactly. But someone in the thread seemed pretty certain that we needed to set our packet size to what the test reported which just didn't make sense. OK, so, bring on the End Of The Internet tomorrow! Peter ___ 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: Preparing for upcoming DNSSEC changes on 5/5
On 5/5/2010 1:32 PM, Lightner, Jeff wrote: > 8:30 EDT 05/05/2010 and the world hasn't ended here yet. > > We can celebrate Cinco de Mayo in peace. If only I didn't detest > tequila. > > Side note: I've actually been to Puebla Mexico which is where the > battle that Cinco de Mayo commemorates took place. Not so fast! It's not 17:00 GMT yet. Still ~4 more hours. "** The final transition to the DURZ will take place on ** J-Root, on 2010-05-05 between 1700--1900 UTC." 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: Preparing for upcoming DNSSEC changes on 5/5
On May 5 2010, Lightner, Jeff wrote: 8:30 EDT 05/05/2010 and the world hasn't ended here yet. The switchover of j.root-servers.net to "DURZ" is scheduled for 17:00-19:00 UTC (see http://www.root-dnssec.org/ - or just try "dig dnskey . @j.root-servers.net"). We aren't there yet ... We can celebrate Cinco de Mayo in peace. If only I didn't detest tequila. Side note: I've actually been to Puebla Mexico which is where the battle that Cinco de Mayo commemorates took place. The (in fact largely successful) French invasion was apparently triggered by Mexico defaulting on its debts. Watch out, Greece ... -- 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: DNSSEC
On May 4, 2010, at 11:01 AM, Linux Addict wrote: On Tue, May 4, 2010 at 10:43 AM, Stephane Bortzmeyer > wrote: On Tue, May 04, 2010 at 10:27:25AM -0400, Linux Addict wrote a message of 89 lines which said: > lacks EDNS, defaults to 512" > DNS reply size limit is at least 490" > "Tested at 2010-05-04 14:21:02 UTC" You edited the responses (which includes an IP address). Is it the IP address of your resolver? There is may be a forwarder which does not have EDNS. Second possibility, a middlebox mangles your packets and deletes EDNS options. Actually that IP was our external NAT. One information I neglected to mention is bind forwards to a tinydns appliance which of course does not support DNSSEC for obvious reasons. So what are my options now? Will the internet work for me tomorrow? At least I have company in Google.. dig +short rs.dns-oarc.net txt @8.8.8.8 rst.x476.rs.dns-oarc.net. rst.x485.x476.rs.dns-oarc.net. rst.x490.x485.x476.rs.dns-oarc.net. "64.233.168.94 DNS reply size limit is at least 490" "64.233.168.94 lacks EDNS, defaults to 512" "Tested at 2010-05-04 15:00:07 UTC" Actually, we do support EDNS0, but usually only advertise larger buffers if needed. For example, if you retry this with +dnssec you should get: wkum...@colon:/$ dig +dnssec +short rs.dns-oarc.net txt @8.8.8.8 rst.x1247.rs.dns-oarc.net. rst.x1257.x1247.rs.dns-oarc.net. rst.x1228.x1257.x1247.rs.dns-oarc.net. "74.125.44.94 DNS reply size limit is at least 1257" "74.125.44.94 sent EDNS buffer size 1280" "Tested at 2010-05-05 15:51:16 UTC" wkum...@colon:/$ W ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- If the bad guys have copies of your MD5 passwords, then you have way bigger problems than the bad guys having copies of your MD5 passwords. -- Richard A Steenbergen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC
On Wed, May 5, 2010 at 11:53 AM, Warren Kumari wrote: > > On May 4, 2010, at 11:01 AM, Linux Addict wrote: > > On Tue, May 4, 2010 at 10:43 AM, Stephane Bortzmeyer wrote: > >> On Tue, May 04, 2010 at 10:27:25AM -0400, >> Linux Addict wrote >> a message of 89 lines which said: >> >> > lacks EDNS, defaults to 512" >> > DNS reply size limit is at least 490" >> > "Tested at 2010-05-04 14:21:02 UTC" >> >> You edited the responses (which includes an IP address). Is it the IP >> address of your resolver? There is may be a forwarder which does not >> have EDNS. >> >> Second possibility, a middlebox mangles your packets and deletes EDNS >> options. >> >> > Actually that IP was our external NAT. One information I neglected to > mention is bind forwards to a tinydns appliance which of course does not > support DNSSEC for obvious reasons. > > So what are my options now? Will the internet work for me tomorrow? > At least I have company in Google.. > > dig +short rs.dns-oarc.net txt @8.8.8.8 > rst.x476.rs.dns-oarc.net. > rst.x485.x476.rs.dns-oarc.net. > rst.x490.x485.x476.rs.dns-oarc.net. > "64.233.168.94 DNS reply size limit is at least 490" > "64.233.168.94 lacks EDNS, defaults to 512" > "Tested at 2010-05-04 15:00:07 UTC" > > > > > Actually, we do support EDNS0, but usually only advertise larger buffers > if needed. > > For example, if you retry this with +dnssec you should get: > > wkum...@colon:/$ dig +dnssec +short rs.dns-oarc.net txt @8.8.8.8 > rst.x1247.rs.dns-oarc.net. > rst.x1257.x1247.rs.dns-oarc.net. > rst.x1228.x1257.x1247.rs.dns-oarc.net. > "74.125.44.94 DNS reply size limit is at least 1257" > "74.125.44.94 sent EDNS buffer size 1280" > "Tested at 2010-05-05 15:51:16 UTC" > wkum...@colon:/$ > > > W > > thanks for the clarification, I learned that after sometime. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
