Re: does bind depends on system DNS settings for lookup?
Am 18.11.2015 um 05:42 schrieb Dil Lee: This is probably a dummy question. My understand of bind in handling non-authoritative queries is: 1) forward mode. It just forward the client queries to an upstream DNS server, which is defined in "forwarders" directive. 2) recursive mode. It actually start asking from root DNS server, then 2nd level DNS server etc till it finally get an authoritative answer for the host in question. Non of these modes seems to depends/relates to the system DNS settings on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE? no beause it would not make sense to do so when /etc/resolv.conf contains only 127.0.0.1 which is a common dns-cache setup on inbound mailservers 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
Query on ignoring additional section returned in replies
Hi guys, I'm having issues resolving www.fis.com.my. I'm trying to tell fis.com.my that its an issue at their end, but when checking against 8.8.8.8 it resolves fineso it MUST be a problem with me. 1. Lookups fail, this is clear enough root@sputnik # dig @localhost www.fis.com.my ; <<>> DiG 9.9.5-P1 <<>> @localhost www.fis.com.my ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51246 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.fis.com.my.IN A ;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Nov 18 17:40:58 MYT 2015 ;; MSG SIZE rcvd: 43 2. All of fis.com.my's authoritative nameservers answer and are consistent It tells me that www.wip.fis.com.my is a CNAME for www.fis.com.my And that wan1-wan4.fis.com.my is the authoritative servers for *.wip.fis.com.my root@sputnik # dig @ns1.fis.com.my www.fis.com.my ; <<>> DiG 9.9.5-P1 <<>> @ns1.fis.com.my www.fis.com.my ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33357 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.fis.com.my.IN A ;; ANSWER SECTION: www.fis.com.my. 38400 IN CNAME www.wip.fis.com.my. ;; AUTHORITY SECTION: wip.fis.com.my. 38400 IN NS wan1.fis.com.my. wip.fis.com.my. 38400 IN NS wan4.fis.com.my. wip.fis.com.my. 38400 IN NS wan3.fis.com.my. wip.fis.com.my. 38400 IN NS wan2.fis.com.my. ;; ADDITIONAL SECTION: wan1.fis.com.my.38400 IN A 202.188.242.130 wan2.fis.com.my.38400 IN A 210.19.86.114 wan3.fis.com.my.38400 IN A 175.143.6.162 wan4.fis.com.my.38400 IN A 219.92.28.106 ;; Query time: 8 msec ;; SERVER: 202.188.242.135#53(202.188.242.135) ;; WHEN: Wed Nov 18 17:41:09 MYT 2015 ;; MSG SIZE rcvd: 205 3. I now do a 3rd lookup test against wan1.fis.com.my for www.wip.fis.com.my and get the answers BUT, the nameserver is also returning an authority section saying wip.fis.com.my is now served by ns1.wip.fis.com.my [Previously I know wip.fis.com.my was served by wan1-wan4.fis.com.my, but now somehow I'm caching ns1.wip.fis.com.my instead] [Question: Is it the expected behaviour that this new NS will override the previous NS for wip.fis.com.my? And is there any way to ignore authority/additional answers that I get from replies?] root@cbj-cdns21 # dig @wan1.fis.com.my www.wip.fis.com.my ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my www.wip.fis.com.my ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43777 ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;www.wip.fis.com.my.IN A ;; ANSWER SECTION: www.wip.fis.com.my. 5 IN A 175.143.6.165 www.wip.fis.com.my. 5 IN A 202.188.242.137 www.wip.fis.com.my. 5 IN A 210.19.86.117 ;; AUTHORITY SECTION: wip.fis.com.my. 3600IN NS ns1.wip.fis.com.my. ;; Query time: 7 msec ;; SERVER: 202.188.242.130#53(202.188.242.130) ;; WHEN: Wed Nov 18 17:44:59 MYT 2015 ;; MSG SIZE rcvd: 102 4. Lo and behold, ns1.wip.fis.com.my doesn't exist! And because of this all my queries for www.fis.com.my are failing. Am I correct? root@sputnik # dig @wan1.fis.com.my ns1.wip.fis.com.my ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my ns1.wip.fis.com.my ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37457 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;ns1.wip.fis.com.my.IN A ;; AUTHORITY SECTION: wip.fis.com.my. 3600IN SOA ns1.wip.fis.com.my. webmaster. 2015111825 16384 2048 1048576 2560 ;; Query time: 6 msec ;; SERVER: 202.188.242.130#53(202.188.242.130) ;; WHEN: Wed Nov 18 17:47:45 MYT 2015 ;; MSG SIZE rcvd: 81 We only send and receive email on the basis of the terms set out at http://www.tm.com.my/email_disclaimer. ___ 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: root hints operation
Grant Taylor wrote: > > This quite from Twitter seems appropriate: DNSSEC only protects you from > getting bad answers. If someone wants you to get no answers at all then > DNSSEC cannot help. That wasn't from Twitter, that was from me on NANOG. http://mailman.nanog.org/pipermail/nanog/2015-November/082413.html Tony. -- f.anthony.n.finchhttp://dotat.at/ German Bight, Humber, Thames, Dover: West or northwest, backing southwest for a time, 6 to gale 8, increasing severe gale 9 at times, perhaps storm 10 later in German Bight and Humber. Rough or very rough, occasionally high later in German Bight and Humber. Rain at times. Good, occasionally poor. ___ 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: Query on ignoring additional section returned in replies
In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: > Hi guys, > > I'm having issues resolving www.fis.com.my. I'm trying to tell fis.com.my tha > t its an issue at their end, but when checking against 8.8.8.8 it resolves fi > neso it MUST be a problem with me. > > 1. Lookups fail, this is clear enough > > root@sputnik # dig @localhost www.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @localhost www.fis.com.my > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51246 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;www.fis.com.my.IN A > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Nov 18 17:40:58 MYT 2015 > ;; MSG SIZE rcvd: 43 > > > 2. All of fis.com.my's authoritative nameservers answer and are consistent >It tells me that www.wip.fis.com.my is a CNAME for www.fis.com.my >And that wan1-wan4.fis.com.my is the authoritative servers for *.wip.fis.c > om.my > > root@sputnik # dig @ns1.fis.com.my www.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @ns1.fis.com.my www.fis.com.my > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33357 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 > ;; WARNING: recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;www.fis.com.my.IN A > > ;; ANSWER SECTION: > www.fis.com.my. 38400 IN CNAME www.wip.fis.com.my. > > ;; AUTHORITY SECTION: > wip.fis.com.my. 38400 IN NS wan1.fis.com.my. > wip.fis.com.my. 38400 IN NS wan4.fis.com.my. > wip.fis.com.my. 38400 IN NS wan3.fis.com.my. > wip.fis.com.my. 38400 IN NS wan2.fis.com.my. > > ;; ADDITIONAL SECTION: > wan1.fis.com.my.38400 IN A 202.188.242.130 > wan2.fis.com.my.38400 IN A 210.19.86.114 > wan3.fis.com.my.38400 IN A 175.143.6.162 > wan4.fis.com.my.38400 IN A 219.92.28.106 > > ;; Query time: 8 msec > ;; SERVER: 202.188.242.135#53(202.188.242.135) > ;; WHEN: Wed Nov 18 17:41:09 MYT 2015 > ;; MSG SIZE rcvd: 205 > > > 3. I now do a 3rd lookup test against wan1.fis.com.my for www.wip.fis.com.my > and get the answers >BUT, the nameserver is also returning an authority section saying wip.fis. > com.my is now served by ns1.wip.fis.com.my >[Previously I know wip.fis.com.my was served by wan1-wan4.fis.com.my, but > now somehow I'm caching ns1.wip.fis.com.my instead] >[Question: Is it the expected behaviour that this new NS will override the > previous NS for wip.fis.com.my? And is there any way to ignore authority/add > itional answers that I get from replies?] Yes. The delegation is broken. Having a NS pointing at a nonexistant name is a big no no. It's just a matter of time for a delegation like this to break. > root@cbj-cdns21 # dig @wan1.fis.com.my www.wip.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my www.wip.fis.com.my > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43777 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;www.wip.fis.com.my.IN A > > ;; ANSWER SECTION: > www.wip.fis.com.my. 5 IN A 175.143.6.165 > www.wip.fis.com.my. 5 IN A 202.188.242.137 > www.wip.fis.com.my. 5 IN A 210.19.86.117 > > ;; AUTHORITY SECTION: > wip.fis.com.my. 3600IN NS ns1.wip.fis.com.my. > > ;; Query time: 7 msec > ;; SERVER: 202.188.242.130#53(202.188.242.130) > ;; WHEN: Wed Nov 18 17:44:59 MYT 2015 > ;; MSG SIZE rcvd: 102 > > > 4. Lo and behold, ns1.wip.fis.com.my doesn't exist! And because of this all m > y queries for www.fis.com.my are failing. Am I correct? > > root@sputnik # dig @wan1.fis.com.my ns1.wip.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my ns1.wip.fis.com.my > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37457 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;ns1.wip.fis.com.my.IN A > > ;; AUTHORITY SECTION: > wip.fis.com.my. 3600IN SOA ns1.wip.fis.com.my. webmaster > . 2015111825 16384 2048 1048576 2560 > > ;; Query time: 6 msec > ;; SERVER: 202.188.242.130#53(202.188.242.130) > ;; WHEN: Wed Nov 18 17:47:45 MYT 2015 > ;; MSG SIZE rcvd: 81 > >
RE: Query on ignoring additional section returned in replies
Even with a broken delegation its like always resolvable with Google DNS or even Open DNS. Are there any BIND specific workarounds? -Original Message- From: Mark Andrews [mailto:ma...@isc.org] Sent: Wednesday, November 18, 2015 6:26 PM To: Elias Ahmed Kamal Cc: bind-users@lists.isc.org Subject: Re: Query on ignoring additional section returned in replies In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: > Hi guys, > > I'm having issues resolving www.fis.com.my. I'm trying to tell > fis.com.my tha t its an issue at their end, but when checking against > 8.8.8.8 it resolves fi neso it MUST be a problem with me. > > 1. Lookups fail, this is clear enough > > root@sputnik # dig @localhost www.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @localhost www.fis.com.my ; (1 server found) > ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51246 ;; flags: > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;www.fis.com.my.IN A > > ;; Query time: 0 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Wed Nov 18 17:40:58 MYT 2015 > ;; MSG SIZE rcvd: 43 > > > 2. All of fis.com.my's authoritative nameservers answer and are consistent >It tells me that www.wip.fis.com.my is a CNAME for www.fis.com.my >And that wan1-wan4.fis.com.my is the authoritative servers for > *.wip.fis.c om.my > > root@sputnik # dig @ns1.fis.com.my www.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @ns1.fis.com.my www.fis.com.my ; (1 server > found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33357 ;; flags: qr > aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; WARNING: > recursion requested but not available > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;www.fis.com.my.IN A > > ;; ANSWER SECTION: > www.fis.com.my. 38400 IN CNAME www.wip.fis.com.my. > > ;; AUTHORITY SECTION: > wip.fis.com.my. 38400 IN NS wan1.fis.com.my. > wip.fis.com.my. 38400 IN NS wan4.fis.com.my. > wip.fis.com.my. 38400 IN NS wan3.fis.com.my. > wip.fis.com.my. 38400 IN NS wan2.fis.com.my. > > ;; ADDITIONAL SECTION: > wan1.fis.com.my.38400 IN A 202.188.242.130 > wan2.fis.com.my.38400 IN A 210.19.86.114 > wan3.fis.com.my.38400 IN A 175.143.6.162 > wan4.fis.com.my.38400 IN A 219.92.28.106 > > ;; Query time: 8 msec > ;; SERVER: 202.188.242.135#53(202.188.242.135) > ;; WHEN: Wed Nov 18 17:41:09 MYT 2015 > ;; MSG SIZE rcvd: 205 > > > 3. I now do a 3rd lookup test against wan1.fis.com.my for > www.wip.fis.com.my and get the answers >BUT, the nameserver is also returning an authority section saying wip.fis. > com.my is now served by ns1.wip.fis.com.my >[Previously I know wip.fis.com.my was served by > wan1-wan4.fis.com.my, but now somehow I'm caching ns1.wip.fis.com.my instead] >[Question: Is it the expected behaviour that this new NS will > override the previous NS for wip.fis.com.my? And is there any way to > ignore authority/add itional answers that I get from replies?] Yes. The delegation is broken. Having a NS pointing at a nonexistant name is a big no no. It's just a matter of time for a delegation like this to break. > root@cbj-cdns21 # dig @wan1.fis.com.my www.wip.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my www.wip.fis.com.my ; (1 > server found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43777 ;; flags: qr > aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: > recursion requested but not available > > ;; QUESTION SECTION: > ;www.wip.fis.com.my.IN A > > ;; ANSWER SECTION: > www.wip.fis.com.my. 5 IN A 175.143.6.165 > www.wip.fis.com.my. 5 IN A 202.188.242.137 > www.wip.fis.com.my. 5 IN A 210.19.86.117 > > ;; AUTHORITY SECTION: > wip.fis.com.my. 3600IN NS ns1.wip.fis.com.my. > > ;; Query time: 7 msec > ;; SERVER: 202.188.242.130#53(202.188.242.130) > ;; WHEN: Wed Nov 18 17:44:59 MYT 2015 > ;; MSG SIZE rcvd: 102 > > > 4. Lo and behold, ns1.wip.fis.com.my doesn't exist! And because of > this all m y queries for www.fis.com.my are failing. Am I correct? > > root@sputnik # dig @wan1.fis.com.my ns1.wip.fis.com.my > > ; <<>> DiG 9.9.5-P1 <<>> @wan1.fis.com.my ns1.wip.fis.com.my ; (1 > server found) ;; global options: +cmd ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 37457 ;; flags: > qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: > recursion requested but not available > > ;; QUESTION SECTION: > ;ns1.wi
RE: Query on ignoring additional section returned in replies
Is this hosted on some sort of load-balancer? Add a +norecurse to your dig and see how that changes things. Regards, Bob ___ 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: Query on ignoring additional section returned in replies
In message <5b818b25da9e40ebbff0e3d6dfec1...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: > Even with a broken delegation its like always resolvable with Google DNS or= > even Open DNS. Are there any BIND specific workarounds? The other nameservers will also fail with the right query sequence. Just because something resolves, it doesn't mean that there is not a error. It is just good luck that Google's server resolve. It's so broken that http://dnscheck.ripe.net can't even start checking the delegation. Delegation Begin testing delegation for wip.fis.com.my. Name servers listed at parent: wan1.fis.com.my,wan2.fis.com.my,wan3.fis.com.my,wan4.fis.com.my Failed to find name servers of wip.fis.com.my/IN. No name servers found at child. Not enough nameserver information was found to test the zone wip.fis.com.my, but an IP address lookup succeeded in spite of that. Done testing delegation for wip.fis.com.my. This is a case of Garbage-In - Garbage Out (lookup failure). RFC 1035 states that nameserver each side of the delegation need to stay the same. This rule is there in part to stop issues like this. Fis.com.my need to fix their nameservers. The NS records need to be made consistent. There needs to be address records for the nameservers. Mark > -Original Message- > From: Mark Andrews [mailto:ma...@isc.org] > Sent: Wednesday, November 18, 2015 6:26 PM > To: Elias Ahmed Kamal > Cc: bind-users@lists.isc.org > Subject: Re: Query on ignoring additional section returned in replies > > > In message <659dec986e9347369634488991f6e...@pvsvrexc06.ad.tmres.my>, Elias= > Ahm ed Kamal writes: > > Hi guys, > > > > I'm having issues resolving www.fis.com.my. I'm trying to tell > > fis.com.my tha t its an issue at their end, but when checking against > > 8.8.8.8 it resolves fi neso it MUST be a problem with me. > > > > 1. Lookups fail, this is clear enough > > > > root@sputnik # dig @localhost www.fis.com.my > > > > ; <<>> DiG 9.9.5-P1 <<>> @localhost www.fis.com.my ; (1 server found) > > ;; global options: +cmd ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51246 ;; flags: > > qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;www.fis.com.my.IN A > > > > ;; Query time: 0 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Wed Nov 18 17:40:58 MYT 2015 > > ;; MSG SIZE rcvd: 43 > > > > > > 2. All of fis.com.my's authoritative nameservers answer and are consisten= > t > >It tells me that www.wip.fis.com.my is a CNAME for www.fis.com.my > >And that wan1-wan4.fis.com.my is the authoritative servers for > > *.wip.fis.c om.my > > > > root@sputnik # dig @ns1.fis.com.my www.fis.com.my > > > > ; <<>> DiG 9.9.5-P1 <<>> @ns1.fis.com.my www.fis.com.my ; (1 server > > found) ;; global options: +cmd ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33357 ;; flags: qr > > aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5 ;; WARNING: > > recursion requested but not available > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags:; udp: 4096 > > ;; QUESTION SECTION: > > ;www.fis.com.my.IN A > > > > ;; ANSWER SECTION: > > www.fis.com.my. 38400 IN CNAME www.wip.fis.com.my. > > > > ;; AUTHORITY SECTION: > > wip.fis.com.my. 38400 IN NS wan1.fis.com.my. > > wip.fis.com.my. 38400 IN NS wan4.fis.com.my. > > wip.fis.com.my. 38400 IN NS wan3.fis.com.my. > > wip.fis.com.my. 38400 IN NS wan2.fis.com.my. > > > > ;; ADDITIONAL SECTION: > > wan1.fis.com.my.38400 IN A 202.188.242.130 > > wan2.fis.com.my.38400 IN A 210.19.86.114 > > wan3.fis.com.my.38400 IN A 175.143.6.162 > > wan4.fis.com.my.38400 IN A 219.92.28.106 > > > > ;; Query time: 8 msec > > ;; SERVER: 202.188.242.135#53(202.188.242.135) > > ;; WHEN: Wed Nov 18 17:41:09 MYT 2015 > > ;; MSG SIZE rcvd: 205 > > > > > > 3. I now do a 3rd lookup test against wan1.fis.com.my for > > www.wip.fis.com.my and get the answers > >BUT, the nameserver is also returning an authority section saying wip.= > fis. > > com.my is now served by ns1.wip.fis.com.my > >[Previously I know wip.fis.com.my was served by > > wan1-wan4.fis.com.my, but now somehow I'm caching ns1.wip.fis.com.my inst= > ead] > >[Question: Is it the expected behaviour that this new NS will > > override the previous NS for wip.fis.com.my? And is there any way to > > ignore authority/add itional answers that I get from replies?] > > Yes. The delegation is broken. Having a NS pointing at a nonexistant name= > is a big no no. It's just a matter of time for a delegation like this to = > break. > > > root@cbj-cdns21 # dig @wan1.fis.com.my www.wip.fis.com.my > > > > ;
Re: Query on ignoring additional section returned in replies
Am 18.11.2015 um 12:34 schrieb Mark Andrews: In message <5b818b25da9e40ebbff0e3d6dfec1...@pvsvrexc06.ad.tmres.my>, Elias Ahm ed Kamal writes: Even with a broken delegation its like always resolvable with Google DNS or= even Open DNS. Are there any BIND specific workarounds? The other nameservers will also fail with the right query sequence. Just because something resolves, it doesn't mean that there is not a error. It is just good luck that Google's server resolve. It's so broken that http://dnscheck.ripe.net can't even start checking the delegation. Delegation Begin testing delegation for wip.fis.com.my. Name servers listed at parent: wan1.fis.com.my,wan2.fis.com.my,wan3.fis.com.my,wan4.fis.com.my Failed to find name servers of wip.fis.com.my/IN. No name servers found at child. Not enough nameserver information was found to test the zone wip.fis.com.my, but an IP address lookup succeeded in spite of that. Done testing delegation for wip.fis.com.my. This is a case of Garbage-In - Garbage Out (lookup failure) http://www.intodns.com/wip.fis.com.my when a result looks like below it needs to be fixed and "Are there any BIND specific workarounds?" is the wrong question becaus even if - the domain owner is not in the position to place workarounds somewhere else Error Missing nameservers reported by parent FAIL: The following nameservers are listed at your nameservers as nameservers for your domain, but are not listed at the parent nameservers (see RFC2181 5.4.1). You need to make sure that these nameservers are working.If they are not working ok, you may have problems! ns1.wip.fis.com.my Error Missing nameservers reported by your nameservers ERROR: One or more of the nameservers listed at the parent servers are not listed as NS records at your nameservers. The problem NS records are: wan2.fis.com.my wan4.fis.com.my wan1.fis.com.my wan3.fis.com.my This is listed as an ERROR because there are some cases where nasty problems can occur (if the TTLs vary from the NS records at the root servers and the NS records point to your own domain, for example). 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
Resolution differences for getaddrinfo versus host/dig/delv
All, This isn't strictly a "bind" question, but it kind-of, sort-of is. We've got an Office 365 tenancy, along with offsite voicemail. We send our SIP connections to a hostname: $GUID.um.outlook.com This hostname is resolvable using "dig" & "host", but on Linux (glibc 2.20) the "ping", "telnet" and "nc" commands return "unknown host" or equivalent. I suspect getaddrinfo isn't parsing the DNS response for some reason. Can anyone cast their eye over the response to the query below and guess why host/dig/delv think it's OK, but glibc getaddrinfo() apparently doesn't? $ dig blahblah.um.outlook.com ;; ANSWER SECTION: blahblah.um.outlook.com. 118 IN CNAME *.um.outlook.com.glbdns2.microsoft.com. *.um.outlook.com.glbdns2.microsoft.com. 60 IN CNAME wildcard-emeawest.um.outlook.com. wildcard-emeawest.um.outlook.com. 60 IN A 157.55.9.252 (It's a wildcard, any left-hand-side will work) Obviously the *.thing on the RHS of the first CNAME is weird, but is it illegal? If you're of a sensitive disposition I'd avoid digging (pardon the pun) into the minutiae of the zone surrounding those records e.g. enclosing SOA - they're very seriously odd. Cheers, Phil ___ 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: Resolution differences for getaddrinfo versus host/dig/delv
Phil Mayers wrote: > > This hostname is resolvable using "dig" & "host", but on Linux (glibc 2.20) > the "ping", "telnet" and "nc" commands return "unknown host" or equivalent. `ping` fails for me on FreeBSD but not MacOS. > I suspect getaddrinfo isn't parsing the DNS response for some reason. Well, sort of. The failure is because the resolver is doing name validity checks along the chain of aliases, and an intermediate wildcard is not a valid hostname. For instance, have a look at https://svnweb.freebsd.org/base/head/lib/libc/net/gethostbydns.c?view=markup#l140 Note the name_ok function pointer which is set to res_hnok for forward queries, and res_hnok checks LDH syntax (plus underscores). The old libbind code is similar, as is glibc. Tony. -- f.anthony.n.finchhttp://dotat.at/ Fair Isle, South Faeroes: Cyclonic 4 or 5, occasionally 6, becoming northeasterly 5 to 7, increasing gale 8 for a time. Rough or very rough, occasionally moderate. Rain or showers. Moderate or good. ___ 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: Query on ignoring additional section returned in replies
In article , Reindl Harald wrote: > when a result looks like below it needs to be fixed and "Are there any > BIND specific workarounds?" is the wrong question becaus even if - the > domain owner is not in the position to place workarounds somewhere else While that's the pedantically correct answer, in practice it doesn't work well when your users complain "Google DNS deals with it, why don't you?" Your users don't care what happens to people somewhere else, they just want to get their work done. Google understands that there are lots of broken DNS configurations out there, but their users don't want to hear that it's someone else's fault. -- Barry Margolin Arlington, MA ___ 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: Query on ignoring additional section returned in replies
Am 18.11.2015 um 16:47 schrieb Barry Margolin: In article , Reindl Harald wrote: when a result looks like below it needs to be fixed and "Are there any BIND specific workarounds?" is the wrong question becaus even if - the domain owner is not in the position to place workarounds somewhere else While that's the pedantically correct answer, in practice it doesn't work well when your users complain "Google DNS deals with it, why don't you?" Your users don't care what happens to people somewhere else, they just want to get their work done. the pedantically correct answer would have been "if you can't convince your DNS operator that something is wrong fire him and seek for somebody with a clue what he is doing which implies running tools like the quoted regulary" Google understands that there are lots of broken DNS configurations out there, but their users don't want to hear that it's someone else's fault the users shouldn't take notice of such config bugs at all because it should not last for longer than a few hours until get proactive fixed 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: Query on ignoring additional section returned in replies
On 11/18/15, 10:47 AM, "bind-users-boun...@lists.isc.org on behalf of Barry Margolin" wrote: >In article , > Reindl Harald wrote: > >> when a result looks like below it needs to be fixed and "Are there any >> BIND specific workarounds?" is the wrong question becaus even if - the >> domain owner is not in the position to place workarounds somewhere else > >While that's the pedantically correct answer, in practice it doesn't >work well when your users complain "Google DNS deals with it, why don't >you?" Your users don't care what happens to people somewhere else, they >just want to get their work done. > >Google understands that there are lots of broken DNS configurations out >there, but their users don't want to hear that it's someone else's fault. Yes, exactly. Having spent a few decades wearing the DNS admin hat in environments with large user bases, I'd be rich if I had a few cents for all the times I've spent "digging" around to prove it's not "our" problem but modern users don't care when they can just use Google DNS and it works magically. "It's an upstream issue Google is just working around." "OK, so why can't you?" Following up with the remote admins to fix the issue is often a joke, this isn't the early Internet where most people had a clue, cared, listened to zone contact mailboxes, or were enabled to make timely changes (in all fairness with many orgs). :-) The upstream brokenness comes in various forms so there's no one-size-fits-all, but for what it's worth to the OP some sites that gave us issues in 9.9.x seems to work in 9.10.x after we explicitly changed dnssec-validation to auto. Can't fully explain that, but we literally had queries running in a loop against google, 9.9.x and 9.10.x while we twiddled different things and zones with upstream issues like this would not resolve via 9.9.x but started working fine with 9.10.x. ___ 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: Query on ignoring additional section returned in replies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 2015-11-18 at 10:47 -0500, Barry Margolin wrote:
> While that's the pedantically correct answer, in practice it doesn't
> work well when your users complain "Google DNS deals with it, why
> don't you?" Your users don't care what happens to people somewhere
> else, they just want to get their work done.
zone "fis.com.my" {
type forward;
forwarders { 8.8.8.8; };
};
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
iEYEARECAAYFAlZMwO8ACgkQL6j7milTFsE3swCbBMM7SFbmOg+6VMf0Myy8g01E
5OwAnjhLO9GzSEw/bu3cs97awKHXUeLZ
=k/ga
-END PGP 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: Query on ignoring additional section returned in replies
In article , Reindl Harald wrote: > Am 18.11.2015 um 16:47 schrieb Barry Margolin: > > In article , > > Reindl Harald wrote: > > > >> when a result looks like below it needs to be fixed and "Are there any > >> BIND specific workarounds?" is the wrong question becaus even if - the > >> domain owner is not in the position to place workarounds somewhere else > > > > While that's the pedantically correct answer, in practice it doesn't > > work well when your users complain "Google DNS deals with it, why don't > > you?" Your users don't care what happens to people somewhere else, they > > just want to get their work done. > > the pedantically correct answer would have been "if you can't convince > your DNS operator that something is wrong fire him and seek for somebody > with a clue what he is doing which implies running tools like the quoted > regulary" It's not your DNS operator, it's someone else's. > > > Google understands that there are lots of broken DNS configurations out > > there, but their users don't want to hear that it's someone else's fault > > the users shouldn't take notice of such config bugs at all because it > should not last for longer than a few hours until get proactive fixed The OP said he reported the problem to the domain owner. They ignored his report, because Google DNS doesn't have a problem resolving their domain. -- Barry Margolin Arlington, MA ___ 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: Query on ignoring additional section returned in replies
On 11/18/15, 1:19 PM, "bind-users-boun...@lists.isc.org on behalf of Carl
Byington" wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>On Wed, 2015-11-18 at 10:47 -0500, Barry Margolin wrote:
>> While that's the pedantically correct answer, in practice it doesn't
>> work well when your users complain "Google DNS deals with it, why
>> don't you?" Your users don't care what happens to people somewhere
>> else, they just want to get their work done.
>
>zone "fis.com.my" {
> type forward;
> forwarders { 8.8.8.8; };
>};
Makes me laugh (and cry), but have done exactly this... However, I
considered it an ugly hack vs real solution. Glad to know the ugly hack
is at least used elsewhere. :-)
___
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: Resolution differences for getaddrinfo versus host/dig/delv
In message <564c6ced.6060...@imperial.ac.uk>, Phil Mayers writes: > All, > > This isn't strictly a "bind" question, but it kind-of, sort-of is. > > We've got an Office 365 tenancy, along with offsite voicemail. We send > our SIP connections to a hostname: > > $GUID.um.outlook.com > > This hostname is resolvable using "dig" & "host", but on Linux (glibc > 2.20) the "ping", "telnet" and "nc" commands return "unknown host" or > equivalent. > > I suspect getaddrinfo isn't parsing the DNS response for some reason. > > Can anyone cast their eye over the response to the query below and guess > why host/dig/delv think it's OK, but glibc getaddrinfo() apparently doesn't? > > $ dig blahblah.um.outlook.com > > ;; ANSWER SECTION: > blahblah.um.outlook.com. 118 IN CNAME > *.um.outlook.com.glbdns2.microsoft.com. > *.um.outlook.com.glbdns2.microsoft.com. 60 IN CNAME > wildcard-emeawest.um.outlook.com. > wildcard-emeawest.um.outlook.com. 60 IN A 157.55.9.252 > > (It's a wildcard, any left-hand-side will work) > > Obviously the *.thing on the RHS of the first CNAME is weird, but is it > illegal? As a hostname lookup, yes. RFC 952 + RFC 1123 define a valid hostname. Even with IDN this is a illegal hostname. As a record in the DNS, no. The DNS is a distributed database that can contain lots of things. dig, delve are designed to be general purpose DNS lookup tools. host has a general lookup component to it though it is focused on hosnames. getaddrinfo is strictly address lookups of hostnames. It applies the stricter set of rules to the data returned. > If you're of a sensitive disposition I'd avoid digging (pardon the pun) > into the minutiae of the zone surrounding those records e.g. enclosing > SOA - they're very seriously odd. > > Cheers, > Phil > ___ > 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: Resolution differences for getaddrinfo versus host/dig/delv
On Wed, Nov 18, 2015 at 12:19:57PM +,
Phil Mayers wrote
a message of 44 lines which said:
> I suspect getaddrinfo isn't parsing the DNS response for some reason.
...
> Obviously the *.thing on the RHS of the first CNAME is weird, but is it
> illegal?
Yes, for a *host* name (no for a *domain* name). See Tony Finch's
explanation.
In the GNU libc, the relevant code is in resolv/res_comp.c and
includes this function, which tests that a *host* name is
[a-z0-9\.\-]+ :
#define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
|| ((c) >= 0x61 && (c) <= 0x7a))
#define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
#define borderchar(c) (alphachar(c) || digitchar(c))
#define middlechar(c) (borderchar(c) || hyphenchar(c) || underscorechar(c))
#define domainchar(c) ((c) > 0x20 && (c) < 0x7f)
int
res_hnok(const char *dn) {
int pch = PERIOD, ch = *dn++;
while (ch != '\0') {
int nch = *dn++;
if (periodchar(ch)) {
(void)NULL;
} else if (periodchar(pch)) {
if (!borderchar(ch))
return (0);
} else if (periodchar(nch) || nch == '\0') {
if (!borderchar(ch))
return (0);
} else {
if (!middlechar(ch))
return (0);
}
pch = ch, ch = nch;
}
return (1);
}
___
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: Resolution differences for getaddrinfo versus host/dig/delv
And whomever added underscorechar() to that should be shot. There
are good reasons to be able to distingish hostnames from other sorts
of text. Adding '_' doesn't help one do that as it is impossible to
distinguish underscored text from underscored hostnames.
T h i s _i s _a _t i t l e
Mark
In message <20151118212633.ga18...@sources.org>, Stephane Bortzmeyer writes:
> On Wed, Nov 18, 2015 at 12:19:57PM +,
> Phil Mayers wrote
> a message of 44 lines which said:
>
> > I suspect getaddrinfo isn't parsing the DNS response for some reason.
> ...
> > Obviously the *.thing on the RHS of the first CNAME is weird, but is it
> > illegal?
>
> Yes, for a *host* name (no for a *domain* name). See Tony Finch's
> explanation.
>
> In the GNU libc, the relevant code is in resolv/res_comp.c and
> includes this function, which tests that a *host* name is
> a-z0-9\.\-+:
>
> #define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
> || ((c) >= 0x61 && (c) <= 0x7a))
> #define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
>
> #define borderchar(c) (alphachar(c) || digitchar(c))
> #define middlechar(c) (borderchar(c) || hyphenchar(c) ||
> underscorechar(c))
> #define domainchar(c) ((c) > 0x20 && (c) < 0x7f)
>
> int
> res_hnok(const char *dn) {
> int pch = PERIOD, ch = *dn++;
>
> while (ch != '\0') {
> int nch = *dn++;
>
> if (periodchar(ch)) {
> (void)NULL;
> } else if (periodchar(pch)) {
> if (!borderchar(ch))
> return (0);
> } else if (periodchar(nch) || nch == '\0') {
> if (!borderchar(ch))
> return (0);
> } else {
> if (!middlechar(ch))
> return (0);
> }
> pch = ch, ch = nch;
> }
> return (1);
> }
> ___
> 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: Resolution differences for getaddrinfo versus host/dig/delv
Mark Andrews writes:
>
> And whomever added underscorechar() to that should be shot. There
> are good reasons to be able to distingish hostnames from other sorts
> of text. Adding '_' doesn't help one do that as it is impossible to
> distinguish underscored text from underscored hostnames.
>
> T h i s _i s _a _t i t l e
Lets try the example again.
_T_h_i_s__i_s__a__t_i_t_l_e
> Mark
>
> In message <20151118212633.ga18...@sources.org>, Stephane Bortzmeyer writes:
> > On Wed, Nov 18, 2015 at 12:19:57PM +,
> > Phil Mayers wrote
> > a message of 44 lines which said:
> >
> > > I suspect getaddrinfo isn't parsing the DNS response for some reason.
> > ...
> > > Obviously the *.thing on the RHS of the first CNAME is weird, but is it
> > > illegal?
> >
> > Yes, for a *host* name (no for a *domain* name). See Tony Finch's
> > explanation.
> >
> > In the GNU libc, the relevant code is in resolv/res_comp.c and
> > includes this function, which tests that a *host* name is
> > a-z0-9\.\-+:
> >
> > #define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
> >|| ((c) >= 0x61 && (c) <= 0x7a))
> > #define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
> >
> > #define borderchar(c) (alphachar(c) || digitchar(c))
> > #define middlechar(c) (borderchar(c) || hyphenchar(c) ||
> > underscorechar(c))
> > #define domainchar(c) ((c) > 0x20 && (c) < 0x7f)
> >
> > int
> > res_hnok(const char *dn) {
> > int pch = PERIOD, ch = *dn++;
> >
> > while (ch != '\0') {
> > int nch = *dn++;
> >
> > if (periodchar(ch)) {
> > (void)NULL;
> > } else if (periodchar(pch)) {
> > if (!borderchar(ch))
> > return (0);
> > } else if (periodchar(nch) || nch == '\0') {
> > if (!borderchar(ch))
> > return (0);
> > } else {
> > if (!middlechar(ch))
> > return (0);
> > }
> > pch = ch, ch = nch;
> > }
> > return (1);
> > }
> > ___
> > 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
--
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: does bind depends on system DNS settings for lookup?
"Iterative" resolution means following the delegation hierarchy (by sending queries with the RD flag set to 0) to get an answer; "recursive" resolution means sending a query off (with the RD flag set to 1) and relying on the other party to get a complete answer back to you. In order for recursive resolution to be successful, the "upstream" resolver must honor recursion for the client; it signals its willingness to do so by setting the RA flag in its responses to 1. The distinction between the two types of resolution is kind of like the difference between hiring people with specific skills (e.g. carpenter, plumber, electrician) to work on your house, where you have to do all of the work of identifying/locating them, giving them tasks, arranging payment, etc., versus hiring a general contractor and letting them take care of all the co-ordination and details. The confusion comes in when it is stated that a DNS node provides "recursive service". What that means, is that, *as*a*provider*, the node receives and honors recursive queries from its clients, but *as*a*consumer*, it typically uses iterative resolution to get the answers. So it's essentially "recursive" on one side (queries come in with RD=1), "iterative" on the other (queries go out with RD=0). Once one understands the provider/consumer distinction, things become a lot clearer. As for the difference between stub resolvers and forwarders; in protocol-architecture terms, there isn't any difference. They both generate recursive queries and rely on other recursion-honoring DNS nodes to resolve names for them. In *system* architecture terms, however, a stub resolver is only for the benefit of itself, whereas "forwarder" usually refers to a device, server or subsystem that provides DNS resolution to multiple clients. Again, the consumer/provider distinction comes into play. As a shared, scaled resource, forwarders are more likely to provide "value-add" services (such as DNSSEC validation), and to be implemented in a way that maximizes resilience and performance (e.g. running on Anycast addresses). The previous paragraph should not be read as an *endorsement* of forwarding, however. Personally, I think forwarding is over-used and abused, and I prefer other methods of providing nameservice to clients, e.g. replication, iterative resolution, or, if necessary to work around broken delegations, "stub" zones. Forwarding should, in my opinion, only be used when one faces hard connectivity constraints that can't be accommodated any other way, e.g. needing to resolve Internet names, but within security policies and/or routing constraints which don't allow direct contact with Internet nameservers. And don't even get me started on forwarding *chains*. Grrr... - Kevin -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Reindl Harald Sent: Wednesday, November 18, 2015 4:42 AM To: bind-users@lists.isc.org Subject: Re: does bind depends on system DNS settings for lookup? Am 18.11.2015 um 05:42 schrieb Dil Lee: > This is probably a dummy question. > My understand of bind in handling non-authoritative queries is: > 1) forward mode. It just forward the client queries to an upstream DNS > server, which is defined in "forwarders" directive. > 2) recursive mode. It actually start asking from root DNS server, then > 2nd level DNS server etc till it finally get an authoritative answer > for the host in question. > Non of these modes seems to depends/relates to the system DNS settings > on the host which bind is running on, e.g. /etc/resolv.conf . AMIRITE? no beause it would not make sense to do so when /etc/resolv.conf contains only 127.0.0.1 which is a common dns-cache setup on inbound mailservers ___ 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: Resolution differences for getaddrinfo versus host/dig/delv
Mark Andrews writes:
>
> Mark Andrews writes:
> >
> > And whomever added underscorechar() to that should be shot. There
> > are good reasons to be able to distingish hostnames from other sorts
> > of text. Adding '_' doesn't help one do that as it is impossible to
> > distinguish underscored text from underscored hostnames.
> >
> > T h i s _i s _a _t i t l e
>
> Lets try the example again.
>
> _T_h_i_s__i_s__a__t_i_t_l_e
Or even better
_A_ _q_u_e_s_t_i_o_n_ _a_b_o_u_t_
_e_x_a_m_p_l_e_._c_o_m_.
>
> > Mark
> >
> > In message <20151118212633.ga18...@sources.org>, Stephane Bortzmeyer writes
> :
> > > On Wed, Nov 18, 2015 at 12:19:57PM +,
> > > Phil Mayers wrote
> > > a message of 44 lines which said:
> > >
> > > > I suspect getaddrinfo isn't parsing the DNS response for some reason.
> > > ...
> > > > Obviously the *.thing on the RHS of the first CNAME is weird, but is it
> > > > illegal?
> > >
> > > Yes, for a *host* name (no for a *domain* name). See Tony Finch's
> > > explanation.
> > >
> > > In the GNU libc, the relevant code is in resolv/res_comp.c and
> > > includes this function, which tests that a *host* name is
> > > a-z0-9\.\-+:
> > >
> > > #define alphachar(c) (((c) >= 0x41 && (c) <= 0x5a) \
> > > || ((c) >= 0x61 && (c) <= 0x7a))
> > > #define digitchar(c) ((c) >= 0x30 && (c) <= 0x39)
> > >
> > > #define borderchar(c) (alphachar(c) || digitchar(c))
> > > #define middlechar(c) (borderchar(c) || hyphenchar(c) ||
> > > underscorechar(c))
> > > #define domainchar(c) ((c) > 0x20 && (c) < 0x7f)
> > >
> > > int
> > > res_hnok(const char *dn) {
> > > int pch = PERIOD, ch = *dn++;
> > >
> > > while (ch != '\0') {
> > > int nch = *dn++;
> > >
> > > if (periodchar(ch)) {
> > > (void)NULL;
> > > } else if (periodchar(pch)) {
> > > if (!borderchar(ch))
> > > return (0);
> > > } else if (periodchar(nch) || nch == '\0') {
> > > if (!borderchar(ch))
> > > return (0);
> > > } else {
> > > if (!middlechar(ch))
> > > return (0);
> > > }
> > > pch = ch, ch = nch;
> > > }
> > > return (1);
> > > }
> > > ___
> > > 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
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
--
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
