Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

[Vladimír Čunát]

On 7/25/19 7:44 AM, Evan Hunt wrote:
> [... TLD XFR] However, admittedly, one probably
> wouldn't want to do it for large zones, and I don't know of any TLD's that
> allow transfer in the first place, so for the purposes of the current
> discussion, you're right enough.

I know about .se (and .nu) providing AXFR, but I suspect it might not be
worth mirroring continually in this way, even for large Swedish ISPs.  A
related thing in .cz (where to zone is not public by a rule) is that
register-managed instances are running inside ISP networks and routing
ensures they are "separate" from public instances (against attacks), but
I'm digressing...

[.se] https://zonedata.iis.se/

--Vladimir

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tony Finch]

Stephane Bortzmeyer  wrote:
>
> Seen on a slide at IETF 105 :
>
> DoTH (to talk about DoH and DoT together, as in "DoTH use TLS to
> protect DNS queries against snoopers").
>
> A nice addition? :-)

DoTH is the abbreviation I use for my documentation about encrypted DNS
since August last year, https://www.dns.cam.ac.uk/servers/doth.html

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Wight: Variable 2 to 4, becoming cyclonic 5 to 7 for a time. Smooth or slight
becoming slight or moderate. Squally thundery showers. Good, occasionally
poor.

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

Re: [DNSOP] Obsoleting DLV

[Tony Finch]

Samuel Weiler  wrote:
>
> That does not include the argument in the below bullet, which I find unclear.
> What does "name redirection" mean in this context?
>
>o  Since the zones are related to private networks, it would make
>   more sense to make the internal network more secure to avoid name
>   redirection, rather than complicate the DNS protocol.

I guess it's referring to active DNS modification attacks?

Another reason not mentioned in the draft is resilience against loss of
connectivity. If you have a local trust anchor you can validate local
zones even when you can't reach the outside world. With normal DNSSEC
validation everything is screwed if you can't obtain the chain of trust.

Of course, the network should be secure and reliable in its lower layers,
but I tend to think the DNS should be secure and reliable itself, even if
the lower layers are a bit dodgy.

Having thought about this a bit, I now prefer something like catalog zones
as a way to distribute trust anchors.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
or rough. Thundery showers. Moderate or good.

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Normen Kowalewski]

Hi Tony,

what do you use then for  "traditional DNS over UDP/TCP” aka Do53 

I had thought about one approach is to express distinction into the 
abbreviation by transport protocol, a suggestion by Puneet Sood  was to use 
DoUT instead of Do53
This would still be consistent with grouping DoT and DoH into in DoTH.

BR, Normen

> On 25. Jul 2019, at 12:54, Tony Finch  wrote:
> 
> Stephane Bortzmeyer  wrote:
>> 
>> Seen on a slide at IETF 105 :
>> 
>> DoTH (to talk about DoH and DoT together, as in "DoTH use TLS to
>> protect DNS queries against snoopers").
>> 
>> A nice addition? :-)
> 
> DoTH is the abbreviation I use for my documentation about encrypted DNS
> since August last year, https://www.dns.cam.ac.uk/servers/doth.html
> 
> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Wight: Variable 2 to 4, becoming cyclonic 5 to 7 for a time. Smooth or slight
> becoming slight or moderate. Squally 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] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tony Finch]

Normen Kowalewski  wrote:
>
> what do you use then for  "traditional DNS over UDP/TCP” aka Do53

I like Do53. I also like DONUTS (DNS over normal unencrypted TCP streams)
but that joke is a bit over-ripe.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fitzroy, Sole: Southerly veering westerly 5 to 7, occasionally gale 8 at first
in west Sole, decreasing 3 or 4 later. Rough or very rough. Thundery showers.
Good, occasionally poor.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Obsoleting DLV

[Matthijs Mekking]

Sam,


On 7/25/19 1:22 AM, Samuel Weiler wrote:
> On Tue, 2 Jul 2019, Matthijs Mekking wrote:
> 
>> Here's a draft with discussion why also the protocol should go
>> away. We would like to hear what you think about it.
> 
> The discussion of the private network use case in section 2 has two
> minor errors plus one bit that is unclear.
> 
> When we designed DLV, we certainly considered a private network use
> case.  RFC5074 does not strictly have public trust anchors take
> precedence over ("mask") DLV records [1].

