Re: [DNSOP] Multi Provider DNSSEC Models

[Yoshiro YONEYA]

Hi Shumon,

Thank you for starting good document.
I think this document is also useful for DNS provider transfer (or 
Registrar transfer) without causing DNSSEC insecure state.  Good 
thing is that this document doesn't depend on EPP (can be used with 
TLDs who doesn't employing EPP).

-- 
Yoshiro YONEYA 

On Tue, 20 Mar 2018 11:50:36 + Shumon Huque  wrote:

> 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] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

[Stuart Cheshire]

On 29 Feb 2016, at 14:27, John R Levine  wrote:

> The existing port and service registry already has all of the _service names, 
> and is updated as people invent new services. What's the benefit of 
> duplicating it rather than just pointing to it?

I agree. Where possible, it’s better to add to an existing registry, rather 
than creating an entirely new (but mostly overlapping) one.

When we wrote RFC 6335 we made a conscious choice that 15 ASCII characters is 
short enough to be efficient over the air and not burdensome to implement in 
constrained devices, yet long enough for the set of available identifiers to be 
effectively unlimited, and long enough to allow for reasonably mnemonic 
identifiers where that is desired (at least in English, which we deemed 
acceptable since these are protocol identifiers, not generally seen by end 
users).

A consequence of this abundant namespace is that it’s okay to have some 
identifiers in it that are not applicable in all contexts, and that’s 
preferable to having separate per-context namespaces, which risks having some 
identifier string appear in more than of those namespaces, with unrelated 
meanings. When RFC 6335 unified the two separate identifier namespaces there 
were four such unintended overlaps (esp, hydra, recipe, xmp), which fortunately 
were resolved amicably: .

On 1 Mar 2016, at 09:55, Phillip Hallam-Baker  wrote:

> The _service._protocol approach in SRV is rather obviously a mistake. Given 
> the function of SRV, the protocol tag should have been on the RIGHT hand side 
> of the RR type, not the left. The choice of UDP or TCP should be an OUTPUT 
> from the service discovery process, not an input.

We thought about this too, and concluded that few application protocols offer 
the luxury of running over both TCP and UDP (NFS and DNS being two examples 
that come to mind).

In reality, most application protocols are defined as a bundle, such as 
application-protocol-over-UDP-over-IP, or 
application-protocol-over-TCP-over-IP, or 
application-protocol-over-TLS-over-TCP-over-IP. The application protocol name 
implicitly encodes the transport it expects. In an iPhone looking for AirPrint 
(i.e., IPP) printers were to be told that it had found an AirPrint printer that 
supported IPP, but only over SCTP, or DCCP, or whatever, the iPhone would 
simply fail to print on it, because the iPhone doesn’t implement IPP-over-foo.

In retrospect, I wish we had defined all SRV service type identifiers to be 
simply “_app-proto._srv”, and let the specification of the “_app-proto” 
application protocol state what transport layer stack it requires. In practice 
what happens is that TCP-based protocols use “_tcp” and everything else uses 
“_udp” as the catch-all for all non-TCP protocols. RFC 6763 talks about this: 
.

A common convention that seems to be emerging is that application protocols 
that run over TLS are given SRV service type identifiers ending in “-tls”, such 
as, “_dns-update-tls._tcp” and “_dns-push-tls._tcp”. This is just a convention 
for mnemonic convenience though, and not every service uses it. For example, 
IPP over TLS uses service type “_ipps._tcp”. When looking for AirPrint (i.e., 
IPP) printers a modern iPhone will browse for both “_ipp._tcp” and 
“_ipps._tcp”, and show a unified list to the user. In some ways this is not 
ideal, but engineering is often a pragmatic choice between imperfect solutions 
and picking the less bad one. Moving forward we expect that most application 
protocols that need security will only run over TLS, making this “dual 
personality” behavior rare.

Stuart Cheshire

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

[DNSOP] DNSOP Minutes IETF101

[tjw ietf]

Hi

I uploaded the minutes the other day and failed to send the email

Big props to Paul Hoffman on taking notes.

Take a look and make sure you were quoted fairly

https://datatracker.ietf.org/meeting/101/materials/minutes-101-dnsop-00

I left a copy here for the git-inclined

https://github.com/DNSOP/wg-materials/blob/master/dnsop-ietf101/dnsop-ietf101-minutes.txt

The chairs want to thank everyone for making the two sessions pretty
awesome.  We love the energy and enthusiasm and ideas which came out of the
sessions.   I know I enjoyed meeting folks I had not met before, and
running into a few old faces.   What we do want is people focusing on the
content and the presentation.   Don't feel constrained by process, real or
imagined.  My normal way of handling 'process' discussions is to fling them
at our Area Directors, who are paid the big bucks to sort them out (my
co-chair does not fling).

and we'll have a camel naming contest

thanks again. y'all are the best.

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

Re: [DNSOP] On trust anchors, roots of trust, humans and indirection

[Michael StJohns]

Apologies for the top post.

Thanks for the commentary.  My guess is that we're starting from 
different assumptions.


There are three questions I have about your solution - 1) Do you expect 
it to be usable each time a device boots?  2) If (1), how long in years 
to you expect it to be usable?  3) if (1), do you expect that any query 
will change your default trust state (e.g. the selection of witnesses)?


Joe's problem AFAICT simply stated is that 5011 doesn't necessarily work 
for a device that's been on the shelves for 3-4 years.  My counter is 
that anyone who expects a device to come into service after four years 
on the shelf without requiring some intervention is somewhat optimistic.


If the answer to (1) is "No, this is only used for the first 
bootstrapping", then I would suggest one of two alternatives - one of 
which is similar to your proposal.  The first is that the device when 
first connected immediately downloads new firmware (which would include 
the most recent DNS trust anchor).  That becomes a don't care for DNSOP, 
but is really the correct way to deal with consumer devices which are 
the once mostly likely to be placed on the network without 
(knowledgeable) human intervention - at least for the maintenance 
lifetime.   The second is that, absent of knowledge of the DNS root of 
trust, a client queries ALL of the roots (A, B, C, etc) in the kickstart 
file and accepts a SEP DNSKEY  that appears in the root zone served by 
the majority of them.


