Re: blacklisting replies, was: Proper CNAME interpretation
On Sep 14, 2011, at 5:09 PM, Ronald F. Guilmette wrote: In message cf550bd6-ba85-4cb3-8b03-e4e1b0829...@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.3131IN 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 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/4e7236047d79ee3a740a dig graphiteops.com
Re: blacklisting replies, was: Proper CNAME interpretation
In message 39634800-7e01-4878-b1a1-cf384c8a6...@mac.com, Chuck Swiger cswi...@mac.com wrote: On Sep 14, 2011, at 5:09 PM, Ronald F. Guilmette wrote: In message cf550bd6-ba85-4cb3-8b03-e4e1b0829...@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 thankles s labor worthy of Sisyphus. [1] I have a thought on that which I'd like to share, below. This mailing list seems to be using GNU Mailman, which generally will try to a void sending an extra copy of list traffic if it notices that a recipient is a lso To: or CC:ed directly. Too clever by half. nslookup has been deprecated for some time, because it isn't a particularly go od tool for diagnosing DNS issues. dig is much better. OK. Thanks. I didn't know 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: Hummm... well.. ya know, I haven't upgraded in some time, so I'm gonna chalk this one up to my own laziness. 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. Ah! OK. So I'm not crazy after all! (Well, maybe we had better not jmp to any conclusion until all the facts are in.) 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 h andling this error case correctly. OK. Thanks. I feel better already... I think. At least I know now that the goofyiness is not all on my end of the wire. [1]: Yes, I know at least some of the folks who handle IST communication serv ices like email-- including postmaster@ and abuse@-- for various Apple domains Unfortunately so do I, and at least one of them thinks that running mailing lists with no new subscriber confirmation step is just peachy. I disagree. So it's not a matter of finding them; yes, they care; Care is a relative term. The admins or the management at mac.com apparently don't care enough to implement the kind of outbound per-account rate limiting that would prevent me from ever seeing spam from one of their spammer customers. I also care about people being murdered on a daily basis in Darfur. I just don't spend a lot of my day doing anything about it kinda like the admins @ mac.com and outbound spam. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
blacklisting replies, was: Proper CNAME interpretation
Sigh: your mail server is blacklisting email from mac.com. Begin forwarded message: From: postmas...@mac.com Date: September 14, 2011 2:53:05 PM PDT To: cswi...@mac.com Subject: Delivery Notification: Delivery has failed This report relates to a message you sent with the following header fields: Message-id: 2be47d87-8417-4055-8466-f47cd7fdb...@mac.com Date: Wed, 14 Sep 2011 14:52:34 -0700 From: Chuck Swiger cswi...@mac.com To: Ronald F. Guilmette r...@tristatelogic.com Subject: Re: Proper CNAME interpretation Your message cannot be delivered to the following recipients: Recipient address: r...@tristatelogic.com Reason: Remote SMTP server has rejected address Diagnostic code: smtp;550 5.7.1 asmtpout025.mac.com: Helo command rejected: Domain mac.com BLACKLISTED - Use http://www.tristatelogic.com/contact.html Remote system: dns;server1.tristatelogic.com (TCP|17.148.16.100|49837|69.62.255.118|25) (segfault.tristatelogic.com ESMTP Postfix [2.5.3]) Reporting-MTA: dns;asmtp025-bge351000.mac.com (tcp-daemon) Arrival-date: Wed, 14 Sep 2011 14:52:35 -0700 (PDT) Original-recipient: rfc822;r...@tristatelogic.com Final-recipient: rfc822;r...@tristatelogic.com Action: failed Status: 5.7.1 (Remote SMTP server has rejected address) Remote-MTA: dns;server1.tristatelogic.com (TCP|17.148.16.100|49837|69.62.255.118|25) (segfault.tristatelogic.com ESMTP Postfix [2.5.3]) Diagnostic-code: smtp;550 5.7.1 asmtpout025.mac.com: Helo command rejected: Domain mac.com BLACKLISTED - Use http://www.tristatelogic.com/contact.html From: Chuck Swiger cswi...@mac.com Date: September 14, 2011 2:52:34 PM PDT To: Ronald F. Guilmette r...@tristatelogic.com Cc: bind-users@lists.isc.org Subject: Re: Proper CNAME interpretation 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. 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. If you asked for an record, and got that same reply of a CNAME and an A record, then the resolver should chase the CNAME's data field. 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. But is that encourage- ment espressed anywhere as a MUST? By no means. You only ought to chase a CNAME if you got a CNAME *instead* of the resource type that you asked for. Regards, -- -Chuck ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: blacklisting replies, was: Proper CNAME interpretation
In message cf550bd6-ba85-4cb3-8b03-e4e1b0829...@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.3131IN 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 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. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
