Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

[Darcy Kevin (FCA)]

The document candidly categorizes itself, in Section 1, as “a pedantic network 
protocol description”. As such, I think it might be appropriate for it to 
describe DNS names as appearing in the only form that is unambiguous and 
implementation-agnostic, i.e. dot-terminated FQDN.


Having said that, even RFC 1034 admits that the non-dot-terminated form “is 
often one where the trailing dot has been omitted to save typing”, so if the 
document wants to give a nod to how DNS names are typically represented in 
practice, that would also be fine, albeit slightly less pedantic.




  - Kevin



From: DNSOP  On Behalf Of Bob Harold
Sent: Monday, April 09, 2018 4:32 PM
To: Mukund Sivaraman 
Cc: IETF DNSOP WG 
Subject: Re: [DNSOP] New Version Notification for 
draft-muks-dnsop-dns-squash-01.txt


On Mon, Apr 2, 2018 at 6:26 AM, Mukund Sivaraman 
> wrote:
On Mon, Apr 02, 2018 at 03:20:02AM -0700, 
internet-dra...@ietf.org wrote:
>
> A new version of I-D, draft-muks-dnsop-dns-squash-01.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
>
> Name: draft-muks-dnsop-dns-squash
> Revision: 01
> Title:DNS squash
> Document date:2018-04-01
> Group:Individual Submission
> Pages:6
> URL:
> https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-squash-01.txt
> Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-squash/
> Htmlized:   https://tools.ietf.org/html/draft-muks-dnsop-dns-squash-01
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-muks-dnsop-dns-squash
> Diff:   
> https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-squash-01
>
> Abstract:
>This document attempts to specify current DNS protocol in squashed
>form in a single document.

You can compare what's in section 3 (Data structure) to what's in RFC
1034 section 3.1. (Name space specifications and terminology).

I'll post revisions weekly. Reviews and participation (preferrably first
in the form of discussion to prepare a list of things to do) are
welcome.

https://github.com/muks/dnssquash/

Mukund

3. Data Structure
...

   A DNS name is printed as a concatenation left to right of the

   individual labels on the path from the node to the root, each label

   trailing with an ASCII period '.' character.  Thus a complete printed

   DNS name ends with a period character.
Not exactly.  There is no period after the zero-length root zone.
The last period is actually between the tld and the root zone.
So 'there is a period between each zone' not 'after each zone'
even though it looks like a trailing dot.

--
Bob Harold

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

[DNSOP] Comments on draft-ietf-dnsop-kskroll-sentinel-11

[Edward Lewis]

1.

##which they are generated.  The Key Tag is a 16-bit value computed
##from the RDATA portion of a DNSKEY RR using a formula similar to a
##ones-complement checksum.  RRSIG RRs contain a Key Tag field whose

Suggest a reference to the section where the formula is defined, lest the
words here be taken as the definition.

