norecursion on external zone, but how do I allow CNAMEs to be fully resolved?
So I'm been having dns issues for a while, differing issues that pop up and I knock them down , but another just came to my attention which has me stumped. My external zone config has allow-recursion ( none; ); However I have some 3rd party sites that I CNAME too. Akamai for example, yes CNAME to CNAME , i know I know :).. Well my primary NS servers will only provide the CNAME record: ;; QUESTION SECTION: ;cdn.domain.net.IN A ;; ANSWER SECTION: cdn.domain.net. 300 IN CNAME cdn.domain.net.edgesuite.net. This causes all types of failures if just using dig, or Linux built in lookup mechanism, or heck Perl or PHP methods as well. None of the stated methods, know that they should now query cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAIL or whatever. Is there a way to allow any host to actually do a recursive lookup if the request starts out on my domain, in order to receive the A record? Or do I just have to enable recursion on my external zone? The problem there obviously, is now joe and frank can use my dns servers because it performs a bit better than their ISP's. I don't want that, but I do want to provide the extended information for that CNAME record. Oh ya still on "bind-9.7.2-P3" , fedora based system I'm missing something, but since it's gosh knows who that will be querying for cdn.domain.net there really is no ACL I can use, it has to be all. And based on some failures, I have to do the leg work for each client, i have to provide them the necessary information in that one request. Thanks again Tory ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
Implementation specific, probably, but with Bind it's the authoritative part that wins ! (assuming the caching name server is DNSSEC enabled, possibly even validating DNSSEC, then) If Bind is caching for all, but authoritative for some domains (I think this is called : "bogus for some domains"), a query for something in those domains where it is bogus, gets a reply with "AA" set. This regardless of the fact if the official/public domain has or has no DNSSEC information itself. --> so, the bogus name server will produce acceptable results (yes, we - the Internet community - has been doing this for years, make our caching name server bogus for our own public domains) But the problem is for "validating resolvers" (like validating forwarding name server), that use this name server : because the validating resolver asks for DS records, because the DS records are in the *parent* zone, the validating resolver gets DS records (for public, signed, domains) and will *insist* on replies it can validate (signed with correct key). If the "bogus" domain is not signed, that will fail ... (cfr http://www.eurid.eu/files/Insights_DNSSEC2.pdf, combine info on pages 15+16 (bogus NS) and 17+18 (forwarding NS) ) Kind regards, Marc Lampo Security Officer EURid -Original Message- From: Matthew Pounsett [mailto:m...@conundrum.com] Sent: 20 May 2011 06:49 AM To: Carlos Vicente Cc: bind-users@lists.isc.org Subject: Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses On 2011-05-20, at 00:35, Carlos Vicente wrote: > That's news to me. What's the failure mode? Does the server return SERVFAIL, or does it not set the AD flag, or...? It's another undefined condition in the RFCs, and so the outcome is implementation specific. I believe in the case of BIND the authoritative algorithm wins out, and so you get RRSIGs and no AD flag. I haven't tested this one out personally, but I vaguely recall the problem coming up on one of the DNS operations lists several months ago, so someone else may have a more detailed answer. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
On 05/20/2011 05:56 AM, Matthew Pounsett wrote: If, for some reason, you can't wait for your TTLs to expire, then forwarding the relevant zones to your authoritative servers is a better solution than slaving the zones. How? The whole point of stealth slaving is timely (NOTIFY/IXFR) updates of the data the "recursive" resolver will reply with. Waiting for $TTL is not timely in most cases. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: norecursion on external zone, but how do I allow CNAMEs to be fully resolved?
On 05/20/2011 07:16 AM, Tory M Blue wrote: This causes all types of failures if just using dig, or Linux built in lookup mechanism, or heck Perl or PHP methods as well. None of the stated methods, know that they should now query cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAIL or whatever. That's because stub resolvers are not recursive resolvers. No-one should be querying your authoritative servers unless they are themselves a full recursive resolver, and those will handle this situation just fine. Serving A records for other zones isn't valid anyway - for security reasons they'll be ignored (after all, you could be trying to poison the far end cache, and are not authoritative for the zones containing the CNAME target) Can you give more info about how this is causing actual problems, versus problems with dig/perl/whatever? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: norecursion on external zone, but how do I allow CNAMEs to be fully resolved?
On 19.05.11 23:16, Tory M Blue wrote: > My external zone config has allow-recursion ( none; ); > > However I have some 3rd party sites that I CNAME too. Akamai for > example, yes CNAME to CNAME , i know I know :).. > > Well my primary NS servers will only provide the CNAME record: > > ;; QUESTION SECTION: > ;cdn.domain.net. IN A > > ;; ANSWER SECTION: > cdn.domain.net. 300 IN CNAME cdn.domain.net.edgesuite.net. > > This causes all types of failures if just using dig, or Linux built in > lookup mechanism, or heck Perl or PHP methods as well. None of the > stated methods, know that they should now query > cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAIL > or whatever. > > Is there a way to allow any host to actually do a recursive lookup if > the request starts out on my domain, in order to receive the A > record? I doubt so. Even if there was, clients should not trust those responses. Clients just have to find out about cdn.domain.net.edgesuite.net themselves. > Or do I just have to enable recursion on my external zone? The > problem there obviously, is now joe and frank can use my dns servers > because it performs a bit better than their ISP's. I don't want that, > but I do want to provide the extended information for that CNAME > record. That wouldn't help. They will use your server for all queries (you don't want that) or they use their isp's server for all queries, and it will not trust your server about cdn.domain.net.edgesuite.net. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. We are but packets in the Internet of life (userfriendly.org) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: norecursion on external zone, but how do I allow CNAMEs to be fully resolved?
This is why people run separate views, separate instances, or separate devices for DNS resolution (= recursive, by necessity) versus DNS hosting (= non-recursive, best practice). If you run both hosting and resolution on the same nameserver instance but different views, you may need to be a little careful about how you resolve names in your own zones (don't recurse to the same view otherwise you may end up in an infinite loop situation!), and especially if you're publishing a NAT'ed address for your nameserver(s). Within named.conf, you can limit recursive resolution by client address or by view. You can't limit it by zone, because, on deeper analysis, that actually doesn't make any sense anyway -- either you are authoritative for a given zone, in which case no recursion is necessary, or you're not authoritative, in which case recursive resolution is *always* necessary. - Kevin On 5/20/2011 2:16 AM, Tory M Blue wrote: So I'm been having dns issues for a while, differing issues that pop up and I knock them down , but another just came to my attention which has me stumped. My external zone config has allow-recursion ( none; ); However I have some 3rd party sites that I CNAME too. Akamai for example, yes CNAME to CNAME , i know I know :).. Well my primary NS servers will only provide the CNAME record: ;; QUESTION SECTION: ;cdn.domain.net.IN A ;; ANSWER SECTION: cdn.domain.net. 300 IN CNAME cdn.domain.net.edgesuite.net. This causes all types of failures if just using dig, or Linux built in lookup mechanism, or heck Perl or PHP methods as well. None of the stated methods, know that they should now query cdn.domain.net.edgesuite.net, so they provide the CNAME and SERVFAIL or whatever. Is there a way to allow any host to actually do a recursive lookup if the request starts out on my domain, in order to receive the A record? Or do I just have to enable recursion on my external zone? The problem there obviously, is now joe and frank can use my dns servers because it performs a bit better than their ISP's. I don't want that, but I do want to provide the extended information for that CNAME record. Oh ya still on "bind-9.7.2-P3" , fedora based system I'm missing something, but since it's gosh knows who that will be querying for cdn.domain.net there really is no ACL I can use, it has to be all. And based on some failures, I have to do the leg work for each client, i have to provide them the necessary information in that one request. Thanks again Tory ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
So, if I understand you correctly, if I were to sign my authoritative zone and my caching nameserver, which is "bogus" for this zone, is dnssec enabled, and also validating, and no other validating nameserver is querying this bogus nameserver, then it's OK? cv On Thu, May 19, 2011 at 11:16 PM, Marc Lampo wrote: > Implementation specific, probably, but with Bind it's the authoritative > part that wins ! > > (assuming the caching name server is DNSSEC enabled, possibly even > validating DNSSEC, then) > > If Bind is caching for all, > but authoritative for some domains (I think this is called : "bogus for > some domains"), > a query for something in those domains where it is bogus, > gets a reply with "AA" set. > This regardless of the fact if the official/public domain has or has no > DNSSEC information itself. > --> so, the bogus name server will produce acceptable results > (yes, we - the Internet community - has been doing this for years, > make our caching name server bogus for our own public domains) > > But the problem is for "validating resolvers" (like validating forwarding > name server), > that use this name server : > because the validating resolver asks for DS records, > because the DS records are in the *parent* zone, > the validating resolver gets DS records (for public, signed, domains) > and will *insist* on replies it can validate (signed with correct key). > If the "bogus" domain is not signed, that will fail ... > > (cfr http://www.eurid.eu/files/Insights_DNSSEC2.pdf, > combine info on pages 15+16 (bogus NS) and 17+18 (forwarding NS) > ) > > Kind regards, > > Marc Lampo > Security Officer > EURid > > > ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
> If, for some reason, you can't wait for your TTLs to expire, then forwarding > the relevant zones to your authoritative servers is a better solution than > slaving the zones. > But the server that is forwarding to the authoritative also caches the response, so that won't help. I'm looking for something like a 'no-cache' option to put inside a zone definition of type "forward", but I can't find it. cv ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-keygen with different activation date
I found this on our list: https://lists.isc.org/mailman/htdig/bind-users/2010-April/079653.html Made more sense. :) On 05/20/2011 08:41 PM, Noel Rocha wrote: Hello, I don't know if this is a problem ... but I found strange: # date on server: $ date Fri May 20 20:31:23 BRT 2011 # key will be activated at 2011/05/20 20:35:00 $ dnssec-keygen -r '/dev/urandom' -a RSASHA1 -b 2048 -n ZONE -A 20110520203500 'mydomain.com' Kmydomain.com.+005+48738 # Showing activate date $ cat Kmydomain.com.+005+48738.key | grep Activate ; Activate: 20110520203500 (Fri May 20 17:35:00 2011) This (20110520203500)2011/05/20 20:35:00 isn't "Fri May 20 17:35:00 2011." :( Anyone have idea how to solve this problem? Thanks in advance, Noel Rocha ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec-keygen with different activation date
Hello, I don't know if this is a problem ... but I found strange: # date on server: $ date Fri May 20 20:31:23 BRT 2011 # key will be activated at 2011/05/20 20:35:00 $ dnssec-keygen -r '/dev/urandom' -a RSASHA1 -b 2048 -n ZONE -A 20110520203500 'mydomain.com' Kmydomain.com.+005+48738 # Showing activate date $ cat Kmydomain.com.+005+48738.key | grep Activate ; Activate: 20110520203500 (Fri May 20 17:35:00 2011) This (20110520203500)2011/05/20 20:35:00 isn't "Fri May 20 17:35:00 2011." :( Anyone have idea how to solve this problem? Thanks in advance, Noel Rocha ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses
In message , Carlos Vicente writes: > > If, for some reason, you can't wait for your TTLs to expire, then > > forwarding the relevant zones to your authoritative servers > is a better solution than slaving the zones. > > > > But the server that is forwarding to the authoritative also caches the > response, so that won't help. I'm looking for something like a > 'no-cache' option to put inside a zone definition of type "forward", > but I can't find it. There isn't one. > cv > ___ > 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec-keygen with different activation date
On May 20, 2011, at 4:41 PM, Noel Rocha wrote: > # Showing activate date > $ cat Kmydomain.com.+005+48738.key | grep Activate > ; Activate: 20110520203500 (Fri May 20 17:35:00 2011) > > This (20110520203500)2011/05/20 20:35:00 isn't "Fri May 20 17:35:00 2011." :( > > Anyone have idea how to solve this problem? There isn't a problem: 20:35 GMT is 17:35 BRT. As a general rule, ISC software stores timestamps in GMT rather than in the local timezone to avoid all sorts of nonportable painful issues with local timezone conversions. Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
