[DNSOP] Re: Compact Denial of Existence with NSEC3?

[Olafur Gudmundsson]

> On Dec 26, 2024, at 14:05, John Levine  wrote:
> 
> It's fine, but two niggles:
> 
> It appears that Shumon Huque   said:
>>  specific benefit for online signing implementations.  Hence, there
>>  does not appear to be a strong advantage to implementing Compact
>>  Denial of Existence with NSEC3.  An existing implementation of
> 
> I'd say it more clearly
> 
>  Hence, there is no advantage to NSEC3 over NSEC when using Compact Denial of 
> Existence.
> 
> Someone is going to ask what about opt-out. I think the answer is that when
> doing online signing it's easier to sign everything than try and find the
> names whose hashes precede and follow the name you don't want to sign.

I would say online signing is way superior operating practice than off-line 
signing, 
there is no need for NSEC3 in on-line signing operations!
The old mentality of DNS operators that remote servers can not trusted to 
modify 
content of zones is out-dated to say the least, if that is the case then the 
suspect servers should not be used. 

DNS community has tried to hard to overcome operational issues with technical 
solutions when commercial
agreements are more appropriate. 

Olafur

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP] Re: [Ext] New draft on collision free key tags in DNSSEC

[Olafur Gudmundsson]

> On Jul 26, 2024, at 20:02, Paul Wouters  wrote:
> 
> 
> 
>> On Jul 26, 2024, at 16:08, Mark Andrews  wrote:
>> 
>> 
>> Even if we where to go with one failure is allowed we still need to
>> write down the new rules and there will be complaints that we are
>> retrospectively changing the rules.  This is grand fathering in the
>> old rules for the old algorithms.
> 
> Write a BCP, not a standard disallowing key id clashes.
> 
> Paul
> 
> ___
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org

+1 to that 
Most of the problems that resolvers have, are direct result of “bad practices” 
by zone publishers, stop putting more rules on resolvers and give them “fig 
leafs” to reject early. 
 
In this case the only real solution at protocol level is to say “Zone with 
alg+keyTag collision SHOULD/MUST be treated as BOGUS. 

Grumpy 
 
___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

[DNSOP]Re: [IANA #1365805] expert review for draft-ietf-dnsop-zoneversion (dns-parameters)

[Olafur Gudmundsson]

I have reviewed the proposed ENDS0 registration:  it is excellent, and can 
proceed without any comment
The registration requires a new registry for future changes, the included 
description of the registry and how to process applications for that is as 
complete as possible.

Overall the editors of this document did a great job 

Olafur

> On Jun 5, 2024, at 12:35 PM, David Dong via RT 
>  wrote:
> 
> Dear Olafur Gudmundsson (cc: dnsop WG),
> 
> As the designated expert for the DNS EDNS0 Option Codes (OPT) registry, can 
> you review the proposed registration in draft-ietf-dnsop-zoneversion-06 for 
> us? Please see
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-zoneversion/
> 
> The due date is June 19th.
> 
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
> 
> https://www.iana.org/assignments/dns-parameters/
> 
> With thanks,
> 
> David Dong
> IANA Services Sr. Specialist

___
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Re: [DNSOP] [IANA #1285115] expert review for draft-ietf-dnsop-dns-error-reporting (DNS EDNS0 Option Codes (OPT))

[Olafur Gudmundsson]

This specification is complete and clear 
Status: Approved 

 Ólafur

> On Oct 24, 2023, at 3:36 PM, David Dong via RT 
>  wrote:
> 
> Dear Olafur Gudmundsson (cc: dnsop WG),
> 
> As the designated expert for the DNS EDNS0 Option Codes (OPT) registry, can 
> you review the proposed registration in 
> draft-ietf-dnsop-dns-error-reporting-06 for us? Please see:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting/
> 
> The due date is November 7th.
> 
> If this is OK, when the IESG approves the document for publication, we'll 
> make the registration at:
> 
> https://www.iana.org/assignments/dns-parameters/
> 
> With thanks,
> 
> David Dong
> IANA Services Sr. Specialist

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] nsec3-parameters opinions gathered

[Olafur Gudmundsson]

Publishing iteration count higher than 10 is reckless as that affects the 
performance of recursive resolvers in particular the ones that run on small CPE 
equipment.

The document should strongly discourage any use of NSEC3  
For the  that want to keep using it the limit should be real low of 
what resolvers accept. 
Any value between 0 and 10 is fine with me 

Olafur


> On Nov 5, 2021, at 12:09 PM, Benno Overeinder  wrote:
> 
> Wes,
> 
> On 05/11/2021 09:40, Vladimír Čunát wrote:
>> On 04/11/2021 23.44, Wes Hardaker wrote:
>>> The most important sticking point is there are 4 implementations (thank
>>> you for the links Matthijs) that have implemented 150.  Since DNSOP
>>> strives for implementations of specs, I think this is the number we
>>> should publish*unless the vendors speak up and say they'll drive lower*.
>> I'm convinced that 150 was just a quick stop-gap compromise and that from 
>> the start vendors expected that dnsop might set it lower later. Therefore I 
>> don't think this *argument* for keeping 150 is really valid.
>> As for Knot Resolver, I see no problem in setting the hard limit lower, 
>> especially if that gets published in this RFC.  From Viktor I gather that 
>> 100 shouldn't cause issues even at this moment, especially if it's only a 
>> limit for downgrading to insecure (which won't be even noticed by most DNS 
>> consumers).  So personally I expected the draft to lower the bound to <=100, 
>> though as I said... for us the *overall* performance ratio from e.g. 150 -> 
>> 50 isn't that large.
> 
> For Unbound, we have no problem setting the iteration cap to a value lower 
> than the current 150.  If Viktor's analysis shows a limit of 100 is feasible 
> without (m)any problems for operators, and this value will be adopted in the 
> soon-to-be-released RFC, we will use the new limit value.
> 
> 
> Cheers,
> 
> -- Benno
> 
> 
> -- 
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for Revised IANA Considerations for DNSSEC

[Olafur Gudmundsson]

> On Aug 4, 2021, at 11:29 AM, Tim Wicinski  wrote:
> 
> 
> All
> 
> This starts a Working Group Last Call for draft-ietf-dnsop-dnssec-iana-cons
> 
> Current versions of the draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-iana-cons/ 
> 
> 
> The Current Intended Status of this document is: Standards Track
> 
> Please review the draft and offer relevant comments.
> If this does not seem appropriate please speak out. 
> If someone feels the document is *not* ready for publication, please speak 
> out with your reasons.
> 
> This starts a two week Working Group Last Call process, and ends on:  18 
> August 2021
> 
> thanks
> tim


Hi Tim, 

I read the draft and I oppose it on principle, it is a bad idea. 
 
IMHO the ONLY benefit of it is to encourage DS record overloading with random 
data that has no DNSSEC relevance,  leading to abuse that threatens to turn the 
DS record into the new TXT overloading record resulting in large DS sets. 

The DS record is a unique record that it lives only at the parent side of 
delegation, when DNS was defined no such records were envisioned, if more are 
needed this working should take up a new work item to 
define a sub-set of the RRtype number space as Parent side-only to have a 
proper debate on the topic. 

Further more this draft  makes it trivial for vanity algorithms to be added to 
the DS and DNSKEY registries threatening the depletion of the small number 
space. 
There is a big difference between registration and deployment, only algorithms 
that the IETF thinks have a benefit to the whole community and have a 
expectation of wide deployment should be registered. 
Those of us who have fought the battles to get new algorithms rolled out and 
supported by large fraction of the internet can attest that increasing the 
number of supported algorithms is a no-win battle as it may lead to fragmented 
validation on the internet, forcing zones to sign with multiple algorithms ==> 
increasing packet size for no good reason. 

Getting DS records into parents at TLD level is hard, CDS/CDNSKEY are supposed 
to make that easier but uptake has been slow due resistance by industry and any 
overloading of the DS record may derail it. 

Olafur



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-hardaker-dnsop-nsec3-guidance

[Olafur Gudmundsson]

I guess I support the document but would like it to say 
“Please do not use NSEC3 but if you have to use NSEC3 use it use these settings”

The document should point how trivial it is to expose most names in NSEC3 
signed zone using Graphics cards and dictionaries. 

Olafur



> On May 10, 2021, at 1:20 PM, Tony Finch  wrote:
> 
> Benno Overeinder  wrote:
>> 
>> https://datatracker.ietf.org/doc/draft-hardaker-dnsop-nsec3-guidance/.
> 
> Yes, this is a helpful document that should be adopted by dnsop. I'm happy
> to review etc.
> 
> Tony.
> -- 
> f.anthony.n.finchhttps://dotat.at/
> Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally
> moderate in east, becoming very rough in west. Thundery showers. Good,
> occasionally poor.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-hoffman-dnssec-iana-cons

[Olafur Gudmundsson]

> On Dec 25, 2020, at 3:27 PM, Paul Hoffman  wrote:
> 
> On Dec 24, 2020, at 10:28 AM, Daniel Migault  > wrote:
>> 
>> Hi, 
>> 
>> As the DNS is a global shared resource and its reliability is based on 
>> **all** pieces of software adhering a common standard, I am inclined to 
>> believe that new cryptographic algorithms introduced with anything less 
>> restrictive than "IETF Review" - such as "Specification Required" and "RFC 
>> Required" - does not sufficiently prevent altering the interoperability of 
>> the DNS.  
> 
> Why do you feel that DNSSEC has requirements stronger than other IETF 
> security prot0cols such as TLS, IPsec, S/MIME, and so on? 

DNS is a fire-and-forget protocol, all the ones you mention include a handshake 
that can be used to agree on algorithms. Such facility does not exist in DNS. 

I oppose any relaxation of thresholds to add algorithms to DNSSEC, as there is 
no need. 

  Ólafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Olafur Gudmundsson]

> On Jun 18, 2020, at 11:30 AM, Paul Hoffman  wrote:
> 
> On Jun 18, 2020, at 7:59 AM, Dmitry Belyavsky  wrote:
>> The 2nd registry
>> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
>> (https://www.iana.org/assignments/ds-rr-types/ds-rr-types.xhtml#ds-rr-types-1
>>  
>> )
>> has the "Standards Action" update policy
> 
> I had forgotten that the DS registry is "standards action". This document 
> shows why that was a bad idea.

Why ? 

> 
> It might be better, and faster, for this WG to adopt a one-paragraph draft 
> that makes the DS registry "RFC required", like the other DNSSEC-related 
> registries.
You are proposing a bureaucratic solution without thinking about the 
operational implications of it. 
The hardest part to update in DNS tree right now is uploading DS records to the 
parents, keeping the list of algorithms down helps avoid operational problems 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-belyavskiy-rfc5933-bis

[Olafur Gudmundsson]

Thom 
As I have before stated in the past, adding new DNSSEC algorithm is bad for 
interoperability, 
I oppose the adoption of this document unless there are better reasons put 
forward why this algorithm is better than
the 4 ECC algorithms that have been standardized so far. 
Better in this case could be stronger, faster, better post-quantum resistance 
etc 

Also I want to point out this last call did not specify track so my opposition 
is against all tracks, at this point. 

Olafur




> On Jun 3, 2020, at 5:07 PM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.  
> We are looking for *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-belyavskiy-rfc5933-bis
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-belyavskiy-rfc5933-bis/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 15 June 2020
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Olafur Gudmundsson]

> On May 12, 2020, at 9:43 PM, Tim Wicinski  wrote:
> 
> Olafur
> 
> Currently it's marked Standards Track, but I was working on the idea that the 
> working group would make 
> that decision as the document works toward Working Group Last Call.  
> 
Tim 

Thanks for the clarification, 

> I was reserving judgement until there was implementations, interoperability, 
> etc. 
> 
Fair point 

> Please feel free to register any thoughts on publication status at this time 
> as well.
> 
> Hope that helps
> 

This draft is a result of a failure by the DNS community to create any kind of 
framework to manage distributed name server clusters. 
The draft is a “hack” of the best kind it is low impact but does the work for a 
sub-set of usage cases that a real control plane should have. 

I think making this document a standard would be a mistake.  
I think NOT publishing this document at all would be a  BAD thing. 

I support adoption and will review and continue to agrue against standards 
track. 

> tim
> 

Olafur

> 
> On Tue, May 12, 2020 at 9:35 PM Olafur Gudmundsson  <mailto:o...@ogud.com>> wrote:
> 
> 
>> On May 11, 2020, at 1:41 PM, Tim Wicinski > <mailto:tjw.i...@gmail.com>> wrote:
>> 
>> 
>> All,
>> 
>> As we stated in the meeting and in our chairs actions, we're going to run
>> regular call for adoptions over next few months.  
>> We are looking for *explicit* support for adoption.
>> 
>> 
>> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
>> 
>> The draft is available here: 
>> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ 
>> <https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/>
>> 
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.
>> 
>> Please also indicate if you are willing to contribute text, review, etc.
>> 
>> This call for adoption ends: 25 May 2020
>> 
> 
> Tim, 
> a nit question: 
> what is the intended publication status ? 
> Experimental, Informational, Standard  
> 
> Thanks 
> Olafur
> 
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
>> 
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org <mailto:DNSOP@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnsop 
>> <https://www.ietf.org/mailman/listinfo/dnsop>
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-toorop-dnsop-dns-catalog-zones

[Olafur Gudmundsson]

> On May 11, 2020, at 1:41 PM, Tim Wicinski  wrote:
> 
> 
> All,
> 
> As we stated in the meeting and in our chairs actions, we're going to run
> regular call for adoptions over next few months.  
> We are looking for *explicit* support for adoption.
> 
> 
> This starts a Call for Adoption for draft-toorop-dnsop-dns-catalog-zones
> 
> The draft is available here: 
> https://datatracker.ietf.org/doc/draft-toorop-dnsop-dns-catalog-zones/ 
> 
> 
> Please review this draft to see if you think it is suitable for adoption
> by DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> This call for adoption ends: 25 May 2020
> 

Tim, 
a nit question: 
what is the intended publication status ? 
Experimental, Informational, Standard  

Thanks 
Olafur

> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis

[Olafur Gudmundsson]

Hi Scott, some nits below 
> On Jul 8, 2019, at 3:00 PM, Hollenbeck, Scott 
>  wrote:
> 
> I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to 
> propose some additional text for the Security Considerations section in the 
> spirit of this sentence from the abstract:
> 
> "Future versions of this draft will contain descriptions of different 
> minimisation implementation choices that have been made since the RFC 7816 
> first came out, as well as deployment experience."
> 
> QNAME minimization has the consequence of reduction in the amount of 
> information seen by authoritative name server operators. Active consideration 
> of that consequence is worth capturing as a factor to be weighed when making 
> the choice to implement QNAME minimization, especially if there are other 
> ways to gain privacy protection. Here's suggested text:
> 
> In addition to the performance considerations described in Section 4, there's 
> also a security risk associated with the reduction of  data sent to 
> authoritative name servers: they lose some of their ability to assess

“data sent to authoritative name servers” 
The zone authoritative name servers get the same query with and without Query 
Minimization (QM) 
I think you want to say “parental name servers” i.e. servers for zones above 
the zone.

> security threats [Kaliski-Minimum].  This ability  has proven to be useful 
> in, for example, studies of name collision vulnerabilities 
> [MitM-Attack-Name-Collisions]  [Client-Side-Name-Collision].  It was also 
> instrumental in the research that led to the discovery of the JASBUG 
> vulnerability  [ICS-ALERT-15-041-01]. The reduction will also have an impact 
> on the level of detail available for research studies such as DNS-OARC's 
> annual Day in the Life of the Internet (DITL) data collection exercise [DITL].


Your arguments about visibility to researchers are true but not exclusive i.e. 
the same information can be derived from recursive resolvers, and from the pool 
of queries that still arrive without QMr. 
As for using the DITL as argument against query-minimization I think there 
should be some arguments that DITL collection serves a useful purpose. 

> 
> For this reason, implementers should also consider the potential impact on 
> threat analysis and research when reducing the level of detail included in 
> queries to authoritative name servers. Without such consideration, a 
> collection of individual decisions to reduce query information, over time, 
> may well have the unintended consequence of "deciding" to no longer support 
> threat analysis and research that the operational DNS community has 
> historically relied on.  Alternative mechanisms for facilitating threat 
> analysis and research are beyond the scope of this document.

again object to the word “authoritative” 
I think this statement is not needed, it assumes that such research can only be 
done by operators of parental domains. 
What QM does is to disrupt operating models and data collection by 
intermediaries ==> that was an explicit goal 
The target of your advise is not JUST implementers of software but operators of 
resolvers as most resolver implementations provide a configuration option to 
select QM 

Olafur


> 
> [Client-Side-Name-Collision] Qi Alfred Chen, Matthew Thomas, Eric Osterweil, 
> Yulong Cao, Jie You, and Z. Morley Mao.  "Client-side Name Collision 
> Vulnerability in the New gTLD Era: A Systematic Study".  In ACM Conference on 
> Computer and Communications Security (CCS '17), pp. 941-956.  ACM, November 
> 2017.
> 
> 
> [DITL]  CAIDA, "A Day in the Life of the Internet (DITL)", 
> 
> 
> [ICS-ALERT-15-041-01] NCCIC/ICS-CERT, "Microsoft Security Bulletin MS15-011 
> JASBUG", February 10, 2015, revised August 23, 2018.
> 
> 
> [Kaliski-Minimum] Kaliski, B., "Minimum Disclosure: What Information Does a 
> Name Server Need to Do Its Job?", March 2015, 
> 
> 
> [MitM-Attack-Name-Collisions] Qi Alfred Chen, Eric Osterweil, Matthew Thomas, 
> and Z. Morley Mao.  "MitM Attack by Name Collision: Cause Analysis and 
> Vulnerability Assessment in the New gTLD Era".  In 37th IEEE Symposium on 
> Security and Privacy (S&P '16), pp. 675-690.  IEEE, May 2016.
> 
> 
> Scott
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Olafur Gudmundsson]

> On Jul 8, 2018, at 9:35 PM, Mark Andrews  wrote:
> 
> So what if it is not feasible for COM and similarly sized zones?
> 
> At the moment we have one zone where we need a zone signature so that the 
> zone contents can be loaded into every recursive server.
> 
> The question we should be asking is "Is SIG(AXFR) a good fit for the root 
> zone?” not whether is is a good mechanism for all zones because quite frankly 
> there are very few zones that you would want loaded into all recursive 
> servers.
> 
> “.”, “arpa”, “in-addr.arpa” and “ip6.arpa” would be about it.  Does anyone 
> else have any others?  Any zone would necessarily be small. 
> 
> Mark

So the followup question is 
Should we burden the Auth Server implementations with this calculation if the 
usage case if 4 zones ? 
or is this better handled by external tools ?
DNS Camel says ? 

Olafur

>> On 9 Jul 2018, at 10:28 am, Olafur Gudmundsson  wrote:
>> 
>> 
>> 
>>> On Jun 22, 2018, at 6:58 AM, Petr Špaček  wrote:
>>> 
>>> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>>>> On 22:09 21/06, Shane Kerr wrote:
>>>>>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>>>>>> 
>>>>>> Hmm, can you share some details about your experience?
>>>>>> Did you find out when the data corruption took place?
>>>>>> a) network transfer
>>>>>> b) implementation bugs (e.g. incorrectly received IXFR)
>>>>>> c) on disk
>>>>>> d) some other option?
>>>>> 
>>>>> I don't know. I have seen incorrectly transferred zone files both in
>>>>> BIND
>>>>> and NSD slaves. IIRC our solution was to include sentinel records in
>>>>> the
>>>>> zone files to spot problems, take the node out of service, and force a
>>>>> re-transfer. This of course won't work if you are slaving zones that
>>>>> you do
>>>>> not control, and it doesn't prevent a small window of time when the
>>>>> servers
>>>>> are operating with broken zones. TSIG was being used.
>>>> 
>>>> We have also seen broken transfers between secondaries. Our solution
>>>> is to dump the zone after transfer, calculate a hash and compare. We
>>>> would benefit from having a ZONEMD record inside the zone.
>>> 
>>> If the zone got broken during TSIG-secured transfer then it was not most
>>> probably not caused by network problem because TSIG would have caught that.
>>> 
>>> Honestly I do not think it is worth the effort because all the
>>> complexity does not help to prevent implementation bugs, I would say it
>>> even increases probability of a bug!
>>> 
>>> What is left is bug on auth and/or slave sides and in that case there is
>>> no guarantee that
>>> a) master did not compute ZONEMD from already broken data
>>> b) slave verification of ZONEMD actually works
>>> 
>>> 
>>> If we wanted to catch problems with implementation we need something
>>> which is outside of the DNS stack we are attempting to check, be is
>>> simple checksum or some fancier crypto.
>>> 
>>> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
>>> node and an utility which would extract OPENPGPKEY RR from the zone file
>>> and verify that the zone file signature (either detached or in .gpg
>>> file) can be verified using that key (+ add DNSSEC into the mix if you
>>> wish).
>>> 
>>> -- 
>>> Petr Špaček  @  CZ.NIC
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> 
>> 
>> +1 
>> I spent lots of time earlier this century along with Johan Ihren trying to 
>> figure out how to 
>> secure the transfer of a particular zone (the root) to any resolver. 
>> The only sane way is to not transfer the zone over AXFR as any intermediary 
>> can mess with the zone contents mostly in the case of “glue” records,
>> thus transferring the zone over HTTPS or RSYNC with a PGP signature over the 
>> zone file is the only viable solution going forward. 
>> 
>> 
>> Historical background: SIG(AXFR) was rejected because it required putting 
>> the zone into canonical order and calculating the signature, 
>> in the case of dynamic update this is a real expensive operation, thus we 
>> got rid of it. 
>> 
>> Olafur
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Olafur Gudmundsson]

George, 

The reason I should have stated before is 
if the zone fails the check we should not tell the server to load it 

There are roughly 3 kinds of zones in based on update frequency 
— almost Never 
— On schedule 
— All the time 

Calculating the zone “digest” is only feasible in the third case when the zone 
is small 
i.e. imagine calculating the updated zone digest for .org (not to mention .com) 
every time there is an update to the zone. 
SO  if the problem statement that it only applies to the first two then you may 
have a case for a zone digest. 
For the record root zone falls into the second category and my private zone 
falls into the first one.

Olafur
PS: Also for the record I think AXFR is a horrible protocol hack. 
PPS: I almost agree with Prof Bernstein that rsync  is a better solution, from 
an interoperability perspective. 



