CNAME and OTHER data
Marc Storck
Ok, so there is not method to point the Zone-apex to a dynamic IP other then
using nsupdate... do there exist good and end-user-readable how-to s?
Thanks,
Marc
-----Message d'origine-----
De : Kevin Darcy <k...@daimlerchrysler.com>
À : bind-...@isc.org <bind-...@isc.org>
Date : Mittwoch, 16. Mai 2001 00:51
Objet : Re: CNAMES and OTHER data
>
>GraniteCanyon apparently was helping you by translating that name into an
>address, but I doubt that they gave any guarantee that the address would
>automatically update if the underlying name was re-addressed. So it
probably
>never really was an "alias" in any meaningful sense of the term.
>
>In any case, it is not RFC-legal to point an A record at a name or for a
>zone-apex name to own a CNAME record. Your *only* option here is for the
>zone-apex name to own an A record pointing directly to the desired address.
>
>
>- Kevin
>
>Marc Storck wrote:
>
>> Hmmm..... sometime in the past I used granitecanyon.com as DNS provider
and
>> I used wonders.net as host...
>>
>> while wonders.net was experimental and had a dynamic IP, we added the
>> following to the Zone we had at GraniteCanyon:
>>
>> $ORIGIN sample.domain
>>
>> @ IN A wonders.dyn.ml.org
>> (I forgot to mention Wonders.net used Monolith for Static Host to Dynamic
>> IP)
>> I didn't have any real experience with DNS so I wasn't aware it was
>> "illegal/incorrect", but I worked during our 2-3 months of experimental
>> service...
>>
>> Now I'm stuck at the same point, I have/want to point a zone-apex to
another
>> hostname.....
>>
>> any Ideas?
>>
>> I thought of using nsupdate but I don't see a way how I can restrict
access
>> to one zone only.... or how I can give different clients access to only
>> their zone.....
>>
>> Best Regards,
>>
>> Marc
>>
>> -----Message d'origine-----
>> De : Kevin Darcy <k...@daimlerchrysler.com>
>> À : bind-...@isc.org <bind-...@isc.org>
>> Date : Dienstag, 15. Mai 2001 23:47
>> Objet : Re: CNAMES and OTHER data
>>
>> >
>> >You took me too literally. You can't point an A record at a name. But
you
>> can
>> >change the record type to "A" *and* change the name on the right-hand
side
>> to
>> >whatever address the name resolves to.
>> >
>> >
>> >- Kevin
>> >
>> >Marc Storck wrote:
>> >
>> >> Hello Kevin,
>> >>
>> >> my BIND 8.2.3T9B does not accept an IN A record which is pointing to
FQDN
>> >> instead of an IP, does yours work???
>> >>
>> >> Marc
>> >>
>> >> >No, there is no workaround; only a fix. Replace that CNAME with an A
>> record
>> >> >and/or whatever other records you want to be owned by "foo.com".
>> >> >
>> >> >Why do you find it "strange" for a zone-apex name to own an A record?
>> >> >Zone-apex names own MX records all of the time. How is owning an A
>> record
>> >> >fundamentally different from that?
>> >> >
>> >> >
>> >> >- Kevin
>> >> >
>> >> >Marc Storck wrote:
>> >> >
>> >> >> Thanks Charles,
>> >> >>
>> >> >> I just put them there to make it evident that the 3 records are for
>> the
>> >> >> ORIGIN.
>> >> >> The main question is: Is there a work-around the CNAME and OTHER
data
>> >> >> error???
>> >> >>
>> >> >> And I would like to apologize to the list that my first message
came
>> in 3
>> >> >> times, but I got some problems with my mailer, which are now
resolved.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> Marc
>> >> >>
>> >> >> -----Message d'origine-----
>> >> >> De : Charles Bodley <Bod...@tflogic.com>
>> >> >> À : 'Marc Storck' <mst...@ibone.org>
>> >> >> Date : Dienstag, 15. Mai 2001 21:05
>> >> >> Objet : RE: CNAMES and OTHER data
>> >> >>
>> >> >> >I'm not positive but I don't think the second and third @'s are
>> >> necessary.
>> >> >> >
>> >> >> >-----Original Message-----
>> >> >> >From: bind-use...@isc.org
[mailto:bind-use...@isc.org]On
>> >> >> >Behalf Of Marc Storck
>> >> >> >Sent: Tuesday, May 15, 2001 1:12 PM
>> >> >> >To: bind-...@isc.org
>> >> >> >Subject: CNAMES and OTHER data
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >Hello,
>> >> >> >
>> >> >> >I would like to know if there is a workaround for this illegal
case:
>> >> >> >
>> >> >> >$ORIGIN foo.com
>> >> >> >
>> >> >> >@ IN SOA ........
>> >> >> >@ IN NS ns1.foo.com.
>> >> >> >@ IN CNAME foo.net.
>> >> >> >
>> >> >> >This gives a "CNAMES and OTHER data" error but is there a
workaround.
>> >> >> >
>> >> >> >Some BIND versions did allow:
>> >> >> >
>> >> >> >$ORIGIN foo.com
>> >> >> >
>> >> >> >@ IN SOA ........
>> >> >> >@ IN NS ns1.foo.com.
>> >> >> >@ IN A foo.net. ;very strange but it worked!!!!
>> >> >> >
>> >> >> >Thanks,
>> >> >> >
>> >> >> >Marc
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >> >
>> >> >
>> >
>> >
>> >
>> >
>
>
>
>
Kevin Darcy
It's really not that hard:
% nsupdate -d -k/path/to/TSIG/key/files
> update delete foo.com a
>
(a bunch of verbose debugging output from nsupdate)
> update add foo.com 14400 a 1.2.3.4
>
(more verbose debugging)
The TTL could be anything you want of course. That's a BIND 9 command line --
for BIND 8, the syntax would be slightly different. It's possible to do this
without TSIG-authentication, but that would be less secure. You probably
wouldn't need any prerequisites if your client is the only one updating that
particular record.
On the server, you'd need:
zone "foo.com" {
type master;
file "foo.com"; // or whatever you wish
allow-update { foo-update.; }; // you can call the key anything you want
// but you need to define it in a key { } statement
// and the client needs to use the same key name
};
Without TSIG-authentication, the best you can do is authenticate by source
IP address.
Note that once you enable Dynamic Update on the zone, you have to make *all* of
the changes to the zone via Dynamic Update.
- Kevin
P.S. Just out of curiosity, what causes your mailer to emit dates in German but
other header elements in French? I don't think I've ever seen that before.