If the answer to (1) is "Yes, this is used every time to figure out what 
the trust anchors are" I would suggest that you then have simply moved 
the TA management problem one level up and will need to maintain state 
for each of the witnesses for as long as the answer to (2).  (I.e., if 
you can't answer the question of "how does the system continue to 
operate if N of the witnesses have gone dark and/or been replaced by 
other witnesses?" then you don't have a viable system.


If the answer to (3) is yes, then this looks a lot like 5011.  If no, 
then you have to have a maintenance item for the set of witnesses if not 
a protocol.


The problem with the generic "splitting trust" model, is that you have 
an initial set of pseudo-trusted entities that you combine to gain final 
trust.   In the DNS root model, it is doubtful that you can get a 
sufficiently static set of entities for even a 5-8 year period of time 
except for the roots.  And even then, you can only assume that the 
address mappings of the roots are static, and not any key pairs that 
might identify the end points.


Trust models have bit rot.  It's just the nature of the beast.  In 
figuring out how to build a system that resists bit rot, you need to 
answer the three questions I asked, and then figure out the various 
probabilities of any given witness going dark (e.g. moving addresses, 
changing keys, shutting down, being comprimised) and figuring out the 
probability of a given client getting a "good" trust anchor at various 
points in its lifetime given changes in witnesses - e.g. a 100% 
probability at inception vs a 20% probability at year 12.  RFC5011 
considered the requirements as stated in RFC4986 and provided a system 
that was designed to be relatively bit-rot resistant (on a system basis) 
for a design life in excess of 40 years given reasonable attention to 
administration.  No system related to the DNS can be 100% bit-rot 
resistant for all clients given the one-way nature of the DNS data flows.



More in line.

On 3/28/2018 6:36 AM, Tony Finch wrote:

Michael StJohns  wrote:
Interesting thoughts, thanks. I have a slightly different starting point,
which doesn't disagree with your argument, but leads to somewhat different
consequences.


Proposition 1 (P1):  The initial selection of a root of trust (ROT) on behalf
of a validator ALWAYS involves a human in the loop.  It may not be obvious
which human(s), but it is always the case someone (not a computer) decided.
The selector may be the person configuring the validator or the set of people
who compile the code with the validator, or linux distribution manager, but
the initial selection always involves a judgement call of some sort by a
human.  In many cases, this is a judgement call is based on external
information (like widespread publication of the ROT information or multiple
third party endorsements (e.g. reputation evaluation)).

I think it should be possible to automate this judgment call, given a
suitable distributed publication/endorsement mechanism. This is the point
of my trust anchor witnesses draft. The HITL doesn't select the trust
anchor directly, but instead selects the witnesses.


I don't think this invalidates P1 - a human chooses.   The policy 
specified by the human is substituting for: "Take the one DS of the root 
in the file"; with "Go ask N entities, pick the answer that M give 
you".  In either case, the client executes the policy engine to get a 
result.

[DNSOP] I-D Action: draft-ietf-dnsop-algorithm-update-00.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   : Algorithm Implementation Requirements and Usage 
Guidance for DNSSEC
Authors : Paul Wouters
  Ondrej Sury
Filename: draft-ietf-dnsop-algorithm-update-00.txt
Pages   : 9
Date: 2018-03-22

Abstract:
   The DNSSEC protocol makes use of various cryptographic algorithms in
   order to provide authentication of DNS data and proof of non-
   existence.  To ensure interoperability between DNS resolvers and DNS
   authoritative servers, it is necessary to specify a set of algorithm
   implementation requirements and usage guidance to ensure that there
   is at least one algorithm that all implementations support.  This
   document defines the current algorithm implementation requirements
   and usage guidance for DNSSEC.  This document obsoletes [RFC6944].


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

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


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] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

[Dave Crocker]

On 3/29/2018 3:38 PM, Adam Roach wrote:
I still don't fully understand the nature of the objections I cite above 
or the assertions that having separate tables for different RRTYPEs is 
somehow broken. Based on my (admittedly lay) understanding of how DNS is 
used by other protocols, I agree with your proposal that having distinct 
tables for each RRTYPE makes far more sense than the current structure.



1. Another round of thanks. On re-starting the effort, I'd missed that 
exchange.  I think adding


 "Scope is meant as a static property, not one dependent on the 
nature of the query.  It is an artifact of the DNS name."


from it, to the Intro will help a bit.

2. I think the latest round of discussion and change arguably implements 
your view, albeit within a single actual registry.



d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[John C Klensin]

--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari
 wrote:

> On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker
>  wrote:
>> On 3/29/2018 1:45 PM, Warren Kumari wrote:
>>> 
>>> I don't want to get into if this is the*right*  behavior or
>>> not, but it seems like worth mentioning in the draft as it
>>> has much background already...
>>> I can find nothing which states that A /  cannot be
>>> associated with underscore names, but they sure don't seem
>>> to work in practice.

>> The current version is:
>> 
>>https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>> 
>> Please suggest specific text to use and where to put it.
> 
> I'm hoping someone will pipe up with "Gee, RFCfoo, Section
> bar, Bullet N clearly says this, I can't believe you never
> knew that"
> 
> If that doesn't occur I'll craft text.

Warren, just to clarify where I'm coming from (and noting Paul
Vixie's recent comment).  I think there is no question that
putting a label starting with an underscore (or containing one)
on an RRSET that includes an address record would be
ill-advised, nor that some implementations (possibly because
they consider it ill-advised or just plain dumb) won't allow it
or won't make it easy.   I think there is no question that
underscores (leading or otherwise) have no more place in either
historical (e.g., RFC 952) host names or the "preferred syntax"
of RFC 1034/1035 than, e.g., "+", "$", "%", or "/" do.  I am
reasonably confident that you are not going to find a normative
statement that says that the term "host name" (with or without
an intervening space) is any label, or the left-most label,
associated with one or more address records, nor as statement
that host names in the DNS MUST conform to the preferred syntax.
Indeed, the description in RFC 7719 appears to me to be
consistent with what the specifications actually say and it
contains the same "any octet value" language that appears in
earlier, normative, documents including RFC 8121.

My objection was narrow.  The text, even at -06, reads

'"host" (host name) are not allowed to use the
underscore character, this distinguishes the underscore
name from all legal host names [RFC1035]"'

That is objectionable for two reasons.  First and most
important, RFC 1035 just does not say that.  If the text had
referenced RFC 952 instead, it would have been correct, but
maybe not so useful.   Similarly, if it had said, more or less
following 7719, that generally-accepted domain names that
identify hosts ("host names") conform to the preferred syntax of
RFC 1034 (or 1035) and hence do not include underscores, there
would be no problem (if someone wants to take that as proposed
text, feel free).  

Second, as has been discussed many times before in the last
decade or two, "legal" is not a good term to use to describe
validity or conformance in RFCs.  Our standards are voluntary,
which makes it hard for them to assign legality or illegality
to, in this case, particular bits of syntax.  Moreover, the
concept of something being legal or illegal implies that, if the
latter is discovered, I should be able to call the Protocol
Police and have the offending label or its perpetrator arrested.
When last I tried, they were not answering their phone or even
their email.  The IESG has pushed back on that term in the past
and should, I believe, be pushing back on it today, regardless
or what might have been said in kinder and gentler times.

However, I believe that this discussion is, however
unintentionally, a distraction from a far more important issue.
The way the DNS, and particularly DNS queries, are defined makes
the idea of a namespace for all labels starting with "_" very
difficult and potentially a source of confusion.  While sorting
the registry by RRTYPE is an improvement over earlier versions,
the correct structure  is to have subregistries by RRTYPE, each
with whatever keywords (starting with underscore) are
appropriate for use with it listed.  I do not believe it is
appropriate to lose that distinction while we quibble about the
language used to describe the syntax of host names.

best,
   john


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Dave Crocker]

On 3/29/2018 10:30 AM, Paul Vixie wrote:
since the _ was chosen as nonconflicting, and since you desire to 
explain what it is we aren't conflicting with, and since the RFC 1035 
language is both non-normative and archaic by inspection, i really think 
that 952 is the correct, and only correct, reference to use.


Thanks for the detailed explication.  I think it's odd to have a DNS 
naming-related discussion that does not cite either of the seminal 
standards documents for domain naming, but I suppose there's isn't much 
downside at this place in the document, to cite only RFC 952.



as a side node, RFC 952 permits host names of only 24 characters or 
less, including those which have interior periods for RFC 921 purposes. 
therefore, a protocol lawyer could say that any name longer than 24 
characters, or beginning with a number, was by definition 
non-conflicting with RFC 952, and needs no underscore to achieve same. i 
do not harbor this view, and i believe that the LEXICAL GRAMMAR section 
is more definitional than the ASSUMPTIONS section of RFC 952.


To me, that's an example of the problem with citing only that document: 
It is not definitive on 'host name'.  That RFC 1035 isn't, really, 
either was my reason for wanting to cite both.  But anyhow, the next 
version will have only 952.




Trying to eliminate the issue entirely, is this sufficient:



Some resource record types are used in a fashion that can create
scaling problems, if an entire RRset associated with a domain name is
aggregated in the leaf node for that name. An increasingly-popular
approach, with excellent scaling properties, places the RR under a
node having an underscore-based name, at a defined place in the DNS
tree under the 'parent' name. This constrains the use of particular
RR types associated with that parent
name. A direct lookup to the subordinate leaf node produces only the
desired record types, at no greater cost than a typical DNS
lookup.