> On Jul 8, 2018, at 9:02 PM, George Michaelson  wrote:
> 
> So if I look at what you said, what I see is "inband, canonicalization
> is a cost we don't want to bear, to produce a signed product of whole
> of zone" and "if we accept knowledge of a PGP or other external key as
> the moment of trust, out of band, disordered but specifically testable
> as *this file* is signed by *known key* is workable.
> 
> wow. Firstly, I thought canonicalization was a given: we have
> definitions of canonical zone order for other reasons (NSEC*) don't
> we?
> 
> secondly, I absolutely (and no sarcasm implied or intended, I really
> mean it) applaud the pragmatism. If we can move to a world which
> accepts the root is a resource which can routinely be fetched out of
> band, validated out of band, and then locally bound to a DNS server,
> we've probably moved on.
> 
> in-band is great. but, sometimes, its really hard.
> 
> So how about use of a PGP key which is a payload in TXT signed over by
> the ZSK/KSK so the trust paths bind together?
> 
> fetch one DNS record +sigs, check against the TA (which has to be a
> given) and then..
> 
> -G
> 
> On Mon, Jul 9, 2018 at 10:28 AM, Olafur Gudmundsson  wrote:
>> 
>> 
>> On Jun 22, 2018, at 6:58 AM, Petr Špaček  wrote:
>> 
>> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>> 
>> On 22:09 21/06, Shane Kerr wrote:
>> 
>> Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
>> 
>> Hmm, can you share some details about your experience?
>> Did you find out when the data corruption took place?
>> a) network transfer
>> b) implementation bugs (e.g. incorrectly received IXFR)
>> c) on disk
>> d) some other option?
>> 
>> 
>> I don't know. I have seen incorrectly transferred zone files both in
>> BIND
>> and NSD slaves. IIRC our solution was to include sentinel records in
>> the
>> zone files to spot problems, take the node out of service, and force a
>> re-transfer. This of course won't work if you are slaving zones that
>> you do
>> not control, and it doesn't prevent a small window of time when the
>> servers
>> are operating with broken zones. TSIG was being used.
>> 
>> 
>> We have also seen broken transfers between secondaries. Our solution
>> is to dump the zone after transfer, calculate a hash and compare. We
>> would benefit from having a ZONEMD record inside the zone.
>> 
>> 
>> If the zone got broken during TSIG-secured transfer then it was not most
>> probably not caused by network problem because TSIG would have caught that.
>> 
>> Honestly I do not think it is worth the effort because all the
>> complexity does not help to prevent implementation bugs, I would say it
>> even increases probability of a bug!
>> 
>> What is left is bug on auth and/or slave sides and in that case there is
>> no guarantee that
>> a) master did not compute ZONEMD from already broken data
>> b) slave verification of ZONEMD actually works
>> 
>> 
>> If we wanted to catch problems with implementation we need something
>> which is outside of the DNS stack we are attempting to check, be is
>> simple checksum or some fancier crypto.
>> 
>> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
>> node and an utility which would extract OPENPGPKEY RR from the zone file
>> and verify that the zone file signature (either detached or in .gpg
>> file) can be verified using that key (+ add DNSSEC into the mix if you
>> wish).
>> 
>> --
>> Petr Špaček  @  CZ.NIC
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> 
>> 
>> 
>

Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

[Olafur Gudmundsson]

> On Jun 22, 2018, at 6:58 AM, Petr Špaček  wrote:
> 
> On 21.6.2018 22:31, Hugo Salgado-Hernández wrote:
>> On 22:09 21/06, Shane Kerr wrote:
 Dne 1.6.2018 v 12:51 Shane Kerr napsal(a):
 
 Hmm, can you share some details about your experience?
 Did you find out when the data corruption took place?
 a) network transfer
 b) implementation bugs (e.g. incorrectly received IXFR)
 c) on disk
 d) some other option?
>>> 
>>> I don't know. I have seen incorrectly transferred zone files both in
>>> BIND
>>> and NSD slaves. IIRC our solution was to include sentinel records in
>>> the
>>> zone files to spot problems, take the node out of service, and force a
>>> re-transfer. This of course won't work if you are slaving zones that
>>> you do
>>> not control, and it doesn't prevent a small window of time when the
>>> servers
>>> are operating with broken zones. TSIG was being used.
>> 
>> We have also seen broken transfers between secondaries. Our solution
>> is to dump the zone after transfer, calculate a hash and compare. We
>> would benefit from having a ZONEMD record inside the zone.
> 
> If the zone got broken during TSIG-secured transfer then it was not most
> probably not caused by network problem because TSIG would have caught that.
> 
> Honestly I do not think it is worth the effort because all the
> complexity does not help to prevent implementation bugs, I would say it
> even increases probability of a bug!
> 
> What is left is bug on auth and/or slave sides and in that case there is
> no guarantee that
> a) master did not compute ZONEMD from already broken data
> b) slave verification of ZONEMD actually works
> 
> 
> If we wanted to catch problems with implementation we need something
> which is outside of the DNS stack we are attempting to check, be is
> simple checksum or some fancier crypto.
> 
> I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
> node and an utility which would extract OPENPGPKEY RR from the zone file
> and verify that the zone file signature (either detached or in .gpg
> file) can be verified using that key (+ add DNSSEC into the mix if you
> wish).
> 
> -- 
> Petr Špaček  @  CZ.NIC
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 


+1 
I spent lots of time earlier this century along with Johan Ihren trying to 
figure out how to 
secure the transfer of a particular zone (the root) to any resolver. 
The only sane way is to not transfer the zone over AXFR as any intermediary can 
mess with the zone contents mostly in the case of “glue” records,
thus transferring the zone over HTTPS or RSYNC with a PGP signature over the 
zone file is the only viable solution going forward. 
 

Historical background: SIG(AXFR) was rejected because it required putting the 
zone into canonical order and calculating the signature, 
in the case of dynamic update this is a real expensive operation, thus we got 
rid of it. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS Camel Viewer

[Olafur Gudmundsson]

> On Mar 26, 2018, at 4:15 AM, Matthijs Mekking  wrote:
> 
> Nice viewer :)
> 
> What immediately catches my eye is that the DNSSEC RFCs 4033-4034-4035 are a 
> Proposed Standard, and RFC 5011 is an Internet Standard. In fact, RFC 5011 is 
> the only DNSSEC Internet Standard. That can't be right, right? :)
> 
> Matthijs
> 
> 

Matthijs, 

It is real sad that this is correct.
Over the many years chairing DNSIND/DNSEXT working group I can tell you the 
most difficult hurdle was to get anyone help push a document up the standards 
track. 
For some reason people can find time to read and write 100+ messages on naming 
of KeyID but spending the same time to advance a document is hard
and then someone  comes out and wants to make changes to text ….. 
overall result Mike StJohns is the only person that had the stamina and think 
skin to succeed 

Olafur

> 
> On 24-03-18 17:51, bert hubert wrote:
>> Hi everyone,
>> [tl;dr, check out https://powerdns.org/dns-camel/ ]
>> As a first step in attempting to not only whine about a glut of DNS
>> standards, I've made an easy to update viewer of all DNS relevant standards.
>> The good news is, if we filter out obsoleted, historical, informational and
>> BCP documents, we are left with a lot less pages. The bad news is, 1403
>> pages remain.
>> I took the set of RFCs from https://www.isc.org/community/rfcs/dns/ and
>> augmented this with the recent RFCs published by DNSOP and DPRIVE.
>> The page is on https://powerdns.org/dns-camel/ - it is a bit slow to load
>> because it sources the 12MB IETF XML file describing all RFCs. It should do
>> this only once and then be fast.
>> The goal is to augment this view with all drafts that are currently active,
>> so we can also see "what is coming".
>> If you know of RFCs that should or should not be on the list, please edit
>> dns-rfcs.js on https://github.com/ahupowerdns/dns-camel/
>> It is my hope that this view will be helpful in determining:
>> 1) What to obsolete
>> 2) The "must read" list for:
>>  a) stub resolvers
>>  b) dns caches / resolvers
>>  c) authoritative servers
>> 3) The "must not read" list - documents not worth it to obsolete, but
>> considered confusing or misguided
>> 4) Perhaps take a good look at the drafts we are currently working on
>>  Bert
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Multi Provider DNSSEC Models

[Olafur Gudmundsson]

> On Mar 21, 2018, at 8:35 AM, Shumon Huque  wrote:
> 
> On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch  > wrote:
> 
> On 20 Mar 2018, at 11:50, Shumon Huque  > wrote:
> 
>> We've posted a new draft on Multi Provider DNSSEC models,
>> which we're planning to discuss at Thursday's DNSOP session.
>> 
>> https://tools.ietf.org/html/draft-huque-dnsop-multi-provider-dnssec-02 
>> 
> I have read through it, and it looks pretty good, though I think you are 
> burying the lede.
> 
> The first time I looked through I missed the clever parts, and thought to 
> myself that half of the models described in section 2 would make people very 
> sad. But section 4 on resolver behaviour explains the cleverness that avoids 
> making people sad (sharing public keys), so I looked through the model 
> descriptions more carefully and saw that they do in fact mention the trick.
> 
> Thanks for the review.
>  
> To fix this misunderstanding, the introductory paragraphs in section 2.2 need 
> to explain your cleverness a lot more explicitly. eg this sentence: 
> 
> A key requirement here is to manage the contents of the DNSKEY and DS RRset 
> in such a way that validating resolvers always have a viable path to 
> authenticate the DNSSEC signature chain no matter which provider they query 
> and obtain responses from.
> 
> Yeah, validation has to work, I know, now tell me the clever trick up front 
> otherwise I might not realise there is one!
> 
> Ok, the missing part of the up-front description is that each provider has to 
> import the zone signing (public) keys of the other provider(s) into its 
> DNSKEY RRset. I can add this and elaborate some more.
> 
> By the way, I would not characterize this as a "trick", but rather a fairly 
> obvious key provisioning step that is needed to make the multi-provider 
> signing configuration work.
> 
> But I agree that this might not obvious to everyone if they haven't thought 
> through the details. Actually, I added the resolver behavior section, after I 
> needed to explain more clearly how this worked to a colleague.
> 
> Shumon.


I read the document and it is quite good 
I think only Model #1 makes sense, i.e Zone apex  DNSKEY/CDNSKEY/CDS  RRset's 
are signed by zone publisher but rest signed by operator on the fly. 

The document covers the case that different providers use different signing 
algorithms BUT does not cover if they use different negative answer approaches, 
no good answer other than say NSEC with “lies”. 

 Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dnssec-sha3-01

[Olafur Gudmundsson]

> On Apr 10, 2017, at 11:09 AM, Mukund Sivaraman  wrote:
>> 
> 
> We kind of restarted the draft adopting RSASSA-PSS, so please can you
> review it this time from scratch without looking at the diff?
> 
> Many of the examples will need updating once algorithm numbers are
> assigned for them (as for some calculations, the algorithm number is an
> input), so we didn't spend time on wrapping the long lines in this
> revision.
> 

Ok I will bite and be the grumpy old man. 

I strongly advocate against the adoption of this document in current from. 
It violates basic interoperability guidelines by defining way to many 
algorithms with no justification why any of them are better or worse than 
others. 
There is no useful guidance on why these new algorithms are better even among 
themselves. 

One of the biggest hurdles to deployment is not in the 5-20 DNS software 
packages in wide use; but in all the 1000’s of Provision systems around the 
world,
and the crypto libraries found on various Enterprise systems that have life 
time of 4-8 years with security-only updates. 
Lets learn the lessons documented in 
https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-04 


I’m not convinced that SHA3 vs SHA2 matter at all given the constraint small 
data with strict constraints on order and contents is being signed. 

Thus why define 
-  5 new  RSA algorithms proposed, why why ? ? 
-  2 new ECDSA algorithms proposed why why ? ?
In another document there 2 other algorithms being proposed at the same time, 
that I support as they represent new and
faster technology.
All this will do is to cause confusion!

The RSA KEY size allowed for these new supposed stronger Digest algorithms is 
still left at 1024 or 1280 bytes, even though number of other parts of the the 
Internet community will not consider signatures by keys with less than 2048 
bits. 

If there is any reason to go down the path of this document it should pick ONE 
RSA and ONE ECDSA algorithm.
RSA should be defined sensible guidelines on key sizes;  i.e. no keys below 
some stronger value in the 1536-2048 byte range.

The document is proposing two new DS algorithms WHY?
The basic reason for new a  DIS digest algorithm is “much better” so pick one 
and live with it. 

There was an interesting discussion on a resolver software mailing list few 
weeks back about what the RFC’s mean when there are DS records with different 
digest 
algorithm numbers: A domain had 2 DS records one with digest 1 one with digest 
2; 
They both referred to the same key, but there was a typo/error in the digest 
with algorithm 2; 
Question what should the validator do ? 
a) only trust the highest digest number? 
b) trust any DS record ? 
I.e. a higher number was interpreted by the implementor to mean better thus 
only the highest supported number was the only one tried. 

Additionally this document in its current form contains proposed algorithm 
values which IMHO is a NoNo and I hope is removed from future versions. 
If there are interoperability tests you can define the numbers you want to use 
on web page; not in an internet draft that someone may go ahead and
implement not realizing that the final RFC will have a different number(s). 

Olafur




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-tale-dnsop-edns-clientid

[Olafur Gudmundsson]

> On Mar 27, 2017, at 5:49 PM, Dave Lawrence  wrote:
> 
> One of the two drafts I wanted to talk about at dnsop today for WG
> adoption was "Client ID in Forwarded DNS Queries":
> https://datatracker.ietf.org/doc/draft-tale-dnsop-edns0-clientid/
> 
> The core idea of this document is to be able to provide
> device-specific identification in an EDNS option sent to a
> full-service resolver, with the principal motivation to be for
> filtering products.  It uses an IANA Address Family value to indicate
> the format of the identifier that is being sent.  One of the design
> goals was to avoid creating any new registries.
> 
> This document treads on controversial grounds because of the obvious
> privacy implications.  It must be noted that both Nominum and Cisco
> are already doing this via EDNS options, and so the general idea
> confronts some similar issues we've encountered before about whether
> to document in-use protocols or let them just continue on with little
> to no public documentation.
> 
> As Sara commented on Ray's draft that proposes a very similar option,
> draft-bellis-dnsop-xpf, this sort of thing clearly needs a close look
> at privacy, and I whole-heartedly agree.  I've already been directly
> poking privacy-concerned individuals for feedback.
> 
> Speaking of Ray's draft, our proposal is able to handle his use case
> but unfortunately our use cases are not achievable in his.  I'd
> welcome joining up.
> 
> The one other thing I wanted to mention in the WG is that I tried to
> get an EDNS code point assigned through the "Expert Review" process,
> which it turns out is very poorly documented for either process or
> review criteria.  The Expert Reviewer, Olafur Gudmundsson, has
> initially denied the request pending feedback from the WG.  I'll leave
> it to him to state what gave him pause, and to request the feedback he
> seeks.

Strictly speaking the draft was never formally submitted via IANA. 
Rather I was giving David advise on how I would rule if he submitted the draft. 

As expert I do not have any formal guidelines to tell me how to judge 
options. My rule after implementing ClientSubnet is “never again” allow complex 
type. 
So I told David et. al. that the type requested had 4 sub-types one already 
allocated,
so stop sub-typing and ask for 3 extra types.

I did not judge anything about the privacy issues that those 4 types may have, 
as 
that is not in scope.
It is up to the working group to give advice to either editor or expert to 
change
approach. 

> 
> The denial triggered a bit of a philosophical debate between us, but
> no matter which side of that debate you line up on it's very clear
> that Expert Review really needs documentation to appropriately set
> everyone's expectations.  I'm hoping that he and I will be
> collaborating on a draft.
> 
As Expert I do not want to write the rules for myself :-) 
I will be happy to comment on any suggested rules/advise. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] call for agenda items, IETF 98

[Olafur Gudmundsson]

> On Mar 1, 2017, at 2:19 PM, Suzanne Woolf  wrote:
> 
> Hi,
> 
> This is a good point, thanks Paul.
> 
> If you’re an editor on a WG document, please consider what you need from the 
> WG to get it ready for a Working Group Last Call.  If you’re missing 
> reviews/reviewers, the chairs/secretary are happy to help you find some. If 
> you need input from the WG, please ask for it.
> 
> If you’ve been meaning to review a Working Group document, why not make it 
> part of your prep for IETF 98?
> 
> And if you want to propose new work, please remember you’ll need reviewers 
> and editors, and pay it forward by reviewing a current draft or two :-)
> 
> 
> Suzanne
> 

Refuse-Any is ready for LC can we start it before Chicago meeting ?

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] order of records in DNAME responses

[Olafur Gudmundsson]

> On Feb 24, 2017, at 12:35 PM, Evan Hunt  wrote:
> 
> On Fri, Feb 24, 2017 at 02:46:28PM +, Edward Lewis wrote:
>> The reason I point this out is that the order of records in a section has
>> been famously undefined, with the convention of supporting round robin
>> (an undocumented feature of the protocol) hanging around, for all of
>> eternity.  I can see an implementation recommendation note because it
>> makes sense, but, if we use the old rule of "for interoperability" I
>> don't see specifying the order of records as necessary.
> 
> The order of RR's within an RRset is undefined and needs to remain so, but
> can there be constraints on the order of RRsets within a section?

While I would love to say Yes to above, that can not be any stronger than 
“SHOULD” 
The old RFC’s are much less prescriptive than modern ones. 
If we ever do a RFC2181-bis or followup work then this should be one of the 
topics 
There are basically two ways to handle it 
-  Prescribe order 
- Dicate that whole section must be consumed and “ordered” before processing.

One corner case that I seen on couple of occasions is CNAME chain out of order, 
I have no idea how that can happen … 

> 
>> I also think that goats have already left the burning barn on this.
>> Going forward code might put the DNAME ahead of the CNAME, but if past
>> code doesn't, going forward code must account for that.
> 
> It took us a very long time to encounter the first server that did
> CNAME-first.  Most are going to do DNAME-first because it's simpler to
> code that way: it's easier to append to a message than insert something
> into the middle.
> 
> IMHO the problem is now big enough to see, but still small enough
> to step on by declaring we didn't mean for it to be legal.
> 
I was around the time DNAME was defined, and my recollection was that
CNAME after DNAME was so obvious that no-one thought is was needed to specify. 

>> Not to mention the difficulties in writing so-called clarification
>> documents.  They aren't all that pleasant...
> 
> Well, that's why I started with an email thread…

Thank you for bringing real issue to WG

Olafur



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Feb 4, 2017, at 4:46 AM, Ray Bellis  wrote:
> 
> 
> 
> On 04/02/2017 02:13, Andrew Sullivan wrote:
>> Right, that's always been the problem with using this _for the DNS_.
>> Homenet has no choice in that, because the whole point of the homenet
>> name is precisely to enable in-homenet DNS without reference to the
>> global DNS.  I think you're quite correct that we need to decide
>> whether alt is to be used for those purposes.  I'm not convinced
>> that's so useful.
> 
> If it turns out that we can't get the insecure delegation that we need
> for .homenet, then I'd (personally) be reasonably happy with
> .homenet.alt, except that the current proposals for the use of .alt
> wouldn't seem to permit that.
> 
> Ray

What is wrong with homenet.arpa ? 
you can have that next month and no-one will complain 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-vixie-dns-rpz-04.txt

[Olafur Gudmundsson]

+1 
I agree this is ugly as ugly can be but that ship has sailed. 
For interoperability sake lets just publish this with a note that says 
something like this;

This is documentation of fielded useful protocol.
This is ugly protocol and it copying it is strongly discouraged. 


Olafur 
> On Dec 20, 2016, at 8:24 PM, David Conrad  wrote:
> 
> +1
> 
> Regards,
> -drc
> (speaking only for myself)
> 
>> On Dec 20, 2016, at 4:02 PM, John Levine  wrote:
>> 
>>> "Not wanting to be recruited into a botnet" is another such consideration.
>>> Paul and Vernon invented a useful tool to help address it, and I'm
>>> in favor of documenting it.
>> 
>> I would really prefer that the IETF not embarrass itself with a rerun
>> of the NAT fiasco, in which TCP/IP purists yelled and screamed and
>> insisted that NAT was evil, while in the real world it solved (still
>> solves) real problems, and everyone implemented it in various not very
>> transparent or compatible ways.
>> 
>> RPZ is ugly but it solves serious real world problems, and it's going
>> to be used all over the world regardless of what we do.  Just this
>> week I heard from a friend at a largish company that one of their
>> suppliers got hacked with the trendy new malware that hides in web
>> page images.  Without RPZ, approximately all of their Windows users
>> would have been infected, with RPZ none of them were.
>> 
>> If we want to offer advice and perhaps technical twiddles on how to
>> deploy RPZ to minimize surprises and make it easy to find and fix
>> mistakes, that would be swell.  Insisting that it's stupid and wrong
>> confirms the not ill-founded impression that dnsop is out of touch
>> with the real world.
>> 
>> So, yes, we should adopt this draft.
>> 
>> R's,
>> John
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Dec 2, 2016, at 2:55 PM, 神明達哉  wrote:
> 
> At Fri, 25 Nov 2016 19:50:48 -0500,
> tjw ietf  wrote:
> 
>> Please review the draft and offer relevant comments. Also, if someone feels
>> the document is *not* ready for publication, please speak out with your
>> reasons.
>> 
>> *Also*, if you have any opinion on changing the document named from
>> 'refuse-any' to 'minimal-any', please speak out.
> 
> I've read the 03 version of the document.  I do *not* think this is
> ready for publication since I still believe we should not abuse HINFO
> for this purpose as I argued a year ago:
> https://www.ietf.org/mail-archive/web/dnsop/current/msg16118.html
> (But other than that I think the document is quite well written).
> 

We have some implementation experience with this and the fact that we return a 
Record that is parsed and displayed in human readable format has proven 
valuable in 
dealing with “interoperability” problems. 
A number of “abusers” of ANY queries have seen this read the draft and said 
   - yep I should have a fallback
or- asking for exactly what I need is better way 

So what other RFC1034/5 defined type are you willing to throw under the bus? 
Paul Wouters accused us of doing in at the DNS-Oarc workshop in Montreal), 
these exchanges from the Q/A part of the presentation are enlightening
https://youtu.be/Gt9VUPDoZk0?t=1h24m53s



> As for renaming the file, I don't have a strong opinion, but we expect
> a bigger issue like HINFO can lead to more revisions, it would be good
> to rename it at this opportunity in order to avoid confusion for
> future readers.
> 

I’m hoping the version coming after this WGLC be advanced to the IESG/IETF LC 
so renaming at this point serves limited purpose. 

> Some specific comments on the text:
> 
> - Section 3
> 
>   1.  A DNS responder can choose to select one or subset of RRSets at
>   the QNAME.
> 
>  'one or subset of RRSets' sounds a bit awkward to me, partly because
>  'a subset of RRSets' should include 'one of RRSets' and can thus be
>  redundant, and partly because 'subset of RRSets" might sound related
>  to 'subset of an RRSet' (it's actually "a subset of set of RRSets").
>  So I'd suggest changing this one of the following:
>  - "one or a few of RRSets (but not all of them)"
>  - "one or a few of RRSets"
>  - "a subset of RRSets"
>  I personally prefer the first most although it may be too verbose.
> 
I  think the best way to address this to be consistent with Section 4 is to say 
“one RRset” and be done with it 

> - Section 4
> 
>   A DNS responder which receives an ANY query MAY decline to provide a
>   conventional response, or MAY instead send a response with a single
>   RRSet in the answer section.
> 
>  "a single RRSet" doesn't seem to be fully consistent of "one or
>  subset of RRSets" stated in the preceding section (see the previous
>  bullet).
> 
see above 

