In message <[email protected]>, "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 ]
> 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 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.
>
> I'd like to hear others' opinions, especially from implementors.
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...)".<domain>, 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 protected]
> 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 protected]
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
