[DNSOP] DNSOP Presentation "The Camel"

[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.  It
is now also seeing work on 'DNS Stateful Operations', XPF, ANAME (ALIAS),
resolver/client encryption, resolver/authoritative encryption & KSK
signalling/rollovers.
Each of these features interacts with all the others. Every addition
therefore causes a further combinatorial explosion in complexity.
Up to now, the increase in DNS complexity (mostly driven by DNSSEC) has been
made possible by the huge pool of programming talent, mostly in the open
source world.
This presentation sets out, with examples, how innoccuous features
contribute
to the combinatorial rise of complexity, and how we might ponder thinking
twice before loading up this camel further."



https://datatracker.ietf.org/meeting/101/materials/slides-101-dnsop-sessa-the-dns-camel-00

Now, before everyone jumps into the deep end here, we suggest one read RFC
8324, published February of this year https://tools.ietf.org/html/rfc8324 by
John Klensin.   John discusses very similar subject matter. Bert's talk has
a more "operational" focus, which is what caught this chair's eye (since
many in the WG worry about operational issues).  I believe the authors
would agree they are complementary in nature.

(If I am incorrect, the authors are free to castigate me)

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

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

[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 attrleaf first and give you
time to work on the second document.

Tim


On Tue, Mar 20, 2018 at 12:35 AM, Dave Crocker  wrote:

> Folks,
>
> I'll limit what should be an extensive and elaborate apology to just this:
> I'm sorry for the year of inactivity.
>
> The -03 version should provide some useful substance of progress.
>
> I've gone over last summer's comments and the -03 version should reflect
> what the wg agreed to.  Basically, it has been significantly streamlined,
> essentially to reflect a clean-sheet model of the world. That is, it
> doesn't deal with the ugliness that SRV, et al, created.  It merely
> establishes the two registries we need, long term, and populates them.
> This document should have continuing utility.
>
> -03 defines two registries, 'global' and 'second-level'.  I'm suspicious
> of how short the global one is, though it does make sense.
>
> As noted in the document, absent major concerns with the substance of the
> document, please send me or the list s/old/new/ types of change
> suggestions, and if the change is for a reference, I'd love the suggestion
> to be  xml...
>
>
> A second document will attempt to fix up the uglinesses in some existing
> documents, to get them to align with a world that has these registries. It
> should be viewed as a transitional document, though we all know how glacial
> 'transitions' are in the Internet...
>
> Deciding how to pursue that reasonably has been the effort.  The changes
> this 'fixes' document defines will be to documentation, but not to existing
> operation.  Existing uses in the field will be preserved.
>
>
> Here's the approach I'm taking:
>
>
> 1. Simple underscore usage
>
>For many/most specifications that use underscore naming, the text
> merely says to use it.  They are straightforward.
>
>These specifications need to be listed in this document, explicitly, so
> that later updates to them will know to deal with the revisions called for
> by this document.
>
>But this document doesn't really need s/old/new kinds of precise detail
> for them. Rather than provide precise language for changing each of these,
> I propose to provide some generic text, and generic IANA Considerations.
> This will permit this Fixes document to be cited as Updating those RFCs.
>
>
> 2. SRV and URI
>
>These need more detailed text, very much in the s/old/new style.
>
>The current text in them does a use-by-reference of existing tables
> defined for other purposes.  The Update text will, instead, specify a
> requirement for adding entries in the Global or Common Second-Level
> registries.
>
>
> d/
>
>
>  Forwarded Message 
>
> Name:   draft-ietf-dnsop-attrleaf
> Revision:   03
> Title:  DNS Scoped Data Through '_Underscore' Naming of Attribute
> Leaves
> Document date:  2018-03-19
> Group:  dnsop
> Pages:  14
> URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-attrleaf-03.txt
> Status: https://datatracker.ietf.org/
> doc/draft-ietf-dnsop-attrleaf/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-attrleaf-03
> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-03
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
>
> ___
> 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] Terminology question: split DNS