"The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY RR 
using a formula found in "Key Tag Calculation" (Appendix B of "Resource Records 
for the DNS Security Extensions" [RFC 4034]), a formula similar to a 
ones-complement checksum."

the latter is not true for the original DNSSEC Security Algorithm, a 
factoid only significant in trivia games.   (See Appendix B.1 of the same 
document.)

2.

##validating resolvers.  The KSK sentinel method cannot provided him

s/provided/provide/

3.

##"invalid" resource.  His resolver resolves the root-key-sentinel-is-
##ta-02323.example.com name normally (it contacts the example.com
##authoritative servers, etc); as it supports the sentinel mechanism,
##just before Dave's recursive server send the reply to Dave's stub, it

s/send/sends/
Truth is, I can't quite parse the sentence

##performs the KSK Sentinel check (see below).  The QNAME starts with

4.

Unanswered[1] question from before:

Why is this specific to the root zone?

One reason to make this more general (than the root) is testing.  What if, in 
about two years, new implementations arrive and the operator of a root zone KSK 
wants to run tests?  It would be helpful to be able to have a test zone set up 
where secure entry points can be rotated in the name of testing code bases.  
(In the same sense as this test tool: 
https://automated-ksk-test.research.icann.org/)

Beyond that, there are no other rules or conventions in the protocol specific 
to one (absolute) name.  Not even "the reverse map" is special to the protocol. 
 (Perhaps this is too philosophical a topic.)

If this test mechanism only works for the root zone, then other operators 
exercising Automated Updates will not be able to make use of it.  There are two 
operators at the TLD level of the global public Internet DNS who exhibit 
Automated Updates (one has confirmed to me they do), for the sake of clarity, 
these operators do not include ICANN.  I have never searched in other trees nor 
deeper in the global public Internet for any operator following Automated 
Updates nor making use of seeded trust anchors outside the root zone.

[1] - About a month ago, I sent an open question to the list:

https://www.ietf.org/mail-archive/web/dnsop/current/msg22047.html

I missed any public replies to the question, I had one private exchange that 
said the WG preferred root-only without an explanation.  I'm not saying there's 
been no rationale given, but I haven't seen any reason.  There may be a good 
reason, again, I just haven't seen one.



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

Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-squash-01.txt

[Bob Harold]

On Mon, Apr 2, 2018 at 6:26 AM, Mukund Sivaraman  wrote:

> On Mon, Apr 02, 2018 at 03:20:02AM -0700, internet-dra...@ietf.org wrote:
> >
> > A new version of I-D, draft-muks-dnsop-dns-squash-01.txt
> > has been successfully submitted by Mukund Sivaraman and posted to the
> > IETF repository.
> >
> > Name: draft-muks-dnsop-dns-squash
> > Revision: 01
> > Title:DNS squash
> > Document date:2018-04-01
> > Group:Individual Submission
> > Pages:6
> > URL:https://www.ietf.org/internet-
> drafts/draft-muks-dnsop-dns-squash-01.txt
> > Status: https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-
> squash/
> > Htmlized:   https://tools.ietf.org/html/
> draft-muks-dnsop-dns-squash-01
> > Htmlized:   https://datatracker.ietf.org/
> doc/html/draft-muks-dnsop-dns-squash
> > Diff:   https://www.ietf.org/rfcdiff?url2=draft-muks-dnsop-dns-
> squash-01
> >
> > Abstract:
> >This document attempts to specify current DNS protocol in squashed
> >form in a single document.
>
> You can compare what's in section 3 (Data structure) to what's in RFC
> 1034 section 3.1. (Name space specifications and terminology).
>
> I'll post revisions weekly. Reviews and participation (preferrably first
> in the form of discussion to prepare a list of things to do) are
> welcome.
>
> https://github.com/muks/dnssquash/
>
> Mukund
>

3. Data Structure


   A DNS name is printed as a concatenation left to right of the
   individual labels on the path from the node to the root, each label
   trailing with an ASCII period '.' character.  Thus a complete printed
   DNS name ends with a period character.

Not exactly.  There is no period after the zero-length root zone.
The last period is actually between the tld and the root zone.
So 'there is a period between each zone' not 'after each zone'
even though it looks like a trailing dot.

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

Re: [DNSOP] raising the bar: requiring implementations

[神明達哉]

At Fri, 6 Apr 2018 04:35:44 +,
Evan Hunt  wrote:

> > At Thu, 5 Apr 2018 13:46:29 -0400,
> > tjw ietf  wrote:
> >
> > > What is work: An "informational" document being used as standard is people
> > > taking a submitted (expired) draft as "standard"?
> >
> > I'm not sure how to interpret it (not even sure if it's a question to
> > me)...
>
> I suspect Tim meant to type "What is worse: An 'informational' document
> being used as standard, or people taking a submitted (expired) draft as
> 'standard'?"

Ah, okay, it makes sense, thanks.  (Correcting this was far beyond my
ability of dealing with the language of English:-).  I still don't
know if it was meant to be a counter argument to my previous message
or an unrelated followup, but in any case that's a different topic
than my main concern.  This is much closer to the point:

> ECS, though, was published before it was fully cooked, and continuing to
> iterate and update the drafts would've been better.

and, at least in retrospect, my observation was that the intended
informational status was (ab)used to have this result, and IMO we
should be careful not to repeat it.

--
JINMEI, Tatuya

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

Re: [DNSOP] Responsible AD for KSK-Sentinel - Terry Manderson

[Warren Kumari]

On Mon, Apr 9, 2018 at 11:18 AM Suzanne Woolf 
wrote:

> Warren,
>
> Thanks for clarifying this for the WG.


No worries - and just to remind the WG: I will never be the Responsible AD
for a document for which I am an author, and will always recuse myself
during eval, etc.

I’m actually not sure if this is a documented requirement anywhere[0], but
it *is* the standard procedure for documents written by an AD (e.g:
https://datatracker.ietf.org/doc/draft-ietf-6man-maxra/ballot/ )



>
> For those who don’t like to worry about process, just note that Warren has
> done the right thing to head off any potential process issue with having
> the same person acting as both an editor of the document and the Area
> Director responsible for managing DNSOP documents in the IESG (running IETF
> Last Call, shepherding the document through discussion in the IESG).


> Thanks Terry for helping us out!


Indeed.

W
[0]: There are strong implications that this that this should happen - for
example, "IESG Ballot Procedures" has:
""Recuse" means "I cannot post a ballot position due to a personal interest
in the document." This ballot position is used with the AD is a document
author, WG chair, or otherwise interested party."



>
>
> Suzanne
>
> > On Apr 9, 2018, at 11:04 AM, Warren Kumari  wrote:
> >
> > Hello all,
> >
> > Obviously I cannot (nor would I want to) be the responsible AD for
> > this document, and so I asked for volunteers - Terry Manderson (CCed)
> > has kindly volunteered to carry the torch on this document.
> >
> > Thanks Terry!
> > W
> >
> > --
> > 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
>
> --
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] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[Bob Harold]

On Sat, Apr 7, 2018 at 5:41 AM, Benno Overeinder  wrote:

> Hi Suzanne, Warren, DNSOP WG,
>
> > On 7 Apr 2018, at 04:09, Warren Kumari  wrote:
> >
> > On Fri, Apr 6, 2018 at 5:49 PM, Suzanne Woolf 
> wrote:
> >>
> >>
> >> WG vendors/implementers: Can folks who have implemented
> kskroll-sentinel, or considered implementing it, please speak up on your
> concerns/plans?
> >
> > Yup, that would be helpful  - bits I know of are that Knot has an
> > implementation based on an earlier version (with a different label),
> > and Petr says that it will be some time before they are able to update
> > it; I've never touched Lua, if I get a chance I might try patch their
> > implementation with the new strings ("Hold my beer" / "How hard can it
> > be?")).
> > I think I heard that ISC was considering adding support, but was
> > planning on waiting till RFC / some sort of LC.
> >
>
> NLnet Labs is planning to add kskroll-sentinel support soon.  We will
> report progress and feedback to the authors of the kskroll-sentinel draft..
>
> Code will be made available in our repository and asap be part of the
> Unbound release (for packaging & distribution).
>
> Cheers,
>
> — Benno
>
>
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
>
>
+1 to holding for a while to see if implementations find any issues.

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

Re: [DNSOP] Responsible AD for KSK-Sentinel - Terry Manderson

[Suzanne Woolf]

Warren,

Thanks for clarifying this for the WG. 

For those who don’t like to worry about process, just note that Warren has done 
the right thing to head off any potential process issue with having the same 
person acting as both an editor of the document and the Area Director 
responsible for managing DNSOP documents in the IESG (running IETF Last Call, 
shepherding the document through discussion in the IESG). 

Thanks Terry for helping us out!


Suzanne

> On Apr 9, 2018, at 11:04 AM, Warren Kumari  wrote:
> 
> Hello all,
> 
> Obviously I cannot (nor would I want to) be the responsible AD for
> this document, and so I asked for volunteers - Terry Manderson (CCed)
> has kindly volunteered to carry the torch on this document.
> 
> Thanks Terry!
> W
> 
> -- 
> 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

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

[DNSOP] Responsible AD for KSK-Sentinel - Terry Manderson

[Warren Kumari]

Hello all,

Obviously I cannot (nor would I want to) be the responsible AD for
this document, and so I asked for volunteers - Terry Manderson (CCed)
has kindly volunteered to carry the torch on this document.

Thanks Terry!
W

-- 
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] Verifying errata 5316 against RFC1034.

[Warren Kumari]

On Mon, Apr 2, 2018 at 8:12 PM, Matthew Pounsett  wrote:
>
>
> On 2 April 2018 at 09:56, Warren Kumari  wrote:
>>
>>
>> This is not clearly a modification to the intended consensus (yet),
>> and currently feels unclear to me, so I'm going to give this another
>> few days (~1 week) and then, probably, mark it Hold for Document
>> Update. I'd still appreciate peoples' views and comments on if this is
>> correct.

One week is up, and I posted it as Hold for Document Update.

Thanks everyone for your review and advice.

W

>>
> Hold for Document Update seems like the right choice to me.  I don't think
> it's proper Errata for the reasons already mentioned, and as we're already
> discussing maybe obsoleting 1035 with a rewrite, Hold seems more prudent
> than Reject.
>




-- 
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] Mail addresses in .arpa

[Tony Finch]

> On 8 Apr 2018, at 19:14, John R. Levine  wrote:
> 
> I know it's ugly, but is there any rule that forbids putting an MX in a 
> reverse zone?

No, though talk to Joe Abley if you want some practical interop experience :-) 
https://mailarchive.ietf.org/arch/msg/dnsop/Ttvz3m_x7PyS6czeT-K9VQYQeqY/?qid=bff38cd5089003ca0d849bb8f2150644

Similarly, there’s nothing stopping you from putting PTR records in the 
“forward” DNS - my dodgy VM provisioning scripts stuff EUI48 <-> hostname maps 
in the DNS (the vm’s MAC address is its most persistent externally visible 
identifier).

08-00-27-b6-01-b4.dev.dns.cam.ac.uk. 3 IN PTR   vm0.dev.dns.cam.ac.uk.
vm0.dev.dns.cam.ac.uk.  3   IN  EUI48   08-00-27-b6-01-b4

Tony.
-- 
f.anthony.n.finch    http://dotat.at

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

Re: [DNSOP] Mail addresses in .arpa

[Petr Špaček]

On 8.4.2018 20:14, John R. Levine wrote:
> One day when I should have been doing something else, I make some .arpa
> e-mail addresses.
> 
> Try sending mail to jo...@m.183.57.64.in-addr.arpa and in all likelihood
> I will get it.
> 
> I know it's ugly, but is there any rule that forbids putting an MX in a
> reverse zone?

AFAIK there is no such rule because reverse zone is not "special" in the
protocol.

-- 
Petr Špaček  @  CZ.NIC

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