Can't resolve DNS since 2.1.17
Gabriel Souza Franco
gabrielfrancosouza at gmail.com
Mon Feb 13 22:29:30 CET 2017
On Mon, Feb 13, 2017 at 5:46 PM, Werner Koch <wk at gnupg.org> wrote:
> The DNS resolver you are using predates SRV records:
> 19:22:50.674427 IP 192.168.15.20.10218 > 192.168.15.1.domain: 53039+ SRV? _pgpkey-https._tcp.hkps.pool.sks-keyservers.net. (65)
> 19:22:50.693552 IP 192.168.15.1.domain > 192.168.15.20.10218: 53039 FormErr 0/0/0 (65)
> The RFC for SRV records is 17 years old and even not so decent DNS
> software supports this. If it does not it is very likely that the box
> has huge numbers of exploitble bugs (think UDP) and an sysadmin should
> be able to get access to that forgotten DNS server even without a
> password and fix it. If you have no sysadmin at hand I suggest to take
> a sledgehammer and tear down the wall behind you assume 192.168.15.1.
I agree that its security might be laughable, but this is not the
point. This unit is a modem/router provided by my ISP and, short of
manually configuring resolver settings at each client, it can't be
fixed (there is no manual firmware upgrade option).
The problem isn't SRV records, but actually any non-existing address.
Someone must've used the wrong bitmask or something.
Again, the old behavior was to treat a DNS error as 0 results found.
Since libdns requests are not malformed, ignoring FORMERR should be
$ nslookup thisdomaindoesnotexist.co
** server can't find thisdomaindoesnotexist.co: FORMERR
$ nslookup -querytype=SRV _xmpp-client._tcp.google.com
_xmpp-client._tcp.google.com service = 5 0 5222 xmpp.l.google.com.
_xmpp-client._tcp.google.com service = 20 0 5222 alt2.xmpp.l.google.com.
_xmpp-client._tcp.google.com service = 20 0 5222 alt1.xmpp.l.google.com.
_xmpp-client._tcp.google.com service = 20 0 5222 alt3.xmpp.l.google.com.
_xmpp-client._tcp.google.com service = 20 0 5222 alt4.xmpp.l.google.com.
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-devel