I read text from RFC 6840 (Section C.3):

   When the trust anchors have come from different sources (e.g.,
   automated updates ([RFC5011]), one or more DNSSEC Lookaside
   Validation (DLV) registries ([RFC5074]), and manual configuration), a
   validator may wish to choose between them based on the perceived
   reliability of those sources.  The order of precedence might be
   exposed as a configuration option.


> I suggest replacing the text in section 2 starting with "One other..."
> with:
> 
>    One other possible reason to keep DLV is to distribute trust anchors
>    for private enterprises.  The authors are not aware of any such use
>    of DLV.
> 
> That does not include the argument in the below bullet, which I find
> unclear.  What does "name redirection" mean in this context?
> 
>    o  Since the zones are related to private networks, it would make
>   more sense to make the internal network more secure to avoid name
>   redirection, rather than complicate the DNS protocol.

Thanks, I made the change in the GitHub repository (BTW I also resolved
Paul Wouters nit comments from earlier).


Best regards,

Matthijs



> -- Sam
> 
> 
> [1] Specifically, 5074 says to use public trust anchors first.  If they
> give a validation result other than "Secure", then do DLV processing. 
> I'm not 100% sure of how BIND's logic works here.
> 
> ___
> 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] Obsoleting DLV

[Mark Andrews]

> On 25 Jul 2019, at 9:10 pm, Tony Finch  wrote:
> 
> Samuel Weiler  wrote:
>> 
>> That does not include the argument in the below bullet, which I find unclear.
>> What does "name redirection" mean in this context?
>> 
>>   o  Since the zones are related to private networks, it would make
>>  more sense to make the internal network more secure to avoid name
>>  redirection, rather than complicate the DNS protocol.
> 
> I guess it's referring to active DNS modification attacks?
> 
> Another reason not mentioned in the draft is resilience against loss of
> connectivity. If you have a local trust anchor you can validate local
> zones even when you can't reach the outside world. With normal DNSSEC
> validation everything is screwed if you can't obtain the chain of trust.
> 
> Of course, the network should be secure and reliable in its lower layers,
> but I tend to think the DNS should be secure and reliable itself, even if
> the lower layers are a bit dodgy.
> 
> Having thought about this a bit, I now prefer something like catalog zones
> as a way to distribute trust anchors.

You just slave the private DLV registry and load the trust anchors from that
after validating each DLV RRset.

> Tony.
> -- 
> f.anthony.n.finchhttp://dotat.at/
> Lundy, Fastnet: Variable 2 to 4 in east Lundy, otherwise southerly veering
> southwesterly 4 to 6. Slight or moderate in east Lundy, but elsewhere moderate
> or rough. Thundery showers. Moderate or good.
> 
> ___
> 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] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Paul Wouters]

On Thu, 25 Jul 2019, Tony Finch wrote:


what do you use then for  "traditional DNS over UDP/TCP” aka Do53


I like Do53.


I dislike Do53, because then we should really have Do53-over-TCP as DoT
and Do53-over-https as DoH. If we call it "DNS-over-TCP" than really
what we are doing is running (classic) DNS over TCP, and we shouldn't
midway the discussion rename "DNS" to "Do53".

Paul

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

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Paul Hoffman]

Do53 was invented as a way of saying "DNS format and transport as described in 
RFC 1034 and RFC 1035, with updates". If anyone has a better shorthand for that 
than "Do53", that's great. I believe a shorthand is needed, particularly for 
publications that are discussiong multiple transports.

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tony Finch]

Paul Wouters  wrote:
>
> I dislike Do53, because then we should really have Do53-over-TCP as DoT
> and Do53-over-https as DoH. If we call it "DNS-over-TCP" than really
> what we are doing is running (classic) DNS over TCP, and we shouldn't
> midway the discussion rename "DNS" to "Do53".

These abbreviations are about identifying the transport that is being used
for the DNS messages. One problem with Do53 is that it isn't specific
about the transport, because it covers both UDP and TCP. But it's a handy
abbreviation for DNS over traditional transports. It doesn't identify DNS
as a whole, just the framing of DNS messages in UDP and TCP.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
a just distribution of the rewards of success

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[George Michaelson]

