Re: Proper CNAME interpretation
In message 7737.1316035...@tristatelogic.com, Ronald F. Guilmette writes: 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? You get indeterminate behaviour. 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? The second sentence is saying if you have a CNAME record in the cache and don't have the type you are looking for you just follow the CNAME. If you don't do this the resolver would have to make a two queries. One to the authoritative server for the missing type which will normally result in the CNAME being returned and one for the target of the CNAME. 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 appear s along side a CNAME. In this case you also have a CNAME that points to itself which is also a error condition. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
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
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
