Re: [DNSOP] Fwd: [EXT] New Version Notification for draft-toorop-dnsop-dns-catalog-zones-01.txt

[Richard Gibson]

Doesn't that preclude scenarios in which a zone transitions from one 
catalog to another?


On 4/16/20 09:17, Willem Toorop wrote:

An authoritative nameserver might have two or more catalog zones, each
associated with their own set of configuration.  In that case, the
member zone that was configured first (and associated with the settings
of the particular catalog zone it was a member of) will keep that
association, regardless of it being a member zone of other catalog zones
as well.


-- Willem


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-01.txt

[Richard Gibson]

The following excerpts allow for and even encourage software written 
against this document in its present form to behave in ways that will 
hinder adoption of future changes, and should probably be altered in 
order to foster the desired compatibility.


Section 2 requires "Each ZONEMD RR MUST specify a unique Digest Type", 
which means that a name server written against this document would be 
justified in rejecting a zone containing both a SHA384 ZONEMD RR with 
Reserved=0 and a SHA384 ZONEMD RR with Reserved!=0.


Section 2.2 declares that "The [presentation format] Reserved field MUST 
be represented as an unsigned decimal integer set to zero", which means 
that software written against this document would be justified in 
rejecting a master file containing a ZONEMD RR with nonzero Reserved.


In Section 3.2 ZONEMD placeholder records, "The Digest field MUST be set 
to all zeroes and of length appropriate for the chosen digest 
algorithm", which may poorly accommodate variable-length digests and 
result in interoperability issues.


Section 1 anticipates "a name server can verify the zone data it was 
given and refuse to serve a zone which fails verification" but Section 4 
declares that digest verification MUST NOT be considered successful if 
"If the zone contains more than one apex ZONEMD RR" or "If the Reserved 
field value is not zero", which means that software written against this 
document would be justified in rejecting a zone containing a ZONEMD 
described by either of those conditions. This is the crux of the 
compatibility concerns, and I think it would be best corrected by 
restricting step 4 failures to zones containing "more than one apex 
ZONEMD RR /with Reserved field equal to zero and the same Digest Type/" 
and updating later steps such that they apply for each ZONEMD RR and 
failures mean "digest verification MUST NOT be considered successful 
/for that RR/".



On 9/10/19 19:18, Wessels, Duane wrote:

Thanks Shane & George, I agree this needs some clarification.

Something thats probably missing from the document is that in any future 
revision of ZONEMD we expect backwards compatibility.  For this version, it is 
expected that Reserved is set to zero.  In a future version, if the formerly 
reserved field can have non-zero values, then a value of zero there should 
produce the exact same hashes as it does in this version.

I gave a presentation at DNS-OARC last year with some experiments in making 
large dynamic zones more efficient.  There I used the reserved field to encode 
the depth of a Merkle tree.  A depth of zero corresponds to effectively no tree 
which is the same as described in the current version.

Recently Mukund posted here a proposal of his for how to store zone data in 
memory in a ZONEMD-compatible way.  While slightly different than my idea, I 
believe his also could be implemented in a way such that the reserved field 
encodes what the consumer needs to know about how the data should be stored and 
the hash computed for interoperation.

If we agree that a value of zero in this field produces the same hash value in 
this version and future versions of ZONEMD, then shouldn't we say that it is an 
error to have non-zero values at this time?  If we say it is acceptable to 
ignore non-zero values at this time, then it would lead to incompatible hash 
values in the future version.

DW


On Sep 9, 2019, at 2:13 AM, George Michaelson  wrote:

This is a not uncommon problem in 'make this protocol work in future' spec. It could say "for 
version ZERO of this protocol" and then say "future versions of this protocol should 
stipulate what other values mean, and how this affects handling of all-zeros state, and other 
states"

Saying "must not validate" baldly basically says "will always be zero" to me 
-Which I think is what you're saying!

_G

On Mon, Sep 9, 2019 at 3:04 PM Shane Kerr  wrote:
Duane,

On 2019-09-06 02:01, Wessels, Duane wrote:

With this version the authors feel that it is ready for working group last call.

Sorry for a late comment, but I decided to give this one thorough last
read-through.

I'm a little concerned that the way the Reserved field is described may
make adoption of later versions of ZONEMD difficult. The relevant text:

2.1.3.  The Reserved Field

 The Reserved field is an 8-bit unsigned integer, which is always set
 to zero.  This field is reserved for future work to support efficient
 incremental updates.
  .
  .
  .
4.  Verifying Zone Message Digest
  .
  .
  .
 7.   The Reserved field MUST be checked.  If the Reserved field value
  is not zero, verification MUST NOT be considered successful.


The question is, what can a zone producer do to support both this
version of ZONEMD as well as a new version? Adding a non-zero Reserved
ZONEMD value will break any implementation using this specification.

I think what would be ideal is for non-zero Reserved values to be ignored.

If we treat 

Re: [DNSOP] proposal: Covert in-band zone data

[Richard Gibson]

Class is a bad idea for a few reasons, but principal among them in my 
mind is the fact that per section 4.2 of RFC 1034, the concept of zone 
is subordinate to the concept of class—even if zone cuts were in the 
same places, example. in a new class would still be a distinct zone from 
example. in the Internet class.


On 7/8/19 13:20, Wessels, Duane wrote:
I'll probably regret this, but what about a COVERT class, instead type 
RR type? 


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

Re: [DNSOP] question regarding draft-ietf-dnsop-aname-03.txt/proof of non-existence of the ANAME record

[Richard Gibson]

When an authoritative server receives a request with QTYPE= (without 
loss of generality with respect to A or any future ANAME-affected 
address record) for a domain name in a signed zone, there is either a 
relevant ANAME or there is not.


In the case where there a relevant ANAME, the server should include it 
with covering RRSIG(s) in the Additional section and  records 
(whether static or derived from the ANAME) with covering RRSIG(s) in the 
Answer section. Intermediate servers may not replace the Answer section 
records with their own ANAME-derived data unless they can either cover 
them with valid RRSIG(s) or are responding to their own client without 
DNSSEC.


In the case where there is no relevant ANAME, which is currently always 
the case, I don't think the server is under any obligation to make 
claims about records that could have affected the response if they 
existed. Its response should include RRSIG(s) proving either the 
authenticity of the  RRSet or its nonexistence (as appropriate).


On 5/29/19 03:52, Klaus Malorny wrote:



Hi all,

while still struggling with the basic ANAME processing (as described 
in my other mail), I wondered whether with DNSSEC, an authoritative 
name server MAY, SHOULD or MUST prove the non-existence of an ANAME 
record when it receives an A or  query and no sibling ANAME record 
exists for the delivered address records.


My personal opinion is that there is no big harm if a 
man-in-the-middle silently removes the ANAME record from the response, 
as the returned address records should still point to some valid 
hosts, so I would not include it. In the case that there are neither 
address records nor an ANAME, the NSEC/NSEC3 record which covers the 
non-existing address record would also cover the ANAME, so this case 
is not a problem at all.


Nevertheless, I wanted to bring this to your attention just in case 
that you haven't considered that already (it is not clear from the 
spec that you did).


Regards,

Klaus

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=PUSMRyGtOXnqCa18KWsTXNcKZ2vsDfzkAaUWJLf9W18=jB7ql9ejEIrE_BQZMnZT83PY05rG6hg0nrmQxbrhiwU= 



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

Re: [DNSOP] ANAME high-level benefit question

[Richard Gibson]

On 5/10/19 03:12, Brian Dickson wrote:
Have any "closed system" implementations of non-standard apex-CNAME 
hacks, committed publicly to neutral ANAME operations, presuming ANAME 
as currently envisioned?


Oracle are happy to see progress on ANAME and intend to support it. I 
personally have been active on the GitHub repository for the draft, with 
an eye to meaningful compatibility and ensuring that Oracle's support 
goes beyond trivial addition of ANAME records in response to A/ 
queries in order to satisfy and deprecate existing proprietary "ALIAS" use.


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

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

On 4/12/19 07:34, Matthijs Mekking wrote:

I think the logic suggested for ANAME is given this example:

1. Have ANAME and A and  sibling address records.
2. Look up ANAME target A and  target records.
3. If there is no positive answer (SERVFAIL, NXDOMAIN, NODATA) keep
sibling address records.
4. Otherwise replace sibling address records with ANAME target records.

