Re: ignoring incorrect nameservers in authority section
Sunil Shetye writes: Quoting from p...@mail.nsbeta.info's mail on Thu, Dec 30, 2010: What's the difference between these two flags in the response of dig? ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ra : recursion available The nameserver is ready to ask other nameservers for the record we queried. As the 'aa' flag is also missing above, the answer is not authoritative. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 aa : authoritative answer The nameserver is authoritative for the zone of the record that we queried. As the 'ra' flag is also missing above, the nameserver will not do a lookup for you for records it does not know about. Thanks a lot. Where is the document for these flags? I google'd but got no correct result :) Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Sunil Shetye writes: Case 2: Lame Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org. 172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === This is a lame server reply. bind ignores this reply. bind will give a server fail reply to the client. Would you please tell me why this is a lame server reply? why bind will give a server fail reply to the client? Thanks again a lot. Regards. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Quoting from p...@mail.nsbeta.info's mail on Thu, Dec 30, 2010: Where is the document for these flags? I google'd but got no correct result :) http://www.tcpipguide.com/free/t_DNSMessageHeaderandQuestionSectionFormat.htm -- Sunil Shetye. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Dnia 2010-12-30 19:18 p...@mail.nsbeta.info napisał(a): Please see this dig: $ dig +norec dev.game.yy.com @202.96.128.166 ; DiG 9.4.2-P2 +norec dev.game.yy.com @202.96.128.166 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 31949 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dev.game.yy.com. IN A ;; ANSWER SECTION: dev.game.yy.com.1800IN A 202.104.186.179 ;; Query time: 5 msec ;; SERVER: 202.96.128.166#53(202.96.128.166) ;; WHEN: Thu Dec 30 19:16:44 2010 ;; MSG SIZE rcvd: 49 So, is 202.96.128.166 a lame server? There's something strange with this one. You've specified +norec on command line, but the query was sent with 'rd' - 'recursion desired' flag, as if you haven't given +norec. And with recursion giving answer is perfectly legal. If not for that flag, then yes, I'd consider it a lame response, although probably someone more knowledgeable than me should judge this. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Dnia 2010-12-30 11:45 Torinthiel napisał(a): Dnia 2010-12-30 18:03 p...@mail.nsbeta.info napisał(a): Sunil Shetye writes: Case 2: Lame Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === This is a lame server reply. bind ignores this reply. bind will give a server fail reply to the client. Would you please tell me why this is a lame server reply? why bind will give a server fail reply to the client? Thanks again a lot. Because it's contrary to itself. You've specified norecurse, which means that if nameserver believes it has authorative data it should return it, if it doesn't it should return a referral (and no answer beside it). But the server returns answer (which means it believes it has authorative data), but in authority section is not listed in nameservers, which states it does not have authorative data. To sum up: Question: Does the server have authorative data? Answer 1: Server returns data when asked without recursion -; YES Answer 2: Server is not listed in authority section -; NO Real answer: Lame server. And I was wrong about that one. There are two issues with that one. First, I get a different response from that command. different flags (no ra but aa instead), differend authority section. It's much simplier to tell if it's a 'lame nameserver response' although it can't be judged by a single query. Let's say that nameservers for .org domain (there are a lot of them), when asked for example.org give a.iana-servers.net and b.iana-servers.net (which is true, and by itself nothing special). Then lets assume (which is not true, but a good example) that a.iana-servers.net when asked for www.example.org gives something (doesn't matter if a true answer, or missing record, or anything), but with 'aa' flag not set. This, by itself, is still nothing special, no server is required to know everything. But from those two answers you have a contradiction, and this contradiction is a real lane nameserver issue. .org servers delegate answers to a.iana-servers.net, and a.iana-servers.net fails to deliver authorative response. So the delegation is in fact incorrect. Fortunately, a.iana-servers.net does not behave the way I've described here and does set 'aa' flag in it's response. Hope this clears up the issue a bit, and reduces misinformation caused by my previous answer. Regards, Torinthiel ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
What's the difference between these two flags in the response of dig? ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 --- ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 Thanks in advance. Sunil Shetye writes: Quoting from David Sparro's mail on Tue, Dec 28, 2010: Here, I can see that the nameserver is giving the right replies to all queries except the NS queries. How can an authoritative server give wrong answers? Due to misconfiguration of the NS records. My guess is that the domain was transferred from one nameserver to another without updating the NS records and the domain registration was updated. Another reason could be that some ill-informed DNS administrators are replacing their NS records with 'blackhole' or 'fake' nameservers to avoid DNS attacks on their actual servers. I was hoping that either bind should catch such cases automatically or allow some workaround which need not be monitored later. You're asking BIND to deduce the intent of the domain owner. It is hard to say whether it is intentional or due to a misconfiguration. Note that my aim is to ensure that dig +trace (or a non-caching nameserver) should give the same answer as named (ignoring TTL). If dig +trace is always landing at the right server while named is always landing at the wrong server (till the cached NS records expire) (see case 3 below), it is very hard to debug the problem. Here are the detailed cases which are applicable here. When bind queries a nameserver, the following types of answers are expected (apart from referrals, refused replies, and other errors): Case 1: Authoritative Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org. 172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS a.iana-servers.net. example.org.172800 IN NS b.iana-servers.net. === This is the answer in the correct format. Both the A and NS records are cached. bind will give a similar reply back to the client. Case 2: Lame Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org. 172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === This is a lame server reply. bind ignores this reply. bind will give a server fail reply to the client. Case 3: Authoritative Server Reply with Lame NS Records === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org. 172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === Here, we are getting an authoritative reply. This means that the A record can be cached. However, note that NS section here does not list a.iana-servers.net. Should bind cache this authority section? If ns[12].example.org. were the real nameservers, we should have got a referral from a.iana-servers.net. and not an authoritative answer. If bind does cache this (as it currently does), the next query for example.org will go to ns[12].example.org. directly. However, here we can see that a.iana-servers.net. is actually the authoritative nameserver, which means that it is ready to answer all example.org queries. If bind does not cache the NS records, it will land via referrals back to a.iana-servers.net. for the next query and get the correct authoritative answer. What should bind reply back to the client? It would be safe to drop the authority section in the reply. === $ dig example.org. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 === Hope that this elaborate example clears the picture of what I am trying to convey. Note that querying of NS records will also have to be handled in a consistent manner. However, some more thought may be required there. -- Sunil Shetye.
Re: ignoring incorrect nameservers in authority section
Quoting from p...@mail.nsbeta.info's mail on Thu, Dec 30, 2010: What's the difference between these two flags in the response of dig? ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ra : recursion available The nameserver is ready to ask other nameservers for the record we queried. As the 'aa' flag is also missing above, the answer is not authoritative. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 aa : authoritative answer The nameserver is authoritative for the zone of the record that we queried. As the 'ra' flag is also missing above, the nameserver will not do a lookup for you for records it does not know about. -- Sunil Shetye. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
On 12/24/2010 2:51 AM, Sunil Shetye wrote: Here, I can see that the nameserver is giving the right replies to all queries except the NS queries. How can an authoritative server give wrong answers? I was hoping that either bind should catch such cases automatically or allow some workaround which need not be monitored later. You're asking BIND to deduce the intent of the domain owner. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ignoring incorrect nameservers in authority section
Quoting from David Sparro's mail on Tue, Dec 28, 2010: Here, I can see that the nameserver is giving the right replies to all queries except the NS queries. How can an authoritative server give wrong answers? Due to misconfiguration of the NS records. My guess is that the domain was transferred from one nameserver to another without updating the NS records and the domain registration was updated. Another reason could be that some ill-informed DNS administrators are replacing their NS records with 'blackhole' or 'fake' nameservers to avoid DNS attacks on their actual servers. I was hoping that either bind should catch such cases automatically or allow some workaround which need not be monitored later. You're asking BIND to deduce the intent of the domain owner. It is hard to say whether it is intentional or due to a misconfiguration. Note that my aim is to ensure that dig +trace (or a non-caching nameserver) should give the same answer as named (ignoring TTL). If dig +trace is always landing at the right server while named is always landing at the wrong server (till the cached NS records expire) (see case 3 below), it is very hard to debug the problem. Here are the detailed cases which are applicable here. When bind queries a nameserver, the following types of answers are expected (apart from referrals, refused replies, and other errors): Case 1: Authoritative Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS a.iana-servers.net. example.org.172800 IN NS b.iana-servers.net. === This is the answer in the correct format. Both the A and NS records are cached. bind will give a similar reply back to the client. Case 2: Lame Server Reply === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === This is a lame server reply. bind ignores this reply. bind will give a server fail reply to the client. Case 3: Authoritative Server Reply with Lame NS Records === $ dig +norecurse @a.iana-servers.net. example.org. ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 ;; AUTHORITY SECTION: example.org.172800 IN NS ns1.example.org. example.org.172800 IN NS ns2.example.org. === Here, we are getting an authoritative reply. This means that the A record can be cached. However, note that NS section here does not list a.iana-servers.net. Should bind cache this authority section? If ns[12].example.org. were the real nameservers, we should have got a referral from a.iana-servers.net. and not an authoritative answer. If bind does cache this (as it currently does), the next query for example.org will go to ns[12].example.org. directly. However, here we can see that a.iana-servers.net. is actually the authoritative nameserver, which means that it is ready to answer all example.org queries. If bind does not cache the NS records, it will land via referrals back to a.iana-servers.net. for the next query and get the correct authoritative answer. What should bind reply back to the client? It would be safe to drop the authority section in the reply. === $ dig example.org. ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN A ;; ANSWER SECTION: example.org.172800 IN A 192.0.32.10 === Hope that this elaborate example clears the picture of what I am trying to convey. Note that querying of NS records will also have to be handled in a consistent manner. However, some more thought may be required there. -- Sunil Shetye. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
ignoring incorrect nameservers in authority section
Hi, Some authoritative nameservers add incorrect nameservers in the authority section of their replies. Due to caching of the incorrect reply, further queries for that domain go to those incorrect nameservers. Is there a way to ignore / not cache such replies? For example, if ns1.realserver.com gives this authoritative reply: === $ dig a1.example.com. ;; QUESTION SECTION: ;a1.example.com. IN A ;; ANSWER SECTION: a1.example.com. 3600 IN A 10.10.10.10 ;; AUTHORITY SECTION: example.com.3600 IN NS ns1.fakeserver.com. example.com.3600 IN NS ns2.fakeserver.com. === Further queries for example.com go to ns[12].fakeserver.com. === $ dig a2.example.com. ;; QUESTION SECTION: ;a2.example.com. IN A unexpected RCODE (REFUSED) resolving 'a2.example.com/A/IN': ns1.fakeserver.com#53 === ns[12].fakeserver.com. are not authoritative for example.com here. The symptoms are: 1. dig +trace a1.example.com. always works correctly. 2. dig a1.example.com. works correctly the first time. 2. dig a2.example.com. gives an error till the fake NS record expires. This is obviously a misconfiguration on ns1.realserver.com. The correct nameservers are listed in domain registration of example.com along with the correct glue records. Is there any solution to this problem without contacting the DNS administrator of that domain? I have seen this problem for many domains on the internet. -- Sunil Shetye. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