> - Section 4
> 
>   If the DNS query includes DO=1 and the QNAME corresponds to a zone
>   that is known by the responder to be signed, a valid RRSIG for the
>   RRSets in the answer (or authority if answer is empty) section MUST
>   be returned.
> 
>  Does this also apply to a synthesized HINFO (if so, by dynamically
>  signing it?)?
> 
Yes 

> - Section 6
> 
>   In the case where a zone that contains HINFO RRSets is served from an
>   authority server that does not provide conventional ANY responses.
> 
>  This may be just because of my English literacy, but on my first
>  read it was quite confusing to me; I first thought the second 'that'
>  was a relative pronoun, which would make this text an incomplete
>  sentence.  If there was a comma after 'server' that would be more
>  readable for me.

Joe and I will take a stab of making that clearer 

> 
> - Section 7: a minor typo, s/implimentations/implementations/
> 
>   not return all RRSIGS.  In the wild there are implimentations that
> 
Yep need to fix that 
Thank you for your excellent review. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNSSEC operational issues long term

[Olafur Gudmundsson]

> On Nov 16, 2016, at 5:05 AM, George Michaelson  wrote:
> 
> On the current timeline, October 11 ->  January 11 so three months.
> 
> Vendors of sealed units who ship equipment from before October 11 with
> delivery held up for three months at the docks by a strike, or people
> who put the sealed unit into a long-delay orbit to Mars to be turned
> on by Matt Damon on arrival have a problem here, if they don't have a
> backdoor manual override.
> 
> How many vendors do you think are in this space, not shipping a .trx
> or other download which installs the new info?
> 
> On Wed, Nov 16, 2016 at 6:56 PM, Mikael Abrahamsson  wrote:
>> On Wed, 16 Nov 2016, George Michaelson wrote:
>> 
>>> I feel this is a corner case. My experience with 'mom' whitegoods is that
>>> they age out much faster than the 10+ year case. Shops do not hold
>>> electronic goods for sale that long, if its old but unboxed, you have taken
>>> yourself into a dark alley deliberately. If you genuinely were supporting
>>> your mum by buying two, and keeping one offline for 10 years you would have
>>> done better buying one, and replacing after 5.
>> 
>> 
>> Ok, so let me ask an operational question:
>> 
>> The way current root zone key rollovers are thought to be used, what's the
>> theoretical shortest worst-case shelf life of a device that relies on DNSSEC
>> working for itself to work properly?
>> 
>> So if it's manufactured the day before a new key is publically released,
>> when is the key material it has built in no longer viable to have successful
>> DNSSEC validation?
> 

IMHO the device should have two sources of truth for DNSSEC root TA 
a) DNS via RFC5011 
b) Secure Software update from the vendor 

If both fail then operator should be invoked. 

There are other options but they all go into what I call “opportunistic 
learning” and are not documented
TALINK was one of them, 
PGP signed TA from known address is another one, 
sending lots of queries and learning current root key is another 

In short if a device has only what it is configured with at factory as source 
for DNSSEC TA the device is has a good chance of being a brick 
when it is connected. 

You are right we should give some guidance to OS and Systems manufactures about 
how to handle DNSSEC rollovers 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Nov 28, 2016, at 5:25 AM, Matthijs Mekking  wrote:
> 
> Hi,
> 
> I have read the draft and have two comments. Both of these have been called 
> out before, but I don't see them addressed in this version (-03):
> 
> 1. In case of a DNS responder selecting one or a subset of the RRsets at the 
> QNAME, The draft does not give clear guidance on which RRset(s) to pick. In 
> previous discussions there was yes nodding to provide text that the RRset 
> picking should be determinative, even perhaps providing guidance on the 
> selection method to use. Such text has not made it to the draft yet. I am not 
> sure if adding a single line "the RRset selection method SHOULD be 
> determinative" is sufficient, or if more text is wanted.

There have been some discussion on this topic, It is fair to say that there are 
3 camps 
a) answer with the smallest RRSET 
b) pick one at “random"
c) select bases on what is most useful (i.e. deterministic selection) 

I would be happiest to go with b)  and add text that says that. 
> 
> 2. People expressed that they would like to see ANY over TCP stick to the 
> original (undefined) behavior, that is to return all RRsets at the QNAME. Joe 
> replied that this is still possible with this document because the mechanism 
> is "a big giant MAY", but still I think it makes sense to call out explicitly 
> that the behavior MAY differ depending on the transport protocol.

This is operational choice, if we call that out do we also call out that answer 
may depend on address, TSIG etc ? 

> 
> One more nit comment, I would like to see explicitly called out in section 7 
> that "DNS implementations are free to not return all RRSIGS *in case 
> QTYPE=RRSIG*”.

Current text: 
   RRSIG queries have the same potential as ANY queries of generating
   large answers as well as extra work.  DNS implementations are free to
   not return all RRSIGS.  In the wild there are implimentations that
   return REFUSE, others return single RRSIG, etc.

Proposed text: 
   RRSIG queries have the same potential as ANY queries of generating
   large answers as well as extra work.  DNS implementations MAY return some 
but not all RRSIGS when QTYPE=RRSIG. 
   In the wild there are implimentations that
   return REFUSE, others return single RRSIG, etc.

Is this better ? 

> 
> And I prefer `minimal-any` over `refuse-any`, agreeing with the logic Ondrej 
> provided.
> 

I do not care 

> Best regards,
>  Matthijs
thanks 
Olafur

> 
> On 26-11-16 01:50, tjw ietf wrote:
>> 
>> All
>> 
>> The authors have addressed all the outstanding issues with this draft,
>> and the chairs feel this is ready for Working Group Last Call.
>> 
>> There has been one issue raised which we feel the working group may have
>> some opinion on this.
>> 
>> Ondrej Sury raised this point:
>> 
>> 
>>There's a small procedural thing - the last name of the draft
>>appears on both datatracker.i.o and tools.i.o.  I believe it
>>would be better to reupload the draft with name changed to
>> 
>>draft-ietf-dnsop-minimal-any
>> 
>>to prevent the people who might thing the name of the draft
>>bears any significance.  As this requires almost no effort
>>I think it would be better to this now than fend of the
>>questions "why is this refuse-any while it doesn't refuse
>>ANY" later.
>> 
>> 
>> 
>> The authors and the Chairs support this in principle, but the working
>> group should comment on this during the WGLC process.
>> 
>> -
>> This starts a Working Group Last Call for
>> draft-ietf-dnsop-refuse-any
>> 
>> Current versions of the draft is available here:
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>> 
>> Please review the draft and offer relevant comments. Also, if someone
>> feels the document is *not* ready for publication, please speak out with
>> your reasons.
>> 
>> *Also*, if you have any opinion on changing the document named from
>> 'refuse-any' to 'minimal-any', please speak out.
>> 
>> 
>> This starts a two week Working Group Last Call process, and ends on 10
>> December, 2016
>> 
>> thanks
>> tim
>> 
>> 
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00

[Olafur Gudmundsson]

> On Nov 14, 2016, at 5:01 PM, Ondřej Surý  wrote:
> 
> 
> - Original Message -
>> From: "Edward Lewis" 
>> To: "Ondřej Surý" 
>> Cc: "dnsop" 
>> Sent: Monday, 14 November, 2016 08:31:51
>> Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00
> 
>> I'm a little confused to the feedback, so I'm asking for some clarification.
>> 
>> On 11/14/16, 11:27, "DNSOP on behalf of Ondřej Surý" > on
>> behalf of ondrej.s...@nic.cz> wrote:
>> 
>>> I think this is a technical detail best left to the software vendors and it
>>> should be removed from the draft.
>> 
>> My question/suggestion is in reaction to this passage in the draft "proposes
>> updated resolver algorithm that separate authoritative data cache that is
>> answered to stub resolvers and delegation cache" and some other responses
>> suggesting that having two caches might be troublesome.
>> 
>> Are you saying that how this is implemented is to be left up to the software
>> developer?  If so, I agree with that.
> 
> Yes :)
> 
>> But I am not sure you if are commenting on my "why it can't it be done this 
>> way"
>> comment.  Either way, my comment is not to overly specify how.
>> 
>>> As a side note, having a (platform-sized) pointer for each RR in the 
>>> RR-cache is
>>> a huge bloat...
>> 
>> I hadn't claimed by idea was good. ;)  It was the first alternative that 
>> came to
>> mind.
>> 
>>> If we were to design RFC1034/1035 again I would say that NS records are more
>>> close to DS.
>> 
>> Hmmm.  I'm not sure I understand what you mean by "more close."  I was going 
>> to
>> say that for DNSSEC, we found it tricky to find two data sets with the same
>> owner/class/type having two sources and so had to dance around the split
>> responsibilities for the NS set.  But then we invented NSEC which is features
>> two set with the same owner/class/type but two authorities (as opposed to
>> sources) also, except that this time (NSEC and then NSEC3 and any proposed
>> updates) the RDATA was distinctly different.
> 
I was designing it today I would have a different RR type in parent and child, 
and the parent type should be able to hold glue record contents. 

> Yep, I understand why it was left alone, and it's ok that way.
> 
>> If I were to redo what was in the base definitions, I would have used 
>> different
>> type codes for the set above the cut and the set below the cut - but not for
>> NSEC/NSEC3/etc.  I don't have a neat generalization, but, in summary having 
>> the
>> NS set above and below, and having glue not marked as such in the type code
>> (GLUEA or GLUE) is, I don't know, suboptimal in retrospect.
> 
> Sure.
> 
>>> The predictability of resolver behavior.
>> 
>> Yes, there's work needed to do, both NS sets (at a cut) are needed in tandem.
> 
> Are they?  What is child-NS needed for?

That is what the NS set that the resolver should use, the one in parent is just 
a hint. 
All good resolvers should use the Parent as hint as to find the child one, once 
the resolver has the 
child one toss the one from the parent. 
I know this is one extra query which is almost free as it can be done in 
parallel with the query for real data. 

Olafur



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Olafur's "black lies" presentation

[Olafur Gudmundsson]

> On Apr 8, 2016, at 11:08 AM, Ray Bellis  wrote:
> 
> 
> 
> On 08/04/2016 11:39, Edward Lewis wrote:
>> I can't find a draft to cite for this talk, so this refers to the slides
>> presented.
>> 
>> "DNSSEC Protocol Modifications"
>> (http://www.rfc-editor.org/rfc/rfc4035.txt) has an explicit prohibition on
>> names owning only NSEC and RRSIG.
>> 
>> Yeah.
>> 
>> I'm not holding this up as a royal edict.  But it's there in plain text.
>> 


>> Fortunately there's a rationale why the requirement language is there, so
>> there's a starting point to "work on this.”

Ed, 
So the draft document needs to update RFC4035 
thanks for pointing that out 
At one point we contemplated adding a bit to the NSEC signaling this was
a forged NSEC record, just to get around the text in RFC4035 :-) 

> 
> If you treat Cloudflare's implementation as a virtual wildcard record
> where every owner name implicitly exists, then IMHO the rationale in RFC
> 4035 (below) doesn't apply:
> 
> "That is, the signing process MUST NOT create NSEC or RRSIG RRs for
>  owner name nodes that were not the owner name of any RRset before the
>  zone was signed. The main reasons for this are a desire for namespace
>  consistency between signed and unsigned versions of the same zone
>  and  a desire to reduce the risk of response inconsistency in security
>  oblivious recursive name servers."
> 
> That said, Cloudflare's implementation appears to assert that the
> wildcard doesn't exist either - I've asked Olafur to check out the
> implications of that.

Ray 
Yes, we check for wild card match before generating the NSEC. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

[Olafur Gudmundsson]

I have read the draft and support its adoption

Olafur

> On Apr 10, 2016, at 10:18 AM, Tim Wicinski  wrote:
> 
> This was discussed in Buenos Aires Friday morning, but the sense we received 
> from the room is that the group should move forward with this draft.  While 
> we like the simplicity of Warren and Geoff's cheese-shop draft 
> (draft-wkumari-dnsop-cheese-shop), it is basically a simple proof-of-concept. 
>The suggestion was to document the cheese-shop idea in this draft.
> 
> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
> draft-fujiwara-dnsop-nsec-aggressiveuse
> 
> The draft is available here:
> 
> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.  *Speak Up* if 
> you have strong opposition to this work.
> 
> *More Importantly*
> Please also indicate if you are willing to contribute text, review, etc.
> We will want several dedicated reviewers on this.
> 
> I'm going to make this a short call for adoption, as we've discussed this in 
> a few meetings.
> 
> This call for adoption ends 17 April 2016.
> 
> Thanks,
> tim wicinski
> DNSOP co-chair
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Olafur Gudmundsson]

> On Apr 7, 2016, at 11:40 AM, Jacques Latour  wrote:
> 
> Read it, like it, and 
> 
> >3.1 ... The parent retrieves the CDS and inserts the corresponding DS RRset 
> >as requested,
> 
> I think the parent can accept the CDS and insert the DS RRset as requested or 
> as per Parent policy.
> 
> Meaning the Parent could take the signed child DNSKEY and create DS RRset 
> based on parent policy and not being forced to accept the CDS algorithm &  
> Digest type.

Maybe,  the CDS record allows one to refer to a non published key i.e. one that 
is not in the DNSKEY RRset. 
Thus the CDS is “more” flexible than the DNSKEY as one can publish future KSK 
w/o placing one in the DNSKEY set (for size reasons) 

Olafur

> 
> 
> 
> > -Original Message-
> > From: DNSOP [mailto:dnsop-boun...@ietf.org ] 
> > On Behalf Of Tim Wicinski
> > Sent: April-03-16 5:29 PM
> > To: dnsop
> > Subject: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds
> > 
> > This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds
> > 
> > Current versions of the draft is available here:
> > 
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ 
> > 
> > 
> > Please review the draft and offer relevant comments. Also, if someone feels
> > the document is *not* ready for publication, please speak out with your
> > reasons.
> > 
> > Feel free to show up at DNSOP's Wednesday session and voice your approval
> > or disapproval.
> > 
> > This starts a two week Working Group Last Call process, and ends on
> >17 April 2016
> > 
> > thanks
> > tim
> > 
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org 
> > https://www.ietf.org/mailman/listinfo/dnsop 
> > 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-maintain-ds

[Olafur Gudmundsson]

Thanks Bob
fixed in my repo

Olafur

> On Apr 5, 2016, at 9:42 AM, Bob Harold  wrote:
> 
> 
> On Sun, Apr 3, 2016 at 11:25 PM, Ólafur Guðmundsson  > wrote:
> 
> Dear colleagues, 
> a new version of the document has been posted that fixes few minor 
> grammatical and spelling errors. 
> 
> this is version 02 
> URL:
> https://www.ietf.org/internet-drafts/draft-ietf-dnsop-maintain-ds-02.txt 
> 
> Status: 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ 
> 
> Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-maintain-ds-02 
> 
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-maintain-ds-02 
> 
> 
> Olafur 
> 
> On Sun, Apr 3, 2016 at 6:29 PM, Tim Wicinski  > wrote:
> This starts a Working Group Last Call  for draft-ietf-dnsop-maintain-ds
> 
> Current versions of the draft is available here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-maintain-ds/ 
> 
> 
> Please review the draft and offer relevant comments. Also, if someone feels 
> the document is *not* ready for publication, please speak out with your 
> reasons.
> 
> Feel free to show up at DNSOP's Wednesday session and voice your approval or 
> disapproval.
> 
> This starts a two week Working Group Last Call process, and ends on
> 17 April 2016
> 
> thanks
> tim
> 
> 
> Looks good to me.  One more typo:
> 
>  5.  Security considerations
> -- end of last sentence:
> "after a certain about of wait time - thus allowing a child
>administrator to cancel the request."
> 
> "about" should be "amount"
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-maintain-ds adding vs. deleting DS, and document track

[Olafur Gudmundsson]

> On Apr 7, 2016, at 5:33 PM, John Levine  wrote:
> 
>> We could have written 
>> “After observing CDS records for 15 days or 2 resigning cycles which ever is 
>> longer, accept them and upload DS” 
>> Is that  better ? 
>> It sets expectations 
> 
> I think my users (the ones who know about DNSSEC) would not be happy
> to hear that their entirely valid signed zone won't be verifiable for
> two weeks, just because I am not as cool as some others are.
> 
>> But there is the case Parent happens to know the operator of the domain and 
>> via out of band knowledge can be
>> sure the domain is operated a that party. In this case the upload should not 
>> suffer any delay. 
> 
> It needs to be stronger than that, define a small set of automatable
> ways (ideally just one) that the uncool child can verify its bona
> fides to the parent.  It's fine for domains to opt out of them for
> security reasons, but in most cases where the registration is only
> secured by a password, it'll be fine.
> 
> 
> R's,
> John

John, does the challenge mode addresses your concerns?
i.e. parent gives the “uncool” operator something to insert into the zone to 
prove they can change the zone. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-maintain-ds adding vs. deleting DS, and document track

[Olafur Gudmundsson]

> On Apr 6, 2016, at 3:50 PM, Shane Kerr  wrote:
> 
> Hello,
> 
> RFC 7344 left out the problems of deletion and addition because they
> were scary.
> 
> I think that the draft-ietf-dnsop-maintain-ds document is quite clear
> about deleting DS records, and I think it makes sense.
> 
> However, in the case of adding DS records, to me the document is less of
> a specification than a discussion about possible approaches to the
> difficult issue of when to accept the CDS RRset. This discussion is not
> necessarily a problem, because that's all we have today.

Shane thank you for starting this discussion, 
We could have written 
“After observing CDS records for 15 days or 2 resigning cycles which ever is 
longer, accept them and upload DS” 
Is that  better ? 
It sets expectations 
But there is the case Parent happens to know the operator of the domain and via 
out of band knowledge can be
sure the domain is operated a that party. In this case the upload should not 
suffer any delay. 

So yes I agree having well defined policies is a good idea, but we need help 
and guidance in 
making the text better and figure out 2 or 3 reasonable policies, to recommend 
to people 

> The reasons that I questioned whether this draft should result in a
> standards-track document is because of the ambiguous and vague way that
> DNSSEC is enabled with CDS/CDNSKEY.
> 

I get your point, and kind of agee with it (have not asked my co-editor what he 
thinks)

> I do think that RFC 7344 should be standards track.

Great, 

> 
> To be clear, I'm not strongly opposed to standards track, but I am not
> sure what it means to have a standards track document that doesn't
> actually tell me how to inter-operate or even really how to do anything
> concrete. (This might just be my IETF ignorance, I admit!)
> 

I think having this on standards track is better than not. 
If there is bad advise in the document we can always replace it with better 
RFC. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] IPR Disclosure Red Hat, Inc.'s Statement about IPR related to draft-ietf-dnsop-dnssec-roadblock-avoidance and This disclosure relates to text amendment proposed in http://www.ietf.org/mail

[Olafur Gudmundsson]

Petr, 
I’m sorry I failed to include this in the 03 update of the roadblock draft 
issued 2 weeks ago. 
A new version that includes your text slightly edited was just submitted as 04. 
Version 04 only contains textual clarifications and corrections in addition to 
the valuable 
contribution from RedHat. 

Olafur


> On Dec 1, 2015, at 4:42 AM, Petr Spacek  wrote:
> 
> Hello dnsop,
> 
> this IPR statement has been made to unblock the process as proposed by Olafur
> a month ago:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg15848.html
> I'm sorry for the delay.
> 
> Could dnsop now re-consider the draft amendment proposed in
> http://www.ietf.org/mail-archive/web/dnsop/current/msg13303.html
> ?
> 
> Thank you!
> 
> Petr Spacek
> 
> On 30.11.2015 20:50, IETF Secretariat wrote:
>> Dear Wesley Hardaker, Ólafur Guðmundsson, Suresh Krishnaswamy:
>> 
>> 
>> An IPR disclosure that pertains to your Internet-Draft entitled "DNSSEC
>> Roadblock Avoidance" (draft-ietf-dnsop-dnssec-roadblock-avoidance) was
>> submitted to the IETF Secretariat on  and has been posted on the "IETF Page 
>> of
>> Intellectual Property Rights Disclosures"
>> (https://datatracker.ietf.org/ipr/2716/). The title of the IPR disclosure is
>> "Red Hat, Inc.'s Statement about IPR related to
>> draft-ietf-dnsop-dnssec-roadblock-avoidance and This disclosure relates to 
>> text
>> amendment proposed in 
>> http://www.ietf.org/mail-archive/web/dnsop/current/msg13303.html";
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] SecDIr review: draft-holmberg-dispatch-pani-abnf-02

[Olafur Gudmundsson]

I have reviewed this document as part of the security directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written primarily for the benefit of the security area directors. 
 Document editors and WG chairs should treat these comments just like any other 
last call comments.

The document is short and to the point, it has no security issues and is ready 
for publication. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

[Olafur Gudmundsson]

> On Dec 27, 2015, at 11:40 PM, John Levine  wrote:
> 
>>> NEW
>>>   For instance, some authoritative name servers embedded in load
>>>   balancers reply properly to A queries but send REFUSED to NS queries.
>>>   This behaviour violates the DNS protocol (see Section ??? of [RFC??],
>>>   and improvements to the DNS are impeded if we accept such behaviour
>>>   as normal.
>>> END
>> 
>> Does anyone has an idea of the reference to use to replace the "???"
> 
> Given that it doesn't seem to be a protocol violation, I'd suggest this:
> 
>For instance, some authoritative name servers embedded in load
>balancers reply properly to A queries but send REFUSED to NS queries.
>This behavior causes a variety of problems, such as invalid negative
>answers, that are so severe that it is unreasonable to expect clients
>to interoperate with them reliably and so there is no point in trying to
>work around them.
> 
> R's,
> John
> 

For the longest time in the DNS world there have been different  standards of 
conduct for the different functional elements.
Publishers can get a away with gross misconduct, while resolvers are expected 
to find the answer at all cost. 

I agree with your statement as the first step in calling out authorities that 
if they are “not nice” there is no need to try to return the answer.
In 1999 or 2000 we started seeing LoadBalancers that returned NXDOMAIN for any 
query other than A for a name. 
At the time the bind-9 team argued about what to do, I still think that the 
behavior selected was the wrong one i.e. ignore NXDOMAN for  query and ask 
for A. 

IMHO a resolver that does not like the answers it is getting from a authority 
has full right to stop trying to find the answer and return SERVFAIL. 
I understand that operators of said resolver will get complaints that important 
cat pictures are unavailable,……

I think for all practical purposes this situation is a great example of the 
“Prisoners Dilemma” as there is no way to educate the people writing the crap 
software as they are insulated by multiple layers of protection. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt

[Olafur Gudmundsson]

> On Nov 2, 2015, at 12:28 AM, Woodworth, John R 
>  wrote:
> 
> See inline comments:
> 
>> -Original Message-
>> From: Edward Lewis [mailto:edward.le...@icann.org 
>> ]
>> Subject: Re: [DNSOP] discussion for draft-woodworth-bulk-rr-00.txt
>> 
>> Process wise, you should seek to have this on the experimental track.  It
>> has potential but is far from a sure thing.
> 
> 
> Edward, Thank you very much for your time.  I will need to research more in
> regard to the experimental track, thank you.  Any more advice you could
> offer here would be great.
> 

This is a quite interesting proposal, too early to tell what track the document 
should be on,
for now Standards track is fine. 

> 
>> 
>> The idea of being able to send formulas for generating responses,
>> particularly for address records, reverse map and CNAME is a latent need
>> in the DNS hosting industry.  These types are special in that way, so it's
>> no surprise they are singled out.
>> 
>> I'll admit that I read and scanned portions to get an idea of what is
>> discussed.  I do like that you have the section 7.1, addressing DNSSEC.

+1

>> 
>> One "red flag" to me is the idea of hidden wildcards.  One of the design
>> principles of DNSSEC is that it exposes the "thinking" process of the
>> server to the requestor.  That alone isn't a dead end - hidden records and
>> on-the-fly signing would "work" (but as you note not all name server
>> implementations have the ability to sign on-the-fly).
> 
> 
> Good point.  Our reasoning behind this was to avoid undue discrimination.
> Many providers, especially in the context of "anti-spam" make seemingly
> arbitrary decisions to block or disable huge batches of addresses based
> on coin-toss accuracy.  I've personally seen the simple changing of "dyn"
> to "static" in a hostname make all the difference and wanted to entirely
> avoid this set of circumstances where possible.  By hiding the fact the
> records are part of a pattern (i.e. hiding a "BULK" RR request with the
> same owner) the generated records are no longer susceptible to this form
> of discrimination.  Since one of our primary motivations was in essence to
> provide $GENERATES which could AXFR there is a zero externally-identifiable
> change to $GENERATEd records (i.e. no change to operational support).
> 

I understand you want the way to minimize the zone transfers, and not expose to 
the world
your auto generate rules. IMHO this limits your operational to 3 options  
a) no DNSSEC 
b) on-line signing DNSSEC 
c) delegate to zones that are either a) or b) 

