hi,
after i test nsd i find the following. if i use this in a zone file:
$ORIGIN example.com.
CNAME www
www CNAME x
x A 1.2.3.4
then it's excepted by nsd what's more give the proper result. if the
slave is nsd than there is no problem, while if the slave is bind i've
got the following error:
and of course bind don't accept the above even if he's the master.
so my question who is right,
BIND.
but most important is there any other way
than define an A record for the domain itself?
No.
I think a bug should be filed. "CNAME and other data" (to quote the BIND
error message) is not allowed per the standard (RFC 1034, section 3.6.2.),
and letting it into a zone is a no-no.
I'd turn the pointers around, so you'd have
$ORIGIN example.com.
A 1.2.3.4
www CNAME example.com.
x CNAME example.com.
Roy
Hi,
I think you are getting the errors because you put a CNAME at the zone
apex (example.com). And no other data is allowed next to a CNAME, and
there is also a SOA record at the apex. This is why bind complains I
think. But where is your SOA record, I think that is confusing NSD from
giving a similar (CNAME not allowed with other data) error.
Roy Arends wrote:
apart from the fact that you can't define a CNAME RR at the zone apex
because it collides with the mandatory SOA and NS RRs (Roy mentioned it),
it is also not clear what the proper interpretation of the first CNAME
definition is. As per RFC 1035, the <blank> "inherits" the last "stated
ownername" and that isn't influenced by the $ORIGIN statement.
-Peter
hi,
imho it's nothing to d with other part of the zone, that's why i refer
only this part, but here is a full zone file example:
Roy Arends wrote:
hi,
after i test nsd i find the following. if i use this in a zone file:
$ORIGIN example.com.
CNAME www
www CNAME x
x A 1.2.3.4
then it's excepted by nsd what's more give the proper result. if the
slave is nsd than there is no problem, while if the slave is bind i've
got the following error:
----------------------------
transfer of 'example.com/IN' from 212.92.23.223#53: resetting
transfer of 'example.com/IN' from 212.92.23.223#53: failed while
receiving responses: CNAME and other data
transfer of 'example.com/IN' from 212.92.23.223#53: end of transfer
----------------------------
and of course bind don't accept the above even if he's the master.
so my question who is right, but most important is there any other way
than define an A record for the domain itself?I'd turn the pointers around, so you'd have
$ORIGIN example.com.
A 1.2.3.4
www CNAME example.com.
x CNAME example.com.
ok actually the real problem is when web server is not in the given zone
(but i just like to point to the problem in my original mail) like in
this case:
$ORIGIN example.com.
CNAME www
www CNAME virtual.webserver.com.
in this case both record should have to be CNAME and the only place
where any changes would have to made is in webserver.com zone.
Farkas Levente wrote:
ok actually the real problem is when web server is not in the given zone
(but i just like to point to the problem in my original mail) like in
this case:
$ORIGIN example.com.
CNAME www
www CNAME virtual.webserver.com.
in this case both record should have to be CNAME and the only place
where any changes would have to made is in webserver.com zone.
If you want an IP address associated with the domain name, you need to insert the A record for virtual.webserver.com into the example.com domain. You cannot do this with a CNAME because a CNAME is an alias record, and you can't have a record which has both real data and a record saying that the real data is actually another FQDN.
So you are stuck with:
$ORIGIN example.com.
A 1.2.3.4
www CNAME virtual.webserver.com.
There are several ways to deal with this issue in a production environment. You could store all your DB records in a database and have some intelligence which deals with changing IP addresses for any relevant domains. Or you could use some macro language like M4 which auto-generates zone files from a template. Or you could simply use perl or sed in-place.
Of course, this becomes much more difficult when then domain is hosted by a third party, because you then have to instruct them to change all relevant IP addresses.
Nick
I'd say BIND is correct in refusing to load an invalid zone.
Per RFC you're not allowed to have CNAME together with SOA, NS, MX etc.
I think nsd MUST refuse to load it too.
[Quoting Robert Martin-Legene, on Dec 11, 10:50, in "Re: which is the vai ..."]
<zonefile error>
I think nsd MUST refuse to load it too.
I do NOT think so, trying to do something clever with incorrect
zonefiles is and always has been an explicit non-requirement.
Please see the REQUIREMENTS file under C.1.
If you want to change/update the REQUIREMENTS, which is basis for the
NSD design and implementation, you can, of course, start a discussion
on that topic.
But then, you can expect me, and probably others also, to argue
that dealing with zone file errors is an zonefile administrator
task, and not a task for the (fast, high performance, thus mean-and-lean)
NSD daemon process. There are off-line zonefile syntaxcheckers to
assist zonefile administrators.
Regards,
-- ted
Robert Martin-Legene wrote:
Ted Lindgreen wrote:
[Quoting Robert Martin-Legene, on Dec 11, 10:50, in "Re: which is the vai ..."]
<zonefile error>
I think nsd MUST refuse to load it too.
I do NOT think so, trying to do something clever with incorrect
zonefiles is and always has been an explicit non-requirement.
Please see the REQUIREMENTS file under C.1.If you want to change/update the REQUIREMENTS, which is basis for the
NSD design and implementation, you can, of course, start a discussion
on that topic.
But then, you can expect me, and probably others also, to argue
that dealing with zone file errors is an zonefile administrator
task, and not a task for the (fast, high performance, thus mean-and-lean)
NSD daemon process. There are off-line zonefile syntaxcheckers to
assist zonefile administrators.
Oops, already implemented, but not in the server daemon, but in the zone
compiler for offline checking.
If NSD is transmitted a zone via AXFR that contains such CNAME and other
data, no error is given and it is served anyway, like you describe.
Best regards,
Wouter
[Quoting Wouter Wijngaards, on Dec 11, 11:50, in "Re: which is the vai ..."]
Ted Lindgreen wrote:
> [Quoting Robert Martin-Legene, on Dec 11, 10:50, in "Re: which is the vai ..."]
>
> <zonefile error>
>
>> I think nsd MUST refuse to load it too.
>
> I do NOT think so, trying to do something clever with incorrect
> zonefiles is and always has been an explicit non-requirement.
> Please see the REQUIREMENTS file under C.1.
....
Oops, already implemented, but not in the server daemon, but in the zone
compiler for offline checking.
That's OK: not a requirement does not mean it's forbidden
to do something clever 
But I would have had a problem with it, when the server
daemon was complicated, slowed down, whatever.
Regards,
-- ted
Ted Lindgreen writes:
If you want to change/update the REQUIREMENTS, which is basis for the NSD design and implementation, you can, of course, start a discussion on that topic.
But then, you can expect me, and probably others also, to argue that dealing with zone file errors is an zonefile administrator task, and not a task for the (fast, high performance, thus mean-and-lean) NSD daemon process. There are off-line zonefile syntaxcheckers to assist zonefile administrators.
REQUIREMENTS says "well documented", so I think you might as well mention one or two recommended checkers/linters in the nsd or nsdc manpages, and it also says "conformity to relevant RFCs", which I assumed to mean that even if I do feed nsdc bad input, nsd's answers won't flagrantly violate the RFCs.
Arnt
As Wouter already did what I think is right, overlaid with what Ted thinks
is right, I am very happy with the current state.