This is different than NS1, that will never replace sibling address
records.  Instead, if there is no sibling address record, it will
perform ANAME resolution.  If that response is a SERVFAIL, NXDOMAIN or
NODATA, that is what will be given to the client (although returning
SERVFAIL won't be a thing in the ANAME specification).

In order to fit both use cases I think we need to relax the steps in the
ANAME resolution logic, but am hesitant to do that: If you make steps
optional it will be unclear what the optional resolver's behavior is
going to do.  I would very much like to see an agreement on the ANAME
resolution logic, especially so that customers can have multiple
providers or switch providers and can expect the same thing in both places.
The strategy of never replacing siblings seems ill-advised to me, but 
not really harmful because it's functionally equivalent to being 
ANAME-ignorant and therefore matches the behavior of all resolvers and 
nearly all authoritative servers currently on the Internet, and also the 
behavior of future resolverless ANAME-aware authoritative servers.


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

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

In further support of preserving sibling records when target chasing 
comes back negative, I'd like to further explore my offhand mention of 
"A and/or  records".


For a domain owner wanting to use a currently IPv4-only service provider 
(names withheld) while still supporting IPv6, the logical approach would 
be configuring an ANAME record with one or more  siblings. But that 
won't work if the  NODATA response from chasing the ANAME target is 
allowed to override those siblings with nothing. This seems to force a 
needless choice between abandoning the provider or abandoning IPv6.


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

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

On 4/11/19 23:45, Matthew Pounsett wrote:

On Thu, 11 Apr 2019 at 20:02, Richard Gibson
 wrote:

The first problem is for the owner of the ANAME-containing zone, for whom the 
upstream misconfiguration will result in downtime and be extended by caching to 
the MINIMUM value from their SOA, which in many cases will be one to three 
orders of magnitude greater than the TTL of the ANAME itself.

[snip]


But this suffers from both of the problems I have been complaining about—the 
resolver does not necessarily have the zone SOA, possibility necessitating an 
inline lookup, and per RFC 2308 the negative response will be cached according 
to values from the SOA that are unrelated to and far exceed the TTL of the 
ANAME.

Ah, I see the confusion.  You're using definitive statements such as
"will" when what you actually mean is "may."   There's no specific
mechanism that causes the client to cache the negative response "for
one to three orders of magnitude greater than the TTL of the ANAME."
And, the TTL of the SOA doesn't necessarily "far exceed" the TTL of
the ANAME.  You're just presupposing that will be a common
configuration?
I am indeed claiming that will be a common configuration, and I have 
access to data supporting that claim from existing use of Oracle+Dyn 
ALIAS functionality. Also, please note that those "will" statements are 
properly understood in the context of the examples they are describing.

I think we're still talking about misconfigurations here, and
designing a protocol around people who misconfigure their DNS at the
expense of people who configure it properly seems like a bad path to
take.
You're pretty much making my point... it is a bad path to design a 
protocol around people who misconfigure their [ANAME-targeted] DNS at 
the expense of people who configure [ANAMEs with static sibling records] 
properly.

Both of these problems can be addressed by allowing/recommending/requiring 
ANAME-aware servers to preserve ANAME siblings when resolution of ANAME targets 
results in NXDOMAIN or NODATA responses, rather than replacing them with an 
empty RRSet... which, to be honest, seems to be always-undesirable behavior 
anyway—if anyone can think of a scenario where it would be beneficial to 
dynamically remove ANAME siblings, please share it.

Yes, I can think of a case where it would be beneficial to remove
ANAME siblings: when the target of the ANAME is removed from the DNS.
That would take the ANAME-owning domain offline, rather than supporting 
it with its static A and/or  records. How exactly is that beneficial?

In such a configuration, the owner of the ANAME will be able to see that 
clients are using its static sibling records rather than its target (and 
therefore that they are getting no benefit from the ANAME), and can react 
accordingly. If your concern is excess queries for the ANAME target, then this 
seems no different from e.g. CNAME—the owner of the target can issue long-lived 
negative responses while performing whatever other exploration and/or 
mitigation they deem fit.

If the target of the ANAME disappears, the owner of the ANAME will
similarly be able to recognize the problem and deal with it.  If the
administrator of the name owning the ANAME is concerned about downtime
due to misconfigurations by the target, then that administrator can
either select a different target (presumably by selecting a different
service provider)
It seems awfully insensitive to bake into a protocol an unnecessary 
requirement of its users for all-or-nothing commitment to external 
service providers.

or set their TTLs appropriately to not be subject to
the potential issue you identified above.
At the unnecessary expense of reducing cache lifetime (and therefore 
undesired traffic) for /all/ negative responses, rather than just those 
associated with the ANAME.

However, if the spec requires preserving the target in the DNS despite
the administrator of the target zone removing it, then that is a path
for abuse by the administrator of the zone containing the ANAME, and
the owner of the target will have no recourse.  This is what I meant
by my reference to serve-stale.
The spec requires nothing like "preserving the target in the DNS", with 
or without my proposed changes. The abuse path you mention is already 
present with CNAME, and mitigable by owners of ANAME targets in exactly 
the same way—increase negative caching TTL (and unlike the above, this 
is a scenario where it /would/ make sense to increase it broadly rather 
than for specific RRSets).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

Responses inline.

On 4/11/19 18:50, Matthew Pounsett wrote:

On Wed, 10 Apr 2019 at 16:43, Richard Gibson
 wrote:

The first problem is for the owner of the ANAME-containing zone, for whom the 
upstream misconfiguration will result in downtime and be extended by caching to 
the MINIMUM value from their SOA, which in many cases will be one to three 
orders of magnitude greater than the TTL of the ANAME itself.

I think I'm missing something here.  If, for example, the TTL of the
ANAME is 1 hour, what mechanism results in caching holding onto a
negative answer for a broken target name for a minimum of 10 hours,
and to 40 days?

Demonstrative example zone:

example.com.  3600  IN    SOA  ns.example.net. hostmaster.example.net. 1 (
  7200   ; REFRESH
  3600   ; RETRY
 86400   ; EXPIRE
  3600  ); MINIMUM
example.com.    60  IN  ANAME  example.invalid.
example.com.60  IN  A  192.0.2.1

When an ANAME-aware resolver queries an ANAME-aware authoritative server 
for example.com. A, it will receive the A record in the answer section 
and the ANAME in the additional section. If it then chases the ANAME 
target to an NXDOMAIN and accepts that as justification for replacing 
the sibling A RRSet with nothing as currently specified in the draft, 
then the appropriate response will be a Type 2 NODATA in which the 
answer section is empty and the additional section contains the SOA. But 
this suffers from both of the problems I have been complaining about—the 
resolver does not necessarily /have/ the zone SOA, possibility 
necessitating an inline lookup, and per RFC 2308 the negative response 
will be cached according to values from the SOA that are unrelated to 
and far exceed the TTL of the ANAME.



Both of these problems can be addressed by allowing/recommending/requiring 
ANAME-aware servers to preserve ANAME siblings when resolution of ANAME targets 
results in NXDOMAIN or NODATA responses, rather than replacing them with an 
empty RRSet... which, to be honest, seems to be always-undesirable behavior 
anyway—if anyone can think of a scenario where it would be beneficial to 
dynamically remove ANAME siblings, please share it.

I feel like this is creating an even bigger potential problem.  What
happens when the owner of the ANAME target legitimately wants that
name to go away, but some other zone owner is leaving an ANAME in
place pointing to that now-nonexistent name?  Continuing to serve the
sibling records indefinitely seems like serve-stale gone horribly
wrong.


In such a configuration, the owner of the ANAME will be able to see that 
clients are using its static sibling records rather than its target (and 
therefore that they are getting no benefit from the ANAME), and can 
react accordingly. If your concern is excess queries for the ANAME 
target, then this seems no different from e.g. CNAME—the owner of the 
target can issue long-lived negative responses while performing whatever 
other exploration and/or mitigation they deem fit.


But this seems like it will be much more rare and frankly much less of a 
problem than stretching out misconfiguration at an ANAME target into 
extended downtime for an ANAME owner. It must be possible for the latter 
to execute a recovery plan as quickly as possible, and if ANAME is 
specified well then that the first step of recovery can be literally 
instant and automatic.


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

Re: [DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

Responses below.

On 4/9/19 16:04, Bob Harold wrote:
If it gets an authoritative answer saying that there are no address 
records, then it should respect that answer.  If that is incorrect, 
then whatever gave that answer is broken or misconfigured and should 
be fixed.


Perhaps I am missing something.  In what cases can you imagine getting 
a response with no errors and no records?


Misconfiguration is precisely the case, but quite possibly 
misconfiguration in the zone of /target/ records as opposed to the zone 
containing the ANAME. And there are two problems with respecting that 
[negative] answer.


The first problem is for the owner of the ANAME-containing zone, for 
whom the upstream misconfiguration will result in downtime and be 
extended by caching to the MINIMUM value from their SOA, which in many 
cases will be one to three orders of magnitude greater than the TTL of 
the ANAME itself.


The second problem is for the query originator and their ANAME-aware 
resolver, which will be forced to resolve the SOA of the 
ANAME-containing zone in order to issue a proper RFC 2308 Type 2 NODATA 
response —and such 
resolution must take place synchronously, tying up resolver resources 
and increasing end-user latency (insignificantly when the SOA is already 
cached, significantly when it is not).


Both of these problems can be addressed by 
allowing/recommending/requiring ANAME-aware servers to preserve ANAME 
siblings when resolution of ANAME targets results in NXDOMAIN or NODATA 
responses, rather than replacing them with an empty RRSet... which, to 
be honest, seems to be always-undesirable behavior anyway—if anyone can 
think of a scenario where it would be /beneficial/ to dynamically remove 
ANAME siblings, please share it.


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

[DNSOP] What should ANAME-aware servers do when target records are verifiably missing?

[Richard Gibson]

Copied from https://github.com/each/draft-aname/issues/54 per Tony Finch.

The current draft specifies

We treat missing address records (i.e. NXDOMAIN or NODATA) the same 
successfully resolving as a set of zero address records, and distinct 
from "failure" which covers error responses such as SERVFAIL or REFUSED.


This is both undesirable for customers of DNS service providers (whose 
active sites will occasionally be inaccessible to some clients for 
$SOA_MINIMUM seconds), and operationally cumbersome because resolvers 
are not in a good position to synthesize the necessary SOA records for 
NXDOMAIN responses (e.g., example.com. ANAME example.invalid. alongside 
example.com. A 192.0.2.1). Tony suggested that this was to be "as much 
like CNAME as possible", but I disagree because unlike CNAME, ANAME can 
have sibling records which are therefore available for use.


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

Re: [DNSOP] ANAME discussion

[Richard Gibson]

If an implementation has a resolver, then that component is the logical 
place for deduplication (e.g., the second inbound query for a given 
ANAME target does not result in a second outbound query, but rather 
waits on completion of the first).


On 4/9/19 11:15, Vladimír Čunát wrote:

On 4/9/19 3:38 PM, Richard Gibson wrote:

This loop is one reason of several to eliminate inline resolution for
ANAME if possible and minimize it otherwise, but is not quite as bad
as it seems because all involved servers can—and should—avoid issuing
queries that are redundant with an already-active request. But even if
they don't, the early queries eventually time out and rate limiting
eventually detects and caps the runaway load.

In other words, this misconfiguration does not create any new
vulnerabilities, and existing mechanisms are already sufficient to
handle it (although the document should explicitly mention them to
avoid subjecting new implementers to unnecessarily painful lessons).

I can't even see a simple way of detecting this.  At least in the
implementation suggested by Jan where you have an authoritative that
calls out to a resolver (which calls out to authoritatives...) - it
would need some magic that somehow links one query of the cycle to the
other but regular DNS queries do not currently carry such information
AFAIK.  Am I missing some obvious approach?

--Vladimir (Knot Resolver)



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

Re: [DNSOP] ANAME discussion

[Richard Gibson]

This loop is one reason of several to eliminate inline resolution for 
ANAME if possible and minimize it otherwise, but is not quite as bad as 
it seems because all involved servers can—and should—avoid issuing 
queries that are redundant with an already-active request. But even if 
they don't, the early queries eventually time out and rate limiting 
eventually detects and caps the runaway load.


In other words, this misconfiguration does not create any new 
vulnerabilities, and existing mechanisms are already sufficient to 
handle it (although the document should explicitly mention them to avoid 
subjecting new implementers to unnecessarily painful lessons).


On 4/9/19 08:09, Jan Včelák wrote:

On Tue, Apr 2, 2019 at 5:54 PM Tony Finch wrote:

WRT loop detection, it is much easier if the additional section in the
response from the resolver contains the chain(s). The draft doesn't
specify that at the moment; maybe it should.

I meant a situation where an authoritative server is doing the sibling
address record substitution using an external resolver.

Imagine the following ANAME loop:
foo. ANAME bar.
bar. ANAME foo.

For simplification, expect the zones to live on different
authoritative servers and also that the ANAME processing triggers with
the first query.

The resolution steps will look something like this:
1. Authoritative receives a query for foo.
2. Authoritative finds the ANAME and calls out to the resolver asking for bar.
3. Resolver sends a query for bar to the authoritative.
4. Authoritative finds the ANAME and calls out to the resolver asking for foo.
5. goto 1

The authoritative server acting as a stub resolver doesn't have full
context of the resolution chain and therefore cannot break the loop.
We would have to pass around additional context in the queries and I'm
not sure if DNS firewalls would be happy to see messages with QR = 0
and ARCOUNT > 0.

Jan

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=4nTLZAsnHCwTJyrARtQ8uzJN8jmKg6JeQX9gDiHuHhc=O9ORRXkRs5TFBIKPXCdq6ck3K88lw-t7xDcNwI-ecMU=


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

Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

[Richard Gibson]

On timekeeping:

On 11/22/18 07:01, Sara Dickinson wrote:

Section 7.5.1

Does "earliest-time" include leap seconds?


Thanks for noticing this…after digging into it…

The description specifies the number of seconds to be the
number of seconds since the POSIX epoch ("time_t"). POSIX requires that
leap seconds be omitted from reported time, and all days are defined as
having 86,400 seconds. This means that a POSIX timestamp can be
ambiguous and refer to either of the last 2 seconds of a day containing
a leap second (who knew time could stand still in POSIX world - aargh?!)

However, libpcap (for example) can only provide POSIX timestamps for
packets as far as we can see…

Do you think we should just document this as a limitation or do you have
another option in mind?


I am currently going through a similar exercise in another context, and 
the best current text there explicitly characterizes the non-obvious 
day-based accounting of POSIX time. In this context, it would look 
something like


   A time value that is a multiple of 86,400 (i.e., is equal to 86,400
   × /d/ for some integer /d/) represents the instant at the start of
   the UTC day that follows the 1970-01-01T00:00Z epoch by /d/ whole
   UTC days. Every other finite time value /t/ is defined relative to
   the greatest preceding time value /s/ that is such a multiple, and
   represents the instant that occurs within the same UTC day as /s/
   but follows it by /t/ − /s/ seconds.

   Time values do not account for UTC leap seconds—there are no time
   values representing instants within positive leap seconds, but there
   are time values representing instants removed from the UTC timeline
   by negative leap seconds. However, the definition of time values
   nonetheless yields piecewise alignment with UTC, discontinuities
   only at leap second boundaries, and zero difference outside of leap
   seconds.

However, there may be C-DNS purposes that cannot tolerate such 
discontinuities, and they would presumably want to use a continuous 
monotonic timescale with a fixed offset from TAI (as is the case for 
e.g. GPS time). It would be nice to have a field in StorageParameters 
defining the time scale and therefore proper interpretation of 
Timestamps, defaulting to UTC-approximating POSIX but also accommodating 
unadjusted seconds counting.


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

Re: [DNSOP] Fundamental ANAME problems

[Richard Gibson]

Responses inline.

On 11/9/18 11:39, Tony Finch wrote:

Richard Gibson  wrote:

First, I am troubled by the requirement that ANAME forces the zone into a
dynamic zone.

I don't see how it is possible to implement ANAME without some form of
dymamic behaviour, either by UPDATEs on the primary, or on-demand
substitution on the secondaries, or some combination of the two.


I am advocating for the special behavior of ANAME be limited to 
processing of non-transfer queries (i.e., explicitly excluding AXFR and 
IXFR). For example: ANAME-aware authoritative servers MAY attempt 
sibling replacement in response to address or ANY queries and SHOULD add 
records to the additional section in response to address or ANAME 
queries; ANAME-aware resolvers SHOULD do both. But all authoritative 
servers should agree that the sibling records—including their original 
TTLs—are a non-special part of zone contents for the purposes of transfers.



Second, and relatedly, I think the TTLs of replacement records established for
non-transfer responses are too high. Respecting the TTL of every record in a
chain that starts with the ANAME requires the TTL of final replacement records
to be no higher than the minimum TTL encountered over the chain, potentially
/reduced/ nondeterministically to mitigate query bunching. I would therefore
add language encouraging resolvers synthesizing those records to engage in
best-effort determination of original TTLs by (e.g., by directly querying
authoritative servers and refreshing at 50% remaining), but *requiring* them
to decrement TTLs of records for which they are not authoritative.

I'm not sure I understand which TTLs you are worried about here. What are
"non-transfer responses"? There's certainly some rewording needed to make
it more clear, but the TTLs returned by resolvers that do sibling address
record substitution are decremented in the usual way, and resolvers make
no attempt to determine the original TTLs.
I hope the above clarifies... my TTL concerns relate not to resolvers, 
but to authoritative servers. In particular, I take issue with the 
"/Sibling address records are committed to the zone/" and "/Sibling 
address records are served from authoritative servers with a fixed TTL/" 
text, which stretches the TTL of one or more RRSets along the target 
name's resolution chain.

And finally, back on the question of what ANAME sibling address records
actually represent, I think that NXDOMAIN and NODATA results should be treated
as errors for the purposes of ANAME sibling replacement. This position can be
justified on both practical and principled grounds—replacing functional
records with an empty RRSet is undesirable for DNS users (or at least the
sample of them that are Oracle+Dyn customers),

Maybe so, but that's what happens with CNAME records.
CNAME does not allow for siblings, and therefore its processing is 
incapable of replacing functional records with an empty RRSet. Further, 
clients are required to understand CNAME and can therefore always 
identify at which domain name an issue lies (and in particular that it 
is not the queried name).

Let's please just eliminate all of that by specifying that ANAME
processing can never replace something with nothing.

So when the target goes away, you would prefer to leave behind zombie
address records, and stretch their TTL indefinitely? If the zone admin is
given only a target hostname (just like a CNAME) they don't have any
alternative addresses to use when the target goes away. So the options are
to copy the target by deleting the addresses, or ignore the target and
leave the addresses to rot.
When the target goes away, there is no longer anything to replace the 
sibling records, which are not zombies but rather part of the zone 
contents and always issued by authoritative servers with their original 
TTL (just like every other record, including the ANAME itself). Only if 
there are no sibling records could an authoritative server issue a 
NODATA response, and if a /resolver/ cannot successfully resolve an 
ANAME target to non-expired records, then it should re-resolve the 
requested RRSet anyway—it will get from upstream either refreshed 
fallbacks or a NODATA, and in either case then has a response for its 
own client.

I'm inclined to say that fallback records should remain a non-standard
feature. The semantics can be that when you see the target go AWOL, delete
the ANAME and its siblings, and replace them with the fallback records
that were specified by some other means. You can apply the same logic to
CNAMEs too, if you want :-)
A system that complicated would /have/ to be non-standard, but I think 
you're reading too much into my use of the term "fallback". It's not a 
specification of special treatment, but rather the absence of such that 
gives ANAME sibling records that status... they're what to serve when 
nothing replaces them (i.e., the current semantics of every record in

Re: [DNSOP] Fundamental ANAME problems

[Richard Gibson]

I have finally reviewed the latest draft directly, and like the overall 
direction but have a small number of issues (however, the issues 
theirselves are somewhat fundamental). They broadly break down into 
concerns about zone transfers and TTL stretching, and ultimately seem to 
stem from a disagreement with my position that the proper conception of 
ANAME sibling address records is as fallback data to be used in cases 
where ANAME target resolution fails or is never attempted.


First, I am troubled by the requirement that ANAME forces the zone into 
a dynamic zone. That a primary master would dynamically replace sibling 
records on its own, update the zone serial, and then propagate that 
dynamic data via zone transfer overrides user conception about the state 
of a zone, induces undesirable churn between authoritative nameservers, 
/and/ stretches the TTLs of ANAME targets on downstream servers by the 
amount of time between successive updates. These consequences are just 
too much for what is supposed to be a low-impact feature. Anyone willing 
to opt-in to them should be updating the ANAME sibling address records 
on their own, not forcing authoritative server implementations to choose 
between taking on that dirty work or being labeled noncompliant.


Second, and relatedly, I think the TTLs of replacement records 
established for non-transfer responses are too high. Respecting the TTL 
of every record in a chain that starts with the ANAME requires the TTL 
of final replacement records to be no higher than the minimum TTL 
encountered over the chain, potentially /reduced/ nondeterministically 
to mitigate query bunching. I would therefore add language encouraging 
resolvers synthesizing those records to engage in best-effort 
determination of original TTLs by (e.g., by directly querying 
authoritative servers and refreshing at 50% remaining), but *requiring* 
them to decrement TTLs of records for which they are not authoritative.


And finally, back on the question of what ANAME sibling address records 
actually represent, I think that NXDOMAIN and NODATA results should be 
treated as errors for the purposes of ANAME sibling replacement. This 
position can be justified on both practical and principled 
grounds—replacing functional records with an empty RRSet is undesirable 
for DNS users (or at least the sample of them that are Oracle+Dyn 
customers), and could inappropriately stretch the maximum specified 
ANAME sibling TTL (on the ANAME record itself) to the SOA MINIMUM value 
(which is doubly bad, because it results in extended caching of the 
/least/ valuable state). And adding insult to injury, resolvers in 
general will not even have the SOA, and will need to perform more 
lookups in order to issue a proper negative response of their own. Let's 
please just eliminate all of that by specifying that ANAME processing 
can never replace something with nothing.


P.S. There is a typographical error in Appendix D; "RRGIG" should be 
"RRSIG".


P.P.S. I think it has been discussed before, but this document should 
also introduce and use a new "Address RTYPE" registry or subregistry, 
rather than forever constraining ANAME exclusively to A and AAAA.


On 11/2/18 17:00, Richard Gibson wrote:


I haven't reviewed the full draft yet, but am happy to see some people 
echoing my sentiments from earlier versions [1]. I particularly wanted 
to agree with some statements from Bob Harold.


On 11/2/18 15:20, Bob Harold wrote:
Another option to give users is a non-updating fallback A record, 
that could point to a web redirect.  That saves all the hassle of 
updates.


YES! This means a slightly worse fallback-only experience for users 
behind ANAME-ignorant resolvers that query against ANAME-ignorant 
authoritatives (the introduction of ANAME awareness to /either/ 
component allowing an opportunity to provide better address records by 
chasing the ANAME target), but provides a dramatic reduction in the 
amount of necessary XFR traffic. And even more importantly, it forces 
TTL stretching to be an explicit decision on the part of those 
administrators who choose to perform manual target resolution and 
update their zones to use them as fallback records (as they would do 
now to approximate ANAME anyway), rather than an inherent and enduring 
aspect of the functionality.


Treating ANAME-sibling address records as fallback data also supports 
better behavior for dealing with negative results from resolving ANAME 
targets (NODATA, NXDOMAIN, signature verification failure, response 
timeout, etc.)—serve the fallbacks.


My preference would be a *NAME record that specifies which record 
types it applies to.  So one could delegate A and  at apex to a 
web provider, MX to a mail provider, etc.  That would also be 
valuable at non-apex names.  But I am happy to support ANAME as part 
of the solution.
I agree on both counts (arbitrary type-specificity and deferment to a 
later date)

Re: [DNSOP] Further ANAME minimization /\ Ray convergence

[Richard Gibson]

This is such a salient point, and always draws me back towards a desire 
for accompanying questions. They wouldn't directly address exactly the 
issue handled by ANAME (the addresses of one host corresponding to those 
of a distinct [probably out-of-bailiwick] name), but might make it 
moot—or at least tolerable—by tackling more fundamental progress 
blockers. Support for covering apex A, apex , and service-specific 
SRV (especially with target host addresses in the additional section of 
the response) in a single transaction could absolve many sins.


On 11/6/18 13:51, Ray Bellis wrote:
IMHO, any record that doesn't support a service selector isn't doing 
its job properly.


You _have_ to be able to say "if I want this service at this domain, I 
either prepend this prefix, or lookup this type", otherwise you're 
just forcing _all_ services to connect to the A and  found there.


A and  should be for connecting to the right _host_, once you've 
established from the _service_ which host that is.


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

Re: [DNSOP] Fundamental ANAME problems

[Richard Gibson]

I haven't reviewed the full draft yet, but am happy to see some people 
echoing my sentiments from earlier versions [1]. I particularly wanted 
to agree with some statements from Bob Harold.


On 11/2/18 15:20, Bob Harold wrote:
Another option to give users is a non-updating fallback A record, that 
could point to a web redirect.  That saves all the hassle of updates.


YES! This means a slightly worse fallback-only experience for users 
behind ANAME-ignorant resolvers that query against ANAME-ignorant 
authoritatives (the introduction of ANAME awareness to /either/ 
component allowing an opportunity to provide better address records by 
chasing the ANAME target), but provides a dramatic reduction in the 
amount of necessary XFR traffic. And even more importantly, it forces 
TTL stretching to be an explicit decision on the part of those 
administrators who choose to perform manual target resolution and update 
their zones to use them as fallback records (as they would do now to 
approximate ANAME anyway), rather than an inherent and enduring aspect 
of the functionality.


Treating ANAME-sibling address records as fallback data also supports 
better behavior for dealing with negative results from resolving ANAME 
targets (NODATA, NXDOMAIN, signature verification failure, response 
timeout, etc.)—serve the fallbacks.


My preference would be a *NAME record that specifies which record 
types it applies to.  So one could delegate A and  at apex to a 
web provider, MX to a mail provider, etc.  That would also be valuable 
at non-apex names.  But I am happy to support ANAME as part of the 
solution.
I agree on both counts (arbitrary type-specificity and deferment to a 
later date).



[1]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21722.html

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

Re: [DNSOP] review: draft-wessels-dns-zone-digest-04.txt

[Richard Gibson]

On 10/31/18 19:50, Joe Abley wrote:

It sounds wrong to me to say that identical instances of RRs would not be 
allowed in a zone.

It's true though, right? It's not meaningful to include more than one resource 
record with the same (owner,type, class, TTL, RDATA) in the same RRSet, and 
hence also not meaningful to include such duplicates in a single zone (which is 
a particular set of RRSets). I don't think RFC 1034 is explicit about this, but 
it's surely implied. I don't know of any nameserver software that would allow 
duplicates like that, though, with the possible exception of the SOA. Quite 
possibly I have just typed more nonsense about this than the world ever needed 
to see.


RFC 2181 section 5: "It is meaningless for two records to ever have 
label, class, type and data all equal - servers should suppress such 
duplicates if encountered."


And RFC 7719 section 4 affirms the "different data" requirement.

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

Re: [DNSOP] Genart last call review of draft-ietf-dnsop-terminology-bis-11

[Richard Gibson]

On 08/10/2018 11:51 AM, Giovane C. M. Moura wrote:

The response is the entire DNS message that is sent in reply to a
question.

Great. Do you plan to define it in the document as well?
Analogous to a "response" DNS message containing an "answer" (presumably 
consisting of zero or more records), I'd be equally precise about a 
"query" DNS message containing a "question" (consisting of zero or more 
entries, but with any count other than 1 being essentially meaningless) 
and avoid conflating those terms.


https://tools.ietf.org/html/rfc1035#section-4.1.2 :
> The question section is used to carry the "question" in most queries, 
i.e., the parameters that define what is being asked.


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

Re: [DNSOP] I-D Action: draft-bellis-dnsext-multi-qtypes-06.txt

[Richard Gibson]

This is conceptually similar to [accompanying-questions], but limits all 
questions to share a QNAME. The result is a more concise payload and 
simpler processing logic at the expense of an ability to request e.g. 
(www.example.com, A) and (_443._tcp.www.example.com, TLSA) in one query. 
I can imagine many scenarios where such queries would be valuable, 
though, and am suspicious about the tradeoff (which essentially supports 
only A+ queries) being worthwhile. [accompanying-questions] had some 
[issues] of its own to work out, but seemed to fall at approximately the 
right level of flexibility for allowing clients to query for more than 
one tuple.


[accompanying-questions]: 
https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/

[issues]: https://www.ietf.org/mail-archive/web/dnsop/current/msg21085.html


On 07/02/2018 08:51 AM, internet-dra...@ietf.org 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 Multiple QTYPEs
 Author  : Ray Bellis
Filename: draft-bellis-dnsext-multi-qtypes-06.txt
Pages   : 7
Date: 2018-07-02

Abstract:
This document specifies a method for a DNS client to request
additional DNS record types to be delivered alongside the primary
record type specified in the question section of a DNS query.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes_=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=nAF1psaBl4BrcSH12DDD8-h4jVVriftlNvhtAmFlY5Q=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=D1oTk_bgVu4lj3OjjuiXoxOIuBBbIL0KO6kbHZ9_hRM=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=8WzllvYxQajep8eqJqq3yV2J_tRoOKYnow5bwzceXx8=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dbellis-2Ddnsext-2Dmulti-2Dqtypes-2D06=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=J471bGTuh5C7VV8996erxtZkgU-KZ5fbUOgkqqEtR-I=


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:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=kfPI_hiW8R7kJUNYC9wrFWmPV07xPNgiZcm7jtOdhjA=

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=qoeMRqSzFwqsFQC8jC1yu3vx8EparFX7LesUv2k9jCM=aFTa0u2T8MtsiQHha6UQaRdLL3FoifHiU9sY-XorioQ=


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-07.txt

[Richard Gibson]

This update addresses all of my earlier comments with the exception of 
implementation-specific extension data using namespaced string keys (as 
opposed to negative-integer keys)—which I assume to be intentional 
because of the "String keys would significantly bloat the file size" 
text in Section 7.1—and the ability to support variable truncation of IP 
addresses—particularly for identifying the full addresses of responders 
while truncating the addresses of requestors, but also for retaining 
more requestor precision in some subnets than others.


This format in its present state /can/ work for my organization, but the 
second gap in particular means we'll be manually hacking around those 
deficiencies by e.g. representing 192.0.2.0/24 as 192.0.2.0/32 in order 
to fully specify 198.51.100.42/32.



On 05/08/2018 12:55 PM, Sara Dickinson wrote:

Hi All,

This update addresses the following issues:

* Resolve outstanding questions and TODOs
* Make RR RDATA optional
* Update matching diagram and explain skew
* Add count of discarded messages to block statistics
* Editorial clarifications and improvements

Regards

Sara.


On 8 May 2018, at 17:40, internet-dra...@ietf.org 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   : C-DNS: A DNS Packet Capture Format
Authors : John Dickinson
  Jim Hague
  Sara Dickinson
  Terry Manderson
  John Bond
Filename: draft-ietf-dnsop-dns-capture-format-07.txt
Pages   : 64
Date: 2018-05-08

Abstract:
   This document describes a data representation for collections of DNS
   messages.  The format is designed for efficient storage and
   transmission of large packet captures of DNS traffic; it attempts to
   minimize the size of such packet capture files but retain the full
   DNS message contents along with the most useful transport metadata.
   It is intended to assist with the development of DNS traffic
   monitoring applications.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat_=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=-u1MK57BW5D8-4pRW93F3iGOeUleCbk_ZcBsHqaJ9t8=

There are also htmlized versions available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=C3JyMunVCDkuQmIVefLLP1pxe8CEegg7nfoL1klK_To=
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=wyWytvxkoi319adauctYZq3PVsUMYE-kzBYRzKivPjU=

A diff from the previous version is available at:
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=JlUS92uQuF7x5Xjb75Uxjp6fMTaaoEAux_ZacxCvN_U=


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:
https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=L3Jo61TkqDrhjdg5YB-37i96KK9yh5WVilrcK6DUj9Y=

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=1OG0b26AkBwGSkwxhcNHmA2EPht8H6ZYV2sgkIfomRE=

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo=1OG0b26AkBwGSkwxhcNHmA2EPht8H6ZYV2sgkIfomRE=


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

Re: [DNSOP] A new version of mixfr

[Richard Gibson]

I really like this document, especially the changes to version 02.

One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH 
must be non-zero" _and_ that "The same syntax is used to delete an RRset 
and to replace an RRset with an RR whose RDLENGTH is zero". I think the 
former should be dropped; replacing an RRset with a new record having 
zero RDLENGTH is disambiguated by containing section so there is no 
reason to prohibit it.



On 03/28/2018 09:31 AM, Matthijs Mekking wrote:

All,

It's been a while, but I have put up a new version of the MIXFR draft:

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmekking-2Dmixfr-2D02=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9E3JS209vJp6dQBpJJBXlr32ZbLYLOLNNAiovQ1iAnY=

The IETF 101 Hackathon lead to the revival of this draft.

Changes after the three year sleep:

- I removed the IXFR Gone Wild section. This document should focus in 
the in-band transfer improvements. I know there are others who like to 
see and work on a new DNS transfer protocol, but one does not exclude 
the other.

- Intended status: Standards track.
- Added a clarification from Bob Harold about class ANY (from 2015).
- Remove ambiguous "Delete All RRsets of a Type".
- Affiliation changes.

Who would like to contribute, review, and all that great fun?

Github is here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_matje_mixfr=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9jcbJIa5DBxRHlL2wVDEwCWBJXvbZffQobFtQvjEMH0=


Best regards,
  Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=n1GMn0ZrYJoVbOVyFWt2A2n2n6d5T3xoCwjdK8xsbiw= 



___
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

[Richard Gibson]

TSIGs cover "A whole and complete DNS message in wire format, before the 
TSIG RR has been added to the additional data section and before the DNS 
Message Header's ARCOUNT field has been incremented to contain the TSIG 
RR" (RFC 2845 section 3.4.1), and would therefore be sensitive to 
decompression.



On 03/26/2018 11:33 AM, Michael Casadevall wrote:

2. Resolvers MUST never generate obsolete RRtypes in a compressed
format. If (in line with below) the resolver receives a record in
compressed form, it MUST be decompressed before being sent to downstream
resolvers as though. Resolvers SHOULD warn that they are unpacking
records in transit.

How's that sound? I'm still somewhat iffy on my understanding of DNSSEC
RRSIG canonical forms, but if I understood the RFCs correctly, the
uncompressed record should match the canonical form the RRSIG validates
against to which in turn is identical to RFC 3597 (aside from WKS,
although RFC 2136 suggests it only applies in the case of DNS update and
not validation)

It specifically states you're allowed to understand, but thou must not
speak. If there's a DNSSEC concern, it should be noted though I don't
think it's a showstopper in and of itself. As previously stated, I very
much doubt these records are commonly if ever signed.


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

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-dns-wireformat-http-02.txt

[Richard Gibson]

I personally would rather see a single media type with a transport 
parameter than creation of a distinct media type for each transport 
(UDP, TCP, QUIC, …).



On 03/21/2018 09:36 PM, Davey Song wrote:

Hi folks,

I just submit a updated version of dns wireformat over HTTP. This 
draft has been adopted as the dnsop wg document for quite a while 
before DOH.  The original intention of this draft is to explore the 
possiblity of DNS over HTTP(s) use cases and demonstrate its capacity 
as an experimental draft. But the draft lacked enough specification on 
HTTP requirement and context at that time. Since DOH later was setup 
focusing on developing https as DNS transport protocol. So I updated 
this draft as a a special use case of DOH which served as DNS proxy.


I would like to ask comments and advice in dnsop and doh wgs mainly 
two quesions:
1) (for dns people) Does this proxy use case sounds useful as a IETF 
experiment document .
2) (for HTTP people) Is a media type "application/dns-tcpwireformat" 
acceptable specially for this use case. We also consider to introduce 
an optional parameter to existing "application/dns-udpwireformat" MIME 
in DOH document, because the two media type carries the identical 
message body (the udp dns wireformat) in DOH request  in proxy use 
case. We need suggestion here.