The option of modifying resolvers is likely to hinder the deployment of the 
proposal as the community that your
are trying to trick are  . 

One way is that your document can be simplified is by dropping any attempt to 
support off-line signed zones. 
I do not see this as operational complication as in most cases BULK records 
will be interpreted by servers that are under a
single administrative control. 

> This, of course, is negated where pre-signed DNSSEC records are used and
> supplemental "NPN" records are required.  In this case, hiding the wildcards
> would prove moot for this purpose.  However, the NPN record provides a
> level of transparency for DNSSEC's "thinking" process while also offering
> some additional protection against would-be attackers probing DNS for a
> zone's internal organizational structure a la NSEC.
> 
> 
>> 
>> Cutting to the chase, there are various elements here that could work
>> together.  But also combinations that wouldn't work so well.  Simply put,
>> this is complicated.  For reasons I'll not include here, complicating the
>> protocol isn't leading in the right direction.
> 
> 
> Before continuing let me state your opinion is greatly respected and
> appreciated and my enthusiasm should not be taken as disrespect toward you
> or your comments in any way.
> 
> While I wholeheartedly agree this adds a fair amount of complexity to the
> authoritative side of the equation, disregarding DNSSEC the burden on the
> recursive side is unaffected.  Where DNSSEC is required and on-the-fly is
> available, the recursive side is just as unaffected.  Where DNSSEC is
> required and on-the-fly is unavailable, we feel this complication is
> unavoidable.
> 

A big compliment to you for thinking about how to support DNSSEC 
IMHO on-line signing is the only realistic way forward, as the there is little  
motivation by resolvers operators that you want mostly to affect to run
modern stuff. 

> When placed into a similar context as DNSSEC and the complexity of
> recursively chained cryptographic validation the added complexity supporting
> these records would add is relatively trivial.
> 
This is not a question of complexity, it is about inertia.
 

> Best regards,
> John
> 

Olafur 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state "Candidate for WG Adoption"

[Olafur Gudmundsson]

> On Nov 5, 2015, at 9:55 PM, Shane Kerr  wrote:
> 
> Dear dnsop working group,
> 
> On Thu, 05 Nov 2015 17:20:18 -0800
> IETF Secretariat  wrote:
> 
>> The DNSOP WG has placed draft-ogud-dnsop-maintain-ds in state 
>> Candidate for WG Adoption (entered by Tim Wicinski)
>> 
>> The document is available at
>> https://datatracker.ietf.org/doc/draft-ogud-dnsop-maintain-ds/
> 
> First, I definitely think that this should be a working group document.
> 
> Second, some comments about the draft (with the hope that it does get
> adopted):
> 
> * I think "all 0" CDS/CDNSKEY indicating desire for deletion is fine.
>  Defining a DNSKEY algorithm that does not actually define a DNSKEY
>  algorithm is a bit weird.
> 
> * Perhaps a paragraph clarifying behavior when there is the "all 0"
>  CDS/CDNSKEY AND another CDS/CDNSKEY record is a good idea?
>  Something like:
> 
>If any other CDS/CDNSKEY record is present in a zone, then the
>CDS/CDNSKEY records indicating deletion MUST be ignored.   
> 

Shane, 
good suggestion we will adopt it, maybe with some rewording. 

> * The acceptance criteria for new CDS records seem less like a protocol
>  definition and more like an exploration of possible approaches.
>  Probably this is because that is what they are? :P Does it make sense
>  to define more detail? I kind of think "yes", but since there is no
>  deployment experience it's likely that it would all be incorrect.
> 

You are right it is a protocol exploration as we have nothing but what has 
shown to be difficult to deploy. 
And hopefully you are also wrong on if this advise will be ignored, I hope it 
will become the bases
of many operations. 

> * I don't see much motivation for "Acceptance policy via authenticated
>  channel". It seems like if you have access to such a channel you may
>  as well just provide the DS record? Or is the idea that you make it so
>  that the administrator for a zone doesn't need to cut/paste DS
>  information but can just check a "delegate this" box?

Well the idea is a that a DNS operator can Identify the request that the 
CDS/CDNSKEY processing by parent is started. 
possibly even handing over the expected records. 
In my employers case the acceptance policy is we give the people that are 
willing to work with us the list of keys we will sign with, 
because that is a short list. 

> 
> * Perhaps "Accept with challenge" should provide some advice on how
>  this works. For example, a TXT record with a unique key for each zone
>  (or customer) seems like a good recommendation. It might also make
>  sense if each child domain (or customer) has a unique ownername to
>  look for, to prevent 3rd parties from detecting such bootstrapping.
>  (Yes a 3rd party can see the CDS update followed by the DS update,
>  but they won't know the verification used.) Also to note that after
>  the trust is established that the challenge record should no longer
>  be necessary and can be removed.
> 

There are many different ways to do this
a) generate a random name with arecord with defined content 
b) put a  record at a fixed name with random content 
c) require resigning the CDS/CDNSKEY record with defined expiration time 
etc. it is just a question of imagination what people come up with. 
If the working group wants to recommend one standard way, that is fine. 
Text welcome 


> Sayōnara!
> 
> —
> Shane

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views: IPR issues

[Olafur Gudmundsson]

Petr, 
sorry of my tardiness,
I’m fine with adding text along the lines you outlined, as long as there is
and IPR statement that is inline with the terms you referred. 

Wes, do you agree ? 

Olafur

> On Oct 23, 2015, at 5:38 AM, Petr Spacek  wrote:
> 
> On 7.10.2015 17:47, Petr Spacek wrote:
>> On 25.8.2015 17:34, Petr Spacek wrote:
>>> On 26.6.2015 22:45, Olafur Gudmundsson wrote:
>>>>> On Feb 11, 2015, at 11:24 AM, Petr Spacek  wrote:
>>> [...]
>>>>> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way 
>>>>> how to
>>>>> improve usability without sacrificing security.
>>>>> 
>>>>> 
>>>>> Disclaimer
>>>>> ==
>>>>> Method described below is covered by US patent application named "USING 
>>>>> DOMAIN
>>>>> NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".
>>>>> 
>>>>> See Red Hat, Inc. Statement of Position and Our Promise on Software 
>>>>> Patents:
>>>>> http://www.redhat.com/legal/patent_policy.html
>>>>> 
>>>>> 
>>>> I reject the below text as I do not want any IPR on anything in this 
>>>> informational document. 
>>>> Olafur
>>> 
>>> Olafur and dnsop chairs,
>>> 
>>> would you be willing to accept the text below if Red Hat granted a license
>>> similar to https://datatracker.ietf.org/ipr/1430/ ?
>>> (I.e. the patent could be asserted only for defensive purposes.)
>>> 
>>> I'm asking because the text might be suitable for some other document
>>> describing split-dns, so this question is still valid even if the text might
>>> not be directly usable in draft-ietf-dnsop-dnssec-roadblock-avoidance.
>>> 
>>> Thank you for considering this as an option.
>> 
>> I'm sorry for nagging you again, but we are still interesting in knowing if
>> proposed approach how to deal with patent issue would be acceptable to dnsop.
>> 
>> Thank you very much,
>> Petr Spacek  @  Red Hat
> 
> Hello once again,
> 
> we as a company are really interested in contributing to IETF but we have to
> sort out situation about the patent first. Could chairs (or possibly draft
> authors) clarify dnsop (or author's?) position on this?
> 
> Thank you for your time,
> Petr Spacek @ Red Hat
> 
> 
>>> Petr Spacek @ Red Hat
>>> 
>>>>> The Hack
>>>>> 
>>>>> Fundamental assumption:
>>>>> Internal & external DNS view are both signed with the same keys or both
>>>>> unsigned. This assumption allows the method to work without explicit
>>>>> configuration on every client and removes dependency on reliable/secure
>>>>> network-detection logic.
>>>>> 
>>>>> 
>>>>> The main idea can re-phrased as amendment to section 5 of the draft:
>>>>> 
>>>>>  The general fallback approach can be described by the following
>>>>>  sequence:
>>>>> 
>>>>>  If the resolver is labeled as "Validator" or "DNSSEC aware"
>>>>>  Send query through this resolver and perform local
>>>>>  validation on the results.
>>>>> 
>>>>>  If validation fails, try the next resolver
>>>>> 
>>>>>  Else if the resolver is labeled "Not a DNS Resolver" or
>>>>> "Non-DNSSEC capable"
>>>>>  Mark it as unusable and try next resolver
>>>>> 
>>>>> --- amended text begins here ---
>>>>> 
>>>>>  Else if no more resolvers are configured and if direct queries
>>>>>  are supported
>>>>> 1. Try iterating from Root
>>>>> 
>>>>> 2. If the answer is SECURE/BOGUS
>>>>>   Return the result of iteration.
>>>>> 
>>>>> 3. If the answer is INSECURE
>>>>>   Re-query "Non-DNSSEC capable" servers and get answer
>>>>>   from "Non-DNSSEC capable" servers.
>>>>>   Set AD bit to 0 before returning the answer to client.
>>>>> 
>>>>>  Else return a useful error code
>>>>> 
>>>>> 
>>>>> This method covers DNS split-views with internal unsigned views pretty
>>>>> nicely as long as the fundamental assumption holds. (Naturally it works 
>>>>> only
>>>>> for cases where fallback to iteration is possible.)
>>>>> 
>>>>> We wanted to write Unbound module for this but it is harder than it seems.
>>>>> (Proof-of-concept with stand-alone DNS proxy works fine, we have problem 
>>>>> with
>>>>> Unbound module architecture - not with the described method.)
>>>>> 
>>>>> Feel free to incorporate the idea to the draft if you wish.
>>>>> 
>>>>> -- 
>>>>> Petr Spacek  @  Red Hat

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The EDNS Key Tag Option

[Olafur Gudmundsson]

> On Jul 29, 2015, at 10:34 PM, Wessels, Duane  wrote:
> 
> Hi Olafur,
> 
> For an RD=0 query to a name server authoritative for the "." zone the client 
> would send 12345, 23456.
> 
> For an RD=0 query to a name server authoritative for the evil.example zone, 
> the client would send 9666, 6669.
> 
> For RD=1 queries, I propose that the client send key tags for the trust 
> anchor whose name has the longest match to the query name.  So for an RD=1 
> query for verisign.com <http://verisign.com/> it would send 12345, 23456.  
> For www.evil.example <http://www.evil.example/> it would send 9666, 6669.  
> Certainly I suppose the "." trust anchor could still validate the 
> www.evil.example <http://www.evil.example/> response but the client will have 
> other queries that would result in the "." trust anchor being sent upstream.

Why not include the number of labels to the TA  in the option? 
rather than have “user” chase down with it was for www.evil.examle 
<http://www.evil.examle/>. evil.example. , example or “.”  ? 

The main usage for this option IMHO is to check if the “local” resolver set is 
using expected TA’s, and if it is not enable “user” to complain.

Olafur



> 
> DW
> 
> From: Olafur Gudmundsson [o...@ogud.com]
> Sent: Wednesday, July 29, 2015 9:19 PM
> To: Wessels, Duane
> Cc: IETF DNSOP WG
> Subject: Re: [DNSOP] The EDNS Key Tag Option
> 
> 
>> On Jul 29, 2015, at 8:09 PM, Wessels, Duane > <mailto:dwess...@verisign.com>> wrote:
>> 
>> Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged
>> me to finish and submit what I think may be a better method for tracking
>> trust anchor updates.  I've described an edns-key-tag option, which puts
>> trust anchor key tags in the EDNS OPT record.  It is modeled after RFC
>> 6975, which is a way that clients can signal to servers the DNSSEC algorithms
>> that they support.
>> 
>> https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/ 
>> <https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/>
>> 
>> Feedback would be welcomed.
>> 
>> Duane W.
> 
> 
> Duane, 
> 
> Question: 
> Validator has following TA’s configured 
> . 12345  and 23456 
> evil.example9666 6669  
> 
> The if the query is for 
> verisign.com <http://verisign.com/>  what TA”S are returned 
> if the query is for 
> www.evil.example <http://www.evil.example/>.   What TA’s are returned ? 
> 
> Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] The EDNS Key Tag Option

[Olafur Gudmundsson]

> On Jul 29, 2015, at 8:09 PM, Wessels, Duane  wrote:
> 
> Seeing Warren's recent draft on updates of DNSSEC trust anchors encouraged
> me to finish and submit what I think may be a better method for tracking
> trust anchor updates.  I've described an edns-key-tag option, which puts
> trust anchor key tags in the EDNS OPT record.  It is modeled after RFC
> 6975, which is a way that clients can signal to servers the DNSSEC algorithms
> that they support.
> 
> https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/
> 
> Feedback would be welcomed.
> 
> Duane W.


Duane, 

Question: 
Validator has following TA’s configured 
. 12345  and 23456 
evil.example9666 6669  

The if the query is for 
verisign.com   what TA”S are returned 
if the query is for 
www.evil.example .   What TA’s are returned ? 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 2181 - a pathway forward.

[Olafur Gudmundsson]

> On Jul 10, 2015, at 1:31 PM, manning  wrote:
> 
> I am aware of  at least three of the independent ideas in RFC 2181 that folks 
> are working on:
> 
> draft-pfrc-2181--naming-issues-00
> draft-pfrc-2181-handling-zone-cuts-00  (isn’t this the basis for the dbound 
> work?)
> draft-pfrc-2181-resource-record-sets-00
> draft-pfrc-2181-tc-bit-00
> 
> Ok, so that is four.   The rational for eight is so that nothing gets lost 
> and we can garbage collect RFC 2181, moving it to historic.
> Then each idea can progress independently, without the linkage to any of the 
> other work and without the vestigial anchor to the
> collective past (RFC2181).

There is a difference between “someone” working on and what is acceptable 
and/or relevant to the DNSOP working group.
Please share more!!! 


> 
> First split them apart  into their own RFCs
> Second, move RFC 2181 to historic
> Third, start -bising the specify RFCs that folks are working on anyway.
> 
> Clean, Tidy, No trailing steams of toilet paper stuck to our shoes.
> 

Not at all this will become a reference nightmare there are currently over 40 
RFC that reference 2181, finding which document to read
now is much harder.
Not to mention that people will pick on the documents for not following current 
way of standards writing to the letter. 

Bill,  please tell us what you want update before starting any process that may 
or may not work. 
With out justification this is a waste of everyone’s time, because if the 
proposed work is not acceptable there is no reason to update RFC2181 in any way.

Olafur (hating being the process fascist) 


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC 2181 - a pathway forward.

[Olafur Gudmundsson]

> On Jul 8, 2015, at 2:50 PM, manning  wrote:
> 
> With the WG Chairs permission.
> 
> RFC 2181 is growing a both long in the tooth.  It is, by its own admission, a 
> collection of eight distinct and independent ideas.  As such, it is difficult 
> to work on one of 
> those ideas without raising concerns about all of them.   With some 
> coworkers, we split out each of the ideas in RFC 2181 and have created a 
> standalone ID that has the 
> EXACT text from RFC 2181.  What would be a very nice, administrative, step is 
> to take each of these IDs and last call them, turning them into RFCs with the 
> same status
> as RFC 2181.  It will then be possible to declare RFC 2181 historic, and 
> folks that then want to update/work on specifics can make changes against 
> these new RFCs.
> 

Bill, 
I oppose this strongly for the following reasons 
a) A frequent comment I hear is “DNS has too many RFC’s to read”, this approach 
will make that worse for no reason. 
b) If there is a need to update an section of RFC2181 then we have a process to 
obsolete parts of RFC2181 with a new document.
c) Just putting this as is in front of the WG is just make-work IMHO 

Question: 
What sections of 2181 do you see the need to update? 

Regards 
Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

[Olafur Gudmundsson]

On Thu, Jul 9, 2015 at 9:23 AM, Suzanne Woolf 
wrote:

> (No hats, and no strong feelings-- a minor point.)
>
> On Jul 8, 2015, at 11:11 PM, Evan Hunt  wrote:
>
> > On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote:
> >> Less flippantly, it is in this email:
> >> https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html  I
> >> don't think that we have a really good motivation for a week, other
> >> than that is feels sort of like a good, human scale timeframe to
> >> recheck on things. We really want there to be a limit on the lifetime,
> >> a week felt right...
> >
> > Yep, that's pretty much it, right there.  A day isn't enough (we had
> > feedback from customers to this effect) but anything longer than a week
> > strikes me as much too likely to fall off operators' radar.  Though the
> > limit is arbitrary, I do believe that we need to assert *some* limit,
> > on this approximate time scale.
>
> OK, so….vendor feedback from customers sounds like a motivation that's
> perfectly appropriate to document. "There's limited experience with what
> this value should be, but at least one large vendor has documented customer
> feedback suggesting that a week is reasonable based on expectations of how
> long failures take to fix or to be forgotten. Operational experience may
> further refine these expectations."
>
> Agreed that there MUST be an expiration set (Sec. 2) but MUST (or even
> MUST NOT) always seems weird to me on a specific value, especially given
> that there's a SHOULD in Sec. 2 about letting the operator set the duration.
>
> How about: "NTAs MUST expire automatically when their configured lifetime
> ends.  The lifetime SHOULD NOT exceed a week."
>
> This allows for enforcement in code if Evan wants, without requiring it.
> :-)
>
>
Strictly speaking the minimum time needed for a Negative Trust anchor is
something like
Domain_Operator_reaction_time + Parent_reaction_time + Parent DS TTL +
DNSKEY TTL

We do not know how long the reaction times are for either the domain
operator nor the Parent, once both have acted we the change is still
hostage of the TTL values selected by the two operators.

>From a large sample of DNSKEY and DS I have (few months old) majority of
parents set DS TTL to a day or more.
Com./net./org/info/root are 1D.
fr./ovh. are 2D

Thus if a domain in fr. requires a negative trust anchor the MINIMAL time
needed for that trust anchor is 3 days.
On the other hand a domain in com.br  is a day.

Summary: giving out a general conservative rule is OK, as predicting the
the total recovery time is impossible as only the lower bound can be
estimated.

Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

> On Jul 1, 2015, at 9:31 AM, Tim Wicinski  wrote:
> 
> 
> Thanks Olafur.  The Workign Group should discuss this as it was originally 
> planned to go into a Working Group Last Call.  It can still be taken in this 
> direction.
> 
> tim
> 
> 
Tim
We request a WGLC on the document

    Olafur

> On 7/1/15 8:52 AM, Olafur Gudmundsson wrote:
>> This version is a final version from the editors.
>> We explicitly punt on explaining how to overcome the situation when a 
>> ´proxy/forwarder’ “randomly” sends queries to
>> Resolvers with different capabilities.
>> 
>> Olafur
>> 
>>> On Jul 1, 2015, at 8:49 AM, internet-dra...@ietf.org wrote:
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> This draft is a work item of the Domain Name System Operations Working 
>>> Group of the IETF.
>>> 
>>>Title   : DNSSEC Roadblock Avoidance
>>>Authors : Wes Hardaker
>>>  Olafur Gudmundsson
>>>  Suresh Krishnaswamy
>>> Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
>>> Pages   : 16
>>> Date: 2015-07-01
>>> 
>>> Abstract:
>>>   This document describes problems that a DNSSEC aware resolver/
>>>   application might run into within a non-compliant infrastructure.  It
>>>   outline potential detection and mitigation techniques.  The scope of
>>>   the document is to create a shared approache to detect and overcome
>>>   network issues that a DNSSEC software/system may face.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
>>> 
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02
>>> 
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

This version is a final version from the editors. 
We explicitly punt on explaining how to overcome the situation when a 
´proxy/forwarder’ “randomly” sends queries to 
Resolvers with different capabilities. 

Olafur

> On Jul 1, 2015, at 8:49 AM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
>Title   : DNSSEC Roadblock Avoidance
>Authors : Wes Hardaker
>      Olafur Gudmundsson
>  Suresh Krishnaswamy
>   Filename: draft-ietf-dnsop-dnssec-roadblock-avoidance-02.txt
>   Pages   : 16
>   Date: 2015-07-01
> 
> Abstract:
>   This document describes problems that a DNSSEC aware resolver/
>   application might run into within a non-compliant infrastructure.  It
>   outline potential detection and mitigation techniques.  The scope of
>   the document is to create a shared approache to detect and overcome
>   network issues that a DNSSEC software/system may face.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-roadblock-avoidance/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-roadblock-avoidance-02
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

[Olafur Gudmundsson]

> On Jun 30, 2015, at 8:53 AM, Tony Finch  wrote:
> 
> Olafur Gudmundsson  wrote:
> 
>> There is much simpler way.
>> Just add record to the rootzone that is only signed by the new key.
>> If resolver returns AD bit it has the new key.
> 
> I don't think this works.


> 
> If the new key is published in the root zone's DNSKEY RRset then it will
> be signed by the old key, so a validator will have a trust path from a
> stale trust anchor down to the special record (just like it does for
> records signed by ZSKs).
> 

> If the new key is not published in the root zone, then you are assuming
> that the validator uses DNSKEY records for its trust anchor configuration
> (but some validators use DS records) and that the validator will allow any
> RRset to be signed by the trust anchor (but RFC 4035 section 5 suggests
> only using the trust anchor to validate the apex DNSKEY RRset).
> 

