CNAME pointing to external host names problem

[heaven.k3y]

Hi,
I have a problem with CNAME record in GDNSD. I wish to have local names point to external entries with CNAME records. For example, it may be desirable to have the shortcut "google" for "www.google.com". One way one may wish to do this is as follows:

google.example.com. +86400 CNAME www.google.com.

I expect GDNSD to output the following for "google.example.com":
   

google.example.com. +86400 CNAME www.google.com.
www.google.com. +900 A 66.102.7.104

But GDNSD simply outputs:

google.example.com. +86400 CNAME www.google.com.

I can't point to external entries in another zonefile. Do you have any solution for me?
Thanks!

[Brandon Black]

On Wed, Oct 30, 2013 at 5:15 AM, heaven.k3y via gdnsd <gdnsd+noreply-APn2wQcqUHlFuCC0SE...@googlegroups.com> wrote:

I can't point to external entries in another zonefile. Do you have any solution for me?

Given your examples, I'm not sure which of three distinct cases you're talking about, so I'll just go over them all.  But the bottom line is that this is the intended and correct behavior.

1) Out-of-zone "glue" for a CNAME: If you're actually putting an A-record for "www.google.com." in your zonefile for "example.com", gdnsd will ignore that as an unused glue address (and warn about the unused glue, I believe).  The only reason gdnsd accepts an out-of-authority record like that in a zonefile (or serves it to the world) is for the special case of delegation glue.

2) Expecting gdnsd to cache: If you're not putting an A-record for "www.google.com" in your zonefile for "example.com", and your server is also not authoritative for "google.com", then the only way you could get your desired result would be if gdnsd actually queried the servers for "google.com" and cached and relayed the result to the client.  gdnsd doesn't do that.  It's strictly an authoritative-only server - it never queries other servers or caches/relays information from them.

3) Cross-zone CNAME between local zones: If the intent in your example was that your server is authoritative for and has separate zonefiles for both "example.com" and "google.com", then this is simply a cross-zone CNAME between unrelated but locally-authoritative zones.  Again, gdnsd doesn't do that, but I won't go so far as to say that it's completely wrong to do so.  In a very basic sense, the reason it's wrong to return the cross-zone data is because a secure cache shouldn't believe any data it gets for "google.com" from an "example.com" server, and there's no point intentionally designing to make life easier for insecure caches.

When "google.com" and "example.com" happen to share an authoritative server it's no longer technically "wrong" for a secure cache to accept and believe your "google.com" record in an "example.com" response, *if* the cache had enough information/awareness to be able to take advantage of that optimization (reduction of query traffic) securely.  It certainly couldn't have that information ready on-hand in a cold cache situation (it would still need to at least query back up the chain at the .com servers and ask who's authoritative for "google.com" first), but a smart implementation might retain the ability to cross-reference cached nameserver IPs and "realize" that the two domains are both served by the server being queried and that it can believe the mixed-zone response, at least when such information is already available in the cache itself.

For the time being, it has made life simpler for gdnsd to ignore this potential optimization and always keep a simple wall between all local zones, never returning cross-zone data.  I'm willing to revisit that design decision and incorporate cross-zone records in cases like these (there are other similar cases, such as MX->A crossing zone boundaries within a set of local zones, for example), but before adding that complexity to gdnsd I'd probably want to see some proof that there are optimizing recursors/caches out there in the world that are smart enough to take advantage of it in a secure way.  If they have, please point me at the code and I'll stop using the excuse that nobody's optimizing for this case in the caches :)

-- Brandon

[heaven.k3y]

Thank you for your help. I'll research more about this issue.

On Wednesday, October 30, 2013 8:08:37 PM UTC+7, blblack wrote:

[heaven.k3y]

Hi blblack,
I have just put a NS record:

*.dyndns                NS     dyndns.example.com.

and GDNSD throw error:

Name '*.dyndns.': Cannot delegate via wildcards

Please tell me about what wrong with my zonefile? Can i use wildcards with a NS record?

Thanks!

[Brandon Black]

On Thu, Oct 31, 2013 at 5:04 AM, heaven.k3y via gdnsd <gdnsd+noreply-APn2wQcqUHlFuCC0SE...@googlegroups.com> wrote:

Hi blblack,
I have just put a NS record:

*.dyndns                NS     dyndns.example.com.

and GDNSD throw error:

Name '*.dyndns.': Cannot delegate via wildcards

Please tell me about what wrong with my zonefile? Can i use wildcards with a NS record?

I really don't know what you're trying to do, so it's hard to offer advice on how to accomplish it.  Do you have a nameserver with the hostname dyndns.example.com, which you wish to delegate the subdomain of the same name to?  In that case, get rid of the wildcard.  In most normal use-cases, wildcard NS records simply don't make sense, and in the cases where they do make sense, the server you're delegating the queries to would have to be some special implementation that thinks it is authoritative for all possible subzones being delegated to it and responds appropriately with synthesized NS records, etc.

