[DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt

[John C Klensin]

Taking another look at this now that the IETF dust has settled.

First, when I wrote my earlier note on the 21st, I had just
glanced through the spec, not studied it, and was under the
impression that either the SRV entries and registry would not be
affected or that all entries in the SRV registry would be folded
into the new one.  The former would be fine, the latter
plausible if it could be done smoothly but I gather there are
reasons why it cannot.

Two additional, possibly more important, thoughts after reading
-05 more closely...

(1) The introductory material in the I-D seems to imply that use
of labels styled with "_" is a reasonable alternative to
creating a new label type.  My impression has been that, while
there is nothing we can change about what is done and deployed,
there has been community consensus that it is a bad idea and
that changes have been made to the procedures for defining and
registering new RRTYPEs to reinforce the principle that new
RRTYPEs should be used and to make their use easier.
"Significantly challenging over the life of the DNS" is
undoubtedly correct, but that should not be, and presumably is
not, the situation today or in recent years.   I believe this
document should not be advanced until that material is changed
to be clear that use of underscore or similar conventions may be
a reality but is not a desirable substitute for separate RRTYPEs
(with or without that convention as appropriate).

(2) I'd encourage people to think through another possibility.
I'm not sure it is the right answer, but it is worth more
consideration than this draft (at least at -05) appears to be
giving it.  The issues associated with QTYPE=ANY
notwithstanding, it is not clear to me that the set of labels
starting with "_" constitute a namespace, any more than the set
of labels starting with "xn--" do.  It is just a naming
convention that identifies the labels as keywords with defined
meaning.   From that point of view, namespaces are actually
per-RRTYPE and the right way to design this document would be as
a registry of "_"-introduced keywords, with subregistries for
each RRTYPE with which those keywords can be used.  Given the
way the DNS works, at least as I understand it, there is no DNS
protocol conflict between
 _foo IN XYZ Data1
and
 _foo IN ABC Data2

Using the same keyword in both cases may be a bad idea but the
zone files don't care and, given that queries are typically made
for QNAME and QTYPE (etc.) and not the name alone (i.e., with
QTYPE=ANY) except for other purposes, I see some advantages of
[sub]registry-per-RRTYPE rather than pretending that every label
starting with "_" is the same namespace.  Of course, one of them
is that there is no need to treat SRV as a special, legacy, case
or even debate that.   The coverage of the current document
would be simply a subregistry for SRV (reorganized from the
current registry, but that is simply an IANA organizational
matter, not a change to what is registered, protocols, etc.,
plus a subregistry for RRTYPE=TXT and provisions for other
subregistries as might be needed in the future.

Organizing things that way would have at least one additional
advantage: while FCFS may be appropriate for some RRTYPEs, other
procedures may be appropriate for others.  In a way, SRV is a
good example of that distinction.

Again, that might not be the right thing to do on balance, but I
think it should be examined carefully as an alternative to
trying to treat "everything starting with '_' as long as it
occupies a particular place in the tree" as a namespace.

best,
john

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

Re: [DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Vixie]

Paul Hoffman wrote:

Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining
a new media type seems like overkill, particularly given that it will
be transporting *the exact same* data as an existing media type.
Instead, an optional parameter could be added to the
application/dns-udpwireformat registration in the DOH document.

Proposal:

=

In the media type definition, change "Optional parameters" to:

Optional parameters: original_transport original_transport has two
defined values, "udp" and "tcp". This is only expected to be used by
servers.


s/servers/proxies/


Also in the the DOH document, under Operational Considerations, we
would add:

This protocol does not define any use for the original_transport
optional parameter of the application/dns-udpwireformat media type.

=

Then draft-ietf-dnsop-dns-wireformat-http could define the use of
that optional parameter as it sees fit.


so this would look like

content-type: application/dns-udpwireformat; tcp

?

--
P Vixie

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

[DNSOP] Alternate proposal for transport indication in draft-ietf-dnsop-dns-wireformat-http

[Paul Hoffman]

Given the use case in draft-ietf-dnsop-dns-wireformat-http, defining a new 
media type seems like overkill, particularly given that it will be transporting 
*the exact same* data as an existing media type. Instead, an optional parameter 
could be added to the application/dns-udpwireformat registration in the DOH 
document.

Proposal:

=

In the media type definition, change "Optional parameters" to:

Optional parameters: original_transport
   original_transport has two defined values, "udp" and "tcp".
   This is only expected to be used by servers.

Also in the the DOH document, under Operational Considerations, we would add:

This protocol does not define any use for the original_transport optional
parameter of the application/dns-udpwireformat media type. 

=

Then draft-ietf-dnsop-dns-wireformat-http could define the use of that optional 
parameter as it sees fit.

--Paul Hoffman

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

Re: [DNSOP] Phishing? was Fwd: nthpermutation

[Michael StJohns]

On 3/25/2018 6:15 PM, Ólafur Guðmundsson wrote:

Mike,

This is a domain extortion attempt, they want you to buy the domain at 
inflated price

https://security.stackexchange.com/questions/56290/is-this-domain-registration-service-email-a-scam#56304

Olafur


Thanks! I figured it had to be something like that Mike




On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns 
mailto:m...@nthpermutation.com>> wrote:


Apologies for dumping this here, but I figured if anyone had a
clue they'd probably be on this list. Is anyone familiar with
mopo-io.com.cn ? Is this a legitimate email
(or company)?  If not, its one of the better phishing emails I've
seen.

Thanks - Mike



 Forwarded Message 
Subject:nthpermutation
Date:   Thu, 22 Mar 2018 11:59:50 +0800
From:   Sharon Han  
To: msj  



(Letter to the President or Brand Owner, thanks)

Dear Sir/Madam,

We are the department of Asian Domain Registration Service in
China. I have something to confirm with you. We formally received
an application on March 22, 2018 that a company which self-styled
"Gulf East Ltd " were applying to register "nthpermutation" as
their Brand Name and some domain names through our firm.

Now we are handling this registration, and after our initial
checking, we found the name were similar to your company's, so we
need to check with you whether your company has authorized that
company to register these names. If you authorized this, we will
finish the registration at once. If you did not authorize, please
let us know within 5 workdays, so that we will handle this issue
better. After the deadline we will unconditionally finish the
registration for "Gulf East Ltd ". Looking forward to your prompt
reply.

Best regards,

Sharon Han
Tel: 0086.5516349 1192
Fax: 0086.5516349 1192
Address:No.313, Changjiang Zhonglu, Hefei 23 China


___
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] Phishing? was Fwd: nthpermutation

[Ólafur Guðmundsson]

Mike,

This is a domain extortion attempt, they want you to buy the domain at
inflated price
https://security.stackexchange.com/questions/56290/is-this-domain-registration-service-email-a-scam#56304

Olafur


On Sun, Mar 25, 2018 at 11:04 PM, Michael StJohns 
wrote:

> Apologies for dumping this here, but I figured if anyone had a clue they'd
> probably be on this list. Is anyone familiar with mopo-io.com.cn?   Is
> this a legitimate email (or company)?  If not, its one of the better
> phishing emails I've seen.
>
> Thanks - Mike
>
>
>  Forwarded Message 
> Subject: nthpermutation
> Date: Thu, 22 Mar 2018 11:59:50 +0800
> From: Sharon Han  
> To: msj  
>
> (Letter to the President or Brand Owner, thanks)
>
> Dear Sir/Madam,
>
> We are the department of Asian Domain Registration Service in China. I
> have something to confirm with you. We formally received an application on
> March 22, 2018 that a company which self-styled "Gulf East Ltd " were
> applying to register "nthpermutation" as their Brand Name and some domain
> names through our firm.
>
> Now we are handling this registration, and after our initial checking, we
> found the name were similar to your company's, so we need to check with you
> whether your company has authorized that company to register these names.
> If you authorized this, we will finish the registration at once. If you did
> not authorize, please let us know within 5 workdays, so that we will handle
> this issue better. After the deadline we will unconditionally finish the
> registration for "Gulf East Ltd ". Looking forward to your prompt reply.
>
>
>
> Best regards,
>
> Sharon Han
> Tel: 0086.5516349 1192
> Fax: 0086.5516349 1192
> Address:No.313, Changjiang Zhonglu, Hefei 23 China
>
> ___
> 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] Phishing? was Fwd: nthpermutation