[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 different answers in those domains depending
>   on the source of the query.   The effect of this is that a domain name that
>   is notionally globally unique nevertheless has different meanings for
>   different network users.

This might be a little *too* generic: it appears to cover things like
geographically tailored responses and EDNS Client-Subnet, as well as
the internal and external views that are more typically what
"split[-horizon] DNS" refers to.

At a technical level there may not be much difference, but I've always
thought of "split DNS" as being specific to the boundary point between an
organizational intranet and the global internet. It's my impression that
historically most people who've used the term meant it in that sense, and
it might be confusing to broaden the definition retroactively.

I do think the text above is useful, though. I would suggest that, as there
are now several situations in which DNS responses may differ depending on
the client, would could define a generic term for that ("multi-horizon DNS"
or similar?), and then define "split DNS" as a specific case in which the
answer depends on whether the originating client is inside or outside of a
network controlled by the server's operator.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

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

Re: [DNSOP] Terminology question: split DNS

[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 RFC 8244 comments further in section
4.1.1. Neither document attempts to enumerate the use cases, however.

I think that split DNS is a specific use case, and does not encompass the
whole phenomenon. If we want to talk about the whole phenomenon, this may
not be the place to do it—I don't actually know of a term for the general
idea. But I'm pretty sure that "split DNS" is not that term.

On Mar 19, 2018 21:15, "Paul Wouters"  wrote:

> On Mon, 19 Mar 2018, John Heidemann wrote:
>
> +1 on "split-horizon dns" as the term, over "split dns" and some other
>> neologism, on the basis of running code and existing documentation and
>> existing wide use.
>>
>
> I and google disagree:
>
> "split dns":  72900 hits
> "split horizon dns": 5640 hits
>
>
> If the document is about explaining terminology, it must explain "split
> dns" and can say another term for it is "split horizon dns", but not the
> other way around.
>
> I personally don't hear (or use) "split horizon dns"
>
> Paul
>
> ___
> 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] Current Document status,

[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 comments
- Write up and move forward

* [draft-ietf-dnsop-isp-ip6rdns]
- 1 week WGLC

* [draft-ietf-dnsop-refuse-any]
- will confirm authors resolved issues, 1 Week WGLC

* [draft-ietf-dnsop-alt-tld](
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-09)
- W-T-F

## In WGLC

* [draft-ietf-dnsop-session-signal]
- Updates addressed during WGLC

* [draft-ietf-dnsop-let-localhost-be-localhost]
- WGLC over waiting on Authors...

## current WGLC Order

* [draft-ietf-dnsop-dns-capture-format]
- version 06 appears ready for WGLC

* [draft-ietf-dnsop-kskroll-sentinel]
- Updates since last version, ready for WGLC

* [draft-ietf-dnsop-terminology-bis]
- tentatively mid-April 2018 for WGLC

## Adopted

* [draft-ietf-dnsop-attrleaf]
- Authors published update, splitting document

* [draft-ietf-dnsop-aname](
https://tools.ietf.org/html/draft-ietf-dnsop-aname-01)
- Authors want to split into 2 drafts (per talk)

* [draft-ietf-dnsop-extended-error]
- Authors owe an update, and ready for WGLC

* [draft-ietf-dnsop-serve-stale]
- May be too contentious?

* [draft-ietf-dnsop-dns-tcp-requirements]
- Section 4 and 5.3 TODOs

## Call for Adoption

* [draft-dupont-dnsop-rfc2845bis
- Yes

## What Happened

* [draft-wouters-sury-dnsop-algorithm-update
- Adopted by WG 2017-03-16, but no new version

## Candidates For Adoption

## Documents Worth Considering

* [draft-bellis-dnsop-xpf

* [draft-huque-dnsop-multi-provider-dnssec

* [draft-gavrichenkov-dnsop-dnssapi

* [draft-muks-dnsop-dns-catalog-zones
- stronger drive

* [draft-pwouters-powerbind

* [draft-jabley-dnsop-bootstrap-validator

* [draft-woodworth-bulk-rr

## Needs more Review

## Expired

* [draft-song-dns-wireformat-http
- new version, should push forward and/or why

* [draft-ietf-dnsop-no-response-issue
- author will upload new version
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 definition seems to imply that this is only
the case if the RCODE is NXDOMAIN, NOERROR, SERVFAIL or if there was
a timeout (unreachable). The definition I have been using includes
responses with other RCODEs too, for example FORMERR or REFUSED. 



I wonder if this is just me and my bubble or if others also a
slightly different meaning of 'Negative response' as it is defined
now. If there are others, is it worth spending a line or two about
this here?


I would suggest that only NXDOMAIN and NOERROR+ANCOUNT=0 are negative 
responses.   SERVFAIL, FORMERR, and REFUSED are error responses; you do 
not know as a result of those responses whether the name/type tuple 
queried about exists.


Fair enough, just note that RFC 2308 defines SERVFAIL as (Other) 
Negative Response.


Best regards,
  Matthijs



___
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-pwouters-powerbind-00.txt (fwd)

[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 DNSSEC.

I don't think that you replied to Bob's remark. He said that the
proposal is useless because it addresses only the case of "answering
authoritatively for their child domain", not the "directing child
domain to someplace".

> Without the proposed flag, one would also have to log denial of
> existence

There is no denial of existence in the attack explained by Bob.

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

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

[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. He said that the
proposal is useless because it addresses only the case of "answering
authoritatively for their child domain", not the "directing child
domain to someplace".


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 do not have
to monitor all TLSA and other security RRtypes. Without this flag,
we need to track and log every DNS RRtype that has public key material
in it.

Paul

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

[DNSOP] Multi Provider DNSSEC Models

[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.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 do not have
> to monitor all TLSA and other security RRtypes. Without this flag,
> we need to track and log every DNS RRtype that has public key material
> in it.
> 

Forgive my ignorance on the subject, but I'm having trouble following
how delegation_only flag actually helps in this specific case.

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, I'm not seeing how you're supposed to be
able to audit them. In the case where a KSK is compromised, you could
simply sign a new zone record, serve up fraudulent records and remain
unaware. CT as it's implemented in the x509 world (combined with
Expect-CT) specifically prevents unknown but validly signed certificates
from being used.

I'm likely missing something obvious, by only logging DS/NS, it would be
impossible to determine if a private key is misused to serve fraudulent
records which in my mind is a bigger and much more likely/common threat
since one can simply attack a target domain and not try to compromise
the root.

Moving to the topic of the draft itself:

>From a technical point of view, aren't there TLDs that as authoritative
for second level domains as well? The specification likely needs a way
to denote how many levels deep delegation can go. This also would be
true in the case of delegation_only being used at a level above both the
root and TLD zones.

I know historically .name only allowed registration of third-level
domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs
still restrict and/or is authoritative for second-level domains as well.

At a minimum though, the one case I know off hand of a TLD being
authoritative for a second-level domain is that ICANN requires new gTLDs
are required to publish a wildcard for 90 days when they're added to the
root zone to help catch any name collisions.

Michael

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

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

[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 InternetWorking
bbiw.net

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

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

[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, I'm not seeing how you're supposed to be
able to audit them. In the case where a KSK is compromised, you could


Neither this nor certificate transparency protects against a (non-known)
private key compromise. In the case of CA's there are multiple entities
that can create a certificate that need to be audited. In DNSSEC, it is
only the zone or its parents that could create a rogue TLSA record.


I'm likely missing something obvious, by only logging DS/NS, it would be
impossible to determine if a private key is misused to serve fraudulent
records which in my mind is a bigger and much more likely/common threat
since one can simply attack a target domain and not try to compromise
the root.


This is similar to the TLS server private key being compromised without
knowledge. That is not what is being protected.


From a technical point of view, aren't there TLDs that as authoritative
for second level domains as well? The specification likely needs a way
to denote how many levels deep delegation can go. This also would be
true in the case of delegation_only being used at a level above both the
root and TLD zones.


In trying to keep this as simple as possible, the idea was to make this
concept as simple as possible. Making a promise about "every zone cut"
is much easier then making a promise to point to some more complicated
policy that might change over time, and then you have to log/audit the
changes to that policy as well.

For instance, you could have the DNSKEY flag mean "look for the
DELEGATE RRtype policy" and in there specify exceptions for your empty
non-terminals, but it just makes everything much harder.


I know historically .name only allowed registration of third-level
domains until 2009, and .uk up until 2014. I'm unsure if any of the TLDs
still restrict and/or is authoritative for second-level domains as well.


If you run .example and have registrations in *.com.example and
*.edu.example, then the easy way is to create real zones for edu.example
and com.example.


At a minimum though, the one case I know off hand of a TLD being
authoritative for a second-level domain is that ICANN requires new gTLDs
are required to publish a wildcard for 90 days when they're added to the
root zone to help catch any name collisions.


If the software allows signing the wildcard and setting the
delegation-only flag that would mean the wildcard must be
treated as BOGUS, that would not be a problem. It would still
cause problems to be found with name collisions, except now the
name SERVFAILs instead of resolving to 127.0.0.53. Both will show
the name collision as a problem.

Paul

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

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

[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
  Joao Silva Damas
  Warren Kumari
Filename: draft-ietf-dnsop-kskroll-sentinel-07.txt
Pages   : 15
Date: 2018-03-20

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain of trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a mechanism that
   will allow an end user and third parties to determine the trusted key
   state for the root key of the resolvers that handle that user's DNS
   queries.  Note that this method is only applicable for determing
   which keys are in the trust store for the root key.

   There is an example / toy implementation of this at http://www.ksk-
   test.net .

   [ This document is being collaborated on in Github at:
   https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
   recent version of the document, open issues, etc should all be
   available here.  The authors (gratefully) accept pull requests.  Text
   in square brackets will be removed before publication. ]

   [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-", "kskroll-sentinel-not-ta-"; older versions of this
   document used "_is-ta-", "_not-ta-".  Also note
   that the format of the tag-index is now zero-filled decimal.
   Apolgies to those who have began implmenting.]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-07
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-07


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

Re: [DNSOP] Terminology question: split DNS

[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
>   is notionally globally unique nevertheless has different meanings for
>   different network users.

I mostly like that, but I quibble with "source of the query".  It's
really "depending on some factor apart from the name, class, and type
of the query.  For instance, the answers might differ according to the
source of the query."  EDNS client subnet is another example, but I've
also seen things based on authentication (SIG(0) or TSIG).
Effectively, every "DNS tricks" service on the public Internet is also
a kind of split horizon.

I think we should include all of "split DNS", "split horizon", and
"split brain": they're all terms I've heard and so we ought to make
sure they're both included.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

Re: [DNSOP] Terminology question: split DNS

[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 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
> >   is notionally globally unique nevertheless has different meanings for
> >   different network users.
>
> I mostly like that, but I quibble with "source of the query".  It's
> really "depending on some factor apart from the name, class, and type
> of the query.  For instance, the answers might differ according to the
> source of the query."  EDNS client subnet is another example, but I've
> also seen things based on authentication (SIG(0) or TSIG).
> Effectively, every "DNS tricks" service on the public Internet is also
> a kind of split horizon.
>
> I think we should include all of "split DNS", "split horizon", and
> "split brain": they're all terms I've heard and so we ought to make
> sure they're both included.
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com
>
> ___
> 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] Terminology question: split DNS

[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 
> had the same observation, circa 2000).

+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.

Matt

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

Re: [DNSOP] Terminology question: split DNS

[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" was common at one time, and I think we need to say 
what it means in this context.   I think it makes sense to point out that it is 
not the currently preferred term, and that people shouldn't use it anymore, but 
it's useful to clue people in as to what it means.

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

Re: [DNSOP] DNSOP Presentation "The Camel"

[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
, camels
are extraordinary animals, well adapted to their harsh environment

and usable for many things, even war
. If the DNS is a camel,
this is great!

> "In past years, DNS has been enhanced with DNSSEC, QName
> Minimization, [...]

I dispute the idea that QNAME minimization is an addition. It is not a
change in the protocol, and it was even possible from the beginning
(Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
QNAME maximimization, it is just an accidental evolution).

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

Re: [DNSOP] DNSOP Presentation "The Camel"

[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: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
> , camels
> are extraordinary animals, well adapted to their harsh environment
> 
> and usable for many things, even war
> . If the DNS is a camel,
> this is great!
> 
>> "In past years, DNS has been enhanced with DNSSEC, QName
>> Minimization, [...]
> 
> I dispute the idea that QNAME minimization is an addition. It is not a
> change in the protocol, and it was even possible from the beginning
> (Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
> QNAME maximimization, it is just an accidental evolution).
> 
> ___
> 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] Terminology question: split DNS

[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-robin. The abstract, overarching concept is for the resolver to make a 
decision on how to answer a particular query, based on one or more attributes 
of the query transaction, including the “existential” attribute of what 
resolver was asked the question in the first place (aka “splitting”).



- Kevin

From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Ted Lemon
Sent: Tuesday, March 20, 2018 5:05 AM
To: Paul Wouters 
Cc: dnsop WG 
Subject: Re: [DNSOP] Terminology question: split DNS

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 RFC 8244 comments further in section 
4.1.1. Neither document attempts to enumerate the use cases, however.

I think that split DNS is a specific use case, and does not encompass the whole 
phenomenon. If we want to talk about the whole phenomenon, this may not be the 
place to do it—I don't actually know of a term for the general idea.. But I'm 
pretty sure that "split DNS" is not that term.

On Mar 19, 2018 21:15, "Paul Wouters" mailto:p...@nohats.ca>> 
wrote:
On Mon, 19 Mar 2018, John Heidemann wrote:
+1 on "split-horizon dns" as the term, over "split dns" and some other
neologism, on the basis of running code and existing documentation and
existing wide use.

I and google disagree:

"split dns":  72900 hits
"split horizon dns": 5640 hits


If the document is about explaining terminology, it must explain "split
dns" and can say another term for it is "split horizon dns", but not the
other way around.

I personally don't hear (or use) "split horizon dns"

Paul

___
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] DNSOP Presentation "The Camel"

[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 completely disagree
>
>Joao
>
>> On 20 Mar 2018, at 15:12, Stephane Bortzmeyer 
>wrote:
>> 
>> 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
>> , camels
>> are extraordinary animals, well adapted to their harsh environment
>>
>
>> and usable for many things, even war
>> . If the DNS is a camel,
>> this is great!
>> 
>>> "In past years, DNS has been enhanced with DNSSEC, QName
>>> Minimization, [...]
>> 
>> I dispute the idea that QNAME minimization is an addition. It is not
>a
>> change in the protocol, and it was even possible from the beginning
>> (Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT
>mandate
>> QNAME maximimization, it is just an accidental evolution).
>> 
>> ___
>> 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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 much in the s/old/new style.

  The current text in them does a use-by-reference of existing tables 
defined for other purposes.  The Update text will, instead, specify a 
requirement for adding entries in the Global or Common Second-Level 
registries.


The second level registry, though, is a problem, because it tries to 
redefine the naming rules for SRV records.  RFC 2782 said that SRV second 
level names are from the services in Assiged Numbers STD 2.  RFC 3400 
abolished STD 2 in favor of an IANA registry.  That registry, the Service 
Name and Transport Protocol Port Number Registry, was cleaned up by RFC 
6335 which reiterates the fact that the service names in that registry are 
the services used to name SRV records.  RFC 7335 states that URI records 
are named the same as SRV, and also says you can use enumservice 
_subtype._type.


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 second level names 
used for other stuff like NAPTR and _adsp._domainkey.


R's,
John

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

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

[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.  thanks.

as for enumservice, see below.




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 second level names 
used for other stuff like NAPTR and _adsp._domainkey.


No.  "Special" invites "errors", for on-going administration and 
operations.  I'm trying to make things simpler and less tangled.


We need to move away from the complexity created by having special rules 
for some entries in the registry.


Rather, we need to change the documents that are trying to be special 
to, instead, make them be mundane.  Hence the need for detailed text 
changes in the proposed, second draft.


d/

ps.  I thought the URI RR had no current actual use (or at least very 
little.)


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[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 second level names used
  for other stuff like NAPTR and _adsp._domainkey.


 No.  "Special" invites "errors", for on-going administration and operations.
 I'm trying to make things simpler and less tangled.

 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 SRV names. Importing 
a handful of names that we guess are commonly used with SRV is the worst of 
both worlds.


Either point at the real registry for SRV, or say that this explicitly 
redefines the namespace for SRV and see if dnsop will go for that.  I don't see 
any way you can just ignore RFC 6335 and its predecessors.



 ps.  I thought the URI RR had no current actual use (or at least very
 little.)


I belive that's correct, but again, either we deprecate URI or we deal with its 
naming rules.


To get rid of special, add another column to the first table which identifies 
the second level namespace.  In some cases it's empty, in some cases it's Ports 
and Services, in a few it's Enumservice, and in the rest it's the second table.


R's,
John___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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 
SRV names. Importing a handful of names that we guess are commonly used 
with SRV is the worst of both worlds.


Again: the plan is to change the SRV spec so that it doesn't try to 
inherit all those values automatically.



Either point at the real registry for SRV, or say that this explicitly 
redefines the namespace for SRV and see if dnsop will go for that.  I 
don't see any way you can just ignore RFC 6335 and its predecessors.



 ps.  I thought the URI RR had no current actual use (or at least very
 little.)


I belive that's correct, but again, either we deprecate URI or we deal 
with its naming rules.


Or, here too, we change the URI spec.


d/

--
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[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 IANA 
Service Name and Transport Protocol Port Number Registry most recently 
defined by RFC 6335.  This draft proposes that the service names now come 
from a newly defined second-level name registry in the draft. The URI 
record uses the same namespace, but nobody believes it's widely used so 
it's less of an issue.


This seems to be a large change for very little benefit, and 
unlikely to be backward compatible unless we can identify every service 
name now in use with SRV which seems unlikely.


R's,
John


G'day. This concerns an activity in dnsop, but the wg chair has quite 
reasonably suggested running a significant, proposed change past apps folk, 
since the work affects a number of existing and future apps efforts.   (In 
fact, the effort was first triggered by the DKIM work, more than 12 years 
ago...)


The domain of discourse is _underscore domain names, used for defining a 
special place to use some DNS resource records, such as TXT and SRV.


There are quite a few, existing documents that define such use, all without 
the benefit of a common registry.  Hence the danger of name collision.  The 
attrleaf effort is seeking to define a registry for holding existing 
_underscore names and defining new ones.


Besides defining the registry, the task requires updating existing 
specifications to use it.  The attrleaf draft has attempted to perform both 
tasks in a single document, but this has made for a confused and confusing 
document. (There's a larger lesson here, in spec writing...)


More recent discussions (well, actually, last August) in dnsop, pointed 
toward splitting registry definition from existing document updating, and the 
note below points to a new draft that does the first.  The note also charts 
out the plan for the updating document.


Comments?

d/

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

Date: Mon, 19 Mar 2018 17:35:29 -0700
From: Dave Crocker 
Reply-To: dcroc...@bbiw.net
Organization: Brandenburg InternetWorking
To: dnsop 

Folks,

I'll limit what should be an extensive and elaborate apology to just this: 
I'm sorry for the year of inactivity.


The -03 version should provide some useful substance of progress.

I've gone over last summer's comments and the -03 version should reflect what 
the wg agreed to.  Basically, it has been significantly streamlined, 
essentially to reflect a clean-sheet model of the world. That is, it doesn't 
deal with the ugliness that SRV, et al, created.  It merely establishes the 
two registries we need, long term, and populates them.  This document should 
have continuing utility.


-03 defines two registries, 'global' and 'second-level'.  I'm suspicious of 
how short the global one is, though it does make sense.


As noted in the document, absent major concerns with the substance of the 
document, please send me or the list s/old/new/ types of change suggestions, 
and if the change is for a reference, I'd love the suggestion to be 
 xml...



A second document will attempt to fix up the uglinesses in some existing 
documents, to get them to align with a world that has these registries. It 
should be viewed as a transitional document, though we all know how glacial 
'transitions' are in the Internet...


Deciding how to pursue that reasonably has been the effort.  The changes this 
'fixes' document defines will be to documentation, but not to existing 
operation.  Existing uses in the field will be preserved.



Here's the approach I'm taking:


1. Simple underscore usage

  For many/most specifications that use underscore naming, the text merely 
says to use it.  They are straightforward.


  These specifications need to be listed in this document, explicitly, so 
that later updates to them will know to deal with the revisions called for by 
this document.


  But this document doesn't really need s/old/new kinds of precise detail 
for them. Rather than provide precise language for changing each of these, I 
propose to provide some generic text, and generic IANA Considerations.  This 
will permit this Fixes document to be cited as Updating those RFCs.



2. SRV and URI

  These need more detailed text, very much in the s/old/new style.

  The current text in them does a use-by-reference of existing tables 
defined for other purposes.  The Update text will, instead, specify a 
requirement for adding entries in the Global or Common Second-Level 
registries.



d/


 Forwarded Message 

Name:   draft-ietf-dnsop-attrleaf
Revision:   03
Title:		DNS Scoped Data Through '_Underscore' Naming of Attribute 
Leaves

Document date:  2018-03-19
Group:  

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

[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 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
>IANA 
>Service Name and Transport Protocol Port Number Registry most recently 
>defined by RFC 6335.  This draft proposes that the service names now
>come 
>from a newly defined second-level name registry in the draft. The URI 
>record uses the same namespace, but nobody believes it's widely used so
>
>it's less of an issue.
>
>This seems to be a large change for very little benefit, and 
>unlikely to be backward compatible unless we can identify every service
>
>name now in use with SRV which seems unlikely.
>
>R's,
>John
>
>
>> G'day. This concerns an activity in dnsop, but the wg chair has quite
>
>> reasonably suggested running a significant, proposed change past apps
>folk, 
>> since the work affects a number of existing and future apps efforts. 
> (In 
>> fact, the effort was first triggered by the DKIM work, more than 12
>years 
>> ago...)
>>
>> The domain of discourse is _underscore domain names, used for
>defining a 
>> special place to use some DNS resource records, such as TXT and SRV.
>>
>> There are quite a few, existing documents that define such use, all
>without 
>> the benefit of a common registry.  Hence the danger of name
>collision.  The 
>> attrleaf effort is seeking to define a registry for holding existing 
>> _underscore names and defining new ones.
>>
>> Besides defining the registry, the task requires updating existing 
>> specifications to use it.  The attrleaf draft has attempted to
>perform both 
>> tasks in a single document, but this has made for a confused and
>confusing 
>> document. (There's a larger lesson here, in spec writing...)
>>
>> More recent discussions (well, actually, last August) in dnsop,
>pointed 
>> toward splitting registry definition from existing document updating,
>and the 
>> note below points to a new draft that does the first.  The note also
>charts 
>> out the plan for the updating document.
>>
>> Comments?
>>
>> d/
>>
>>  Forwarded Message 
>> Subject: [DNSOP] Fwd: New Version Notification for 
>> draft-ietf-dnsop-attrleaf-03.txt
>> Date: Mon, 19 Mar 2018 17:35:29 -0700
>> From: Dave Crocker 
>> Reply-To: dcroc...@bbiw.net
>> Organization: Brandenburg InternetWorking
>> To: dnsop 
>>
>> Folks,
>>
>> I'll limit what should be an extensive and elaborate apology to just
>this: 
>> I'm sorry for the year of inactivity.
>>
>> The -03 version should provide some useful substance of progress.
>>
>> I've gone over last summer's comments and the -03 version should
>reflect what 
>> the wg agreed to.  Basically, it has been significantly streamlined, 
>> essentially to reflect a clean-sheet model of the world. That is, it
>doesn't 
>> deal with the ugliness that SRV, et al, created.  It merely
>establishes the 
>> two registries we need, long term, and populates them.  This document
>should 
>> have continuing utility.
>>
>> -03 defines two registries, 'global' and 'second-level'.  I'm
>suspicious of 
>> how short the global one is, though it does make sense.
>>
>> As noted in the document, absent major concerns with the substance of
>the 
>> document, please send me or the list s/old/new/ types of change
>suggestions, 
>> and if the change is for a reference, I'd love the suggestion to be 
>>  xml...
>>
>>
>> A second document will attempt to fix up the uglinesses in some
>existing 
>> documents, to get them to align with a world that has these
>registries. It 
>> should be viewed as a transitional document, though we all know how
>glacial 
>> 'transitions' are in the Internet...
>>
>> Deciding how to pursue that reasonably has been the effort.  The
>changes this 
>> 'fixes' document defines will be to documentation, but not to
>existing 
>> operation.  Existing uses in the field will be preserved.
>>
>>
>> Here's the approach I'm taking:
>>
>>
>> 1. Simple underscore usage
>>
>>   For many/most specifications that use underscore naming, the text
>merely 
>> says to use it.  They are straightforward.
>>
>>   These specifications need to be listed in this document,
>explicitly, so 
>> that later updates to them will know to deal with the revisions
>called for by 
>> this document.
>>
>>   But this document doesn't really need s/old/new kinds of precise
>detail 
>> for them. Rather than provide precise language for changing each of
>these, I 
>> propose to provide some generic text, and generic IANA
>Considerations.  This 
>> will permit this Fixes document to be cited as Updating those RFCs.
>>
>>
>> 2. SRV and URI
>>
>>   These need more detailed text, 

Re: [DNSOP] DNSOP Presentation "The Camel"

[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 
friday the 13th part 37. there were danger signs saying "don't go here, 
there's no road, nothing to see, and no way back" and we ignored them.


see also:

https://queue.acm.org/detail.cfm?id=1242499

--
P Vixie

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

Re: [DNSOP] DNSOP Presentation "The Camel"

[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 ECS. dnssec sentinels feels like friday
> the 13th part 37. there were danger signs saying "don't go here, there's no
> road, nothing to see, and no way back" and we ignored them.

Speaking of being horrified, compare the growth rate on the graph on
slide 2 in this presentation:

https://indico.dns-oarc.net/event/28/session/11/contribution/55/material/slides/1.pdf

With the growth rate on the graph in this article for the same time
period:

https://www.recode.net/2017/4/27/15413870/comcast-broadband-internet-pay-tv-subscribers-q1-2017

A hybrid resolution model that allows leaf queries for parts of the DNS
to be resolved direct-to-authority at endpoints would be very helpful
for some use cases (especially, CDNs) and could stall the insatiable
growth in resolution capacity needed at centralized resolvers. Not to
mention, such a model would provide a solid deprecation path for ECS.

I also note most but not all of the stuff Bert is talking about in his
slide deck are on the inter-server side of the protocol (resolver to
authority). But there are also other DNS camels that have been slowly
gestating in the browser world, e.g.:

https://plus.google.com/+WilliamChanPanda/posts/FKot8mghkok

https://bugzilla.mozilla.org/show_bug.cgi?id=1434852

-- 
Robert Edmonds

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

Re: [DNSOP] DNSOP Presentation "The Camel"

[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 going with bit-string labels querying for the longest
sequence of labels on the RHS without a bit-string label would have
been been the way to get to the servers that supported bit-string labels.

DNS COOKIES has problems because there are bad implementations of EDNS
out there.  Whatever we did when introducing them ran up against broken
implementations (includes bad firewalls) (DNS COOKIES alone or EDNS(1) and
DNS COOKIES).

1. Servers that DO NOT respond to queries with EDNS options present.
2. Servers that return BADVERS, NOTIMP to EDNS queries (STD13 says return
   FORMERR to unknown queries).  RFC 6891 turned this to NOERROR on unknown
   EDNS option.
3. Servers that echo back the option, who is insane enough to send bits that
   you don’t understand them meaning of! (this one is not fatal for DNS COOKIE).
4. Servers that don’t return BADVERS to EDNS(1) + EDNS Options but return 
FORMERR.
5. Servers that don’t answer EDNS(1) + EDNS Options.
6. Load balance front ends that punted to poorly configured backends when they
   saw a EDNS option.  This leads to NXDOMAIN and other bad data being returned.
7. Other random rcodes.

All of this was testable for by developers when they introduce EDNS to
their servers. EDNS has 3 extension mechanism. That is not a lot of test
case to write and think about does the response you see make sense?

EDNS(1) query   (behaviour fully described in 
RFC 2671)
EDNS unknown option query   (behaviour fully described in 
RFC 6891)
EDNS unknown flag query (behaviour fully described in 
RFC 2671)
EDNS(1) query + EDNS unknown option (behaviour fully described in 
RFC 6891)
EDNS(1) query + EDNS unknown flag   (behaviour fully described in 
RFC 2671)
EDNS unknown option + EDNS unknown flag (behaviour fully described in 
RFC 6891)
EDNS(1) query + EDNS option + EDNS unknown flag (behaviour fully described in 
RFC 6891)

One shouldn’t have to say to DNS developers “test you servers against
possible extension methods before you ship it!"  That should be part
and parcel of adding EDNS support.

I can find servers that fail one or more of every one of these tests.

> On 21 Mar 2018, at 2:12 am, Stephane Bortzmeyer  wrote:
> 
> 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
> , camels
> are extraordinary animals, well adapted to their harsh environment
> 
> and usable for many things, even war
> . If the DNS is a camel,
> this is great!
> 
>> "In past years, DNS has been enhanced with DNSSEC, QName
>> Minimization, [...]
> 
> I dispute the idea that QNAME minimization is an addition. It is not a
> change in the protocol, and it was even possible from the beginning
> (Section 5.3.3 of [RFC1034] or Section 7.2 of [RFC1035] do NOT mandate
> QNAME maximimization, it is just an accidental evolution).
> 
> ___
> 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] Multi Provider DNSSEC Models

[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 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.

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!

Tony.
-- 
f.anthony.n.finchhttp://dotat.at___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Terminology question: split DNS

[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 potential variants"?
>
> E.g. in Paul H.'s original text
>
> Instead of: "Where a corporate network serves up partly or completely
> different DNS inside and outside its firewall."
>
> Use: "Where a corporate [enterprise?] network serves partly or completely
> different DNS based on a client's location inside or outside of a perimeter
> defined by that organization."
>
> This also gives the enterprise organization both the authority (and onus)
> to define its perimeter in a reasonable logical way.


And I would leave off "corporate", "enterprise" and any other qualification
of who's using the technology.  If there's no reason to specify the type of
network it might get used on, then we shouldn't.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[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, which 
pertains to ensuring that new behaviors use the new model.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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