The definition of a underscore global registry, provided in this
specification, primarily attends to the top-most names used for
coping an RR type; that is the _underscore "global" names. 




it's almost 100% of the way there. but, you should say "places the 
RRset"


oops.  quite correct.



in: 2. DNS Underscore Scoped Entry Registries Function

...

/name space/name space, just as every RR type owns a distinct,
subordinate name space./


An RR type owns a name space? I don't understand what that means or how
it is correct.


While I think I see a computer science basis for saying that an RR type
has a namespace, I'm continuing to find the point more confusing than
helpful, and fear that other readers will, too.

At the least, can you point me to official documents that explain that
view? I've looked around a bit an haven't found such a specification or
discussion.


it only contains a namespace for the purposes of your underscore 
registry. no use of _TCP by any other RR type will conflict with the use 
of _TCP by SRV, for example. thus, each RR type effectively has its own 
registry, whose names need only be unique within that registry. you may 
prefer to call it a dictionary rather than a namespace in order to avoid 
confusion around what other DNS RFC's call a "namespace".


Oh.  Alas, I'm still not seeing how this is helpful pedagogy for the 
average reader.  Let's suspend this until the next version and see how 
the doc sits with folks.


d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Paul Vixie]

you do not need to document what won't work. underscored names don't 
match the syntax for host names. that's deliberate. that's why they were 
created. most dns servers will allow you to associate A or  rrsets 
with underscored names, though some might warn you about it when parsing 
the zone file. some getaddrinfo() or gethostbyname() libraries will look 
up A or  rrsets for these names, but many will not.


see RFC 952.

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

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

[Warren Kumari]

On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker  wrote:
> On 3/29/2018 1:45 PM, Warren Kumari wrote:
>>
>> I don't want to get into if this is the*right*  behavior or not, but
>> it seems like worth mentioning in the draft as it has much background
>> already...
>> I can find nothing which states that A /  cannot be associated
>> with underscore names, but they sure don't seem to work in practice.
>
>
>
> The current version is:
>
>https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>
> Please suggest specific text to use and where to put it.

I'm hoping someone will pipe up with "Gee, RFCfoo, Section bar, Bullet
N clearly says this, I can't believe you never knew that"

If that doesn't occur I'll craft text.
W

>
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] raising the bar: requiring implementations

[Phillip Hallam-Baker]

On Thu, Mar 29, 2018 at 3:18 PM, Suzanne Woolf 
wrote:

>
> Should we refuse to document such things because they’re not in well-known
> open source codebases, or have otherwise not passed tests of goodness?
>
> It’s not a rhetorical question. Given that people are extending the
> protocol outside of the IETF or any other formal process, in order to solve
> their own technical and business problems, it makes sense to ask ourselves
> periodically whether we should be encouraging them, trying to stop them, or
> something in between.
>

​There are in fact precedents for doing something of the sort. But not ones
that I think we should follow.

DNSSEC would have been implemented as part of the VeriSign ATLAS roll out.
The reason it was not was it simply could not be deployed using the tech
available with the spec as it was at the time without a major increase in
cost and complexity.

A blanket requirement for open source implementations may well have the
same effect.

Operating systems at Internet scale is vastly more complex than running
systems at network scale. It is not just the genius of the original
Internet designers that has allowed the Internet to scale from 100 nodes to
10 billion. There is a vast amount of unseen engineering work that is
equally heroic and some of that infrastructure comes with some very
specific constraints.

Some of the most useful work in IETF is making closed systems more open.
Often those projects require some extra slots to carry information that is
needed for some legacy system. I see no value to saying folk can't have a
smooth transition path from proprietary to open.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Dave Crocker]

On 3/29/2018 1:45 PM, Warren Kumari wrote:

I don't want to get into if this is the*right*  behavior or not, but
it seems like worth mentioning in the draft as it has much background
already...
I can find nothing which states that A /  cannot be associated
with underscore names, but they sure don't seem to work in practice.



The current version is:

   https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/

Please suggest specific text to use and where to put it.

d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Warren Kumari]

On Mon, Mar 26, 2018 at 9:21 PM, John C Klensin  wrote:
> (top post)
>
> Dave,
>
> I identified that issue as a nit deliberately.  This is a WG
> document and I believe the document would be improved if a less
> strong assertion were made, just because the issues of what,
> exactly, a "host" is for DNS purposes and what it can be called
> has been a source of controversy among those who seem to enjoy
> such discussions for about as long as I can remember. Trying to
> address that issue through this document is unnecessary and has
> a bit of a "side effect" feel to it -- it would be sufficient to
> say that there is a convention about using leading underscore
> followed by a keyword with some RRTYPEs and then move on.
>
> To answer your specific question, RFC 2181, Section 11, says
> "...any binary string whatever can be used as the label of any
> resource record."  I have not checked as to whether one of the
> many updates to that document modifies that statement, but the
> point is that
>_tcp IN A 10.0.0.1
> is a perfectly valid record, whether it identifies a "host" or
> not.  It just doesn't have any special interpretation there
> because there is no special namespace for "_" keywords
> associated with the "A" RRTYPE.

Actually, I'm not sure that that *is* a perfectly valid record, but
for a completely different reason to your statement / argument.

Many implementations simply will not resolve an underscore name to an
A or , and at least one implementation (BIND) won't load a
zonefile with them without bludgining:

foo   IN 600 A 192.0.2.1
_foo  IN 600 A 192.0.2.2
_bar  IN 600 CNAME foo.example.com.
_txt  IN 600 TXT "I'm a lumberjack..."

gets you:
$ named-checkzone  example.com example.com
example.com:11: _foo.example.com: bad owner name (check-names)
zone example.com/IN: not loaded due to errors.

I don't want to get into if this is the *right* behavior or not, but
it seems like worth mentioning in the draft as it has much background
already...
I can find nothing which states that A /  cannot be associated
with underscore names, but they sure don't seem to work in practice.

W


>
> Yes, that means that the use of leading underscores as a
> contention is a risk, just as the use of "xn--" to identify the
> need for IDNA processing is a risk.  In practice, the risks have
> proven to be low for both.  Maybe they are lower for "_" because
> the label strings are interpreted only in the context of
> specific label types, but that is just one more argument for
> binding the concept of a namespace for these names to the
> RRTYPE, not global, RRTYPE-independent, use of the DNS.
>
> However, I certainly don't have the time or energy to turn the
> validity of hostnames into a long, drawn-0ut, debate.It is
> not, IMO, a really serious error in the context of this
> document, at least unless a explanatory statement made here is
> cited later as an authoritative definition.   If no one else in
> the WG cares about it, so be it.
>
> john
>
>
>
>
> --On Monday, March 26, 2018 09:54 -0700 Dave Crocker
>  wrote:
>
>> On 3/26/2018 9:14 AM, John C Klensin wrote:
>>> (1) The text in Section 1.1 says
>>>
>>>  'the DNS rules for a "host" (host name) are not allowed
>>>  to use the underscore character... legal host names
>>>  [RFC1035]'
>>>
>>> 1035 does not say that.  Its section 2.3.1 is about what is
>>> preferred, not what is required (or "legal").  It says
>>> "should"
>>
>> Note that when that spec was written, we didn't have such
>> precise and rigid vocabulary rules.
>>
>> But RFC 1123 should be cited, especially since it has more
>> forceful language: "The syntax of a legal Internet host name".
>> (RFC6055 seems to have missed the import of 'legal'.)
>>
>>
>>> and "preferred", but there is no requirement.  As far as I
>>> know, there has never been a serious attempt to turn that
>>> preference into a requirement.  Indeed, RFC 8121 says exactly
>>> the opposite
>>
>> Please cite the specific text in that RFC you are referencing.
>>
>>
>>> and, if there were a prohibition, RFC 6055 would have been
>>> largely unnecessary.
>>
>> Overall, it appears that your claim is that the underscore
>> naming convention is predicated on an erroneous interpretation
>> of 'hostname' restrictions.  As such, the entire activity is
>> broken.
>>
>> d/
>
>
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

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