I think it works some of the time i.e. 
if one or more of the following are true 
a) If the trust anchor is maintained by operator and operator saw advertisement 
and acted upon 
b) if the new key is advertised by 5011 protocol long before it is rolled and 
then removed 
c) If the New key is advertised via CDNSKEY and is picked up via trust anchor 
maintenance 
but most importantly: 

d) the Trust anchor is maintained by storing the DNSKEY when possible[*]

So this is not perfect mechanism, will give us an idea how many Validators 
picked up the new trust anchor 
and then we can start the real propaganda campaign. 

My bullet b) is a change from the root key rollover plan that assumes that new 
key is added just before it is used. 
I would propose that 5011 advertising  is done multiple times before the 
rollover and the new key is removed during the ZSK rollover,
to allow testing. 

I do not yet propose what name or record is used for this experiment but having 
it an “address of an object” would be good as that
enables testing from browsers. (CNAME is just as good as an address) 
 
Olafur

Ps: based on my quick check of unbound and Bind both store DNSKEY’s,  I do not 
know how Nomininum, Microsoft and/or DNSMasq store it. Large public resolvers 
like Google are likely to do this via configuration 

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Shannon, Rockall, Malin: South 5 to 7, occasionally gale 8 at first in
> Rockall, decreasing 3 or 4. Moderate or rough, occasionally very rough except
> in Malin. Rain then fog patches. Moderate, occasionally very poor.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

[Olafur Gudmundsson]

Atlas probes can help us we can even measure this from webpages,
cellphones, OS updates can add a test etc.

Olafur
On Jun 29, 2015 7:33 PM, "Warren Kumari"  wrote:

> On Mon, Jun 29, 2015 at 7:28 PM, Olafur Gudmundsson
>  wrote:
> > There is much simpler way.
> > Just add record to the rootzone that is only signed by the new key.
> > If resolver returns AD bit it has the new key.
> >
> > All that is needed is to sign a Rrset for a long time and add it at to
> the
> > rootzone and make sure no ZSK signs it.
>
> ... and know where the nameservers are, and be able to query the
> nameservers to see if they are returning the AD bit. This requires
> that they are open recursive, that IANA (or someone) is able to query
> them, or something similar...
>
>
> Unless I've completely misunderstood?
>
> W
>
>
> >
> > Olafur
> >
> > On Jun 29, 2015 4:49 PM, "Warren Kumari"  wrote:
> >>
> >> Hi all,
> >>
> >> So, there is a project underway to roll the DNSSEC root key. There has
> >> been much written about this, including SAC063
> >> (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a
> >> DNSSEC Root KSK Rollover Plan Design Team, various consultations with
> >> the community, many presentations at DNS-OARCs, etc.
> >>
> >> One of the biggest impediments to actually performing the rollover is
> >> that some set of folk will not have performed RFC5011 style rollover,
> >> whether because their software doesn't support 5011, because they have
> >> statically configured a TA, because the bigger response makes them
> >> sad, whatever. The fact that we cannot tell who has only has the old
> >> key, and who has both makes the keyroll very scary - we cannot predict
> >> who, and how wide scale the outage will be when the old key is
> >> removed.
> >>
> >> I've written a draft that proposes a different way of performing root
> >> key rollover that exposes who all has which key - this allows one to
> >> know that 99.8% of resolvers have the new key, who has the old one,
> >> and who will break.
> >> It does this by encoding the current set of TAs that the resolver has
> >> into a query, and using that to fetch the new keys. By watching
> >> queries at the root one can see the population of people with each TA,
> >> and watch that change over time. This was written for root key roll,
> >> but is applicable to any TA in the tree.
> >>
> >>
> >> I'd appreciate any feedback, the draft announcment is here:
> >> Name:   draft-wkumari-dnsop-trust-management
> >> Revision:   00
> >> Title:  Simplified Updates of DNS Security (DNSSEC) Trust
> Anchors
> >> Document date:  2015-06-29
> >> Group:  Individual Submission
> >> Pages:  8
> >> URL:
> >>
> >>
> https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt
> >> Status:
> >> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/
> >> Htmlized:
> >> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00
> >>
> >>
> >> Abstract:
> >>This document describes a simple means for automated updating of
> >>DNSSEC trust anchors.  This mechanism allows the trust anchor
> >>maintainer to monitor the progress of the migration to the new trust
> >>anchor, and so predict the effect before decommissioning the existing
> >>trust anchor.
> >>
> >>It is primarily aimed at the root DNSSEC trust anchor, but should be
> >>applicable to trust anchors elsewhere in the DNS as well.
> >>
> >>[ Ed note - informal summary: One of the big issues with rolling the
> >>root key is that it is unclear who all is using RFC5011, who all has
> >>successfully fetched and installed the new key, and, most
> >>importantly, who all will die when the old key is revoked.  A
> >>secondary problem is that the response sizes suddenly increase,
> >>potentially blowing the MTU limit.  This document describes a method
> >>that is basically CDS, but for the root key (or any other trust
> >>anchor).  Unlike the CDS record though, this record lives at a
> >>special name - by querying for this name, the recursive exposes its
> >>list of TAs to the auth server (signalling upstream) . This allows
> >>the TA maintai

Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

[Olafur Gudmundsson]

There is much simpler way.
Just add record to the rootzone that is only signed by the new key.
If resolver returns AD bit it has the new key.

All that is needed is to sign a Rrset for a long time and add it at to the
rootzone and make sure no ZSK signs it.

Olafur
On Jun 29, 2015 4:49 PM, "Warren Kumari"  wrote:

> Hi all,
>
> So, there is a project underway to roll the DNSSEC root key. There has
> been much written about this, including SAC063
> (https://www.icann.org/en/system/files/files/sac-063-en.pdf[0]), a
> DNSSEC Root KSK Rollover Plan Design Team, various consultations with
> the community, many presentations at DNS-OARCs, etc.
>
> One of the biggest impediments to actually performing the rollover is
> that some set of folk will not have performed RFC5011 style rollover,
> whether because their software doesn't support 5011, because they have
> statically configured a TA, because the bigger response makes them
> sad, whatever. The fact that we cannot tell who has only has the old
> key, and who has both makes the keyroll very scary - we cannot predict
> who, and how wide scale the outage will be when the old key is
> removed.
>
> I've written a draft that proposes a different way of performing root
> key rollover that exposes who all has which key - this allows one to
> know that 99.8% of resolvers have the new key, who has the old one,
> and who will break.
> It does this by encoding the current set of TAs that the resolver has
> into a query, and using that to fetch the new keys. By watching
> queries at the root one can see the population of people with each TA,
> and watch that change over time. This was written for root key roll,
> but is applicable to any TA in the tree.
>
>
> I'd appreciate any feedback, the draft announcment is here:
> Name:   draft-wkumari-dnsop-trust-management
> Revision:   00
> Title:  Simplified Updates of DNS Security (DNSSEC) Trust Anchors
> Document date:  2015-06-29
> Group:  Individual Submission
> Pages:  8
> URL:
>
> https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/
> Htmlized:
> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00
>
>
> Abstract:
>This document describes a simple means for automated updating of
>DNSSEC trust anchors.  This mechanism allows the trust anchor
>maintainer to monitor the progress of the migration to the new trust
>anchor, and so predict the effect before decommissioning the existing
>trust anchor.
>
>It is primarily aimed at the root DNSSEC trust anchor, but should be
>applicable to trust anchors elsewhere in the DNS as well.
>
>[ Ed note - informal summary: One of the big issues with rolling the
>root key is that it is unclear who all is using RFC5011, who all has
>successfully fetched and installed the new key, and, most
>importantly, who all will die when the old key is revoked.  A
>secondary problem is that the response sizes suddenly increase,
>potentially blowing the MTU limit.  This document describes a method
>that is basically CDS, but for the root key (or any other trust
>anchor).  Unlike the CDS record though, this record lives at a
>special name - by querying for this name, the recursive exposes its
>list of TAs to the auth server (signalling upstream) . This allows
>the TA maintainer to predict how many, and who all will break.  It
>also allows the pre-publication of a key before using it, and so
>avoids the need to double response sizes...]
>
>[ Ed note: Text inside square brackets ([]) is additional background
>information, answers to frequently asked questions, general musings,
>etc.  They will be removed before publication.]
>
>[ This document is being collaborated on in Github at:
>https://github.com/wkumari/draft-wkumari-dnsop-trust-management.  The
>most recent version of the document, open issues, etc should all be
>available here.  The authors (gratefully) accept pull requests ]
>
>
>
> W
> [0]: Full disclosure: Author.
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-dnssec-roadblock-avoidance & support for local DNS views

[Olafur Gudmundsson]

Petr, sorry for delayed response, 

> On Feb 11, 2015, at 11:24 AM, Petr Spacek  wrote:
> 
> Hello dnsop,
> 
> draft-ietf-dnsop-dnssec-roadblock-avoidance is a nice idea in general but
> current version of "Roadblock Avoidance", section 5, version 01 has a
> significant drawback:
> 
>   Else if the resolver is labeled "Not a DNS Resolver" or
>  "Non-DNSSEC capable"
> 
>   Mark it as unusable and try next resolver
> 
> This effectively cuts off the client from local DNS view, which can
> effectively mean that internal resources on the network will be unavailable.
> 
You are correct we ignore split-DNS completely and that is on purpose.  It is 
unfortunately badly/not defined. 
But in your case there is in many cases simple solution “when running SPLIT-DNS 
make sure internal DNSSEC resolvers are DNSSEC capable and sign inside and 
outside if there is overlap in names.” 


> On public networks it may be perfectly fine to sacrifice local names to get
> DNSSEC validation.
> 
> However, on internal networks it is a big problem for practical usability of
> the system. I personally experienced this when using dnssec-trigger on
> networks where DHCP does not send complete list of local DNS domains. (Also, I
> have to say that the fact that dnssec-trigger disables DNSSEC validation for
> list of domains supplied DHCP effectively takes all the security away …)

This is side effect of the badly specified nature of SPLIT-DNS, 

> 
> Generally my concern is about practical usability of the proposed solution:
> Imagine that I'm road-warrior/consultant who is traveling all the time and is
> working for different companies. When I arrive to a customer I should not need
> to spend time fiddling with network configuration to get connected to local
> network before I can start working on customer's problem.
> 
> 
> Few guys in Red Hat proposed "hacky but almost-reliable automatic" way how to
> improve usability without sacrificing security.
> 
> 
> Disclaimer
> ==
> Method described below is covered by US patent application named "USING DOMAIN
> NAME SYSTEM SECURITY EXTENSIONS IN A MIXED-MODE ENVIRONMENT".
> 
> See Red Hat, Inc. Statement of Position and Our Promise on Software Patents:
> http://www.redhat.com/legal/patent_policy.html
> 
> 
I reject the below text as I do not want any IPR on anything in this 
informational document. 

Olafur

> The Hack
> 
> Fundamental assumption:
> Internal & external DNS view are both signed with the same keys or both
> unsigned. This assumption allows the method to work without explicit
> configuration on every client and removes dependency on reliable/secure
> network-detection logic.
> 
> 
> The main idea can re-phrased as amendment to section 5 of the draft:
> 
>   The general fallback approach can be described by the following
>   sequence:
> 
>   If the resolver is labeled as "Validator" or "DNSSEC aware"
>   Send query through this resolver and perform local
>   validation on the results.
> 
>   If validation fails, try the next resolver
> 
>   Else if the resolver is labeled "Not a DNS Resolver" or
>  "Non-DNSSEC capable"
>   Mark it as unusable and try next resolver
> 
> --- amended text begins here ---
> 
>   Else if no more resolvers are configured and if direct queries
>   are supported
>  1. Try iterating from Root
> 
>  2. If the answer is SECURE/BOGUS
>Return the result of iteration.
> 
>  3. If the answer is INSECURE
>Re-query "Non-DNSSEC capable" servers and get answer
>from "Non-DNSSEC capable" servers.
>Set AD bit to 0 before returning the answer to client.
> 
>   Else return a useful error code
> 
> 
> This method covers DNS split-views with internal unsigned views pretty
> nicely as long as the fundamental assumption holds. (Naturally it works only
> for cases where fallback to iteration is possible.)
> 
> We wanted to write Unbound module for this but it is harder than it seems.
> (Proof-of-concept with stand-alone DNS proxy works fine, we have problem with
> Unbound module architecture - not with the described method.)
> 
> Feel free to incorporate the idea to the draft if you wish.
> 
> -- 
> Petr Spacek  @  Red Hat
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RFC-3658 errata (minor)

[Olafur Gudmundsson]

> On Jun 7, 2015, at 6:22 PM, Paul Wouters  wrote:
> 
> 
> I was writing some hashing to create DS records code when I noticed
> in the RFC-3658  https://tools.ietf.org/html/rfc3658#section-2.4
> 
Paul 
I would say no as document is obsoleted by newer documents 
Obsoleted by: 4033 , 4034 
, 4035 
 PROPOSED STANDARD
Updated by: 3755   



If you need to file errata file it against 4034 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-root-loopback

[Olafur Gudmundsson]

> On Jun 4, 2015, at 7:48 PM, Paul Hoffman  wrote:
> 
> On Jun 4, 2015, at 4:05 PM, Tony Finch  wrote:
>> Are there any implementations of this draft?
> 
> Assuming you mean "is anyone deploying the ideas in this draft, particularly 
> those in Appendix B", that would be good information for the authors to have.
> 
>> If resolvers are encouraged to use NSEC records to synthesize NXDOMAIN
>> responses, would there still be any point to this draft?
> 
> Yes. No one has written up a document on using NSEC records to synthesize 
> NXDOMAIN for the root, and if they do, there will certainly be operational 
> considerations for that that are different than the operational 
> considerations for this draft. I'm not saying one would be better than the 
> other, but I suspect that the operational description of this draft would be 
> easier for an operator to understand.
> 
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

Paul, 
I consider this a good start in the discussion of NSEC aggressive use
http://www.ietf.org/id/draft-fujiwara-dnsop-nsec-aggressiveuse-00.txt 


Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[Olafur Gudmundsson]

Hi

I have reviewed this document, and support its publication as is.

Olafur


On Mon, Apr 27, 2015 at 11:58 PM, Tim Wicinski  wrote:

> Greetings,
>
> This starts a Working Group Last Call for Adoption for
> draft-ietf-dnsop-negative-trust-anchors
>
> Current versions of the draft is available here:
>
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
>
> https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04
>
>
> Please review the draft and offer relevant comments. Also, if someone
> feels the document is *not* ready for publication, please speak out with
> your reasons
>
> This starts a two week Working Group Last Call process, and ends on May
> 11th, 2015.
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

[Olafur Gudmundsson]

> On Mar 25, 2015, at 8:33 AM, Mark Andrews  wrote:
> 
> 
> In message , Tony 
> Finch writes:
>> John Dickinson  wrote:
>>> 
>>> I support this draft. One thing that jumped out to me was there appears
>>> to be no mention of NSEC/NSEC3 chain management when adding/removing
>>> records.
>> 
>> Even if the slave is able to work out what the necessary changes are to
>> the NSEC chain, the master is still going to have to send the new RRSIG
>> records. So I don't think there would be much saving from adding special
>> cases for NSEC and NSEC3.
> 
> NSEC is a singleton record.  Adding a new one indicates a implicit
> deletion of any other NSEC record at that name.  This does not
> indicate that all NSEC deletes can be removed from the IXFR stream,
> when constructing a MIXFR stream, only those with a matching addition.
> 
> Adding a NSEC3 record causes a implicit deletion of the existing
> NSEC3 with matching parameters.  This does not indicate that all
> NSEC3 deletes can be remove from the IXFR stream, when constructing
> a MIXFR stream, only those with a matching addition.


The only cases where MIXFR can safe in the case of NSEC3 are
a) add of updated NSEC3 with same owner name as singleton the old one is deleted
b) replacement of NSEC3PARM implies that the NSEC3’s matching old NSEC3PARAM 
can be deleted. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

[Olafur Gudmundsson]

> On Mar 18, 2015, at 11:55 AM, Paul Vixie  wrote:
> 
> we need a document that says "If you don't want to answer ANY, here's how to 
> do it interoperably." we don't need to say "you should not answer ANY", but 
> we do need to say "if you want to query for ANY, here's what might happen." 
> that, sir, is a killing. we are killing ANY. there's no pretense.

This is exactly what my goal is tell the upstream the type ANY will not be 
answered. 
I do not care if that is RCODE=X or Rcode=0 + NULL record in answer section or 
something else. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-acl-metaqueries-00.txt

[Olafur Gudmundsson]

updated based on feedback from the mailing list
File name changed at WG secretary request

 Olafur (for editors)

-- Forwarded message --
From: 
Date: Mon, Mar 9, 2015 at 6:25 PM
Subject: New Version Notification for
draft-ogud-dnsop-acl-metaqueries-00.txt
To: Olafur Gudmundsson , Joe Abley ,
Marek Majkowski 



A new version of I-D, draft-ogud-dnsop-acl-metaqueries-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:   draft-ogud-dnsop-acl-metaqueries
Revision:   00
Title:  DNS Meta-Queries resticted.
Document date:  2015-03-09
Group:  Individual Submission
Pages:  6
URL:
http://www.ietf.org/internet-drafts/draft-ogud-dnsop-acl-metaqueries-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ogud-dnsop-acl-metaqueries/
Htmlized:
http://tools.ietf.org/html/draft-ogud-dnsop-acl-metaqueries-00


Abstract:
   Some DNS types have special meaning and are classified as meta
   queries, this includes ANY, AXFR, IXFR.  These queries frequently
   return larger answers than queries for other types.

   This document defines a standard way for Authoritative-Only servers
   how to refuse to serve these and other similar queries, with the
   expectation that resolvers honor that, by not asking followup
   queries.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] More work for DNSOP :-)

[Olafur Gudmundsson]

Happy to pick a less offensive file name :-) will discuss with co-editors (Joe 
Abley is also helping)
 
Olafur
-Original Message-
From: "Paul Hoffman" 
Sent: Monday, 9 March, 2015 11:51
To: "Olafur Gudmundsson" 
Cc: "IETF DNSOP WG" 
Subject: Re: [DNSOP] More work for DNSOP :-)



On Mar 8, 2015, at 6:23 PM, Olafur Gudmundsson  wrote:
> There is a new version in the works, expect it late tomorrow (monday) 

There are questions about whether NOTIMP is the correct response. Given that, 
please consider starting a new -00 without "notimp" in the filename. That will 
help make it clear that you are open to the various changes that might come in 
the WG. Proposal: draft-whoever-metarr-acl-00.

--Paul Hoffman___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] More work for DNSOP :-)

[Olafur Gudmundsson]

There is a new version in the works, expect it late tomorrow (monday) 

It does not outlaw ANY per say, just says limit it  to trusted parties. 
I tries to define that resolver treat NOTIMP as long term signal that resolver 
should keep track of and not retry. 
It says ignore RD=1 on meta queries. 
It says do not upstream Meta queries 

It applies to all meta types, including RRSIG. 

Olafur

> On Mar 7, 2015, at 4:36 PM, Tony Finch  wrote:
> 
> 
>> On 6 Mar 2015, at 19:37, Bob Harold  wrote:
>> 
>> I would be concerned about blocking RD=0 (non-recursive).  That would 
>> prevent me from check to be sure an entry was NOT in the cache, in some DNS 
>> server my clients are using. 
> 
> I thought cache probing was considered an unfortunate information leak :-)
> 
> You can block rd=0 in BIND using a view with a match-recursive-only 
> directive. So I think the only missing ACL is for ANY (and the similar RRSIG).
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "DNS resolver should not use 'ANY' to get cached records for TTL" (bugzilla)

[Olafur Gudmundsson]

Paul,

Marek and I agree with you to expand the scope to include all meta types at
Authoratitive servers.

And address your other points as well, thanks for the support.
Olafur
 On Mar 6, 2015 11:28 PM, "Paul Vixie"  wrote:

> this made the news tonight:
>
> > Tracking Flags:
> > tracking-firefox36:+
> > status-firefox36:fixed
> > tracking-firefox37:+
> > status-firefox37:fixed
> > tracking-firefox38:+
> > status-firefox38:fixed
> > tracking-firefox39:+
> > status-firefox39:fixed
> > relnote-firefox:36+
>
>
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1093983)
>
> notes--
>
> 1. i support the adoption and progression of olafur's draft, regardless
> of mozilla's retraction of the bad logic in tonight's firefox release.
>
> 2. it's not going to change the amplification/reflection problem and
> should not mention that problem at all.
>
> 3. it should be renamed to "restricting DNS meta-data queries".
>
> 4. it should be expanded to include RD=0 against recursion-only servers,
> IXFR/AXFR, and anything else in the DNS protocol that would be useful
> for both diagnostics and surveillance.
>
> 5. non-response to these queries should be designed to avoid re-query
> storms from common initiators.
>
> i agree to review and contribute.
>
> vixie
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Fwd: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt

[Olafur Gudmundsson]

As promised

Olafur

-- Forwarded message --
From: 
Date: Fri, Mar 6, 2015 at 12:27 PM
Subject: New Version Notification for draft-ogud-dnsop-any-notimp-00.txt
To: Olafur Gudmundsson , Marek Majkowski <
ma...@cloudflare.com>



A new version of I-D, draft-ogud-dnsop-any-notimp-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:   draft-ogud-dnsop-any-notimp
Revision:   00
Title:  Standard way for Authoratitive DNS servers to refuse ANY
query
Document date:  2015-03-06
Group:  Individual Submission
Pages:  3
URL:
http://www.ietf.org/internet-drafts/draft-ogud-dnsop-any-notimp-00.txt
Status:
https://datatracker.ietf.org/doc/draft-ogud-dnsop-any-notimp/
Htmlized:   http://tools.ietf.org/html/draft-ogud-dnsop-any-notimp-00


Abstract:
   DNS ANY query is widely abused for reflection attacks.  This feature
   was designed to aid in debugging.  As there is no good reason for
   applications to ever issue an ANY query this document codifies how an
   authoritative server can reject such queries.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Definitions of foo-centric

[Olafur Gudmundsson]

> On Feb 25, 2015, at 4:14 AM, Ray Bellis  wrote:
> 
> 
>> On 25 Feb 2015, at 08:58, Stephane Bortzmeyer  wrote:
>> 
>> I'm not sure they appear in a RFC. They are commonly used (see for
>> instance ) when
>> discussing resolvers' behaviour.
>> 
>> Let me suggest:
>> 
>> Child-centric resolver: a DNS resolver which will replace, in its
>> memory, the NS RRset and glue records obtained from the parent, by
>> data from the authoritative servers of the zone they belong to. This
>> is the proper behaviour.
>> 
>> Parent-centric resolver: a DNS resolver which will keep in memory the
>> NS RRset and glue records obtained from the parent, despite the fact
>> it is non-authoritative. This is bad practice.
> 
> This is my understanding of the terms too.
> 
> However in the child-centric case this can cause problems when the NS set 
> held by the parent changes (i.e. the zone is redelegated) but the NS set in 
> the old set of servers isn't also updated.  Such a child-centric resolver may 
> completely fail to notice the redelegation.
> 
> Olafur has done a lot of work categorising this behaviour - the above is 
> similar to slide 4 in his deck from your link, but doesn't even require 
> DNSSEC for it to be a problem.