Thank to Tim and Paul Hoffman to bring this draft alive.

Davey

-- Forwarded message --
From: >
Date: 22 March 2018 at 08:59
Subject: New Version Notification for 
draft-ietf-dnsop-dns-wireformat-http-02.txt
To: Shane Kerr >, Paul Vixie >, Linjian Song >




A new version of I-D, draft-ietf-dnsop-dns-wireformat-http-02.txt
has been successfully submitted by Linjian Song and posted to the
IETF repository.

Name:           draft-ietf-dnsop-dns-wireformat-http
Revision:       02
Title:          An Proxy Use Case of DNS over HTTPS
Document date:  2018-03-21
Group:          dnsop
Pages:          6
URL: 
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-dns-wireformat-http-02.txt 

Status: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-wireformat-http/ 

Htmlized: 
https://tools.ietf.org/html/draft-ietf-dnsop-dns-wireformat-http-02 

Htmlized: 
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-wireformat-http 

Diff: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-wireformat-http-02 



Abstract:
   This memo introduces a DNS proxy use case to tunnel DNS query and
   response over HTTPs using DOH, a newly proposed DNS transport.  This
   is useful in some situation where DNS is not working properly and DOH
   is not widely available for many stub-resolvers.




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 
.


The IETF Secretariat




___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

