[DNSOP] order of records in DNAME responses

[Evan Hunt]

RFC 6672 saith:

A CNAME RR with Time to Live (TTL) equal to the corresponding DNAME
RR is synthesized and included in the answer section when the DNAME
is employed as a substitution instruction. The DNSSEC specification
([RFC4033] [RFC4034] [RFC4035]) says that the synthesized CNAME does
not have to be signed.  The signed DNAME has an RRSIG, and a validating
resolver can check the CNAME against the DNAME record and validate the
signature over the DNAME RR.

The phrase "included in", as opposed to "appended to", provides no guidance
about the order in which records appear, so presumably it's legal to have
the synthesized CNAME appear first and the DNAME from which it was
synthesized afterward.

Most implementations, however, do send the DNAME first.  We had a problem
with BIND a while back when we encountered a server that didn't.  BIND
processes the RRsets in an answer in the order they're received (I suspect
nearly all resolvers do this).  In this case, the decisions about how to
validate and cache the CNAME went wrong because we didn't have the flag set
saying we'd previously seen a DNAME.

We rejiggered the code so it wouldn't care about the order of records
anymore (incidentally, and embarrassingly, introducing another bug in the
process, but that's another story).  It would have been simpler and more
painless if we could have just treated this condition as a FORMERR.

I'd like to start a discussion of that now.  Does anyone have a problem
with the idea of clarifying the protocol here, saying that the order of
records in the answer section of a chaining response is significant, and in
particular, that a DNAME MUST precede the corresponding synthesized CNAME?

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

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

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

[Bob Harold]

On Tue, Feb 21, 2017 at 6:39 AM, Sara Dickinson  wrote:

> Hi All,
>
> This update to the draft tries to address the recent comments:
>
> * Many editorial improvements by Paul Hoffman
>
> * Included discussion of malformed packet handling
>
> * Improved Appendix C on Comparison of Binary Formats
>
> * Now using C-DNS field names in the tables in section 8
>
> * A handful of new fields included (CDDL updated)
>
> * Timestamps now include optional picoseconds
>
> * Added details of block statistics
>
> Regards
>
> Sara.
>
> > On 21 Feb 2017, at 11:36, 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   : 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-01.txt
> >   Pages   : 48
> >   Date: 2017-02-21
> >
> > 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://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-01
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-01
> >
> >
> > 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/
> >
>
>
Is it possible to have a case where the software does not know if
promiscuous mode was enabled ?  If so, we should allow for an "unspecified"
or "unknown" code for "promisc"

Perhaps a pcap to C-DNS converter would have this issue, if the pcap format
does not include "promisc" info?

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

Re: [DNSOP] Published: draft-hardaker-rfc5011-security-considerations-04.txt

[Bob Harold]

On Fri, Feb 17, 2017 at 4:38 PM, Wes Hardaker  wrote:

>
> For those following along with this draft, I've just published -04.
>
> --
> Wes Hardaker
> USC/ISI
>
>
Thanks for your work on this.

I see you updated the formula in section 6.  Minimum RFC5011 Timing
Requirements
The paragraph after it says:
"The most confusing element of the above equation comes from the "3 *
(DNSKEY RRSIG Signature Validity) / 2" element, but is the most critical to
understand and get right."

But the formula no longer contains "3 * " anything.

Also, diff2 does not handle the UTF-8 in Petr's name.
https://tools.ietf.org/rfcdiff?url2=draft-hardaker-rfc5011-security-considerations-04.txt
and even the normal view
https://tools.ietf.org/html/draft-hardaker-rfc5011-security-considerations-04

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

[DNSOP] summary: virtual interim meeting, 16 Feb. 2017

[Suzanne Woolf]

Hi,

The chairs’ summary from the WG virtual interim meeting last week appears below.

Recording of the webex session: 

https://ietf.webex.com/ietf/ldr.php?RCID=09e87536cf71661d1e4e7339abcf001e 



Chairs’ summary of the discussion

1. sutld-ps WGLC:
* editors are resolving issues, quite a few have been raised and most 
are straightforward to resolve
* distinction between special use names generally and “TLDs” needs to 
be clear, also distinction between names to be resolved with DNS and names to 
be resolved otherwise
* Question came up of where we stand process-wise, particularly if the 
IETF or IESG change or don't publish the problem statement. There's been no 
commitment to publish it, but the roadmap that blocked other action on having 
one was discussed multiple times with our AD; and even if we don’t publish it, 
the exercise has been useful for the WG
* Future action may not occur in DNSOP at all; that’s largely up to the 
IESG.

2. alt-tld:
* mostly done; we know what it will and won’t do, and there was 
agreement that more distinction needs to be made in the document
* as discussed on the list, consensus seems to be against asking for a 
signed delegation in the root for .alt
* open issue discussed here was whether to add .alt to the 
locally-served zones registry; consensus on the call seemed to be not to do 
that either; editors will propose text to wrap up both issues. Some people felt 
the justification for the latter should be in a “Security Considerations,” 
others felt it should be in a “Privacy Considerations”.

3. next steps
* no one is ready to propose concrete next steps beyond “find out what 
the IESG thinks”
* some people feel this topic isn’t DNSOP WG business, because there 
are technical issues but they won’t be resolved within the scope of the WG 
charter; a few feel it’s a “layer violation” that has nothing to do with the 
IETF, because it’s intrinsically and entirely political.
* some confusion on the scope limitation put in place for the problem 
statement that we/the IESG might want to relax for DNSOP (or anyone else) to 
consider solutions

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