What I did was to look at what states resolvers are in regards to which set of 
NS records they fetch records from, I did most of this work while looking at 
DNS operator change/Redelegation. 
I never got around publishing the final results so here they are in short:
Resolver types: 
   Parent Centric: will only use NS from parent zone 
   Strict Child Centric: will always fetch NS from one of the servers listed in 
parent NS set 
   Accidental Child Centric: will overwrite parent NS with child one if it is 
included in answer (i.e. in Auth section) 
   Sticky Child Centric: will reset the TTL of NS set every time it sees NS in 
Auth Section of answer from child zone 

Before “Minimal answers” became popular I did not realize the difference 
between Strict and Accidental Child Centric resolvers. 
Sticky resolvers are only a real problem in when three conditions are met,  
 - domain has been relegated,
 - Old operator keep answering for the domain.
 - Old operator includes NS in Authority section. 

Notes: 
 - The only times the resolver Centricity is an issue is when there is a 
difference in NS sets at parent and child. 
 - In most cases Sticky CC Resolver is also a Accidental CC resolver,  
 - In many cases Accidental Child Centric resolvers act like Parent Centric 
because the name severs operate in minimal-answer mode. 
 
  Olafur 
ps: Trivia question why is Parent Centric never sticky? 



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Debugging DNSSEC SERVFAILs on resolver side

[Olafur Gudmundsson]

Hi Petr, 
This has been discussed in the past a few times and died as people could not 
agree on what the format of the record was going to be, if it was going to be 
useful for human or computers 
etc. 

The first idea was probably presented in 1987 by Robert Watson and myself 
https://tools.ietf.org/html/draft-watson-dns-error-00

Reading that draft over again the only thing I would change is to 
add a 16 bit field that was an index to a registry of error codes. 

I think something like this is needed and we have a much better handle of
what kind of errors we are going to see. 

Olafur



> On Feb 11, 2015, at 9:18 AM, Petr Spacek  wrote:
> 
> Hello dnsop,
> 
> while implementing DNSSEC validation into Fedora/RHEL distributions we face
> problems with debugging SERVFAILs seen by stub resolvers because different
> causes of SERVFAILs are indistinguishable.
> 
> Even in cases where we have access to server logs (e.g. because the validating
> resolver runs on the same machine as the stub resolver) we have to grep
> validator logs which makes the whole system validator-dependent, which is
> undesirable.
> 
> Wild idea: Could it be solved by adding more information to SERVFAIL answer?
> 
> Is there a standard which forbids adding a meta-RRs to SERVFAIL answer?
> 
> How likely will it break something? What about middleboxes?
> 
> 
> I envision meta-RR with information like:
> - signature will be valid in xxx seconds (validator's clock is in past)
> - signature expired xxx seconds ago (validator's clock is in future)
> - signature expected but was not received (perceived downgrade attack)
> - locally generated SERVFAIL y/n
> - unspecified (upstream server did not return detailed information)
> - forwarder IP address/ID (when applicable)
> etc.
> 
> dnssec-roadblock-avoidance draft contains interesting list of problems which
> could be reported in some way.
> 
> My hope is to get enough information to distinguish cases where there is a
> problem with validator (clock out of sync, wrong keys etc.) or upstream cache
> used by validator (downgrade attack/missing EDNS suport) etc. to make
> debugging easier.
> 
> 
> Maybe this was discussed in the past and rejected, in that case please refer
> me back to archives so I can understand the reasoning.
> 
> Thank you for your time!

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Updating the DNS Registration Model to Keep Pace with Today’s Internet

[Olafur Gudmundsson]

> On Feb 5, 2015, at 11:58 AM, Stephane Bortzmeyer  wrote:
> 
> "CloudFlare is advocating to gain the ability to update NS records for
> our customers and address records associated with them using automated
> channels. Our goal is to be able to add and remove nameservers from
> customer domains without the customer being involved." Possible work
> for this working group?
> 
> https://blog.cloudflare.com/updating-the-dns-registration-model-to-keep-pace-with-todays-internet/
> 

Thanks Stephane, 

Possible work in DNSOP or as this may involve registries and registers
a new single topic WG might be the way to go. 
It is, almost, too too late to ask for a BoF in Dallas, but if DNSOP can spend 
some  time on
this topic and what it involves that would be great. IMHO

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New version of the DNS terminology draft

[Olafur Gudmundsson]

> On Feb 4, 2015, at 11:09 AM, Stephane Bortzmeyer  wrote:
> 
> On Mon, Jan 19, 2015 at 02:16:47PM -0800,
> Paul Hoffman  wrote 
> a message of 17 lines which said:
> 
>> Greetings again. Andrew, Kazunori, and I have done a massive
>> revision on the DNS terminology draft based on the input we got on
>> the -00. We're sure we have further to go, but we wanted people to
>> look over the new version and give feedback.
> 
> I find the definition of Forwarder still confused. I suggest to
> rewrite it as:
> 
>   DNS forwarder -- When a first resolver receives a DNS query (and
>   cannot directly answers it), then sends the
>   query to a second recursive resolver, instead of directly to the
>   authoritative name servers, this second resolver is called a
>   forwarder. Section 1
>   of RFC 2308 describes a forwarder as "a nameserver used to resolve queries
>   instead of directly using the authoritative nameserver chain".  RFC
>   further says "The forwarder typically either has better access to
>   the internet, or maintains a bigger cache which may be shared amongst
>   many resolvers.”
> 

I do not think this helps. 
Forwarding is not always a capacity/access issue but policy decision to improve
site resolution cache hit ratio among a farm of resolvers.
Forwarding resolver by policy does not do recursion but requests upstream to 
perform recursion. 

Olafur





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] RSA/SHA-1 to >= RSA/SHA-256 ?

[Olafur Gudmundsson]

> On Jan 16, 2015, at 5:13 AM, Marco Davids (SIDN)  wrote:
> 
> Hi,
> 
> SHA-1 for TLS-certificates is considered insufficient nowadays.
> 
> But what about the usage of RSA/SHA-1 in DNSSEC ?
> 
> Should TLD's such as .se make preparations for an algorithm roll-over?
> 
> --
> Marco
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

Yes,
 but they should not restrict themselves to just RSA-xxx as a rollover target 
:-)

ECDSA is available and is a good alternative if you want stronger zone signing 
signatures than 1024 bits. 
Hopefully we will have a modern ECC signature algorithm available in few years. 

  Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] MIXFR: Smaller IXFR in the DNSSEC case

[Olafur Gudmundsson]

> On Jan 15, 2015, at 1:33 PM, 神明達哉  wrote:
> 
Jinmei,  
thank you for your good comments. 

> At Thu, 15 Jan 2015 11:13:10 +0100,
> Matthijs Mekking  wrote:
> 
>> IXFR with DNSSEC is suddenly not so small anymore. Do you recognize
>> this? Olafur and I have some ideas on keeping those zone transfers
>> small. Your feedback is appreciated.
>> 
>>  http://www.ietf.org/internet-drafts/draft-mekking-mixfr-01.txt
> 
> I see the motivation, and the proposed approach of MIXFR may make
> sense.  But, just like for any kind of optimization ideas, I would
> wonder whether this could be a premature one.  Do you have any
> measurement of the effect of this idea?

This is a real good point, I would hope we (or others) have some 
information on that before we standardize, right now this just an idea to 
discuss. 
The quick back of the envelope calculations say 30-45% for DNSSEC signed zones, 
that are just
being resigned. The milage on other operations my differ. 

This begs the question what is the best way to measure? 

> On the draft text (also related to this higher level point):
> 
>   The goal of this proposal is to allow small changes to be
>   communicated over UDP, and remove as much redundant information from
>   the zone transfer as possible.
> 
> We still need to send new RRSIGs, and since the main concern is the
> size of them (whether they are to be removed or added), I guess
> sending a non-negligible number of RRSIGs could easily require TCP,
> even if we can omit a half of them.  So I'm not sure how often we can
> avoid falling back to TCP (M)IXFR thanks to this in practice.  Again,
> some actual measurement or at least a quantitative analysis may help.
> 

not sending the OLD RRsig’s is a big savings on its own, in particular when 
people
use large RSA keys. Close to 50% when all you are just refreshing a signature 
on a one or two RRsets. 

> Regarding Section 5 (IXFR Gone Wild: Even more optimized transfers):
> if we go this far, I wonder whether we might just use generic and more
> efficient compression and exchange compressed data.
> 
One of the oldest ideas on that was from Andreas Gustafsson was to wrap
XFR transmission inside compressed transmission. 
But the biggest reason not to do compression is that RRSIG rdata is not 
compressible. 

I have a much more radical zone transfer proposal in the works that is over 
persistent TCP
connections and that is ripe for secured and compressed transmission. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] identifying an identifier's name space was Re: draft-grothoff-iesg-special-use-p2p-names-03

[Olafur Gudmundsson]

> On Jan 7, 2015, at 8:59 AM, Tony Finch  wrote:
> 
> Andrew Sullivan  wrote:
>> 
>> In the other case, it's an indication that the _namespace_ is
>> different: that if you resolve that name on the Internet without
>> special enabled software, you aren't getting the service you desired,
>> regardless of the protocol you happen to be using.  In theory, these
>> kinds of applications actually ought to want a new DNS class; but
>> since classes are broken (because of CNAMEs/DNAMEs and also because of
>> the facts of deployed infrastructure), in-band signalling in the
>> domain name is the preferred alternative.
> 
> Classes are the wrong thing for this purpose, because I don't think these
> are separate namespaces - they are different resolution mechanisms for
> particular parts of the same hostname namespace. There already examples of
> similar splits, e.g. mDNS using .local and (to some extent) /etc/hosts
> (though that covers the whole namespace rather than a particular part).
> 

Tony
I disagree, in my mind different resolution mechanism implies a different 
namespace. 
I think this mechanism of identifying the lookup mechanism by the last byte in 
the
name is BAD. 
I wrote this up a long time ago, and still think we should be encouraging 
new namespaces to address their lookups via BETTER functions rather than 
patching DNS resolution libraries. 


> You can't use classses for this purpose because applications that resolve
> hostnames do not have a way to specify a name's class. But it is perfectly
> feasible to install a new system resolver module which changes the way
> part of the namespace works without requiring changes to any of the apps.

Strictly speaking new classes do not have a resolution mechanism defined, thus
Andrew is right, when one defines the use of a new class new lookup mechanism 
can be
part of that definition. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] "Optimization" in draft-ietf-dnsop-qname-minimisation

[Olafur Gudmundsson]

> On Jan 5, 2015, at 12:04 PM, Rubens Kuhl  wrote:
> 
>> 
>> Em 05/01/2015, à(s) 14:33:000, Paul Hoffman  escreveu:
>> 
>> On Jan 4, 2015, at 12:13 PM, David Conrad  wrote:
> "Sending the full qname to the authoritative name server is a
> tradition, not a protocol requirment."
> 
> I'd actually call it an optimization, not a tradition.
 
 In many cases, sending the full qname degrades performance so I would
 not call it an optimization.
>>> 
>>> If there are cases in which sending the full QNAME degrades performance, it 
>>> might be useful to document them in the draft (off the top of my head, I 
>>> can't imagine non-broken cases where that would be true, but I haven't 
>>> thought about it too long).
>>> 
>>> The reason I'd call it an optimization is that in the case where a server 
>>> is authoritative for multiple layers of hierarchy, sending the full QNAME 
>>> allows that server to bypass the referrals for all intermediate layers of 
>>> hierarchy and simply respond to the depth it knows.  If QNAME minimization 
>>> is applied, that shortcut isn't possible.
>> 
>> +1 to David's comment. I have always heard that sending the full name was an 
>> optimization for authoritative severs that spanned more than one level, and 
>> that such servers were common in "the early days". It is worth pointing this 
>> out in this draft, and to also say that that situation may be much less 
>> common now than it was in antiquity.
> 
> 
> I can point to 25 million domain names that currently benefit from such 
> optimization in .br and .uk alone, probably more if you add other TLDs that 
> register on the 3rd level. 
> 

Of those the ones using DNSSEC will suffer due to the difficulty of getting 
DNSKEY and DS records for the “skipped” delegations. 

Olafur

> 
> Rubens
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org 
> https://www.ietf.org/mailman/listinfo/dnsop 
> 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-child-syncronization-04.txt

[Olafur Gudmundsson]

> On Dec 1, 2014, at 4:31 PM, Wes Hardaker  wrote:
> 
> 神明達哉  writes:
> 
>> From a quick check some of them still seem to be open.  And, as far as
>> I remember there has been no response to my comments, so I'm not sure
>> if they were considered/discussed but dismissed or simply overlooked.
> 
> First, apologies again for missing these comments during last call.
> Multiple people missed it for some reason.
> 
> Here's a summary of your comments and what I've done to address them.
> My comments/actions are prefixed by "WJH:"
> 
> 
> 
> * DONE Section 1 (introduction), the first paragraph:
> 
>This document specifies how a child zone in the DNS ([RFC1034],
>[RFC1035]) can publish a record to indicate to a parental agent that
>it may copy and process certain records from the child zone.  The
>existence of and value change of the record may be monitored by a
>parental agent and acted on as appropriate.
> 
>  I vaguely remember someone already pointed this out, but anyway: I'm
>  afraid the term "parental agent" is not so widely shared that we can
>  safely use it without first giving the definition.  One easy way to
>  address this would be to add a forward reference to Section 1.1 at
>  the first occurrence of the term.  If possible, it would be even
>  nicer if we can avoid using this term until the definition is given
>  in Section 1.1.  For the same reason, it would be safer to avoid
>  using it in the abstract.
> 
>  WJH: I've put in a forward reference in the introduction.  I'm
>  not worried about the abstract as much, as any serious reader
>  will likely read on anyway.  And the point of the term was to
>  make sure we don't say something confusing like "parent" when
>  there is more than one.  There is no standard term, and the best
>  that the WG came up with (thanks to Olafur) is the new term.
>  But a forward reference in the introduction definitely makes
>  sense.
> 
See RFC7344 as definition of Parental Agent


>  This document specifies how a child zone in the DNS ([RFC1034],
>  -   [RFC1035]) can publish a record to indicate to a parental agent that
>  -   it can copy and process certain records from the child zone.  The
>  -   existence of the record and any change in its value can be monitored
>  -   by a parental agent and acted on depending on local policy.
>  +   [RFC1035]) can publish a record to indicate to a parental agent (see
>  +   section Section 2 for a definition of "parental agent") that it can
>  +   copy and process certain records from the child zone.  The existence
>  +   of the record and any change in its value can be monitored by a
>  +   parental agent and acted on depending on local policy.
> 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption draft-livingood-dnsop-negative-trust-anchors

[Olafur Gudmundsson]

> On Nov 26, 2014, at 10:58 AM, Tim Wicinski  wrote:
> 
> 
> This starts a Call for Adoption for 
> draft-livingood-dnsop-negative-trust-anchors. There was much discussion at 
> the last meeting about adopting this draft and working on it.
> 
> The draft is available here:
>   
> https://datatracker.ietf.org/doc/draft-livingood-dnsop-negative-trust-anchors/
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP,  and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.
> 
> 
> This call for adoption ends Wednesday, December 10th, 2014

This is a unique document that addresses operational realities and tries hard 
to do something that protocol purists 
do not like in a sane manner, if we do not document how to do this some real 
bad ideas will spread. 
The idea is the “permissive validator” i.e. validator that will set AD bit on 
every answer that validates
but ignores validation errors. 
I strongly support this document will review again

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Call for Adoption: draft-dickinson-dnsop-5966-bis

[Olafur Gudmundsson]

On Nov 14, 2014, at 2:04 PM, Tim Wicinski  wrote:

> 
> This starts a Call for Adoption for draft-dickinson-dnsop-5966-bis
> 
> The draft is available here:
>   https://datatracker.ietf.org/doc/draft-dickinson-dnsop-5966-bis/
> 
> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
> 
> Please also indicate if you are willing to contribute text, review, etc.

Strong support.
 will review and comment 
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On Nov 11, 2014, at 5:48 PM, Lee Howard  wrote:

> Many SSH servers (by default) reject connections from IP addresses without
> PTRs.
> This is stupid.
> 
> I heard applause during the WG meeting in response to these statements;
> sounded like consensus to me. I said I would check that consensus on list.
> 
> Thanks,
> Lee


Lee, 

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 system is running at 
high speed the delay in looking up addresses is just too long.
Thus I would say the usage case is “a log processing tool MAY do PTR lookups” 
the real information about addresses can be extracted from other sources as 
well like 
whois and geo-location data bases etc. 

The other usage case that I can think of is network debugging. 

Thus the real question in this case “what granularity in name is needed and 
when ?” 

Below is short list of of possible requirement based on the needs of these two 
“usage cases”

We all love having the names displayed by trace route for each hop ==> 
names of router interfaces are a SHOULD in my mind 

We all want big services to have PTR records, this web servers, mail servers, 
etc. 
Addresses that provide services SHOULD have a PTR record 

“End-user” addresses do not need a PTR record but could be simple wild card 
responses like “Customer.HNL.biz-ISP.net” 
as none is complaining about 
123.136.133.31.in-addr.arpa. 3600 INPTR dhcp-887b.meeting.ietf.org.
or 
9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15 IN 
PTR s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.meeting.ietf.org.


This message  raised some questions
On Nov 11, 2014, at 5:29 PM, George Michaelson  wrote:

> I'll take a dollar for every query in PTR we take at the ipv4  /8 and Ipv6 
> /12 level. Thats somewhere around 170,000/sec.
> 
> Luckily, you'll all stop before I have the entire western economy in my 
> pocket, but thats ok. I'll take the cents.. I'll take the millicents... 
> 
> Seriously: the volume of query is not small. It may be pointless but by golly 
> its popular.
> 
> What do people do with it? I have no idea. But as long as people want to 
> query, the RIR are happy to anchor the domains.
> 

That to me indicates that people use log post processing all the time and 
Intrusion Detection Systems are doing PTR lookups
by policy 
For IDS are their expectations any different than log processors?
and if IDS’s are taking decisions based on the content of PTR records what 
granularity do they need? 

  Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] Automating Provision of DS Records

[Olafur Gudmundsson]

Hi,
as I mentioned at the mike: 

For those at the IETF-91 I will be hosting a Beach Bof for people that are
interested in working on creating an automated solution to this problem in
as short time as possible.

Send me an email if you are interested
Time: 15:00 @ Thursday
Loaction: TBD

Olafur


Call to Action: Automating Provision of DS Records to DNS Parents

Background

The DNS ecosystem is complex and problematic. Because there are many
relationships between domains and their “DNS parent”, and these
relationships are often convoluted, updating information for the parent is
difficult. This blog post will explore this issue in an effort to highlight
the need for an automated mechanism to inject DNS delegation information
into Parent DNS.

To get an idea of the convoluted nature of the DNS ecosystem, it will be
helpful to start with an example: If we were to sign the domain “example.com
”, the parent of this domain is “com”. However, .com is what’s known as a
“shared registration delegating domain following the ICANN rules”. This
means that the holder or owner of “example.com”, known as Registrant,
purchased or leased the domain from a Registrar or a Reseller authorized to
market domain names in .com.

After the Registrant pays for the domain, the Registrar updates a common
database called a Registry. The Registry holds information about the
Registrant, Registrar, and DNS servers for the domain. This information is
kept in a database operated by the Registry Operator. Registry Operators
also operate (or contract out) the DNS servers that list the registered
domains.

In most cases, the Registrant has a single account with the Registrar for
all its domains. However, there are three “handles” listed in the account:
Registrant, Admin, and Tech. And there are different ways that DNS for the
domain is handled:


   -

   The DNS can be handled by the Registrant
   -

   The Registrar can operate DNS (This is common when the domain is
   registered and operations are then moved.)
   -

   The Registrant can outsource the operation to a company like CloudFlare


For the three different kinds of DNS operators listed above, the difficulty
of changing information in the parent differs greatly. For the Registrant,
the process is fairly simple: they will need to log into their account and
change the information manually. Registrars can simply inject changes via
the programmatic interface they use to update the Registry. In the case of
third party operator like CloudFlare, it becomes a bit more difficult.
Third party operators need the Registrant to either hand over access to the
Registration account, or ask Registrant to pass information on---both of
those options have many potential problems.

To make matters worse, in many cases the third party operator has no
information on who the entity acting as a registrar for the domain is, or
how to contact them. Even if the DNS operator knows about the registrar, it
may not have any authority to make changes.

CloudFlare currently operates between 1-2 Million DNS domains for its
customers as a third party DNS operator. These registrations are in over
400+ TLD’s, and in unknown number of sub-delegation domains like “se.com”.
In only a few cases do we have access to domain registration accounts
because we are treated as unknown entity by Registrars and Resellers. When
we want DNS information changed, we need the Registrant to relay that
information, and the only time an registrant is motivated to log into his
or her registration account on our behalf is when we become the DNS
operator, or when DNS operation is moved away from us.

Our Goal: An Automated Solution to Update DNS Leveraging DNSSEC.

We would like to create a system where CloudFlare, and any other third
party DNS operators, can update the delegation DNS information in the
parent domains in a 100% automated manner. In the current registrations
system, we can, in theory, find out who the Registrar is via a WHOIS
query.  But, in many cases, the WHOIS query fails, or the information from
that query is not relevant. It might only return the name of Registrar,
Address of registrar, phone number, or even just a email address.

We are looking for ways to discover the correct entity that needs to be
contacted to insert the change into parent zone, or find out that there is
no such capability. In order to make this happen wwe want to leverage
RFC7344  and DANE like
technologies to build a solution that
is easy to manage, easy to operate, and is secure.

Path forward: What are the Missing Pieces?

There are three different problems that need to be addressed:


   1.

   Protocols for expressing to “parent representative/agent” what needs to
   be changed for a specific domain
   2.

   Protocols for finding the “Parent agent” delegation automation server,
   i.e., to be able to send message via the protocol developed for a to the
   appropriate party

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

[Olafur Gudmundsson]

On Oct 25, 2014, at 8:30 PM, Paul Ebersman  wrote:

> 
> dougb> It's not just a philosophical objection, it's an operational
> dougb> one. When DNSSEC fails for a domain there are 2 main
> dougb> reasons. Operator error, and an actual MITM or similar attack. If
> dougb> the operators of validating resolvers simply turn off validation
> dougb> for domains that should be validating but are not,* it kicks the
> dougb> door open for the exact problem that DNSSEC was designed to
> dougb> solve.
> 
> Have you actually read through the new draft? It specifically prohibits
> automatic installation of NTAs and says that you should have folks
> familiar with operating DNS servers making any decisions.
> 
> That isn't painless. It means that this skips past all 1st tier and gets
> to senior engineers. Don't know about you but I hate getting on-call
> problems caused by someone else that I have no direct way to fix but
> that my customers beat me for.
> 
> And that's way more expensive than standard help desk...
> 
> But it is a good way to make sure that this isn't a constant and knee
> jerk reaction but an operationally sane one.
> 
> dougb> The other problem is that this feature is only really useful in
> dougb> the DNSSEC ramp-up period. Sure, mistakes are more common now,
> dougb> software is immature, etc. etc. But if DNSSEC is successful, the
> dougb> software will get better (it already is a lot better than even a
> dougb> few years ago), and mistakes will be less common (both on an
> dougb> absolute, and on a percentage basis). But once you introduce a
> dougb> feature like this, you cannot remove it.
> 
> Sure. It will only be temporary/fast. Like rolling out IPv6. Or getting
> all the broken CPEs using old dnsmasq and being open resolvers. Or
> getting folks to roll out BCP38.
> 
> How long have we been trying to get folks to use DNSSEC? How far are we?
> And why do we keep insisting that only by painful and expensive
> suffering will we do it "correctly"?