Re: [DNSOP] raising the bar: requiring implementations

[Mukund Sivaraman]

On Thu, Mar 29, 2018 at 03:18:45PM -0400, Suzanne Woolf wrote:
> 
> On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman  wrote:
> 
> > On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
> >> I would say that most things we have adopted in the past few years do have
> >> some implementations to reference.
> >> Not when drafts are adopted, but generally before we head to WGLC I've
> >> always wanted to see someone
> >> who implemented the option in some manner.
> >> 
> >> But yes, agree.
> > 
> > I'd raise the bar even higher, to see complete implementation in a major
> > open source DNS implementation when it applies. Sometimes implementation
> > problems are very revealing (client-subnet should have gone through
> > this).
> 
> This is actually quite a good example of another problem:
> Client-subnet was documented for Informational purposes; it was
> already in wide use in the public internet and had an EDNS opt code
> codepoint allocated from the IANA registry.
> 
> Nothing that happened in DNSOP or the IETF changed that, and I
> strongly suspect nothing that happened in DNSOP or the IETF could have
> changed it.

We found issues in the client-subnet description (in the draft stages)
that were corrected before it became RFC - this involved some behavioral
changes. However, the opportunity was not given to address fundamental
design issues, so what's in the RFC largely documents the
implementations preceding it and still has issues. I didn't think
client-subnet was in wide use when it came to dnsop. Even today it
doesn't look like it's in wide use.

You have asked an interesting question, because what happens if
something is already being used and there's no chance to update/correct
problems because that would make it a different protocol?

IMO, we should not put anything through dnsop that does not allow
reviewing and correcting problems. It is pointless for dnsop to shepherd
a draft to RFC when there's no possibility to influence it.

During later stages of the draft via dnsop, we implemented client-subnet
(resolver side) and found various problems. Some of these were addressed
in the draft, but it was revealing how poor the state of the
design/draft was. This is why I strongly suggest: A code contribution of
a _complete implementation_ of everything described in the draft to one
of the open source DNS implementations should come sometime during
adoption, so that

(a) issues in production implementation are revealed

(b) it can be tried in the real world to understand how it behaves.

As you're a co-chair:

When Bert did that Camel presentation, I felt hooray, here's one of us
who's talking about what the steady churn of ideas and RFCs is doing to
DNS implementations. We finish implementing one draft and at almost
breathless pace, a few more drafts queue up. It's not sustainable,
esp. as all the existing features also need to be maintained for years.

Introducing a new RR type that doesn't involve additional processing is
relatively trivial and nobody objects about it.

Introducing something like TCP pipelining, or rather, out-of-order query
processing, may seem trivial when describing the change, but
implementing it may need fundamental restructuring of the
implementation. Proper implementation of client-subnet needs change
everywhere within a nameserver from the client message parsing code to
the data structures used for cache, and how cache lifetime is managed.

Implementations are being stretched and bent 5 different ways to adapt
to the length and breadth of all these newfangled DNS items that
literally are showing up at an alarming pace.

Bert really hit the spot at the right time. Something needs to be done
to check what becomes an RFC. A good way is to require an open source
implementation. If draft authors cannot supply that or convince an open
source implementation to write support for it, it can go back to where
it came from.

Mukund

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

Re: [DNSOP] raising the bar: requiring implementations

[Suzanne Woolf]

On Mar 28, 2018, at 11:19 AM, Mukund Sivaraman  wrote:

> On Wed, Mar 28, 2018 at 10:55:13AM -0400, tjw ietf wrote:
>> I would say that most things we have adopted in the past few years do have
>> some implementations to reference.
>> Not when drafts are adopted, but generally before we head to WGLC I've
>> always wanted to see someone
>> who implemented the option in some manner.
>> 
>> But yes, agree.
> 
> I'd raise the bar even higher, to see complete implementation in a major
> open source DNS implementation when it applies. Sometimes implementation
> problems are very revealing (client-subnet should have gone through
> this).

This is actually quite a good example of another problem: Client-subnet was 
documented for Informational purposes; it was already in wide use in the public 
internet and had an EDNS opt code codepoint allocated from the IANA registry.

Nothing that happened in DNSOP or the IETF changed that, and I strongly suspect 
nothing that happened in DNSOP or the IETF could have changed it.

Other documents we’ve considered on features or modifications to the protocol 
include refuse-any and, I believe, serve-stale, and the stated purpose of the 
localhost draft is to clarify the existing documentation on the reserved name 
“localhost”.

Should we refuse to document such things because they’re not in well-known open 
source codebases, or have otherwise not passed tests of goodness?

It’s not a rhetorical question. Given that people are extending the protocol 
outside of the IETF or any other formal process, in order to solve their own 
technical and business problems, it makes sense to ask ourselves periodically 
whether we should be encouraging them, trying to stop them, or something in 
between.


Suzanne

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

Re: [DNSOP] raising the bar: requiring implementations

[Phillip Hallam-Baker]

On Wed, Mar 28, 2018 at 2:45 PM, Paul Vixie  wrote:

>
> i'm in general agreement with each of the assertions made at each layer of
> quoting above, but i have two quibbles.
>
> first, they aren't reference implementations. not even BIND, which for
> many years i called a reference implementation, is not one. a reference
> implementation is a special kind of beast, it's something that if you don't
> interoperate with it, you are in the wrong. we have a specification, and we
> judge the quality of that specification by the ease with which
> interoperable non-reference implementations can be made.
>
> second, i think it's 2018, and  can require that at least one of the
> demonstrated interoperable implementations be source-available. (not open
> source; we don't care about license, only transparency.)


​Quite, a reference implementation is not a production implementation. In
fact it may well not even be standards compliant because the most important
parts of an implementation to test are what happens when messages are not
as expected.

Production implementations should be forgiving in what they accept and
conservative in what they generate. Reference implementations should be the
opposite.

I generate my deployment and reference implementations from the same source
but they are not the same thing.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] mixfr - issue #10 - Client RRSIG logic simplification

[Frederico A C Neves]

I was looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware client
logic don't take in account that a posterior record at the addition
section, by an MIXFR DNSSEC aware server, will implicitly replace the
RRSIG RRset.

Logic could be simplified only to Deletions of RRs, when they conclude
a removal of a RRset, or RRsets by itself.

All the other cases, addition or replacement, will be covered
automatically by an addition or replace of a RRSIG RRset. There is no
need to extra client logic to remove RRSIG, at addition of a RR, and
at deletion of a RR if it not remove the RRset.

This is documented as issue #10 and includes proposed text.

https://github.com/matje/mixfr/issues/10

Fred

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

Re: [DNSOP] raising the bar: requiring implementations

[Jan Komissar (jkomissa)]

Cisco

On 3/29/18, 8:12 AM, "DNSOP on behalf of Tony Finch"  wrote:

Frederico A C Neves  wrote:
> On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote:
> >
> >  ... I have probably missed several ...
>
> MS

D'oh!

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet: Cyclonic 4 or 5. Moderate or rough, occasionally very rough 
in
southwest Fastnet. Thundery showers. Good, occasionally moderate.

___
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] A new version of mixfr

[Frederico A C Neves]

