> On Feb 10, 2017, at 12:55 PM, Dan Langille <d...@langille.org> wrote:
>
>> On Feb 10, 2017, at 12:20 PM, Kern Sibbald <k...@sibbald.com
>> <mailto:k...@sibbald.com>> wrote:
>>
>> Hello,
>>
>> I suspect that this is a problem with the FreeBSD networking implementation.
>> If I remember right on FreeBSD, when doing name lookups, if the packet size
>> is not *exactly* what FreeBSD wants, it fails the call. On Linux and other
>> machines (Solaris, Mac), as long as the packet size is equal or greater than
>> what is needed the OS call succeeds. If I am not mistaken, Bacula allocates
>> space for the larger of IPv4 and IPv6 (which is always IPv6), and so if you
>> are using an IPv4 network, Bacula may send OS calls with a packet size
>> larger than actually required.
>
> I just spoke with a FreeBSD developer. They are unaware of anything special
> in the FreeBSD ports tree for patching FreeBSD when it comes to doing name
> lookups. Specifically, gethostby*(), getipnodeby*() just work...
>
> If you can reproduce/encounter a situation which fails, we will look at it
> and fix it. In short, I do not think this is an issue with the FreeBSD
> networking implementation.
>
> I suspect it's a local DNS misconfiguration on one of my hosts. Which ones,
> I don't know yet. Your first post mentioned the SDs, so I checked them. They
> seem OK now. I will verify them again if I see them again.
>
> For testing purposes, I will use dig +short and verify that all of these FQDN
> resolve on the FD, the SD, the director, and from from a fourth host:
>
> The FQDN of the FD (even though it is not used in a Copy job)
> The FQDN of the read SD
> The FQDN of the write SD
> The FQDN of the Director
>
> I will also check that the PTR record for the A record also resolves back to
> the FQDN.
>
>> If this is the case, I would consider it a FreeBSD bug. For me to fix it is
>> a bit complicated, because I need to know exactly what call is failing and
>> the values that FreeBSD wants. By the way, it is possible this is already
>> fixed in the Enterprise version where FreeBSD is supported too. If that is
>> the case, in my next round of backporting to start next week, it will get
>> fixed.
>
> If this was the case, I'd expect apps on FreeBSD to be failing everywhere.
> They aren't. I've never patched anything for DNS issues either.
>
> I suspect it's more likely to be an issue on one of the Bacula nodes in
> question (SD or FD) where there is a local DNS issue.
For documentation: I found that one of my three name servers was not correctly
resolving PTR records. That is:
$ dig +short -x 10.52.0.1 @10.55.0.1
Whereas the other two nameservers:
$ dig +short -x 10.52.0.1 @10.55.0.13
bast.int.unixathome.org.
$ dig +short -x 10.52.0.1 @10.55.0.73
bast.int.unixathome.org.
That issue since been fixed. It took a while to track down. That nameserver
is running pfSense, using their GUI. The issue is right there on the page:
Note: IN-ADDR.ARPA will be automaticaly included in config files when reverse
zone option is checked.
The checkbox is four controls farther down the page.
The expected zone 0.55.10.in-addr.arpa was actually zone
0.55.10.in-addr.arpa.in-addr.arpa
I'll keep an eye on the Bacula logs to see if this shows up again.
Thank you.
--
Dan Langille - BSDCan / PGCon
d...@langille.org
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
