Re: [DNSOP] I-D Action: draft-ietf-dnsop-nxdomain-cut-01.txt

Hi, On 14/03/16 23:59, Robert Edmonds wrote: > Robert Edmonds wrote: >> 神明達哉 wrote: >>> p.s. in my understanding Unbound adopts hash-based data structure for >>> cached RRsets. If it still supports nxdomain-cut as described in >>> Section 8, an argument against the proposal by referring to that t

Re: [DNSOP] update on draft-jabley-dnssec-trust-anchor

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Joe, I have reviewed the document, and I support it. section 1. s/complimentary/complementary/ section 4.3. Unbound's implementation currently only accepts trust anchors after the validFrom has passed and not during add-hold-down-time before.

Re: [DNSOP] Expiration impending:

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 05/10/15 23:42, Suzanne Woolf wrote: > All, > > First, thanks to the engaging on this. > > On Oct 5, 2015, at 5:20 PM, "Joe Abley" > wrote: >> >> Perhaps it's time to sit back and wait for others here to >> express an opinion. > > I'd li

Re: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Paul, On 18/03/15 09:59, Paul Vixie wrote: >> Stub and recursive resolvers MUST be able to process responses >> that arrive in a different order to that in which the requests >> were sent, regardless of the transport protocol in use. > > this do

Re: [DNSOP] Why no more meta-queries? (Was: More work for DNSOP :-)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Shumon, On 09/03/15 21:17, Shumon Huque wrote: > On Mon, Mar 9, 2015 at 2:55 PM, Shumon Huque > wrote: > > On Mon, Mar 9, 2015 at 2:45 PM, Robert Edmonds > wrote: > > Shumon Huque wrote: >> PS

Re: [DNSOP] DNS, fragmentation, and IPv6 extension headers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi David, On 07/28/2014 04:05 PM, David Conrad wrote: > Hi, > > On Jul 28, 2014, at 5:48 AM, Nicholas Weaver > wrote: >> The IPv6 net has decreed “No, really, FRAGMENTS DO NOT WORK”. > > This could be a bit of an issue when the DNSSEC root key is r

Re: [DNSOP] confidentialdns draft

this encryption is really between a DNS client and the > DNS server it is about to query, it should be the "private key of > that DNS server". But that is not what DNSSEC is about. > > Hence, I think ENCRYPT RR's cannot be protected by DNSSEC. > > Kind regards, &

Re: [DNSOP] confidentialdns draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul, So this is another solution, which I want out there in the solution space because it is stateless. And there are many things to consider ... Sending the qname as the zone name in plaintext is not a good idea. For hop-by-hop encryption there

[DNSOP] confidentialdns draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I also heard that this is the place to discuss DNS privacy. This draft is a protocol, and represents an (interesting) point in the solution space. I would refer to Borzmeyer's draft and Koch's draft for problem space analysis. http://tools.ietf

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 07/03/2013 11:56 PM, Warren Kumari wrote: My question earlier still stands: does Unbound do what HAMMER says (waits for a request before refreshing the cache) or does it just refresh the cache automatically? The Unbound doc

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, It is exactly that option. With some small changes. The draft has a fixed time HAMMER_TIME. Unbound has a hard-coded percentage, 10%, which is not configurable (by choice, no option that hurts). This setting causes an upper bound on the extra

Re: [DNSOP] Data model and field names for DNS in JSON or XML

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Paul, On 01/18/2012 06:35 PM, Paul Vixie wrote: > On 1/18/2012 3:41 PM, Paul Wouters wrote: >> >> The latest unbound supports DNS over (real) HTTPS. >> >> See unbound.conf man page options "ssl-port", "ssl-service-key" and >> "ssl-service-pem". >>

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi George, No comment on section 4.1.4, but wanted to note a mistake in your post. On 05/09/2011 08:22 AM, George Barwood wrote: > I have a comment about section 4.1.4. Rollover for a Single Type Signing Key > rollover. > > The following simple sc

Re: [DNSOP] On resolver priming

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 11/11/2010 07:49 PM, Matt Larson wrote: > On Thu, 11 Nov 2010, Andrew Sullivan wrote: >> argument by just signing the data. > > That's simply the conservative, operationally prudent course of > action. I suspect there is cause to be conservati

Re: [DNSOP] Comments on RFC4641bis

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Rickard, On 11/09/2010 10:40 AM, Rickard Bellgrim wrote: > I also think that it should be possible to send in a DS RR for which > there is no DNSKEY in the child zone. I know that there are > registries that disallow this and others allow this. The

Re: [DNSOP] Fwd: I-D Action:draft-jabley-dnssec-trust-anchor-00.txt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Dnsop, On 10/04/2010 07:46 PM, Joe Abley wrote: > We've talked to DNS vendors and although I don't want to foreshadow > their timelines for making code or strategies available, I can tell > you that there is work underway to accommodate 5011 rollov

Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Thanks for your comments and suggestions, and I'll go and make my (software-vendor-specific-)pick from them. Best regards, Wouter On 09/17/2010 05:31 PM, Paul Hoffman wrote: > No, I am sure we don't want to create a forced cross-dependency on

Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi dnsop, The sentiment over the last week is that retired keys should not be abused, and trust-history is then gone, with such opposition by WG. I do have to renew the root anchor when it changes. Let's look at the 'fetch from iana again' method in