On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote:
> 
> > On 29 Mar 2018, at 9:05 am, Frederico A C Neves  wrote:
> > 
> > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> >>> No. You can have multiple nsec3 chains in a zone at the same time. Only 
> >>> one is active.  Some may be incomplete. 
> >>> 
> >>> Named builds and destroys chains incrementally to avoid large changes. 
> >>> 
> >>> Timely ness of changes is more  important than volume of changes.
> >> 
> >> As I stated down on this thread this behaviour is the one that is
> >> already supported by IXFR. For large zones, on large anycast networks,
> >> the volume of changes on the wire is important. The current aproach is
> >> impractical.
> > 
> > Perhaps this text is more specific and address the incremental re-salt
> > scenario and even improve it after the new chain in already in place
> > at the time of the removal of the old one.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is deleted or replaced, the MIXFR client MUST also
> > remove all existing NSEC3 records on the zone that form the chain
> > related to the deleted or replaced salt.
> > 
> > Fred
> 
> Firstly we should just say “DO NOT CHANGE NSEC3PARAM” as it is POINTLESS
> 
> Secondly you lose the ability to determine is the MIXFR is still in sync if 
> you do that.
> 
> Currently named requires that all delete operations in IXFR MUST find the 
> record in the
> zone and that all add operations MUST NOT find a existing record.  If either 
> condition
> fails then named falls back to a full AXFR of the zone as we know the zone 
> contents are
> no longer in sync.
> 
> That property needs to be preserved by this implementation.

AFAIK there is nothing on the current logic that a compliant server
implementation would not preserve this property for a compliant client
that expects it.

> You also need to be able to extract a MIXFR stream from a IXFR stream (as 
> that is what
> gets recorded to disk).  I don’t believe that will be possible from a 
> arbitrary IXFR
> stream.  

You are right if what you have is only the stream of IXFRs. But a
compliant server implementation at the time it updates the zone -
being looking for differences of a zonefile, processing Dynamic
Updates or reading an adequate jornal of updates - it will accordingly
produce the IXFR and the MIXFR to be recorded on disk.

Starting with the current zone representation and a stream of backward
IXFRs allow you do first get to the past zone representation, I mean
applying the IXFRs backward, and then start to produce the respective
MIXFRs. Awkward, very unlikely implementation for a compliant MIXFR
server, but possible.

Fred

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

Re: [DNSOP] A new version of mixfr

[Frederico A C Neves]

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:

> > One comment,
> > 
> > [3.1] As section 3 states that MIXFR is DNSSEC aware we need text
> > regarding NSEC3PARAM update as well.
> > 
> > For that I suggest to change 3.1 section name and include an extra
> > paragraph.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
> > existing NSEC3 records on the zone.
> 
> I agree that with the current syntax NSEC3 resalting is still a hassle. 
> But I am not sure if this implicit NSEC3 deletion is the right solution: 
> One can have multiple chains in the zone, the NSEC3PARAM just signals 
> that the chain is complete. Signers may have incomplete chains as an 
> intermediate step of NSEC3 resalting.
> 
> I shall add a GitHub issue for this. Thanks for bringing it up!

This is documented at issue #8 with an updated proposed text after
discussion down this thread.

https://github.com/matje/mixfr/issues/8

Fred

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Paul Vixie]

Dave Crocker wrote:

The text in RFC 1035 I have in mind is:

 > 2.3.1. Preferred name syntax



So, no, it doesn't explicitly cite the RFC number, but I read it as
citing the substance.


i think it's non-normative and should not be referenced in your 
document. this text:



However, when assigning a domain name for an object, the prudent user
will select a name which satisfies both the rules of the domain system
and any existing rules for the object, whether these rules are published
or implied by existing programs.


does not require or prohibit. and in your example:


When creating a new host name,
the old rules for HOSTS.TXT should be followed.


is not using a modern SHOULD, it's general advice only.

bizarrely, we are then greeted by this text:


The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.


it says "must", and if this is to be seen as a modern MUST, then it is 
true of all labels, and SRV updated 1035. also, the famous example of 
3com.com required a change to the SRI-NIC policies of its era, but was 
never backported to 1035. so, this text is clearly archaic.


whereas, in 952 we have the following. (more commentary below the break.)


GRAMMATICAL HOST TABLE SPECIFICATION

   A. Parsing grammar

   ::=  ":"  ":"  [":" []
 [":" []  [":" [] ]]] ":"
   ::=  *["," ]
   ::=  "."  "."  "." 
   ::= <0 to 255 decimal>
   ::=  |  |  *[","
 ]
 |  *["," ]
::= 
   ::= 
   ::= 
   ::= 
   ::= 
   ::=  *["," ]
   ::=  "/" 
 | 

   B. Lexical grammar

   ::=  [  ]
::=  *
   ::=  []
   ::= NET | GATEWAY | HOST | DOMAIN
   ::= *["."]
::= [*[]]
   ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
 ::= ITS | MULTICS | TOPS20 | UNIX...etc.
   ::= TCP | NCP | UDP | IP...etc.
   ::= TELNET | FTP | SMTP | MTP...etc.
   ::= 
   ::= ";" 
  ::= *[ | ]
::= 


since the _ was chosen as nonconflicting, and since you desire to 
explain what it is we aren't conflicting with, and since the RFC 1035 
language is both non-normative and archaic by inspection, i really think 
that 952 is the correct, and only correct, reference to use.


as a side node, RFC 952 permits host names of only 24 characters or 
less, including those which have interior periods for RFC 921 purposes. 
therefore, a protocol lawyer could say that any name longer than 24 
characters, or beginning with a number, was by definition 
non-conflicting with RFC 952, and needs no underscore to achieve same. i 
do not harbor this view, and i believe that the LEXICAL GRAMMAR section 
is more definitional than the ASSUMPTIONS section of RFC 952.








in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records

s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of
uses.//;
   s/Their use can scale poorly.*different uses\.//;
   s/increasingly-popular//; s/approach,/approach/



it's not increasingly popular, it doesn't scale poorly, and it's not
generic. so you can either remove those descriptions of SRV, or you
can remove SRV as the object of your description, or you can finesse it.


Trying to eliminate the issue entirely, is this sufficient:



Some resource record types are used in a fashion that can create
scaling problems, if an entire RRset associated with a domain name is
aggregated in the leaf node for that name. An increasingly-popular
approach, with excellent scaling properties, places the RR under a
node having an underscore-based name, at a defined place in the DNS
tree under the 'parent' name. This constrains the use of particular
RR types associated with that parent
name. A direct lookup to the subordinate leaf node produces only the
desired record types, at no greater cost than a typical DNS
lookup.

The definition of a underscore global registry, provided in this
specification, primarily attends to the top-most names used for
coping an RR type; that is the _underscore "global" names. 




it's almost 100% of the way there. but, you should say "places the 
RRset" since an RR never travels singly except in zone files, and all 
underscore-using applications i know of will accept more than one RR 
having the same name, class, and type -- thus, they process RRsets, 
which travel as RRsets on the wire, and the fact that an RRset contains 
RRs is unimportant in and of itself -- and describing it this way is 
confusing. an RRset with one RR may seem to be a degenerate case, but 
it's essential (respects law of least astonishment) to think of it that way.



in: 2. DNS Underscore Scoped Entry Registries Function

...

/name space/name space, just as every RR type owns a distinct,
subordinate name space./


An RR type owns a 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Dave Crocker]

Paul,

On 3/29/2018 9:31 AM, Paul Vixie wrote:

in: 1.1. _Underscore Scoping

...

s/[RFC1035]/[RFC952]/ (first occurrence)


hmmm. I suggest listing both, since RFC1035 both cites the precedence of
RFC952 as well as supplying an (apparently redundant) formal syntax
specification for host name.