[Richard Gibson]

That was literally the fastest turnaround I've ever experienced. All the 
changes look good to me; thank you very much.



On 03/05/2018 04:47 PM, Joe Abley wrote:

On 5 Mar 2018, at 15:00, Richard Gibson <richard.j.gib...@oracle.com> wrote:


To re-raise my unaddressed points:

• The document should include planned text you mentioned acknowledging lack of a 
signal to indicate "partial response" for section 4.1/section 4.3 subset 
responses ([1]).
• "Conventional [ANY] response" is used but not defined ([2]).
• The document needs to identify itself as updating RFC 1034 
(specifically, section 4.3.2).
• In section 7, "ANY does not mean ALL" is misleading—[RFC 1035 section 3.2.3] is 
clear about QTYPE=255 being "a request for **all** records" (emphasis mine). That said, 
the proposed response behavior is consistent with that RFC.
[1]: https://www.ietf.org/mail-archive/web/dnsop/current/msg20629.html
[2]: https://www.ietf.org/mail-archive/web/dnsop/current/msg20628.html
[RFC 1035 section 3.2.3]: https://tools.ietf.org/html/rfc1035#section-3.2.3

Many apologies for missing those. Fortunately I had spare minutes before the 
cut-off. With luck the following will address those issues; if not, you can 
look forward to another rev in a couple of weeks.

Begin forwarded message:


From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-dnsop-refuse-any-06.txt
Date: 5 March 2018 at 16:44:49 EST
To: "Joe Abley" <jab...@afilias.info>, "Marek Majkowski" <ma...@cloudflare.com>, "Olafur 
Gudmundsson" <olafur+i...@cloudflare.com>


A new version of I-D, draft-ietf-dnsop-refuse-any-06.txt
has been successfully submitted by Joe Abley and posted to the
IETF repository.

Name:   draft-ietf-dnsop-refuse-any
Revision:   06
Title:  Providing Minimal-Sized Responses to DNS Queries that have 
QTYPE=ANY
Document date:  2018-03-05
Group:  dnsop
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-refuse-any-06.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-06
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-refuse-any-06
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-06

Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.




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.

The IETF Secretariat





___
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] Fwd: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt

[Richard Gibson]

To re-raise my unaddressed points:

 * The document should include planned text you mentioned acknowledging
   lack of a signal to indicate "partial response" for section
   4.1/section 4.3 subset responses ([1]).
 * "Conventional [ANY] response" is used but not defined ([2]).
 * The document needs to identify itself as updating RFC 1034
   (specifically, section 4.3.2).
 * In section 7, "ANY does not mean ALL" is misleading—[RFC 1035
   section 3.2.3] is clear about QTYPE=255 being "a request for **all**
   records" (emphasis mine). That said, the proposed response behavior
   is consistent with that RFC.

[1]: https://www.ietf.org/mail-archive/web/dnsop/current/msg20629.html
[2]: https://www.ietf.org/mail-archive/web/dnsop/current/msg20628.html
[RFC 1035 section 3.2.3]: https://tools.ietf.org/html/rfc1035#section-3.2.3


On 03/05/2018 02:28 PM, Joe Abley wrote:

Hi all,

Per subject, see below, etc. I apologise for the ludicrous amount of time it 
has taken for me to do these final edits. Fortunately the beatings continued 
until the morale improved.

I believe the -05 represents a reasonable facsimile of the consensus of 
suggestions that came up at the working group last call, which some of you may 
recall (others are no doubt too young). Apart from language changes, the 
principal change from the -04 is a softening of the language regarding RRSIG, 
basically punting any such specification to future work whilst observing the 
potential for alignment in approach. This seemed like a reasonable compromise 
and arguably better than specifying behaviour without the benefit of real-world 
experience or detailed RRSIG-specific thinking.


Joe


Begin forwarded message:

From: internet-dra...@ietf.org
Subject: New Version Notification for draft-ietf-dnsop-refuse-any-05.txt
Date: 5 March 2018 at 14:17:50 EST
To: "Joe Abley" , "Marek Majkowski" , "Olafur 
Gudmundsson" 


A new version of I-D, draft-ietf-dnsop-refuse-any-05.txt
has been successfully submitted by Joe Abley and posted to the
IETF repository.

Name:   draft-ietf-dnsop-refuse-any
Revision:   05
Title:  Providing Minimal-Sized Responses to DNS Queries that have 
QTYPE=ANY
Document date:  2018-03-05
Group:  dnsop
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-ietf-dnsop-refuse-any-05.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
Htmlized:   https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-05
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-refuse-any-05
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-05

Abstract:
   The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
   The operator of an authoritative DNS server might choose not to
   respond to such queries for reasons of local policy, motivated by
   security, performance or other reasons.

   The DNS specification does not include specific guidance for the
   behaviour of DNS servers or clients in this situation.  This document
   aims to provide such guidance.




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.

The IETF Secretariat




___
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] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

[Richard Gibson]

On 02/28/2018 12:21 PM, Jim Hague wrote:

We'll discuss this. We absolutely meant for negative keys to be
restricted to closed systems. Allowing string keys in addition is an
interesting idea; off the cuff, I wonder whether folk will want to pay
the file space penalty.
The cost of interoperability. An understandable concern for raw files, 
but repetitions of the same string keys would compress extremely well.

* Section 7.4.1.1: StorageParameters fields "opcodes" and "rrtypes"
could be defined better... are they values /recorded/ (i.e., that were
actually observed) or values that are /recordable/ (i.e., that the
collection application was looking for)? And shouldn't they be optional
(in either case, but *especially* the latter, lest implementations write
out every possible rrtype value).

The intention is that they should be /recordable/ values - in line with
the rest of the StorageParameters fields, they let a reader distinguish
values that aren't present because the writer didn't understand them and
values not present because they didn't occur in the data stream. And
yes, we're thinking implementations should explicitly write each opcode
and rrtype they understand.
Especially in our closed system, I don't see us keeping current another 
list of supported RR types. So we'd probably leave the array empty, 
violating the spirit of the spec if not the letter of it. But on the 
plus side, the size of the complete list in CBOR was smaller than I 
anticipated—less than 100 bytes.

The thinking here is that
if, say, an rrtype the writer does not know how to decode contains a
compressed label, it's not going to be correctly handled, and we should
not be recording potentially known-broken data in the file as not malformed.
I sure hope that no new types violate RFC 3597 section 4. The problems 
with corrupted data in captures pale in comparison to the problems with 
corrupted data in live messages.

We need to clarify the language. qr-transport-flags is a single bit
IPv4/v6, a 4 bit number indicating the protocol, and a final single bit
indicating the presence of trailing data in the query. The protocol
values are (currently) UDP=0, TCP=1, TLS=2, DTLS=3. We did consider a
UDP/TCP bit and a !TLS/TLS bit, but felt this (a) might imply a closer
connection between TLS and DTLS than is the case, and (b) would not
easily extend to possible future schemes like DOH and DNS over QUIC. So
we went for a number with sufficient range to add another 12 options
before trouble happens. We considered breaking the number out to a
separate integer, but felt that this was likely, in practice, to be
unnecessary and so space efficiency considerations took precedence.
Thank you, that explanation greatly clears things up and the reasoning 
is sensible. I would recommend updating the text to something like "Bit 
1-4. Transport.  = plain-text UDP, 0001 = plain-text TCP, 0010 = TLS 
[over TCP?], 0011 = DTLS [over UDP?]" (with a note in Section 7.2 that 
bit sequences are presented in descending significance).


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-05.txt

[Richard Gibson]

Thank you so much for the changes, I am confident that this format is 
now in a state where my organization could build on top of it to suit 
our needs. I have a handful of remaining comments below, mostly 
describing ways in which that process could be made more straightforward 
and standardized.


* Section 6.2.1 and 7.5.3.4: At minimum, RR field "ttl" should be 
optional in order to accommodate aggregation of resolver responses in 
which that field is decremented over time. But probably "rdata-index" 
should be optional as well.


* Section 7.1: Negative integer map keys are concise, but they come with 
the potential for interoperability-hostile collisions. I think the 
document should encourage restricting their use to tightly-controlled 
closed systems, and then additionally propose a particular namespacing 
pattern (e.g., "{namespaceName}-{keyName}") for use of 
implementation-specific /string/ keys in other cases. Further, it should 
explicitly reserve positive integer keys for future standardized 
extensions to the C-DNS format.


* Section 7.4.1: Why is BlockParameters an array instead of a map?

* Section 7.4.1.1: StorageParameters fields "opcodes" and "rrtypes" 
could be defined better... are they values /recorded/ (i.e., that were 
actually observed) or values that are /recordable/ (i.e., that the 
collection application was looking for)? And shouldn't they be optional 
(in either case, but *especially* the latter, lest implementations write 
out every possible rrtype value).


