Subject: [DNSOP] edns-key-tag: EDNS0 option or query name?

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 10 Mar 2016 22:47:06 +0000

During previous discussions of the edns-key-tag draft, some people argued that it would be better to convey key tags as query names, rather than EDNS0 options.

Perhaps the best argument against the EDNS0 option is that since EDNS0 is hop-by-hop, some resolvers and other meddleboxes won't know to forward the option unless/until they are upgraded to support edns-key-tag.

Personally I think EDNS0 is more elegant but its hop-by-hop-ness complicates things.

I worry that using query names will reduce the quality of the data because the bar is low -- its so easy to just generate a query.  I'd prefer it if the key tag data was tied to some additional indication of validation (i.e., in the same message as the DNSKEY query).

I also worry about Geoff Huston's "Zombie Queries" talk from NANOG (https://www.nanog.org/sites/default/files/02%20zombies.pdf).  In his experiment he sent one-time-use URLs and DNS queries throughout the Internet and found them getting repeated over and over, day after day.  

I'd like to hear others' opinions, especially from implementors.

DW

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Mar 2016 11:04:05 +1100

In message <[email-masked]>, "Wessels, Duane
" writes:
> During previous discussions of the edns-key-tag draft, some people argued tha
> t it would be better to convey key tags as query names, rather than EDNS0 opt
> ions.
> 
> Perhaps the best argument against the EDNS0 option is that since EDNS0 is hop
> -by-hop, some resolvers and other meddleboxes won't know to forward the optio
> n unless/until they are upgraded to support edns-key-tag.

[ meddleboxes is the correct description even though you meant middleboxes ]
 
> I worry that using query names will reduce the quality of the data because th
> e bar is low -- its so easy to just generate a query.  I'd prefer it if the k
> ey tag data was tied to some additional indication of validation (i.e., in th
> e same message as the DNSKEY query).

It's just as easy to generate queries with EDNS options as well.

	dig +ednsopt=<codepoint>:<payload> domain dnskey +norec @server

If people want to mess with the data they will.
 
> I also worry about Geoff Huston's "Zombie Queries" talk from NANOG (https://w
> ww.nanog.org/sites/default/files/02%20zombies.pdf).  In his experiment he sen
> t one-time-use URLs and DNS queries throughout the Internet and found them ge
> tting repeated over and over, day after day.  
> 

Personally I would encode it in query names (and have done so on
experimental branches).  This works through the existing resolver
base.  This is also deployable without upgrading all existing tools.
You just need a new tool that can take a list of trust anchors and
generate the queries.

As for Geoff's zombies there are lots of potential causes for it many
of which are not DNS elements.  I would not worry about it.

Below is the ARM description from the experimental branch.

            <varlistentry>
              <term><command>trust-anchor-telemetry</command></term>
              <listitem>
                <para>
                  Causes <command>named</command> to send specially-formed
                  queries once per day to domains for which trust anchors
                  have been configured via <command>trusted-keys</command>,
                  <command>managed-keys</command>,
                  <command>dnssec-validation auto</command>, or
                  <command>dnssec-lookaside auto</command>.
                </para>
		<para>
		  The query name used for these queries has the
		  form "_ta-xxxx(xxxx...)".&lt;domain&gt;, where xxxx is
		  a group of four hexadecimal digits representing
		  the key ID of a trusted DNSSEC key.  The key ids
		  for each domain are sort smallest to largest prior
		  to encoding. The query type is NULL.
		</para>
                <para>
                  By monitoring these queries, zone operators will
                  be able to see which resolvers have been updated to
                  trust a new key; this may help them decide when it
                  is safe to remove an old one.
                </para>
                <para>
                  The default is <userinput>yes</userinput>.
                </para>
              </listitem>

We have existing tools that can easily extract the queries without having
to update authoritative servers.
e.g.
	tcpdump | grep "NULL? _ta"

As for using a EDNS option there are still authoritative servers that
mishandle unknown EDNS options.  All resolvers in the path need to be
updated.

Mark

> DW
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]