I dislike the rate of change in terminology, and what feels like
intrusion of somebodys favourite term, which is not actually
reflective of widespread use in DNS discussion.

I have never said DO53 and I don't know anyone who has. Every other
term of art, has sound basis. This feels like a bad backronym and we
are now moving from a terminology to an emerging AI aware ontology of
phoneme-building.

Can we stick to acronyms which really exist? Is this in a document of
substance and I missed something? (very possible)

A dictionary model I like (btw) is to show the earliest published use
of the form, to set its context and definitions as they emerge.

-G

On Thu, Jul 25, 2019 at 10:37 AM Tony Finch  wrote:
>
> Paul Wouters  wrote:
> >
> > I dislike Do53, because then we should really have Do53-over-TCP as DoT
> > and Do53-over-https as DoH. If we call it "DNS-over-TCP" than really
> > what we are doing is running (classic) DNS over TCP, and we shouldn't
> > midway the discussion rename "DNS" to "Do53".
>
> These abbreviations are about identifying the transport that is being used
> for the DNS messages. One problem with Do53 is that it isn't specific
> about the transport, because it covers both UDP and TCP. But it's a handy
> abbreviation for DNS over traditional transports. It doesn't identify DNS
> as a whole, just the framing of DNS messages in UDP and TCP.
>
> Tony.
> --
> f.anthony.n.finchhttp://dotat.at/
> a just distribution of the rewards of success
>
> ___
> 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] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Paul Wouters]

On Thu, 25 Jul 2019, Paul Hoffman wrote:


Do53 was invented as a way of saying "DNS format and transport as described in RFC 1034 and 
RFC 1035, with updates". If anyone has a better shorthand for that than "Do53", 
that's great. I believe a shorthand is needed, particularly for publications that are discussiong 
multiple transports.


Classic DNS or Native DNS ?

Or just "DNS over UDP/TCP" ? It's not that long to use.

Paul

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

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Martin Hoffmann]

Paul Hoffman wrote:
> Do53 was invented as a way of saying "DNS format and transport as
> described in RFC 1034 and RFC 1035, with updates". If anyone has a
> better shorthand for that than "Do53", that's great. I believe a
> shorthand is needed, particularly for publications that are
> discussiong multiple transports.

I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

Kind regards,
Martin

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

Re: [DNSOP] proposal: Covert in-band zone data

[Samuel Weiler]

Both docs in this set should say something more about authenticity and 
integrity, particularly since DNSSEC cannot be used to establish the 
same.  (The security considerations sections mention confidentiality. 
Authenticity and integrity are likely important for most use cases.)


On the whole, I'm not a fan of this overall approach, though I'm 
willing to wait and see.


-- Sam

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

Re: [DNSOP] [dbound] [art] not DNAME, was Related Domains By DNS (RDBD) Draft (fwd)

[Samuel Weiler]

Moving the discussion to DNSOP, as requested in Montreal.

I continue to be concerned that the RDBD draft is:

1) Biting off too much.  As in the thread below, I think DBOUND failed 
because it attempted to be all things to all people.


2) Failing to address the full-stack implications.  Some use cases I 
heard at the microphone in Montreal involve automated processing and 
have security impacts along the stack.  Yet the doc admits:


   It is not a goal of this specification to provide a high-level of
   assurance as to whether or not two domains are definitely related,

Data formats are simple.  Processing rules for them are hard.
Specifying the former without the latter leads to breakage.  Let's 
pick one use case and then spec out the logic for satisfying it.


-- Sam


-- Forwarded message --
Date: Fri, 8 Mar 2019 15:30:03 -0500 (EST)
From: Samuel Weiler 
To: dbo...@ietf.org
Cc: Stephen Farrell 
Subject: Re: [dbound] [art] [DNSOP]  not DNAME,
was Related Domains By DNS (RDBD) Draft

On Fri, 1 Mar 2019, Suzanne Woolf wrote:

My memories of DBOUND are not reliable but I do recall a distinct sense that 
people thought they were talking about "the same thing" and repeatedly 
discovering that maybe they weren’t.