If you're sure you know what you're doing and you really want delegation-via-wildcard support, that's another matter entirely.  You can see some discussion of the issue in the wildcard RFC here: http://tools.ietf.org/html/rfc4592#section-4.2  .  In brief: Wildcard NS records are not illegal in the DNS, but they do have poorly defined semantics in some corner cases.  Notably they're not very compatible with DNSSEC, either, but then again gdnsd doesn't currently implement DNSSEC anyways.  There are other non-DNSSEC issues, though, and I thought it prudent to avoid the whole issue and disallow them for the time being.  If you, as a user, have a legitimate need for them that you can express in technical terms, the feature can be added, perhaps with some warnings emitted when it's used, and/or a config option to enable it.  Please explain the use-case, though, so that I have some idea what's being done and that there isn't an easier legitimate method of accomplishing the same.

-- Brandon

[Jayen]

Hi Brandon,

I'm new to gdnsd and I think I'm having an issue similar to this thread, but I don't understand how to fix it.  I'm trying to move my DNS from godaddy to gdnsd and am in the process of massaging my zone file to work with gdnsd.  My current problem is:

mail    14400   IN      CNAME   mx01.d2networks.net.
@       14400   IN      MX      0       mail

In rrset 'skedgo.com. MX', same-zone target 'mail.skedgo.com.' has no addresses

The mail server for this domain is outside my control, and I would prefer to use an CNAME record, although gdnsd seems happy with an A record.  Can I use a CNAME for the MX?

Thanks,
Jayen

[blblack]

On Tuesday, December 17, 2013 12:23:20 AM UTC-6, Jayen wrote:

mail    14400   IN      CNAME   mx01.d2networks.net.
@       14400   IN      MX      0       mail

In rrset 'skedgo.com. MX', same-zone target 'mail.skedgo.com.' has no addresses

The mail server for this domain is outside my control, and I would prefer to use an CNAME record, although gdnsd seems happy with an A record.  Can I use a CNAME for the MX?

I believe the message you're getting is just a warning, so you *can* just ignore it and it will serve the data (unless you're setting zones_strict_data which is new in 1.11.0 - or perhaps if you're on a very old version, it might have been a hard error back then?), assuming that works for you.

But that aside, it's not a good idea to point an MX at a CNAME, which is why the warning is there.  The relevant RFCs are pretty clear on this matter (e.g. RFC2181 section 10.3, which is just a clarification of earlier RFCs saying the same thing).  If I were you, I would just take the "mail" CNAME out of the MX chain, and do:

@ 14400 MX 0 mx01.d2networks.net.

If you also need the "mail" hostname for other convenience purposes, you could still also CNAME it directly:

mail 1440 CNAME mx01.d2networks.net.

[Jayen Ashar]

So gdnsd warns me if I point to my own CNAME, but not someone else's?  (I was setting zones_strict_data, because I'm new to gdnsd and didn't want to screw something up.)

Your suggestion works well, thanks.

--Jayen

--
Jayen Ashar
SysAdmin/Developer @TripGo
"All the ways" http://skedgo.com/

-----Original Message-----
From: gdnsd on behalf of blblack on behalf of blblack via gdnsd
Sent: Sat 21/12/2013 2:08 AM
To: gd...@googlegroups.com
Subject: Re: [gdnsd] Re: CNAME pointing to external host names problem



On Tuesday, December 17, 2013 12:23:20 AM UTC-6, Jayen wrote:

        mail    14400   IN      CNAME   mx01.d2networks.net <http://www.google.com/url?q=http%3A%2F%2Fmx01.d2networks.net&sa=D&sntz=1&usg=AFQjCNF9zpfPsJxrtcqEq598ye3IxCwUzw> .

--
--
http://gdnsd.org/
--
You received this message because you are subscribed to the Google
Groups "gdnsd" group.
To post to this group, send email to gd...@googlegroups.com
To unsubscribe from this group, send email to
gdnsd+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/gdnsd?hl=en
---
You received this message because you are subscribed to the Google Groups "gdnsd" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gdnsd+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Brandon Black]

On Fri, Dec 20, 2013 at 4:24 PM, gdnsd <gd...@googlegroups.com> wrote:

So gdnsd warns me if I point to my own CNAME, but not someone else's?

Correct :)  As a general rule gdnsd never queries other servers - it's a pure authoritative data server.  Even if we did query other servers just to validate things like this, the remote data could change out from under us right after we check it, so it's really up to you to do the sane thing here.  For that matter, gdnsd also doesn't warn about these things when they cross between two separate zonefiles that are both served by your server.  Mostly that's because it would require a bunch of extra state to backtrack those links, given that zones can be updated at runtime independently of each other, possibly generating new warnings related to cross-linked data, or eliminating past ones.

There are many correctness and/or compliance issues with DNS data that really can only be enforced by the zone administrator, rather than the protocol or implementation.  Even within a single zonefile where we can validate all local data at load time, some constraints are situational and we have to allow for some flexibility.