the reference to 952 in 1035 is only in the bibliography, and does not 
specifically discuss its relationship to A RR owner names or to MX RR 
targets. if you can show me the part of 1035 you think is relevant to 
the definition of a host name, i'd like to see it.


The text in RFC 1035 I have in mind is:

> 2.3.1. Preferred name syntax
...

When creating a new host name,
the old rules for HOSTS.TXT should be followed.  This avoids problems
when old software is converted to use domain names.

The following syntax will result in fewer problems with many

applications that use domain names (e.g., mail, TELNET).

 ::=  | " "

 ::=  |  "." 

 ::=  [ [  ]  ]


So, no, it doesn't explicitly cite the RFC number, but I read it as 
citing the substance.




in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records

s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of uses.//;
   s/Their use can scale poorly.*different uses\.//;
   s/increasingly-popular//; s/approach,/approach/


Sorry, not understanding the issue(s). Please clarify.

Here's my guess at the concern:

SRV is viewed as not generic and/or doesn't have scaling problems?

...


it's not increasingly popular, it doesn't scale poorly, and it's not 
generic. so you can either remove those descriptions of SRV, or you can 
remove SRV as the object of your description, or you can finesse it.


Trying to eliminate the issue entirely, is this sufficient:

 

   Some resource record types are used in a fashion that can create
  scaling problems, if an entire RRset associated with a domain
  name is aggregated in the leaf node for that name. An
  increasingly-popular approach, with excellent scaling properties,
  places the RR under a node having an underscore-based name, at a
  defined place in the DNS tree under the 'parent' name. This
  constrains the use of particular RR
  types associated with that parent name. A direct lookup to the
  subordinate leaf node produces only the desired record types, at
  no greater cost than a typical DNS lookup.

   The definition of a underscore global registry, provided in this
  specification, primarily attends to the top-most names used for
  coping an RR type; that is the _underscore "global" names. 

   



in: 2. DNS Underscore Scoped Entry Registries Function

...

/name space/name space, just as every RR type owns a distinct,
subordinate name space./


An RR type owns a name space? I don't understand what that means or how
it is correct.


While I think I see a computer science basis for saying that an RR type 
has a namespace, I'm continuing to find the point more confusing than 
helpful, and fear that other readers will, too.


At the least, can you point me to official documents that explain that 
view?  I've looked around a bit an haven't found such a specification or 
discussion.


Note, for example, that RFC 1034 says:

> 2.4. Elements of the DNS
...

 The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
 specifications for a tree structured name space and data
 associated with the names.  Conceptually, each node and leaf
 of the domain name space tree names a set of information, and
 query operations are attempts to extract specific types of
 information from a particular set.


which is not language that lends itself towards saying that an RR type 
has its own namespace.  I don't see anything in RFC 1035 that works for 
that view, either.



d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

[DNSOP] Request for guidance on SIN

[Phillip Hallam-Baker]

Strong Internet Names is a concept that I have been developing for about 4
years now. It is an extension of concepts that Brian LaMachia and team
applied to the design of dotNET security with great success and I think it
has value applied at the network level.

The current draft can be found in HTML format here:
http://mathmesh.com/Documents/draft-hallambaker-sin.html

The related draft describing UDFs can be found here:
http://mathmesh.com/Documents/draft-hallambaker-udf.html


The question I would like to pose is which group to raise the work in as it
is a security specification with DNS implications.

This is one of the technologies I am using to build the mathematical mesh
but it is not limited to that application. The relationship is similar to
that of URIs to HTTP, they are both used in the Web but URIs are much wider
in scope.


The basic concept of a SIN is to bind together an Internet address and a
security policy that constrains the interpretation and use of that address.

For example, Example Inc holds the domain name example.com and has deployed
a private CA whose root of trust is a PKIX certificate with the UDF
fingerprint MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.


Alice is an employee of Example Inc., she uses three email addresses:

al...@example.com
A regular
email address (not a SIN).

al...@mm--mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com
A strong
email address that is backwards compatible.

al...@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz
A strong
email address that is backwards incompatible. These are addresses that can
be entered into the contacts directory of any existing email client. Note
the use of the mm-- prefix to identify this as a SIN. Existing policy means
these labels cannot be issued as ICANN TLDs etc. That coupled with the fact
that accidental collisions are statistically improbable and these names are
as robust as is possible.

Putting what is functionally a superset of an OpenPGP fingerprint into a
domain name means that we can cryptographically harden any system.


This is not necessarily a construct that would be put in front of a user,
most of the time we use SINs in the mesh it is to record the outcome of a
trust decision.

So in the example above, Alice might give me her business card, I send her
an email and when she replies, there is a header giving me her Strong email
address which is bound to a security policy such as 'always use end-to-end
encryption with either S/MIME or OpenPGP and here are my keys'.

Certificate Authorities are currently employed as trust providers. In the
SIN model, we can limit their role to that of Trusted Introducers who are
only required to make the initial connection.

There is of course an infinite amount of complexity in the specification
and application of security policies. And the design of UDFs takes account
of that with a construction that provides for isolation of semantic domains.

What I want to do at this point is to get the foundations laid to allow us
to build interesting stuff. The interesting stuff itself is a separate
matter.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Paul Vixie]

Dave Crocker wrote:

On 3/28/2018 11:41 AM, Paul Vixie wrote:

dave, HEREIS. --paul


Cool. Thanks!

...

Inline questions/comments/concerns...

...


in: 1.1. _Underscore Scoping

...

s/[RFC1035]/[RFC952]/ (first occurrence)


hmmm. I suggest listing both, since RFC1035 both cites the precedence of
RFC952 as well as supplying an (apparently redundant) formal syntax
specification for host name.


the reference to 952 in 1035 is only in the bibliography, and does not 
specifically discuss its relationship to A RR owner names or to MX RR 
targets. if you can show me the part of 1035 you think is relevant to 
the definition of a host name, i'd like to see it.


when i chose _ it was right after the great \n PTR vuln in sendmail, and 
so i was darn sure where the definition of host name was that did not 
include _ as a valid character, having just wrestled those 'gators.



in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records

s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of uses.//;
   s/Their use can scale poorly.*different uses\.//;
   s/increasingly-popular//; s/approach,/approach/


Sorry, not understanding the issue(s). Please clarify.

Here's my guess at the concern:

SRV is viewed as not generic and/or doesn't have scaling problems?

...


it's not increasingly popular, it doesn't scale poorly, and it's not 
generic. so you can either remove those descriptions of SRV, or you can 
remove SRV as the object of your description, or you can finesse it.



The variability of such types can make it problematic to aggregate all
occurrences of them into the same node, even though they are associated
with that node. The underscore naming approach separates these subsets.
Again, SRV is interesting because it was designed with that naming as
part of its original design. However the fact that it was designed with
the solution from the start doesn't relieve it of needing that solution.
The text, here, is attempting to characterize a motivating issue, namely
a scaling challenge that occurs due to the variability of use for some
RR types.