Accordingly, I’d like to see an example or two of how you’d expect an 
application to use the kind of connection between domains established by the 
RDBD mechanism.


+1.

Reading back through the end-of-DBOUND discussions from 2016, I'm having these 
same thoughts.


Digging into two details:

I don't understand the value added by publishing new keys - and signing with a 
new signature format - when there's no evident way to bootstrap trust in those 
keys.  Could you explain (again) the value being added?  (I see value from 
using DNSSEC, but if we insist on DNSSEC, we don't need these other pieces.)


The DBOUND problem statement draft covered a number of "use cases that seem 
intuitively similar [but] actually aren't" (quoting Suzanne). Even so, it made 
a general recommendation in the security considerations section: "In general, 
positive assertions about another name should never be accepted without 
querying the other name for agreement."  I'm surprised to not see that 
reflected in this draft. Indeed, the discussion here suggests that this is an 
explicit non-requirement.  So I want to know more about the use case(s) you're 
tackling and why checking the symmetry of assertions is not necessary.


https://www.ietf.org/archive/id/draft-sullivan-dbound-problem-statement-02.txt

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

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

[Shumon Huque]

(I'll ignore the question of the cost/benefits of running a local root copy
for now and just focus on the technical topic below).

On Thu, Jul 25, 2019 at 1:45 AM Evan Hunt  wrote:

>
> Third, and more pertinently, this work may have spin-off benefits.  I've
> thought for a long time that a mechanism to use DNSSEC to validate zone
> transfers would be a useful addition to BIND.  While that feature, per se,
> still doesn't exist, the mirror zone developemnt invovled writing a lot the
> code that's needed for it, and I expect it to exist fairly soon. So I don't
> think 7706 will have been a waste of time even if it turns out not to have
> been particularly effective at its original use case.
>

Evan,

Can you elaborate on how you plan to do this?

One of the things that has always annoyed me about RFC7706 (and its
successor I-D) is that it offers no suggestions on how to validate that you
got a correct copy of the entire root zone. The example configurations
given in the appendix are all insecure - they rely on unauthenticated zone
transfer. The one example that is likely secure is the one given for the
Knot resolver, but that's because it is decidedly not using 7706, and
instead uses cache prefill from a root zone copy located at a well known
HTTPS authenticated destination. If an operator using 7706 is targeted by a
glue spoofing attack, then it will likely require manual intervention of
the resolver operator to recover. Whereas without 7706, I assume robust
resolvers may be able to recover by themselves by retrying other root
servers, if they can determine that they were directed to bogus servers in
the case of signed child zones.

If you plan to use DNSSEC to validate the zone, I assume you might be
thinking of either (1) signed ZONEMD, although that does not exist yet for
the root zone, or (2) proposing to re-design child NS and glue records so
that they can be signed. But perhaps there are other ways that I haven't
thought of.

Recall that there have been extensive discussions on this topic during the
initial debate on ZONEMD, which I won't rehash here. But I want to note
that there is now a draft on XFR over TLS, which may offer a new channel
protection possibility to address this issue (assuming it makes progress,
and there is implementation interest on the part of root zone operators).

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

[DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-02.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   : Terminology for DNS Transports and Location
Author  : Paul Hoffman
Filename: draft-hoffman-dns-terminology-ter-02.txt
Pages   : 3
Date: 2019-07-25

Abstract:
   This document adds terms and abbreviations to "DNS Terminology" (RFC
   8499) that relate to DNS running over various transports, as well as
   terms and abbreviations for DNS resolution at traditional and non-
   traditional locations.

   [[ This is an early attempt at these terms.  They will probably be
   improved over time. ]]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hoffman-dns-terminology-ter/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hoffman-dns-terminology-ter-02
https://datatracker.ietf.org/doc/html/draft-hoffman-dns-terminology-ter-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-hoffman-dns-terminology-ter-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

Re: [DNSOP] some 2015-era thoughts about RFC 7706 -bis

[Evan Hunt]

On Thu, Jul 25, 2019 at 11:15:22AM -0400, Shumon Huque wrote:
> Can you elaborate on how you plan to do this?
> 
> One of the things that has always annoyed me about RFC7706 (and its
> successor I-D) is that it offers no suggestions on how to validate that you
> got a correct copy of the entire root zone. The example configurations
> given in the appendix are all insecure - they rely on unauthenticated zone
> transfer.

I wouldn't say "insecure", exactly, but you're partly right - in the
examples in RFC 7706, the zone transfer itself would be insecure, but once
the zone was transfered, answers would still be validated. That's why the
local mirror is set up in a separate auth server or view - it prevents
answers from being returned as authoritative data, without validation.  So
clients do still have some protection; the problem is, there's no automatic
recovery if the transfer is bad. Clients would start to SERVFAIL and the
local root wouldn't know it had a problem.

BIND 9 mirror zones address this in two ways: first, the zone is validated
when transferred; the transfer is rejected if any bogus RRsets are found or
if the NSEC chain is incompete. Second, if the zone is unusable, either
because it failed to transfer in the first place or because it expired
without a successful refresh, named automatically fails over to normal
recursion to the root.

This doesn't address the problem of glue and delegation NS records, but
those aren't subject to DNSSEC validation during normal recursion anyway,
so clients aren't substantially worse off. The transfer does represent an
attack surface that wasn't there before, but it would be an extremely
difficult one to exploit. That said, ZONEMD or XoT would improve things
further, and I hope the root zone will adopt one or both.

In the more general case for validating zone transfers, the idea is to have
a sanity check that signatures are good before a secondary starts serving a
zone.  This is mostly about preventing self-foot-shooting incidents; ZONEMD
isn't strictly necessary for it.

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

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Evan Hunt]

On Thu, Jul 25, 2019 at 03:36:39PM +0100, Tony Finch wrote:
> These abbreviations are about identifying the transport that is being used
> for the DNS messages. One problem with Do53 is that it isn't specific
> about the transport, because it covers both UDP and TCP. But it's a handy
> abbreviation for DNS over traditional transports. It doesn't identify DNS
> as a whole, just the framing of DNS messages in UDP and TCP.

The other day at ANRW, a paper was presented that compared performance of
DoH, DoT, and Do53. It was unclear to me what transport the authors had
used for their Do53 measaurements - and it makes a significant difference.
I don't know, even now, whether the comparison was apples-to-apples or not.

"Do53" is a handy abbreviation, but I'm concerned that using it as a
coequal peer of DoT and DoH will lead to fuzzy thinking.

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

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

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

> I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

I agree with "encrypted DNS" because that makes the meaning (DoH or DoT or X : 
X is some new way to encrypt DNS) clear when it is intended, and saying DoH/DoT 
when that is really intended (just those two and not any other encrypted 
version of DNS) isn't that burdensome. DoTH can be confused with some new 
specific protocol "DNS over T H" since that's what the other Do* 
patterns indicate.

However, I think Do53 makes sense as it includes any use of DNS over port 53 
and fits the Do* pattern used by other DNS protocols. This would only become 
confusing in the event we end up introducing an encrypted DNS protocol that 
also operates over port 53 which seems incredibly unlikely.

Thanks,
Tommy

From: DNSOP  on behalf of Martin Hoffmann 

Sent: Thursday, July 25, 2019 7:52 AM
To: Paul Hoffman 
Cc: dnsop 
Subject: Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01..txt

Paul Hoffman wrote:
> Do53 was invented as a way of saying "DNS format and transport as
> described in RFC 1034 and RFC 1035, with updates". If anyone has a
> better shorthand for that than "Do53", that's great. I believe a
> shorthand is needed, particularly for publications that are
> discussiong multiple transports.

I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

Kind regards,
Martin

___
DNSOP mailing list
DNSOP@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C6e63764eb3524be5ccc108d7110fd3cf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996631991661796&sdata=8bdbQf45P7S53XE4DLJ9H9m0di%2FgbykgOrCPXktNdtM%3D&reserved=0
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Joe Abley]

