Re: [DNSOP] [homenet] My assessment of .homenet as described during the WG session yesterday.

On Wed, Mar 29, 2017 at 5:07 PM, Mark Townsley wrote: > > > On Mar 29, 2017, at 10:07 AM, Michael Richardson > wrote: > > > > > > Terry Manderson wrote: > >> B) seek a .homenet special use domain WITHOUT the delegation

[DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

I was thinking about the DNSSEC validation by stubs, with respect to the homenet discussion. And, I was wondering about various trust anchor options (other than ICANN's current root trust anchor). It occurred to me, that any non-ICANN trust anchor, would possibly require 5011 key rolls under

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

On Mon, Mar 20, 2017 at 6:54 PM, Ted Lemon <mel...@fugue.com> wrote: > On Mar 20, 2017, at 9:50 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > This would require an update every time the KSK is rolled, or whenever the > RRSIG needs to be refreshed.

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

Brian > > Further comments inline. > > On Mar 20, 2017, at 6:08 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > >1. What is required for the above, is generation of DNSSEC records >including RRSIG(NS), NSEC, and RRSIG(NSEC), for "homen

Re: [DNSOP] WG review of draft-ietf-homenet-dot-03

> Hi, > The INT Area Director who oversees the homenet WG, Terry Manderson, has > asked DNSOP participants to review > https://www.ietf.org/id/draft-ietf-homenet-dot-03.txt, "Special Use Top > Level Domain '.homenet’”, with the following aspects in mind: > 1) in terms of RFC6761 > 2) in terms of

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

> > Richard Gibson wrote: > > Because without such a signal, humans using ANY for legitimate diagnostic > > purposes have no means of differentiating section 4.1/4.3 "subset" > > responses from conventional responses where there just happen to be only > a > > small number of RRSets at the queried

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote: > > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon > writes: > > > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote: > > > At the moment we have Ted saying that if you want privacy you MUST

Re: [DNSOP] ALT-TLD and (insecure) delgations.

.@isc.org> wrote: > > > In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer > writes > : >> On Wed, Feb 08, 2017 at 12:36:23PM -0800, >> Brian Dickson <brian.peter.dick...@gmail.com> wrote >> a message of 258 lines which said: >> >&g

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote: > > > And if the service has the same privacy issues as .onion has? > >

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews wrote: > > In message , Ted Lemon > writes: > > > > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote: > > > Which assumes agggressive negative caching. I'm going to make a

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote: > > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon > writes: > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. > > When I validate, I get a secure denial of existence. This is the

Re: [DNSOP] ALT-TLD and (insecure) delgations.

On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews <ma...@isc.org> wrote: > > In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian > Dickson writes: > > The suggestion of DNAME to empty.as112.arpa involves some subtle details, > > which IMHO may in

Re: [DNSOP] ALT-TLD and (insecure) delgations.

under alt would be unsigned NXDOMAINs. I am not seeing a problem with this. Am I missing anything? Brian Sent from my iPhone > On Feb 6, 2017, at 10:31 PM, Mark Andrews <ma...@isc.org> wrote: > > > > > In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.c

Re: [DNSOP] ALT-TLD and (insecure) delgations.

ate domain. An insecure delegation from the root may be seen as an invitation for exploitation by squatters. Sent from my iPhone > On Feb 6, 2017, at 8:05 PM, Mark Andrews <ma...@isc.org> wrote: > > > In message > <cah1icipkwcosmqy3kjvsz42lmk37gld6gp2avtnwk0c83k-...@mail.g

Re: [DNSOP] ALT-TLD and (insecure) delgations.

ohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@ > mail.gmail.com> > , Brian Dickson writes: > > > >- I am in favor of AS112 for ALT > >- For AS112, I prefer the AS112++ method (DNAME) > >- I do not see why the DNAME would/should not be DNSSEC signed > >- Any l

Re: [DNSOP] ALT-TLD and (insecure) delgations.

i, Feb 3, 2017 at 12:06 PM, Steve Crocker <steve.croc...@gmail.com> > wrote: > >> Are you also expecting ALT will never be delegated in the root? If it >> were to be delegated in the root, what impact would that have on the uses >> you have in mind? >> >>

Re: [DNSOP] ALT-TLD and (insecure) delgations.

sending from st...@shinkuro.com, but I am receiving > mail without trouble. Please continue to send mail to me at > st...@shinkuro.com] > > > On Feb 3, 2017, at 12:02 PM, Brian Dickson <brian.peter.dick...@gmail.com> > wrote: > > Stephane wrote: > >> On Wed, Fe

Re: [DNSOP] ALT-TLD and (insecure) delgations.

Stephane wrote: > On Wed, Feb 01, 2017 at 03:28:29PM -0500, > Warren Kumari wrote > a message of 103 lines which said: > > > or 2: request that the IANA insert an insecure delegation in the > > root, pointing to a: AS112 or b: an empty zone on the root or c" > > something similar. > > Here,

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote: > On Dec 14, 2016, at 5:04 PM, John Levine wrote: > > But it's worse than that -- if your client software does DNSSEC > validation it needs to understand that homenet is a special case and > it's OK not to

Re: [DNSOP] Future of "Using DNAME in the DNS root zone for sinking of special-use TLDs" ?

A short time ago, in a time zone not far away, Warren Kumari wrote: On Fri, Oct 14, 2016 at 10:04 AM, Paul Wouters wrote: > On Fri, 14 Oct 2016, Stephane Bortzmeyer wrote: > >> draft-bortzmeyer-dname-root >> >> ,

Re: [DNSOP] Another suggestion for any

? It would still accomplish Olafur's goal. Brian On Wed, Mar 11, 2015 at 2:00 AM, Paul Vixie p...@redbarn.org wrote: Brian Dickson brian.peter.dick...@gmail.com Wednesday, March 11, 2015 11:13 AM On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: Hey

[DNSOP] Another suggestion for any

On Sun, Mar 8, 2015 at 2:55 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: Hey, everyone, [snip] dig-friendly. Okay, thinking about this a bit more... Recursive vs authoritative, RD=0 vs RD=1. In all combinations of the above, do the new thing, except for one corner case: if(RD==1

[DNSOP] Suggestion for any - TCP only

Hey, everyone, Given the diagnostic value of any (and similarly RRSIG et al), I would prefer deprecation of only the UDP version, via mechanisms that are dig-friendly. E.g. return TC=1 (and minimal response) instead, to trigger TCP retry. It throws out the bath water, but keeps the baby. I am

Re: [DNSOP] Comments on draft-ietf-dnsop-root-loopback

On Sat, Jan 10, 2015 at 10:05 AM, Paul Hoffman paul.hoff...@vpnc.org wrote: Wearing my co-author hat: On Dec 29, 2014, at 2:23 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: - Given the unsigned nature of the glue in the zone, and the importance of root glue, it might be the right

[DNSOP] Fwd: Comments on draft-ietf-dnsop-cookies

black-listing IP addresses and filtering based on cookies. Both are effective at blocking DDOS traffic, but only cookies facilitate valid traffic flowing while attack traffic is blocked. Maybe something in an Appendix? Hope this is helpful. Brian Dickson

[DNSOP] Fwd: Comments on draft-ietf-dnsop-qname-minimisation

is an Empty Non-Terminal, e.g. a non-zone-cut with a child, but no RRs at the owner name. I seem to recall something along those lines but don't recall details, e.g. which software, version, etc., has this issue. Hope this is helpful. Brian Dickson

[DNSOP] Fwd: Comments on draft-ietf-dnsop-root-loopback

this is helpful. Feel free to ignore anything viewed as controversial or unlikely to gain consensus. Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Spartacus and new record types

IIRC, there is support for generic-named types similar to BIND's record type name/number thing. The RRTYPE would be a given a name which is something like rrtype, and numeric value associated with the name, which is . The RDATA would be encoded as a specified-length base-64 encoded

Re: [DNSOP] Spartacus and new record types

Sent from my iPhone On Nov 12, 2014, at 1:26 PM, Mark Andrews ma...@isc.org wrote: In message cah1iciqxwowao8nm8k-x47qiwawery9+etuefygzfn3aj5w...@mail.gmail.com, Brian Dickson writes: IIRC, there is support for generic-named types similar to BIND's record type name/number thing

Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)

Paul Vixie wrote: because right now the people who do this have to pirate the address space of root name servers, and they have to do it for all of our addresses. under this proposal, there would be no piracy required, and there would only be two address blocks per stack (two for v4, two for

Re: [DNSOP] Secure Unowned Hierarchical Anycast Root Name Service - And an Apologia (circleid)

On Mon, Nov 10, 2014 at 7:16 PM, Ralf Weber d...@fl1ger.de wrote: Moin! On 10 Nov 2014, at 16:49, Brian Dickson brian.peter.dick...@gmail.com wrote: The addresses associated with those names ( [a-m].root-servers.net ) are replaceable in a way which is undetectable and unprotected

Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

in another Appendix?) Brian Dickson The patch needed for 9.10.1 (which may work on other bind branches) is as follows: *diff --git a/lib/dns/validator.c b/lib/dns/validator.c* *index 88bfaef..31e9425 100644* *--- a/lib/dns/validator.c* *+++ b/lib/dns/validator.c* @@ -2274,7 +2274,8 @@ validatezonekey

Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

Sent from my iPhone On Nov 1, 2014, at 4:30 PM, Warren Kumari war...@kumari.net wrote: On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson brian.peter.dick...@gmail.com wrote: I think it is good to minimize disruption caused by broken DNSSEC domains, for all the reasons listed in the document

[DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

. (Is it the case that things that use DLV validate the chain of trust to the DLV itself, from the root, if there is not a separate trust anchor for the DLV zone? That would be optimal, security-wise, I believe.) Thoughts? Brian Dickson ___ DNSOP mailing

Re: [DNSOP] Call for Adoption: draft-bortzmeyer-dns-qname-minimisation

TL;DR tidbit: IF the combined authority+resolver case (when switching ISP hosting companies) is not handled by the QNAME minimization draft, IMHO it should consider adding it. It is a real-world problem edge-case seen frequently. On Tue, Oct 07, 2014 at 12:04:22AM -0400, Tim Wicinski wrote:

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-lang-00.txt

Hi, I have posted two new IDs, one for a DNS description language, the other for a DNS-JSON-DNS system, designed to be operated either as a bridge, or as a transparent proxy. I'm hoping for some initial feedback, including whether either/both belong in DNSOP. Thanks, Brian DIckson

[DNSOP] Fwd: New Version Notification for draft-dickson-dnsop-spartacus-system-00.txt

Hi, This is the second of the pair of drafts submitted together for consideration. (See the first post for the full description.) Brian Dickson -- Forwarded message -- From: internet-dra...@ietf.org Date: Wed, Oct 15, 2014 at 6:11 PM Subject: New Version Notification for draft

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

I'm not sure where it would belong, exactly, but certainly between best practices and DNSSEC security concerns, is the basic tenet: The DNS is a unified namespace. This leads to a number of potential issues, which can largely be addressed by viewing the issues from the perspective of a unified

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

stick to the notions of FQDN versus anything else, we can avoid entering the rat-hole, IMHO. (I.e., We don't need to get into any issues over the number of labels in an FQDN; an FQDN does not require treatment, special or otherwise; etc., etc.,) Brian Dickson On Thu, Oct 20, 2011 at 9:38 PM, Keith

[DNSOP] Time vs bootstrap (was Re: [dnsext] draft-jabley-dnsop-validator-bootstrap-00)

Top-replying here, to attempt a high-level suggestion on how to get some close approximation of time, using DNS/DNSSEC exclusively. (Warning to those with weak stomachs - this is mildly evil stuff.) First, without any assurances on the accuracy of local time, the best that can be achieved

Re: [DNSOP] Cache poisoning on DNSSEC

Dean Anderson wrote: On Sun, 24 Aug 2008, Brian Dickson wrote: Dean Anderson wrote: On Sun, 24 Aug 2008, Dean Anderson wrote: Ok. But when you resign using arbitrary data controlled by the attacker, the private key can be obtained. [There is a crypto attack

Re: [DNSOP] Cache poisoning on DNSSEC

[EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 12:04:15AM -0400, Brian Dickson wrote: The DS may be provided by the operator of the subordinate zone, or built by the parent operator, most likely the latter. thats an interesting premise. why do you think

Re: [DNSOP] Cache poisoning on DNSSEC

sigs, No he can't do that. Oh, no, No, he can't do that. -- Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP

bert hubert wrote: On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote: and let's also make explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. This means disabling one of the more widely used MTAs.

Re: [DNSOP] Services and top-level DNS names

Mark Andrews wrote: names which do not terminate in . (and in some cases, which might not permit such name termination). Consider the label foo.bar, a stub resolver, a recursive resolver, new TLD bar, and existing SLD example.com. Partially qualified domains and search lists

Re: [DNSOP] Fwd: New Version Notification

Paul Vixie wrote: [EMAIL PROTECTED] (Phil Regnauld) writes: Question: How do existing implementations react to the presence of a single, terminal dot ? What if an A record is published for '.' ? I know it probably won't happen. but I'm also curious to know, and I think the document should

Re: [DNSOP] Fwd: New Version Notification

Paul Vixie wrote: Is it not the case that ANCOUNT=0 RCODE=0 responses could be cached, whilst failures to send DNS UPDATE messages to root servers would not be cached? the data at hand tells me that lots of people don't cache, and those who do only cache positives. but in principle, yes,

Re: [DNSOP] Why deny AXFR from root servers?

Dean Anderson wrote: BTW, can you explain what these zones are? XN--KGBECHTV. NS A.IANA-SERVERS.NET Wow, an interesting, operationally pertinent question. It deserves mild praise and an answer. See http://www.iana.org/reports/2007/testetal-report-01aug2007.html (Things that start with

Re: [DNSOP] Public Suffix List

Yngve Nysaeter Pettersen wrote: On Thu, 12 Jun 2008 14:54:32 +0200, Niall O'Reilly [EMAIL PROTECTED] wrote: On 12 Jun 2008, at 12:25, Gervase Markham wrote: The second question is one of resources and client complexity. I am meeting resistance to the idea of having the existing

Re: [DNSOP] Public Suffix List

Gervase Markham wrote: The difference is that the public suffix list is an (attempt at an) expression of fact, not policy. I think is where you are encountering resistance, even though you may not realize it. What you are doing is *publishing* something, which alleges to be a factual list.

Re: [DNSOP] Public Suffix List

, or by some more-centralized box, is an implementation issue (but one that should be given lots of thought!!). But, it is better to trust information already published, which is required for proper operation of DNS, than to look for additional information that may become stale or inconsistent. Brian

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

can do more than guide readers on the high-level issues, and the deeper understanding is the responsibility of the reader, not the authors. Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] short term document roadmap

Peter Koch wrote: 3) draft-ietf-dnsop-respsize-10.txt WGLC to start around mid April ending around 2005-05-05 I have reviewed this draft, and don't see any problems in it. I am in favor of it progressing. Brian Dickson ___ DNSOP mailing list

Re: [DNSOP] short term document roadmap

, WGLC starting early April until 2008-04-18. Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] WGLC: Considerations for the use of DNS Reverse Mapping

have reviewed the draft, and support it moving forward without any further changes. Brian Dickson ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Always registering the IP address of the name servers during a delegation?

[EMAIL PROTECTED] wrote: On Tue, Nov 27, 2007 at 02:05:55PM -0500, Edward Lewis wrote: At 6:25 PM + 11/27/07, [EMAIL PROTECTED] wrote: then we have a small issue... you as zone admin, can't dictate which IP's i must use on my machines, since you don't

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

Brian Dickson wrote: It operates in exactly the same way, as if there were two equal cost routes to two or more routers, each advertising the existence of one of these servers, on the other side of a PPLB router - except that it has the ability to handle the state issue for TCP. Anyone who

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

bill fumerola wrote: not all load balancers work the same. direct server return aka one-arm load balancing does no translation or rewrite of any headers (l3 or l4). all it does is make a switching decision based on health check and other weighting criteria. Just to clarify, for those who

Re: [DNSOP] Re: [secdir] secdir review of draft-ietf-dnsop-reflectors-are-evil-04.txt (fwd)

Dean Anderson wrote: The load balancer is really just a special kind of stateful NAT. No. Load balancers can load balance, without any translation being done at all. And a load balancer is by definition doing *anycast*. The same address is used as a destination, and the packets are

<    1   2   3   4