Re: about AUTHORITY SECTION
At 00:04 08-07-2011, Chris Buxton wrote: As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. Further, section 8 of this RFC does not say explicitly that an SOA must be RFC 2308 replaces Section 4.3.4 of RFC 1034. Irrespective of whether it is only at Proposed Standard, it is implemented by BIND 9. Regards, -sm ___ 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: about AUTHORITY SECTION
On Jul 7, 2011, at 6:32 PM, Feng He wrote: 2011/7/8 Kevin Darcy k...@chrysler.com: I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. In the second case I think the NS records should be there in the Authority Section. Consider this case: example.com. IN NSdns.example.com. l2.example.com. IN NS dns.example.com. l3.l2.example.com. IN NS dns.example.com. When a query for example, dig l3.l2.example.com @dns.example.com, the nameserver answser without the Authority Section, then the client won't know the answer is in which authority zone. While that is correct, it is also unimportant. Everything will work as expected if the resolver never finds that out. Ditto if the resolver does discover it. As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point. RFCs 1034 and 1035 permit a negative answer with no content in the authority section; all modern name servers should handle this correctly. While this prevents caching of the negative answer, it should still be treated as a final negative answer to the query being worked on. Regards, Chris Buxton BlueCat Networks ___ 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: about AUTHORITY SECTION
On 7/8/2011 3:04 AM, Chris Buxton wrote: On Jul 7, 2011, at 6:32 PM, Feng He wrote: 2011/7/8 Kevin Darcyk...@chrysler.com: I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. In the second case I think the NS records should be there in the Authority Section. Consider this case: example.com. IN NSdns.example.com. l2.example.com. IN NS dns.example.com. l3.l2.example.com. IN NS dns.example.com. When a query for example, dig l3.l2.example.com @dns.example.com, the nameserver answser without the Authority Section, then the client won't know the answer is in which authority zone. While that is correct, it is also unimportant. Everything will work as expected if the resolver never finds that out. Ditto if the resolver does discover it. As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. OK, I stand corrected. It's mandatory per a Proposed Standard that hasn't had any major objections, reported flaws, or updates in years, and is implemented in virtually every authoritative nameserver -- including load-balancers, pretending to be auth nameservers, and which break a whole raft of other standards and/or best practices -- and resolver. *Technically* a negative response can be given that does not conform to RFC 2308, and no RFC Police will show up at one's doorstep wielding an arrest warrant... Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point. Um, Section 8 talks about how resolvers deal with negative caching. Section 3 talks about responses from authoritative servers, and that was the subject of this thread. Section 3 is quite clear on the point: 3 - Negative Answers from Authoritative Servers Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. - 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: about AUTHORITY SECTION
On Jul 8, 2011, at 9:05 AM, Kevin Darcy wrote: On 7/8/2011 3:04 AM, Chris Buxton wrote: As for Kevin's assertion that the SOA record in the authority section is required for a negative response, this is also incorrect. RFC 2308 is a proposed standard, not a standard. OK, I stand corrected. It's mandatory per a Proposed Standard that hasn't had any major objections, reported flaws, or updates in years, and is implemented in virtually every authoritative nameserver -- including load-balancers, pretending to be auth nameservers, and which break a whole raft of other standards and/or best practices -- and resolver. *Technically* a negative response can be given that does not conform to RFC 2308, and no RFC Police will show up at one's doorstep wielding an arrest warrant... I'm not disagreeing with your points above, merely being a pedant. Obviously it's a good thing when negative answers are cacheable. Further, section 8 of this RFC does not say explicitly that an SOA must be included in a negative response, only that it must be cached (presumably only if present). We might ask the author, Mark Andrews, for clarification of this point. Um, Section 8 talks about how resolvers deal with negative caching. Interesting, then, that it's titled, Changes from RFC 1034. You're right, of course, but the title is confusing. Section 3 talks about responses from authoritative servers, and that was the subject of this thread. Section 3 is quite clear on the point: Agreed. I stand corrected on this point. A bit confusing, though, that Mark chose to include in his examples in section 2 cases where the authority section is empty. Regardless, my primary point was that, while returning a cacheable negative answer is now pretty much standard behavior, a resolver should still be able to cope with a completely empty negative response. I do still see them from time to time, although I don't have an example to hand. Regards, Chris Buxton BlueCat Networks ___ 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: about AUTHORITY SECTION
On 07/07/11 04:56, pa...@laposte.net wrote: Hello, I got two different forms of AUTHORITY SECTION from the dig, for example, $ dig mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 36520 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mydots.net. IN A ;; AUTHORITY SECTION: mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 604800 3600 This one means that there's no such record. Your answer is empty. See, you don't have answer section and RFCs state that authorative nameservers should send SOA record in authority section if there's no data. ;; Query time: 90 msec ;; SERVER: 58.22.107.162#53(58.22.107.162) ;; WHEN: Thu Jul 7 09:54:07 2011 ;; MSG SIZE rcvd: 86 $ dig www.mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 www.mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3327 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.mydots.net. IN A ;; ANSWER SECTION: www.mydots.net. 900 IN A 61.144.56.101 ;; AUTHORITY SECTION: mydots.net. 3600 IN NS ns7.dnsbed.com. mydots.net. 3600 IN NS ns8.dnsbed.com. And this one has correct answer, and the NS records are there just in case - to notify you that you got your answer from authorative ns and what other authorative ns'es are. Torinthiel signature.asc Description: OpenPGP digital signature ___ 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: about AUTHORITY SECTION
On 7/7/2011 1:50 AM, Torinthiel wrote: On 07/07/11 04:56, pa...@laposte.net wrote: Hello, I got two different forms of AUTHORITY SECTION from the dig, for example, $ dig mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 36520 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mydots.net. IN A ;; AUTHORITY SECTION: mydots.net. 3600 IN SOA ns7.dnsbed.com. support.dnsbed.com. 6 10800 3600 604800 3600 This one means that there's no such record. Your answer is empty. See, you don't have answer section and RFCs state that authorative nameservers should send SOA record in authority section if there's no data. ;; Query time: 90 msec ;; SERVER: 58.22.107.162#53(58.22.107.162) ;; WHEN: Thu Jul 7 09:54:07 2011 ;; MSG SIZE rcvd: 86 $ dig www.mydots.net @ns7.dnsbed.com ; DiG 9.4.2-P2.1 www.mydots.net @ns7.dnsbed.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 3327 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.mydots.net. IN A ;; ANSWER SECTION: www.mydots.net. 900 IN A 61.144.56.101 ;; AUTHORITY SECTION: mydots.net. 3600 IN NS ns7.dnsbed.com. mydots.net. 3600 IN NS ns8.dnsbed.com. And this one has correct answer, and the NS records are there just in case - to notify you that you got your answer from authorative ns and what other authorative ns'es are. I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. - 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: about AUTHORITY SECTION
2011/7/8 Kevin Darcy k...@chrysler.com: I think it's worth emphasizing that in the first case, the contents of the Authority Section were *mandatory* (see RFC 2308, Negative Caching), whereas in the second case the authoritative nameserver was *optionally* providing NS records in the Authority Section. It could have legally left the Authority Section completely empty, and in fact many load-balancers, pretending (to various degrees of competence) to be authoritative nameservers, will give responses that look like that. In the second case I think the NS records should be there in the Authority Section. Consider this case: example.com. IN NSdns.example.com. l2.example.com. IN NS dns.example.com. l3.l2.example.com. IN NS dns.example.com. When a query for example, dig l3.l2.example.com @dns.example.com, the nameserver answser without the Authority Section, then the client won't know the answer is in which authority zone. Thanks. ___ 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: about AUTHORITY SECTION
In message AANLkTi=9B07Q=flysn6s-0scossneuxms0qgy9h+o...@mail.gmail.com, terr y writes: Hello, When I delegate a subdomain in a zone example.com, the config in named.conf is like: test.example.com. 3600 IN NS ns1.another.com. test.example.com. 3600 IN NS ns2.another.com. Then I dig to the auth-server of the example zone: dig test.example.com ns @ns1.example.com I found some servers return the ANSWER SECTION, but some servers return the AUTHORITY SECTION. For example: ;; ANSWER SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. And: ;; AUTHORITY SECTION: test.example.com. 3600IN NS ns2.another.com. test.example.com. 3600IN NS ns1.another.com. I'm confused, shall name server answer with ANSWER or AUTHORITY for this case ? Look at RA and RD. If the server recurses, you will get a answer. If the server does not recurse, you will get a referral. Then there are the really old broken servers which get this wrong. Mark Thanks in advance. ___ 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: about AUTHORITY SECTION
2011/3/4 Mark Andrews ma...@isc.org: In message AANLkTi=9B07Q=flysn6s-0scossneuxms0qgy9h+o...@mail.gmail.com, terr y writes: Hello, When I delegate a subdomain in a zone example.com, the config in named.conf is like: test.example.com. 3600 IN NS ns1.another.com. test.example.com. 3600 IN NS ns2.another.com. Then I dig to the auth-server of the example zone: dig test.example.com ns @ns1.example.com I found some servers return the ANSWER SECTION, but some servers return the AUTHORITY SECTION. For example: ;; ANSWER SECTION: test.example.com. 3600 IN NS ns2.another.com. test.example.com. 3600 IN NS ns1.another.com. And: ;; AUTHORITY SECTION: test.example.com. 3600 IN NS ns2.another.com. test.example.com. 3600 IN NS ns1.another.com. I'm confused, shall name server answer with ANSWER or AUTHORITY for this case ? Look at RA and RD. If the server recurses, you will get a answer. If the server does not recurse, you will get a referral. Then there are the really old broken servers which get this wrong. Hi Mark, Please see this for details: $ dig nsbeta.info ns @ns34.domaincontrol.com ; DiG 9.4.2-P2.1 nsbeta.info ns @ns34.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41454 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;nsbeta.info. IN NS ;; ANSWER SECTION: nsbeta.info.3600IN NS ns34.domaincontrol.com. nsbeta.info.3600IN NS ns33.domaincontrol.com. ;; Query time: 183 msec ;; SERVER: 208.109.255.17#53(208.109.255.17) ;; WHEN: Fri Mar 4 22:59:39 2011 ;; MSG SIZE rcvd: 123 There isn't the ra flag in the response, why the nameserver has been also answering with the ANSWER SECTION? I think it should answer with the AUTHORITY SECTION. Thanks again. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
Dnia 2011-03-04 23:07 terry napisał(a): Look at RA and RD. If the server recurses, you will get a answer. If the server does not recurse, you will get a referral. Then there are the really old broken servers which get this wrong. Hi Mark, Please see this for details: $ dig nsbeta.info ns @ns34.domaincontrol.com ; DiG 9.4.2-P2.1 nsbeta.info ns @ns34.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41454 ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;nsbeta.info. IN NS ;; ANSWER SECTION: nsbeta.info.3600IN NS ns34.domaincontrol.com. nsbeta.info.3600IN NS ns33.domaincontrol.com. There isn't the ra flag in the response, why the nameserver has been also answering with the ANSWER SECTION? I think it should answer with the AUTHORITY SECTION. But in this case, you're asking the authotrative server. Authorative server answers in answer section, as it knows the answer. Authorative section is for 'I don't know, ask ...' The rule above goes for servers which are not authorative for a given zone. Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
But in this case, you're asking the authotrative server. Authorative server answers in answer section, as it knows the answer. Authorative section is for 'I don't know, ask ...' The rule above goes for servers which are not authorative for a given zone. Torinthiel ___ I'm very sorry, just by typo, I do mean this case: $ dig test.nsbeta.info ns @ns33.domaincontrol.com ; DiG 9.4.2-P2.1 test.nsbeta.info ns @ns33.domaincontrol.com ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 13538 ;; flags: qr rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;test.nsbeta.info. IN NS ;; ANSWER SECTION: test.nsbeta.info. 3600IN NS ns2.dnsbed.com. test.nsbeta.info. 3600IN NS ns1.dnsbed.com. ;; Query time: 186 msec ;; SERVER: 216.69.185.17#53(216.69.185.17) ;; WHEN: Sat Mar 5 09:36:58 2011 ;; MSG SIZE rcvd: 122 So why does ns33.domaincontrol.com answer with ANSWER SECTION rather than AUTHORITY SECTION? Thanks. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about AUTHORITY SECTION
2011/3/5 Mark Andrews ma...@isc.org: So why does ns33.domaincontrol.com answer with ANSWER SECTION rather than AUTHORITY SECTION? If you ask with rd=0 (+norec), which is what nameservers do, you get the referral. Presumably ns33.domaincontrol.com is running BIND 8 which didn't fully comply the RFC 1034. One of the reasons for writing BIND 9 was to sort out these corner cases. If rd=1 BIND 8 assumed that there was a stub resolver talking to it so it put the response in the answer section despite it not being authoritative for the child zone. It rd=0 it did what RFC 1034 said to do, put the response in the authority section. BIND 9 will actually recurse if rd=1 and the client is in the allow-recursion acl and fetch the answer from the child zone and return it. If not it will return a referral. That's the great answer. You have cleaned my confusion which exists long time in my head. Thanks a lot Mark. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