Re: [DNSOP] draft-ietf-dnsop-dnssec-trust-history - discussion

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi dnsop, On 09/10/2010 01:24 PM, Stephen Morris wrote: > Colleagues > > Although draft-ietf-dnsop-dnssec-trust-history (the DNSSEC Trust > Anchor History Service) is a working group item and the editor has > received a number of private comments on

Re: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-history-02.txt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi DnsOP WG, As you saw announced, a new version of the trust history draft. Includes new sections (thanks Andrew Sullivan!) that explain why exactly these old keys, expired signatures, and revoked flags are useful and proper. The algorithm is mostly

Re: [DNSOP] That key size argument...was Re: The case for single active key

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi George, On 06/24/2010 11:59 AM, George Barwood wrote: > It could also note that validators SHOULD NOT check the RRSIG for a DNSKEY > RRset > where all the keys are validated by DS records. This is not possible, and Casey thought similarly, so her

[DNSOP] trust-history-01 text changes

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Changes to trust-history draft that are to be done are listed below. There are no open issues that I am aware of. Section 3. * step 1. change: Otherwise, store the DNSKEY RR set as result to: Otherwise, store the possibly empty DNSKEY RR set as r

Re: [DNSOP] Should root-servers.net be signed

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, Joe, On 03/08/2010 08:35 PM, Tony Finch and Joe Abley alternated: - signing ROOT-SERVERS.NET would result in potentially-harmful large responses with no increase in security >>> >>> Can't you deal with this by omitting the root-serv

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Roy, On 02/22/2010 02:14 PM, Roy Arends wrote: > Nah, we love collisions, it makes it all so more efficient. Besides, > I think the probability of finding a bug in authoritative server > software is way higher than a hash-collision. Yes, I agree t

Re: [DNSOP] I-D Action:draft-ietf-dnsop-dnssec-trust-history-01.txt

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The dnsop wg adopted this draft at the IETF meeting and with discussion on the mailing list afterwards. The draft-ietf-dnsop-dnssec-trust-history-00 is a copy of draft-wijngaards-dnsop-trust-history-02. draft-ietf-dnsop-dnssec-trust-history-01 co

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2010 04:53 AM, Roy Arends wrote: > On Feb 21, 2010, at 7:22 PM, Mark Andrews wrote: > >> NSEC3 >> has a non zero false positive rate due to the fact that the names >> are hashed. > > Are you going on again about the possibility of hash coll

Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2010 05:37 PM, Paul Wouters wrote: 5.3. NSEC3 parameters The NSEC3 hashing includes the FQDN in its uncompressed form. This >>> >>> "over its uncompressed form"? The hash does not 'include' it. >> >> I overlooked this when I

Re: [DNSOP] Trust History draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Florian, On 10/05/2009 08:52 AM, Florian Weimer wrote: > I don't understand this part: > | validator configuration. The validator then fetches old DNSKEY > | RRsets and checks they form a chain to the latest key. > > Doesn't this defeat the purpo

Re: [DNSOP] new version: trust-history-02 draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joe, On 08/30/2009 03:05 AM, Joe Abley wrote: Well, in practice that means someone holding such a software update key. That does not change at all. For 20 years or so? I do not see how this would be more secure. >>> >>> It at least

[DNSOP] Trust history amendments

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Since the trust history draft was accepted at the stockholm IETF75 (is that right, chairs? There was some discussion of looking at which workgroup would fit better?) I want to present some changes to the draft after discussion with the workgroup p

Re: [DNSOP] new version: trust-history-02 draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joe, You remove a part I think is very important: > So the rollover is clearly effective. 99% of people pick up that > new key within the timeframe, and 99.9% after 2 timeframes. > And with trust history, it works for the remaining 0.1% too. > >

Re: [DNSOP] new version: trust-history-02 draft

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Joe, In reply to your email, and the discussion following. On 08/25/2009 03:22 AM, Joe Abley wrote: > I don't remember whether I've expressed my concerns about this work in > e-mail before. I remember talking to people in Stockholm about it. I'm

[DNSOP] new version: trust-history-02 draft

Hi, http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 Is available for review and comment. This represents my take on how to perform trust-anchor management for a validator without having a system update mechanism (which works with unsafe DNS). I have incorporated substantial c

[DNSOP] trust-history draft updated to -01

Hi, http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-wijngaards-dnsop-trust-history-01.txt Spelling of the working group, comments made by the dns expert and fix for algorithm rollover in the history. I am asking for adoption by the working group, but Bill Manning made me aware of the

[DNSOP] Trust History draft

Hi, Just new in the dnsop wg tools page: http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-00 This is the same version as draft-wijngaards-dnsext-trust-history-03, but moved to the DNSOP wg. I would like to request adoption of the document. Why? I want to enable end users to use

Re: [DNSOP] dns data exchanged between host and local dns-sever

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Shane Kerr wrote: > Presumably it would still forward queries to a nearby recursive > resolver, so there would be some shared caching going on? > > Has anybody ever written this down anywhere? (Sorry if I missed it.) It is called a validating stub.

Re: [DNSOP] More solicitation for feedback on dns64

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Sullivan wrote: > So AD doesn't mean "I validated this", but rather "I know this is > valid". The translating validator _can_ know it's valid: it validated > the "base" A record, and then performed a translation using the data > it also has by