On Jul 25, 2019, at 19:14, Tommy Jensen <
Jensen.Thomas=40microsoft@dmarc.ietf.org> wrote:

> I still maintain that having descriptive terms should be preferable

over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

I agree with "encrypted DNS" because that makes the meaning (DoH or DoT or
X : X is some new way to encrypt DNS) clear when it is intended


Like DNSCrypt with UDP transport?

Or like an apex TXT record that contains a one-time token to authenticate a
zone to a service?

I spent some time this week at the Africa DNS Forum in Botswana promoting
the idea that the concept of "DNS Security" is usefully more broad than
just DNSSEC. Perhaps we need a corresponding effort to broaden "DNS
Encryption" beyond DoH and DoT?


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

Re: [DNSOP] proposal: Covert in-band zone data

[Ólafur Guðmundsson]

On Mon, Jul 22, 2019 at 2:00 PM Dan Mahoney  wrote:

> After a hallway conversation with Evan yesterday, I wanted to clarify a
> few things that I came across when working on this.  Point one is the
> use-case of NOTE.  Point two is an argument for the general usefulness of
> a COVERT record.
>
> On NOTE:
>
> I am an admin who uses my zone files as a source of truth -- which
> include comments, versioning, and formatting.  (I also commit to version
> control, and there's a $Id: $ tag in my zonefiles.)
>
> I'd like the ability to have some degree of human-intended metadata
> survive an AXFR, to be able to promote a slave copy of a zone to being
> master, promote versioning, and keep my zonefiles readable within my
> processes.  I am not suggesting NOTE be anything but exactly what its name
> implies: not a hook for some kind of inter-server transfers or private
> keys, just things like "remove after 1/1/2020" or "allocated to group foo"
> or even "generated from config DB on $date".  I especially intend to
> state, perhaps with stronger language, that NOTE SHOULD NOT used for
> things intended to be machine-parsed the way we've overloaded TXT.
>
> I'm an operator.  Among my credentials: I operate personal infrastructure,
> ISC's infrastructure, and a nontrivial amount of the infrastructure for
> the root zone.  This is the operational input I'm told the IETF community
> craves and suggests an issue of not getting until after a standard passes..
>
>
Dan,
I think all of this makes sense, what does not make sense is to stuff this
into old "AXFR/IXFR" semantics.
The draft is already changing how "upstream" deals with "downstream" in
this proposal.
My suggestion is to take a step back and say we have outgrown AXFR  and we
need better mechanism to sync
various servers.
Lets start work on a new "SYNC Name servers" protocol that can meet modern
requirements
My list of features that I would like to see:
   -- DNSSEC awareness (MIXFR)
  -- Long lived TLS connections that allow
--- updates of multiple zones
--  adding and removing of zones
-- Configuring service parameters: online-keys, ACL's, logging
status ..
-- even send back logging information

This would allow us to get rid of Notify, catalog zones, and few other
warts that have been added on over the years.

Olafur



> Best,
>
> -Dan
>
> On Sat, 6 Jul 2019, Evan Hunt wrote:
>
> > Colleages,
> >
> > Some years ago, Dan Mahoney and I submitted a draft describing a proposed
> > mechanism for storing confidential zone comments alongside normal zone
> > data - a NOTE RR, which would be transferrable from primary to secondary
> > servers, but not accessible to ordinary DNS queries.  It generated some
> > iniital interest, but not much momentum, and we let the proposal lapse.
> >
> > More recently, Witold Krecicki had a very similar idea for a mechanism to
> > disseminate private key data between primary and secondary servers.  We
> > talked it over and decided to expand the NOTE record semantics into a
> > generic method for storing and transferring covert in-band zone data.
> >
> > The generic mechanism is described in draft-krecicki-dns-covert-00. It
> > calls for the allocation of a range of "Covert-RR" type code values,
> > which would have restrictions on their dissemenination.  A primary server
> > implementing Covert-RR types must not allow them to queried, nor to be
> > transerred to a secondary server unless that server indicates via an EDNS
> > option that it *also* understands Covert record semantics and will not
> > transfer the data to any peer that doesn't.
> >
> > The original NOTE RR draft has been shrunk down and rewritten as a
> > proposed use case for Covert RR's.  Additional use cases will be coming
> > in the future; in particular, draft-pusateri-dnsop-update-timeout seems
> > like it might be a good candidate.
> >
> > Details are below. Please have a look.  Thanks!
> >
> > 
> > Name: draft-krecicki-dns-covert
> > Revision: 00
> > Title:Domain Name System (DNS) Resource Record types for
> transferring covert information from primary to secondaries
> > Document date:2019-07-06
> > Group:Individual Submission
> > Pages:6
> > URL:
> https://www.ietf.org/internet-drafts/draft-krecicki-dns-covert-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-krecicki-dns-covert/
> > Htmlized:   https://tools.ietf.org/html/draft-krecicki-dns-covert-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-krecicki-dns-covert
> >
> >
> > Abstract:
> >The Domain Name System (DNS) Resource Record TYPEs IANA registry
> >reserves the range 128-255 for Q-TYPEs and Meta-TYPEs [RFC6895] -
> >Resource Records that can only be queried for or contain transient
> >data associated with a particular DNS message.
> >
> >This document reserves a range of RR TYPE numbers for Covert-TYPEs -
> >types that are an integral part of t

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Paul Wouters]

