domain keys and name-checking
aklist
I'm trying to bring up a mailserver in the domain that uses domain-keys, and
the server's tech support staff sent me a domain key to add as a text record
for the domain.
This is the first domain I ever was required to set up domain-keys for. The
domain key has a syntax like:
server._domainkey.domain.com. IN TXT "k=rsa; p=[very long string]"
When I try to reload the zone, I get a log error:
17-Oct-2008 09:40:30.816 general: error: db.domain.com:18:
server._domainkey.domain.com: bad owner name (check-names)
17-Oct-2008 09:40:30.816 general: error: zone domain.com/IN/external:
loading from master file db.domain.com failed: bad owner name (check-names)
The server's support people are telling me "the current release of BIND
doesn't seem to like underscores and you need to disable name-checking in
BIND"
Is that correct? If so, can I disable name-checking for a particular domain?
Barry Margolin
"aklist" <aklis...@enigmedia.com> wrote:
Underscores are only disallowed in host names, i.e. A and AAAA records,
they're allowed in all other records.
My guess is that you inserted that line between records for the same
name, that were making use of the feature of automatically reusing the
name from the previous line, e.g. you started with:
foo IN A 1.2.3.4
IN A 2.3.4.5
and changed it to:
foo IN A 1.2.3.4
server._domainkey IN TXT "k=rsa; p=[very long string]"
IN A 2.3.4.5
Now the second A record is assigned to server._domainkey, which is not a
valid hostname.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
aklist
> name, that were making use of the feature of automatically reusing the
> name from the previous line, e.g. you started with:
>
> foo IN A 1.2.3.4
> IN A 2.3.4.5
>
> and changed it to:
>
> foo IN A 1.2.3.4
> server._domainkey IN TXT "k=rsa; p=[very long string]"
> IN A 2.3.4.5
>
> Now the second A record is assigned to server._domainkey, which is not a
> valid hostname.
Hi: I'm close to fixing this...I moved the "sever._domainkeys..." record to
the bottom of the domain, and named-checkzone doesn't object.
However, I have a subdomain that I'm trying to declare at the same time, and
when I append it to the end of the domain I get an "ignoring out-of-zone
data" error for all the subdomain's A records. (The subdomain only contains
a single server, which is a mailserver with 5 IPs assigned to it.) My
complete domain looks like this:
$TTL 3h
@ IN SOA ns.parent.com. hostmaster.parent.com. (
2008101601 ; serial
3h ; refresh
1h ; retry
1w ; expire
1h ) ; neg cache
;
NS ns.parent.com.
NS ns1.parent.com.
;
MX 10 mail
;
TXT "v=spf1 ip4:aaa.bbb.ccc.40/29 a mx -all"
;
A aaa.bbb.ccc.41
mail A aaa.bbb.ccc.42
www A aaa.bbb.ccc.41
;
server._domainkey.domain.com. IN TXT "k=rsa; p=[long string]"
;
$ORIGIN sub.domain.com.
server A aaa.bbb.ccc.42
server A aaa.bbb.ddd.12
server A aaa.bbb.ddd.13
server A aaa.bbb.ddd.14
server A aaa.bbb.ddd.15
MX 10 server
;
TXT "v=spf1 ip4:aaa.bbb.ccc.40/29 a mx -all"
aklist
>> do I need to just make the MX record (right before the domain keys
>> record):
>>
>> domain.com. MX 10 mail
>>
>> or do I also have to prepend "domain.com" to the A record that follows
>> the domain keys record?
>>
>
> You need to move the domainkey record to after the A record. That's
> supposed to be a continuation of all the records for the zone name. Do
> you understand that indenting a line means it inherits the name from the
> previous line?
>
I do now <g>...I always did it without thinking about why it worked, because
it worked!
The question for me now, how do I delegate a subzone in this domain without
named-checkzone grumbling that it's "ignoring out-of-zone data"? I have:
[last A record in zone]
www A aaa.bbb.ccc.41
;
server._domainkey.domain.com. IN TXT "k=rsa; p=[long string]"
;
$ORIGIN sub.domain.com.
server A aaa.bbb.ccc.42
server A aaa.bbb.ddd.12
server A aaa.bbb.ddd.13
server A aaa.bbb.ddd.14
server A aaa.bbb.ddd.15
MX 10 server
;
but I'm still getting the error above for all the subzone A records?
Barry Margolin
"aklist" <aklis...@enigmedia.com> wrote:
> >>
> >> do I need to just make the MX record (right before the domain keys
> >> record):
> >>
> >> domain.com. MX 10 mail
> >>
> >> or do I also have to prepend "domain.com" to the A record that follows
> >> the domain keys record?
> >>
> >
> > You need to move the domainkey record to after the A record. That's
> > supposed to be a continuation of all the records for the zone name. Do
> > you understand that indenting a line means it inherits the name from the
> > previous line?
> >
> I do now <g>...I always did it without thinking about why it worked, because
> it worked!
Maybe it's time for you to read the "DNS & BIND" book and learn how all
this stuff works.
>
> The question for me now, how do I delegate a subzone in this domain without
> named-checkzone grumbling that it's "ignoring out-of-zone data"? I have:
>
> [last A record in zone]
> www A aaa.bbb.ccc.41
> ;
> server._domainkey.domain.com. IN TXT "k=rsa; p=[long string]"
> ;
> $ORIGIN sub.domain.com.
> server A aaa.bbb.ccc.42
> server A aaa.bbb.ddd.12
> server A aaa.bbb.ddd.13
> server A aaa.bbb.ddd.14
> server A aaa.bbb.ddd.15
> MX 10 server
Is that supposed to be an MX record for sub.domain.com? The way you
have it written, it's the MX record for server.sub.domain.com. If you
want it to belong to the subdomain, it should be:
@ MX 10 server
Remember what you learned above about indented lines! Note also that
this means you don't need to repeat "server" on each line, you can just
indent all the continuations.
> ;
>
> but I'm still getting the error above for all the subzone A records?
Those records all belong in the zone file for sub.domain.com, not
domain.com. That's what "delegating a subzone" means -- the subdomain
data is all in its own files on the servers that you've delegated to
(the ones named in the NS records).
If you're using all the same servers for both domain.com and
sub.domain.com, you don't need to delegate at all. Get rid of the NS
records for sub.domain.com, the "zone" statement in your named.conf, and
then you can put these records in the
aklist
>> because
>> it worked!
>
> Maybe it's time for you to read the "DNS & BIND" book and learn how all
> this stuff works.
I do have the book, and I've used the examples therein to set up BIND, but I
didn't read it cover to cover...Cricket said this was OK <g>. Thanks for you
patience though.
>> but I'm still getting the error above for all the subzone A records?
>
> Those records all belong in the zone file for sub.domain.com, not
> domain.com. That's what "delegating a subzone" means -- the subdomain
> data is all in its own files on the servers that you've delegated to
> (the ones named in the NS records).
I understand that, but I was using DNS & BIND's example of "Creating a
Subdomain in the Parent's Zone"...which doesn't provide much detail...just
add the origin statment for the subdomain and the subdomain records under
it.
> If you're using all the same servers for both domain.com and
> sub.domain.com, you don't need to delegate at all. Get rid of the NS
> records for sub.domain.com, the "zone" statement in your named.conf, and
> then you can put these records in the
Oh, I wish you'd finish that statement!
FWIW: I thought I _wasn't_ delegating the subdomain by including it in the
parent zone in my example...nor did I create any NS records for the
subdomain...all I did was append this to the end of the parent zone file as
the example shows, but I'm getting the out-of-zone error with this config.
Alan Clegg
> FWIW: I thought I _wasn't_ delegating the subdomain by including it in the
> parent zone in my example...nor did I create any NS records for the
> subdomain...all I did was append this to the end of the parent zone file as
> the example shows, but I'm getting the out-of-zone error with this config.
>
> $ORIGIN sub.domain.com.
> server A aaa.bbb.ccc.42
> server A aaa.bbb.ddd.12
> server A aaa.bbb.ddd.13
> server A aaa.bbb.ddd.14
> server A aaa.bbb.ddd.15
> MX 10 server
Since you continue to submit edited snippets of your zone file instead
of the complete/correct ones, we can't tell you what the problem is.
If, however, you decide to post the actual contents of your file,
someone will be able to see the problem and would have corrected it
about 5 message exchanges back.
AlanC
Barry Margolin
"aklist" <aklis...@enigmedia.com> wrote:
> >> I do now <g>...I always did it without thinking about why it worked,
> >> because
> >> it worked!
> >
> > Maybe it's time for you to read the "DNS & BIND" book and learn how all
> > this stuff works.
>
> I do have the book, and I've used the examples therein to set up BIND, but I
> didn't read it cover to cover...Cricket said this was OK <g>. Thanks for you
> patience though.
>
> >> but I'm still getting the error above for all the subzone A records?
> >
> > Those records all belong in the zone file for sub.domain.com, not
> > domain.com. That's what "delegating a subzone" means -- the subdomain
> > data is all in its own files on the servers that you've delegated to
> > (the ones named in the NS records).
>
> I understand that, but I was using DNS & BIND's example of "Creating a
> Subdomain in the Parent's Zone"...which doesn't provide much detail...just
> add the origin statment for the subdomain and the subdomain records under
> it.
>
> > If you're using all the same servers for both domain.com and
> > sub.domain.com, you don't need to delegate at all. Get rid of the NS
> > records for sub.domain.com, the "zone" statement in your named.conf, and
> > then you can put these records in the
>
> Oh, I wish you'd finish that statement!
>
> FWIW: I thought I _wasn't_ delegating the subdomain by including it in the
You said "subzone", so I assumed it was delegated. The difference
between a subdomain and a subzone is whether it's delegated.
> parent zone in my example...nor did I create any NS records for the
> subdomain...all I did was append this to the end of the parent zone file as
> the example shows, but I'm getting the out-of-zone error with this config.
There must be something elsewhere in the zone file or named.conf that
tells it that the subdomain is in a separate zone. Otherwise, it
wouldn't complain about out-of-zone data.
Or you've made a typo that makes it look like these new records belong
in a different zone. As the other poster said, if you post the actual
configuration and zone files, we should be able to tell.
D. Stussy
news:gdaoll$tu3$1...@sf1.isc.org...
It works for me.
The underscore is a valid character in labels, but not in hostnames. Do you
have any other records owned by or under the _domainkey label?
D. Stussy
If it's really a subdomain, then the $ORIGIN statement should be a RELATIVE
name (especially since there's only one such statement). The same thing
goes with the _domainkey label(s).
Barry Margolin
"D. Stussy" <sp...@bde-arc.ampr.org> wrote:
That's just a style choice, not a requirement. Although it's a good way
to avoid many unintended "out-of-zone data" errors.
D. Stussy
news:gdir0q$1s7e$1...@sf1.isc.org...
That's why I said SHOULD instead of MUST.
aklist
>> FWIW: I thought I _wasn't_ delegating the subdomain by including it in
>> the
>> subdomain...all I did was append this to the end of the parent zone file
>> as
>> the example shows, but I'm getting the out-of-zone error with this
>> config.
>>
>> server A aaa.bbb.ccc.42
>> server A aaa.bbb.ddd.12
>> server A aaa.bbb.ddd.13
>> server A aaa.bbb.ddd.14
>> server A aaa.bbb.ddd.15
>> MX 10 server
>
> of the complete/correct ones, we can't tell you what the problem is.
> If, however, you decide to post the actual contents of your file,
> someone will be able to see the problem and would have corrected it
> about 5 message exchanges back.
>
> AlanC
Thanks for your kind words...if you read my original post "5 message
exchanges back" you would have seen the complete zone file.
Barry Margolin
"aklist" <aklis...@enigmedia.com> wrote:
I haven't seen anything that uses real domains, just bogus domains like
"parent.com" and "sub.domain.com", and addresses containing non-numbers
like aaa, bbb, and ccc. I refuse to believe that this is what's in your
actual zone file.
If you did actually post a real zone file, it somehow didn't make it
across the mail-to-news gateway, because I read this group in the
comp.protocols.dns.bind Usenet newsgroup and I don't see it.
Also, you haven't posted the named.conf file. The most complete
facsimile of a zone file starts with:
$TTL 3h
@ IN SOA ns.parent.com. hostmaster.parent.com. (
Since there's no $ORIGIN directive, I can't tell what zone this is. If
I had to guess, I'd assume you're defining parent.com. Then later the
file contains:
$ORIGIN sub.domain.com.
Since sub.domain.com is not part of the parent.com zone, this would
explain the "out-of-zone" errors.