RFC: retry keyservers witout SRV

[Luis R. Rodriguez]

On Tue, Nov 21, 2017 at 02:48:30PM +0100, Kristian Fiskerstrand wrote:
> On 11/21/2017 02:27 AM, Luis R. Rodriguez wrote:
> > I have a R6300v2 which after a firmware upgrade it seems it now replies to SRV
> > queries for _pgpkey-https and others as a "format error". I've captured tcpdumps
> > for it and are on file.
> 
> My $0.02 would be that a format error for SRV request is that should be
> fixed in the DNS resolver (or use another resolver) and not introduce
> complexity to work around, 

I'd agree if this was not widespread.

> in particular as long as it isn't a widespread issue.

I've taken a random silly twitter poll [0] and so far its two failures, two
successes for a 50% failure rate, feel free to poll up if you've succumbed
to twitter. And that doesn't count my own issue, putting this failure rate
up might higher. I'm certain these metrics must be off otherwise folks on
this list would have digged into the issue and found it earlier as well.
Unless of course folks have been lazy :)

Since it so far seems it may be an issue affecting much more folks than
expected, I think its fair to consider for us to try to both:

1) get to the bottom of what is causing this issue on routers and;
2) consider a work around for DNS servers when they don't work with SRV HKP

As for 1) I'm currently suspect of a dnsmasq bug, however since the software
was proprietary I can't do any more work on it.

> Are you aware of any bug reports for this with netgear?

Netgear only offers complimentary support 90 days after purchase, you can also
pay for extra support contracts, one is at at $149.00, no thanks! After that
they let you just use community forums.

I'll note that even if this issue was fixed this router interface currently
does not even let you pick an option to use alternative DNS servers, nor for
a way to confirm this. Because of this I suspect more similarly affected
routers may suffer similar fate or making it hard to work around for an entire
network.

I've reflashed my first R6300v2 with OpenWRT but that worked miserbly -- but I did
confirm that it *does not* have the SRV HKP issue. I then then tried to move on to
the R6300v2 DD-WRT firmware, this worked *much better* (has the stupid proprietary
driver which enables 5 GHz and 802.11ac, and has a functional web interface),
but more importantly I was also able to confirm it does not have the same
DNS SRV HKP issue and *does* lets users select specific DNS servers as verified
through tcpdump on the router itself (using defaults, ie my ISP, and also using
shiny new 9.9.9.9, or 8.8.8.8).

We can't expect users to *know* how to do all the above, and if its widespread,
I think we do need to address an alternative route than using HKP SRV first.
The documentation is not very clear also as to why its imperative we don't
do a retry *without* HKP SRV, why should we shy away from that? The best
justification I could find for DNS HKP SRV was Kristian Fiskerstrand's paper
on using SRV on sks-keyservers.net. It goes into much of the algorithmic
aspects about weights, but doesn't seem to have anything which to me reads
"though shall not skip SRV HKP". Why should we avoid simply DNS lookups
if all SRV HKP attempts fail? Currently we fail with a brutal and non-obvious
non-functional GPG for basic operations.

I'll keep on digging to root cause 1) by looking to see if there may be an
old dnsmasq bug, or "feature" / flag, but at this point I could not let
such issue stall my work, since I reflashed I now cannot reproduce the original
issue but it would seem there a souls out there that also suffer from it.

[0] https://twitter.com/mcgrof/status/932849226895126529
[1] https://sks-keyservers.net/files/sks-keyservers-SRV.pdf

  Luis