On Thu, 25 Jul 2019, Evan Hunt wrote:


"Do53" is a handy abbreviation, but I'm concerned that using it as a
coequal peer of DoT and DoH will lead to fuzzy thinking.


Indeed. U53, T53 and UT53 (or 53U, 53T, 53UT) would be far more informative.

Paul

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

Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

Good point ("s/new/other" in my definition of "encrypted DNS"). And I agree, 
"encrypted DNS" is a superset of "DoH and DoT" but not the other way around.

Thanks,
Tommy

From: Joe Abley 
Sent: Thursday, July 25, 2019 10:24 AM
To: Tommy Jensen 
Cc: Martin Hoffmann ; Paul Hoffman 
; dnsop 
Subject: Re: [DNSOP] [Ext] I-D Action: draft-hoffman-dns-terminology-ter-01..txt

On Jul 25, 2019, at 19:14, Tommy Jensen 
mailto:Jensen.Thomas=40microsoft@dmarc.ietf.org>>
 wrote:

> I still maintain that having descriptive terms should be preferable
over an abundance of abbreviations, particular in documents. In this
case, why not "classic DNS" or "traditional DNS"? Likewise, "encrypted
DNS" instead of DoTH.

I agree with "encrypted DNS" because that makes the meaning (DoH or DoT or X : 
X is some new way to encrypt DNS) clear when it is intended

