[DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread tjw ietf
All At the end of Tuesday's session we're having Bert Hubert from Power DNS give a talk on what he views "The Camel". He sent us a short abstract: "In past years, DNS has been enhanced with DNSSEC, QName Minimization, EDNS Client Subnet and in-band key provisioning through magic record types.

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread tjw ietf
Dave First, thanks for resurrecting this for us. I think splitting draft into two parts probably makes sense after that last round of comments. However, we need to go find those App Area folks (hence cc'ing Murray here) and run this past them. If the group likes this split, we can progress att

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Evan Hunt
On Mon, Mar 19, 2018 at 05:58:08PM +, Ted Lemon wrote: > Yeah, that's a bit iffy. Homenet is another example of the same thing. > I would make it more generic, something like this: > > Where DNS servers that are authoritative for a particular set of domains > provide partly or completely

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Ted Lemon
Yes, split horizon is the original term, which has experienced linguistic drift and is now just split DNS. I think there is a useful distinction to be made between the various different ways that global names may have different meanings in different contexts. RFC 2826 talks about this a bit, and

[DNSOP] Current Document status,

2018-03-20 Thread tjw ietf
All In advance of today's meeting, here's where we have our current document status. Comments, etc to the chairs Tim # DNSOP Chairs Status Updated: 20 March 2018 # Done ## WG chairs Work * [draft-ietf-dnsop-rfc5011-security-considerations] - update to reflect Victor's comment

Re: [DNSOP] Status of draft-ietf-dnsop-terminology-bis

2018-03-20 Thread Matthijs Mekking
On 19-03-18 20:08, Matthew Pounsett wrote: On 19 March 2018 at 08:21, Matthijs Mekking > wrote: I and some others have been using the term 'Negative response' to indicate that the response does not contain any records in the Answer section. Current

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

2018-03-20 Thread Stephane Bortzmeyer
On Mon, Mar 19, 2018 at 07:49:45PM +, Viktor Dukhovni wrote a message of 30 lines which said: > The 'delegation-only' flag does not *by itself* prevent parent > domains from answering authoritatively for their child domains, but > it could make "certificate-transparency" more tractable for

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

2018-03-20 Thread Paul Wouters
On Tue, 20 Mar 2018, Stephane Bortzmeyer wrote: The 'delegation-only' flag does not *by itself* prevent parent domains from answering authoritatively for their child domains, but it could make "certificate-transparency" more tractable for DNSSEC. I don't think that you replied to Bob's remark.

[DNSOP] Multi Provider DNSSEC Models

2018-03-20 Thread Shumon Huque
Hi folks, 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 Thanks! Shumon. ___ DNSOP mailing list DNSOP@ietf.or

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

2018-03-20 Thread Michael Casadevall
On 03/20/2018 07:44 AM, Paul Wouters wrote: > The goal of the document is to make such malicious changes visible. > > If the parent needs to replace NS/DS records, these are easily > auditable identically to Certificate Transparency (rfc 6962bis) > We only need to look (log) the DS/DNSKEY and we

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread Dave Crocker
On 3/20/2018 12:41 AM, tjw ietf wrote: However, we need to go find those App Area folks (hence cc'ing Murray here) and run this past them. tim, good idea. query has been sent to the art mailing list. ('app' area, per se, was retired, and folded with rai.) d/ -- Dave Crocker Brandenburg Int

Re: [DNSOP] New Version Notification for draft-pwouters-powerbind-00.txt (fwd)

2018-03-20 Thread Paul Wouters
On Tue, 20 Mar 2018, Michael Casadevall wrote: Certificate Transparency works because specifically because the entire certificate is uploaded, and (assuming a valid cert) a SCT is generated which can be verified by cross-checking it against the log servers public key. Without the RRtypes logged

[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-07.txt

2018-03-20 Thread internet-drafts
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 WG of the IETF. Title : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Andrew Sullivan
On Mon, Mar 19, 2018 at 05:58:08PM +, Ted Lemon wrote: > Where DNS servers that are authoritative for a particular set of domains > provide partly or completely different answers in those domains depending > on the source of the query. The effect of this is that a domain name that > i

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Ted Lemon
I think split horizon is really specific to source address, but I agree with your clarification as it applies to views. Also agree that we should mention all variants. On Mar 20, 2018 13:52, "Andrew Sullivan" wrote: > On Mon, Mar 19, 2018 at 05:58:08PM +, Ted Lemon wrote: > > Where DNS ser

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Matt Larson
> On Mar 19, 2018, at 3:26 PM, Darcy Kevin (FCA) > wrote: > > The trouble with "split horizon" is that it is a term of inter-network > routing of much older and more-established provenance, and thus to use it for > DNS can be viewed as a usurpation, and ultimately, confusing. (I know Cricket

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Ted Lemon
On Mar 20, 2018, at 3:05 PM, Matt Larson wrote: > +1 to "split DNS", which has always been the term I've used and heard. I > completely agree that "split horizon" muddies the water by referring to a > routing concept that probably pre-dates widespread use of split DNS. The term "split horizon"

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread Stephane Bortzmeyer
On Tue, Mar 20, 2018 at 07:29:50AM +, tjw ietf wrote a message of 94 lines which said: > At the end of Tuesday's session we're having Bert Hubert from Power DNS > give a talk on what he views "The Camel". Unlike the popular saying

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread Joao Damas
Camels are indeed great animals and they can be loaded until eventually one more insignificant straw breaks their back. I guess that is were Bert thinks the DNS is at now and I don’t completely disagree Joao > On 20 Mar 2018, at 15:12, Stephane Bortzmeyer wrote: > > On Tue, Mar 20, 2018 at 07

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Darcy Kevin (FCA)
The whole phenomenon is what I would call “context-sensitive resolution” (although we don’t like neologisms, so I’m not proposing that). Context-sensitive resolution encompasses “split DNS”, “views”, policy-based resolution (blacklists, etc.), GSLB algorithms, geolocation, even plain old round-

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread P Vix
When Ed have up defending the qtuple, complexity moved in. On March 20, 2018 4:04:31 PM UTC, Joao Damas wrote: >Camels are indeed great animals and they can be loaded until eventually >one more insignificant straw breaks their back. I guess that is were >Bert thinks the DNS is at now and I don’t

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread John R. Levine
-03 defines two registries, 'global' and 'second-level'. I'm suspicious of how short the global one is, though it does make sense. It's missing _dmarc, and the type names from the Enumservice registry which are used to name URI records. 2. SRV and URI These need more detailed text, very

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread Dave Crocker
On 3/20/2018 9:31 AM, John R. Levine wrote: -03 defines two registries, 'global' and 'second-level'.  I'm suspicious of how short the global one is, though it does make sense. It's missing _dmarc, and the type names from the Enumservice registry which are used to name URI records. _dmarc. t

Re: [DNSOP] redefining SRV, was New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread John R. Levine
2. SRV and URI ... We need to change the description of the second level name registry to say that SRV and URI are special, they use names from Ports and Services at the second level and URI uses enumservice subtypes, and take out all of the SRV entries.  What's left is the grabbag of

Re: [DNSOP] redefining SRV, was New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread Dave Crocker
On 3/20/2018 10:16 AM, John R. Levine wrote:  We need to move away from the complexity created by having special rules for  some entries in the registry. That would be fine except that the Port and Service registry has thousands of entries, and the named ones (nearly all of them) are valid S

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread John R. Levine
After some back and forth with Dave, I realized I missed what seems to be to be a large change: this draft redefines the naming rules for SRV and URI. The current rule is that SRV is _service._protocol where the protocol is from a short list including _tcp and _udp and the service is from the

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread P Vix
Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better. On March 20, 2018 6:11:08 PM UTC, "John R. Levine" wrote: >After some back and forth with Dave, I realized I missed what seems to >be >to be a large change: this dra

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread Paul Vixie
Joao Damas wrote: Camels are indeed great animals and they can be loaded until eventually one more insignificant straw breaks their back. I guess that is were Bert thinks the DNS is at now and I don’t completely disagree i was pretty horrified even before ECS. dnssec sentinels feels like fri

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread Robert Edmonds
Paul Vixie wrote: > Joao Damas wrote: > > Camels are indeed great animals and they can be loaded until > > eventually one more insignificant straw breaks their back. I guess > > that is were Bert thinks the DNS is at now and I don’t completely > > disagree > > i was pretty horrified even before EC

Re: [DNSOP] DNSOP Presentation "The Camel"

2018-03-20 Thread Mark Andrews
QNAME minimisation failures happen for 2 reasons. 1. Bad implementations of DNS that don’t return ENTs in a zone. 2. Failure to add delegating NS records to the parent zone resulting in no ENT being emitted when both the child and parent server are served by the same server. If we had kept

Re: [DNSOP] Multi Provider DNSSEC Models

2018-03-20 Thread Tony Finch
> 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 go

Re: [DNSOP] Terminology question: split DNS

2018-03-20 Thread Matthew Pounsett
On 19 March 2018 at 17:24, Michael Sinatra wrote: > > Rather than try for some physical demarcation like "firewall" or > "network," why don't we simply say "organizationally-defined perimeter" or > "perimeter defined by the organization," which leaves it vague enough to > support the "many potent

Re: [DNSOP] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

2018-03-20 Thread Dave Crocker
On 3/20/2018 11:32 AM, P Vix wrote: Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better. I agree completely. So please forgive my not understanding how your first and third comments are relevant to the current topic,