* Section 7.5.3: It's very good that the BlockTables "ip-address" items 
can be truncated by prefix length, but we have actually run into cases 
that call for /variable/ truncation (i.e., more precision in some 
subnets than in others), especially true given that a single table holds 
both client and server address data. What would you think about 
representing addresses not as direct byte strings, but rather as 
variable-length arrays or maps—index 0 encoding the prefix as a byte 
string, and optional index 1 (when present) encoding a prefix-length 
override? Or, if the extra size per address is too much, at least 
allowing such representations via polymorphism (byte string for default 
prefix-length, array/map for non-default)?


* Section 7.5.3.2: QueryResponseSignature field "qr-transport-flags" 
seems to reserve 1 bit /each/ for UDP, TCP, TLS, and DTLS, but it seems 
to me that UDP is mutually exclusive with TCP and that TLS is mutually 
exclusive with DTLS. Couldn't that data be represented in two bits (one 
in which 0 ⇒ UDP and 1 ⇒ TCP, the other in which 0 ⇒ plain-text and 1 ⇒ 
TLS)?



On 02/22/2018 07:31 AM, Sara Dickinson wrote:

Hi Folks,

We have an update to draft which we hope captures all the comments to-date.

- Make all data items in Q/R, QuerySignature and Malformed Message arrays 
optional
- Re-structure the FilePreamble and ConfigurationParameters into BlockParameters
- BlockParameters has separate Storage and Collection Parameters
- Storage Parameters includes information on what optional fields are present, 
and flags specifying anonymisation or sampling
- Addresses can now be stored as prefixes.
- Switch to using a variable sub-second timing granularity
- Add response bailiwick and query response type
- Add specifics of how to record malformed messages
- Add implementation guidance
- Improve terminology and naming consistency

There are still a number of ‘QUESTIONS’ in the draft that we would appreciate 
feedback on.

Regards

Sara.


On 22 Feb 2018, at 12:27, internet-dra...@ietf.org 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   : C-DNS: A DNS Packet Capture Format
Authors : John Dickinson
  Jim Hague
  Sara Dickinson
  Terry Manderson
  John Bond
Filename: draft-ietf-dnsop-dns-capture-format-05.txt
Pages   : 62
Date: 2018-02-22

Abstract:
   This document describes a data representation for collections of DNS
   messages.  The format is designed for efficient storage and
   transmission of large packet captures of DNS traffic; it attempts to
   minimize the size of such packet capture files but retain the full
   DNS message contents along with the most useful transport metadata.
   It is intended to assist with the development of DNS traffic
   monitoring applications.


The IETF datatracker status page for this draft is:
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat_=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=S0pguE4aKgWT-7tOAVBInPr7s58myqhSmv9WtwMzeNA=522TfZMUJHLQox2FWFORwOQXhrlqwp36X9Ty1v54YeI=

There are also htmlized versions available at:

Re: [DNSOP] I-D Action: draft-huston-kskroll-sentinel-04.txt

[Richard Gibson]

Indeed, the concept of "address record" has also come up in 
https://tools.ietf.org/html/draft-ietf-dnsop-aname-01 , which even 
suggests (but does not specify) the creation of an IANA registry.



On 01/29/2018 05:37 PM, Martin Hoffmann wrote:

Warren Kumari wrote:

Yes, you are right -- for all places where there is 'A' it should be
'A or '; how do people feel about something along the lines of:

"Throughout this document, we are using A to refer to an Address
record (either 'A' or  '') " -- having "A or " scattered all
over the document makes it now flow as nicely...

Perhaps define a term for "A or " such as "address record"? That
could potentially be useful as a general term in more contexts.

Kind regards,
Martin

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=IgPbrWR6stuN7EM0GwJxqlFLRK6hEx84qtzcWWHMExA=9h6luQk0E_2DJUP0z5j846tHq6g7w4VMI8v7-scoQfQ=


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

Re: [DNSOP] I-D Action: draft-ietf-dnsop-aname-01.txt

[Richard Gibson]

Comments on the latest ANAME draft:

In Section 3.1, "records retrieved during ANAME <> resolution" looks 
like a typo. Should "<>" be ""?


Also in Section 3.1, the first five paragraphs could be more explicit 
about resolving and adding address records instead of specifically A 
and/or  (other than as examples).


Also in Section 3.1, the final paragraph will result in universal 
SERVFAIL responses if an ANAME target is in a misconfigured signed zone, 
even if the zone containing the ANAME is _not_ signed (and a 
corresponding traffic spike from ANAME-ignorant resolvers).


In Section 4, "resolution fails" should be better defined. Specifically, 
may resolvers use server-provided records if their own query results in 
NODATA or NXDOMAIN?


I think zone transfer considerations merit their own section, rather 
than being buried in and mixed with DNSSEC in 3.3. And because of those 
considerations, I consider it a mistake to prohibit secondary servers 
from resolving ANAME targets when there are address records at the same 
node as is required by Section 3.2. Behavior in error cases, including 
those stemming from ANAME-ignorant participants, seems to be much more 
preferable if such address records are treated as fallback data occluded 
during healthy operation:


1. *ANAME-ignorant primary, ANAME-aware secondary*: The secondary will
   have access to fallback data from the zone, but will only include it
   in responses when its own ANAME target resolution fails. The
   secondary can thus provide better answers to ANAME-ignorant clients
   when responses for the ANAME target are tailored.
2. *ANAME-aware primary, ANAME-ignorant secondary*: Including expanded
   records in the transferred zone data results in stretching ANAME
   TTLs and failing to update anything until secondary refresh, but
   /not/ including them would almost completely suppress ANAME
   functionality. I think the tradeoffs here need further analysis;
   more on that below.
3. *Address-including zone, address-lacking target*: An ALIAS-aware
   server will be able to locally resolve answers from the target name
   for address types that it has (e.g., A), while still providing
   nonempty answers from the zone for those it lacks (e.g., ). At
   least Oracle [Dyn] customers actually prefer such behavior, as I
   mentioned in
   https://www.ietf.org/mail-archive/web/dnsop/current/msg20061.html .
   But note that it requires authoritative servers to override NODATA
   responses to ANAME target resolution, changing the last two
   paragraphs of Section 3.1.
4. *Address-ignorant primary, address-aware secondary*: Assuming that a
   new address record has been defined that the primary does not know
   of, the secondary will be able to include locally-resolved data for
   it, whether or not zone data includes the new type. In cases where
   the zone data just hasn't been updated, this behavior is better than
   assuming it has been pre-expanded to an empty set.
5. *Address-aware primary, address-ignorant secondary*: Assuming that a
   new address record has been defined which the primary knows of but
   the secondary does not, the transferred zone data should include
   pre-expanded answers of the type so the secondary has them available
   for its responses (since it doesn't know to look them up on its
   own). This informs the question from case 2 above, but does not
   completely resolve it (see below).
6. And layering DNSSEC on top of the above (i.e., assuming the
   ANAME-containing zone is signed), *ANAME-aware secondary without a
   zone-signing private key*: I agree that there is no reason for a
   secondary to respond with data that it cannot sign, but it should
   still include signed (fallback) data that ANAME-aware clients will
   attempt to override with local resolution. But how is the XFR server
   to know if the XFR client can add valid signatures?

Regarding zone transfers in which the secondary server is ignorant of 
ANAME altogether, or the inclusion of a new address type, it seems clear 
that primary servers capable of pre-expansion should do so. But in my 
mental model, there's a distinction between static in-zone fallback data 
and data that was resolved upstream (the latter subject to TTL 
decrementing and local refreshes, the former not), and ANAME-aware zone 
transfers should preserve the distinction even though resolution 
responses won't. There's also the practical matter of zone serial, which 
controls zone transfers but SHOULD NOT be updated by changes in non-zone 
data like ALIAS target answers.


With all that in mind, I think ANAME will need to update the definition 
of AXFR and IXFR, and IXFR in particular is likely to give ANAME a hard 
time:


   @ SOA serial= ; PROBLEM 1!
  ; Use of an already-known serial (since static zone contents
   have not changed).
  ; This may confuse ANAME-ignorant servers into ignoring the
   XFR altogether.
   @     SOA serial= ; PROBLEM 2!
      ; 

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Richard Gibson]

On 12/21/2017 02:17 PM, Niall O'Reilly wrote:

On 21 Dec 2017, at 16:06, Richard Gibson wrote:

first, because it's consistent with the rest of the document in its current form (for 
example, the very next sentence after my quoted text describes how a fully qualified 
domain name "begins at the common root of the graph"),

But, as you pointed out in an earlier message, this depends on which portions 
of the rest
of the document you pick.  Under "Domain name" and "Composition of names" the 
order described
is away from the root, while under "presentation format", "wire format", and 
"display format",
the opposite is the case.
The text is consistent in identifying "domain name" with "a list of 
labels ordered from parent to child", it's just confusing that wire 
format and presentation format are each /also/ "a list of [the same] 
labels" but ordered in reverse.

RFC 1034 seems to contemplate an undirected graph, so can happily use towards-the-root for domain 
names and away-from-the-root for delegations. But I don't think 7719bis has that luxury, because 
"domain name" should remain valid even in a "naming system" without a single 
common root.

I'ld be surprised, because of what I understood of how the development of 7719
was approached, to learn that 7719bis can be permitted to revise a foundational
document such as 1034.  I may be mistaken in this.
RFC 1034 defines domain name as "the list of the labels on the path… to 
the root of the tree" and references a /convention/ that labels "are 
printed or read… from the most specific (lowest, farthest from the root) 
to the least specific". I still think the original text applies to an 
undirected graph, so describing it in terms of a directed graph 
(specifically with edges from parents to children, as it is in the 
protocol) constitutes a clarification rather than a revision. That said, 
though, nailing down the ordering of domain name labels to /oppose/ the 
direction of such edges is most in accord with 1034 and seems like it 
would eliminate the most confusion in 7719bis.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Richard Gibson]

On 12/21/2017 07:31 AM, Niall O'Reilly wrote:


On 19 Dec 2017, at 7:09, Richard Gibson wrote:

1. "Domain name" is defined as «an ordered list of one or more
labels… identifying a portion along one edge of a directed acyclic
graph» (presumably starting at the root).

I'm not sure why one would presume to start there. As I read the 
following fragment
of RFC 1034, the list of labels explicitly starts at the node of 
interest and is read

towards the root.