Like DNSCrypt with UDP transport?

Or like an apex TXT record that contains a one-time token to authenticate a 
zone to a service?

I spent some time this week at the Africa DNS Forum in Botswana promoting the 
idea that the concept of "DNS Security" is usefully more broad than just 
DNSSEC. Perhaps we need a corresponding effort to broaden "DNS Encryption" 
beyond DoH and DoT?


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

Re: [DNSOP] proposal: Covert in-band zone data

[Paul Wouters]

On Thu, 25 Jul 2019, Ólafur Guðmundsson wrote:


I think all of this makes sense, what does not make sense is to stuff this into old 
"AXFR/IXFR" semantics. 
The draft is already changing how "upstream" deals with "downstream" in this 
proposal. 
My suggestion is to take a step back and say we have outgrown AXFR  and we need 
better mechanism to sync 
various servers. 
Lets start work on a new "SYNC Name servers" protocol that can meet modern 
requirements 


+1

Paul

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Tommy Jensen]

The 53U, 53T, 53UT ordering makes more sense to me, since it aligns with the 
DoH/DoT alignment of protocol indicator followed by transport indicator 
ordering.

From: DNSOP  on behalf of Paul Wouters 
Sent: Thursday, July 25, 2019 10:29 AM
To: Evan Hunt 
Cc: dnsop 
Subject: Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

On Thu, 25 Jul 2019, Evan Hunt wrote:

> "Do53" is a handy abbreviation, but I'm concerned that using it as a
> coequal peer of DoT and DoH will lead to fuzzy thinking.

Indeed. U53, T53 and UT53 (or 53U, 53T, 53UT) would be far more informative..

Paul

___
DNSOP mailing list
DNSOP@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca83a347f25ef461c263708d71125b5a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996725966251868&sdata=l29PLDfowCk0761lJXtpG4%2FZEvgf8nSkmKWLZ8HxcFE%3D&reserved=0
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] proposal: Covert in-band zone data