your words, "needing that solution", have no subject here. the problems 
you are describing for TXT will apply to NULL, and to JSON if we restart 
that effort, and possibly to URI (i didn't check that), but they do not 
occur with SRV, nor might they, ever.


other than the need to document _UDP and _TCP in the registry for the 
SRV type, there is nothing in your effort that touches or is motivated 
by SRV. having an _ doesn't make it "like TXT". there is an RRset for 
SRV where it is used, and that RRset is selected by its attrleaf. it 
passes like ships in the night with any other type of RRset at any child 
of the same domain name.



s/RR/RRset/ (note, leave "RR"s alone)


The substitution command seems to be at odds with the comment. Please
explain.


i don't want you to change the quoted RR ("RR") only the unquoted RR (RR).


in: 2. DNS Underscore Scoped Entry Registries Function

...

/name space/name space, just as every RR type owns a distinct,
subordinate name space./


An RR type owns a name space? I don't understand what that means or how
it is correct.


the children of some node (www.example.com) that are of some type (SRV) 
are in a different namespace, with respect to an application's ability 
to fetch them discretely (_SMTP._TCP.www.example.com SRV) and also with 
respect to conflicts with the same node being used by some other type 
(_TCP.www.example.com TXT).


perhaps after "subordinate name space" i ought to have added "for the 
purpose of allowing applications to fetch only the data they desire and 
without also hearing unrelated data used by other services and apps."


--
P Vixie

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

[DNSOP] Fwd: Delivery Status Notification (Failure)

[Phillip Hallam-Baker]

Oh and if you are going to be on a mailing list, then configure your mail
server so it does not spam people with reject notices.


-- Forwarded message --
From: Mail Delivery Subsystem 
Date: Thu, Mar 29, 2018 at 11:43 AM
Subject: Delivery Status Notification (Failure)
To: hal...@gmail.com


[image: Error Icon]
Message not delivered
There was a problem delivering your message to *j...@rfc1035.com*. See the
technical details below, or try resending in a few minutes.
The response from the remote server was:

550 5.7.1 : Client host rejected:
No thanks.

Final-Recipient: rfc822; j...@rfc1035.com
Action: failed
Status: 5.7.1
Remote-MTA: dns; mailhost.rfc1035.com. (93.186.33.42, the server for the
 domain rfc1035.com.)
Diagnostic-Code: smtp; 550 5.7.1 :
Client host rejected: No thanks.
Last-Attempt-Date: Thu, 29 Mar 2018 08:43:32 -0700 (PDT)


-- Forwarded message --
From: Phillip Hallam-Baker 
To: Jim Reid 
Cc: dnsop WG 
Bcc:
Date: Thu, 29 Mar 2018 11:41:30 -0400
Subject: Re: [DNSOP] New WG for document/protocol cleanup?


On Wed, Mar 28, 2018 at 1:12 PM,
​​
Jim Reid  wrote:

>
>
> > On 28 Mar 2018, at 18:02, Phillip Hallam-Baker 
> wrote:
> > ... long rant snipped ...
> > Well that is how I plan to go forward at any rate.
>
> Good for you. Please come back to the IETF once you've figured it all out
> and have running, interoperable code.
>
>
​http://mathmesh.com/​
​https://github.com/hallambaker/Mathematical-Mesh

I always base my protocol observations on actual code. Had you actually
read my post rather than felt threatened by it, you would have seen that I
said I had code at the very start.

The sub-library in question is

https://github.com/hallambaker/Mathematical-Mesh/
tree/master/Libraries/Goedel.Discovery

The discovery mechanism is described in:
http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html

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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Phillip Hallam-Baker]

A bit of context here, this is probably a document you have seen before and
it is one of those cleanup documents that tends to languish.

The reason I asked Dave to restart work on this draft is that I was
reviewing another draft (SMTPRPT) that clearly needs to register a new
prefix and indeed really needs a new prefix registry.

This this draft is about to become critical path for another draft which
means that it is much more likely that it will actually make it to RFC this
time which means that if you have an opinion on it, now is the time to
speak or forever hold your peace.



On Wed, Mar 28, 2018 at 11:30 AM,  wrote:

>
> 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-06.txt
> Pages   : 9
> Date: 2018-03-28
>
> 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-06
> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-attrleaf-06
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-06
>
>
> 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
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] New WG for document/protocol cleanup?

[Phillip Hallam-Baker]

On Wed, Mar 28, 2018 at 1:12 PM,
​​
Jim Reid  wrote:

>
>
> > On 28 Mar 2018, at 18:02, Phillip Hallam-Baker 
> wrote:
> > ... long rant snipped ...
> > Well that is how I plan to go forward at any rate.
>
> Good for you. Please come back to the IETF once you've figured it all out
> and have running, interoperable code.
>
>
​http://mathmesh.com/​
​https://github.com/hallambaker/Mathematical-Mesh

I always base my protocol observations on actual code. Had you actually
read my post rather than felt threatened by it, you would have seen that I
said I had code at the very start.

The sub-library in question is

https://github.com/hallambaker/Mathematical-Mesh/tree/master/Libraries/Goedel.Discovery

The discovery mechanism is described in:
http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html

As I said, that is the direction I am headed in.​


Oh and since I have been in the IETF for 25 years, I take exception to folk
using exclusionary language or representing themselves as authorities on
process etc. as a way to shut down discussion of technical contributions.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-attrleaf-06.txt

[Dave Crocker]

On 3/28/2018 11:41 AM, Paul Vixie wrote:

dave, HEREIS. --paul


Cool.  Thanks!

(Sorry for the sloppy vocabulary usage.  By way of an empathy signal cf, 
common use of 'header' in email when it should be 'header field'...)


I've gone through the entire document and reviewed all occurrences RR 
and resource record strings.  The results don't exactly the match the 
set of changes you specify, but did produce quite a few changes.


The RFC 2181 definition resource record set is a set of records of the 
/same/ type.  In some cases, that isn't what's meant, so I didn't change 
the text. In some cases, the text's intent is to to cover RRs of 
/different/ types populating the same leaf.  As I read the definition, 
that's not covered by RRset.




Inline questions/comments/concerns...




in: 1.1. _Underscore Scoping

...

s/specific resource records/specific resource record sets/


Current text:

 "That scope is a leaf node, within which the uses of specific 
resource records can be formally defined and constrained."


I often find that there is wording danger in using plurals, that can be 
avoided with the singular.  I think the issue here can be simplified by 
changing the text to:


 "That scope is a leaf node, within which the uses of a specific 
resource record type can be formally defined and constrained."




s/[RFC1035]/[RFC952]/ (first occurrence)


hmmm. I suggest listing both, since RFC1035 both cites the precedence of 
RFC952 as well as supplying an (apparently redundant) formal syntax 
specification for host name.




in: 1.2. Scaling Benefits for TXT, SRV, and URI Resource Records

s/SRV,//; S/"SRV",//
OR s/Some resource records are generic and support a variety of uses.//;
    s/Their use can scale poorly.*different uses\.//;
    s/increasingly-popular//; s/approach,/approach/


Sorry, not understanding the issue(s). Please clarify.

Here's my guess at the concern:

 SRV is viewed as not generic and/or doesn't have scaling problems?

There is a type of variability to the use of some RR types that 
effectively means they have variation in their role, not just their 
payload.  TXT is the extreme example of this.  SRV is more interesting, 
because it was designed for that variability.  Glad to use a term other 
than generic, but I don't have an obvious alternative that suits.


The variability of such types can make it problematic to aggregate all 
occurrences of them into the same node, even though they are associated 
with that node. The underscore naming approach separates these subsets. 
Again, SRV is interesting because it was designed with that naming as 
part of its original design.  However the fact that it was designed with 
the solution from the start doesn't relieve it of needing that solution. 
 The text, here, is attempting to characterize a motivating issue, 
namely a scaling challenge that occurs due to the variability of use for 
some RR types.




s/RR/RRset/ (note, leave "RR"s alone)


The substitution command seems to be at odds with the comment.  Please 
explain.





in: 2. DNS Underscore Scoped Entry Registries Function

...
/name space/name space, just as every RR type owns a distinct, 
subordinate name space./


An RR type owns a name space?  I don't understand what that means or how 
it is correct.


d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

Re: [DNSOP] raising the bar: requiring implementations

[Tony Finch]

Arsen STASIC  wrote:
>
> Quad9 is using powerdns dnsdist as loadbalancer and powerdns recursor and
> unbound [0], [1]
>
> [0] https://www.makeuseof.com/tag/quad9-dns-overview/
> [1] 
> https://www.theinquirer.net/inquirer/news/3021536/ibm-teams-with-global-cyber-alliance-to-launch-quad9-a-free-public-domain-name-service-system