|The domain name of a node is the list of the labels on the path from 
the node to the root of the tree. By convention, the labels that 
compose a domain name are printed or read left to right, from the most 
specific (lowest, farthest from the root) to the least specific 
(highest, closest to the root). |
Two reasons why I presume edge direction to be away from the root: 
first, because it's consistent with the rest of the document in its 
current form (for example, the very next sentence after my quoted text 
describes how a fully qualified domain name "begins at the common root 
of the graph"), and second, because parent-to-child directionality is 
inherent to the DNS for delegations.


RFC 1034 seems to contemplate an undirected graph, so can happily use 
towards-the-root for domain names and away-from-the-root for 
delegations. But I don't think 7719bis has that luxury, because "domain 
name" should remain valid even in a "naming system" without a single 
common root.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Review of draft-ietf-dnsop-terminology-bis-08

[Richard Gibson]

On 12/18/2017 10:20 PM, Martin Hoffmann wrote:

That said, there seems to be a mistake in the text for the common
display format:

| so, in both English and C the first label in the ordered list is
| right-most

Previously this list was defined as being "ordered ordered by
decreasing distance from the root" which would make the first labal in
this list to be the left-most label in English.

Hmmm.
1. "Domain name" is defined as «an ordered list of one or more labels… 
identifying a portion along one edge of a directed acyclic graph» 
(presumably starting at the root).
2. In "Global DNS", "Composition of names" relies upon that same order: 
«in a fully-qualified domain name, the first label in the ordered list 
is 0 octets long… it is called the "root" or "root label"».
3. But then in "Format of names", the opposite order is specified: «The 
basic wire format for names in the global DNS is a list of labels 
/ordered by //*decreasing*//distance from the root/, with the root label 
last» and «The presentation format for names in the global DNS is a list 
of labels /ordered by *decreasing* distance from the root/» (emphasis 
mine) and «The common display format… is the same as the presentation 
format… in both English and C the first label in the ordered list is 
right-most». It makes sense if that last "ordered list" is the one from 
"Domain name" and "Composition of names", but not if it is the one from 
"presentation format", which I guess is the problem.


The initial graph-theoretic definition is accurate, but suggests 
(although notably does not require) an order backwards with respect to 
all three name formats. Perhaps everything would be more clear if those 
issues were eliminated right up front: «given a directed acyclic graph 
in which no node has in-degree greater than one, a domain name is a list 
of labels identifying a path in reverse (i.e., against the direction of 
the edges)» (the restriction on in-degree precluding child-to-parent 
directionality). For global DNS, the labels would then /always/ be 
ordered by decreasing distance from the root, hopefully eliminating 
confusion about how they appear in text or on the wire.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

[Richard Gibson]

On Wed, Sep 20, 2017 at 3:45 AM, Jiankang Yao <ya...@cnnic.cn> wrote:

> *From:* Richard Gibson <rgib...@dyn.com>
> *Date:* 2017-09-19 10:48
> *To:* dnsop <dnsop@ietf.org>
> *Subject:* Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-
> questions-04.txt
> In a more general sense, how are responders to generate—and how are
> initiators to interpret—responses in which it is not clear which question
> any given response record corresponds to?
>
>
> *[Jiankang Yao]*
>The responders will put the query result of main question first,
> then Accompanying Question 1, Accompanying Question 2 in the answer,
> authority or additional section. It means that the responders will put the
> results for main question first, then Accompanying Question 1, Accompanying
> Question 2, one by one in order.
>
Ah, so the response is expected to include *duplicate* records when they
answer multiple questions (e.g., in the case of NXDOMAIN and NODATA
results)? That's worth making explicit (e.g., rewording "the SOA resource
record will be put in the authority section" in section 4). And I believe
it also calls for guidance instructing responders to reject question sets
that include duplicates or special QTYPES (AXFR/IXFR/ANY), including a
description of *how* to reject (e.g., AQ-RCODE=REFUSED).

> Why require accompanying question names to match or be subdomains of the
> QNAME? It precludes potentially useful queries like QNAME=www.example.com.
> accompanied by prefix=static.example.com., and prohibiting them doesn't
> prevent out-of-bailiwick queries anyway.
> *[Jiankang Yao]*
> currently the use cases for accompanying questions are the same domain
> names with different typs (A and AAA) or different sub domain names (TLSA
> record: _443._tcp.www.example.com  ).
>
> If we can find some strong use cases for  queries like QNAME=
> www.example.com. accompanied by prefix=static.example.com, we may
> consider to adjust the design.
>
 I don't think you need to adjust the design, just strike "The domain name
for accompanying questions MUST be same with the domain name for a main
question or be children name of it" from section 3.

Your response did get me thinking about name compression, though. RFC 3597
section 4 <https://tools.ietf.org/html/rfc3597#section-4> states "Future
specifications for new RR types that contain domain names within their
RDATA MUST NOT allow the use of name compression for those names", and I
don't think that should be tossed aside lightly. If they truly are to be
allowed in EDNS0 options (which may already be a mistake), I think that
they MUST be required to point into the first QNAME of the message.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-yao-dnsop-accompanying-questions-04.txt

[Richard Gibson]

I have some questions about this draft.

How should responders populate the COUNT fields when one record answers
multiple accompanying questions? For example, assume example.com has an MX
record but no A or  (the latter two thus being covered by an authority
section SOA):

QUESTION example.com. IN MX

AQ example.com. IN A

AQ example.com. IN 

ANSWER example.com. 3600 IN MX 10 mail.example.net.

AUTHORITY example.com. 3600 IN SOA …

ADDITIONAL . 0 CLASS4096 OPT ???


In a more general sense, how are responders to generate—and how are
initiators to interpret—responses in which it is not clear which question
any given response record corresponds to?

Section 3 defines the prefix field of an accompanying question as "a domain
name with the form of a dot or a sequence of labels ending with a
pointer"... could you clarify that "the form of a dot" refers to the root
domain name (i.e., a single null label with wire format 0x00)?

In section 4, what is meant by "the responder assembles the prefix with the
main domain name"? Wire-format domain names are necessarily
fully-qualified, whether or not they end with compression pointers. Is the
operation to be interpreted as something like "if the prefix is the DNS
root domain, treat it as the QNAME"? If so, I think such special processing
is unnecessary, because it's already possible to reference the QNAME
directly with a compression pointer.

Why require accompanying question names to match or be subdomains of the
QNAME? It precludes potentially useful queries like QNAME=www.example.com.
accompanied by prefix=static.example.com., and prohibiting them doesn't
prevent out-of-bailiwick queries anyway.

Section 5 references a "not been implemented, too many
accompanying-questions." response... what would that response look like?


On Sun, Sep 17, 2017 at 11:19 PM,  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   : A DNS Query including A Main Question with
> Accompanying Questions
> Authors : Jiankang Yao
>   Paul Vixie
>   Ning Kong
>   Xiaodong Li
> Filename: draft-yao-dnsop-accompanying-questions-04.txt
> Pages   : 11
> Date: 2017-09-17
>
> Abstract:
>This document enables DNS initiators to send a main question
>accompanying with several related questions in a single DNS query,
>and enables DNS responders to put the answers into a single DNS
>response.  This extension enables a range of initiators to look up
>"X, or failing that, Y" in a better way than both current
>alternatives.  This mechanism can reduce the number of DNS round-
>trips per application work-unit.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-yao-dnsop-accompanying-questions/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-yao-dnsop-accompanying-questions-04
> https://datatracker.ietf.org/doc/html/draft-yao-dnsop-
> accompanying-questions-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-yao-dnsop-
> accompanying-questions-04
>
>
> 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] Fwd: New Version Notification for draft-pan-dnsop-swild-rr-type-00.txt

[Richard Gibson]

I'm assuming there's a very obvious answer to this question, but what would
break if unsigned wildcard caching were covered by allowing
DNSSEC-independent NSEC (and therefore
https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse )?

$ cat zones/github.io
; apex records
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
github.io. 900 IN NS ns-1339.awsdns-39.org.
github.io. 900 IN NS ns-1622.awsdns-10.co.uk.
github.io. 900 IN NS ns-393.awsdns-49.com.
github.io. 900 IN NS ns-692.awsdns-22.net.
github.io. 900 IN NS ns1.p16.dynect.net.
github.io. 900 IN NS ns2.p16.dynect.net.
github.io. 900 IN NS ns3.p16.dynect.net.
github.io. 900 IN NS ns4.p16.dynect.net.
github.io. 30 IN A 151.101.193.147
github.io. 30 IN A 151.101.129.147
github.io. 30 IN A 151.101.1.147
github.io. 30 IN A 151.101.65.147
github.io. 300 IN TXT "v=spf1 a -all"
; wildcard answer records
*.github.io. 3600 IN CNAME sni.github.map.fastly.net.
; aggressive-use signal covering LDH wildcard-synthesized names
*.github.io. 3600 IN NSEC github.io. CNAME NSEC
; aggressive-use signal covering pre-* wildcard synthesized names (omitted
to demonstrate selective application)
; github.io. 3600 IN NSEC *.github.io. A NS SOA TXT NSEC

$ dig @$resolver +noall +answer example.github.io. A; positive answer
with covering NSEC for aggressive use
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
example.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer foo.github.io. A; positive answer from
cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
foo.github.io. 3590 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 20 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3590 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer bar.github.io. ; negative answer
from cache plus fresh SOA
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 900 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3579 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer baz.github.io. ; negative answer
from cache
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 0
;; AUTHORITY SECTION:
github.io. 890 IN SOA ns-1622.awsdns-10.co.uk. awsdns-hostmaster.amazon.com.
1 7200 900 1209600 86400
*.github.io. 3569 IN NSEC github.io. CNAME NSEC

$ dig @$resolver +noall +answer '\032.github.io.' A; positive answer
with non-covering NSEC (due to partial application; could be remedied by
adding another NSEC to the zone)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; ANSWER SECTION:
\032.github.io. 3600 IN CNAME sni.github.map.fastly.net.
sni.github.map.fastly.net. 30 IN A 151.101.117.147
;; AUTHORITY SECTION:
*.github.io. 3600 IN NSEC github.io. CNAME NSEC

On Thu, Aug 10, 2017 at 7:04 AM, Petr Špaček  wrote:

> Hello,
>
> On 4.7.2017 05:54, Lanlan Pan wrote:
> > Hi Tony,
> >
> > We try to solve similar wildcard problem.
> >
> > NSEC/NSEC3 aggressiveuse (Section 5.3 Wildcards
> >  aggressiveuse-10#page-6>)
> > :
> > - NSEC/NSEC3 RR: give "NOT EXIST SUBDOMAIN" information.
> > - cached deduced wildcard: give the default wildcard RR.
> >
> > SWILD:
> > - Directly give "ALL SUBDOMAIN" information, and the default wildcard RR.
> >
> > SWILD is applicable even when Authoritative Nameservers don't give
> > NSEC/NSEC3 RR.
> > SWILD is applicable on non-validating Forwarding Resolvers.
>
> If I understand it correctly:
> - the only information added by SWILD RR is an explicit information
> about the original (unexpanded) name of wildcard owner
> - the very same information can be obtained from RRSIG RR in a
> synthtetised answer (RRSIG labels < owner name labels)
> - SWILD will work only if there are no nodes below the wildcard
>
> Assuming this analysis is right, I'm against this proposal.
>
> We can get even better behavior from aggressive NSEC use. Here are
> advantages of aggressive NSEC use:
> - does not require changes to existing authoritatives or signed zones
> - less fragile (if we consider manual SWILD specification as an option)
> - supports wildcards with nodes below it
>
> Yes, the aggressive NSEC is limited to DNSSEC-signed zones. I think that
> is okay: New features are provided only by the latest version of
> the protocol.
>
> Petr Špaček  @  CZ.NIC
>
>
> >
> > Regards,
> >
> > Tony Finch 

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Wed, Jul 26, 2017 at 2:24 PM, Joe Abley <jab...@hopcount.ca> wrote:

>
> On 26 Jul 2017, at 13:28, Richard Gibson <rgib...@dyn.com> wrote:
>
> > The need for such a signal also came up recently in
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-
> responses-05#section-10 . But in this case particularly, middleboxes
> should be a complete non-issue... anyone expecting QTYPE=ANY passthrough is
> already asking for trouble.
>
> We may be imagining different things by "middlebox" -- I think you're
> thinking of a resolver, whereas I'm thinking more broadly about stateful
> inspection, firewalls, ALGs, proxies, forwarders, etc. I think there's an
> entirely reasonable and observable expectation that QTYPE=ANY passthrough
> works in that broader sense. Mark's <https://www.ietf.org/
> proceedings/92/slides/slides-92-dnsop-7.pdf> was an easy-to-find example
> of trouble in the real world.
>

Yes, color me corrected on vocabulary but unconvinced on interference...
those slides seem to mostly demonstrate noncompliance by name servers
theirselves with respect to EDNS data in queries, whereas the data I'm
suggesting would only appear in responses.

I will plan to add text to acknowledge the lack of signalling but not to
> change the mechanism to introduce any. People should throw rocks if that
> seems bad.


That works. And I'm all out, so you're safe from me.

> 2. Section 4.1 appears to have some errors in grammar and use RFC 2119
> terms, and should be reworded (removals in strikethrough, additions in
> bold):
>
> Strikethrough and bold, eh? OK. :-) Suggestions are good, many thanks!
>

Ha! I'll use Markdown conventions in the future.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-ietf-dnsop-refuse-any: points from Richard Gibson

[Richard Gibson]

On Tue, Jul 25, 2017 at 4:52 PM, Joe Abley  wrote:

> >- There is no mechanism for signaling section 4.1/ section 4.3
> "partial
> >response" behavior to clients (e.g., a new OPT record EDNS header flag
> >bit
> > dns-parameters.xhtml#dns-parameters-13>
> >).
>
> Correct. I presume you are suggesting that there should be one. I have not
> heard anybody else require such a thing, and new EDNS code points are
> thought by at least some to be thorny things to pass undigested through
> middleboxes so I think it's a non-trivial suggestion that would require a
> proposal that itself would need thorough review. That feels out of scope
> for this document, but perhaps something analogous to extended RCODEs in
> the sense that it's channel metadata.
>

The need for such a signal also came up recently in
https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05#section-10
. But in this case particularly, middleboxes should be a complete
non-issue... anyone expecting QTYPE=ANY passthrough is already asking for
trouble.

I think it would be uncontroversial to note explicitly that the mechanism
> described in this document contains no such signalling, however. Let me
> know if that seems like a pragmatic solution.
>

I remain concerned about issuing incomplete responses to ANY queries
without indication of such, and predict that it will hinder operational
problem investigation and remediation (especially pertaining to IPv4/IPv6
issues). My preference has not changed, but an explicit acknowledgment of
the gap at least provides a reference for future improvement.

>- "Conventional [ANY] response" is used but not defined.
>
> I am not sure why it's ambiguous without a definition. To me that phrase
> seems pretty straightforward; if your core objection is that the DNS
> standards are not written down with great accuracy, yeah. The only
> definition I can think of really is something like "A response to a query
> that had QTYPE=ANY which follows convention" which just seems longer, not
> more clear. What did you have in mind?
>

How about updating document text to replace "conventional ANY queries"
(section 3) and "conventional response" (section 4.1) with "conventional
ANY response" and defining it in the Terminology section:

In this document, "conventional ANY response" refers to an ANY Response
that would be produced by the algorithm in section 4.3.2 of RFC 1034.
Conventional ANY responses can include include records from an arbitrarily
high number of RRSets, up to message truncation.

Also, it therefore appears that this draft needs to be noted as updating
RFC 1034.

>- "ANY does not mean ALL" is misleading—RFC 1035
> ><
> > https://tools.ietf.org/html/rfc1035#section-3.2.3>
> >  is clear about
> >QTYPE=255 being "a request for *all* records" (emphasis mine). That
> >said, the proposed *response* behavior is consistent with that RFC.
>
> All records that the server constructing the response knows about?
>
> All records that the server can fit into the response given the
> constraints of the available transport?
>
> ALL THE RECORDS IN THE WHOLE WORLD! That was an obscure reference to
> Blackadder the Second that probably pleases nobody but me. ("Kill Bob!"
> "Never!")
>
> I think to that point we can implicitly acknowledge between ourselves that
> less ambiguity would be nice, but that on the whole this text as-is at
> worst does no harm, and at best helps illustrate the philosophy of the
> approach being described.
>
> Let me know how much of that you can live with :-)
>

In light of the above, referencing RFC 1035 actually seems misleading...
the relevant definitions come from RFC 1034, and this draft is consistent
with it in acknowledging use of QTYPE=255 for *requesting* records of all
types, but inconsistent with it in specifying *responses* that
intentionally omit matching records.

On Tue, Jul 25, 2017 at 4:53 PM, Joe Abley  wrote:

> >1.  A DNS responder can choose to select one or subset of RRSets at
> >the QNAME.
> >
> >   'one or subset of RRSets' sounds a bit awkward to me
>
> I agree. Perhaps "One or more of the RRSets at a QNAME". "... or a subset"
> seems wrong, actually; since some vestigial fragment of a set theory
> lecture in the depths of my pre-history is telling me that the empty set is
> always a valid subset.


