blacklisting replies, was: Proper CNAME interpretation

[Chuck Swiger]

On Sep 14, 2011, at 5:09 PM, Ronald F. Guilmette wrote:
> 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.)

Being an RFC-2142 contact for a large domain is a never-ending, often thankless labor worthy of Sisyphus. [1]

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

This mailing list seems to be using GNU Mailman, which generally will try to avoid sending an extra copy of list traffic if it notices that a recipient is also To: or CC:ed directly.  However, if the copy sent directly bounced, then it would be entirely possible that you'd never see the reply, even though the rest of the list would receive it.

>> In other words, if you ask for an A record, and you get back both a CNAME and
>> an A record, then the A record matches and that's what gethostbyname()/getaddrinfo()
>> 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?

nslookup has been deprecated for some time, because it isn't a particularly good tool for diagnosing DNS issues.  dig is much better.

> 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.
>   ...

dig is appears to be doing the right thing, here.  It's returning all of the records which match, and since it does find non-CNAME matches, it doesn't chase the CNAME.

> 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???

I don't see that here; asking for an A record against a local nameserver gives me an A record back:

% dig graphiteops.com a @127.0.0.1

; <<>> DiG 9.6.0-APPLE-P2 <<>> graphiteops.com a @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21530
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 8

;; QUESTION SECTION:
;graphiteops.com.		IN	A

;; ANSWER SECTION:
graphiteops.com.	21593	IN	A	72.52.4.95

;; AUTHORITY SECTION:
[ ... ]

>> 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.

OK.

> 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.

Give up trying to debug DNS using nslookup, and just use dig.

>>>> 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.

I wonder if something changed in the handling of CNAME loops between BIND-9.5 and later versions?

> 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:

You're getting strange results back from pdns1.ultradns.net; it's not dig, it's what they return.

Most of the other nameservers listed as responsible for the domain don't even return the expected glue records indicating that they know that they're authoritative for it, and that CNAME loop causes simple things like looking up the SOA record to give you the CNAME back, instead:

  http://www.dnsvalidation.com/reports/4e7236047d79ee3a7400000a

>   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?

That's right.

> But it is doing the exact opposite of that... sending me back just the CNAME and keeping the `A' to itself.

Yeah.  I don't know what DNS software ultradns.net are running, but it's not handling this error case correctly.

Regards,
-- 
-Chuck

[1]: Yes, I know at least some of the folks who handle IS&T communication services like email-- including postmaster@ and abuse at -- for various Apple domains.  So it's not a matter of finding them; yes, they care; finally, however, no, I'm not motivated to fill out a contact form on your website.