Just to amply Paul’s point 
We want humans in the loop, I would love to see a twitter feed when ever 
Comcast does a Negative Trust Anchor. 
I know of a ISP that is/will deploy DNSSEC is what they call passive mode i.e. 
they will never give SERVFAIL but will not
set AD bit when validation fails. 
IMHO that is a great way to avoid service calls but ….. 

Right now most of the errors are caused by mistakes by the DNS operator or bugs 
in new tools. 
In not so distant future we will start seeing lots of DNSSEC Operator Change 
errors, i.e. a new DNS operator takes over the operation of the
domain (perfectly legitimate), the errors in this case may be long lived 
(someone forgot a step), or short lived (someone moved to fast or emergency 
procedure was invoked) 

   Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On Oct 7, 2014, at 12:04 AM, Tim Wicinski  wrote:

> 
> Please review this draft to see if you think it is suitable for adoption by 
> DNSOP, and comments to the list, clearly stating your view.
Done, will hold off sending edits to editor until after document adoption 
period. 
> 
> Please also indicate if you are willing to contribute text, review, etc.
Will do all above 
> 
> This call for adoption ends Monday 20-October-2014 at 23:59

Strong support for adoption. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

I’m getting confused about what the exact semantics of the proposed mechanisms 
are. 

Q1: The intent is that  ALIAS/ANAME/etc are a fallback rewrite operation if the 
name does not have the type asked for?

Q2: Is there a good  reason to restrict this to just the apex of a zone? 

Q3: Is there a  good reason to restrict the target of A* to be in-zone ? 

Q4: Is there a  good reason to restrict this to specific types? (Think about 
DANE cases with names like _443._tcp.@apex) 


On Sep 22, 2014, at 6:03 AM, Tony Finch  wrote:

> I can see roughly three ways this might be done, in order of increasing
> complexity...
> 
> (1) Master-only. The master observes an ANAME record at the apex of a zone
> it loads and uses it to periodically refresh the relevant records in the
> zone (as if you had a cron job running dig | magic | nsupdate).
> 
> Disadvantage: potentially lots of XFR traffic if the TTLs are low.

Disadvantage: if the target is a CNAME what does the master do? 
It either need to know ALL possible types that may exist or use NSECx record to 
determine what exists. 
Possible disadvantage: Master/master signer needs access to resolver to access 
out of zone-data. 

Further disadvantage: if the A* target is out of zone at a CDN then the answers 
the “master” gets back reflect its 
location. 

> 
> (2) Authority-only: All authority servers recognize ANAME records,
> PowerDNS style.
> 
> Disadvantage: all authority servers need DNSSEC private keys.

Not an absolute requirement, we could play type code tricks that allow master 
server to store 
A* target records as different types but servers know that to check for them if 
A* exists. 
Disadvantage: All authority serves supporting A* need to know about type 
translation and signers need to know to perform actions. 

> 
> (3) DNAME-style: Authority servers and resolvers recognize ANAME records.
> ANAME-aware servers (auth and rec) return the synthesized records for
> backwards compatibility, without signatures. For DNSSEC purposes the
> signed ANAME goes in the answer section and the original signed target
> goes in the additional section.
> 
> Disadvantages: forklift upgrade; DNSSEC codepoint rollover.
> 

You mean DNSKEY alg code points,? 
We only have 5 popular algorithms so that is not a big deal?

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Olafur Gudmundsson]

On Jul 18, 2014, at 10:52 AM, John Levine  wrote:

>> Many years ago Joe Abley and I suggested to create a special name for 
>> exactly this purpose
>> a name that was guaranteed to never exist in the DNS thus the first lookup 
>> would always return NXDOMAIN thus the A+ lookups would never take place. 
>> http://tools.ietf.org/html/draft-jabley-sink-arpa-03
> 
> While I don't think it's relevant for this application, isn't that
> what RFC 6761 defines "invalid" to be?
> 
> R's,
> John


John,

I think it would be great to have this document use “no-mail.invalid.” as the 
domain name rather
than “.” in the MX record i.e. 
foo.bar.example MX  0 no-mail.invalid. 

But this is just a question of preference and installed base. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard

[Olafur Gudmundsson]

On Jul 18, 2014, at 10:18 AM, Tony Finch  wrote:

> Paul Vixie  wrote:
>> 
>> what's unstated here is that every SMTP sender who encounters such an MX
>> without understanding its new meaning will do two or three lookups: ".
>> MX",
> 
> No, MTAs do not look up MX records for MX targets.
> 
>> [". ",] and ". A".
> 
> But they might do these lookups, yes.
> 
> If this is a worry for the root server operators (but I thought they had
> said in the past that it doesn't pose a problem) then the draft could
> specify a canonical address-less domain lower down the hierarchy, e.g.
> empty.as112.arpa (making use of the AS112 DNAME proposal).
> 
> Tony.
> -

Many years ago Joe Abley and I suggested to create a special name for exactly 
this purpose
a name that was guaranteed to never exist in the DNS thus the first lookup 
would always return NXDOMAIN thus the A+ lookups would never take place. 
http://tools.ietf.org/html/draft-jabley-sink-arpa-03

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS terminology (Was: draft-bortzmeyer-dnsop-dns-privacy (was: DNS privacy : now at least two drafts)

[Olafur Gudmundsson]

On Jul 16, 2014, at 11:26 AM, Stephane Bortzmeyer  wrote:

> On Wed, Jul 16, 2014 at 03:21:22PM +,
> Hosnieh Rafiee  wrote 
> a message of 44 lines which said:
> 
>> For DNS in general, I saw some terminologies in different RFCs. In
>> other words, they are distributed in different RFCs.
> 
> Not only distributed: it is also inconsistent ("resolver" being
> sometimes "stub resolver" and sometimes "recursive cache”)

Stephane, 

RFC403x used explicit language that is a good start. 
 
Peter Koch and I have tried to introduce useful DNS terms in our DNS tutorials 
http://www.ietf.org/edu/documents/80DNS-Koch-Gudmundsson.pdf

I wrote up a document to address vocabulary for DANE specifications 
http://tools.ietf.org/html/draft-ogud-dane-vocabulary-02

You would have expected that RFC6950 would have done something in this space 
but it did not. 

I think you are right we NEED a single document/source that expresses a 
preferred vocabulary 
and translations from common RFC’s to the preferred modern vocabulary. 

I would be happy to work on extending the DANE vocabulary document to cover 
more DNS terms

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Olafur Gudmundsson]

On Jul 8, 2014, at 10:28 AM, William F. Maton Sotomayor  
wrote:

> 
> On Tue, 8 Jul 2014, Olafur Gudmundsson wrote:
> 
>> 
>> On Jul 8, 2014, at 7:40 AM, ? Roy Arends  wrote:
>> 
>>> Hiya,
>>> 
>>> I really like this idea. Many ISPs already do this, (including some high 
>>> profile public recursives, like Google and OpenDNS), because it simply 
>>> makes sense: It reduces latency for the end user, reduces outbound traffic 
>>> overhead, eliminates an attack vector.
> 
> (possibly some more questions or variations for the draft to consider)
> 
> How can I as a user ensure that what Google does in the name of moi, can be 
> verified to be an untampered copy of the root zone?
> 
> How do I as a user know if there's a stale copy of the root zone being 
> slaved^H^H^H^H^H^H^H supplied by my ISP?  (is not being able to reach 
> wyle.e.coyote.acme enough to give me that hint?)
> 
> How do I know if my ISP, etc. are running a local copy of the zone?  Can I 
> call RSACC to complain about an outage?
> 
> (In other words, what are the mechanisms for someone to figure this out 
> before calling the helpdesk, or, should the draft say to call if you suspect 
> something is wrong?  They'd probably do it anyways...maybe.  Yes, I'm 
> rhetorical here, DNSSEC etc for mitigation, etc.)
> 
>>> Roy
>> 
>> Roy
>> you hit the nail on the head, this is a no brainer as a BCP.
>> 
>> The contents of this draft may or may not be right at this point but we need 
>> a BCP that explains how to do this and the pitfalls to be aware off.
> 
> BCP or informational (cautionary tales)?

too early to tell. The former if possible, but that may need protocol work 
a better zone transfer mechanism, a zone consistency check built into the 
system (something like SIG(AXFR) from RFC2065 but better) 


> 
>> For an DNS resolution provider that elects to  there are two ways to do it,
>>  forward zone
>>  local authoritative zone.
>> both should be allowed, this document seems ?bind? specific that it assumes 
>> that the recursive resolver can be both authoritative and recursive which is 
>> not a requirement.
>> 
>> There is no need that every recursive resolver at a Resolution Provider have 
>> a copy of the root zone only that the resolvers know the ?local root 
>> servers?.
> 
> I see mentions of 'Resolution Provider'.  Is this a BCP for only them, or can 
> anyone join the local auth zone party at their own risk/pleasure, at which 
> point it's informational or still BCP?  What is the litmus test?
> 

Litmus test, why? 

Root zone is not special from a serving point of view, only from fetching it 
and maintaining it. 
If I’m a Resolution Provider who can I hurt by messing up? Only my customers. 

>> In my mind this is not that far off from Anycast root servers i.e. 
>> additional server placed closer to the query generators.
>> The big difference is in management and control.
> 
> There were good intentions behind the Cymru bogon list.  Every once in a 
> while, we start to see complaints of former bogons being unreachable because 
> they're no longer bogons.  Is there a similar risk for that here and should 
> it be identified?

All risks and benefits we can think of should be documented. 
A guide to monitoring the service should be provided 

> 
>> The root server operators believe (correctly) that they provide valuable 
>> service and are critical to the operation of the internet, They also believe 
>> that having
>> close control over all root servers is essential.
>> A number of people over the years have said that the current model is not 
>> the only possible way to provide the same service just as well,
>> further diversification of root server services  is enabled by DNSSEC.
>> 
>> The open question is does the promotion of this type of service create any 
>> NEW attacks agains the CONTENT of the root zone,
>> i.e. would this have made the it possible/easier for Turkey to restrict 
>> access to  Google and Twitter?
>> 
>> The technical question that needs to be answered what is the safest way to 
>> distribute the root zone and locally validate it before making it available 
>> on the
>> ?local root servers?. In my mind the answer Notify and incremental XFR with 
>> stronger protections.
>> 
>> I think the answer is NO thus I support the promotion of a BCP on ?locally 
>> provided root servers?.
>> 
>>  Olafur
>> 
>> 
>>> 
>>>> On 04 Jul 2014, at 21:50, Paul Hoffman  wrote:
>>>> 
>>>> Greetings.

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Olafur Gudmundsson]

On Jul 8, 2014, at 12:33 PM, Tony Finch  wrote:

> Olafur Gudmundsson  wrote:
>> 
>> this document seems “bind” specific that it assumes that the recursive
>> resolver can be both authoritative and recursive which is not a
>> requirement.
> 
> You can't implement this draft's validation and fallback requirements just
> by configuring BIND, so I think all name server software will need
> significant improvements.
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> FitzRoy: Northerly 4 or 5, increasing 6 or 7 in south, perhaps gale 8 later in
> southeast. Moderate, becoming moderate or rough in south. Fair. Good.


I agree with you that just configuring “Some off the shelf name server” is not 
enough but 
wether that should be built into Authoritative server or is a stand-alone tool  
should be left 
each implementation. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-wkumari-dnsop-dist-root-01.txt

[Olafur Gudmundsson]

On Jul 8, 2014, at 7:40 AM, 🔒 Roy Arends  wrote:

> Hiya,
> 
> I really like this idea. Many ISPs already do this, (including some high 
> profile public recursives, like Google and OpenDNS), because it simply makes 
> sense: It reduces latency for the end user, reduces outbound traffic 
> overhead, eliminates an attack vector.
> 
> This specific document shouldn’t be a discussion point at all. Folks are 
> doing this right now. What we need is a BCP that describes: IFF you are going 
> to do it, here is how.
> 
> I would also like to see some facilitation around this as well: a notify 
> service of new versions, a zone distribution service (xfer service), possibly 
> out of ICANN or VeriSign.
> 
> Personally, I’m interested in what operators of large recursives have to say 
> about this. 
> 
> Hope this helps.
> 
> Roy
> 

Roy 
you hit the nail on the head, this is a no brainer as a BCP. 

The contents of this draft may or may not be right at this point but we need a 
BCP that explains how to do this and the pitfalls to be aware off. 
For an DNS resolution provider that elects to  there are two ways to do it, 
forward zone 
local authoritative zone. 
both should be allowed, this document seems “bind” specific that it assumes 
that the recursive resolver can be both authoritative and recursive which is 
not a requirement. 

There is no need that every recursive resolver at a Resolution Provider have a 
copy of the root zone only that the resolvers know the “local root servers”. 

In my mind this is not that far off from Anycast root servers i.e. additional 
server placed closer to the query generators.
The big difference is in management and control. 
The root server operators believe (correctly) that they provide valuable 
service and are critical to the operation of the internet, They also believe 
that having
close control over all root servers is essential. 
A number of people over the years have said that the current model is not the 
only possible way to provide the same service just as well, 
further diversification of root server services  is enabled by DNSSEC. 

The open question is does the promotion of this type of service create any NEW 
attacks agains the CONTENT of the root zone,
 i.e. would this have made the it possible/easier for Turkey to restrict access 
to  Google and Twitter? 

The technical question that needs to be answered what is the safest way to 
distribute the root zone and locally validate it before making it available on 
the 
“local root servers”. In my mind the answer Notify and incremental XFR with 
stronger protections. 

I think the answer is NO thus I support the promotion of a BCP on “locally 
provided root servers”. 

Olafur


> 
>> On 04 Jul 2014, at 21:50, Paul Hoffman  wrote:
>> 
>> Greetings. Warren and I have done a major revision on this draft, narrowing 
>> the design goals, and presenting more concrete proposals for how the 
>> mechanism would work. We welcome more feedback, and hope to discuss it in 
>> the WG in Toronto.
>> 
>> --Paul Hoffman
>> 
>> Begin forwarded message:
>> 
>>> From: internet-dra...@ietf.org
>>> Subject: I-D Action: draft-wkumari-dnsop-dist-root-01.txt
>>> Date: July 3, 2014 at 2:17:46 PM PDT
>>> To: i-d-annou...@ietf.org
>>> Reply-To: internet-dra...@ietf.org
>>> 
>>> 
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories.
>>> 
>>> 
>>>  Title   : Securely Distributing the DNS Root
>>>  Authors : Warren Kumari
>>>Paul Hoffman
>>> Filename: draft-wkumari-dnsop-dist-root-01.txt
>>> Pages   : 9
>>> Date: 2014-07-03
>>> 
>>> Abstract:
>>> This document recommends that recursive DNS resolvers get copies of
>>> the root zone, validate it using DNSSEC, populate their caches with
>>> the information, and also give negative responses from the validated
>>> zone.
>>> 
>>> [[ Note: This document is largely a discussion starting point. ]]
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-dist-root/
>>> 
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-01
>>> 
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-dist-root-01
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On May 28, 2014, at 8:23 AM, Ted Lemon  wrote:

> So not to put too fine a point on it, but where is the use case for this 
> proposal?   It seems like something that is more of someone's cool hack than 
> a standard people ought to implement.   What am I missing?
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

I was wondering about that as well. 
Then I started thinking about the bigger picture. 

In the beginning we had in the zone file 
RR’s: SOA NS   ==> loaded into memory 
Comments:  text ==> not loaded into memory 
Directives: $ORIGIN, $TTL …. ==> affect how the RR’s are named

Then we got Macros:  
$INCLUDE  ===> read this new file s
$GENERATE ==> creates lots of records that are similar 

Then we got comments that guide tools :  “; Active …."

Now we are getting request for persistent comments that are not exposed, and 
only transferred to “connecting adults” 
i think this is normal evolution, but doing this without looking at the whole 
picture is which includes the RR type code space
there we have 
normal RR’s  1-127, 256-61439
meta RR’s: 128-255
Undefined: 61400-65279
Private Use: 65280-65279 

At this point I can not  make up my mind if NOTE should be a Meta Type or we 
cave up the Undefined space to create a block for Note like
records, as we can not assume there will not be an application for more in the 
future (lets call this: COMMENT TYPES for now )

For example I can see many of the “comments that guide tools” becoming a type 
like NOTE, thus enabling for example 
signing on the fly by by secondaries. 

For this reason the “Flag/Option” defined to express understanding should cover 
them all. 
The only ways to do that in a sane way are: 
List all “comment types you know about” 
or create a range for comment types. 

Thus the decision on flag vs option depends allocation policy for this comment 
type and future ones. 

(Sorry Evan for creating an even higher bar for your document but simple useful 
hacks like this sometimes have consequences 
that flood of new ideas come out) 

Olafur





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Extended CNAME (ENAME)

[Olafur Gudmundsson]

On May 19, 2014, at 8:26 PM, Bob Halley  wrote:

> On 5/19/14, 16:43, "Mark Andrews"  wrote:
> 
>> No.  Your analysis is faulty.
>> 
>> ENAME could be used immediately once the authoritative servers for
>> the zone support it.  It would just be insecure until validators
>> catch up.  ENAME + old algorithm would be illegal and would be
>> enforced by signing code and authoritative servers.
> 
> I didn't say ENAME wouldn't work if you didn't validate.  What I'm saying
> is that proposals which are incompatible with existing DNSSEC should be
> subject to the most rigorous scrutiny and cost-benefit analysis, and that
> I don't think ENAME's benefits are worth its costs.  Others may have
> differing valuations.  That's all I'll say on this matter.

+1
Anything that requires logic changes in resolvers takes a long time to roll
out. We can not afford having one more change that negatively affects DNSSEC 
validation. 
SRV use by HTTPv2 is mostly a client change, we will not need to wait for the 
5+ year developmental 
+ deployment cycle of upgraded resolver in certain OS distributions. 

As a matter of fact I recall that Mark wrote this document many years back: 
 http://tools.ietf.org/html/draft-andrews-http-srv-00
If that draft had got traction then,  the world would be a much better place 
today. 

Olafur
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Olafur Gudmundsson]

On May 16, 2014, at 7:56 AM, Ted Lemon  wrote:

> On May 16, 2014, at 5:35 AM, S Moonesamy  wrote:
>> I sent a few comments about that CDNI draft.  The DNS discussion in the 
>> draft was problematic.  It is worth documenting what people are doing.  It 
>> is worthwhile to consider whether the mechanism should be standardized by 
>> the IETF.
> 
> Did you feel that your comments were adequately addressed by the working 
> group?
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop


As a chair of the working group where this draft started (dnsext), I can state 
the discussion was “dysfunctional” there where some people 
strongly supporting this and few people saying this would cause the world to 
end and calling the proponents names. 
Most people avoided getting into the food fight, thus there is was no way to 
judge if the proposal had significant support. 

I personally want to see this published, 
a)  as the type code has been allocated (by the ENDS0 Options Expert: 
yours truly) 
b) this is in use and this option has a role in certain environments. 
c) we need to be more rational in judging proposals on their merits not 
just by the initial smell test. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-delegation-trust-maintainance-13.txt

[Olafur Gudmundsson]

Hi
This version contains new appendix B 
that demonstrates how to do KSK rollover using CDS (or CDNSKEY) 
Tim,  I think this takes care off all outstanding issues from the WG LC. 

Olafur

On May 3, 2014, at 3:16 PM, internet-dra...@ietf.org wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Domain Name System Operations Working Group 
> of the IETF.
> 
>Title   : Automating DNSSEC Delegation Trust Maintenance
>Authors : Warren Kumari
>      Olafur Gudmundsson
>  George Barwood
>   Filename: draft-ietf-dnsop-delegation-trust-maintainance-13.txt
>   Pages   : 21
>   Date: 2014-05-03
> 
> Abstract:
>   This document describes a method to allow DNS operators to more
>   easily update DNSSEC Key Signing Keys using the DNS as communication
>   channel.  The technique described is aimed at delegations in which it
>   is currently hard to move information from the child to parent.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-delegation-trust-maintainance/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dnsop-delegation-trust-maintainance-13
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-delegation-trust-maintainance-13
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Olafur Gudmundsson]

On Apr 25, 2014, at 2:28 AM, Matthijs Mekking  wrote:

> Hi,
> 
> On 04/24/2014 05:41 PM, 神明達哉 wrote:
>> At Thu, 24 Apr 2014 07:55:52 +0200,
>> Matthijs Mekking  wrote:
>> 
>>> The child can also signal its desire to remove DS records by removing
>>> the corresponding records from the CDS/CDNSKEY RRset again.
>> 
>> ...unless that would make the resulting CDS/CDNSKEY RRset empty.
>> Otherwise it can contradict this one:
> 
> Of course. I tried to rephrase it in four short lines. That does not
> mean that one line that stands alone is the absolute truth: you have to
> consider the complete context.
> 
> 
>>> If the parent sees no CDS/CDNSKEY RRset published in the child's zone,
>>> this means there is no action to perform for the parent. Hence, this
>>> document does not support removing all DS records from the parent.
>> 
>> I guess this discussions is essentially the same as what I asked a few
>> months ago:
>> http://www.ietf.org/mail-archive/web/dnsop/current/msg11051.html
>> 
>> and while I thought revised versions of the draft were clear about
>> this point, but the fact that we still have this discussion seems to
>> suggest it's probably not sufficiently clear.  Perhaps the problem is
>> that many of us already knows how it works and it's difficult for us
>> to see how it could be interpreted by first-time readers.  So, while
>> it may look redundant, it may help if we show a specific example of
>> how the child adds/removes CDS/CDNSKEY and how it works at the parent:
> 
> I am indeed pretty clear about how this should work and I think the
> draft reflects that. But indeed: there is nothing wrong with adding an
> appendix with some examples. Some remarks below:
> 
>> 0. the child becomes signed from unsigned, tells the parent its
>>   DNSKEY (say KSK1), the parent has a DS.  this step is out of scope
>>   of CDS/CDNSKEY:
>>   child.example. DS (for KSK1)
>> 1. the child adds the corresponding CDS in the child zone:
>>   child.example. DNSKEY (for KSK1)
>>   child.example. CDS (for KSK1)
> 
> The child does not necessarily need to add the CDS now: The parent
> already has the correct DS RRset (step 0) and no rollover has happened
> since then.
> 
> 
>> 2. the child adds a new DNSKEY (KSK2) and corresponding CDS in the
>>   child zone:
>>   child.example. DNSKEY (for KSK1)
>>   child.example. DNSKEY (for KSK2)
>>   child.example. CDS (for KSK1)
>>   child.example. CDS (for KSK2)
> 
> Depending on the type of rollover, the child might not want to add the
> CDS directly (Double-Signature KSK Rollover) or might want to add the
> CDS before adding the DNSKEY (Double-DS KSK Rollover).
> 
> 
>> 3. the parent notices or is notified of a change in the child, and
>>   finds there's a new CDS (for KSK2) that doesn't match its set of
>>   CDS, and adds a new DS corresponding to that one:
>>   child.example. DS (for KSK1)
>>   child.example. DS (for KSK2)
>> 4. the child confirms the DS and CDS are now synchronized, and removes
>>   the old DNSKEY (KSK1) and corresponding CDS:
>>   child.example. DNSKEY (for KSK2)
>>   child.example. CDS (for KSK2)
> 
> You want to remove DNSKEY and CDS for KSK1 here.
> 
> Again: The old CDS may be removed earlier, at the time of adding the CDS
> for KSK2 (Double-Signature) or later (Double-DS).
> 
> 
>> 5. the parent notices or is notified of a change in the child, and
>>   finds a CDS (for KSK1) that currently matches one of its DS's is
>>   now removed.  the parent removes the corresponding DS:
>>   child.example. DS (for KSK2)
>> 6. the child confirms the DS and CDS are now synchronized.  at this
>>   point, it MAY remove the remaining CDS for the reason explained in
>>   Section 4.1 of draft-ietf-dnsop-delegation-trust-maintainance-11:
>>   child.example. DNSKEY (for KSK2)
>>   (no CDS records)
>> 7. the parent notices the change in the child, but does nothing since
>>   there's no CDS record in the child:
>>   child.example. DS (for KSK2) ; still exist
>> 8. eventually the child might go unsigned again.  all of its DNSKEYs
>>   will be removed, but the child needs to tell the parent about the
>>   change and have them remove the DS records in some other way than
>>   CDS/CDNSKEY.  removing all CDS records can't be used since it
>>   doesn't make any change at the parent as shown in steps 6 and 7.
> 
> Other than that, I think these examples are very clear, and I support
> adding them as an appendix.
> 
> Best regards,
>  Matthijs
> 

