Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
> On 6. 5. 2022, at 8:19, Bjørn Mork wrote: > > How about configuring forwarder(s) if you have to operate a resolver in > such an environment? Hoping that the answer from the intercepting > server isn't too different from what you'd expect from a forwarder. I would personally go with VPN as a first option. Other than that this is classical example of GIGO (garbage in, garbage out). Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
Am 06.05.22 um 08:19 schrieb Bjørn Mork: Mark Andrews writes: It’s a long known issue with so called “Transparent” DNS proxies/accelerators/firewalls. Iterative resolvers expect to talk to authoritative servers. They ask questions differently to the way they do when they talk to a recursive server. Answers from different levels of the DNS hierarchy for the same question are different. If you just cache and return the previous answer you break iterative lookups. The answers from recursive servers are different to those from authoritative servers. You get the same sort of problem in many hotels if you have an iterative resolver on your portable devices. Switching named to use a public recursive server that supports DNSSEC in forward only mode helps sometimes. It really depends on what the middleware is doing. How about configuring forwarder(s) if you have to operate a resolver in such an environment? Hoping that the answer from the intercepting server isn't too different from what you'd expect from a forwarder the problem is that this middleware crap operates on the protocol level in the past our CISCO ISP router with "DNS ALG" even rewrote zone transfers and invented a zero TTL for each and every CNAME it saw means our secondary nameserver hat completly different zone files than the master you don't expect that and watch a zone transfer on both ends with wireshark solved that riddle so from the moment on some device thinking it's smart about DNS you are lost -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
On 5/5/2022 11:19 PM, Bjørn Mork wrote: Mark Andrews writes: How about configuring forwarder(s) if you have to operate a resolver in such an environment? Hoping that the answer from the intercepting server isn't too different from what you'd expect from a forwarder. In my environment, I'm operating 3 nameservers authoritative for a bunch of domains. If it's crapping what I'm pulling in from outside it's probably crapping what I'm sending to the rest of the world. However the real reason for me? The real reason is _I_ pay _them_ for connectivity. Therefore _they_ give it to me the way _I_ want, not the way _they_ want. I have the gold, and he who has the gold makes the rules. As for the hotel scenario simple answer there. Never stay at that hotel again and inform them as to why. Why do people insist on rewarding poor service with money? Ted -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
On 5/6/2022 12:45 AM, Reindl Harald wrote: in the past our CISCO ISP router with "DNS ALG" even rewrote zone transfers and invented a zero TTL for each and every CNAME it saw Probably doing that to retaliate for dynamic DNS providers abusing DNS and people abusing dynamic DNS providers for being cheapskates and saving a nickle on a real static IP. You got caught in the crossfire of that particular war. Ted -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
> On 6. 5. 2022, at 12:24, Ted Mittelstaedt wrote: > > You got caught in the crossfire of that particular war. Nah, it was just crappy implementation and somebody at Cisco not understanding the RFC. I remember that - at my previous job we had a ticket opened with them about this particular issue. They were crippling the TTL to 0 in the wrong direction. Ondřej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Hell breaks loose in the afternoon with format error from X.X.X.X#53 resolving ./NS: non-improving referral
Am 06.05.22 um 12:24 schrieb Ted Mittelstaedt: On 5/6/2022 12:45 AM, Reindl Harald wrote: in the past our CISCO ISP router with "DNS ALG" even rewrote zone transfers and invented a zero TTL for each and every CNAME it saw Probably doing that to retaliate for dynamic DNS providers abusing DNS and people abusing dynamic DNS providers for being cheapskates and saving a nickle on a real static IP. You got caught in the crossfire of that particular war nonsense - it's the cisco default behavior no ip nat service alg udp dns no ip nat service alg tcp dns -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Confused by parental-source documentation
Hi Nick, Thanks for bringing this to our attention. Yes, this is a copy paste error. I think it can be removed, although we could change it because you should make sure the address matches with what the parental agent expects. Best regards, Matthijs On 01-05-2022 07:18, Nick Tait via bind-users wrote: Hi list. I've been reading the latest BIND9 documentation on the new DNSSEC features, and section 4.2.28.1 got me horribly confused: /The following options apply to DS queries sent to //|parental-agents|//:/ /|parental-source|/ /|parental-source|//determines which local source address, and optionally UDP port, is used to send parental DS queries. This address must appear in the secondary server’s //|parental-agents|//zone clause. This statement sets the //|parental-source|//for all zones, but can be overridden on a per-zone or per-view basis by including a //|parental-source|//statement within the //|zone|//or //|view|//block in the configuration file./ No matter how many times I read the sentence in blue font, I couldn't make sense of it... I finally realised that the parental-source paragraph is almost identical to the documentation for notify-source: /|notify-source|/ /|notify-source|//determines which local source address, and optionally UDP port, is used to send NOTIFY messages. This address must appear in the secondary server’s //|primaries|//zone clause or in an //|allow-notify|//clause. This statement sets the //|notify-source|//for all zones, but can be overridden on a per-zone or per-view basis by including a //|notify-source|//statement within the //|zone|//or //|view|//block in the configuration file./ And so I can only assume that the problematic sentence in parental-source (i.e. "/This address must appear in the secondary server’s //|parental-agents|//zone clause./") is a copy-paste error? If that is the case can the sentence please be removed from the documentation? Or if I'm mistaken can anybody please give an example to explain what this is trying to say? Thanks, Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Server conflicts with docker0 interface
Hi folks, Thank you for the reply. I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as suggested and it seems that the order fixed the issue.Now my Bind9 clients are getting ip 192.168.0.10 favorably. Anyway, I'd like to eliminate ip 172.17.0.1 from name resolutions.I never added this ip in my zone files and I don't have any DNS clients coming from this network (at least not at the moment). It makes no sense to me. Why does Bind9 insist on adding the docker0 ip in name resolutions.That is a mystery. Kind regards,Mauricio Em quinta-feira, 5 de maio de 2022 21:44:50 GMT+1, Nick Tait via bind-users escreveu: On 6/05/2022 7:51 am, Grant Taylor via bind-users wrote: On my Bind9 server, I have the following zone-files: forward.example.lan.db: ns1 IN A 192.168.0.10 ns1 IN fe80::f21f:afff:fe5d:be90 I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone. So if your client is still receiving that address in addition to the 192.168.0.10 address, then something else is happening outside of BIND. Mauricio, was 172.17.0.1 in the zone file at any time in the past? Because if so, I'm betting that the problem is simply that after you removed it, you neglected to increment the SOA serial number? (In case you weren't aware the serial number needs to be increased every time you change the zone file.) Can you please try updating the "1 ; Serial" line to "2 ; Serial" as shown below: $TTL 604800@ IN SOA ns1.example.lan. hostmaster.example.lan. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL Once you've done that, run "sudo rndc reload" on your the primary DNS server for the zone (or alternatively restart BIND), and see if that makes a difference? Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Server conflicts with docker0 interface
I just message you and the problem happened again ... C:\Users\Mauricioλ ping ns1.example.lan Pinging ns1.example.lan [172.17.0.1] with 32 bytes of data:Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable. Ping statistics for 172.17.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), C:\Users\Mauricioλ ping ns1.example.lan Pinging ns1.example.lan [172.17.0.1] with 32 bytes of data:Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable. Ping statistics for 172.17.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), C:\Users\Mauricioλ ping ns1.example.lan Pinging ns1.example.lan [172.17.0.1] with 32 bytes of data:Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable.Reply from 84.116.236.63: Destination net unreachable. Ping statistics for 172.17.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), = (Em sexta-feira, 6 de maio de 2022 14:38:37 GMT+1, MaurÃcio Penteado via bind-users escreveu: Hi folks, Thank you for the reply. I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as suggested and it seems that the order fixed the issue.Now my Bind9 clients are getting ip 192.168.0.10 favorably. Anyway, I'd like to eliminate ip 172.17.0.1 from name resolutions.I never added this ip in my zone files and I don't have any DNS clients coming from this network (at least not at the moment). It makes no sense to me. Why does Bind9 insist on adding the docker0 ip in name resolutions.That is a mystery. Kind regards,Mauricio Em quinta-feira, 5 de maio de 2022 21:44:50 GMT+1, Nick Tait via bind-users escreveu: On 6/05/2022 7:51 am, Grant Taylor via bind-users wrote: On my Bind9 server, I have the following zone-files: forward.example.lan.db: ns1 IN A 192.168.0.10 ns1 IN fe80::f21f:afff:fe5d:be90 I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone. So if your client is still receiving that address in addition to the 192.168.0.10 address, then something else is happening outside of BIND. Mauricio, was 172.17.0.1 in the zone file at any time in the past? Because if so, I'm betting that the problem is simply that after you removed it, you neglected to increment the SOA serial number? (In case you weren't aware the serial number needs to be increased every time you change the zone file.) Can you please try updating the "1 ; Serial" line to "2 ; Serial" as shown below: $TTL 604800@ IN SOA ns1.example.lan. hostmaster.example.lan. ( 2 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL Once you've done that, run "sudo rndc reload" on your the primary DNS server for the zone (or alternatively restart BIND), and see if that makes a difference? Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
DNS traffic tracking
Hi all, I have the following problem: I run a caching dns server using bind9 v9.10.3 in a gateway device which it serves several internal LAN IP addresses (clients). I am doing some traffic accounting in the gateway device using Linux conntrack so as to calculate the generated client traffic (mostly HTTP/HTTPs related, in/out) so as to charge the volume consumed. What I cannot charge is the actual DNS traffic that each client is generating, since each client DNS request is actually two sessions, one between client and gateway device and the other between gateway and upstream DNS servers. It seems to me not fare to charge the traffic observed between the client and the gateway since the internal DNS traffic includes cached responses and may be much higher from the actual DNS traffic observed on the WAN side (gateway - upstream). I was wondering if there is a solution to this. If bind9 has any feature that can be used to track the WAN DNS traffic and understand from which client was first requested/generated. In this way I will be able to differentiate the DNS traffic per client and avoid accounting DNS traffic that the gateway generated for its own services. Just as an additional note on this, I had in the past the same issue with the proxy traffic that this same gateway was generating and found a solution by using TPROXY feature of the squid proxy, which exposes the real internal client IP address at the WAN traffic which can later be NATed. Thanx for any ideas, Alex -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 Server conflicts with docker0 interface
On 7/05/2022 1:38 am, Maurà cio Penteado via bind-users wrote: I added the A-record "ns1 IN A 172.17.0.1" to my zone-file as suggested and it seems that the order fixed the issue. Now my Bind9 clients are getting ip 192.168.0.10 favorably. Hi Mauricio. I don't think anyone suggested that you add that address to your zone file? My suggestion was to simply update the SOA serial number. Nick. -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Turn To Bind-Users For Advice And Help
Hi, We are encountering a problem that SOA records had data residue when deleting a new-created zone with BIND 9. The operation procedures are as below: 1. Firstly, a zone named test18.cn was added with BIND 9. The command "dig -t SOA test18.cn" shows the corresponding SOA record was created successfully. 2. Secondly, RNDC command "rndc -s 127.0.0.1 -p 953 -k /etc/rndc.key delzone test18.cn" was applied to remove zone "test18.cn". 3. After a few of minutes, "dig -t SOA test18.cn" was applied again and found the SOA record still existed. The BIND version is 9.11.4-P2-RedHat-9.11.4-16.P2.el7. The problem occurred from time to time. Unfortunately, the logging file "name.run" does not record any abnormal information. Any comments or suggestions will be highly appreciated. Best Regards, Tengfei -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