Thanks for the correction!

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
South Utsire, Forties, Cromarty: Easterly 5 to 7, occasionally gale 8 at first
except in Cromarty. Moderate or rough. Occasional sleet. Good, occasionally
moderate.

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

Re: [DNSOP] raising the bar: requiring implementations

[Tony Finch]

Frederico A C Neves  wrote:
> On Wed, Mar 28, 2018 at 04:46:52PM +0100, Tony Finch wrote:
> >
> >  ... I have probably missed several ...
>
> MS

D'oh!

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Lundy, Fastnet: Cyclonic 4 or 5. Moderate or rough, occasionally very rough in
southwest Fastnet. Thundery showers. Good, occasionally moderate.

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

[DNSOP] Hello, and welcome to DNS

[bert hubert]

Hi everyone,

[tl;dr: check out https://powerdns.org/hello-dns/ and
https://powerdns.org/hello-dns/meta.md.html ]

As part of looking into the complexity of the current DNS specification, I
have been pointed at earlier efforts to improve the situation, both for DNS
and for other protocols. 
(https://tools.ietf.org/html/draft-ietf-dnsext-dns-protocol-profile-01
for example).

As has been noted here, "redoing the spec" is a stupendous amount of work,
easily a person-year.  And not a pleasant year at that since it leads to
endless relitigations of previous battles fought, even in a supportive
environment.  This was confirmed by Paul Hoffman and Andrew Sullivan for two
protocols.

I think I and the WGs in general can't credibly commit to this effort, but I
have had it confirmed from several sides that even to the highly skilled
outsider, the DNS specification is currently completely impenetrable. We may
not see this ourselves since we've lived in it for a decade or more.

The reasons for this impenetrability are partially to the age of the
documents, which spend a lot of time talking about conditions which no
longer exist, or at the very least no longer need explaining or defending.

In addition, over the decades, a lot of the original 1034/1035 era text has
been updated, replaced or obsoleted by dozens of later documents.  This
makes it hard to assemble what DNS actually is today. If you start at the
bottom, many things are no longer true. If you start at the end, you can't
make sense of the changes without understanding the earlier documents.

On the positive side, the documents themselves are in pretty good shape once
you get them (!).  Most questions are eventually answered and if you add up
all the text, it ends up as a pretty decent specification.

Given that we likely have no appetite or time to write 1034-bis/1035-bis, I
think the best thing we can do is create an entrypoint for newcomers.  For
this idea, I've been inspired by the wonderful work of Richard Stevens (who
we still miss, nearly two decades on).

In his seminal works on TCP/IP, networks and Unix, he managed to explain
these complicated environments in a far better way than an RFC ever could,
importantly, while not contradicting the standards documents, or misleading
the user with an overly simplified picture of the world.

Crucially, the document may also be opinionated and not talk about things
that are legal, but that we no longer think you should do, like for example
mixing authoritative and recursive service on one IP address.

I've made a start of describing DNS like this on https://powerdns.org/hello-dns/
Of specific interest is the 'meta' document which sets out the goals, 
https://powerdns.org/hello-dns/meta.md.html

I very much welcome help in working on these documents. I do realize WGs are
geared for standards action and this is what attracts a lot of attention.
But I also think that realistically speaking, if we conclude we do not have
the oomph to do a full redo of the standards, this is the best we can do.

Perhaps once we end up with a document we are happy with we could give it
some publicity or perhaps publish it as an informational RFC. Who knows. 

Please let me know your thoughts, or even better, head to 
https://github.com/ahupowerdns/hello-dns/
to fix my inevitable mistakes or contribute text!

Bert

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

Re: [DNSOP] raising the bar: requiring implementations

[Arsen STASIC]

* Tony Finch  [2018-03-28 16:46 (+0100)]:

bert hubert  wrote:


Well to allow the one remaining closed source DNS implementation some room,


authoritative services: Akamai Amazon Cloudflare Dyn Google Verisign
recursive services: Google OpenDNS Quad9
COTS: Nominum


Quad9 is using powerdns dnsdist as loadbalancer and powerdns recursor and 
unbound [0], [1]

[0] https://www.makeuseof.com/tag/quad9-dns-overview/
[1] 
https://www.theinquirer.net/inquirer/news/3021536/ibm-teams-with-global-cyber-alliance-to-launch-quad9-a-free-public-domain-name-service-system


-arsen

___
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

[william manning]

my mailbox is not filled with crap from spammers, if that is what you
mean.  it's not empty either. :)
if you want to kill off NSAP-PTR, I'd support that.

/Wm

On Mon, Mar 26, 2018 at 11:44 AM, Dick Franks  wrote:

>
> On 26 March 2018 at 16:42, Paul Vixie  wrote:
>
>>
>>
>> Ondřej Surý wrote:
>>
>>> No, I am claiming that no current Internet standard is using those
>>> records and they were already marked as EXPERIMENTAL or OBSOLETE 30
>>> years ago.
>>>
>>
>> the original specification of these RR types is still in effect,
>> regardless of whether any other specification currently specifies whether
>> to use them..
>>
>> i don't entirely disagree that the Internet System definition ought to be
>> a window, adding new things and deleting old things as it marches down the
>> years.
>>
>> but if you want to deprecate something that somebody somewhere may still
>> be using, then it's because the definition for it is still in effect --
>> thus neither experimental nor obsolete as you begin.
>>
>> the process for doing so is more than reaching consensus on this working
>> group. figure out a schedule that includes outreach.
>
>
>
> This hypothetical somebody somewhere has already had 30 years warning that
> these RR's will disappear or be replaced by something better.
>
> Deprecation signals end of life, end of support, end of story.
>
> To speak of outreach in this particular case is a nonsense; your
> hypothetical friend has been ignoring the real world for 30 years, and
> nothing drops into his mailbox these days.
>
>
>
>
>> --
>> P Vixie
>>
>> ___
>> 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 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

[william manning]

concur with Pauls assertions wrt "long tail".  Picking on specific RR types
to remove is a high maintenance method to put the camel on a diet.
Laudable but maybe not worth the efforts needed to clean up the installed
base.  Perhaps these two ideas might be a better way to simplify things.
1) remove additional section processing for any proposed RR types & then
rework existing rr's that require ASP.   2) dynamically loadable rr's types
(harder in resolvers but so worth the flexablity)

ymmv of course.

/Wm

On Mon, Mar 26, 2018 at 2:36 PM, Paul Vixie  wrote:

>
>
> Dick Franks wrote:
>
>>
>> On 26 March 2018 at 16:42, Paul Vixie > > wrote:
>> ...
>>
>> This hypothetical somebody somewhere has already had 30 years warning
>> that these RR's will disappear or be replaced by something better.
>>
>> Deprecation signals end of life, end of support, end of story.
>>
>> To speak of outreach in this particular case is a nonsense; your
>> hypothetical friend has been ignoring the real world for 30 years, and
>> nothing drops into his mailbox these days.
>>
>
> i've had my symbolics 3640 online quite a bit in the last 30 years, and it
> still makes WKS queries, and i have used WKS responses to control it. the
> software still works as well as it was designed to do, but the vendor is
> long out of business. however, read on.
>
> please see down-thread where deprecation turns out to be both undesirable
> for the reasons i've given, and additive to developmental complexity since
> there would be _more_ DNS RFC's to read, and suboptimal compared to
> declaring a core subset of DNS technology as "mandatory to implement" and
> simply leaving WKS (and its hypothetical friends) out of that core subset.
>
>
> --
> P Vixie
>
> ___
> 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