Apparently my issues were caused by two different problems.
Issue #1
SSHFP does not support using search paths. So if you add "domain example.com" to /etc/resolv.conf then you would expect ssh myhost to work with SSHFP since regular ssh will correctly resolve the name to myhost.example.com. Apparently the OpenBSD devs are aware of the issue since a patch was issued 2 years ago but it was never applied. Instead an ssh_config hack was suggested but that doesn't appear to work either. So the solution to the first issue is that FQDN must always be used with SSHFP.
Issue #2
Using FQDNs to solve the previous issue, everything works if I use the current version of the OpenSSH client which is OpenSSH_6.1. The OpenSSH_5.8p2 client on my FreeBSD system is able find the SSHFP records for a new OpenSSH_6.1 server, but it is unable to match the fingerprint it receives from DNS with the one it receives from the server. The OpenSSH_5.9p1 client on my OS X 10.8.2 machine is unable to even retrieve the SSHFP records for a new OpenSSH_6.1 server despite being a never version of the client than the FreeBSD machine. Obviously it is unable to match the non-existant SSHFP records with the fingerprint returned by the OpenSSH server. Lastly, ssh-keygen on the FreeBSD box produces bad SSHFP records according to the OpenSSH_6.1 clients which complain about a MITM attack since they don't match the fingerprint returned by the server. The solution appears to be that you must run the current version of both OpenSSH client and server for SSHFP to work. Using an older version of either the client or the server is asking for trouble.
Final Thoughts
Using SSHFP with DNS is apparently too cutting edge to be used in a mixed OS environment and have everything "just work" since the non-OpenBSD OS's have to port OpenSSH portable which is out of date by the time it is ported. Perhaps in 3-5yrs, SSHFP will be stable enough that even the older versions which are ported to other OSs will also be stable and compatible with the latest version.
After more research, the problem appears to be the following:
The initial setup contained both forwarders that were DNSSEC-capable (GoogleDNS 8.8.8.8, 8.8.4.4) and some that weren't (OpenDNS 208.67.222.222, 208.67.220.220). I had BIND9 running with DNSSEC fully enabled, as per the following configuration:
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
a) Whenever a request (A?) was forwarded to the GoogleDNS servers, my_server got a reply (A), sent a DNSSEC-query (DS?) and got a proper answer. Resolution done, signature confirmed, all working like a charm, case closed (see above, the normal case).
b) Whenever a request (A?) was forwarded to the OpenDNS servers, my_server got a reply (A), sent a DNSSEC-query (DS?) which OpenDNS failed to answer properly as it does not support DNSSEC. So BIND9 threw an error in syslog
, stating that it got insecure response
and tried to get it's DNSSEC-validation elsewhere (see above, the problematic case).
I still don't fully understand what happened then, but obviously that's when the hiccups started. Now I don't know if the GoogleDNS-servers didn't like giving out DS?-answers without having served the corresponding A?-query first. But in both of the problematic cases (sueddeutsche.net, dasoertliche.de) it seems that the entries were also not properly signed so DNSSEC didn't produce correct validation. So DNSSEC-lookaside validation (DLV) was started (Type32769?
) and again it all went south. No idea why.
c) Solution: After all this, I have done the following and have not yet run into any problem (so it seems the question is solved):
First, I switched forwarders to only
forwarders { 8.8.8.8; 8.8.4.4; };
so that there's no longer a mixup of DNSSEC support. Second, I commented out
//dnssec-lookaside auto;
because after digging through lots of tcpdumps, it appears that whenever resolution is slow, the delays are either caused by GoogleDNS taking some time to give back an answer (very rarely happens) or - regularly - happen during DLV. Since DLV is currently being phased out anyway with entries no longer available in 2017
https://www.isc.org/blogs/dlv/
I believe that's acceptable from a security-standpoint.
Now an alternative solution would be to ditch the GoogleDNS servers and only use OpenDNS as forwarders. But then I'd have to comment out all dnssec-entries mentioned above completely disabling DNSSEC, because OpenDNS does not support it. That would leave my dns queries open to attacks which would require adding an alternative layer of security like dnscrypt
(as mentioned by Rui F Ribeiro). While that looks like a worthwile project (as it completely encrypts dns traffic, therefore not only keeping it unaltered but also unreadable by attackers), it's a little over my current time budget.
Any DNS experts out there who want to chime in if the explanations above make sense?
Best Answer
You can do however you please, the only thing you must make sure is that the new serial number is greater than the old one.
Having said that, I would recommend a timestamp based approach following a scheme like:
where
xx
starts at00
and is incremented for all edits on that specific day (when editing on another day, you resetxx
to00
)The main advantage of this scheme is, that you also know the date of the last modification of your zone-file at first glance.
It also makes the serial number incrementing more robust.
The alternative is to start with
1
and just increment whenever you edit the file.If the serial number is already timestamp based (and
2015040500
looks very much like that), you shold probably stick with that decision (even if not made by you), and use the logical successor2015042200