Proper CNAME interpretation
Last night, it appeared to me that nslookup was resolving the name graphiteops.com to IP address 72.52.4.95. Today however it is no longer doing that, reporting instead: % 127.0.0.1 Address:127.0.0.1#53 Non-authoritative answer: graphiteops.com canonical name = graphiteops.com. Given what I see in the dig output (see below) I think that today's results are more ``correct'', but frankly, I'm not at all sure. Is there a rule that says how a resolver should behave in cases where there is both an A record and also a CNAME record for the same FQDN? Which one should take precedence, the A or the CNAME? = % dig graphiteops.com any ; DiG 9.5.0-P2 graphiteops.com any ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 52447 ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 6, ADDITIONAL: 4 ;; QUESTION SECTION: ;graphiteops.com. IN ANY ;; ANSWER SECTION: graphiteops.com.21600 IN MX 0 mx.graphiteops.com.cust.b.hostedemail.com. graphiteops.com.3600IN SOA pdns1.ultradns.net. tech.synthasite.com. 2011060500 10800 3600 2592000 86400 graphiteops.com.21600 IN A 72.52.4.95 graphiteops.com.3600IN CNAME graphiteops.com. graphiteops.com.86400 IN NS pdns2.ultradns.net. graphiteops.com.86400 IN NS pdns1.ultradns.net. graphiteops.com.86400 IN NS pdns5.ultradns.info. graphiteops.com.86400 IN NS pdns3.ultradns.org. graphiteops.com.86400 IN NS pdns4.ultradns.org. graphiteops.com.86400 IN NS pdns6.ultradns.co.uk. ;; AUTHORITY SECTION: graphiteops.com.86400 IN NS pdns5.ultradns.info. graphiteops.com.86400 IN NS pdns1.ultradns.net. graphiteops.com.86400 IN NS pdns6.ultradns.co.uk. graphiteops.com.86400 IN NS pdns4.ultradns.org. graphiteops.com.86400 IN NS pdns2.ultradns.net. graphiteops.com.86400 IN NS pdns3.ultradns.org. ;; ADDITIONAL SECTION: pdns1.ultradns.net. 81556 IN A 204.74.108.1 pdns1.ultradns.net. 81556 IN 2001:502:f3ff::1 pdns2.ultradns.net. 81556 IN A 204.74.109.1 pdns3.ultradns.org. 81556 IN A 199.7.68.1 ;; Query time: 106 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Sep 14 13:28:22 2011 ;; MSG SIZE rcvd: 500 = ___ 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: Proper CNAME interpretation
On Sep 14, 2011, at 4:35 PM, Ronald F. Guilmette wrote: Is there a rule that says how a resolver should behave in cases where there is both an A record and also a CNAME record for the same FQDN? Which one should take precedence, the A or the CNAME? RFC 1034, Section 3.6.2: If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types. via http://www.bind9.net/BIND-FAQ DNSSEC changes that a little in as much as a node can have an RRSIG with a CNAME, but what good is a rule without an exception? :) ___ 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: Proper CNAME interpretation
In message 7d9b265c-36bf-40c1-9012-ac0a96fb8...@sackheads.org, you wrote: On Sep 14, 2011, at 4:35 PM, Ronald F. Guilmette wrote: Is there a rule that says how a resolver should behave in cases where there is both an A record and also a CNAME record for the same FQDN? Which one should take precedence, the A or the CNAME? RFC 1034, Section 3.6.2: If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types. Thanks for the response John. So, um, the first part of that just says what people should not be doing when they are constructing sets of RRs applicable to a given domain name. But we all know that, right? We know you are not supposed to put a CNAME with other stuff for the same domain. 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? 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? Not that I would want to deviate from common established practice... if in fact ignoring flotsam jetsum that appears with a CNAME is the common practice. I'd just like to be able to defend the rightness of my code... RFC-wise... in case anybody ever presses me and says Why did you do THAT??, you know, after I tell them that my code ignores flotsam jetsum that appears along side a CNAME. Regards, rfg ___ 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: 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
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: Proper CNAME interpretation
On 9/14/2011 5:52 PM, Chuck Swiger wrote: 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.' Indeed. It should be noted that not only does the graphiteops.com name break the CNAME and other rule, but it's a *self-referential* CNAME (rdata = graphiteops.com), so if one tried to chase it, one could chase infinitely. This is, presumably, what RFC 1034 calls a CNAME loop, and according to that document (Of course, by the robustness principle, domain software should not fail when presented with CNAME chains or loops; CNAME chains should be followed and CNAME loops signalled as an error) I would have expected nslookup and/or dig to have error'ed out when encountering this. Are those utilities not considered domain software? Hard to know, since neither 1034 nor 1035 define that term... - Kevin ___ 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