[Michael StJohns]

Apologies for dumping this here, but I figured if anyone had a clue 
they'd probably be on this list. Is anyone familiar with 
mopo-io.com.cn?   Is this a legitimate email (or company)?  If not, its 
one of the better phishing emails I've seen.


Thanks - Mike



 Forwarded Message 
Subject:nthpermutation
Date:   Thu, 22 Mar 2018 11:59:50 +0800
From:   Sharon Han 
To: msj 



Mail

(Letter to the President or Brand Owner, thanks)

Dear Sir/Madam,

We are the department of Asian Domain Registration Service in China. I 
have something to confirm with you. We formally received an application 
on March 22, 2018 that a company which self-styled "Gulf East Ltd " were 
applying to register "nthpermutation" as their Brand Name and some 
domain names through our firm.


Now we are handling this registration, and after our initial checking, 
we found the name were similar to your company's, so we need to check 
with you whether your company has authorized that company to register 
these names. If you authorized this, we will finish the registration at 
once. If you did not authorize, please let us know within 5 workdays, so 
that we will handle this issue better. After the deadline we will 
unconditionally finish the registration for "Gulf East Ltd ". Looking 
forward to your prompt reply.


Best regards,

Sharon Han
Tel: 0086.5516349 1192
Fax: 0086.5516349 1192
Address:No.313, Changjiang Zhonglu, Hefei 23 China

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

[DNSOP] Definition of "trust anchor"

[Paul Hoffman]

The current text is:

"A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
validating security-aware resolver uses this public key or hash as
a starting point for building the authentication chain to a signed
DNS response." (Quoted from , Section 2)

The WG has has a preference for quoting from RFCs, but there was also 
some hesitation about this. How would people change this, possibly 
updating RFC 4033?


--Paul Hoffman

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

[DNSOP] help needed adding sections Re: DNS Camel Viewer

[bert hubert]

On Sat, Mar 24, 2018 at 02:04:02PM -0400, Matthew Pounsett wrote:
> I went to go dig into this and in the process of producing a list I found
> that the list was longer than I imagined, and that there are more
> categories of documents that don't contribute to the camel than I thought.

Hi Matthew,

I have indeed found the same thing. I've trawled the RFC index for anything
with "DNS" or "Domain Name System" in the title, and this found even more
documents that do not change the DNS itself, but do specify how to use it.

These documents may be worthy, but an implementer need not specifically
adhere to thse RFCs. 

There are 267 RFCs and active drafts that are "about" DNS right now.

I have begun to sort these into sections, tentatively:

Core: everyone needs to read this
DNSSEC: Could be skipped if you do not care about DNSSEC
rrtype: Define rrtypes that do not change semantics
dns-meta: Documents contemplating DNS
dns-use: Documents describing how to use DNS to do certain things

Probably more sections are possible. Some documents could be in multiple
sections. 

The file that contains my very limited work on assigning sections is:

https://github.com/ahupowerdns/protocol-camel/blob/master/dns-rfcs.js

I'd love for people to send pull requests improving the file.

Note that RFCs themselves are already grouped into 'Informational', 'Best
current practice' or even 'Experimental'. Almost everything that is an
operational guideline is already in 'Informational'. 

>  Rather than immediately send a pull request I've decided to share my
> attempt at categorizing of non-camel documents here to invite discussion on
> whether they should be included in the camel list, or not, and to allow for
> others to spot things I've either mis-categorized or missed.

> My main criteria for putting something on one of these lists is that
> implementers not be in the intended audience for the document.  That is, if
> the document doesn't directly contribute to a decision about whether or how
> to write code, it should appear here.

My goal is to list everything that has DNS as its main thrust, even if it
can be safely ignored because it merely specifies how DNS can be used for
something. The reason for listing this stuff is that this at least stores
the knowledge that this RFC is not required reading. This is then 'dns-use'.

These documents are hidden by the default filter settings.

> There's an additional category that I didn't dig into that actually
> contributes negatively to the camel: deprecations (e.g. RFC 6563).

Yes - even though you still have to read them. 

> Operational Guides

So this overlaps hugely with "INFORMATIONAL" and "BCP", but indeed likely
still worth its own section.

> Proposals
> rfc1535

Unsure what to make of this document.

> 
> Essays and Comments
> rfc1178
> rfc1591
> rfc2826
> rfc3071
> rfc3467
> rfc6305

This is likely my 'dns-meta' category.

> Correspondence between parties (?)
> rfc1401

Perhaps we should have an 'oddball' category :-)

> Summaries of Discussions and other "Current Status" documents
> rfc2825
> rfc3130
> rfc7085
> rfc7626

dns-meta perhaps too?

> Requirements Documents and Problem Statements
> rfc4892
> rfc4986
> rfc5507
> rfc6168
> rfc6761
> rfc8244

Agree.

> Procedural and Policy Documents (for IANA & other non-operations groups)
> rfc6335
> rfc6841
> rfc6895
> rfc6912

Perhaps this could go with rfc1401 as 'procedural'?

Bert

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

[DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-05.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   : DNS Scoped Data Through '_Underscore' Naming of 
Attribute Leaves
Author  : Dave Crocker
Filename: draft-ietf-dnsop-attrleaf-05.txt
Pages   : 8
Date: 2018-03-25

Abstract:
   Formally, any DNS resource record may occur for any domain name.
   However some services have defined an operational convention, which
   applies to DNS leaf nodes that are under a DNS branch having one or
   more reserved node names, each beginning with an underscore.  The
   underscore naming construct defines a semantic scope for DNS records
   that are associated with the parent domain, above the underscored
   branch.  This specification explores the nature of this DNS usage and
   defines the "DNS Global Underscore Scoped Entry Registry" with IANA.
   The purpose of the Underscore registry is to avoid collisions
   resulting from the use of the same underscore-based name, for
   different services.


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

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

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


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] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Paul Wouters]

On Sun, 25 Mar 2018, Evan Hunt wrote:


I think it would help if there were more clarity on what exactly is being
proposed, other than adding the words "obsolete" or "deprecated" to a list
of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to implementers.


I agree.

And I don't see much point in obsoleting simple defines and logging
unknown RRtypes.

Paul

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

Re: [DNSOP] New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Paul Hoffman]

On 25 Mar 2018, at 9:05, Evan Hunt wrote:

I think it would help if there were more clarity on what exactly is 
being
proposed, other than adding the words "obsolete" or "deprecated" to a 
list

of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to implementers.


Fully agree. I would hope that such guidance gets into the draft before 
it moves forwards.


These RR types have text representations and wire format 
representations,

which from a complexity standpoint seem quite harmless to implement.


Yes.


There
are the old annoying rules about name compression and sorting, which 
do add
some complexity, but are already implemented in all the existing 
codebases.


and probably needs to be kept for the future to interoperate with the 
current code bases.


I don't see how the IETF can mandate that they be removed, nor am I 
sure

it's particuilarly worth doing.


Right.


We can make them optional to implement in
the future, though.


except that, if some implementer reads this document as meaning that 
they don't have to handle the listed RRtypes in any special way, they 
could get nailed when interoperating with implementations that handle 
the compression correctly.



Perhaps that's all Ondrej has in mind?


Only he can say. :-)

--Paul Hoffman

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

Re: [DNSOP] Fwd: New Version Notification for draft-sury-deprecate-obsolete-resource-records-00.txt

[Evan Hunt]

On Sat, Mar 24, 2018 at 06:48:35AM -0700, Joe Abley wrote:
> I'm actually surprised to see that support for rarely-used RRTypes is
> really upsetting the camel.

It's an interesting object lesson in the complexity of unloading camels,
though.  (Perhaps it's time to add something about "the eye of a needle" to
our camel metaphor.)

> A combinatorial explosion of annoying workarounds for the inability of
> middleboxes or upstream authority servers to implement EDNS(0)
> properly seems like a much more plausible camel irritant to me. I'm
> sure there are many more like that.

Wholeheartedly agree, and efforts to address this are under way.

> I can see why you could strip out lines of code by eliminating the
> need to parse the canonical formatting of WKS and friends, but I'm
> surprised that it's a notable source of complexity. It is, after all,
> complexity that I heard is causing the camel strain, not just lines of
> code.
> 
> If future-BIND stops parsing an archaic RRType that I happen to use,
> I'm going to have to change whatever code or processes that depend on
> it. Maybe someone (ISC, even) is going to publish a filter that will
> turn all the old RRs in canonical syntax into TYPE representation,
> and back again. New RRTypes might then need to get implemented in both
> BIND (because presumably they are camel-friendly) and also in the
> filter or filters, because perhaps we are targeting multiple
> nameserver implementations with our zone file.
> 
> This all sounds like we're just sharing the complexity around. It
> doesn't sound any simpler. Maybe it's a silly example? I don't know.
> Could be. But I think brushing the grains RRType parsing dust off the
> camel is not going to do much for its posture.

I think it would help if there were more clarity on what exactly is being
proposed, other than adding the words "obsolete" or "deprecated" to a list
of RRtypes on a website somewhere. The draft didn't seem to have
particularly clear guidance to implementers.

These RR types have text representations and wire format representations,
which from a complexity standpoint seem quite harmless to implement.  There
are the old annoying rules about name compression and sorting, which do add
some complexity, but are already implemented in all the existing codebases.
I don't see how the IETF can mandate that they be removed, nor am I sure
it's particuilarly worth doing.  We can make them optional to implement in
the future, though.  Perhaps that's all Ondrej has in mind?

(With respect to BIND, if these types are declared obsolete by the working
group, then my inclination would be to a log a message saying so if you
tried to load them in a zone, same as with SPF.  In a future relase I might
start treating them as opague types when rendering to wire format, but
would probably retain the ability to parse them and display them as text.)

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

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