Suggestion: "A DNS responder can choose to select one or more
nonempty matching RRSets". This works because existence is guaranteed by
the preceding text ("for names that exists that are used", probably better
phrased as "for QNAMEs with at least one nonempty RRSet"). And it has the
added benefit of correctly covering wildcard behavior.

I also discovered some incidental issues while confirming the above:
1. The draft should standardize on one of "RRSet" (capital S, 17 current
instances) or "RRset" (minuscule S, 7 current instances).
2. 

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Richard Gibson]

On Thu, Jul 6, 2017 at 5:17 AM, Jim Hague  wrote:

> > All the keys in those maps (and in every map, as far as I can tell) are
> > strings, for which "unsigned" is a meaningless concept.
>
> No. All keys are unsigned ints, with values specified in the CDDL. We
> should
> make this more explicit in the text.
>
> String keys would bloat the output file size enormously.
>

Oh, wow. Yes, more explicit documentation in the text would be
appreciated. I completely missed that, even in the CDDL where the key
definitions follow maps referencing them. It seemed like you were using
string keys and relying on general compression to eliminate the bloat, but
this greatly clarifies your "designate as implementation-specific all key
values above a threshold" statement regarding extension fields (and in that
case, might I recommend reserving all nonnegative integers and perhaps also
all strings lacking an implementation-extension prefix for standard key
values? That would suggest negative numbers and prefixed strings for
extension keys, a set encompassing one full major type and then some).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Richard Gibson]

On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague  wrote:

> Timestamps, on the other hand, I always regarded as a basic data type,
> so naturally a structure. Plus, of course, there's one per
> query/response item, so in a block the size savings are in the 10-15k
> bytes region, which is rather more significant.
>

In that case, I'm even more convinced that all of them (block preamble
"earliest-time", Q/R data item "time" and "delay", malformed packet item
"time") should have the same structure—either variable-precision arrays or
{"seconds", "useconds", "pseconds"} maps.

> * In section 7.18, "and an unsigned key" appears to be meaningless and
> > should probably be removed.
>
> In most places where we are discussing a map, we've specified the type
> of the map key in the text, though I notice we're not 100% consistent
> with that.
>

All the keys in those maps (and in every map, as far as I can tell) are
strings, for which "unsigned" is a meaningless concept.


> Example use
> > cases:
> [...]
> > * Extend the block preamble (section 7.7) to override file preamble
> > fields like "host-id" and "server-addresses", enabling fleet-wide file
> > merges.
>
> I don't quite follow why you'd need to put this informational-only stuff
> into the block preamble rather than the file preamble/configuration. Can
> you expand on that a bit?
>

Some of our processing can benefit from merging telemetry (e.g., all hosts
at a site), which would produce files containing blocks that don't share
values for fields currently in the file preamble. In fact, we might even
decide to treat "block" as the only relevant unit, using block preamble
extension fields for *everything* in the standard file preamble except
version information.

> *Opt-in Lossyness*
> This raises a question about a tension between the background of C-DNS
> to date and the slightly different angle you are coming from. We've been
> very much focused on using C-DNS to record traffic in a form where the
> packets can be recreated in wire format (i.e. as PCAP). The optional
> data items mean that data may be missing from those packets, but the
> core query and response will still be present.
>

Agreed. But it's _so close_ that I felt these suggestions were worth
raising—not to water down the primary use case, but to cover a few more
with some tradeoffs.

moves the recording to a point where reconstructing wire format means
> that the application doing the reconstruction has to not just omit
> information not present in C-DNS, but must start generating values to
> fill in for the missing items. This feels a bit like a step that needs
> discussion; we need to think over the design from your point of view.
> Possibly those fields should be optional, but with recommendations for
> how to populate them when/if generating PCAP.
>

That sounds great.

We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome
> discussion there.


I don't expect to be there personally, but we'll have a well-informed
representative.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-wkumari-dnsop-multiple-responses-05.txt

[Richard Gibson]

Comments:
1. There's a "www.exmaple.com" typo in the introduction.
2. It is very limiting for this functionality to rely upon DNSSEC, given
that many practical cases still preclude its use.
3. Why have a composite value for EXTRA instead of just using one EXTRA
record per domain (with a Priority field for proper ordering)?
4. Why limit EXTRA domain names to single labels, instead of allowing
answers for e.g. en.m.example.org from m.example.org queries?
5. The missing signal about records that *could* have been included via TCP
or secured by DNS cookies (the TC bit being too strong) seems to be another
case for a "partial response" EDNS header flag (which I raised for
refuse-any in
https://www.ietf.org/mail-archive/web/dnsop/current/msg19322.html ).

On Mon, Jul 3, 2017 at 2:16 PM,  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 of the IETF.
>
> Title   : Returning extra answers in DNS responses.
> Authors : Warren Kumari
>   Zhiwei Yan
>   Wes Hardaker
>   David C Lawrence
> Filename: draft-wkumari-dnsop-multiple-responses-05.txt
> Pages   : 9
> Date: 2017-07-03
>
> Abstract:
>This document (re)introduces the ability to provide multiple answers
>in a DNS response.  This is especially useful as, in many cases, the
>entity making the request has no a prori knowledge of what other
>questions it will need to ask.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-multiple-responses/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05
> https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-
> multiple-responses-05
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-wkumari-dnsop-
> multiple-responses-05
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-03.txt

[Richard Gibson]

I looked over this draft in detail, and found a handful of ambiguous points
("Clarifications" and "Potentially Missing Data" below). But more
importantly, it is very close to defining a format that could replace much
of my organization's in-house technology. Would you consider some
generalizations to take it over the finish line ("Extension Fields" and
"Opt-in Lossyness")? Only the suggestions related to representing time and
"classtype" items would change the representation of existing data in such
a way that implementations already supporting the draft specification would
require changes.

*Clarifications*
* Items in the "classtype" table (section 7.11) are missing data type
documentation. Both "type" and "class" should be unsigned numbers.
  * And speaking of 7.11, why are CLASS/TYPE pairs represented as CBOR maps
instead of more efficient two-item arrays? If it was an intentional
decision for clarity, then maybe the section 7.7 block preamble
"earliest-time" field should also be promoted to a map ("time-seconds",
"time-useconds", "time-pseconds", mirroring Q/R items) for the same reason.
* In "query-sig" table items (section 7.13) "transport-flags" field, the
bit corresponding to "trailing bytes" shouldn't be limited to UDP.
* In section 7.18, "and an unsigned key" appears to be meaningless and
should probably be removed.

*Potentially Missing Data*
* In "query-sig" table items (section 7.13), "transport-flags" should
probably be extended to include a TLS bit (cf. RFC 7858).

*Extension Fields*
Of the many potentially open-ended key-value maps (file preamble, file
preamble configuration, block preamble, block statistics, query signatures,
Q/R data), only block statistics allows for "implementation-specific
fields", and no further guidance is provided. I think all maps should allow
such fields, with a recommendation that they use an implementation-specific
prefix to avoid collisions with fields added by other implementations or
later versions of C-DNS. Example use cases:
* Extend file preamble configuration (section 7.5) to document aggregation
of queries answered by wildcard names.
* Extend the block preamble (section 7.7) to override file preamble fields
like "host-id" and "server-addresses", enabling fleet-wide file merges.
* Extend query signatures (section 7.13) to indicate EDNS Client Subnet use
(cf. RFC 7871) or selection of context-dependent handling like views.
* Extend Q/R data (section 7.18) to include actual EDNS Client Subnet
values or even a "count" field (which would come with *tremendous* space
savings, sufficient for my organization to abandon its internal
summarization format in favor of C-DNS).

*Opt-in Lossyness*
The format is generally quite good about allowing for detail without
requiring it. However, there are some areas where more space savings could
be had:
* Communicate aggregation of IP addresses into prefixes (i.e., the
irrelevance of least-significant bits in ip-address values) with new
"client-prefix-length-ipv4" and "client-prefix-length-ipv6" and
"server-prefix-length-ipv4" and "server-prefix-length-ipv6" file preamble
configuration options.
* Communicate case-normalizing aggregation of names (e.g., transforming
"eXaMpLe.com" into "example.com") with a new boolean-valued
"name-normalization" file preamble configuration option.
* In "rr" table items (section 7.15), "ttl" should be optional to
accommodate decrementing in recursive resolver responses.
* In Q/R data items (section 7.18) and malformed packet records (section
7.20), I'd like "time-useconds" broken out into "time-seconds" and optional
"time-useconds", both for parity with block-preamble "earliest-time" and
for space savings in applications that are content with second-level
resolution.
* For truly customizable aggregation, I think all query signature (section
7.13) and Q/R (section 7.18) data item fields should be optional... but
especially Q/R data "client-port" and "transaction-id".

On Mon, Jul 3, 2017 at 5:08 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 of the IETF.
>
> Title   : C-DNS: A DNS Packet Capture Format
> Authors : John Dickinson
>   Jim Hague
>   Sara Dickinson
>   Terry Manderson
>   John Bond
> Filename: draft-ietf-dnsop-dns-capture-format-03.txt
> Pages   : 49
> Date: 2017-07-03
>
> Abstract:
>This document describes a data representation for collections of DNS
>messages.  The format is designed for efficient storage and
>transmission of large packet captures of DNS traffic; it attempts to
>minimize the size of such packet capture files but retain the full
>DNS message contents along with the most useful transport metadata.
>It is intended to assist 

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Richard Gibson]

On Sun, Apr 9, 2017 at 3:56 PM, Peter van Dijk 
wrote:

> Thank you for taking the time for this.


My pleasure; this topic has frequently been on my mind over the past
several years. Thank you for drafting it.

*Section 3.1*
>>
>
>> This section calls for limiting the TTL of cached address records to the
>> lesser of the ANAME TTL and the TTL of the retrieved address records, but
>> section 3 requires servers to follow chained responses. Are the TTLs of
>> intermediate records in a chain supposed to be ignored?
>>
>
What was the response on this point?

What is the expected behavior when the target record set is empty, or
>> bogus, or when resolution fails?
>>
>
> Empty becomes empty. The common case will be ‘the ANAME target only has A,
> no ’ which means the  lookup encounters a valid ‘no data’.


> If resolution fails (i.e. runs into an actual SERVFAIL-like error
> condition, including ‘bogus’), we should also SERVFAIL. If the draft is
> unclear on this we should definitely fix that.
>

Right; I definitely think there should be text explicitly defining behavior
for timeouts, nonzero RCODEs, and bogus responses received when looking up
ANAME targets. Section 4 covers part of it (for recursive servers only),
but doesn't define how to determine when "resolution fails" or what to do
when not opting to use the accompanying records as a fallback, and there is
no guidance at all for authoritative servers.

*Section 3.2*
>>
>> The wording of this section could use some improvement. It seems to
>> prohibit secondary servers from resolving ANAME targets when they are
>> present at the same domain as address types... do I understand correctly?
>>
>
> Yes, that is correct. We went through a few iterations and thought
> exercises and this seemed like the optimal behaviour.


Dyn went another way with our ALIAS functionality, reserving same-domain
address record sets for fallback data to be used whenever target resolution
doesn't yield records of the appropriate type (including, perhaps
controversially, NXDOMAIN and NODATA empty responses). Assuming a secondary
server predating ANAME, the Dyn behavior would be slightly better when the
primary server is ignorant of that gap (i.e., the secondary would always
serve fallback data) and identical behavior when it is not (i.e., the
authoritative would pre-expand as the draft specifies in Section 5). It
also provides support for multi-type host names with single-type targets,
e.g. static  records sharing a domain with an ALIAS targeting a name
providing only A records. Where it really shines, though, is in handling
error cases like those discussed above—it was very important to our
customers that they could prevent us from ever issuing cacheable negative
responses. What thought exercises took you in this direction?

Are such address records still subject to TTL decrementing (presumably
>> starting at the time of zone transfer)? And when only a single address
>> type
>> is present (e.g., just ANAME and A), does that still prevent resolution of
>> the ANAME target for the other type?
>>
>
> (1) Yes, they are still subject to TTL decrementing, but if the slave is
> not ANAME-aware, no decrementing will happen and the draft allows this, if
> we wrote it all down correctly.
> (2) Yes, when any address records are present, the ANAME is deemed to have
> already been expanded. If A is there and no , then this means that
> there is in fact no  to be had.
>

I understand the motivation, but there's an interesting wrinkle with
respect to forward compatibility... what happens when a new address type is
added to the DNS? The assumption that pre-expansion of any address type
implies pre-expansion of all address types seems like it could lead to some
dramatic changes in behavior as primary servers, secondary servers,
resolvers, and targeted zones become aware of the new type in a nonuniform
fashion. Has any consideration been given to that concern?

On a related note, should recursive resolvers query for ANAME targets even
when they *don't* correspond to A or  QTYPEs?

It is also mute on the use of DNSSEC for resolving ANAME target records,
>> but that should probably be covered somewhere.
>>
>
> This is an interesting topic actually. There are existing deployments of
> PowerDNS ALIAS (which of course is quite similar to ANAME) that use it
> instead of ‘CNAME to unsigned’ so they can sign the target addresses (that
> they get via a non-DNSSEC but still secure path). This draft should also
> allow that. If you have suggestions for a section on ANAME target resolving
> and DNSSEC, please let us know.


Addressing the above points to explicitly define behavior for bogus
responses will cover the functional requirements, so this will likely take
the form of MAY or SHOULD guidance for using DNSSEC when resolving ANAME
targets.
___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] new ANAME draft: draft-hunt-dnsop-aname-00.txt

[Richard Gibson]

I'm happy to see progress being made on this front. Some comments:

*Section 3.1*

This section calls for limiting the TTL of cached address records to the
lesser of the ANAME TTL and the TTL of the retrieved address records, but
section 3 requires servers to follow chained responses. Are the TTLs of
intermediate records in a chain supposed to be ignored?

What is the expected behavior when the target record set is empty, or
bogus, or when resolution fails?

