Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Mark Andrews]

Expiry Time:  Internet Date/Time Format from [RFC3339] Section 5.6
  profile of ISO 8601

Please don’t add yet another time format that it way too generic.
See RRSIG for how to present the time.  Name servers already have
code to parse this.

e.g.
MMDDHHMMSS in seconds since Jan 1, 1970 UTC ignoring leap seconds.

Also the field doesn’t need to be 64 bits.  32 would be fine.  We
really don’t need to support garbage collection +68 years in the
future.  You can just reference the RRSIG which uses 32 bit time
stamps.  Name servers do serial number arithmetic.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

Re: [DNSOP] New Version Notification for draft-pusateri-dnsop-update-timeout-00.txt

[Mark Andrews]

The record is not self describing for converting from wire to
presentation.  It requires knowledge of the size of the hash
which is algorithm dependent and not specified in the record.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

[DNSOP] Eric Rescorla's No Objection on draft-ietf-dnsop-terminology-bis-13: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-dnsop-terminology-bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-terminology-bis/



--
COMMENT:
--

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3131



IMPORTANT
S 6.
> [RFC5358]
>   
>  Split DNS:  The terms "split DNS" and "split-horizon DNS" have long
> been used in the DNS community without formal definition.  In
> general, they refer to situations in which DNS servers that are
> authoritative for a particular set of domains provide partly or

What about ones that aren't authoritative. Apparently this exists in
VPN settings.

COMMENTS
S 2.
>  learn the DNS by reading this document.
>   
>   2.  Names
>   
>  Naming system:  A naming system associates names with data.  Naming
> systems have many significant facets that help differentiate them.

>From each other? Or from other systems that aren't naming systems?


S 2.
> The need for the term "fully qualified domain name" comes from the
> existence of partially qualified domain names, which are names
> where one or more of the earliest labels in the ordered list are
> omitted (for example, a name of "www" derived from
> "www.example.net").  Such relative names are understood only by
> context.

I think we agree here but I had to read it several times, because
"earliest" in the list is not earliest in the presentation format.
Perhaps you should say "less specific" or "closest to the root" are
omitted  instead.


S 2.
>  Subdomain:  "A domain is a subdomain of another domain if it is
> contained within that domain.  This relationship can be tested by
> seeing if the subdomain's name ends with the containing domain's
> name."  (Quoted from [RFC1034], Section 3.1).  For example, in the
> host name "nnn.mmm.example.com", both "mmm.example.com" and
> "nnn.mmm.example.com" are subdomains of "example.com".

It might be worth noting that whole component matches are required
here.


S 2.
>   
>  Canonical name:  A CNAME resource record "identifies its owner name
> as an alias, and specifies the corresponding canonical name in the
> RDATA section of the RR."  (Quoted from [RFC1034], Section 3.6.2)
> This usage of the word "canonical" is related to the mathematical
> concept of "canonical form".

This paragraph didn't seem very clear. Perhaps an explanatory sentence
or two about what a CNAME is for woudl help.


S 4.
>the name originally queried, or a name received in a CNAME
>chain response.
>   
> *  QNAME (final): The name actually resolved, which is either the
>name actually queried or else the last name in a CNAME chain
>response.

So to be clear, the QNAME (final) is always one of the QNAME
(effective) sets?


S 6.
> name server side (which is what answers the query) and a resolver
> side (which performs the resolution function).  Systems operating
> in this mode are commonly called "recursive servers".  Sometimes
> they are called "recursive resolvers".  While strictly the
> difference between these is that one of them sends queries to
> another recursive server and the other does not, in practice it is

Which one does which?


S 6.
> general, a recursive resolver is expected to cache the answers it
> receives (which would make it a full-service resolver), but some
> recursive resolvers might not cache.
>   
> [RFC4697] tried to differentiate between a recursive resolver and
> an iterative resolver.

Did it fail?


S 6.
> client to another server and lets the client pursue the query
> there.  (See Section 2.3 of [RFC1034].)
>   
> In iterative resolution, the client repeatedly makes non-recursive
> queries and follows referrals and/or aliases.  The iterative
> resolution algorithm is described in Section 5.3.3 of [RFC1034].

This may just be my confusion, but it seems like this is still a bit
hard to follow.

Say that I send a query to a server X with the recursive bit set, and
that server in fact decides to give me a full answer (as opposed to
failing). At that point it could either:

(1) send the query to another server with the recursive bit set
(2) resolve the q

[DNSOP] Genart last call review of draft-ietf-dnsop-kskroll-sentinel-15

[Jari Arkko]

Reviewer: Jari Arkko
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-dnsop-kskroll-sentinel-??
Reviewer: Jari Arkko
Review Date: 2018-08-29
IETF LC End Date: 2018-09-06
IESG Telechat date: Not scheduled for a telechat

Summary:

This document was easy to read, and I had no issues to raise. I believe the
test that it describes is useful and important for the DNSSEC operational
processes in the Internet.

I did, however, have one question and one minor issue discussed below, and
several editorial observations.

Major issues:

Minor issues:

The document says:

   If the validating resolver has a forwarding configuration, and uses
   the CD bit on all forwarded queries, then this resolver is acting in
   a manner that is identical to a standalone resolver.

What does "using the CD bit" mean? Do you expect the bit to be set or not set?
Please clarify the language.

The document says:

   nonV:  A non-security-aware DNS resolver will respond with an A or
   record response for "root-key-sentinel-is-ta", an A record
  response for "root-key-sentinel-not-ta" and an A or  RRset
  response for the name that returns "bogus" validation status.

I do not understand why an old, non-DNSSEC aware resolver would respond in
different ways to the -is-ta and -not-ta queries. But here you say an A record
response is returned for -not-ta but A or  RRset response is returned for
-is-ta. What am I missing?

Nits/editorial comments:

Section 3 table lists "A" as responses, while the text talks about "A or RRset
response". Perhaps this could be aligned to avoid confusion.

Section 4 title is "Sentinel Tests from Hosts with More than One Configured
Resolve". Shouldn't that be "... Resolvers"?

The document did not clearly specify whether the names queried (including the
-is-ta and not-ta label) need to exist in the used domain, or if it is enough
for the domain itself to exist. Perhaps this could be clarified.


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