On 04/22/14 16:38, Todd Lyons wrote:
> On Tue, Apr 22, 2014 at 12:49 PM, Phil Stracchino <phils_at_caerllewys.net> wrote:
>>> As I understand things, _ is not valid in a hostname, but it is valid
>>> in a DNS RR.
>>
>> Yes, and it's legal in an IN TXT record. However, due to quirks of
>> bind9 implicit syntax, it was causing the next A record to fail.
>
> That's interesting, I've not seen this. Some of my bind servers use
> generated zone files and some are backed by dlz with mysql, so my
> systems are not homogenous enough to be indicative.
Actually, I misspoke there. I meant NS records, not A records; and all
of my NS records inherit _at_ from the SOA record. I forgot about the
inheritance when I placed the dkim TXT record where I did.
>> I moved the _domainkey TXT record to the end of each respective zone
>> file, and it's now working.
>
> That's a really odd bug. I haven't come across that in my versions of
> bind9. Which versions are affected?
It isn't a bug; it's standard BIND behavior which I'd forgotten about.
If you do this:
a IN A 10.10.10.3
b IN A 10.10.10.4
c IN A 10.10.10.5
you end up with one address assigned to each of a, b, c. But if you do
this:
a IN A 10.10.10.3
IN A 10.10.10.4
IN A 10.10.10.5
then the A records with no hostname inherit the hostname from the record
above, so all three records end up bound to host a.
In this case, my zone file contains my SOA record, followed by several _at_
In TXT records, the last of them my spf1 record. Right after the spf1
record seemed to be the obvious place for the dkim record.
I'd FORGOTTEN that the very next thing in the zone file after the spf1
record was my IN NS records, all of which inherit _at_ from the records
above them. Except that _now_ they didn't inherit _at_ any more, they
inherited dkim._domainkey, which of course is not valid in an NS record.
The other fix of course would have been to use an explicit _at_ in the NS
records. There's really no particular reason for doing the NS records
the way I was, with an implicitly inherited _at_, other than history;
that's what the example I originally based my first zone file on did.
In light of this problem, one might deem it a questionable practice.
(Although I have some recollection of doing it that way because at some
point in time, you could only have one _at_ record, but following records
could inherit the _at_.)
--
Phil Stracchino
Babylon Communications
phils_at_caerllewys.net
phil_at_co.ordinate.org
Landline: 603.293.8485
Received on Tue Apr 22 2014 - 22:12:24 PST