*Section 3.2*

The wording of this section could use some improvement. It seems to
prohibit secondary servers from resolving ANAME targets when they are
present at the same domain as address types... do I understand correctly?
Are such address records still subject to TTL decrementing (presumably
starting at the time of zone transfer)? And when only a single address type
is present (e.g., just ANAME and A), does that still prevent resolution of
the ANAME target for the other type?

*Section 3.3*

Although labeled "DNSSEC signing", this section also contains more general
specification (e.g., "the master server MUST respect the TTLs of the
address records" and "TTLs [of address records in a secondary server] will
count down").

It is also mute on the use of DNSSEC for resolving ANAME target records,
but that should probably be covered somewhere.

On Fri, Apr 7, 2017 at 2:11 PM, Evan Hunt  wrote:

> Greetings,
>
> Here's the new ANAME draft I mentioned last week.
>
> This is similar to existing non-standard approaches (ALIAS records,
> CNAME-flattening, etc) but also sends the ANAME record to the resolver so
> that, if the resolver understands the ANAME type, it can re-query for the
> answer just as it would with a CNAME.
>
> Please have at it.
>
> - Forwarded message from internet-dra...@ietf.org -
>
> From: internet-dra...@ietf.org
> To: Evan Hunt , Peter van Dijk  >,
> Anthony Eden 
> Subject: New Version Notification for draft-hunt-dnsop-aname-00.txt
> Date: Fri, 07 Apr 2017 11:04:39 -0700
>
> A new version of I-D, draft-hunt-dnsop-aname-00.txt
> has been successfully submitted by Evan Hunt and posted to the
> IETF repository.
>
> Name:   draft-hunt-dnsop-aname
> Revision:   00
> Title:  Address-specific DNS Name Redirection (ANAME)
> Document date:  2017-04-07
> Group:  Individual Submission
> Pages:  10
> URL:https://www.ietf.org/internet-
> drafts/draft-hunt-dnsop-aname-00.txt
> Status: https://datatracker.ietf.org/doc/draft-hunt-dnsop-aname/
> Htmlized:   https://tools.ietf.org/html/draft-hunt-dnsop-aname-00
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-hunt-dnsop-
> aname-00
>
>
> Abstract:
>This document defines the "ANAME" DNS RR type, to provide similar
>functionality to CNAME, but only redirects type A and  queries.
>Unlike CNAME, an ANAME can coexist with other record types.  The
>ANAME RR allows zone owners to redirect queries for apex domain names
>in a standards compliant manner.
>
> 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.
>
> The IETF Secretariat
>
> - End forwarded message -
>
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
>
> ___
> 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 draft for ALIAS/ANAME type

[Richard Gibson]

I don't think you can drop section 3.4 completely, but it should be updated
to acknowledge Refuse-Any
.
Only behavior 2 (HINFO synthesization) allows total ignorance of special
ALIAS behavior; every other (including conventional) needs modification to
deal with ANY queries against names at which ALIAS is the only RRSet.

On Thu, Mar 30, 2017 at 10:34 AM, Ólafur Guðmundsson 
wrote:

> Anthony,
>
> Good writeup
>
> Section 3.4 is in conflict with Refuse-Any draft (in WGLC)
> IMHO there is no need to say that there is special processing for ANY
> query;  so drop section 3.4
>
> Olafur
>
>
> On Wed, Mar 29, 2017 at 9:51 AM, Anthony Eden 
> wrote:
>
>> After attending the dnsop meeting on Monday I decided it was time I
>> submitted my first ID for review:
>>
>> https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/
>>
>> This draft describes the ALIAS/ANAME record (aka CNAME-flattening)
>> that numerous vendors and DNS providers are now supporting in
>> proprietary fashions. I hope that this draft will eventually lead to a
>> good mechanism for interop of ALIAS/ANAME records.
>>
>> Sincerely,
>> Anthony Eden
>>
>> --
>> DNSimple.com
>> http://dnsimple.com/
>> Twitter: @dnsimple
>>
>> ___
>> 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] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[Richard Gibson]

To re-raise my unaddressed points from the first Working Group Last Call:

   - There is no mechanism for signaling section 4.1/ section 4.3 "partial
   response" behavior to clients (e.g., a new OPT record EDNS header flag
   bit
   

   ).
   - Insisting that the HINFO OS field SHOULD be empty ("set to the null
   string") seems a little too strong; there's room in it for—and value
   from—a short explanation (e.g., as can be observed today:
   dns.cloudflare.com. 3789 IN HINFO "Please stop asking for ANY" "See
   draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS field
of the HINFO
   RDATA SHOULD be short to minimize the size of the response, and MAY be
   empty or MAY include a summarized description of local policy."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
    is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.


On Thu, Mar 16, 2017 at 3:11 AM, tjw ietf  wrote:

>
> All
>
> During the first WGLC of draft-ietf-dnsop-refuse-any, several issues were
> raised by the working group that needed to be addressed. The Authors
> addressed the issues, but the changes are enough that there should be a
> second Working Group Last Call on the changes.
>
> This begins a Second WGLC for draft-ietf-dnsop-refuse-any.  The Document
> is located here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-
> refuse-any/
>
> However, the changes that were made since the last WGLC can be found here:
>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-dnsop-refuse-
> any-03=draft-ietf-dnsop-refuse-any-04
>
> Please take a few moments to refer the changes and let the working group
> know if the document is ready to move forward.   We're mostly looking for
> remaining issues that have not been addressed.
>
> This WGLC ends on Thursday 30 March 2017.
>
> Thanks
>
> tim/suzanne
>
>
> ___
> 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] [Ext] A nudge on the new terms in draft-ietf-dnsop-terminology-bis

[Richard Gibson]

On Mon, Feb 13, 2017 at 6:34 PM, Viktor Dukhovni 
wrote:

> My beef
> would be with the "zero or more" part, as applied to labels, since
> zero length labels (if construed as actual labels rather than just
> termination sentinels) do not occur except to terminate a domain
> name.  Otherwise, if the zero length terminator is a label, then
> domains have at least one (terminal zero-length) label.
>

https://github.com/DNSOP/draft-ietf-dnsop-terminology-bis/issues/6
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 1:02 PM, Wessels, Duane 
wrote:

> Tools like dig, when asked to issue an ANY query over UDP can:
>
> 1) fail with "ANY over UDP is deprecated", or
>

That's not true, though, and tools have no way of knowing whether or not
such a failure is appropriate without the very signal I'm requesting.

2) warn with "ANY over UDP might give partial results", or
> 3) automatically use TCP


Regardless of anything else, those are both reasonable.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 12:38 PM, Robert Edmonds  wrote:

> You think this would actually provide any sort of useful information? No
> operator would understand what "MBZ: 0x" means without re-training,
> and if you're re-training operators you may as well point them to this
> document.


I think it would be _very_ useful. People easily forget new information,
but seeing unexpected data like that would provide the necessary trigger
for remembering this document and e.g. retrying with +tcp.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 11:46 AM, Tony Finch  wrote:

> OK. But does an EDNS flag help? What if you are using old tools?


If you are using old tools, then you don't get new conveniences (the same
is true of using OPT class to specify a maximum payload size exceeding 512
bytes, using the DO bit to request DNSSEC records, and using the COOKIE
option for authentication). But a flag would still be there, conveying
information even if any given client or tool isn't looking for it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

On Mon, Feb 13, 2017 at 8:03 AM, Tony Finch  wrote:

> There are several ways to avoid this pitfall:
>
> Use TCP
>
> Look for an NSEC(3) record
>
> Query for the specific types you want to know about


The pitfall comes from unexamined muscle-memory assumptions when inspecting
a DNS response, so none of those methods avoid it. They're expecting people
to remember that longstanding behavior has changed without providing any
clue about it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

Because without such a signal, humans using ANY for legitimate diagnostic
purposes have no means of differentiating section 4.1/4.3 "subset"
responses from conventional responses where there just happen to be only a
small number of RRSets at the queried name, encouraging (or at least doing
nothing to dissuade) a conclusion that the response is in fact conventional
and complete.

On Fri, Feb 10, 2017 at 1:44 PM, Ólafur Guðmundsson <ola...@cloudflare.com>
wrote:

> Thank you for your comments
>
> Q: why do you think it is useful to complicate things with a EDNS0 flag ?
>
> Olafur
>
>
>
> On Thu, Feb 9, 2017 at 8:47 PM, Richard Gibson <rgib...@dyn.com> wrote:
>
>> With full realization that this is coming very late in the game, we had a
>> great deal of internal conversation within Dyn about implementing
>> refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
>> approaches—the latter because of reasons that have already been covered,
>> and the former for lacking in-band signaling of non-"conventional"
>> incompleteness to aid legitimate use.
>>
>> I believe there is sufficient cause to reserve a new OPT record EDNS
>> header flag bit
>> <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-13>
>> for indicating "partial response" (as distinct from "truncation"). It will
>> be safely ignored by current clients, but convey the desired information to
>> those in the know.
>>
>> P.S. Our discussion also raised some more minor points:
>>
>>- Insisting that the HINFO OS field SHOULD be empty ("set to the null
>>string") seems a little too strong; there's room in it for (and value
>>from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
>>stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer
>>text like "The OS field of the HINFO RDATA SHOULD be short to
>>minimize the size of the response, and MAY be empty or MAY include a
>>summarized description of local policy."
>>- "Conventional [ANY] response" is used but not defined.
>>- "ANY does not mean ALL" is misleading—RFC 1035
>><https://tools.ietf.org/html/rfc1035#section-3.2.3> is clear about
>>QTYPE=255 being "a request for *all* records" (emphasis mine). That
>>said, the proposed *response* behavior is consistent with that RFC.
>>
>>
>> On Thu, Feb 9, 2017 at 12:56 AM, <internet-dra...@ietf.org> 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 of the
>>> IETF.
>>>
>>> Title   : Providing Minimal-Sized Responses to DNS
>>> Queries that have QTYPE=ANY
>>> Authors : Joe Abley
>>>   Olafur Gudmundsson
>>>   Marek Majkowski
>>> Filename: draft-ietf-dnsop-refuse-any-04.txt
>>> Pages   : 10
>>> Date: 2017-02-08
>>>
>>> Abstract:
>>>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>>>The operator of an authoritative DNS server might choose not to
>>>respond to such queries for reasons of local policy, motivated by
>>>security, performance or other reasons.
>>>
>>>The DNS specification does not include specific guidance for the
>>>behaviour of DNS servers or clients in this situation.  This document
>>>aims to provide such guidance.
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>>>
>>>
>>> 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
>>
>>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] I-D Action: draft-ietf-dnsop-refuse-any-04.txt

[Richard Gibson]

With full realization that this is coming very late in the game, we had a
great deal of internal conversation within Dyn about implementing
refuse-any, and came away unsatisfied with both the "subset" and "HINFO"
approaches—the latter because of reasons that have already been covered,
and the former for lacking in-band signaling of non-"conventional"
incompleteness to aid legitimate use.

I believe there is sufficient cause to reserve a new OPT record EDNS header
flag bit

for indicating "partial response" (as distinct from "truncation"). It will
be safely ignored by current clients, but convey the desired information to
those in the know.

P.S. Our discussion also raised some more minor points:

   - Insisting that the HINFO OS field SHOULD be empty ("set to the null
   string") seems a little too strong; there's room in it for (and value
   from) a short explanation (e.g., cloudflare.com. 3789 IN HINFO "Please
   stop asking for ANY" "See draft-ietf-dnsop-refuse-any"). I'd prefer text
   like "The OS field of the HINFO RDATA SHOULD be short to minimize the size
   of the response, and MAY be empty or MAY include a summarized
   description of local policy."
   - "Conventional [ANY] response" is used but not defined.
   - "ANY does not mean ALL" is misleading—RFC 1035
    is clear about
   QTYPE=255 being "a request for *all* records" (emphasis mine). That
   said, the proposed *response* behavior is consistent with that RFC.


On Thu, Feb 9, 2017 at 12:56 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 of the IETF.
>
> Title   : Providing Minimal-Sized Responses to DNS Queries
> that have QTYPE=ANY
> Authors : Joe Abley
>   Olafur Gudmundsson
>   Marek Majkowski
> Filename: draft-ietf-dnsop-refuse-any-04.txt
> Pages   : 10
> Date: 2017-02-08
>
> Abstract:
>The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
>The operator of an authoritative DNS server might choose not to
>respond to such queries for reasons of local policy, motivated by
>security, performance or other reasons.
>
>The DNS specification does not include specific guidance for the
>behaviour of DNS servers or clients in this situation.  This document
>aims to provide such guidance.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-refuse-any/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-refuse-any-04
>
>
> 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] DNSOP Digest, Vol 122, Issue 9

[Richard Gibson]

On Fri, 6 Jan 2017 13:01:10 -0500, Robert Edmonds  wrote:

> It can be rev'd in the same document that introduces a DNS address RR
> for that address family :-)
>

Why not use Address Family

 like EDNS Client Subnet ?
But for that matter...

On Fri, 6 Jan 2017 18:43:30 +, "Wessels, Duane"  wrote:

> It is of course quite similar to EDNS client subnet, except that there is
> no masking and the client cannot opt-out.  Might be worth saying in your
> document why EDNS client subnet wouldn't work for this purpose.
>

Why *wouldn't* ECS work for this? If the idea is to expose
everything obscured by a proxy (e.g., for backend logging), then the option
data should include quite a bit more than an address—at minimum, a protocol
number
 for
differentiating UDP/TCP, the original OPT CLASS (UDP payload size) and
flags (including DO), and a flag indicating presence or absence of an OPT
record in the original query. You might also want to include the port and
id from the original query (for direct response) and/or allow arbitrary
data after the address (for communicating installation-specific metadata).
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop