blacklisting replies, was: Proper CNAME interpretation

[Ronald F. Guilmette]

In message <CF550BD6-BA85-4CB3-8B03-E4E1B0829A1D at mac.com>, you wrote:

>Sigh: your mail server is blacklisting email from mac.com.

Yes.  Sorry about that.  Too much spam from there and no indication
that anybody there gives a damn that that they gush spam.  (If you
find anybody who does care, please le me know via the contact form on
my web site.)

Anyway, on-list replies are OK, I think.  I mean it's not like any of
this is in any way off topic.

>> On Sep 14, 2011, at 2:27 PM, Ronald F. Guilmette wrote:
>>> The second part however seems to go more to my question, which is "What is
>>> the resolver supposed to do when some knucklehead breaks the rules and puts
>>> a CNAME in with some other stuff?"
>> 
>> Depends on which query one issued.  The very next paragraph of RFC-1034 is:
>> 
>> "CNAME RRs cause special action in DNS software.  When a name server
>> fails to find a desired RR in the resource set associated with the
>> domain name, it checks to see if the resource set consists of a CNAME
>> record with a matching class.  If so, the name server includes the CNAME
>> record in the response and restarts the query at the domain name
>> specified in the data field of the CNAME record.  The one exception to
>> this rule is that queries which match the CNAME type are not restarted."

That's just about a clear as mud. :-(
 
>> In other words, if you ask for an A record, and you get back both a CNAME an
>d an A record, then the A record matches and that's what gethostbyname()/getad
>drinfo() or whatever should receive from the resolver.

OK. That much _is_ clear from the above RFC quote.

But then if that _is_ supposed to be true, then why is nslookup all of a
sudden balking and not printing _any_ IP address for graphiteops.com
today?  My local name server has _both_ a CNAME _and_ an A record cached
for that... at least that is what appears to be the case when I check
locally using:

   dig graphiteops.com any @127.0.0.1

When I do that I get back:

   ...
   graphiteops.com.        21131   IN      A       72.52.4.95
   graphiteops.com.        3131    IN      CNAME   graphiteops.com.
   ...

So under these circumstances, nslookup really should be printing out the
address (72.52.4.95) which I just simply do "nslookup graphiteops.com", no?
But it ain't doing that.

Also very puzzling is what I get when I just do:

    dig graphiteops.com a @127.0.0.1

In this case I only get back the CNAME record, and the A record doesn't even
appear in the dig output !?!?!  So what's up with that???

>If you asked for an AAAA
>record, and got that same reply of a CNAME and an A record, then the resolver
>should chase the CNAME's data field.

Yes.  That part makes sense, and is abundantly clear from the RFC passage you
quoted.  In short, I agree, and this is, and has been, an enlightening ex-
change for me.  So thank you for that.

Now, if I can just figure out why my local dig and nslookup seem to be pro-
ducing such nonsensical (and non-standard?) results, I'll be a happy man.

>>> It sure _sounds_ like that second sentence is encouraging any & all people
>>> who are writing resolvers, or other related tools, that they should ignore
>>> any flotsam & jetsum that appear along side a CNAME.
>> ...
>By no means.  You only ought to chase a CNAME if you got a CNAME *instead*
>of the resource type that you asked for.

Yea.  I see now, and understand.  (And thanks again.)

But as I say, my local dig & nslookup _do not_ seem to understand.  In fact
they both seem to be misbehaving rather significantly, and I don't understand
that at all.
 

Regards,
rfg


P.S.  Curiously, I am getting the exact same odd results out of dig, even
when I force it to directly query one of the authoritative servers for the
graphiteops.com domain.  So, for example:

   dig graphiteops.com a @pdns1.ultradns.net

only shows me the CNAME... no A record!  Whereas:

   dig graphiteops.com any @pdns1.ultradns.net

is showing me both the A and the CNAME.  This part actually makes sense.
I asked for "ANY" so it is sending me (and showing me) everything.  It is
the reslt when I explicitly ask for an `A' however that seems altogether
bizzare and also wrong, based upon what you quoted above.  I am asking
explicitly for an `A' and graphiteops.com clearly _does_ have an `A'
associated with it, so the server should be sending me back the `A'
and keeping the CNAME to itself, no?  But it is doing the exact opposite
of that... sending me back just the CNAME and keeping the `A' to itself.

I get the feeling that there may be something here which is beyond my
comprehension.