> 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
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 mo
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 somethi
> 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
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
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
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 hav
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 ;
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
__
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.
>
> O
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, "en
> 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 o
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
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 roo
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: dr
(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 mechani
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
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
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
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
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 back
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 abbr
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.
--Pa
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 (cla
> 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
>>
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
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 t
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 D
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
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, http
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)
31 matches
Mail list logo
