Re: AXFR/IN' denied
On 04/28/2011 04:10 AM, jeffrey j donovan wrote:
master 192.168.1.2
zone mydomain.com {
type master;
file domain.db;
allow-transfer { 192.168.96.3; };
Ok, you have an allow-transfer so this is working.
allow-update {none;};
};
zone 96.168.192.in-addr.arpa {
type master;
file in-arpa-192/REV-NOC.db;
};
zone 97.168.192.in-addr.arpa {
type master;
file in-arpa-192/REV-EDC.db;
};
There is no allow-transfer on these two zones, so they are failing.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND error: opcode: QUERY, status: SERVFAIL
goelexports.com is delegated to the following nameservers which do not exist. kshitij : may i know how you checked the delegation for the above domain Regards, Kshitij On Wed, Apr 27, 2011 at 7:17 PM, Mark Andrews ma...@isc.org wrote: In message banlktik70mdfrhcbfi+7ye_sibccoge...@mail.gmail.com, kshitij mali w rites: Hi everbody , we are unable to lookup the domain goelexports.com goelexports.com is delegated to the following nameservers which do not exist. Mark goelexports.com.172800 IN NS ns.hostsearchindia.com. goelexports.com.172800 IN NS ns2.hostsearchindia.com. ; DiG 9.6.0-APPLE-P2 ns.hostsearchindia.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 36873 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;ns.hostsearchindia.com.IN A ;; AUTHORITY SECTION: hostsearchindia.com.10719 IN SOA ns4.webcomindia.net. amit.sood.webcomindia.net. 2009090712 86400 7200 360 86400 ;; Query time: 2 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Apr 27 23:45:38 2011 ;; MSG SIZE rcvd: 105 [root@D1OKH680RL ~]# dig goelexports.com ; DiG 9.2.4 goelexports.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 63082 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;goelexports.com. IN A ;; Query time: 10 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Apr 27 03:28:13 2011 ;; MSG SIZE rcvd: 33 what does status: SERVFAIL means how can check Regards, kshitij --0016e6d96f657794a304a1e56815 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable div=A0/div divHi everbody ,/div div=A0/div divwe are unable to lookup the domain quot;a href=3D http://goelexports= .comgoelexports.com/aquot;/div div=A0/div div p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= [root@D1OKH680RL ~]# dig a href=3Dhttp://goelexports.com; goelexports.co= m/a/span/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= ; lt;lt;gt;gt; DiG 9.2.4 lt;lt;gt;gt; a href=3D http://goelexport= s.comgoelexports.com/abr ;; global options:=A0 printcmdbr;; Got answer:br;; -gt;gt;HEADERlt;= lt;- opcode: QUERY, statusspan style=3DBACKGROUND: yellow; mso-highlight:= yellow: SERVFAIL/span, id: 63082br;; flags: qr rd ra; QUERY: 1, ANSW= ER: 0, AUTHORITY: 0, ADDITIONAL: 0/span/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= ;; QUESTION SECTION:br;a href=3Dhttp://goelexports.com; goelexports.co= m/a.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 IN=A0=A0=A0=A0=A0 A/span= /p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= ;; Query time: 10 msecbr;; SERVER: 127.0.0.1#53(127.0.0.1)br;; WHEN: W= ed Apr 27 03:28:13 2011br ;; MSG SIZE=A0 rcvd: 33/span/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= /span=A0/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= /span=A0/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= what does status: SERVFAIL means how can check/span/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= /span=A0/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= Regards,/span/p p style=3DMARGIN: 0in 0in 0pt class=3DMsoNormalspan style=3DFONT-FA= MILY: #39;Tahoma#39;,#39;sans-serif#39;; COLOR: black; FONT-SIZE: 10pt= kshitij/span/p/div --0016e6d96f657794a304a1e56815-- --===2533559258763338727== Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users --===2533559258763338727==-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?
Assuming a case where there is an empty CNAME chain, but no error, [...] ... ;; ANSWER SECTION: www.apple.com. 281 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.net. ... As a matter of terminology, in the quoted example, I see a chain of three CNAME records. That's not what I would call an empty CNAME chain. What I do see, though, is a CNAME chain of three CNAME records, but where the ultimate target of the CNAME chain exists, but does not have any data of the requested type. Therefore, in the DNS you get a NOERROR status code, and an answer section which does not contain any records of the requested type. Now... should getaddrinfo() return EAI_NONAME or EAI_FAIL? RFC 3493 says: [EAI_NONAME]The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. Which means that it should probably return EAI_NONAME; it's the least bad error code among the ones listed in RFC 3493 for getaddrinfo(), although one should not be mislead to think that this means that the DNS said NXDOMAIN. Between RFC 2553 and its follow-on RFC 3493, it appears that the EAI_NODATA error code was deprecated. I've not been able to find out why -- this change may have come from the POSIX side. I would have thought that it would have been better to use that error code in this case, since the name does exist, it just doesn't have any records of the asked-for type(s). Oh, well. Best regards, - Håvard ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AXFR/IN' denied ::solved::
On Apr 27, 2011, at 11:10 PM, jeffrey j donovan wrote:
Greetings
I have 2 systems master and slave, the slave seems to not allow the zone
transfer.
snip
found the problem, I had multiple option entries in named.conf there was an
original option line that I over looked that was from a previous master that
had allow-transfer { none; };
sorry to waste bandwidth :)
-j
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
IPv6 prefix length error
Hello, We just added the IPv6 address on our DNS servers. When we started named, we see these errors in the log: prefix length for 2001:1930:e03::e is unknown (assume 128) prefix length for ::1 is unknown (assume 128) So far, named is still running fine... I can't find any information to correct these errors. Thanks, Linh Khuu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?
On Apr 28, 2011, at 3:23 AM, Havard Eidnes wrote: www.apple.com. 281 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.net. ... As a matter of terminology, in the quoted example, I see a chain of three CNAME records. That's not what I would call an empty CNAME chain. What I do see, though, is a CNAME chain of three CNAME records, but where the ultimate target of the CNAME chain exists, but does not have any data of the requested type. Therefore, in the DNS you get a NOERROR status code, and an answer section which does not contain any records of the requested type. Agreed. Akamai's EdgeSuite doesn't provide IPv6 records at this time, but e3191.c.akamaiedge.net does have an A record. should getaddrinfo() return EAI_NONAME or EAI_FAIL? RFC 3493 says: [EAI_NONAME]The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. Which means that it should probably return EAI_NONAME; it's the least bad error code among the ones listed in RFC 3493 for getaddrinfo(), although one should not be mislead to think that this means that the DNS said NXDOMAIN. +1 to this analysis as well. Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?
Thanks Håvard and Chuck, not disagreeing below since I am genuinely confused, just trying to get it straight in my head. On 04/28/2011 10:00, Chuck Swiger wrote: On Apr 28, 2011, at 3:23 AM, Havard Eidnes wrote: www.apple.com. 281 IN CNAME www.isg-apple.com.akadns.net. www.isg-apple.com.akadns.net. 60 IN CNAME www.apple.com.edgekey.net. www.apple.com.edgekey.net. 17295 IN CNAME e3191.c.akamaiedge.net. ... As a matter of terminology, in the quoted example, I see a chain of three CNAME records. That's not what I would call an empty CNAME chain. What I do see, though, is a CNAME chain of three CNAME records, but where the ultimate target of the CNAME chain exists, but does not have any data of the requested type. Therefore, in the DNS you get a NOERROR status code, and an answer section which does not contain any records of the requested type. Agreed. Akamai's EdgeSuite doesn't provide IPv6 records at this time, but e3191.c.akamaiedge.net does have an A record. I understand what you're saying, but I've always referred to such a thing as an empty CNAME chain because it doesn't result in an address record at the end. Is there a more proper term for it? should getaddrinfo() return EAI_NONAME or EAI_FAIL? RFC 3493 says: [EAI_NONAME]The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. Which means that it should probably return EAI_NONAME; it's the least bad error code among the ones listed in RFC 3493 for getaddrinfo(), although one should not be mislead to think that this means that the DNS said NXDOMAIN. +1 to this analysis as well. The original question that started me down the rabbit hole was, What error code should 'ping6 www.apple.com' return? What confuses me here is that the node does actually exist in the sense that there is _an_ address record for it. So attempting to look at this from the standpoint of a user, the error message I get back (in our case, hostname or servname not provided, or not known) doesn't make any sense. (Although admittedly the does not resolve for the supplied parameters part of the definition does seem to.) Since for the purpose of ping6 no record at the end of the chain is a non-recoverable error, _FAIL (non-recoverable failure in name resolution) seems to make more sense. Is it possible that what we need is a new error code to designate something exists here, just not what you asked for? If _NONAME is intended to indicate that it seems overloaded. Alternatively I think we need to improve the language of our error messages. :-/ Thanks again, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?
On Apr 28, 2011, at 11:52 AM, Doug Barton wrote: Agreed. Akamai's EdgeSuite doesn't provide IPv6 records at this time, but e3191.c.akamaiedge.net does have an A record. I understand what you're saying, but I've always referred to such a thing as an empty CNAME chain because it doesn't result in an address record at the end. Is there a more proper term for it? RFC-1034 talks about CNAME chains: 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. ...and the recursive query algorithm: If recursive service is requested and available, the recursive response to a query will be one of the following: - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. - A temporary error indication. This phrase name does not exist appears to best be represented as EAI_NONAME. should getaddrinfo() return EAI_NONAME or EAI_FAIL? RFC 3493 says: [EAI_NONAME]The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. Which means that it should probably return EAI_NONAME; it's the least bad error code among the ones listed in RFC 3493 for getaddrinfo(), although one should not be mislead to think that this means that the DNS said NXDOMAIN. +1 to this analysis as well. The original question that started me down the rabbit hole was, What error code should 'ping6 www.apple.com' return? Well, it appears that some other folks expect EAI_NONAME: http://www.freebsd.org/cgi/query-pr.cgi?pr=156684 ...and the MacOSX version of ping6 uses it for this case: % ping6 www.apple.com ping6: getaddrinfo -- nodename nor servname provided, or not known What confuses me here is that the node does actually exist in the sense that there is _an_ address record for it. So attempting to look at this from the standpoint of a user, the error message I get back (in our case, hostname or servname not provided, or not known) doesn't make any sense. (Although admittedly the does not resolve for the supplied parameters part of the definition does seem to.) Since for the purpose of ping6 no record at the end of the chain is a non-recoverable error, _FAIL (non-recoverable failure in name resolution) seems to make more sense. If the nameserver returned a failure (ie, NXDOMAIN, SERVFAIL), then I would agree with EAI_FAIL. However, it didn't fail; you just asked a question which it answered successfully by providing all of the data which matched the query type; ie, the CNAMES up to the end of the chain, but not including the A record which terminates it, since you asked for an instead. Is it possible that what we need is a new error code to designate something exists here, just not what you asked for? If _NONAME is intended to indicate that it seems overloaded. Alternatively I think we need to improve the language of our error messages. :-/ As Harvard mentioned, EAI_NODATA? :-) Regards, -- -Chuck ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Anyone have problems with BIND 9.8.0
Folks, In my preparation to upgrade from 9.7.3 to 9.8.0. I figured it would be worth to field the obvious question: has anyone run into any problems in their upgrade? Thanks in advance, -Marion ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Empty CNAME chain, should getaddrinfo() return EAI_NONAME or EAI_FAIL?
On 04/28/2011 13:16, Chuck Swiger wrote: On Apr 28, 2011, at 11:52 AM, Doug Barton wrote: Agreed. Akamai's EdgeSuite doesn't provide IPv6 records at this time, but e3191.c.akamaiedge.net does have an A record. I understand what you're saying, but I've always referred to such a thing as an empty CNAME chain because it doesn't result in an address record at the end. Is there a more proper term for it? RFC-1034 talks about CNAME chains: 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. ...and the recursive query algorithm: If recursive service is requested and available, the recursive response to a query will be one of the following: - The answer to the query, possibly preface by one or more CNAME RRs that specify aliases encountered on the way to an answer. - A name error indicating that the name does not exist. This may include CNAME RRs that indicate that the original query name was an alias for a name which does not exist. - A temporary error indication. This phrase name does not exist appears to best be represented as EAI_NONAME. should getaddrinfo() return EAI_NONAME or EAI_FAIL? RFC 3493 says: [EAI_NONAME]The name does not resolve for the supplied parameters. Neither nodename nor servname were supplied. At least one of these must be supplied. [EAI_FAIL] A non-recoverable error occurred when attempting to resolve the name. Which means that it should probably return EAI_NONAME; it's the least bad error code among the ones listed in RFC 3493 for getaddrinfo(), although one should not be mislead to think that this means that the DNS said NXDOMAIN. +1 to this analysis as well. The original question that started me down the rabbit hole was, What error code should 'ping6 www.apple.com' return? Well, it appears that some other folks expect EAI_NONAME: http://www.freebsd.org/cgi/query-pr.cgi?pr=156684 Yes, my discussion with Jared on another list was what prompted me to post here. ...and the MacOSX version of ping6 uses it for this case: % ping6 www.apple.com ping6: getaddrinfo -- nodename nor servname provided, or not known What confuses me here is that the node does actually exist in the sense that there is _an_ address record for it. So attempting to look at this from the standpoint of a user, the error message I get back (in our case, hostname or servname not provided, or not known) doesn't make any sense. (Although admittedly the does not resolve for the supplied parameters part of the definition does seem to.) Since for the purpose of ping6 no record at the end of the chain is a non-recoverable error, _FAIL (non-recoverable failure in name resolution) seems to make more sense. If the nameserver returned a failure (ie, NXDOMAIN, SERVFAIL), then I would agree with EAI_FAIL. However, it didn't fail; you just asked a question which it answered successfully by providing all of the data which matched the query type; ie, the CNAMES up to the end of the chain, but not including the A record which terminates it, since you asked for an instead. Ok, I think that straightens it out for me. The deciding factor should be whether or not there is a name server error, is that right? If so that gives a nice clear, bright line. Is it possible that what we need is a new error code to designate something exists here, just not what you asked for? If _NONAME is intended to indicate that it seems overloaded. Alternatively I think we need to improve the language of our error messages. :-/ As Harvard mentioned, EAI_NODATA? :-) Well I was avoiding agreeing with him because I don't know why it was deprecated. :) Anyone here have an idea as to why it was? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Anyone have problems with BIND 9.8.0
Marion Bogdanov wrote: In my preparation to upgrade from 9.7.3 to 9.8.0. I figured it would be worth to field the obvious question: has anyone run into any problems in their upgrade? I haven't notice anything myself really, but would be interested in hearing of others have. Regards Eivind Olsen ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 prefix length error
On 04/28/11 11:20, Khuu, Linh Contractor wrote: Hello, We just added the IPv6 address on our DNS servers. When we started named, we see these errors in the log: prefix length for 2001:1930:e03::e is unknown (assume 128) prefix length for ::1 is unknown (assume 128) So far, named is still running fine… I can’t find any information to correct these errors. Thanks, Linh Khuu ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users These are not bind errors, but errors in how you configured IPv6 in the host OS. You have not specified the prefix length(compares to /24 for IPv4 cidr notation) in your network configuration for your IPv6 addresses. Lyle Giese LCR Computer Services, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: IPv6 prefix length error
In message f80b214c2304c641b917b47051d743c407f0297...@hq-mb-08.ba.ad.ssa.gov, Khuu, Linh Contractor writes: Hello, We just added the IPv6 address on our DNS servers. When we started named, w= e see these errors in the log: prefix length for 2001:1930:e03::e is unknown (assume 128) prefix length for ::1 is unknown (assume 128) So far, named is still running fine... I can't find any information to corr= ect these errors. Thanks, Linh Khuu These are reported because named was unable to determine the prefix length associated with the address. Usually because no one has documented the OS specicif method for doing this or it is write only. Please contact your OS vendor so they can address the issue. The major implication of not having this information is that the builtin localnets acl will not be complete. Instead of 2001:1930:e03::/64, assuming it is a /64, it will have 2001:1930:e03::e/128. Mark -- 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
