Re: [DNSOP] on private use TLDS

On 11/28/19 4:24 PM, Joe Abley wrote: On Nov 28, 2019, at 19:07, Doug Barton wrote: Can you please explain why ICANN's work on name collision and the ongoing onslaught of queries at the root for un-delegated TLDs are not sufficient evidence? If it's not obvious from the questio

Re: [DNSOP] on private use TLDS

On 11/28/19 5:15 PM, John R Levine wrote: On Thu, 28 Nov 2019, Doug Barton wrote: I don't see how relying on ISO's advice is poaching.  They say: You, like Ted, are ignoring the fact that ISO can choose to change those rules. The user assigned codes are part of the publishe

Re: [DNSOP] on private use TLDS

Can you please explain why ICANN's work on name collision and the ongoing onslaught of queries at the root for un-delegated TLDs are not sufficient evidence? And if not, how do you propose that we study it? Doug On 11/28/19 3:58 PM, Joe Abley wrote: Hi Doug, I appreciate the response and I

Re: [DNSOP] on private use TLDS

On 11/28/19 2:42 PM, Roy Arends wrote: On 28 Nov 2019, at 22:30, Doug Barton wrote: And if you don't think ICANN has promised to not delegate HOME, CORP, and MAIL; you didn't read the reference I provided. From section 3.2: "The deferral is not guaranteed to be forever

Re: [DNSOP] on private use TLDS

On 11/28/19 2:20 PM, Joe Abley wrote: Hi Doug, I am not suggesting that you are wrong in your final paragraph, and I am not philosophically opposed to reserving a label in the root zone for private use, somehow analogously to RFC1918, but I think it's worth challenging how obvious this really

Re: [DNSOP] [Ext] on private use TLDS

On 11/28/19 2:15 PM, Paul Hoffman wrote: On Nov 28, 2019, at 1:30 PM, Doug Barton wrote: The IETF and ICANN share a sandbox on many topics, including the root zone. (But of course you already knew that.) And if you don't think ICANN has promised to not delegate HOME, CORP, and MAIL

Re: [DNSOP] on private use TLDS

On 11/28/19 8:55 AM, John Levine wrote: In article <71ad677a-8c88-8916-fe02-7d0d8ae93...@dougbarton.us> you write: I agree with Matt, Bill Woodcock, Steve Crocker, and others that have expressed that we should stay out of ISO's sandbox. Whatever the rules are today, they can change, and poaching

Re: [DNSOP] on private use TLDS

t in to ICANN’s? ICANN has not promised never to delegate those domains, whereas ISO effectively has, so your reasoning doesn’t make sense. On Nov 27, 2019, at 23:39, Doug Barton wrote: On 11/26/19 9:16 AM, Matthew Pounsett wrote: On Tue, 26 Nov 2019 at 05:19, Roy Arends mailto:r...@dnss.ec>

Re: [DNSOP] on private use TLDS

On 11/26/19 9:16 AM, Matthew Pounsett wrote: On Tue, 26 Nov 2019 at 05:19, Roy Arends > wrote: “ZZ” was used in my presentation as an example. Since this bikeshedding is siphoning attention from the important part of the discussion, I’ll try to re-focus on the

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 09:19 AM, Vladimír Čunát wrote: Ehm, we somehow forgot that this thread is supposed to be about DHCP, so that's only the "uninteresting" case where you do trust the ISP and want to use their DNS over a secure channel:-D This perspective that users "trust" their network environment

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 09:25 AM, Ted Lemon wrote: DHCP is automatic, so the question of what to do when you have configuration information that conflicts with DHCP needs to be addressed.   It isn't "simple" simply because it addresses only one specific use case. If your "conflicting information" issue

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