I'm willing add an appendix that has Double DS KSK rollover to the appendix 
with reference to RFC6781 figure 7, as an example. 
I will think about the dual KSK example. 

Tim tell me if you DO NOT want this added to the document. 

Olafur 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Working Group Last call for draft-ietf-dnsop-delegation-trust-maintainance

[Olafur Gudmundsson]

On Apr 15, 2014, at 8:06 PM, Paul Hoffman  wrote:

> This looks greatly improved from the -03 that started the WG Last Call. It 
> clears almost all of my concerns, particularly about the overly-loose 
> language.
> 
> There is still one assumption being made of the reader that I think can 
> cleanly be cleared up. The first paragraph of the introduction says:
> 
>   When a DNS operator first signs their zone, they need to communicate
>   their DS record(s) (or DNSKEY(s)) to their parent through some out-
>   of-band method to complete the chain of trust.
> 
> I think the concept of what is being told to the parent would be much clearer 
> as:
> 
>   When a DNS operator first signs their zone, they need to communicate their
>   keying material to their parent through some out-of-band method to complete
>   the chain of trust. Depending on the desires of the parent, the child might
>   send their DNSKEY record, a DS record, or both.


I agree this text is much better. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Olafur Gudmundsson]

On Apr 1, 2014, at 10:48 PM, Paul Hoffman  wrote:

> On Apr 1, 2014, at 7:37 PM, Olafur Gudmundsson  wrote:
> 
>> Why not go to a good ECC instead ? (not sure which one, but not P256 or 
>> P384) 
> 
> Why not P256 or P384? They are the most-studied curves. Some of the newer 
> curves do have advantages, but they are also newer.
> 
> --Paul Hoffman


The verification performance is bad, P256 takes 24x times longer to verify a 
signature than 2048 bit RSA key. 
Studied != good performance

Olafur



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Olafur Gudmundsson]

On Apr 1, 2014, at 11:15 AM, Colm MacCárthaigh  wrote:

> 
> On Tue, Apr 1, 2014 at 5:39 AM, Olafur Gudmundsson  wrote:
> Doing these big jumps is the wrong thing to do, increasing the key size 
> increases three things:
> time to generate signatures
> bits on the wire
> verification time.
> 
> I care more about verification time than bits on the wire (as I think that is 
> a red herring).
> Signing time increase is a self inflicted wound so that is immaterial.
> 
>   signverifysign/s verify/s
> rsa 1024 bits 0.000256s 0.16s   3902.8  62233.2
> rsa 2048 bits 0.001722s 0.53s580.7  18852.8
> rsa 4096 bits 0.012506s 0.000199s 80.0   5016.8
> 
> Thus doubling the key size decreases the verification performance by roughly 
> by about 70%.
> 
> With those numbers; if the validating resolver uses speculative/optimistic 
> concurrency [1] then jumping from 1024 to 4096 bits, the user-impact is that 
> ~180us are added to the overall resolution time. Zero in the cached case. 
> 

you are assuming one validation per question ? 
what if the resolver needs to to 10? that is 1.8ms, 

> There is an impact on the overall capacity of the resolver, though it's a 
> function of cache-miss-rate (since cache hits need not be verified). Large 
> centralised resolver operators may face some pressure (anyone doing 
> validation locally is unlikely to notice), but is it sensible to compromise 
> your zone security to accommodate that?

What is the security model ? 
without defining that we can not discuss "compromise" in practical terms. 
In my mind the question is what is the value of breaking key for "X", and the 
value depends on who/what "X" is. 
How valuable is it to anyone to break the key for ogud.com vs amazon.com ? 
As amazon.com is more valuable they SHOULD use stronger keys at all times, but 
.com key is even more valuable.

In all system design we need to take into account where the system can be 
subverted, right now the 
registration part of DNS system is the weakest link, thus most cost effective 
way to gain hold of a domain is to 
divert the registration. 

Secondly what can someone do with "cracked" key and for how long?  

> 
> [1] There's no need to wait for a response to be validated before recursing, 
> a validating resolver can first recurse and later backtrack if the parent 
> signature doesn't verify.

In the scope of things verification times are small compared to network delays 
but can add up if done as batch operation. 

Olafur




___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Olafur Gudmundsson]

On Apr 1, 2014, at 9:05 AM, Nicholas Weaver  wrote:

> 
> On Apr 1, 2014, at 5:39 AM, Olafur Gudmundsson  wrote:
>> 
>> Doing these big jumps is the wrong thing to do, increasing the key size 
>> increases three things:
>>  time to generate signatures  
>>  bits on the wire
>>  verification time. 
>> 
>> I care more about verification time than bits on the wire (as I think that 
>> is a red herring).
>> Signing time increase is a self inflicted wound so that is immaterial. 
>> 
>> signverifysign/s verify/s
>> rsa 1024 bits 0.000256s 0.16s   3902.8  62233.2
>> rsa 2048 bits 0.001722s 0.53s580.7  18852.8
>> rsa 4096 bits 0.012506s 0.000199s 80.0   5016.8
>> 
>> Thus doubling the key size decreases the verification performance by roughly 
>> by about 70%. 
>> 
>> KSK's verification times affect the time to traverse the DNS tree, thus 
>> If 1024 is too short 1280 is fine for now
>> If 2048 is too short 2400 bit key is much harder to break thus it should be 
>> fine. 
>> 
>> just a plea for key use policy sanity not picking on Bill in any way.
> 
> NO!  FUCK THAT SHIT.  Seriously.

Watch your language, just because I'm calling you on the carpet for simplistic 
world view, does not mean you need to use foul language. 

> 
> There is far far far too much worrying about "performance" of crypto, in 
> cases like this where the performance just doesn't matter!
> 

disagree strongly, you are only looking at a part of the whole picture. 
Verification adds resolution latency + verification adds extra queries which is 
more latency
latency == un-happy eye-balls.  

> Yes, you can only do 18K verifies per CPU per second for 2048b keys.  Cry me 
> a river.  Bite the bullet, go to 2048 bits NOW, especially since the servers 
> do NOT have resistance to roll-back-the-clock attacks.

Why not go to a good ECC instead ? (not sure which one, but not P256 or P384) 

18K answers/second ==> is a fraction of what larger resolver servers do today 
during peak times, yes not all answers need validation.
BUT you need to take into account that in some cases there is going to be lots 
of redundancy in verification in large resolver clusters, thus
if your query stream hits 5 different hosts all of them may end up doing almost 
5x of the work, thus adding servers does not scale. 
Yes people can create any cast clusters in depth where only the front end ones 
do verification and the back end ones only answer queries, but
that has different implications. 

Remember it is not average load that matters it is peak load, even if the peak 
for 30 minutes on one day of the year. 

Over the years I have been saying use keys that are appropriate, thus for 
someone like Paypal it makes sense to have strong keys,
but for my private domain does it matter what key size I use? 
I do not buy the theory that one size fits all model for crypto, people should 
not use unsafe crypto, but the one size fits all is not the
right answer, just like not every zone needs a KSK and ZSK split. ( I use 
single 1280 bit RSA key with NSEC) 

A real world analogy is that not everyone needs the same kind of car, some 
people need big cars, others small ones or even no car. 

Furthermore using larger keys than your parents is non-sensical as that moves 
the cheap point of key cracking attack. 
 
> In a major cluster validating recursive resolver, like what Comcast runs with 
> Nominum or Google uses with Public DNS, the question is not how many verifies 
> it can do per second per CPU core, but how many verifies it needs to do per 
> second per CPU core.

I have no doubt that CPU's can keep up but the point I was trying to make is 
increasing the key sizes by this big jump 
==> invalidates peoples assumptions on what the load is going to be in the near 
term. 

> 
> And at the same time, this is a problem we already know how to parallelize, 
> and which is obscenely parallel, and which also caches…

Do we? Some high performance DNS software is still un-treaded, many resolvers 
are run in VM's with low number of cores 
exported to the VM. 

> 
> Lets assume a typical day of 1 billion external lookups for a major ISP 
> centralized resolver, and that all are verified.  Thats less 1 CPU core-day 
> to validate every DNSSEC lookup that day at 2048b keys.  

1B is low due to low TTL's and synthetic names used for transactions, and as I 
said before it is peak load that matters not average. 
DNSSEC processing is just a part of the whole processing model. 

> 
> And yeah, DNS is peaky, but that's also why this task is being run on a 
> cluster already, and each cluster node has a lot of CPUs.

that costs money, and effort to operate.

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...

[Olafur Gudmundsson]

On Mar 27, 2014, at 6:54 PM, Bill Woodcock  wrote:

> 
> On Mar 27, 2014, at 10:14 AM, Matthäus Wander  
> wrote:
>> Here's a small statistic about RSA key lengths of 741,552 signed
>> second-level domains (collected on 2014-01-27, counting KSK and ZSKs):
>> 
>> 1024 bit: 1298238
>> 2048 bit: 698232
>> 1280 bit: 28441
>> 4096 bit: 25326
>> 512 bit:   8893
>> 1536 bit: 385
> 
> Matthäus, do you have an easy way of separating out KSK from ZSK in your 
> statistics?  FWIW, we’re currently doing 2048-bit KSK and 1024-bit ZSK, but 
> will shortly be transitioning to 4096-and-2048.
> 
>-Bill
> 


Doing these big jumps is the wrong thing to do, increasing the key size 
increases three things:
time to generate signatures  
bits on the wire
verification time. 

I care more about verification time than bits on the wire (as I think that is a 
red herring).
Signing time increase is a self inflicted wound so that is immaterial. 

  signverifysign/s verify/s
rsa 1024 bits 0.000256s 0.16s   3902.8  62233.2
rsa 2048 bits 0.001722s 0.53s580.7  18852.8
rsa 4096 bits 0.012506s 0.000199s 80.0   5016.8

Thus doubling the key size decreases the verification performance by roughly by 
about 70%. 

KSK's verification times affect the time to traverse the DNS tree, thus 
If 1024 is too short 1280 is fine for now
If 2048 is too short 2400 bit key is much harder to break thus it should be 
fine. 

just a plea for key use policy sanity not picking on Bill in any way.

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] port 0 requests leading to errors

[Olafur Gudmundsson]

On Mar 23, 2014, at 8:59 PM, Christopher Morrow  
wrote:

> If I have a patch which makes no sense, will you also add it?
> 
> 

Speaking for Paul, 
Paul used value judgement based on the persons reputation. 
If Mark thought it was important enough to submit a patch then there must be a 
reason, even if
Paul was not clueful enough to understand in the few minutes he thought about 
it. 

Olafur

> On Mar 22, 2014 1:25 PM, "Paul Vixie"  wrote:
> 
> 
> bert hubert wrote:
> > ...
> >
> > 43.504115 IP x.y.117.10.0 > 192.175.48.6.53: 6365+ SOA? 
> > 168.192.in-addr.arpa. (38)
> > 45.504152 IP x.y.117.10.0 > 192.175.48.6.53: 6365+ SOA? 
> > 168.192.in-addr.arpa. (38)
> > 49.505124 IP x.y.117.10.0 > 192.175.48.6.53: 6365+ SOA? 
> > 168.192.in-addr.arpa. (38)
> >
> > PowerDNS now refuses to attempt to answer such packets, which silences the
> > error messages.
> 
> mark andrews sent me a similar patch to bind 4.9 back in 1992, which
> made no sense to me but i put it in anyway. thanks for explaining.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New Version Notification for draft-schmidt-brainpool-dnssec-00.txt

[Olafur Gudmundsson]

On Mar 21, 2014, at 3:39 AM, "Schmidt, Jörn-Marc" 
 wrote:

> Dear all,
> 
> I've just submitted the draft below on using ECDSA with Brainpool Curves for 
> DNSSEC. 
> 
> The rationale behind this submission is the fact that the  German electronic 
> health insurance card (Gesundheitskarte) mandates the use of DNSSEC, while 
> the use of Brainpool curves is recommended by the German Federal Office for 
> Information Security (BSI). Currently, using ECC with DNSSEC is only 
> specified for NIST Curves (RFC 6605). Hence, in order to comply with the 
> recommendations on the one hand and with global specifications on the other 
> hand, we wrote this draft.
> 
> Any feedback/comments/thoughts are very welcome.
> 


Is the performance of these curves any better than P256,  P384 and EC-GOST that 
are currently specified? 
Unless there is significant performance improvement over the Px curves this is 
IMHO wasted effort.

Is there a reason to believe that the curves you request are significantly 
stronger than the currently specified curves? 

Why are you defining 3 curves ? 
There are only about 230 code points available for algorithms, we do not want 
"vanity" curves specified
so unless you can JUSTIFY each one as being significantly "better" than what is 
currently specified 
what is the point this includes both Pxxx curves and ECC-GOST. 
Defining more algorithms decreases interoperability as code bases need to pick 
up all algorithms. 

While you talk about German regulations wanting some curve, that does not mean 
that they can mandate any
domain to use it. Thus the issue of what german regulations use for health care 
cards is orthogonal to what is used by DNSSEC. 

If all you want is to publish German health Insurance Card keys in DNS then ask 
for a "Gesundheit" record to publish the keys, and
then the consumption of these records only affects the those that need to 
process the keys. 

Sorry for the tone of the message but you need MUCH better justification in 
your next version for this to be considered,
right now this looks like a pure vanity registration request. 

Olafur 


> Best,
> 
> Jörn
> 
> 
> ---
> A new version of I-D, draft-schmidt-brainpool-dnssec-00.txt
> has been successfully submitted by Joern-Marc Schmidt and posted to the IETF 
> repository.
> 
> Name: draft-schmidt-brainpool-dnssec
> Revision: 00
> Title:ECC Brainpool Curves for DNSSEC
> Document date:2014-03-21
> Group:Individual Submission
> Pages:6
> URL:
> http://www.ietf.org/internet-drafts/draft-schmidt-brainpool-dnssec-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-schmidt-brainpool-dnssec/
> Htmlized:   http://tools.ietf.org/html/draft-schmidt-brainpool-dnssec-00
> 
> 
> Abstract:
>   This document specifies the use of ECDSA with ECC Brainpool curves in
>   DNS Security (DNSSEC).  It comprises curves of three different sizes.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission 
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Olafur Gudmundsson]

On Mar 5, 2014, at 2:42 PM, Stephane Bortzmeyer  wrote:

> On Wed, Mar 05, 2014 at 12:51:52PM +,
> Olafur Gudmundsson  wrote 
> a message of 41 lines which said:
> 
>> I NEED confidence that I'm talking to the real 8.8.8.8 if the only
>> way to get that is encryption then I support it.
> 
> The goal of the DNSE BoF was privacy, not authentication. For
> authentication, we have DNSSEC :-) For the case where the validating
> resolver is far away and we need to secure the last mile against
> AD-bit tampering, well... no problem statement published, no I-D and
> no BoF yet.

Fair enough 
> 
>> I would prefer that before we start talking about encryption is we
>> agree on label stripping by recursive resolvers as that minimizes
>> the leak of information to root/tld servers.
> 
> Why before? Encryption and QNAME minimization are both great things
> and should be done but they solve different privacy problems:
> 
> * surveillance by a third-party sniffing the wire (encryption)
> * surveillance by the name servers' operators (QNAME minimization)
> 
> 

You and I can in theory write up an BCP candidate on this QNAME minimization, 
topic in one day and have it published in about 3 months and we are done. 
Any recursive resolver can make this change in their next version as an option 
and we can 
evaluate the impact, and then recommend when to turn on "label stripping" i.e. 
I'm not sure
if reverse tree should have any QNAME minimization. 

Encryption will take much longer to gain traction, in my mind I do not like 
that 
for example tad servers can see what is asked for in a sub-domain as xTLD are
most natural collection points thus we need to make the data that they see have 
as little value
as possible
To my encrypting full QNAME to everyone is non-sensical. 


Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-fujiwara-dnsop-ds-query-increase-02

[Olafur Gudmundsson]

On Mar 5, 2014, at 10:23 AM, fujiw...@jprs.co.jp wrote:

> Dear Chairs and WG participants,
> 
> I updated draft-fujiwara-dnsop-ds-query-increase this Janurary.
> 
>  http://tools.ietf.org/html/draft-fujiwara-dnsop-ds-query-increase
> 
> Recent DS traffic increase seems not high, I did not request time slot
> of WG meeting. However, Increasing is a fact. 
> 
> Recent DS query graph is here:
>  http://member.wide.ad.jp/~fujiwara/files/DS_graph_20140305.pdf
> 
> Please comment to the draft.
> 
> What should I do about this draft from now on?  


This is not a protocol issue this, is an implementation choice when a resolver 
is optimizing for speed of resolving by 
fetching any possible missing information 

Increasing the negative TTL will to large extend address the issue but has 
other implications

Dummy DS  an option for the high query volume domains you do not need it for 
most. 
If some validators have problem with them report it as bugs and hopefully it 
will be fixed quick.  

Your calculations on the amplification are good illustration, but assume that 
the resolvers use
the parental provided NS set, not the child side provided NS set. 
In the case of google.co.jp. 
JP side NS has TTL of 1 day but google.co.jp side has is 96 hours (4 days) 
Unbound resolver has by default of MaxTTL 1 day thus it does not matter in the 
case of google.co.jp 
which NS set is stored, but other resolvers do different things. 

In short I think the simple conclusion is 
"signed domain will see increased DS traffic for unsigned child domains" 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] my dnse vision

[Olafur Gudmundsson]

On Mar 5, 2014, at 11:07 AM, Francis Dupont  wrote:

>> From discussions with Stephane Bortzmeyer and Mark Andrews...
> 
> First I come back to the fact there are two different problems
> (aka divide and conquer):
> * stubs <-> resolver
> * resolver <-> auth servers
> 
> I consider the first one to be already solved, cf. the Microsoft
> deployed solution which puts clients, local networks, the resolver
> (also the Microsoft Domain Server :-), in the same area and uses
> IPsec to protect it. You can do other ways but IMHO we can assume
> you don't need confidentiality with far or untrusted resolvers.
> Or with other words you don't need confidentiality with 8.8.8.8
> 

I strongly disagree, my hotel list 8.8.8.8 as one of the resolvers available on 
the 
network, the answers from the 8.8.8.8  there are nothing like the answers I get 
from 8.8.8.8 on the IETF network. 
I NEED confidence that I'm talking to the real 8.8.8.8 if the only way to get 
that is 
encryption then I support it. 

I'm not sure if Microsoft solution works when one attaches to new networks like 
the IETF network. 

The stub <--> recursive [validating] resolver 

is the one more important to protect as the that is where it is easier to lie. 

On the other one 
recursive resolver <--->  auth servers 
 I would prefer that before we start talking about encryption is we agree on 
label stripping by recursive resolvers as that minimizes the leak of 
information to 
root/tld servers. 

Olafur

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

[Olafur Gudmundsson]

On Mar 3, 2014, at 2:03 PM, Andrew Sullivan  wrote:

> On Mon, Mar 03, 2014 at 01:56:20PM +, Jelte Jansen wrote:
>> I'd think that a domain name is only a domain name when whatever
>> protocol it is defined in defines it as a domain name (or whatever
>> undefined protocol uses it in actual dns resolution). What a non-domain
>> name looks like shouldn't matter.
> 
> Are NetBIOS names domain names?  How about mDNS names?  I think yes,
> but neither is part of the DNS as such.

NetBIOS IMHO is a different namespace but it is not treated that way by 
sysadmin's 
due to lack off ….. 

Olafur


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)

[Olafur Gudmundsson]

On Feb 17, 2014, at 11:22 AM, Ted Lemon  wrote:

> On Feb 16, 2014, at 9:03 PM, Paul Wouters  wrote:
>> DNSOP needs
>> to broaden its charter, or we need to revive some kind of DNSEXT group.
> 
> We would need to find some volunteers to act as co-chair.   I don't think 
> adding the work to the DNSOP charter is the right thing to do, although I am 
> not wedded to that position.   I just suspect that (a) it will make life in 
> DNSOP harder and (b) we will get better review in an intarea working group.   
> But that's a fairly artificial point to be making, so argue away!   :)


I think recreating DNS WG is a bad idea. 
We have a few ideas on the table in various that are related to 
a) DNS transport TCP, SCTP, "tree answer: give me all records need to 
answer/validate X starting from point above X", 
Zone transfer improvements 
aa) DNS "privacy" ie. channel encryption/authentication 
b) Operational Automation 
c) Keeping noise out of DNS (AS112) and name spaces/meta-tld/alt TLD.
d) New protocols adopting DANE
e) Name server control protocols 


a) and aa) should have its own short term WG 
b) Belongs in DNSOP 
c) is above DNSEXT and DNSOP wg it is more of an intersection of many different 
areas like RAI, APPS, 
OPS and SECURITY  ==> a special WG 
d) DANE WG is handling that 
d) Domain boundaries BOF may turn into a WG. 
e) Belongs in DNSOP 

So Yes I see a need for a focused DNS protocol wg at this time.
The problem with long lived groups is you never know when new useful work will 
show up,
killing groups or just the threat of killing a WG seems to bring out 
innovation. 

Olafur



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop