> On Aug 30, 2016, at 12:00 AM, Shane Kerr <[email protected]> wrote: > > Paul, > > At 2016-08-10 16:54:39 -0700 > "Paul Hoffman" <[email protected]> wrote: > >> [[ A month later, we're still eager to hear responses to the draft. We >> got a few that we have incorporated for a new version, but want to be >> sure we're on the right track before we move ahead. ]] > > I'm back from vacation and catching up on old mail. I decided to go > through this draft instead of finishing that. ;) > > > I have a couple questions about the Key Tag Query. (Apologies if these > have been discussed already - I do remember some mention of the first > question in a meeting so maybe it has been discussed and discarded.) > > First, can we please just use the decimal version of the Key Tag > values? As an operator it sure is easier to be able to cut & paste from > a log instead of having to use "bc" or Python to convert from the hex > to the value that is actually in all of my configuration files > everywhere.
I have a weak preference for the hex format because IMO it adds some structure to the message that helps differentiate real signal from noise. For example I think it is useful to know that "_ta-0033" is a well-formatted key tag query, but "_ta-33" is not. I'm not sure about the bc/python argument because I would expect this to be generally built in to the name server software, and I don't feel that adding an awk/bc/python one-liner to a shell script to be all the burdensome. > > Second, the easiest way for a querier to use this might be to set up a > cron job that grabs the anchor information out of a configuration file > and sends it via "dig". That doesn't require any support from any > software beyond what I have today, but it doesn't match the idea of > sending it at the same time as a DNSKEY query. I suggested tying it to the DNSKEY query for a couple of reasons: (1) thats how it works when conveyed by EDNS; (2) it provides a consistent interval across all implementations and gives the zone operator some control over how often to receive key tag data. > > Finally, the security concerns section got me to thinking about ways to > send the trust anchor information in an encrypted way. I don't see an > easy way to do this in the DNS itself, but we could use HTTPS for this. > A zone could add a RR something like: > > _dns-trust-anchor-reporting._tcp.$ZONE. $TTL IN SRV 0 1 443 an.example > > Then a resolver could use a RESTful query like: > > https://an.example/$ZONE/$SRVID/keytag1,keytag2,keytag3 > > If we really wanted to keep it in DNS do something similar but submit a > DNS over TLS query instead. Maybe: > > _dns_trust_anchor_reporting._tcp.$ZONE. $TTL IN SRV 0 1 853 an.example > > Then the resolver could use the Key Tag query. This also has a slight > advantage of only reporting information to trust anchor operators who > plan on doing something with the data. It does require DNS over TLS > support though.... This seems like too much complexity to me. DW
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