talking about one of a number of different ways of configuring DoT. On Tue, Aug 21, 2018 at 11:04 PM Doug Barton <mailto:do...@dougbarton.us>> wrote: On 08/21/2018 05:48 AM, Ted Lemon wrote: > On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton mailto:do...@d

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/21/2018 05:48 AM, Ted Lemon wrote: On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton <mailto:do...@dougbarton.us>> wrote: You, like Ted, are looking at the problem the wrong way 'round. And this, in a nutshell, is why this discussion has gone on so long.  If you just c

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/20/2018 06:11 PM, Paul Hoffman wrote: DHCP options are easy and cheap. However #2 was vexing. The proposal that an OS say "oh look, there is a DoH server, I'll use that because it is more secure than Do53" was what was controversial because of the utter lack of DHCP security. Some of the

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/20/2018 09:22 PM, Bill Woodcock wrote: On Aug 20, 2018, at 6:40 PM, Paul Ebersman wrote: pusateri> There was general pusateri> agreement in the room that you only should use DHCP in IPv4 pusateri> for address/router info and then use trusted sources for pusateri> everything else. In I

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

knowledgeable about such things, the only time they matter to your normal, non-security-aware user is when they intentionally configure a resolver (DOH/DOT or not). If they do this, they are taken out of the realm of DHCP resolver options entirely. Doug On Sun, Aug 19, 2018 at 8:2

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/19/2018 04:57 PM, manu tman wrote: On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon > wrote: A user who relies on the dhcp server for dns server info is no worse off. The problem is that if your host lets the dhcp server override the DoT or DoH configuratio

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

I agree with Steinar's sensibilities on this, FWIW. Ted, you've restated your thesis several times now, but what I haven't seen is an answer to my question, so let me pose it a different way. How is a user that relies on the DHCP server's DOH or DOT resolving name server instructions worse of

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/19/2018 06:18 AM, Livingood, Jason wrote: So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk thr

Re: [DNSOP] Draft for dynamic discovery of secure resolvers

On 08/18/2018 06:08 PM, Ted Lemon wrote: The thing is that most devices don't connect to just one network.   So while your devices on your network can certainly trust port 853 on your network, when they roam to other networks, they have no reason to trust it.   If you have devices that never ro

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

On 03/17/2017 03:22 AM, Havard Eidnes wrote: If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again? If something is unable to unambiguously ask for the exact thing it really needs, that's their problem. It's not

Re: [DNSOP] DNSOP Call for Adoption draft-vixie-dns-rpz

On 03/13/2017 07:28 PM, Dave Crocker wrote: On 3/13/2017 1:28 PM, Viktor Dukhovni wrote: Whether we like it or not, publication of said existing practice by the IETF will be seen as an endorsement of that practice. This kind of assertion is frequently made, but never demonstrated with anythin

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

cause far more disruption than benefit. Doug On 03/17/2017 12:12 AM, Jim Reid wrote: On 17 Mar 2017, at 06:54, Doug Barton wrote: If something gets an ANY response that does not include the thing it really needs, how is it supposed to know that it needs to ask again? If something is

Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

I think this is a bad idea generally, and that RRL is a better solution to the amplification vector issue. But since the "War on ANY" doesn't show signs of abating ... On 03/16/2017 09:27 PM, Richard Gibson wrote: To re-raise my unaddressed points from the first Working Group Last Call: * T

Re: [DNSOP] draft-arends-dnsop-dnssec-algorithm-update

I can't help finding this discussion funny, as I proposed prior to the -bis docs that we make RSA-SHA256 mandatory, and SHA1 optional; for the simple reason that it was overwhelmingly likely that the root would be signed with the former, making it as close to mandatory to implement as possible

Re: [DNSOP] Differences between one view and two in BIND when slaving a zone

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/21/14 7:09 PM, Doug Barton wrote: | When using a separate view in a recursor that is also performing | DNSSEC validation | the DS records in the slaved zone will be validated as they are | used. In BIND this validation does not occur when

Re: [DNSOP] Differences between one view and two in BIND when slaving a zone

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/21/14 6:12 PM, Paul Hoffman wrote: | Clearly, different people view the "advantages" and "disadvantages" | separately. The wording below tries to make the comparisons neutral | while still fully stating what the differences are. Note that I |

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

On 11/20/14 11:27 AM, Evan Hunt wrote: On Thu, Nov 20, 2014 at 11:13:42AM -0800, Doug Barton wrote: Slaving the zone into the same view/instance as the recursion has the advantage that when changes happen to the data in the zone the recursive view/instance will be updated as soon as it receives

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

What about something like this: When using BIND, or other software that can act as both a recursive and authoritative server in the same instance, there is a tradeoff between using a separate view (or separate instance) for slaving the root zone, versus slaving the zone into the same view (or

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

On 11/20/14 9:34 AM, Paul Hoffman wrote: On Nov 20, 2014, at 9:19 AM, Doug Barton wrote: The question at the end of this post was a serious one, FWIW. If I understand it correctly, the question is a feature request for BIND/NSD/whatnot, not an issue with the draft, correct? That is, I think

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

The question at the end of this post was a serious one, FWIW. On 11/17/14 3:39 PM, Doug Barton wrote: On 11/17/14 2:50 PM, Evan Hunt wrote: On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote: That seems like something that should be fixable in BIND, yes? (And thanks for doing that

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

On 11/17/14 2:50 PM, Evan Hunt wrote: On Mon, Nov 17, 2014 at 02:16:22PM -0800, Doug Barton wrote: That seems like something that should be fixable in BIND, yes? (And thanks for doing that testing, btw) Yes, by using two views and slaving the root in one of them and validating in the other

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

On 11/16/14 11:12 PM, Evan Hunt wrote: On Sun, Nov 16, 2014 at 03:12:58PM -0800, Doug Barton wrote: Before commenting further I'd love the authors to flesh out their reasoning for not simply slaving the zone where possible. I'm not one of the authors, but I can give you an answe

Re: [DNSOP] Call for Adoption draft-wkumari-dnsop-root-loopback

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/16/14 1:45 PM, Tim Wicinski wrote: | | This starts a Call for Adoption for | draft-wkumari-dnsop-root-loopback I have read the draft, I support its adoption, and I will review and contribute text as necessary. It should come as no surprise t

Re: [DNSOP] PTR usage cases for networking Re: Using PTRs for security validation is stupid

On 11/12/14 9:48 AM, Olafur Gudmundsson wrote: The usage case that got brought up at the mike “PTR records are used by logging systems” got me thinking “when does a logging system need this information” and the answer is I think “when a human is looking at the log” in all other cases if the syste

Re: [DNSOP] A Preliminary Test for Loopback Server

On 11/10/14 9:28 AM, Evan Hunt wrote: One of these days I want to write a mail client that checks for the word "attached" and refuses to let me hit send until I attach something. Well the obvious solution is to attach the item first, then write the message. :) ... and FWIW, Thunderbird will

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

On 10/30/14 6:02 PM, Ted Lemon wrote: On Oct 30, 2014, at 6:05 PM, Doug Barton wrote: 1. "Residential" users, or more specifically, those who will not be/should not be running services on their addresses This is not a value judgment the IETF should be making. Of course not, but

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

Lee, I don't see any discussion in your draft about why rDNS is needed in this space. IME there are typically 2 uses cases: 1. "Residential" users, or more specifically, those who will not be/should not be running services on their addresses 2. "Commercial" users, who may be running things

Re: [DNSOP] Possible slower response with minimization

On 10/27/14 3:09 PM, Warren Kumari wrote: On Sat, Oct 25, 2014 at 11:57 AM, Stephane Bortzmeyer wrote: On Mon, Oct 20, 2014 at 05:26:29PM -0400, Phillip Hallam-Baker wrote a message of 74 lines which said: If we are going there, I would want to know how common the configurations are. Y

Re: [DNSOP] Fwd: New Version Notification for draft-livingood-dnsop-negative-trust-anchors-01.txt

On 10/24/14 9:01 AM, Warren Kumari wrote: Hi all, This draft has risen from the deep... It describes a technique that a number of DNS operators use to surgically / tactically deal with DNSSEC validation failures, for large-scale outages. We believe that this is needed -- simply telling custome

Re: [DNSOP] Possible slower response with minimization

On 10/20/14 2:03 PM, Bob Harold wrote: I support the idea of qname minimization, but I think there is a common case where it will cause additional DNS round trips, slowing the response and increasing the number of packets and queries the servers must handle. Consider “www.host.group.department.e

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 9/21/14 2:04 PM, Doug Barton wrote: | On 9/21/14 1:14 PM, Suzanne Woolf wrote: |> Hi, |> |> This topic has come up here many times before, and there always |> seems to be interest. A fielded implementation and Paul's |&

Re: [DNSOP] fyi [Pdns-users] Please test: ALIAS/ANAME apex record in PowerDNS

On 9/21/14 1:14 PM, Suzanne Woolf wrote: Hi, This topic has come up here many times before, and there always seems to be interest. A fielded implementation and Paul's suggestion of an interoperable spec both seem like healthy developments. As always I stand ready to revive https://tools.ietf.

Re: [DNSOP] NOTE RR type for confidential zone comments

On 05/27/2014 04:49 PM, Evan Hunt wrote: On Tue, May 27, 2014 at 04:08:29PM -0700, Doug Barton wrote: I'm interested in why you think a flag bit is more elegant than an option, as I agree with Nicholas that the latter is preferable. As with any argument that resorts to "eleganc

Re: [DNSOP] NOTE RR type for confidential zone comments

On 05/27/2014 12:29 PM, Evan Hunt wrote: One of our operations staff made what I thought was a clever suggestion the other day: That it would be nice, from an operational standpoint, to have a way to encode comments into a zone so that they wouldn't get obliterated when a dynamic zone was dumped

Re: [DNSOP] call to work on edns-client-subnet

On 05/06/2014 10:30 AM, Joe Abley wrote: On 6 May 2014, at 13:27, Doug Barton wrote: On 05/06/2014 10:18 AM, Joe Abley wrote: I think not picking up this work will result in implementation and operational problems. Those of us who still have the vomity taste would like the problems with

Re: [DNSOP] call to work on edns-client-subnet

On 05/06/2014 10:18 AM, Joe Abley wrote: I think not picking up this work will result in implementation and operational problems. Those of us who still have the vomity taste would like the problems with interop and implementation to continue. Just because we _can_ make something work better

Re: [DNSOP] Unexpected behaviour of dig +trace

On 3/26/2014 9:41 AM, Evan Hunt wrote: On Wed, Mar 26, 2014 at 06:52:44PM +0800, Warren Kumari wrote: "Feature", but does catch many folk by surprise. I'd written a patch and given it to someone at ISC that makes dig output a warning message if you hand it both the "+trace" and "@server" options

Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

On 02/07/2014 10:14 AM, Warren Kumari wrote: On Fri, Feb 7, 2014 at 1:12 PM, Doug Barton wrote: On 02/06/2014 11:13 AM, Warren Kumari wrote: This means that you can use this to update / replace / remove existing DS records (if you have keys A, B, C and D and want to stop using C, you simply

Re: [DNSOP] how to delete obsolete DS for obsolete DNSKEY using CDS/CDNSKEY

On 02/06/2014 11:13 AM, Warren Kumari wrote: This means that you can use this to update / replace / remove existing DS records (if you have keys A, B, C and D and want to stop using C, you simply publish A, B, D), but you cannot remove*all* DS records / go unsigned. If we're willing to allow z

Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

On 01/14/2014 04:43 PM, Doug Barton wrote: Other than the DS records (if any) the records associated with a given TLD (specifically the NS records) in the root are not signed. ... obviously the glue records are not signed either of course. My point was that it's the delegation that

Re: [DNSOP] More keys in the DNSKEY RRset at ., and draft-ietf-dnsop-respsize-nn

On 01/14/2014 12:08 PM, Andrew Sullivan wrote: Good point. I think the idea is that this is a feature, because it's supposed to be the Mutually-Assured Destruction threat that will prevent the USG from unilaterally removing some country from the root zone (that seems to be the threat people are

Re: [DNSOP] CDS and/or CDNSKEY

On 10/08/2013 01:22 PM, Warren Kumari wrote: In many regulatory environments (the polite way of saying where ICANN says "No!") Just FYI, it's not ICANN that says no. It's the registrars who do not want ANY channel of communication with their customers that does not go through them. ICANN simp

Re: [DNSOP] CDS and/or CDNSKEY

On 10/08/2013 12:52 PM, Paul Hoffman wrote: On Oct 8, 2013, at 11:48 AM, Doug Barton wrote: However I think a reasonable conclusion from the stalemates that have arisen from all of the previous attempts over the years would be, "There is no agreement on how to proceed, so we shoul

Re: [DNSOP] CDS and/or CDNSKEY

On 10/08/2013 11:13 AM, Paul Wouters wrote: On Tue, 8 Oct 2013, Doug Barton wrote: What's actually missing is a signaling mechanism from the child to the parent. Google for "timers versus triggers". We had that discussion years ago. I know, I've followed the thin

Re: [DNSOP] CDS and/or CDNSKEY

Responding to a message at random ... With respect to all of those who are involved and highly motivated in this topic I continue to think that it is a solution in search of a problem. The DNSKEY needs to be in the child zone, and we know that parents have varying requirements for how they han

Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt

On 07/02/2013 10:25 PM, John Levine wrote: I don't see the real-world benefit of this. Fine: you don't need implement it. There are enterprise environments where the round-trip times are more significant to them than they seem to you in your enterprise environment. I'm still trying to figure

Re: [DNSOP] Thoughts on CDS

On 04/23/2013 02:02 PM, Wes Hardaker wrote: Objecting to the notion without offering fixes is like saying "I don't want soup to exist because watching people eat it might make me want it in the future". Wes, that's not only not true, it's at best inflammatory, and IMO ad hominem. As I pointe

Re: [DNSOP] Thoughts on CDS

On 04/23/2013 02:20 PM, Wes Hardaker wrote: Doug Barton writes: ... thus creating a support problem when the customer checks their CDS record, sees that it is "valid," and then doesn't understand why the parent won't accept it. Yes, but a CDS management tool wouldn&#

Re: [DNSOP] Thoughts on CDS

On 04/23/2013 01:53 PM, Wes Hardaker wrote: Edward Lewis writes: I firmly believe that a validator (as described in 4033-4035) should have to be altered for the CDS proposal. I don't think so at all. Validators will still provide you with a "valid" answer for the CDS record no matter which

Re: [DNSOP] Thoughts on CDS

FWIW, I agree with Ed's points below (some of which I have expressed previously). Doug On 04/23/2013 11:37 AM, Edward Lewis wrote: On Apr 23, 2013, at 12:39, Paul Wouters wrote: I get it, you don't like the concept. No, that's not true. I see great utility in placing whatever is needed

Re: [DNSOP] Thoughts on CDS

On 04/22/2013 02:19 PM, Joe Abley wrote: On 2013-04-22, at 17:17, Wes Hardaker wrote: Wes Hardaker writes: For what it's worth: I'm sort of on the fence when it comes to needing to sign with the KSK. There are so very very few key-split owners out there that it's not a huge market for the

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 12:53 PM, Joe Abley wrote: On 2013-03-13, at 13:34, Doug Barton wrote: On 03/13/2013 10:20 AM, Joe Abley wrote: On 2013-03-13, at 13:17, Doug Barton wrote: In order to really make this work a non-trivial number of TLD registries (which have a variety of different rules and

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 11:13 AM, Alan Clegg wrote: Why is this argument so tied up in TLD operations when it is going to be so useful for all of the rest of us even if the TLDs don't use it? It's NOT just for TLDs, it's for anyone that does secure delegations. ... as I have acknowledged many times. :)

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 10:20 AM, Joe Abley wrote: On 2013-03-13, at 13:17, Doug Barton wrote: In order to really make this work a non-trivial number of TLD registries (which have a variety of different rules and policies) AND registrars would have to be on board. No. Where there are registrars

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 10:05 AM, Paul Wouters wrote: On Wed, 13 Mar 2013, Doug Barton wrote: So how likely are those parents to utilize CDS records to auto-publish DS? Or, put more simply, Do we have any indication that registry operators will actually use this? I know that registries are not the only

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 10:02 AM, Joe Abley wrote: On 2013-03-13, at 12:54, Doug Barton wrote: On 03/13/2013 09:39 AM, Joe Abley wrote: However, there's nothing to stop registrars making arrangements with their registrants to receive change requests via signed RRSets. It may that for gTLDs

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/13/2013 09:39 AM, Joe Abley wrote: On 2013-03-13, at 12:26, Doug Barton wrote: On 03/13/2013 07:45 AM, Joe Abley wrote: 1. Because not all parents (by policy) construct DS records on behalf of children; So how likely are those parents to utilize CDS records to auto-publish DS? Or

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

published in the child. If the parents are actually using some method of accepting signals from the child to scrape the zone (whether CDS; actual scraping of NS, DNSKEY, etc.; or some other method) wouldn't that lower the barrier to entry for standby keys? Doug On 2013-03-13, at 3:00, Doug B

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/12/2013 11:52 AM, Johan Ihrén wrote: On Mar 7, 2013, at 10:58 , Tony Finch wrote: Paul Wouters wrote: To get back to the draft: I have not seen too many people talk about the CNS/GLUE record types. Should those be in this draft, a separate draft, or no where? Why not use the child's

Re: [DNSOP] General comments on draft-kumari-ogud-dnsop-cds-01

On 03/07/2013 08:58 AM, Tony Finch wrote: Paul Wouters wrote: On Thu, 7 Mar 2013, Tony Finch wrote: To get back to the draft: I have not seen too many people talk about the CNS/GLUE record types. Should those be in this draft, a separate draft, or no where? Why not use the child's normal NS

Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00

On 07/14/2012 14:05, Joe Abley wrote: > > On 2012-07-14, at 16:50, Doug Barton wrote: > >> I would argue further that a child NS set which is a superset of >> the parent is not lame, or broken. There are valid reasons to do >> this, (outside the scope of this docume

Re: [DNSOP] draft-wouters-dnsop-secure-update-use-cases-00

On 07/11/2012 11:16, Andreas Gustafsson wrote: > Paul Wouters wrote: >> On Wed, 11 Jul 2012, Jim Reid wrote: >> >>> So it may be better if the draft uses a different term for the scenario >>> where >>> the parent and child do not have the same NS RRset. Perhaps that can be >>> called a Broken De

Re: [DNSOP] on "Negative Trust Anchors"

On 4/13/2012 2:19 PM, David Conrad wrote: > Patrik, > > On Apr 13, 2012, at 2:00 PM, Patrik Fältström wrote: >> What I am against is this *CHANGE* in who is responsible. > > I don't see NTAs changing who is responsible. I see it changing who > absorbs the costs. Without NTAs, it is primarily the

Re: [DNSOP] on "Negative Trust Anchors"

Responding to a message at random ... I skimmed the draft, and with respect to the authors this is a terrible idea. DNSSEC is pointless if it's not used as designed. Providing an easy way to bypass validation makes many things worse instead of better ... not the least of which is that if an attac

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

On 10/25/2011 10:20, Ted Lemon wrote: > > > On Oct 24, 2011, at 5:30 PM, "Doug Barton" > wrote: > >>> I think there's a need for IETF to document why any other value >>> than 1 is a Bad Idea, and more to the point, why it will break >>>

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

On 10/24/2011 13:58, Keith Moore wrote: > > On Oct 24, 2011, at 4:52 PM, Doug Barton wrote: > >> On 10/24/2011 05:16, Keith Moore wrote: >>> That's the point - search lists are not appropriate most of the time, and >>> it's very hard for softw

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

On 10/24/2011 05:16, Keith Moore wrote: > That's the point - search lists are not appropriate most of the time, and > it's very hard for software to distinguish the cases where they are > potentially appropriate from the cases when they're not, and it's not > possible for software to do this in

Re: [DNSOP] [dnsext] [mif] 2nd Last Call for MIF DNS server selection document

On 10/21/2011 08:13, Keith Moore wrote: > Names containing "." should not be subject to search lists. Given a > name like foo.bar, there's no reliable way to tell whether "bar" is a > TLD or a subdomain of something in the search list. I've been following this discussion, mostly in the hopes tha

Re: [DNSOP] WGLC [2011-05-17]

On 04/18/2011 16:14, George Barwood wrote: - Original Message - > From: "Paul Wouters" On Mon, 18 Apr 2011, George Barwood wrote: (1) It's my belief that almost all Zones except for the root zone should NOT use a KSK/ZSK split. With the signing of the root zone and many TLDs, manual

Re: [DNSOP] Question about the time of regular DS rollover by ICANN

On 01/09/2011 16:40, Zheng Wang wrote: I have a question on the ICANN's processing time of the regular DS RR rollover request from TLD operators. I find in ICANN's document saying that "the emergency change process will be completed and reflected in the root zone within 48 hours from the recepti

Re: [DNSOP] draft-liman-tld-names-04

On 11/26/2010 14:28, Andrew Sullivan wrote: On Fri, Nov 26, 2010 at 02:15:38PM -0800, Doug Barton wrote: Ah, now I get it. You're arguing that the protocol restriction did exist in the past, and now we're relaxing it, but only slightly. No, I'm arguing, just as the document

Re: [DNSOP] draft-liman-tld-names-04

On 11/25/2010 06:56, Andrew Sullivan wrote: On Wed, Nov 24, 2010 at 10:48:19AM -0800, Doug Barton wrote: IETF is supposed to be about interoperability, and if stuff breaks because we have decided, "We don't care lalalalalala I can't hear you there isn't a problem," th

Re: [DNSOP] draft-liman-tld-names-04

On 11/25/2010 09:52, Andrew Sullivan wrote: It seems to me that those who don't like the document aren't actually offering text that they'd like to see in the document. You may recall that my first post on the topic did actually offer a diff. My intention was to be minimalistic to avoid changi

Re: [DNSOP] draft-liman-tld-names-04

Generally I like this, and it is a much more thorough treatment than what I was working on. I think it needs a little wordsmithing, and I'm not clear if Tony's intention in the last section is to indicate that there should be a protocol restriction on non-IDN labels (which obviously I oppose).

Re: [DNSOP] draft-liman-tld-names-04

On 11/24/2010 06:23, Andrew Sullivan wrote: On Wed, Nov 24, 2010 at 01:15:23PM +1100, James Mitchell wrote: If deployed software does not work with a TLD, it is the TLD owner who loses. I'm sorry, but that claim is arrant nonsense. We _all_ lose. Which is why I mentioned specifically that I

Re: [DNSOP] draft-liman-tld-names-04

On 11/23/2010 17:35, Joe Abley wrote: On 2010-11-23, at 20:26, Doug Barton wrote: On 11/23/2010 16:19, Joe Abley wrote: 1. there is no restriction to be inferred from RFC 1123 that TLD labels be alphabetic; Unqualified "yes" to this. I presume you appreciate that not everyb

Re: [DNSOP] draft-liman-tld-names-04

On 11/23/2010 16:19, Joe Abley wrote: On 2010-11-23, at 17:44, Doug Barton wrote: I don't think you can mix those 2 terms in the same sentence. :) Just so I understand the context for your comments, you're saying that in your opinion: 1. there is no restriction to be inferred fro

Re: [DNSOP] draft-liman-tld-names-04

On 11/22/2010 06:30, Joe Abley wrote: Thanks for your review (Stéphane and Doug), and sorry for not replying to your comments earlier, Stéphane. I also know of no protocol (1034/1035) restriction for labels in the root zone. However, as the document describes in citations from 1123 there is som

Re: [DNSOP] draft-liman-tld-names-04

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/17/2010 01:19, Stephane Bortzmeyer wrote: | On Thu, Nov 11, 2010 at 01:42:24PM -0500, | Joe Abley wrote | a message of 15 lines which said: | |> http://www.ietf.org/id/draft-liman-tld-names-04.txt |> |> is the latest iteration of an effor

Re: [DNSOP] [saag] [pkix] [TLS] Cert Enumeration and Key Assurance With DNSSEC

On 10/5/2010 1:00 AM, der Mouse wrote: But the original statement was that DNSSEC provides "secure" association from name to IP. This is a stronger property than providing secure distribution of name-to-IP mapping information; it also implies that the creation of that information and its injecti

Re: [DNSOP] Question for someone with a V6 capable recursive resolver...

On Thu, 29 Jul 2010, Nicholas Weaver wrote: Could someone with a IPv6 connected recursive resolver do a favor for me? Validate that ipv6_dns.eaoe.n1.netalyzr.icsi.berkeley.edu resolves to 67.202.37.63 host ipv6_dns.eaoe.n1.netalyzr.icsi.berkeley.edu

Re: [DNSOP] automatic update of DS records

On 3/4/2010 11:03 PM, Alex Bligh wrote: Sure. And I don't want to expand a one-liner into more than it is worth, nor start a discussion on the merits of various registry models. All I was saying was that in a thin model, as the registry has no direct contact with registrants, and as the canonical

Re: [DNSOP] automatic update of DS records

On 3/4/2010 8:03 PM, Eric Brunner-Williams wrote: On 3/4/10 10:53 PM, Doug Barton wrote: On 3/4/2010 4:31 PM, Alex Bligh wrote: May be it's not a thick vs. thin distinction per se, but a "what happens if registrant falls out with registrar" distinction. Thick registries tha

Re: [DNSOP] automatic update of DS records

On 3/4/2010 4:31 PM, Alex Bligh wrote: May be it's not a thick vs. thin distinction per se, but a "what happens if registrant falls out with registrar" distinction. Thick registries that have a direct contract with the registrant (e.g. Nominet) tend tob be rather less willing to let a losing regi

Re: [DNSOP] automatic update of DS records

On 3/4/2010 3:33 PM, Alex Bligh wrote: --On 4 March 2010 15:16:29 -0800 Doug Barton wrote: The losing registrar is either going to be helpful, or unhelpful. Given that adding ANY kind of mechanism to enable secure transition of the domain is extra work without any direct benefit, the answer

Re: [DNSOP] automatic update of DS records

On 3/3/2010 6:39 AM, Tony Finch wrote: On Tue, 2 Mar 2010, Doug Barton wrote: 5. The very large number of misconfigured name servers out there now argue strongly against considering DNS a "secure" channel. I think I agree with everything except point 5. The aim of automating this is

Re: [DNSOP] automatic update of DS records

On 3/3/2010 11:50 AM, Stephan Lagerholm wrote: Correct, but I have a hard time seeing that the loosing registrar would be that helpful. It is more realistic to think that they could provide access to the private key for their hosted customer. And in that case the key can not be shared among custo

Re: [DNSOP] automatic update of DS records

On 3/2/2010 12:43 PM, Edward Lewis wrote: > An omnibus reply. A mini bus reply. :) I've read through this thread and I generally agree with Ed's analysis. Throwing in some more bullet points: 1. There MUST be an OOB (where the B is DNS) channel for initial zone configuration, contact info change

Re: [DNSOP] New version of document for review

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 01/15/10 08:16, Michelle Cotton wrote: > Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group > > There is a new version of the Internet Assigned Numbers Authority (IANA) > Procedures for the Management > of the Transpor

  1   2   >