[Evan Hunt]

On Thu, Jul 25, 2019 at 01:25:52PM -0400, Ólafur Guðmundsson wrote:
> Dan,
> I think all of this makes sense, what does not make sense is to stuff this
> into old "AXFR/IXFR" semantics.
> The draft is already changing how "upstream" deals with "downstream" in
> this proposal.
> My suggestion is to take a step back and say we have outgrown AXFR  and we
> need better mechanism to sync
> various servers.
> Lets start work on a new "SYNC Name servers" protocol that can meet modern
> requirements
> [...]

We're running out of bar bof opportunities in Montreal, but I'd be happy
to discuss this further.

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

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

Re: [DNSOP] proposal: Covert in-band zone data

[Tim Wattenberg]

> Am 25.07.2019 um 13:25 schrieb Ólafur Guðmundsson 
> :
> 
> I think all of this makes sense, what does not make sense is to stuff this 
> into old "AXFR/IXFR" semantics. 
> The draft is already changing how "upstream" deals with "downstream" in this 
> proposal. 
> My suggestion is to take a step back and say we have outgrown AXFR  and we 
> need better mechanism to sync 
> various servers. 
> Lets start work on a new "SYNC Name servers" protocol that can meet modern 
> requirements 

+1

– Tim

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] proposal: Covert in-band zone data

[Paul Ebersman]

olafur> My suggestion is to take a step back and say we have outgrown
olafur> AXFR and we need better mechanism to sync various servers.

olafur> Lets start work on a new "SYNC Name servers" protocol that can
olafur> meet modern requirements

paulw> +1

+1.

I think we're allowed to replace something after 20+ years ;)

Things that might go in:

  - AXFR/IXFR/*XFR
  - zone meta data (create/modify/delete/digital-sigs)
  - "covert" data

My only hesitation is we seem to slow logarithmically as we increase
scope but this sure seems like the right direction.

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

Re: [DNSOP] I-D Action: draft-hoffman-dns-terminology-ter-01.txt

[Brian Dickson]

As long as we avoid 53Cr.
(One of the isotopes of chromium happens to have atomic mass of 53 - funny
coincidence, what with chrome/chromium being google things.)
(Particularly if it is hexavalent.)

Brian

On Thu, Jul 25, 2019 at 1:34 PM Tommy Jensen  wrote:

> The 53U, 53T, 53UT ordering makes more sense to me, since it aligns with
> the DoH/DoT alignment of protocol indicator followed by transport indicator
> ordering.
> --
> *From:* DNSOP  on behalf of Paul Wouters <
> p...@nohats.ca>
> *Sent:* Thursday, July 25, 2019 10:29 AM
> *To:* Evan Hunt 
> *Cc:* dnsop 
> *Subject:* Re: [DNSOP] I-D Action:
> draft-hoffman-dns-terminology-ter-01.txt
>
> On Thu, 25 Jul 2019, Evan Hunt wrote:
>
> > "Do53" is a handy abbreviation, but I'm concerned that using it as a
> > coequal peer of DoT and DoH will lead to fuzzy thinking.
>
> Indeed. U53, T53 and UT53 (or 53U, 53T, 53UT) would be far more
> informative..
>
> Paul
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
>
> https://nam06..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Ca83a347f25ef461c263708d71125b5a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636996725966251868&sdata=l29PLDfowCk0761lJXtpG4%2FZEvgf8nSkmKWLZ8HxcFE%3D&reserved=0
> 
> ___
> 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-hoffman-dns-terminology-ter-01.txt

[Paul Wouters]

> On Jul 25, 2019, at 06:54, Tony Finch  wrote:
> 
> Stephane Bortzmeyer  wrote:
>> 
>> Seen on a slide at IETF 105 :
>> 
>> DoTH (to talk about DoH and DoT together, as in "DoTH use TLS to
>> protect DNS queries against snoopers").
>> 
>> A nice addition? :-)
> 
> DoTH is the abbreviation I use for my documentation about encrypted DNS

It might be useful in writing but when speaking it is too similar to DoT in 
pronunciation, especially for those whose English isn’t a first language.

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