Hi, Simon,
Thanks for the detailed explanation. I think I understand now!
But would it not be possible achieve roughly the same functionality
within the dnsmasq architecture (without using CNAMEs) if there were
some sort of configuration option that says a lookup of "foo" should
always be proxied to the upstream server(s) as a lookup of "bar"
instead? (Kind of a name based version of the --alias option instead of
the current IP based version?)
Merlin
Simon Kelley wrote:
Merlin wrote:
Can dnsmasq serve up locally defined CNAME records?
As an example, for a query of "ntp", I'd like to have dnsmasq return
a CNAME record that points to an external NTP server by
*name*--rather than defining "ntp" to return an A record by hard
coding it with an IP address in /etc/hosts or an 'address' config
line. This would be especially useful if the CNAME refers to a pool
of addresses (such as pool.ntp.org).
I've dug through the dnsmasq documentation and source and I can't
find this. Which actually surprises me because dnsmasq already
supports almost every other DNS record type and feature one can imagine!
It doesn't support CNAME, because it wouldn't work to do so. The
reason is a bit complicated, I'll try to explain,
The architecture of dnsmasq is really that of a forwarder/proxy, with
the extra, local records added. When a DNS query arrives, dnsmasq has
two choices, it can answer the query from locally known information,
or it can forward the query, unaltered, to an upstream nameserver.
What can't be done it to break the down the query into constituent
parts, answer some from local info and some from upstream, and then
synthesise a new answer from both sources.
When a a query arrives, dnsmasq could answer it from local
information, and produce an answer
"foo is CNAME pointing to bar"
_however_ if bar is a record that has to come from an upstream server,
there's no way that dnsmasq can add to the answer
"and bar is A record 1.2.3.4"
Now you might think that a client, on receiving the answer
"foo is CNAME pointing to bar"
would then do another query for bar, and all would be well, but that's
not what happens. In the dns protocol, an answer containing _just_ a C
record has a different meaning: it means "The CNAME exists, but the
target it points at doesn't, at least in the class (A, PTR, AAAA etc)
specified by the original query." So the client, on getting the
partial answer from dnsmasq, concludes that the thing it was looking
for doesn't exist, and gives up.
There's really no way around this short of re-writing all of the DNS
section of dnsmasq as a much more heavyweight system.
Cheers,
Simon.
