Re: Special-use names and RPZ
On Tue, May 14, 2024 at 2:34 PM John Thurston wrote: > > There are several 'special-use' domain names I'm pondering > > invalid. > test. > onion. > > My read of the RFCs indicate they should result in NXDOMAIN, and not be > passed for resolution. > > RFC 6761 (test. Section 6.2.4 / invalid. Section 6.4.4) > > caching DNS servers SHOULD, by default, generate immediate negative responses > for all such queries. > > RFC 7686 (onion. Section 2.4) > > where not explicitly adapted to interoperate with Tor, SHOULD NOT attempt to > look up records for .onion names. They MUST generate NXDOMAIN for all such > queries. > > Is there some reason these should not just be hammered into our RPZ ? If RFCspeek SHOULD and SHOULD NOT mean "do whatever you feel like doing" (ref RFC 2119 Key words for use in RFCs to Indicate Requirement Levels) So if you feel like adding them to your RPZ file go right ahead :) Regards, Lee -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Tue, Apr 30, 2024 at 2:40 AM Mark Andrews wrote: > > And it has been fixed. Yay! No more error messages in the log because of them :-) Thanks for your help Lee -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Mon, Apr 29, 2024 at 11:40 PM Walter H. wrote: > > On 29.04.2024 22:19, Lee wrote: > > On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users > > wrote: > > > > something that I replied to and got this in response: > > > > Error Icon > > Message blocked > > Your message to Walter.H@[..snip..] has been blocked. See technical > > details below for more information. > > > > The response from the remote server was: > > 554 5.7.1 : Client host rejected: Use IPv4 > > > > > For explanation: this is MY mail server, which blocks IPv6 connections from > > Outlook.com > Gmail.com > ... > > as these are the biggest SPAM senders Which is fine .. your server, your rules. But maybe what isn't so fine is me replying only to the list and still getting a 'rejected: Use IPv4' msg. I don't know how the mailing list works; I'm a bit surprised that I can reply only to the list, get the Client host rejected msg and somehow you can still get the msg?? Anyway.. best regards Lee -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Mon, Apr 29, 2024 at 5:13 PM Mark Andrews wrote: > > I prefer to only name and shame when I’m 100% sure of the target. I was only trying to understand why I was getting a SERVFAIL, there was no intention to name & shame. Regards, Lee "name & shame" was not my intent. > > -- > Mark Andrews > > > On 30 Apr 2024, at 06:56, Lee wrote: > > > > On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: > >> > >> It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that > >> it serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is > >> actually delegated to it. > >> > >> % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all > >> ;; BADCOOKIE, retrying. > >> > >> ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer-gslb.verisignlabs.com > >> +trace +all > >> ;; global options: +cmd > >> ;; Got answer: > >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37498 > >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 > > <.. snip lots ..> > > > >> ;; AUTHORITY SECTION: > >> com. 60 IN SOA this.name.is.invalid. hostmaster.this.name.is.invalid. > >> 2023030710 10800 3600 604800 60 > > > > I did a search for "this.name.is.invalid" and the only results I got > > were for F5 support pages - eg. > > The fix in BIG-IP DNS 14.1.0 introduces a new setting, > > wideip-zone-nameserver, which defaults the WideIP zone nameserver to > > this.name.is.invalid. > > > > Wouldn't a badly configured F5 server be a better explanation? > > > > Thanks > > Lee > -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Sun, Apr 28, 2024 at 7:56 PM Mark Andrews wrote: > > It isn’t DNSSEC. It’s a badly configured DNS server that is claiming that it > serves .com rather than dnssec-analyzer-gslb.verisignlabs.com which is > actually delegated to it. > > % dig dnssec-analyzer-gslb.verisignlabs.com +trace +all > ;; BADCOOKIE, retrying. > > ; <<>> DiG 9.19.24-dev <<>> dnssec-analyzer-gslb.verisignlabs.com +trace > +all > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37498 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27 <.. snip lots ..> > ;; AUTHORITY SECTION: > com. 60 IN SOA this.name.is.invalid. hostmaster.this.name.is.invalid. > 2023030710 10800 3600 604800 60 I did a search for "this.name.is.invalid" and the only results I got were for F5 support pages - eg. The fix in BIG-IP DNS 14.1.0 introduces a new setting, wideip-zone-nameserver, which defaults the WideIP zone nameserver to this.name.is.invalid. Wouldn't a badly configured F5 server be a better explanation? Thanks Lee -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Sun, Apr 28, 2024 at 2:18 AM Walter H. via bind-users wrote: something that I replied to and got this in response: Error Icon Message blocked Your message to Walter.H@[..snip..] has been blocked. See technical details below for more information. The response from the remote server was: 554 5.7.1 : Client host rejected: Use IPv4 Which is strangely appropriate when trying to troubleshoot an issue that applies only to IPv6. But I've forgotten how to turn off IPv6 :( -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Sun, Apr 28, 2024 at 2:18 AM Walter H. wrote: > > On 27.04.2024 16:54, Lee wrote: > > On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users > > wrote: > >> # host dnssec-analyzer.verisignlabs.com > >> dnssec-analyzer.verisignlabs.com is an alias for > >> dnssec-analyzer-gslb.verisignlabs.com. > >> dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 > >> > > Right, the IPv4 address lookup works. Now try looking up the IPv6 address. > > if there was one it would be presented there Try this: $ dig www.github.com ; <<>> DiG 9.16.48-Debian <<>> www.github.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45964 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: 6e0635047fb42cbf0100662ff80b95c1aaed2c48a54b (good) ;; QUESTION SECTION: ;www.github.com.IN ;; ANSWER SECTION: www.github.com. 3600IN CNAME github.com. ;; AUTHORITY SECTION: github.com. 3600IN SOA dns1.p08.nsone.net. hostmaster.nsone.net. 1656468023 43200 7200 1209600 3600 The query status is NOERROR. Compare that to $ dig dnssec-analyzer-gslb.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer-gslb.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 18045 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1432 ; COOKIE: 8dca27caaec9a4740100662ff8ad9cc9bff9bf779d54 (good) ;; QUESTION SECTION: ;dnssec-analyzer-gslb.verisignlabs.com. IN where the query status is SERVFAIL. OK.. noerr vs. servfail doesn't make all that much difference to me, but I *would* like to understand why looking ip the IPv6 address for that name gives me an error. I'm still operating under the (increasingly looking like it's delusional) assumption that I should be able to understand this stuff. > this can't be a matter of DNSSEC, as there are only signed whole zones > and not just single DNS-records ... I dunno. I've seen some weird stuff with servers on AWS not resolving IPv6 addresses but having a CNAME pointing outside the zone. Which I don't understand, but at least it doesn't return an error so I just chalked it up to them deciding that supporting IPv6 was too much of a pain. Regards, Lee -- 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: dnssec-analyzer.verisignlabs.com aaaa lookup fail
On Sat, Apr 27, 2024 at 9:50 AM Walter H. via bind-users wrote: > > # host dnssec-analyzer.verisignlabs.com > dnssec-analyzer.verisignlabs.com is an alias for > dnssec-analyzer-gslb.verisignlabs.com. > dnssec-analyzer-gslb.verisignlabs.com has address 209.131.158.42 > Right, the IPv4 address lookup works. Now try looking up the IPv6 address. I get a status: SERVFAIL instead of a status: NOERROR $ dig dnssec-analyzer.verisignlabs.com ; <<>> DiG 9.16.48-Debian <<>> dnssec-analyzer.verisignlabs.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60491 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 Lee -- 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
dnssec-analyzer.verisignlabs.com aaaa lookup fail
dig dnssec-analyzer.verisignlabs.com gives me a SERVFAIL & this in the bind errors_log file: $ grep dnssec-analyzer.verisignlabs.com named-errors.log | tail -1 26-Apr-2024 19:28:37.600 query-errors: info: client @0x7f384488e3c0 127.0.0.1#47121 (dnssec-analyzer.verisignlabs.com): query failed (failure) for dnssec-analyzer.verisignlabs.com/IN/ at query.c:7471 Is that because of the insecure delegation shown at https://dnsviz.net/d/dnssec-analyzer.verisignlabs.com/dnssec/ and me having "dnssec-validation auto;" in named.conf? Thanks Lee (still struggling to understand this stuff) -- 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: replace "SERVFAIL" to "NXDOMAIN" with rpz
On 6/19/23, sami.rahal wrote:
> Thank you Greg
>
> I tested with other domain name to replace "SERVFAIL" with "NXDOMAIN" is it
> not working
You're missing "break-dnssec yes" on your response-policy stanza?
You need something like
response-policy { zone "rpz.mozilla"; zone "rpz.zone"; }
break-dnssec yes
recursive-only no
qname-wait-recurse no;
#enable rpz
# By default, RPZ actions are applied only to DNS requests that either do not
# request DNSSEC metadata (DO=0) or when no DNSSEC records are available for
# request name in the original zone (not the response policy zone).
# This default can be changed for all response policy zones in a view with a
# break-dnssec yes clause. In that case, RPZ actions are applied regardless
# of DNSSEC.
#
# zone "rpz.mozilla";
#
https://support.mozilla.org/en-US/kb/configuring-networks-disable-dns-over-https
Regards,
Lee
>
> I use CentOS7 with BIND9.16.41
>
>
>
> grep antlauncher db.rpz
>
> antlauncher.com CNAME .
>
> *.antlauncher.com CNAME .
>
>
>
> grep example db.rpz
>
> example.com IN CNAME .
>
> *.example.com IN CNAME .
>
>
>
> dig @0 foo.antlauncher.com
>
>
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @0
> foo.antlauncher.com ; (1 server found) ;; global options: +cmd ;; Got
> answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54704 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4096
>
> ;; QUESTION SECTION:
>
> ;foo.antlauncher.com. IN A
>
>
>
> ;; Query time: 241 msec
>
> ;; SERVER: 127.0.0.1#53(0.0.0.0)
>
> ;; WHEN: Mon Jun 19 10:52:22 CET 2023
>
> ;; MSG SIZE rcvd: 48
>
>
>
> # dig @0 example.com
>
>
>
> ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.10 <<>> @0 example.com ; (1
> server found) ;; global options: +cmd ;; Got answer:
>
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 9852 ;; flags: qr rd
> ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
>
>
>
> ;; OPT PSEUDOSECTION:
>
> ; EDNS: version: 0, flags:; udp: 4096
>
> ;; QUESTION SECTION:
>
> ;example.com. IN A
>
>
>
> ;; ADDITIONAL SECTION:
>
> siteblockeddb. 1 IN SOA LOCALHOST.
> need.to.know.only. 2016011100 43200 900 1814400 7200
>
>
>
> ;; Query time: 347 msec
>
> ;; SERVER: 127.0.0.1#53(0.0.0.0)
>
> ;; WHEN: Mon Jun 19 10:52:36 CET 2023
>
> ;; MSG SIZE rcvd: 115
>
>
>
>
> De : Greg Choules
> Envoyé : lundi 19 juin 2023 15:12
> À : RAHAL Sami SOFRECOM
> Cc : bind-users@lists.isc.org
> Objet : Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
>
> Hi Sami.
> That's not what I said.
> Yes, you can do this with RPZ if you want - it's all in the BIND ARM - but
> it's not something I would do.
>
> Cheers, Greg
>
> On Mon, 19 Jun 2023 at 12:40,
> mailto:sami.ra...@sofrecom.com>> wrote:
> Thank you Greg
> So if I understand correctly if we receive a servfail return code we can not
> modify this code by nxdomain with the rpz configuration?
> Regards
>
> De : Greg Choules
> mailto:gregchoules%2bbindus...@googlemail.com>>
> Envoyé : lundi 19 juin 2023 12:02
> À : RAHAL Sami SOFRECOM
> mailto:sami.ra...@sofrecom.com>>
> Cc : bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
> Objet : Re: replace "SERVFAIL" to "NXDOMAIN" with rpz
>
> That's because this domain is broken. The NS for it are:
> antlauncher.com<http://antlauncher.com>: type NS, class IN, ns
> ns1626.ztomy.com<http://ns1626.ztomy.com> (204.11.56.26)
> antlauncher.com<http://antlauncher.com>: type NS, class IN, ns
> ns2626.ztomy.com<http://ns2626.ztomy.com> (204.11.57.26)
> No matter what query you send them (so far) they respond with REFUSED and
> claim not to be authoritative for
> "antlauncher.com<http://antlauncher.com>".
>
> Personally I would live with the SERVFAIL because it tells you that
> something is wrong, not just that it doesn't exist. Then try to contact the
> people who own this domain and tell them it is broken.
>
> Cheers, Greg
>
> On Mon, 19 Jun 2023 at 10:33,
> mailto:sami.ra...@sofrecom.com>> wrote:
> Hello
> Thank you for these details Greg, by the way I worked on a problem on one of
> my resolvers and there are no errors of type
Re: Response Policy Zone returns servfail for time.in Trigger
On 4/8/23, Fred Morris wrote:
> Since one of the corner cases where RPZ is used is for mitigation of
> failures of legitimate resources, I have a question...
>
> On Sat, 8 Apr 2023, Ondřej Surý wrote:
>> time.in is currently broken - I am guessing this is the reason why are you
>> trying to rewrite the answers.
>>
>> RPZ does try to resolve the name first, and it fails, so there’s nothing
>> to rewrite.
>
> Does this mean that in the default configuration an e.g. A record in an
> RPZ overriding brokenness in the global DNS with a QNAME override might
> fail due to the same brokenness? As far as I know I've never experienced
> that.
>
> Going forward, what is anticipated to be the proper configuration for that
> scenario?
I haven't noticed any problems with this bit:
response-policy { zone "thing1"; zone "thing2"; }
break-dnssec yes
recursive-only no
qname-wait-recurse no;
#enable rpz
# By default, RPZ actions are applied only to DNS requests that either do not
# request DNSSEC metadata (DO=0) or when no DNSSEC records are available for
# request name in the original zone (not the response policy zone).
# This default can be changed for all response policy zones in a view with a
# break-dnssec yes clause. In that case, RPZ actions are applied regardless
# of DNSSEC.
Regards,
Lee
--
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: caching does not seem to be working for internal view
On 8/3/22, Robert Moskowitz via bind-users wrote:
> thanks Greg. Yes I need to figure out how to troubleshoot this. But
> here is some stuff:
>
> # cat resolv.conf
> # Generated by NetworkManager
> search attlocal.net htt-consult.com
> nameserver 23.123.122.146
> nameserver 2600:1700:9120:4330::1
>
> My server is 23.123.122.146. That IPv6 addr is my ATT router.
>
> # cat named.conf
> include "/etc/named/named.acl";
>
> options {
> listen-on port 53 { any; };
> listen-on-v6 port 53 { any; };
> use-v4-udp-ports { range 10240 65535; };
> use-v6-udp-ports { range 10240 65535; };
> directory "/var/named";
> dump-file "/var/named/data/cache_dump.db";
> statistics-file "/var/named/data/named_stats.txt";
> memstatistics-file "/var/named/data/named_mem_stats.txt";
> allow-query { localhost; };
seems wrong, shouldn't that be
allow-query{ httnets; };
Lee
--
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: underscores in A queries
On 4/9/21, John W. Blue via bind-users wrote: > It would seem that underscores is one of those characters in DNS that leads > a double life. > > RFC’s say that underscores are disallowed for use in hostnames Right. But it's **hostnames** and not everyone enforces that rule :( > but SRV > records use it to indicate service type et al. SRV records aren't hostnames, nor are CNAME records, TXT, etc. I've got this bit in my notes re "check-names response fail;" # also see dns-operati...@lists.dns-oarc.net # [dns-operations] about the underline in hostname # where the consensus is to not do this check on resolvers Regards, Lee ___ Please 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: Fwd: DNS Misconfiguration on- http://cyberia.net.sa/
On 6/5/20, Fred Morris wrote: > Hrmmm... I'm reminded of something else I've seen reported on recently... > > On Fri, 5 Jun 2020, Ejaz Ahmed wrote: >> localhost.cyberia.net.sa > > I don't know if you've been paying attention, but it's been reported that > among others EBay has been port scanning visitor's devices [0]. Having > localhost.ebay.com could be handy for them in terms of circumventing some > rules on setting of cookies and the execution of scripts. Not saying > that's what they're doing, heaven forbid. > > Any domain you visit could have entries in it which point to e.g. > localhost or nonrouting addresses commonly used for gateways, things like > that. > > This is not a DNS problem, it's a problem in what commonly used programs > aid and abet in the name of "freedom of commerce" or something. It's possible to block with rpz & something else that I can't recall right now. I did RPZ blocking first, so I didn't bother changing ; return NXDOMAIN for any 127.0.0.0/8 answers ;exceptions: onea.net-snmp.org CNAME rpz-passthru. twoa.net-snmp.org CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 ; check: ; localhost 127.0.0.1 ; onea.net-snmp.org 127.0.0.1 ; twoa.net-snmp.org 127.0.0.2 127.0.0.3 All my other host names that used to return 127.0.0.1 answers don't any more :( Anyone know some valid names I can use for testing? Lee ___ Please 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: Slow recursive query performance on Windows x64
On 1/20/20, Ondřej Surý wrote: > > Please note that filter--on-v4 was always wrong. how so? > You should fix your network instead. It’s a bandaid, not a fix. My ISP doesn't offer ipv6, so I'm not sure how to fix my network.. unless you mean disable ipv6 on everything? (which I'm not sure is even possible) Lee ___ 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: Slow recursive query performance on Windows x64
On 1/18/20, Steve Farr wrote:
>
> I don't have IPv6 connectivity through my ISP, and don't use it on my LAN,
> so I have it unchecked/not bound in Windows,
Same here.
When I tried running named on windows it didn't support the -4 option;
the workaround I was given was to add
server ::/0 { bogus yes; };
to named.conf so it wouldn't try to use ipv6. And maybe this is
enabled/works on windows now:
options {
filter--on-v4 yes;
}
> Basically, it looks like my DNS server sits on it for 3.2 seconds before
> asking the root for a referral.
Which is weird. Exactly how did you do the packet capture - as in, is
it possible you didn't capture everything to/from the server?
Lee
>
> From: Ondrej Surý
> Sent: Friday, January 17, 2020 3:27 PM
> To: Steve Farr
> Cc: bind-users@lists.isc.org
> Subject: Re: Slow recursive query performance on Windows x64
>
>
>
> Hi Steve,
>
>
>
> I would suggest to either bump debugging level in bind9 or use wireshark to
> look what’s happening on the wire. My best guest is broken IPv6
> connectivity, but it could be something completely different. Looking at the
> packets is a easiest way to get better understanding of the problem.
>
> Ondrej
>
> --
>
> Ondřej Surý — ISC
>
>
>
>
>
> On 17 Jan 2020, at 20:52, Steve Farr via bind-users
>
> Hi there,
>
>
>
> I'm hoping perhaps someone can point me in a good direction for
> troubleshooting here… I recently upgraded from BIND 9.9.10-P3 running in
> 32-bit Windows, to 9.14.9 running on 64-bit Windows. I've tried it in both
> Windows 10 and Windows 7, and the behavior is the same: Queries for
> addresses that aren't already cached take a long time (long enough that the
> client resolver often gives up and assumes the DNS server failed - perhaps
> 5-6 seconds). On a second attempt, it's usually in the cache and responds
> right away. The server has three views, two of which allow recursion, and it
> hosts a couple of authoritative domains (differing in content between the
> views, but present in all three). Queries for addresses in the domains that
> are hosted locally are fast, and so are queries for anything that's cached.
> I had to make a few tweaks to the config, jumping so many versions, in order
> to eliminate warnings about things like DNSSEC… I also downloaded a fresh
> copy of the named.cache / root hints, as well as bind.keys.
>
>
>
> It's entirely possible that I just don't know what I'm doing.
>
>
>
> Any ideas what could be causing this? The old server occupied the same
> internal IP address (same firewall, same NAT, etc) so I don't tend to
> suspect the network, especially since it's reproducible (the old 32-bit box
> still works fast if I swap it back in). Here's my current config (feel free
> to critique it even if off-topic):
>
>
>
> // named.conf
>
> acl internal { 192.168.63.0/24; 192.168.65.0/24; 127.0.0.1; };
>
> acl wifi { 192.168.64.0/24; };
>
> acl notifiers { [public IP removed for anonymity];};
>
>
>
> key "transfer-key" {
>
> algorithm hmac-md5;
>
> secret "[removed for security]";
>
> };
>
> server [same public IP as in acl notifiers] {
>
> keys { transfer-key; };
>
> };
>
>
>
> options {
>
> version "1.1.1.1";
>
> directory "C:\ISCBIND9\etc\namedb"; // Working directory
>
> pid-file "C:\ISCBIND9\var\named.pid";
>
> statistics-file "C:\ISCBIND9\var\named.stats";
>
> memstatistics-file "C:\ISCBIND9\var\named.memstats";
>
> auth-nxdomain yes;
>
> listen-on { 192.168.63.23; 127.0.0.1; };
>
> tcp-clients 1024;
>
> max-cache-size 128M;
>
> allow-query { any; };
>
>recursion no;
>
>allow-recursion { none; };
>
>allow-query-cache { none; };
>
> allow-transfer { none; };
>
>allow-notify { notifiers; };
>
> notify no;
>
>
>
>dnssec-enable yes;
>
>dnssec-lookaside no;
>
>dnssec-validation yes;
>
>bindkeys-file "C:\ISCBIND9\etc\namedb\bind.keys";
>
> };
>
>
>
> view internal {
>
>match-clients { internal; };
>
>recursion yes;
>
>allow-query { internal; };
>
>allow-recursion { internal; };
>
>allow-query-cache { internal; };
>
>
>
>zone "." in {type hint; file "named.cache"; };
>
>
Re: Debugging Information Lacking?
On 11/27/19, isc-bind-us...@ics-il.net wrote:
>
> I have some other issues that I'm trying to work through, but I wanted to
> ask about a specific issue.
>
> I'm trying to see what BIND currently thinks all of the zones are, so I
> issue the "rndc dumpdb -zones" command.
<.. snip ..>
> However, it appears no file is generated. "find / -name cache_dump.db"
> doesn't return anything.
the default file name is named_dump.db
If your named.conf has this bit
options {
directory "/var/cache/bind";
# working directory
then "rndc dumpdb -zones" creates the file /var/cache/bind/named_dump.db
If your named.conf has this bit
options {
dump-file "/tmp/cache_dump.db";
then "rndc dumpdb -zones" creates the file /tmp/cache_dump.db
> The log says that dumpdb is complete, but it doesn't say what it wrote. I
> would expect the log file to say something like:
>
> Nov 27 07:36:28 DNA-DNS1 named[20035]: dumpdb output to: /var/lib/bind/
> cache_dump.db
>
> It doesn't. Could we get that added to the logging information?
Yes, it would be nice if that was added
Lee
___
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: rpz fail
On 8/27/19, Tony Finch wrote: > Lee wrote: >> >> Can someone please explain why using this as my rpz zone does NOT >> block everything for *.2o7.net? >> >> 2o7.net CNAME . >> *.2o7.net CNAME . >> bcbsks.com.102.112.2o7.net CNAME . > > I suspect this is RPZ obeying the weird semantics of DNS wildcard > matching. The * only matches if the answer would otherwise be NXDOMAIN > (the name does not exist). The weirdness happens when there are subdomains > that exist, because any parent names are NODATA (the name exists but has > no records of the query type) which suppresses wildcard matching. > > So the third CNAME causes com.102.112.2o7.net and 102.112.2o7.net and > 112.2o7.net to exist, so any names under those domains do not match the > wildcard. In your example appleglobal.112.2o7.net is under 112.2o7.net so > it doesn't match. > > For the long explanation see > https://tools.ietf.org/html/rfc4592 - The Role of Wildcards in the Domain > Name System > https://tools.ietf.org/html/rfc8020 - NXDOMAIN: There Really Is Nothing > Underneath Thank you! I posted a similar question on the dns firewall list http://lists.redbarn.org/pipermail/dnsfirewalls/2019-August/000367.html hopefully the rfcs you listed will help me understand the 'empty non-terminals' thing Regards, Lee ___ 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
rpz fail
tl,dr: https://github.com/StevenBlack/hosts/issues/451 Can someone please explain why using this as my rpz zone does NOT block everything for *.2o7.net? $ cat db.test-rpz $ORIGIN rpz.test. $TTL1s @ IN SOA localhost. admin ( 2019082405 6h 15 1d 1s ) IN NS localhost. 2o7.net CNAME . *.2o7.net CNAME . bcbsks.com.102.112.2o7.net CNAME . ; end but using this does block all of 2o7.net? (or at least all I've tried) $ cat db.test-rpz $ORIGIN rpz.test. $TTL1s @ IN SOA localhost. admin ( 2019082407 6h 15 1d 1s ) IN NS localhost. 2o7.net CNAME . *.2o7.net CNAME . ; bcbsks.com.102.112.2o7.net CNAME . ; === end === With "; bcbsks.com.102.112.2o7.net CNAME ." commented out both dig @127.0.0.1 appleglobal.112.2o7.net dig @127.0.0.1 appleglobal.2o7.net work as expected & have ;; ADDITIONAL SECTION: rpz.test. 1 IN SOA localhost. admin.rpz.test. 2019082407 21600 15 86400 1 With "bcbsks.com.102.112.2o7.net CNAME ." not commented out dig @127.0.0.1 appleglobal.112.2o7.net -- returns an ip address with the ANSWER, AUTHORITY & ADDITIONAL SECTION dig @127.0.0.1 appleglobal.2o7.net -- doesn't return an ip address & additional info is ;; ADDITIONAL SECTION: rpz.test. 1 IN SOA localhost. admin.rpz.test. 2019082406 21600 15 86400 1 Am I just missing something or is this a bug? I get the same behavior on debian with 9.11.5-P4-5~bpo9+1-Debian and windows 10 with 9.11.9 (from ftp://ftp.isc.org/isc/bind9/9.11.9/BIND9.11.9.x64.zip) TIA Lee ___ 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: recursive query use tcp ?
I have check that your recommended option works well.
Thank you very much.
08-Apr-2019 14:30:17.867 CQ 127.0.0.1:60997 -> 127.0.0.1:0 UDP 54b
sukmoonlee.tk/IN/A
08-Apr-2019 14:30:17.867 RQ 10.0.2.15:53866 -> 192.112.36.4:53 UDP 40b ./IN/NS
08-Apr-2019 14:30:17.867 RQ 10.0.2.15:39398 -> 192.112.36.4:53 UDP 43b tk/IN/NS
08-Apr-2019 14:30:17.926 RR 10.0.2.15:53866 <- 192.112.36.4:53 UDP 56b ./IN/NS
08-Apr-2019 14:30:17.927 RR 10.0.2.15:39398 <- 192.112.36.4:53 UDP 505b tk/IN/NS
08-Apr-2019 14:30:17.926 RQ 10.0.2.15:45621 -> 192.112.36.4:53 TCP 56b ./IN/NS
08-Apr-2019 14:30:17.927 RQ 10.0.2.15:51377 -> 194.0.38.1:53 TCP 43b tk/IN/NS
08-Apr-2019 14:30:18.559 RR 10.0.2.15:51377 <- 194.0.38.1:53 TCP 274b tk/IN/NS
08-Apr-2019 14:30:18.560 RQ 10.0.2.15:45121 -> 192.112.36.4:53 UDP 64b
a.ns.tk/IN/
08-Apr-2019 14:30:18.560 RQ 10.0.2.15:40088 -> 192.112.36.4:53 UDP 64b
b.ns.tk/IN/
08-Apr-2019 14:30:18.561 RQ 10.0.2.15:59965 -> 192.112.36.4:53 UDP 64b
c.ns.tk/IN/
08-Apr-2019 14:30:18.561 RQ 10.0.2.15:48924 -> 192.112.36.4:53 UDP 64b
d.ns.tk/IN/
08-Apr-2019 14:30:18.619 RR 10.0.2.15:40088 <- 192.112.36.4:53 UDP 617b
b.ns.tk/IN/
08-Apr-2019 14:30:18.621 RR 10.0.2.15:59965 <- 192.112.36.4:53 UDP 617b
c.ns.tk/IN/
08-Apr-2019 14:30:18.624 RR 10.0.2.15:45121 <- 192.112.36.4:53 UDP 617b
a.ns.tk/IN/
08-Apr-2019 14:30:18.627 RR 10.0.2.15:48924 <- 192.112.36.4:53 UDP 617b
d.ns.tk/IN/
08-Apr-2019 14:30:18.559 RQ 10.0.2.15:33217 -> 194.0.41.1:53 TCP 54b
sukmoonlee.tk/IN/A
08-Apr-2019 14:30:18.621 RQ 10.0.2.15:60200 -> 194.0.40.1:53 TCP 48b
c.ns.tk/IN/
08-Apr-2019 14:30:18.624 RQ 10.0.2.15:39098 -> 194.0.40.1:53 TCP 48b
a.ns.tk/IN/
08-Apr-2019 14:30:18.620 RQ 10.0.2.15:50933 -> 194.0.40.1:53 TCP 48b
b.ns.tk/IN/
08-Apr-2019 14:30:18.627 RQ 10.0.2.15:50889 -> 194.0.40.1:53 TCP 48b
d.ns.tk/IN/
08-Apr-2019 14:30:19.049 RR 10.0.2.15:33217 <- 194.0.41.1:53 TCP 301b
sukmoonlee.tk/IN/A
08-Apr-2019 14:30:19.049 CR 127.0.0.1:60997 <- 127.0.0.1:0 UDP 86b
sukmoonlee.tk/IN/A
08-Apr-2019 14:30:19.115 RR 10.0.2.15:60200 <- 194.0.40.1:53 TCP 274b
c.ns.tk/IN/
08-Apr-2019 14:30:19.116 RR 10.0.2.15:50933 <- 194.0.40.1:53 TCP 274b
b.ns.tk/IN/
08-Apr-2019 14:30:19.118 RR 10.0.2.15:39098 <- 194.0.40.1:53 TCP 274b
a.ns.tk/IN/
-Original Message-
From: Mark Andrews
Sent: Monday, April 08, 2019 1:38 PM
To: 이석문님/Core솔루션팀
Cc: bind-users@lists.isc.org
Subject: Re: recursive query use tcp ?
I suggest that you fix whatever is blocking the UDP queries as the servers (in
Singapore at least) do respond to UDP queries.
% dig @194.0.38.1 sukmoonlee.tk +nsid
; <<>> DiG 9.15.0-dev+hotspot+add-prefetch+marka <<>> @194.0.38.1 sukmoonlee.tk
+nsid ; (1 server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54117 ;; flags: qr aa rd;
QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9 ;; WARNING: recursion
requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; NSID: 73 69 6e ("sin")
;; QUESTION SECTION:
;sukmoonlee.tk. IN A
;; ANSWER SECTION:
sukmoonlee.tk. 300 IN A 195.20.43.161
;; AUTHORITY SECTION:
tk. 86400 IN NS a.ns.tk.
tk. 86400 IN NS b.ns.tk.
tk. 86400 IN NS c.ns.tk.
tk. 86400 IN NS d.ns.tk.
;; ADDITIONAL SECTION:
a.ns.tk.10800 IN A 194.0.38.1
b.ns.tk.10800 IN A 194.0.39.1
c.ns.tk.10800 IN A 194.0.40.1
d.ns.tk.10800 IN A 194.0.41.1
a.ns.tk.10800 IN 2001:678:50::1
b.ns.tk.10800 IN 2001:678:54::1
c.ns.tk.10800 IN 2001:678:58::1
d.ns.tk.10800 IN 2001:678:5c::1
;; Query time: 136 msec
;; SERVER: 194.0.38.1#53(194.0.38.1)
;; WHEN: Mon Apr 08 14:31:12 AEST 2019
;; MSG SIZE rcvd: 308
%
That said you can set "tcp-only yes”; in an appropriate server clause.
Mark
> On 8 Apr 2019, at 2:26 pm, Sukmoon Lee wrote:
>
> Hello.
>
> My Test DNS is not response for "*.tk".
> I looked around then my server not work connect using udp for tk's tld name
> sever.
> But this server is work to using TCP. (below test)
>
> If there is an option on the named server that recursive queries use tcp?
> I can't search BIND ARM.
>
> Thanks in Advance.
>
>
> Regards,
> Sukmoon Lee
>
>
>
>
> -
>
> $ dig @194.0.38.1 sukmoonlee.tk
>
> ; <<>> DiG 9.11.2-P1 <<>> @194.0.38.1 sukmoonlee.tk ; (1 server found)
> ;; global optio
recursive query use tcp ?
Hello. My Test DNS is not response for "*.tk". I looked around then my server not work connect using udp for tk's tld name sever. But this server is work to using TCP. (below test) If there is an option on the named server that recursive queries use tcp? I can't search BIND ARM. Thanks in Advance. Regards, Sukmoon Lee - $ dig @194.0.38.1 sukmoonlee.tk ; <<>> DiG 9.11.2-P1 <<>> @194.0.38.1 sukmoonlee.tk ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached $ dig @194.0.38.1 sukmoonlee.tk +tcp ; <<>> DiG 9.11.2-P1 <<>> @194.0.38.1 sukmoonlee.tk +tcp ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30919 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;sukmoonlee.tk. IN A ;; ANSWER SECTION: sukmoonlee.tk. 300 IN A 195.20.43.161 ;; AUTHORITY SECTION: tk. 86400 IN NS a.ns.tk. tk. 86400 IN NS b.ns.tk. tk. 86400 IN NS c.ns.tk. tk. 86400 IN NS d.ns.tk. ;; ADDITIONAL SECTION: a.ns.tk.10800 IN A 194.0.38.1 b.ns.tk.10800 IN A 194.0.39.1 c.ns.tk.10800 IN A 194.0.40.1 d.ns.tk.10800 IN A 194.0.41.1 a.ns.tk.10800 IN 2001:678:50::1 b.ns.tk.10800 IN 2001:678:54::1 c.ns.tk.10800 IN 2001:678:58::1 d.ns.tk.10800 IN 2001:678:5c::1 ;; Query time: 242 msec ;; SERVER: 194.0.38.1#53(194.0.38.1) ;; WHEN: Mon Apr 08 11:32:40 KST 2019 ;; MSG SIZE rcvd: 301 ___ 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: RPZ and forward zone trouble
On 3/25/19, Miguel Mucio Santos Moreira wrote: > > Hello everybody! Hi! > I have a problem with DNS-RPZ and forward zone working together. > I've created a rpz zone with the following trigger on my recursive DNS > Server: > 18.0.0.198.200.rpz-nsip IN CNAME rpz-passthru. Which means anybody can answer with a 200.198.0.0/18 address and it will be accepted. .. probably not what you want. > It means any query response comming from a DNS Server which IP address > matching with the any IP address at entire CIDR block 200.198.0.0/18 will be > answered with rpz-passthru > It works perfectly for any domain hosted in my Authoritative DNS Servers. > But when I apply on my recursive RPZ DNS Server a forward zone for those > domains hosted on my Authoritative DNS Servers the problems appear and it is > very weird. > > I have a mg.gov.br domain I'd go with mg.gov.br IN CNAME rpz-passthru. -- it's your domain so hopefully you can trust whatever answers it gives 18.0.0.198.200.rpz-nsip IN CNAME . -- nobody else gets to answer with your address space Regards, Lee > and its NS Servers are zeus.prodemge.gov.br > (200.198.5.13), titanio.prodemge.gov.br (200.198.5.5), tupan.prodemge.gov.br > (200.198.4.4) and jupiter.prodemge.gov.br (200.198.5.2). > If I perform a dig at my workstation using Recursive DNS with RPZ looking > for any record in mg.gov.br domain, rpz-passthru policy is not applied, > however if I perform a dig looking for any record in prodemge.gov.br domain > and after that I perform the same dig before it works properly. > > > Note: Recursive DNS Servers and Authoritative DNS Servers are not the same. > > As workaround solution I applied 4 rpz-nsdname triggers above that one > mentioned in the begining this email with my authoritative name servers with > rpz-passthru policy. > titanio.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru. > jupiter.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru. > tupan.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru. > zeus.prodemge.gov.br.rpz-nsdname IN CNAME rpz-passthru. > > I would like to understand why it didn't work without workaround solution, > anyone has any idea about it? > > Thanks in advance > -- > > Miguel Moreira > Gerente > DPR/SRE/GSR - Gerência de Serviços de Rede > +55(31)3339-1401 > PRODEMGE - Companhia de Tecnologia da Informação do Estado de Minas Gerais > > > Aviso: Esta mensagem é destinada exclusivamente para a(s) pessoa(s) a quem é > dirigida, podendo conter informação sigilosa e legalmente protegida. O uso > impróprio será tratado conforme as normas da empresa e a legislação em > vigor. Caso não seja o destinatário, favor notificar o remetente, ficando > proibidas a utilização, divulgação, cópia e distribuição. > ___ 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: SSHFP observation
On 1/31/19, Alan Clegg wrote: > On 1/31/19 4:57 PM, Mark Andrews wrote: > >> Given type 1 is a SHA-1 fingerprint it isn’t legal. Named just >> hasn’t added type to length to the parsing code. >> >> No real SSHFP will be 1 octet long. > > While I agree that it's junk, the RFC doesn't give the DNS software the > ability to make that decision from my reading. > > There is nothing in the RFC about validating the correctness of the data: I'm not following your logic. The RFC says a field is the fingerprint and the user supplied data can't possibly be a fingerprint. It seems to me there's a requirement to reject the user supplied data since it can't possibly be a fingerprint. Regards, Lee > > -- >The RDATA of the presentation format of the SSHFP resource record >consists of two numbers (algorithm and fingerprint type) followed by >the fingerprint itself, presented in hex, e.g.: > >host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890 > -- > > AlanC ___ 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: stop on unrecognized qresult in rpz_rewrite()
On 11/16/18, Evan Hunt wrote:
> On Fri, Nov 16, 2018 at 11:44:11AM -0500, Lee wrote:
>> > It's an interaction between RPZ and aggressive negative caching (i.e.
>> > "synth-from-dnssec"). It's fixed in the upcoming release.
>>
>> I should have asked which upcoming release? It's still happening in
>> 9.11.5:
>
> I'm sorry, I should have asked you what version you were running. That log
> message was appearing frequently in 9.12 because of the synth-from-dnssec
> feature -- we had a couple of bug reports about it in a row, and I assumed
> it was the same thing when you asked about it.
>
> Since synth-from-dnssec doesn't exist in 9.11, there must be another cause
> in your case. Very sorry for misleading you. How often are you seeing this?
$ grep "stop on unrecognized qresult in rpz_rewrite" errors.log | awk
'{print $1, $2}'
01-Nov-2018 1:13:12.395
01-Nov-2018 1:16:22.145
01-Nov-2018 1:18:58.915
01-Nov-2018 16:52:29.802
02-Nov-2018 4:46:53.086
02-Nov-2018 20:52:42.481
03-Nov-2018 1:59:46.482
03-Nov-2018 21:08:28.767
03-Nov-2018 22:01:53.310
04-Nov-2018 11:03:51.150
04-Nov-2018 21:24:12.043
06-Nov-2018 4:32:23.321
06-Nov-2018 19:56:47.565
07-Nov-2018 14:11:00.171
07-Nov-2018 17:22:15.569
07-Nov-2018 18:37:26.019
07-Nov-2018 19:56:48.379
08-Nov-2018 5:52:43.013
08-Nov-2018 19:56:48.476
09-Nov-2018 8:18:30.319
09-Nov-2018 16:28:36.634
10-Nov-2018 7:33:28.933
10-Nov-2018 8:36:52.640
11-Nov-2018 9:37:42.894
11-Nov-2018 18:59:56.745
11-Nov-2018 22:13:23.277
12-Nov-2018 6:22:47.164
12-Nov-2018 20:54:13.560
12-Nov-2018 20:54:13.560
13-Nov-2018 6:15:23.780
14-Nov-2018 5:46:01.596
14-Nov-2018 10:05:42.434
14-Nov-2018 10:07:31.887
14-Nov-2018 11:02:19.464
15-Nov-2018 14:09:27.462
15-Nov-2018 16:32:12.865
15-Nov-2018 16:32:16.827
16-Nov-2018 10:10:45.695
16-Nov-2018 17:19:00.934
$
___
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: stop on unrecognized qresult in rpz_rewrite()
On 9/29/18, Evan Hunt wrote: > On Sat, Sep 29, 2018 at 05:48:55PM -0400, Lee wrote: >> Can someone tell me what can cause >> stop on unrecognized qresult in rpz_rewrite()failed: >> or how to fix whatever it was? > > It's an interaction between RPZ and aggressive negative caching (i.e. > "synth-from-dnssec"). It's fixed in the upcoming release. I should have asked which upcoming release? It's still happening in 9.11.5: 16-Nov-2018 10:10:45.695 query-errors: debug 1: client @01BD4A36B710 127.0.0.1#58611 (firefox.settings.services.mozilla.com): rpz QNAME rewrite d2k03kvdk5cku0.cloudfront.net via d2k03kvdk5cku0.cloudfront.net stop on unrecognized qresult in rpz_rewrite()failed: : SERVFAIL 16-Nov-2018 10:10:45.695 query-errors: info: client @01BD4A36B710 127.0.0.1#58611 (firefox.settings.services.mozilla.com): query failed (SERVFAIL) for firefox.settings.services.mozilla.com/IN/A at c:\cygwin64\home\jenkins\workspace\bind9-build-win64-tmp\bin\named\query.c:8579 Lee ___ 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: Rewrite/Override QTYPE with RPZ
On 11/12/18, Tom wrote: > I mean the other way: > > My feeded RPZ blocks othercompany.com and *.othercompany.com. Therefore > any qtype (MX, A, ...) are blocked for this domain. Is there a way > with BIND just to whitelist the MX for othercompany.com and the > consequent A-Record (ex. mail.othercompany.com) that we are able to send > mail to othercompany.com? mail.othercompany.com CNAME rpz-passthru. *.othercompany.com CNAME . in your rpz zone file doesn't do what you want? Lee > > > > > On 09.11.18 14:39, Lightner, Jeffrey wrote: >> That wouldn't help you much. Many mail systems these days check not only >> your MX record but also your PTR record to make sure the IP you came from >> has a valid (i.e. not generic) reverse lookup. They'll also check things >> like dkim or spf TXT records. If they don't like what they find they'll >> simply reject email even if you haven't been blacklisted. >> >> In general blacklisting services blacklist specific IPs rather than >> domains anyway. A work around would be to change the outbound IP your >> mail server uses rather than changing other records. Of course you'd have >> to make additional changes for the PTR, A/ and TXT records for the new >> IP you select. >> >> Many blacklisting services have a way to delist yourself. >> >> However, if you don't fix the underlying problem that caused you to be >> blacklisted in the first place any new IP will quickly be blacklisted as >> well and/or delisting yourself a second time is much more difficult. >> >> If you are sending multiple automated emails (e.g. invoices or marketing >> materials) to customers you need to be monitoring for returns and removing >> rejected email addresses from your databases. These often occur because >> the customer no longer has the email address they originally gave you (or >> they had a typo in what they gave you). >> >> -Original Message- >> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of >> Tom >> Sent: Thursday, November 08, 2018 11:49 PM >> To: bind-users@lists.isc.org >> Subject: Re: Rewrite/Override QTYPE with RPZ >> >> Fore example "example.com" and "*.example.com" are blacklisted. I would >> like to return a real ip address for special query types like MX or TXT, >> but not for A or . >> >> Tom >> >> >> On 08.11.18 16:44, Barry Margolin wrote: >>> In article , >>>Tom wrote: >>> >>>> Hi all >>>> Is there a way to override/rewrite QTYPE (ex. MX) with RPZ? If no, is >>>> this planned in future releases of BIND? >>> >>> What would be the point? If a query is for MX, and you return A >>> instead, the client won't be able to do anything with it. >>> >> ___ >> 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 >> ___ >> 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 >> > ___ > 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 > ___ 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: Queries regarding forwarders
On 10/25/18, Grant Taylor via bind-users wrote: > On 10/25/2018 03:25 PM, Lee wrote: > >> I'm missing what filtering out things like benchmarking & documentation >> network addrs gets you beyond maybe saving some bandwidth? > > I do use all sorts of IP ranges (test networks extensively) in my home / > lab networks. So I'd really rather external things not resolve to an > address that I may be using. But that's me being atypical. If you're using those addresses internally it makes sense to filter them from 'outside'. >> Same deal with using RPZ to block IPv4 BOGONs. What does RPZ blocking >> get you that you don't get by blocking them on your edge routers? > > Defense in depth. > > It's more of an exercise of can it be done. Read: Can I concoct > something that will receive feed from Team Cymru's BGP Bogon Rout Server > and turn it into an RPZ. I play those games at times also :) So it sounds like what I was missing is that you like a challenge & are using more address space that I thought. Regards, Lee ___ 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: Queries regarding forwarders
On 10/24/18, Grant Taylor via bind-users wrote: > On 08/09/2018 01:01 AM, Lee wrote: >> it does, so you have to flag your local zones as rpz-passthru. > > Thank you again Lee. You gave me exactly what I needed and wanted to know. you're welcome :) > I finally got around to configuring my RPZ to filter IPv4 > Special-Purpose Address Registry as per IANA's definition. > (https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1) > > I am also happily using rpz-passthru for my local domain(s) that resolve > to filtered IPs. > > Now I'm pontificating augmenting my RPZ to also filter replies that > resolve to IPv4 BOGONs. (Received via BGP feed with Team Cymru.) I feel like I'm missing something :( I read this https://medium.com/@brannondorsey/attacking-private-networks-from-the-internet-with-dns-rebinding-ea7098a2d325 and used RPZ to block anything coming from outside that might be an internal address. I'm missing what filtering out things like benchmarking & documentation network addrs gets you beyond maybe saving some bandwidth? Same deal with using RPZ to block IPv4 BOGONs. What does RPZ blocking get you that you don't get by blocking them on your edge routers? Thanks, Lee ___ 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: BIND and UDP tuning
On 9/30/18, Alex wrote: > Hi, > > On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote: >> >> On 30 Sep 2018, at 09:59, Alex wrote: >> > It also tends to happen in bulk - there may be 25 SERVFAILs within the >> > same second, then nothing for another few minutes. >> >> That really makes it seem like either you modem or you ISP is interfering >> somehow, or is simply not able to keep up. > > I'm leaning towards that, too. The problem persists even when using > the provider's DNS servers. Is this a personal project or can you get help from the network staff & open trouble tickets with the various providers? I'm making a big guess here, but you mentioned dnsbl.sorbs.net earlier so $ dig dnsbl.sorbs.net. <.. snip ..> ;; ANSWER SECTION: dnsbl.sorbs.net.86400 IN A 113.52.8.154 dnsbl.sorbs.net.86400 IN A 113.52.8.155 dnsbl.sorbs.net.86400 IN A 208.43.139.188 dnsbl.sorbs.net.86400 IN A 113.52.8.153 dnsbl.sorbs.net.86400 IN A 208.43.110.204 go here: https://wq.apnic.net/apnic-bin/whois.pl and search for 113.52.8.154 which gives me inetnum:113.52.8.0 - 113.52.8.255 netname:DIGITALSENSE descr: Digital Sense, Data Centres, Brisbane, Colocation country:AU on the other hand https://whois.arin.net/rest/net/NET-208-43-0-0-1/pft?s=208.43.139.188 gives ms CityDallas State/Province TX If this is a packet drop issue as well as a personal project, you might be stuck with figuring out just how fast you can send queries before things start to break and adjusting your setup accordingly. > I thought for sure I'd see some verifiable > info from other people having problems with cable, such as from > dslreports, etc, but there really hasn't been anything. The comment > made about DOCSIS earlier in this thread was helpful. > > Do you believe it could be impacting all data, not just bind/DNS/UDP? > > Do people not generally use cable as even a fallback link for > secondary services? I figured it was because there's no SLA, not > because it doesn't work well with many protocols. I think it's more of a you pay for what you get thing. "business class" cable costs more & might even be provisioned better, but at least the first question you get when calling support isn't "have you tried turning it off and on?" wrt your earlier I attempted to search github for query.c line 8580 there's probably a github answer; I went to https://ftp.isc.org/isc/bind9/ found my release and downloaded the BIND-xxx.tar.gz source code file. It'd be nice if ISC made no response to a query a separate error vs. lumping it in with all the other "Something has gone wrong." possibilities. Lee ___ 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
stop on unrecognized qresult in rpz_rewrite()
I tried to go to https://fpki.idmanagement.gov/ and got some error
message about not finding the site with a "try again" button. Tried
again and it worked:
29-Sep-2018 15:56:21.677 queries: info: client @01F0C8672910
127.0.0.1#58997 (fpki.idmanagement.gov): query: fpki.idmanagement.gov
IN A + (127.0.0.1)
29-Sep-2018 15:56:21.708 query-errors: debug 1: client
@01F0C8672910 127.0.0.1#58997 (fpki.idmanagement.gov): rpz QNAME
rewrite dfew6wnpm1gb5.cloudfront.net via dfew6wnpm1gb5.cloudfront.net
stop on unrecognized qresult in rpz_rewrite()failed: : SERVFAIL
29-Sep-2018 15:56:21.708 query-errors: info: client @01F0C8672910
127.0.0.1#58997 (fpki.idmanagement.gov): query failed (SERVFAIL) for
fpki.idmanagement.gov/IN/A at ..\query.c:8580
29-Sep-2018 15:56:34.893 queries: info: client @01F0C91812E0
127.0.0.1#51991 (fpki.idmanagement.gov): query: fpki.idmanagement.gov
IN A + (127.0.0.1)
I tried searching on the error message & got lots of pointers to
query.c but I haven't found anything that explains what happened.
I've got nothing for .net or .cloudfront.net in my rpz.zone file & the
rpz zone is configured as
response-policy { zone "rpz.zone" log yes; } break-dnssec yes
recursive-only no qname-wait-recurse no;
Can someone tell me what can cause
stop on unrecognized qresult in rpz_rewrite()failed:
or how to fix whatever it was?
Thanks
Lee
___
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: BIND and UDP tuning
On 9/28/18, Alex wrote: > Hi, > > On Fri, Sep 28, 2018 at 12:18 AM Lee wrote: >> >> On 9/27/18, Alex wrote: >> > Hi, >> > >> >> Just a wild thought: >> >> It works with a lower speed line (at least I read it that way) but has >> >> problems with higher speeds. >> >> Could it be that the line is so fast that it "overtakes" the host in >> >> question? >> >> >> >> A faster incoming line will give less time between the packets for >> >> processing. >> > >> > No, I actually upgraded from a 65/20mbit to a 165/35mbit recently, >> > thinking it was too slow because it was happening at the slower speeds >> > as well. I've also implemented some basic QoS to throttle outgoing >> > smtp and prioritize DNS but it made no difference. >> >> Has your provider enabled qos? I'd bet their dropping packets that >> exceed qos rate limits would be considered "working as expected". > > I asked and they had no idea what that even meant. Escalate? Which is assuming you have a ticket open.. I had it a bit easier than you; I was in an enterprise environment & had control of the routers on both sides + it was relatively easy to demonstrate packet loss. > The technician that > was here replacing the modem also had no idea outside of what the > hardware does. > > I've also asked on dslreports about this, and no one answered. > > It certainly seems to be more pronounced now than it ever was in the > past. Sometimes so many queries are failing that it's impossible to > use the network. Can you make it happen on demand? Troubleshooting is so much easier if you can demonstrate the problem vs. trying to reconstruct what happened after the fact. >> Which brings up the question of exactly what does SERVFAIL mean? Can >> no response to a query result in SERVFAIL? Is there a way to tell the >> difference between no response & getting a response indicating a >> failure? > > Early in this thread or another, I provided a packet trace that showed > what appears to me to never have received the replies - it just times > out. Also, the "Server Failure" messages are always on the loopback > interface. I'd be happy to provide another trace if someone knows how > to properly read it. I really have no idea what's causing the problem. It would be nice if there was a way to tell if the problem was packet drops (ie. no response to a query), getting a bad response from the server or something else. At least then you'd know where to direct your attention.. > Also, I recently raised the trace level to 99, but I don't see > anything in the logs beyond level 4. Where do I find what the > different trace levels are supposed to report? No idea. I'm running bind at home and very occasionally see things like 28-Sep-2018 1:04:32.552 query-errors: info: client @01F0C86745C0 127.0.0.1#63459 (www.Amazon.com): query failed (SERVFAIL) for www.Amazon.com/IN/A at ..\query.c:8580 so I'd be interested in knowing if you get a resolution to the problem. Lee ___ 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: BIND and UDP tuning
On 9/27/18, Alex wrote: > Hi, > >> Just a wild thought: >> It works with a lower speed line (at least I read it that way) but has >> problems with higher speeds. >> Could it be that the line is so fast that it "overtakes" the host in >> question? >> >> A faster incoming line will give less time between the packets for >> processing. > > No, I actually upgraded from a 65/20mbit to a 165/35mbit recently, > thinking it was too slow because it was happening at the slower speeds > as well. I've also implemented some basic QoS to throttle outgoing > smtp and prioritize DNS but it made no difference. Has your provider enabled qos? I'd bet their dropping packets that exceed qos rate limits would be considered "working as expected". Which brings up the question of exactly what does SERVFAIL mean? Can no response to a query result in SERVFAIL? Is there a way to tell the difference between no response & getting a response indicating a failure? Lee ___ 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: check-names response fail;
On 8/22/18, Darcy, Kevin wrote:
> So, the short answer is that check-names is pretty granular, doing
> "check-names response fail" is just asking for trouble, for a resolver at
> the Internet edge, since there's too much squirrely stuff out there. Most
> folks just limit check-names "fail" to authoritative data (master or
> slave).
>
> The longer answer is: this is an interesting standards-compliance question.
> The rule is that a "hostname" can't contain an underscore. Owner names that
> aren't "hostnames" are allowed to have underscores. I believe -- I could be
> mistaken -- that owner names for MX records, for instance, can have
> underscores. In some cases, underscores were *purposely* encoded into owner
> names, for certain record types, *because* that way, they could never
> collide with "hostnames". SRV records are an example of that.
>
> But, in this case, the "hostname" is www.newegg.com -- no underscore. For
> that matter, the owner name of the A record -- e5638.g.akamaiedge.net
> -- doesn't
> contain an underscore either. So, the only names that are involved in the
> resolution of this name, that contain underscores, are *intermediate*
> CNAMEs between the original name (www.newegg.com) and the ultimate owner of
> the A record -- names that a user never sees or deals with when accessing
> the resource. Does it therefore violate the "hostnames can't contain
> underscores" rule or not? That's a very debatable question.
Is there an RFC that says a CNAME can't point to another CNAME? I
couldn't find anything like that, so I kind of like Amazon's argument
that
Since a CNAME record is a domain name, and is not necessarily a hostname,
a CNAME may contain underscores.
https://forums.aws.amazon.com/thread.jspa?start=40=100022
which would mean that bind's check-names code is wrong.
> Having said that, however, Akamai violates a different rule by chaining
> CNAMEs ("Domain names in RRs which point at another name should always
> point at the primary name and not the alias" -- RFC 1034).
But further on down in RFC 1034 it explicitly allows CNAME chaining:
Domain names in RRs which point at another name should always point at
the primary name and not the alias. This avoids extra indirections in
accessing information.
. . .
Of course, by the robustness
principle, domain software should not fail when presented with CNAME
chains or loops; CNAME chains should be followed and CNAME loops
signalled as an error.
So CNAME chaining seems to be more of a "you're being inefficient"
than violating a standard - right?
> Now, I don't really have a fundamental problem with Akamai, as a company;
Just as I don't have a fundamental problem with newegg :) But they're
the first site I couldn't get to because I have check-names enabled
and I'm not inclined to turn it off just for them.. there's plenty of
other on-line stores that I can get to.
Thanks,
Lee
>
>
> - Kevin
>
> On Wed, Aug 22, 2018 at 12:04 PM, Lee wrote:
>
>> Validating input is good & rejecting invalid data is the way to go..
>> but has the Internet moved on and check-names is now too restrictive?
>>
>> I have this bit in named.conf
>>check-names response fail;
>> # restrict the character set and syntax of domain names
>> # The rules for legal hostnames and mail domains are derived from
>> RFC 952 and RFC 821 as modified by RFC 1123.
>>
>> which seems to be why I can't resolve www.newegg.com but 1.1.1.1 and
>> 8.8.8.8 can
>>
>> C:\Users\Lee>dig www.newegg.com.
>>
>> ; <<>> DiG 9.11.4 <<>> www.newegg.com.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43232
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ; COOKIE: 97fd73f55fd163f250da7a315b7d7e314d7b33f3eab3f468 (good)
>> ;; QUESTION SECTION:
>> ;www.newegg.com.IN A
>>
>> ;; Query time: 62 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Wed Aug 22 11:16:01 Eastern Daylight Time 2018
>> ;; MSG SIZE rcvd: 71
>>
>> and this is what's logged
>> security: error: client @02112790F990 127.0.0.1#50079
>> (www.newegg.com): check-names failure
>> san_ssl-images.newegg.com.edgekey.net/A/IN
>>
>>
>> 8.8.8.8 and 1.1.1.1 don't have a problem with "_" in the name:
>>
>> C:\Users\Lee>dig www.newegg.com. @8.8.8.8
>>
>> ; <<>> DiG 9.11.4 <<>> www.n
check-names response fail;
Validating input is good & rejecting invalid data is the way to go.. but has the Internet moved on and check-names is now too restrictive? I have this bit in named.conf check-names response fail; # restrict the character set and syntax of domain names # The rules for legal hostnames and mail domains are derived from RFC 952 and RFC 821 as modified by RFC 1123. which seems to be why I can't resolve www.newegg.com but 1.1.1.1 and 8.8.8.8 can C:\Users\Lee>dig www.newegg.com. ; <<>> DiG 9.11.4 <<>> www.newegg.com. ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 43232 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; COOKIE: 97fd73f55fd163f250da7a315b7d7e314d7b33f3eab3f468 (good) ;; QUESTION SECTION: ;www.newegg.com.IN A ;; Query time: 62 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Aug 22 11:16:01 Eastern Daylight Time 2018 ;; MSG SIZE rcvd: 71 and this is what's logged security: error: client @02112790F990 127.0.0.1#50079 (www.newegg.com): check-names failure san_ssl-images.newegg.com.edgekey.net/A/IN 8.8.8.8 and 1.1.1.1 don't have a problem with "_" in the name: C:\Users\Lee>dig www.newegg.com. @8.8.8.8 ; <<>> DiG 9.11.4 <<>> www.newegg.com. @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.newegg.com.IN A ;; ANSWER SECTION: www.newegg.com. 215 IN CNAME san_ssl-images.newegg.com.edgekey.net. san_ssl-images.newegg.com.edgekey.net. 3977 IN CNAME e5638.g.akamaiedge.net. e5638.g.akamaiedge.net. 19 IN A 23.46.201.81 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Aug 22 11:16:16 Eastern Daylight Time 2018 ;; MSG SIZE rcvd: 143 C:\Users\Lee>dig www.newegg.com. @8.8.8.8 ; <<>> DiG 9.11.4 <<>> www.newegg.com. @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;www.newegg.com.IN A ;; ANSWER SECTION: www.newegg.com. 215 IN CNAME san_ssl-images.newegg.com.edgekey.net. san_ssl-images.newegg.com.edgekey.net. 3977 IN CNAME e5638.g.akamaiedge.net. e5638.g.akamaiedge.net. 19 IN A 23.46.201.81 ;; Query time: 15 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Aug 22 11:16:16 Eastern Daylight Time 2018 ;; MSG SIZE rcvd: 143 Thanks Lee ___ 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: nslookup oddities (Was: SRV record not working)
On 8/19/18, Mark Andrews wrote: > nslookup applies the search list by default and doesn’t stop on a NODATA > response. > > Some versions of nslookup have been modified by OS vendors to use /etc/hosts > for address lookups. > > nslookup doesn’t display the entire response by default. I learned something :) Thank you Not that I know the implications of "doesn’t stop on a NODATA response" but hopefully that can be remedied. wrt the search list, that's why I got in the habit of always typing the trailing dot. I've never seen that fail, but 'set nosearch' is supposed to do the same thing. 'set debug' and 'set d2' displays lots, but I never checked to see if it was the entire response or no So... it seems like the bottom line is that dig is better but nslookup ain't all that bad Thanks Lee >> On 20 Aug 2018, at 12:28 pm, Lee wrote: >> >> On 8/19/18, Doug Barton wrote: >>> On 08/19/2018 12:11 PM, Lee wrote: >>>> On 8/18/18, Doug Barton wrote: >>> >>>>> nslookup uses the local resolver stub. That's fine, if that's what you >>>>> want/need to test. If you want to test specific servers, or what is >>>>> visible from the Internet, etc. dig is the right tool, as the answers >>>>> you get from nslookup cannot be guaranteed to be directly related to >>>>> the >>>>> question you asked. >>>> >>>> Could you expand on that a bit please? I thought >>>> nslookup >>>> was pretty much equivalent to >>>> dig @ >>>> >>>> the exception being that nslookup looks for a & records and dig >>>> just looks for a records >>> >>> Nope. Depending on what operating system you're on, what version of >>> nslookup you have, how you format your query, and how the system is >>> configured; even telling nslookup to query a specific server may not get >>> you the answer you're looking for. >> >> That's still awfully vague. Do you have any examples of >>nslookup >> returning bad information? >> >>> If you want to know what answer your stub resolver is going to return >>> for a given query, nslookup is a great tool. Although, if you just need >>> to know what address record you'll get back, ping works just as well. >> >> ping just shows one address; "nslookup www.yahoo.com" shows all of them >> >>> If you want to really debug DNS you need to learn to use dig, and >>> understand the output. >> >> Agreed. If you're serious about debugging DNS you needs to learn dig. >> But the assertion is >>>>> ... the answers >>>>> you get from nslookup cannot be guaranteed to be directly related to >>>>> the >>>>> question you asked. >> >> so I'm wondering how, or under what circumstances, nslookup returns >> invalid information. >> >> Thanks >> Lee ___ 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: nslookup oddities (Was: SRV record not working)
On 8/19/18, Doug Barton wrote: > On 08/19/2018 12:11 PM, Lee wrote: >> On 8/18/18, Doug Barton wrote: > >>> nslookup uses the local resolver stub. That's fine, if that's what you >>> want/need to test. If you want to test specific servers, or what is >>> visible from the Internet, etc. dig is the right tool, as the answers >>> you get from nslookup cannot be guaranteed to be directly related to the >>> question you asked. >> >> Could you expand on that a bit please? I thought >>nslookup >> was pretty much equivalent to >> dig @ >> >> the exception being that nslookup looks for a & records and dig >> just looks for a records > > Nope. Depending on what operating system you're on, what version of > nslookup you have, how you format your query, and how the system is > configured; even telling nslookup to query a specific server may not get > you the answer you're looking for. That's still awfully vague. Do you have any examples of nslookup returning bad information? > If you want to know what answer your stub resolver is going to return > for a given query, nslookup is a great tool. Although, if you just need > to know what address record you'll get back, ping works just as well. ping just shows one address; "nslookup www.yahoo.com" shows all of them > If you want to really debug DNS you need to learn to use dig, and > understand the output. Agreed. If you're serious about debugging DNS you needs to learn dig. But the assertion is >>> ... the answers >>> you get from nslookup cannot be guaranteed to be directly related to the >>> question you asked. so I'm wondering how, or under what circumstances, nslookup returns invalid information. Thanks Lee ___ 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: SRV record not working
On 8/18/18, Doug Barton wrote: > On 08/18/2018 04:53 PM, Barry Margolin wrote: >> In article , >> Grant Taylor wrote: >> >>> On 08/18/2018 07:25 AM, Bob McDonald wrote: >>>> I don't think anyone hates nslookup (well maybe a few do ) I >>>> suppose the immense dislike stems from the fact that it's the default >>>> utility under Windows. Folks who use dig as their default realize that >>>> when used properly, dig provides much more functionality than nslookup. >>>> For example, try using TSIG with nslookup or getting a NSID response. >>>> These are only a couple of examples. There's other reasons to change. >>>> The output from dig is much more comprehensive. And, yes, if you >>>> install >>>> the bind tools from ISC under Windows, dig works quite well. >>> >>> I've been told that nslookup will lie and provide incorrect information >>> in some situations. I have no idea what situations that is. I would >>> love to learn what they are. >>> >>> If you know of such an example, please enlighten me. >>> >>> As such, I tend to use nslookup on platforms without dig when or until I >>> have reason to not do so. >> >> I don't think it "lies" much, but the output isn't as clear and >> unambiguous as dig's. When it reports errors, it can be difficult to >> tell specifically what the actual error was. >> >> One example I can think of is that for some reason it expects the >> nameserver to be able to reverse-resolve its own IP. If it can't, it >> reports this as an error, and you might think that it's reporting an >> error about the name you're actually trying to look up. > > nslookup uses the local resolver stub. That's fine, if that's what you > want/need to test. If you want to test specific servers, or what is > visible from the Internet, etc. dig is the right tool, as the answers > you get from nslookup cannot be guaranteed to be directly related to the > question you asked. Could you expand on that a bit please? I thought nslookup was pretty much equivalent to dig @ the exception being that nslookup looks for a & records and dig just looks for a records Thanks, Lee ___ 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: Queries regarding forwarders
On 8/9/18, Grant Taylor via bind-users wrote: > On 08/08/2018 10:02 PM, Blason R wrote: >> Due to the architecture since I have my internal DNS RPZ built I wanted >> my other internal DNS servers should send traffic to RPZ server and >> then RPZ would resolve on behalf of client. > > Speaking of PRZ and forwarding… > > Does anyone know off hand if BIND, with RPZ configured to filter answers > that resolve to private IPs, can actually respond with private answers > from a local authoritative zone? yes, it works just fine > My long standing fear is that RPZ would filter replies from local > authoritative zones. it does, so you have to flag your local zones as rpz-passthru. eg: *.home.net CNAME rpz-passthru. localhost CNAME rpz-passthru. 8.0.0.0.127.rpz-ip CNAME . ; 127.0.0.0/8 8.0.0.0.10.rpz-ip CNAME . ; 10.0.0.0/8 12.0.0.16.172.rpz-ipCNAME . ; 172.16.0.0/12 16.0.0.168.192.rpz-ip CNAME . ; 192.168.0.0/16 Regards, Lee ___ 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: Question regarding different responses that I am getting for a lookup.
On 8/6/18, Bhangui, Sandeep - BLS CTR wrote: > Hello > > Not sure why I am getting different responses when I perform a dig on > sso.dol.gov. > > Dig is performed from a server which is capable of querying the root > servers….what could be the issue. Probably because the bls.gov server gets a different answer than a server outside the bls.gov (or .gov?) domain. > sso.gslb.dol.gov. 15 IN A 10.49.1.80 you can't get there from here if >>here<< is on the internet Regards, Lee > Both dig commands below are run from the > same server which acts as DNS server capable of performing DNS queries on > the internet. > > The dig +trace +all output is the same when I query my local server as well > as when I query the VZ NS. > > Any guidance/pointers would be appreciated. > > Running Bind 9.11.3 on RHEL 6.x is that is of any relevance. > > I have a feeling that the external DNS entry presented for sso.dol.gov is > messed up… > > Thanks > Sandeep > > > > sh-4.1# dig sso.dol.gov > > ; <<>> DiG 9.11.3 <<>> sso.dol.gov > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12647 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 191369419bc6df077b8f30ce5b688c9e77211f348bb29b35 (good) > ;; QUESTION SECTION: > ;sso.dol.gov. IN A > > ;; ANSWER SECTION: > sso.dol.gov.77266 IN CNAME sso.gslb.dol.gov. > sso.gslb.dol.gov. 15 IN A 10.49.1.80 > > ;; AUTHORITY SECTION: > gslb.dol.gov. 77266 IN NS silprodgslb.dol.gov. > gslb.dol.gov. 77266 IN NS stldrpgslb.dol.gov. > > ;; Query time: 27 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Aug 06 13:59:58 EDT 2018 > ;; MSG SIZE rcvd: 158 > > > sh-4.1# dig @198.6.1.1 sso.dol.gov > > ; <<>> DiG 9.11.3 <<>> @198.6.1.1 sso.dol.gov > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25189 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4000 > ;; QUESTION SECTION: > ;sso.dol.gov. IN A > > ;; ANSWER SECTION: > sso.dol.gov.86378 IN CNAME sso.gslb.dol.gov. > sso.gslb.dol.gov. 15 IN A 152.180.20.21 > > ;; Query time: 93 msec > ;; SERVER: 198.6.1.1#53(198.6.1.1) > ;; WHEN: Mon Aug 06 14:01:42 EDT 2018 > ;; MSG SIZE rcvd: 79 > > ___ 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: BIND and Windows DNS logging and archiving
Just realized I forgot to include a link: https://www.nospaceships.com/products/dns-logger.html Mick On Wed, Apr 11, 2018 at 10:37 PM, Mick Lee <lmick5...@gmail.com> wrote: > Hi All, > > Sometime ago I posted about capturing DNS activity (queries and responses) > for both BIND and Windows DNS, and my colleague had a tool which he ported > to Windows for me. This tool is called dns-logger. > > His company NoSpaceships, has just released the dns-logger product, > available free for anyone to use. > > It currently supports JSON and ISC BIND formatted Syslog based messages > (and also includes responses). They have indicated they look to support > dnstap as an output format too (useful if you are not running BIND). > > This may be a little off-topic, but I thought I would post anyway since I > am finding it quite useful. > > Hopefully someone will find this useful. > > Mick > > On Tue, Aug 15, 2017 at 5:29 PM, Mick Lee <lmick5...@gmail.com> wrote: > >> Forgot to CC the list. >> >> -- Forwarded message -- >> From: Mick Lee <lmick5...@gmail.com> >> Date: Sat, Aug 12, 2017 at 6:55 PM >> Subject: Re: BIND and Windows DNS logging and archiving >> To: Phil Mayers <p.may...@imperial.ac.uk> >> >> >> Thanks, >> >> I checked and it doesn't look like dnscap would work with little change >> :( Anyway, my colleague has now implemented a similar tool called >> dns-activity-logger. >> >> I mention it here since it does DNS response logging, specifically for IP >> addresses. You get output similar to BIND query logging for responses too: >> >> # Response logging is like query logging, but you get rcode, ans-count, >> auth-count, add-count and a space separated list of IP's from the answer >> section if any >> Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client >> 192.168.1.13#61835: query: www.apple.com IN A + (192.168.1.200) >> Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client >> 192.168.1.200#61285: query: www.apple.com IN A + (192.168.1.1) >> Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client >> 192.168.1.200#61285: response: www.apple.com IN A + (192.168.1.1) >> NOERROR 4 0 1: 23.198.68.189 >> Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client >> 192.168.1.13#61835: response: www.apple.com IN A + (192.168.1.200) >> NOERROR 4 0 0: 23.198.68.189 >> >> It streams Syslog messages out in real-time over TCP, supports >> auto-failover in case one Syslog server goes down, and buffers in memory so >> doesn't require any disk I/O. >> >> My initial use case was Windows, but after seeing the response logging I >> think I will disable BIND query logging and just use this. >> >> He's willing to make it available to the general public if there is any >> interest. >> >> Cheers >> >> Mick >> >> On Sun, Jul 23, 2017 at 5:15 PM, Phil Mayers <p.may...@imperial.ac.uk> >> wrote: >> >>> On 23/07/2017 15:16, Mick Lee wrote: >>> >>> I have a colleague who has said he has a parts of a PCAP to BIND query >>>> log agent that runs on UNIX platforms, and he is happy to port that to >>>> Windows for me - he's actually working on it now (for a few beers :) ). >>>> >>> >>> dnscap basically does the same thing. No idea how easy it would be to >>> run under Windows. >>> >>> Absent changes to the resolving setup, I think that a capture/tap is >>> probably your only realistic option. >>> >>> Depending on your architecture (physical, virtual, topology) the tap >>> could live on another box, if all you need is to know that server A made a >>> query for badzone B. >>> >> >> >> > ___ 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
sanity check: localhost rpz
With a few exceptions, I'd like to block external answers for 127.0.0.0/8
Is the following really how it's supposed to be done? I can see
having to whitelist the net-snmp.org names, but having to whitelist
zones I'm authoritative for seems a bit weird.
named.conf:
options {
...
response-policy { zone "rpz.zone" log yes; } break-dnssec yes
recursive-only no;
};
zone "localhost" in { type master; allow-update{none;}; file
"ZONES/master.localhost"; };
zone "home.net" in { type master; allow-update{none;}; file "ZONES/home.net"; };
rpz.zone:
...
; return NXDOMAIN for any 127.0.0.0/8 answers
; exceptions:
onea.net-snmp.org CNAME rpz-passthru.
twoa.net-snmp.org CNAME rpz-passthru.
localhost CNAME rpz-passthru.
localhost.home.net CNAME rpz-passthru.
8.0.0.0.127.rpz-ip CNAME .
; check:
; localhost 127.0.0.1
; onea.net-snmp.org 127.0.0.1
; twoa.net-snmp.org 127.0.0.2 127.0.0.3
; 7f01.c7f11de3.rbndr.us
; should alternate between 199.241.29.227 (allowed) and
127.0.0.1 (NXDOMAIN)
; ref:
https://bugs.chromium.org/p/project-zero/issues/detail?id=1471=3
Thanks
Lee
___
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: BIND and Windows DNS logging and archiving
Hi All, Sometime ago I posted about capturing DNS activity (queries and responses) for both BIND and Windows DNS, and my colleague had a tool which he ported to Windows for me. This tool is called dns-logger. His company NoSpaceships, has just released the dns-logger product, available free for anyone to use. It currently supports JSON and ISC BIND formatted Syslog based messages (and also includes responses). They have indicated they look to support dnstap as an output format too (useful if you are not running BIND). This may be a little off-topic, but I thought I would post anyway since I am finding it quite useful. Hopefully someone will find this useful. Mick On Tue, Aug 15, 2017 at 5:29 PM, Mick Lee <lmick5...@gmail.com> wrote: > Forgot to CC the list. > > -- Forwarded message -- > From: Mick Lee <lmick5...@gmail.com> > Date: Sat, Aug 12, 2017 at 6:55 PM > Subject: Re: BIND and Windows DNS logging and archiving > To: Phil Mayers <p.may...@imperial.ac.uk> > > > Thanks, > > I checked and it doesn't look like dnscap would work with little change :( > Anyway, my colleague has now implemented a similar tool called > dns-activity-logger. > > I mention it here since it does DNS response logging, specifically for IP > addresses. You get output similar to BIND query logging for responses too: > > # Response logging is like query logging, but you get rcode, ans-count, > auth-count, add-count and a space separated list of IP's from the answer > section if any > Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client > 192.168.1.13#61835: query: www.apple.com IN A + (192.168.1.200) > Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client > 192.168.1.200#61285: query: www.apple.com IN A + (192.168.1.1) > Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client > 192.168.1.200#61285: response: www.apple.com IN A + (192.168.1.1) NOERROR > 4 0 1: 23.198.68.189 > Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client > 192.168.1.13#61835: response: www.apple.com IN A + (192.168.1.200) > NOERROR 4 0 0: 23.198.68.189 > > It streams Syslog messages out in real-time over TCP, supports > auto-failover in case one Syslog server goes down, and buffers in memory so > doesn't require any disk I/O. > > My initial use case was Windows, but after seeing the response logging I > think I will disable BIND query logging and just use this. > > He's willing to make it available to the general public if there is any > interest. > > Cheers > > Mick > > On Sun, Jul 23, 2017 at 5:15 PM, Phil Mayers <p.may...@imperial.ac.uk> > wrote: > >> On 23/07/2017 15:16, Mick Lee wrote: >> >> I have a colleague who has said he has a parts of a PCAP to BIND query >>> log agent that runs on UNIX platforms, and he is happy to port that to >>> Windows for me - he's actually working on it now (for a few beers :) ). >>> >> >> dnscap basically does the same thing. No idea how easy it would be to run >> under Windows. >> >> Absent changes to the resolving setup, I think that a capture/tap is >> probably your only realistic option. >> >> Depending on your architecture (physical, virtual, topology) the tap >> could live on another box, if all you need is to know that server A made a >> query for badzone B. >> > > > ___ 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: Can't get RPZ to work in local LAN with bind9.10.3
On 4/1/18, Mario Aeby wrote:
> Hello list,
>
> inspired by Brian Krebs’ article
>
> Omitting the “o” in .com Could Be Costly
> https://krebsonsecurity.com/2018/03/omitting-the-o-in-com-could-be-costly/
>
> this weekend I set out to reconfigure BIND running in my local network to
> prevent resolving any domain with a «cm» TLD (and, based on further
> research, a few others known for phishing and spreading malware).
>
> Unfortunately, I can’t make RPZ to work at all.
I know the feeling :(
This is what I have in named.conf for RPZ:
options {
...
response-policy { zone "rpz.zone" log yes; } break-dnssec yes
recursive-only no;
...
}
zone "rpz.zone" { type master; notify no; file "ZONES/rpz.zone"; };
# Response Policy Zone (RPZ) - aka DNS Firewall
# official docs are useless so use this
# http://zytrax.com/books/dns/ch7/rpz.html
& I just added this bit to ZONES/rpz.zone:
; kill the whole domain
*.cmCNAME .
; except for
*.cnn.cmCNAME rpz-passthru.
C:\Users\Lee>nslookup
> www.aol.cm.
Server: 127.0.0.1
Address:127.0.0.1#53
** server can't find www.aol.cm: NXDOMAIN
> www.cnn.cm.
Server: 127.0.0.1
Address:127.0.0.1#53
Non-authoritative answer:
Name: www.cnn.cm
Address: 165.160.15.20
Name: www.cnn.cm
Address: 165.160.13.20
> hulu.cm.
Server: 127.0.0.1
Address:127.0.0.1#53
** server can't find hulu.cm: NXDOMAIN
> www.hulu.cm.
Server: 127.0.0.1
Address:127.0.0.1#53
** server can't find www.hulu.cm: NXDOMAIN
>
altho... if you want to block the whole domain, why not just block it?
resolv.conf gets this line
zone "cm" { type master; notify no; file "ZONES/null.zone"; };
and ZONES/null.zone looks like
; null.zone
; return NXDOMAIN for any name lookup in this zone
$TTL 1d
@ IN SOA localhost. admin.home. (
2017010100 ; Serial
6h ; Refresh
15 ; Retry
1d ; Expire
1h ); Minimum
IN NS localhost.
Regards,
Lee
___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?
On 1/27/18, PGNet Dev <pgnet@gmail.com> wrote:
> On 1/27/18 11:33 AM, Lee wrote:
>> On 1/27/18, PGNet Dev <pgnet@gmail.com> wrote:
>>> I've a local bind 9.12.0 server. Works for virtually all domains.
>>>
>>> For "irs.gov", it fails,
>>
>> works for me on a local bind 9.11.2 server:
>> $ dig a irs.gov.
>
> Do you any of
>
> // forward first;
> // forward only;
> // forwarders {
>
> set in your conf?
nope
> What does TR from your working server show ?
traceroute doesn't make it
7 7 ms41 ms16 ms dcp-brdr-03.inet.qwest.net [63.235.40.49]
8 7 ms 8 ms 6 ms dca-edge-21.inet.qwest.net [67.14.6.66]
911 ms 9 ms 8 ms 72.166.112.82
1010 ms11 ms11 ms 152.216.7.185
11 *** Request timed out.
but traceroute tends to be blocked..
telnet ns1.irs.gov 53
isn't blocked
Regards,
Lee
___
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: unable to resolve *.irs.gov at local bind 9.12.0 server ?
ns2.irs.gov. irs.gov.7200IN NS ns3.irs.gov. irs.gov.7200IN NS ns4.irs.gov. irs.gov.7200IN RRSIG NS 8 2 7200 20180203180320 20180127170320 48205 irs.gov. UaVHSmN/2XebI8mPuW+QB5CjWyhQOoJsREx+HbxY6Ud6lOG3auf+V4Xx y8Iga+XF6P5TLpPVecBac0zxcObhDezAz3Th8mxRRbaoB0GcjGWqUEQu ecx+2z7npqyQPLZz8T89ng3+mPs0x2PWPww0H+YAtiB8XYdGzwLM+Uxv Bv2Ui1EhZdVZrn7BhLZeztbg/YetYOYG8OXWS6FBrcdYaQ6trnmhL9hm 1e5ik3hYWTBo0TSDN7UgdHpGQEvDF5A/f8fHg+MRvZp9RzmXs9/toIm8 TVGm8mcFZPY04AhKU6YE+uzAn4Bfc716qiBebB1XTwrz5XKpvNYEY3i1 2BaXvw== ;; Received 2955 bytes from 152.216.7.164#53(ns1.irs.gov) in 15 ms $ Regards, Lee > > dig A irs.gov > > ; <<>> DiG 9.12.0 <<>> A irs.gov > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2101 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, > ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 924396a00e82e7e6cb3a18495a6cb893e564a4fc00f78373 > (good) > ;; QUESTION SECTION: > ;irs.gov. IN A > > ;; Query time: 2706 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Sat Jan 27 09:36:19 PST 2018 > ;; MSG SIZE rcvd: 64 > > Resolution is fine at offsite servers > > dig A irs.gov @8.8.8.8 > > ; <<>> DiG 9.12.0 <<>> A irs.gov @8.8.8.8 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56261 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, > ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;irs.gov. IN A > > ;; ANSWER SECTION: > irs.gov.236 IN A 166.123.218.220 > > ;; Query time: 43 msec > ;; SERVER: 8.8.8.8#53(8.8.8.8) > ;; WHEN: Sat Jan 27 09:36:29 PST 2018 > ;; MSG SIZE rcvd: 52 > > looking at local server trace, > > dig +trace irs.gov > > ; <<>> DiG 9.12.0 <<>> +trace irs.gov > ;; global options: +cmd > . 3328IN NS > a.root-servers.net. > . 3328IN NS > b.root-servers.net. > . 3328IN NS > c.root-servers.net. > . 3328IN NS > d.root-servers.net. > . 3328IN NS > e.root-servers.net. > . 3328IN NS > f.root-servers.net. > . 3328IN NS > g.root-servers.net. > . 3328IN NS > h.root-servers.net. > . 3328IN NS > i.root-servers.net. > . 3328IN NS > j.root-servers.net. > . 3328IN NS > k.root-servers.net. > . 3328IN NS > l.root-servers.net. > . 3328IN NS > m.root-servers.net. > . 3328IN RRSIG NS 8 0 518400 > 2018020905 2018012704 41824 . > DkeMZSxEcmxZ78udDb9pw7HxLylmNUJb4utqwV206pQ+ItBvuuJzMnmY > pboHDZPEn15xUcGTmnAmDfpX1fhoHPYuBiXC3DmO/gwRG1ktl/xRKbjE > m9E9PDvUmd1F+/FCcexTFsFm0RU/EMiziKIYJL1ttj2+Ozjc/j+ii6I9 > cOVwjH8DE+3XqGjti803qu4Ycr3MQYcPxQiO6NckxoidZM3GxZRkunmr > mOz5bBDFfOBMbgC4uYGpfVuJ1OysDRzniNuFQXkftIlpFHmgeIi3U/GR > RoeIuOip9YaJRiUfnK1V8iFaff/70YvPr6PQkpmb8NpayLdfDqQdsK3D 8rJORA== > ;; Received 565 bytes from 127.0.0.1#53(127.0.0.1) in 1 ms > > gov.172800 IN NS > a.gov-servers.net. > gov.172800 IN NS > b.gov-servers.net. > gov.172800 IN NS > c.gov-servers.net. > gov.172800 IN NS > d.gov-servers.net. > gov.86400 IN DS 7698 8 1 > 6F109
Re: Creating a blackhole zone...
On 12/24/17, Grant Taylor via bind-users <bind-users@lists.isc.org> wrote: > On 12/24/2017 01:25 PM, Lee wrote: >> So it looks like I'm upgrading to 9.11 before giving RPZ a try. > > If the version of BIND that you're running supports what you want out of > RPZ, you can try it now. It will continue to work the same in newer > versions. > > My understanding is that newer versions introduced additional features. > The existing features should stay the same. Read: No need to change > config / zone data when upgrading. Good to know - thank you. On the other hand, I'd rather troubleshoot a simple config so doing the 9.9 -> 9.11 upgrade and getting any gremlins worked out before trying RPZ is a safer bet for me. Thanks Lee ___ 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: Creating a blackhole zone...
On 12/24/17, Reindl Harald <h.rei...@thelounge.net> wrote: > > Am 24.12.2017 um 20:59 schrieb Grant Taylor via bind-users: >> On 12/24/2017 12:42 PM, Lee wrote: >>> Is there a minimum version of bind one should be running before trying >>> to use RPZ? >>> in other words, v9.9.latest is OK or 9.10.latest or ??? >> >> I don't know when RPZ was introduced (I'd have to check release notes) >> but I've been using it for years. So I'd say give it a try and see if >> your version balks or not. ;-) > > type "Bind rpz" in Google and read the first hit > http://www.zytrax.com/books/dns/ch7/rpz.html > > Response Policy Zone (RPZ) is a BIND9.10+ feature - the basic capability > was released with BIND9.8 but has gone through a number of iterations > and upgrades. The BIND9.10 feature set is defined here (RPZ Format 3). > Earlier specifications, and their BIND9 implementation, had somewhat > fewer features that impaired their usefulness. The RPZ Format 3 > specification anticipates future changes but has, so far, enabled > backward and forward compatibility. Thank you https://www.isc.org/downloads/software-support-policy/ - BIND 9.9 Extended Support Version will be supported until June, 2018 - BIND 9.11 is an Extended support version, and will be supported until December, 2021 So it looks like I'm upgrading to 9.11 before giving RPZ a try. Lee ___ 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: Creating a blackhole zone...
On 12/24/17, Grant Taylor via bind-users <bind-users@lists.isc.org> wrote: > On 12/23/2017 02:11 PM, Michelle Konzack wrote: >> I try to blackhole several 1000 domains and try to redirect them to the >> host > > It looks like you're trying to load zones that are sharing a zone file > in an effort to black hole them. > > I would strongly advise you look at Response Policy Zones as I suspect > this is a better way to accomplish this goal. Is there a minimum version of bind one should be running before trying to use RPZ? in other words, v9.9.latest is OK or 9.10.latest or ??? Thanks Lee ___ 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: Questions about DNS64 operation
>
> Why not just exclude 127.0.0.1 and not map to at all?
If it is answer 127.0.0.1 for test.com/IN/A in an IPv4, the client will not
attempt to connect to the network (only attempt to connect to loopback).
However, if it is query test.com/IN/ in an IPv6, DNS64 will answer
64:ff9b::7f00:1 address. (dns64 prefix is 64:ff9b::/96).
Then, the client will attempt to connect to 64:ff9b::7f00:1(NAT64).
I want to prevent the client from attempting to network up to NAT64.
So I want to reply 127.0.0.1 to ::1 in DNS64.
And I was using to below option. But this is not what I want.
dns64 64:ff9b::/96 {
...
mapped { !127/8; any; };
}
Thanks.
>
> > On 29 Nov 2017, at 7:32 pm, Sukmoon Lee <sm...@sk.com> wrote:
> >
> > Hello.
> >
> > I testing DNS64 using 64:ff9b::/96(prefix).
> > Some domain(IN/A) is responses to 127.0.0.1/IN/A.
> > Under DNS64, this domain(IN/) is working 64:ff9b::7f00:1.
> >
> > I want to response ::1 under DNS64.
> > Is there any way?
> >
> > 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
>
> --
> 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
Questions about DNS64 operation
Hello. I testing DNS64 using 64:ff9b::/96(prefix). Some domain(IN/A) is responses to 127.0.0.1/IN/A. Under DNS64, this domain(IN/) is working 64:ff9b::7f00:1. I want to response ::1 under DNS64. Is there any way? 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: named: how to disable ipv6 lookups on windows 10?
On 9/1/17, Mark Andrews <ma...@isc.org> wrote:
>
> Use server clauses. Most specific wins.
>
> server ::/0 { bogus yes; }; // all of IPv6
Cool - that did it. Thank you!
Lee
<.. snip ..>
> In message
>
named: how to disable ipv6 lookups on windows 10?
I have Verizon FIOS - which doesn't do IPv6 :( So I've turned off
IPv6 on my Win10 machine ('ipconfig /all' now doesn't say anything
about IPv6) but I still get a *lot* of network unreachable msgs in the
log - eg:
01-Sep-2017 17:23:13.721 lame-servers: info: error (network
unreachable) resolving 'ns1.p16.dynect.net/A/IN': 2001:502:7094::30#53
01-Sep-2017 17:23:13.721 lame-servers: info: error (network
unreachable) resolving 'ns1.p16.dynect.net/A/IN': 2001:500:d937::30#53
ftp://ftp.isc.org/isc/bind9/9.9.11/doc/arm/man.named.html
Says to use the "-4" option to have named only use IPv4, but how to
specify that option?
If I run services.msc & double click on "ISC BIND" it opens up a
window that has 'start parameters' greyed out, so I can't add it
there.
I tried using regedit to add " -4" to the program name
(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\named\ImagePath)
so the path to the executable for ISC BIND was 'c:\program
files\bind9\named.exe -4'
but I still got all those log messages.
How to tell named not to use ipv6?
& failing that, how to not log all those 'error (network unreachable)
resolving [ipv6 address]' messages while still logging everything
else?
Thanks,
Lee
___
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
Fwd: BIND and Windows DNS logging and archiving
Forgot to CC the list. -- Forwarded message -- From: Mick Lee <lmick5...@gmail.com> Date: Sat, Aug 12, 2017 at 6:55 PM Subject: Re: BIND and Windows DNS logging and archiving To: Phil Mayers <p.may...@imperial.ac.uk> Thanks, I checked and it doesn't look like dnscap would work with little change :( Anyway, my colleague has now implemented a similar tool called dns-activity-logger. I mention it here since it does DNS response logging, specifically for IP addresses. You get output similar to BIND query logging for responses too: # Response logging is like query logging, but you get rcode, ans-count, auth-count, add-count and a space separated list of IP's from the answer section if any Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client 192.168.1.13#61835: query: www.apple.com IN A + (192.168.1.200) Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client 192.168.1.200#61285: query: www.apple.com IN A + (192.168.1.1) Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client 192.168.1.200#61285: response: www.apple.com IN A + (192.168.1.1) NOERROR 4 0 1: 23.198.68.189 Aug 12 17:47:25 dns01 dns-activity-logger[6476]: client 192.168.1.13#61835: response: www.apple.com IN A + (192.168.1.200) NOERROR 4 0 0: 23.198.68.189 It streams Syslog messages out in real-time over TCP, supports auto-failover in case one Syslog server goes down, and buffers in memory so doesn't require any disk I/O. My initial use case was Windows, but after seeing the response logging I think I will disable BIND query logging and just use this. He's willing to make it available to the general public if there is any interest. Cheers Mick On Sun, Jul 23, 2017 at 5:15 PM, Phil Mayers <p.may...@imperial.ac.uk> wrote: > On 23/07/2017 15:16, Mick Lee wrote: > > I have a colleague who has said he has a parts of a PCAP to BIND query log >> agent that runs on UNIX platforms, and he is happy to port that to Windows >> for me - he's actually working on it now (for a few beers :) ). >> > > dnscap basically does the same thing. No idea how easy it would be to run > under Windows. > > Absent changes to the resolving setup, I think that a capture/tap is > probably your only realistic option. > > Depending on your architecture (physical, virtual, topology) the tap could > live on another box, if all you need is to know that server A made a query > for badzone B. > ___ 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: BIND and Windows DNS logging and archiving
Thanks Phil, You are right it's not a BIND issue :) I am a BIND user myself, and I was wondering how other BIND users have copied when they've had to deal with Windows DNS servers like this. I appreciate any response to be honest. I have a colleague who has said he has a parts of a PCAP to BIND query log agent that runs on UNIX platforms, and he is happy to port that to Windows for me - he's actually working on it now (for a few beers :) ). Basically it just listens on port 53 and streams the data over TCP syslog, i.e. doesn't write to disk but queues in memory with a limit. It also logs responses for certain record types which is nice. I'll give that a try, sounds like it will give me query logging formatted logs, which I can push into pretty much anything :) Many thanks Mick On 23 Jul 2017 3:06 p.m., "Phil Mayers" <p.may...@imperial.ac.uk> wrote: On 22/07/2017 07:33, Mick Lee wrote: > Hi Guys, > > Can anyone offer any advice based on their experience? > Well, if I understand correctly, your main problem is the windows boxes running windows DNS, so this is not a bind problem. You might be better asking elsewhere. However, honestly I would consider moving the traffic from the windows boxes elsewhere to somewhere you can log. There are great tools for doing this but they're all unix-oriented e.g. dnsdist, dnscap. I guess you could try and get one of those running on a Windows box, but for the effort involved on about 100 servers, you might as well just spin up a recursive resolver that you *can* instrument, and point all the boxes at that. Regards, 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 ___ 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: BIND and Windows DNS logging and archiving
Hi Guys, Can anyone offer any advice based on their experience? Thanks Mick On 19 Jul 2017 2:16 p.m., "Mick Lee" <lmick5...@gmail.com> wrote: Hi All, I wonder if I could get some advice and guidance based on everyones experience. I have a mix of pre-compiled versions of BIND on Linux (can't change or re-compiled I'm afraid) and Windows DNS, and I have a need to log DNS queries from about 100 or so of these types of servers, to identify queries to specific domains, and to be able to go back through and search for queries to domains which we now know to be bad. I am currently using query logging on Linux, and Syslog to move the data around, and simple regex matching to look for domains, but I need to get the data from Windows servers and the current tooling is not performant/scalable. I could just enable Windows DNS logging and try to get the files from the servers somehow, but from what I remember there are issues around log file rotation and the potential for data loss there. One of my colleagues suggested sending the DNS queries to the Windows event log, but I am not sure I can even do that, and I am worried about the impact too - there are approx. 10,000 DNS qps across all servers in total. Should I be looking at some off the shelve software (although I don't have a lot of budget), what would even do this, or is there some open source tool that would do the job (I have some scripting ability) - I'm quite open to any ideas? Any advice or guidance anyone can offer would be greatly appreciated. (I know each environment is different, so apologies if I have left any important detail out, please point this out if so and I will try to fill in the gaps) Many Thanks Mick ___ 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
BIND and Windows DNS logging and archiving
Hi All, I wonder if I could get some advice and guidance based on everyones experience. I have a mix of pre-compiled versions of BIND on Linux (can't change or re-compiled I'm afraid) and Windows DNS, and I have a need to log DNS queries from about 100 or so of these types of servers, to identify queries to specific domains, and to be able to go back through and search for queries to domains which we now know to be bad. I am currently using query logging on Linux, and Syslog to move the data around, and simple regex matching to look for domains, but I need to get the data from Windows servers and the current tooling is not performant/scalable. I could just enable Windows DNS logging and try to get the files from the servers somehow, but from what I remember there are issues around log file rotation and the potential for data loss there. One of my colleagues suggested sending the DNS queries to the Windows event log, but I am not sure I can even do that, and I am worried about the impact too - there are approx. 10,000 DNS qps across all servers in total. Should I be looking at some off the shelve software (although I don't have a lot of budget), what would even do this, or is there some open source tool that would do the job (I have some scripting ability) - I'm quite open to any ideas? Any advice or guidance anyone can offer would be greatly appreciated. (I know each environment is different, so apologies if I have left any important detail out, please point this out if so and I will try to fill in the gaps) Many Thanks Mick ___ 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
Quick Response Query for server-fail?
Hello. I found the slow response query at dns server. This query is server fail response. In reality, this query gets to response a server fail for foreign dns server. For example, maincastad.com’s glue record has 3 name server, 5 ip address. All glue record dns is not response. So, this query responses to slow. Is it possible to cache and quick response like ncache(negative cache)? Thanks. $ dig @b.gtld-servers.net maincastad.com ; <<>> DiG 9.9.9-P5 <<>> @b.gtld-servers.net maincastad.com ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38238 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 5 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;maincastad.com.IN A ;; AUTHORITY SECTION: maincastad.com. 172800 IN NS ns1.site4now.net. maincastad.com. 172800 IN NS ns2.site4now.net. maincastad.com. 172800 IN NS ns3.site4now.net. ;; ADDITIONAL SECTION: ns1.site4now.net. 172800 IN A 198.98.124.111 ns1.site4now.net. 172800 IN A 72.26.101.2 ns2.site4now.net. 172800 IN A 209.132.245.131 ns2.site4now.net. 172800 IN A 23.89.199.119 ns3.site4now.net. 172800 IN A 208.118.63.170 ;; Query time: 5 msec ;; SERVER: 192.33.14.30#53(192.33.14.30) ;; WHEN: Mon Feb 13 08:54:22 KST 2017 ;; MSG SIZE rcvd: 178 ___ 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
How can limit recursive query on ipv6 network?
Hello.
Our DNS Server has services on IPv6 network.
Clients queries on ipv6 network. But recursive client query is only to use on
ipv4 network.
(DNS Server has not ipv6 network for foreign network.)
So DNS server performs unnecessary a recursive client query for ipv6.
How can limit recursive query on ipv6 network?
I modified some source code as shown below to confirm the ipv6 limit query for
recursive client.
This code seems to work well. Is there any problem using this?
Thanks.
[root@smlee:/root/isc] $ diff -Nur bind-9.9.9-P4/ bind-9.9.9-P4-ipv6/
diff -Nur bind-9.9.9-P4/lib/dns/resolver.c bind-9.9.9-P4-ipv6/lib/dns/resolver.c
--- bind-9.9.9-P4/lib/dns/resolver.c2016-10-21 14:12:02.0 +0900
+++ bind-9.9.9-P4-ipv6/lib/dns/resolver.c 2017-01-03 19:11:57.246779004
+0900
@@ -3419,6 +3419,7 @@
return;
}
+retry_addrinfo:
#ifdef ENABLE_FETCHLIMIT
while ((addrinfo = fctx_nextaddress(fctx)) != NULL) {
if (! dns_adbentry_overquota(addrinfo->entry))
@@ -3428,6 +3429,16 @@
addrinfo = fctx_nextaddress(fctx);
#endif /* !ENABLE_FETCHLIMIT */
+ if (addrinfo != NULL &&
+ addrinfo->sockaddr.type.sa.sa_family ==
AF_INET6) {
+ /*
+ isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
+ DNS_LOGMODULE_RESOLVER, ISC_LOG_DEBUG(3),
+ "skip %p (%s) %p", fctx, fctx->info,
addrinfo);
+ */
+ goto retry_addrinfo;
+ }
+
/*
* While we may have addresses from the ADB, they
* might be bad ones. In this case, return SERVFAIL.
___
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: refused rcode is not working RPZ?
> On 17/11/2016 10:20, LEE SUKMOON wrote: > > > I want to response NXDOMAIN. > > Is it a solution this case? > > You'd usually get SERVFAIL from the recursor because the domain is > misconfigured with a lame delegation, and either way the client won't > get an answer. > > Is there a particular reason that the exact RCODE matters ? > > Ray > This domain causes many recursive query. And client received late SERVFAIL response. I want to quickly response "*.jifr.net". I want to solve this problem using RPZ. Thanks. Sukmoon Lee. ___ 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
refused rcode is not working RPZ?
Hi all. I am using RPZ zone. Below line is rpz zone file. But jifr.net is not working. jifr.netCNAME . *.jifr.net CNAME . Unusual, this domain is responding with refused rcode. (from authority name server) $ dig @173.245.58.51 jifr.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 39590 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;jifr.net. IN A ;; Query time: 105 msec I want to response NXDOMAIN. Is it a solution this case? 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: forced to execute DNS64
Sorry. I made mistake.
/29 prefix is good work.
My dns is use expired cache before update cache.
(below 600 TTL is expired cache.)
Thanks.
[root@DNS_STG:/root] $ dig @::1 m.facebook.com
; <<>> DiG 9.9.9-P3_NLIA_NS_160928 <<>> @::1 m.facebook.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27452
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;m.facebook.com.IN
;; ANSWER SECTION:
m.facebook.com. 600 IN
2a03:2880:f115:83:face:b00c:0:25de
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Oct 12 08:21:39 KST 2016
;; MSG SIZE rcvd: 60
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Wednesday, October 12, 2016 8:47 AM
> To: 이석문/ICT Solution팀
> Cc: bind-users@lists.isc.org
> Subject: Re: forced to execute DNS64
>
>
> I don't understand why you are saying "But /29 prefix is not work."
> FaceBook is 2a03:2880::/29 and the acl code should handle this.
>
> Mark
>
> [rock:~/git/bind9/xx] marka% whois -r 2a03:2880::
> % This is the RIPE Database query service.
> % The objects are in RPSL format.
> %
> % The RIPE Database is subject to Terms and Conditions.
> % See http://www.ripe.net/db/support/db-terms-conditions.pdf
>
> % Note: this output has been filtered.
> % To receive output for a database update, use the "-B" flag.
>
> % Information related to '2a03:2880::/29'
>
> % Abuse contact for '2a03:2880::/29' is 'dom...@fb.com'
>
> inet6num: 2a03:2880::/29
> netname:IE-FACEBOOK-201100822
> country:IE
> org:ORG-FIL7-RIPE
> admin-c:RD4299-RIPE
> tech-c: RD4299-RIPE
> status: ALLOCATED-BY-RIR
> mnt-by: RIPE-NCC-HM-MNT
> mnt-lower: fb-neteng
> mnt-routes: fb-neteng
> created: 2015-09-24T12:59:37Z
> last-modified: 2016-04-14T10:48:51Z
> source: RIPE # Filtered
>
> In message <0171a9ab70c54918ab355dc66dda3...@skt-tnetpmx2.skt.ad>, LEE
> SUKMOON
> writes:
> > Thank you.
> >
> > Your advice is very well done. Thank you again.
> > But /29 prefix is not work. /32 prefix is good work.
> >
> >
> > dns64 64:ff9b::/96 {
> > clients { acl_ipv6; ::1; };
> > exclude {
> > 2a03:2880::/32; // Facebook
> > };
> > };
> >
> > root@DNS_STG:/root $ dig @::1 m.facebook.com +short
> > star-mini.c10r.facebook.com.
> > 64:ff9b::1f0d:4423
> > root@DNS_STG:/root $ dig @::1 m.facebook.com +short
> > star-mini.c10r.facebook.com.
> > 64:ff9b::1f0d:4423
> --
> 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: forced to execute DNS64
Thank you.
Your advice is very well done. Thank you again.
But /29 prefix is not work. /32 prefix is good work.
dns64 64:ff9b::/96 {
clients { acl_ipv6; ::1; };
exclude {
2a03:2880::/32; // Facebook
};
};
[root@DNS_STG:/root] $ dig @::1 m.facebook.com +short
star-mini.c10r.facebook.com.
64:ff9b::1f0d:4423
[root@DNS_STG:/root] $ dig @::1 m.facebook.com +short
star-mini.c10r.facebook.com.
64:ff9b::1f0d:4423
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Wednesday, October 12, 2016 7:04 AM
> To: 이석문/ICT Solution팀
> Cc: bind-users@lists.isc.org
> Subject: Re: forced to execute DNS64
>
>
> Exclude Facebook's IPv6 range.
>
> dns64 {
>exclude {
> :::0:0/96; // mapped addresses
> 2a03:2880::/29; // Facebook
>};
> };
>
> In message <389ab5475d0a441a9cc175f0326e5...@skt-tnetpmx2.skt.ad>, LEE
> SUKMOON
> writes:
> >
> > Thanks for reply.
> >
> > But a client's network is ipv6 network.
> > Client obtains a ipv6 address. Then client connect to global ipv6
> > address over oversea.
> > But client obtains a ipv4 address(DNS64 translated ipv6 address).
> > Then client connect to NAT64, and connect to local ipv4 service(ex:
> CDN).
> >
> > I tried to modify a test code. This code works similar to what I think.
> > Without modify program, similarly I wondered whether the operation is
> > set to do so.
> >
> > Thanks.
> >
> >
> >
> > root@smlee:/root/isc $ diff -Nur bind-9.9.9-P3/ bind-9.9.9-P3-dns64/
> > diff -Nur bind-9.9.9-P3/bin/named/query.c
> > bind-9.9.9-P3-dns64/bin/named/query.c
> > --- bind-9.9.9-P3/bin/named/query.c 2016-09-09 11:47:21.0
> > +0900
> > +++ bind-9.9.9-P3-dns64/bin/named/query.c 2016-10-11
> > 16:41:14.741269111 +0900
> > @@ -6022,6 +6022,17 @@
> > client->query.dboptions, client->now,
> > , fname, , , rdataset,
> > sigrdataset);
> >
> > + if (type==dns_rdatatype_ && result==ISC_R_SUCCESS) {
> > + char fbufDNS_NAME_FORMATSIZE = "";
> > +
> > + if (fname != NULL) {
> > + dns_name_format(fname, fbuf, sizeof(fbuf));
> > + if (strcmp("star-mini.c10r.facebook.com",
> > fbuf)==0) {
> > + result=DNS_R_NCACHENXRRSET;
> > + }
> > + }
> > + }
> > +
> > resume:
> > CTRACE(ISC_LOG_DEBUG(3), "query_find: resume");
> >
> > root@smlee:/root/isc $
> >
> >
> > root@smlee:/root/isc $ dig @127.0.0.1 star-mini.c10r.facebook.com
> > +short
> > 2a03:2880:f10b:83:face:b00c:0:25de
> > root@smlee:/root/isc $ dig @127.0.0.1 star-mini.c10r.facebook.com
> > +short
> > 64:ff9b::1f0d:4a24
> > root@smlee:/root/isc $ dig @127.0.0.1 star-mini.c10r.facebook.com
> > +short
> > 64:ff9b::1f0d:4a24
> > root@smlee:/root/isc $ dig @127.0.0.1 star-mini.c10r.facebook.com
> > +short
> > 64:ff9b::1f0d:4a24
> >
> >
> > > -Original Message-
> > > From: Mark Andrews mailto:ma...@isc.org
> > > Sent: Tuesday, October 11, 2016 2:14 PM
> > > To: /ICT Solution
> > > Cc: bind-users@lists.isc.org
> > > Subject: Re: forced to execute DNS64
> > >
> > >
> > > DNS64 doesn't work like that.
> > >
> > > If you are having problems connecting over IPv6 contact your service
> > > provider. Facebook treats IPv6 as a production service and will
> > > deal with connectivity issues.
> > >
> > > If you want to force browsers to use IPv4 then send back RST to the
> > > connection attempts to reach the facebook servers. They should fail
> > over
> > > to using IPv4. This should only require configuring the firewall on
> > your
> > > router appropriately.
> > >
> > > Mark
> > >
> > > In message <aac4f429ca6d4d1e86a98d8057f77...@skt-tnetpmx2.skt.ad>,
> > > LEE SUKMOON
> > > writes:
> > > > Hello, All.
> > > >
> > > > Many clients queries to IPv6(IN/) domain.
> > > > But IPv6 network is so far, then slow then IPv4 network.
> > > >
> > > > I want to forced dns64 for special domain.
> > > >
> > > > Example, 'm.facebook.com' IN/ address
RE: forced to execute DNS64
Thanks for reply.
But a client's network is ipv6 network.
Client obtains a ipv6 address. Then client connect to global ipv6 address over
oversea.
But client obtains a ipv4 address(DNS64 translated ipv6 address).
Then client connect to NAT64, and connect to local ipv4 service(ex: CDN).
I tried to modify a test code. This code works similar to what I think.
Without modify program, similarly I wondered whether the operation is set to do
so.
Thanks.
[root@smlee:/root/isc] $ diff -Nur bind-9.9.9-P3/ bind-9.9.9-P3-dns64/
diff -Nur bind-9.9.9-P3/bin/named/query.c bind-9.9.9-P3-dns64/bin/named/query.c
--- bind-9.9.9-P3/bin/named/query.c 2016-09-09 11:47:21.0 +0900
+++ bind-9.9.9-P3-dns64/bin/named/query.c 2016-10-11 16:41:14.741269111
+0900
@@ -6022,6 +6022,17 @@
client->query.dboptions, client->now,
, fname, , , rdataset, sigrdataset);
+ if (type==dns_rdatatype_ && result==ISC_R_SUCCESS) {
+ char fbuf[DNS_NAME_FORMATSIZE] = "";
+
+ if (fname != NULL) {
+ dns_name_format(fname, fbuf, sizeof(fbuf));
+ if (strcmp("star-mini.c10r.facebook.com", fbuf)==0) {
+ result=DNS_R_NCACHENXRRSET;
+ }
+ }
+ }
+
resume:
CTRACE(ISC_LOG_DEBUG(3), "query_find: resume");
[root@smlee:/root/isc] $
[root@smlee:/root/isc] $ dig @127.0.0.1 star-mini.c10r.facebook.com +short
2a03:2880:f10b:83:face:b00c:0:25de
[root@smlee:/root/isc] $ dig @127.0.0.1 star-mini.c10r.facebook.com +short
64:ff9b::1f0d:4a24
[root@smlee:/root/isc] $ dig @127.0.0.1 star-mini.c10r.facebook.com +short
64:ff9b::1f0d:4a24
[root@smlee:/root/isc] $ dig @127.0.0.1 star-mini.c10r.facebook.com +short
64:ff9b::1f0d:4a24
> -Original Message-
> From: Mark Andrews [mailto:ma...@isc.org]
> Sent: Tuesday, October 11, 2016 2:14 PM
> To: 이석문/ICT Solution팀
> Cc: bind-users@lists.isc.org
> Subject: Re: forced to execute DNS64
>
>
> DNS64 doesn't work like that.
>
> If you are having problems connecting over IPv6 contact your service
> provider. Facebook treats IPv6 as a production service and will deal
> with connectivity issues.
>
> If you want to force browsers to use IPv4 then send back RST to the
> connection attempts to reach the facebook servers. They should fail over
> to using IPv4. This should only require configuring the firewall on your
> router appropriately.
>
> Mark
>
> In message <aac4f429ca6d4d1e86a98d8057f77...@skt-tnetpmx2.skt.ad>, LEE
> SUKMOON
> writes:
> > Hello, All.
> >
> > Many clients queries to IPv6(IN/) domain.
> > But IPv6 network is so far, then slow then IPv4 network.
> >
> > I want to forced dns64 for special domain.
> >
> > Example, 'm.facebook.com' IN/ address is
> > '2a03:2880:f115:83:face:b00c:0:2 5de'.
> > But I don't want to use IPv6 address. So I want to use dns64 translate
> > addres s.
> >
> > m.facebook.com. 600 IN CNAME star-mini.c10r.facebook
> > .com.
> > star-mini.c10r.facebook.com. 1351 IN
> 2a03:2880:f115:83:face:
> > b00c:0:25de
> >
> > Is it possible? Or should modify source?
> > 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
> --
> 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
forced to execute DNS64
Hello, All. Many clients queries to IPv6(IN/) domain. But IPv6 network is so far, then slow then IPv4 network. I want to forced dns64 for special domain. Example, 'm.facebook.com' IN/ address is '2a03:2880:f115:83:face:b00c:0:25de'. But I don't want to use IPv6 address. So I want to use dns64 translate address. m.facebook.com. 600 IN CNAME star-mini.c10r.facebook.com. star-mini.c10r.facebook.com. 1351 IN 2a03:2880:f115:83:face:b00c:0:25de Is it possible? Or should modify source? 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: change response cache ttl (--enable-cache-ttl)
> > In message <f6a85647247a48639aaa40cb86b42...@mxph4chrw.fgremc.it>, "Darcy > Kevin (FCA)" > writes: > > That's only a problem if the clients are constantly looking up the > > name, right? If they're looking it up only _occasionally_, with some > > degree of entropy, then the query load gets spread out. > > Provided there isn't multiple caches involved. > > > So, in those cases, implement something on the client side that > > pre-expires the cache entry with some degree of randomness factored in. > > Pre-expiring cache entries is entirely within the standards and the > > original concept of how DNS response caching works (since, after all, > > dumping one's cache can't be prevented if the client restarts or > > reboots). Sure, pre-expiration may result in an overall increase in > > query traffic, but it smooths out the spikes to the intermediate > > resolvers, which is what we're worried about here. In time, the data > > owners will catch on that their cache entries are being pre-expired; > > if they care about that, they'll bump up the TTLs to compensate, > > eventually we reach a point of equilibrium. > > Or named reduces the ttl returned so it randomly hits in the prefetch > interval. Or add a counter to the rdataset and once so many queries for > the rdataset have been made just prefetch it. This will cause the ttl to > be renewed and desyncronise down stream caches. Or both. Thanks for answer. I think that a prefetch cache is a good idea. A prefetch cache will be update a cache TTL. So it is split to a client query. But I find a prefetch option over BIND 9.10. BIND 9.9 is not found prefetch option. Under BIND 9.10, I will test to do it. (prefetch vs --enable-cache-ttl) Sukmoon Lee > > > - Kevin > > > > > > > > > > -Original Message- > > From: Mark Andrews [mailto:ma...@isc.org] > > Sent: Thursday, August 04, 2016 7:47 PM > > To: Darcy Kevin (FCA) > > Cc: bind-users@lists.isc.org > > Subject: Re: change response cache ttl (--enable-cache-ttl) > > > > > > In message <de89e87d93dc4c7dad81bcc0ddae3...@mxph4chrw.fgremc.it>, > > "Darcy Kevin (FCA )" writes: > > > "many client have caused a burst DNS traffic" is not much of a > > > problem statement, honestly. > > > > > > What does this patch add, of value, that isn't already covered by > > > "max-cache-ttl"? > > > > > > If you're trying to allow the operators of intermediate resolvers to > > > override the intentions of the data owner, by enforcing a *minimum* > > > TTL, then I have to say that's a really bad idea. The data owner > > > sets their TTL for a reason, and if it's low, it's probably because > > > the infrastructure is very dynamic. Forcing data to be kept after > > > the data owners' TTL, risks keeping "stale" data in the client, and > > > this will likely have a negative impact on the user experience. It > > > might even have security implications, because maybe that resource > > > (e.g. IP > > > address) isn't trusted any more. You don't want clients connecting > > > to an untrusted resource, do you? Who would have legal or criminal > > > liability, if that happened? > > > > > > - Kevin > > > > The problem is when you have a million clients each with a local cache > > they all expi re the record simultaniously and if it is a popular > > address then you get a million D NS queries in the second after the > > ttl has expired as all those local caches refresh . > > > > This is a attempt to distribute the query load from those caches > > uniformly rather th an have a peak load every ttl seconds. > > > > -- > > 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 t his 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 ___ 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
change response cache ttl (--enable-cache-ttl)
Hello Sirs,
I am Sukmoon Lee, a software developer and network engineer in South Korea.
Recently, most clients(smart phone) have a local DNS cache.
The Cache DNS TTL affects the client cache expiration time domain. So many
clients have caused a burst DNS traffic.
In order to solve this issue made the following patches for 9.9.9-P2 ISC BIND.
It was modified so as not to affect the original code as much as possible.
This function is working using '--enable-cache-ttl' option.
So cache DNS responses a stored cache TTL.
My question is wondering whether to require this function.
So, please check code that there are no problems.
Thank you.
Sukmoon Lee
diff -Nur bind-9.9.9-P2/bin/named/query.c bind-9.9.9-P2-ttl/bin/named/query.c
--- bind-9.9.9-P2/bin/named/query.c 2016-07-14 08:54:33.0 +0900
+++ bind-9.9.9-P2-ttl/bin/named/query.c 2016-07-27 11:05:46.414020726 +0900
@@ -2302,11 +2302,15 @@
dns_rdatalist_init(dns64_rdatalist);
dns64_rdatalist->rdclass = dns_rdataclass_in;
dns64_rdatalist->type = dns_rdatatype_;
+#ifdef USE_CACHE_STORED_TTL
+ dns64_rdatalist->ttl = rdataset->base_ttl;
+#else
if (client->query.dns64_ttl != ISC_UINT32_MAX)
dns64_rdatalist->ttl = ISC_MIN(rdataset->ttl,
client->query.dns64_ttl);
else
dns64_rdatalist->ttl = ISC_MIN(rdataset->ttl, 600);
+#endif
if (RECURSIONOK(client))
flags |= DNS_DNS64_RECURSIVE;
@@ -2360,6 +2364,9 @@
result = dns_rdatalist_tordataset(dns64_rdatalist, dns64_rdataset);
if (result != ISC_R_SUCCESS)
goto cleanup;
+#ifdef USE_CACHE_STORED_TTL
+ dns64_rdataset->base_ttl = rdataset->base_ttl;
+#endif
client->query.attributes |= NS_QUERYATTR_NOADDITIONAL;
dns64_rdataset->trust = rdataset->trust;
query_addrdataset(client, mname, dns64_rdataset);
@@ -5456,7 +5463,11 @@
dns_rdataset_current(, );
result = dns_rdata_tostruct(, , NULL);
RUNTIME_CHECK(result == ISC_R_SUCCESS);
+#ifdef USE_CACHE_STORED_TTL
+ ttl = ISC_MIN(rdataset.base_ttl, soa.minimum);
+#else
ttl = ISC_MIN(rdataset.ttl, soa.minimum);
+#endif
cleanup:
if (dns_rdataset_isassociated())
@@ -6984,10 +6995,14 @@
* decremented to zero or if there was no negative cache
* ttl in the answer.
*/
+#ifdef USE_CACHE_STORED_TTL
+ client->query.dns64_ttl = rdataset->base_ttl;
+#else
if (rdataset->ttl != 0)
client->query.dns64_ttl = rdataset->ttl;
else if (dns_rdataset_first(rdataset) == ISC_R_SUCCESS)
client->query.dns64_ttl = 0;
+#endif
query_releasename(client, );
dns_db_detachnode(db, );
rdataset = NULL;
@@ -7510,7 +7525,11 @@
*/
client->query.dns64_ = rdataset;
client->query.dns64_sig = sigrdataset;
+#ifdef USE_CACHE_STORED_TTL
+ client->query.dns64_ttl = rdataset->base_ttl;
+#else
client->query.dns64_ttl = rdataset->ttl;
+#endif
query_releasename(client, );
dns_db_detachnode(db, );
rdataset = NULL;
diff -Nur bind-9.9.9-P2/config.h.in bind-9.9.9-P2-ttl/config.h.in
--- bind-9.9.9-P2/config.h.in 2016-07-14 08:54:33.0 +0900
+++ bind-9.9.9-P2-ttl/config.h.in 2016-07-27 08:35:55.669404673 +0900
@@ -159,6 +159,9 @@
/* Define to enable the "filter--on-v4" option. */
#undef ALLOW_FILTER__ON_V4
+/* Define to enable the "cache-ttl" option. */
+#undef USE_CACHE_STORED_TTL
+
/* define if ATF unit tests are to be built. */
#undef ATF_TEST
diff -Nur bind-9.9.9-P2/configure bind-9.9.9-P2-ttl/configure
--- bind-9.9.9-P2/configure 2016-07-14 08:54:33.0 +0900
+++ bind-9.9.9-P2-ttl/configure 2016-07-27 08:33:08.743618406 +0900
@@ -1024,6 +1024,7 @@
with_dlz_stub
with_make_clean
enable_full_report
+enable_cache_ttl
'
ac_precious_vars='build_alias
host_alias
@@ -1690,6 +1691,7 @@
[default=no]
--enable-querytrace enable very verbose query trace logging [default=no]
--enable-full-report report values of all configure options
+ --enable-cache-ttl use response a stored cache ttl [default=no]
Optional Packages:
--with-PACKAGE[=ARG]use PACKAGE [ARG=yes]
@@ -11442,6 +11444,7 @@
test "${enable_fetchlimit+set}" = set || enable_fetchlimit=yes
test "${enable_warn_error+set}" = set || enable_warn_error=yes
test "${enable_warn_shadow+set}" =
does bind depends on system DNS settings for lookup?
Hi, 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? Regards, Dil ___ 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: Multi-master (HA)
Josh, we use multiple masters across multiple hosts, with mysql as a backend for the zone data. Each DNS server is a master and has it’s own local mysql DB. Each mysql database is then kept in ‘sync’ using mysql replication over a VPN link from a single (private) admin host. The single admin host (i.e. master mysql database) sits on a cluster framework, so it is HA. By doing things this way, if we do have any problems with our primary admin cluster, all the other DNS servers continue to serve clients without interruption. If there is a big problem with the admin cluster, it doesn’t take long to repoint the replication to another system or even just run manual mysql updates on the databases, if it really came down to it. From my experience, systems often need to resolve hosts to boot cleanly (ntp springs to mind), so having the DNS daemon itself in a cluster/HA control, often means it will only be started once the main OS has started, which is often a wee bit too late. Hope this is of some use… If you do go down the ‘putting named under cluster control’ route, just check that your local host doesn’t need it before cluster starts it up :-) I’ve seen that bite a number of my customers before... cheers marty On 6 May 2014, at 19:20, Baird, Josh jba...@follett.com wrote: Hi, For those of you who operate at multiple sites or datacenters, are you doing any HA for your BIND masters? Ideally, we would have a master in each datacenter; maybe not an active one, but one that is standing by in case your primary master becomes unavailable. Do you have multiple active masters and list them as master in each of your slave's zone definitions? This seems like it could get rather messy. One thought is to use a technology like VMWare SRM which will spin up a master/virtual machine automatically in a second datacenter if your primary master goes down. This coupled with Layer2 connectivity between your sites could make things fairly simple. The standby/secondary master would retain the same IP address as your primary, so everything should just *work*. What are others doing? Any thoughts, ideas or advice is much appreciated. Thanks, Josh ___ 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 - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Clients Matching Multiple Views
On 11 Apr 2014, at 18:59, John Wobus jw...@cornell.edu wrote: On Apr 9, 2014, at 4:14 AM, Steven Carr wrote: However, assuming you are using views on the same IP address and not splitting it across internal/external servers as that would screw up NS records), you can reuse the same zone file so those zones that appear in both internal and external views refer back to the same zone file, then when you update that zone file both views are updated. My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. If I'm wrong, that would be a good thing to know. John Wobus Cornell U If you were to use a DLZ for the dynamic zone rather than a file, then the multiple writer integrity can be handled by the DLZ code (i.e. palming it off to a RDBMS to deal with). Just a thought - but generally I agree that multiple writers to a file is just asking for trouble… - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Bind 9.9.5-S1 Cross Compile help
Leave the —-prefix option to point to where you want it to finally be positioned
(i.e. —-prefix=/usr/local or probably just leave it out for /usr/local)
Then when you do your ‘make install’, pass in a ‘DESTDIR’ to prefix the install
location:
make install DESTDIR=/tmp/BUILDdir
and you should find that under /tmp/BUILDdir is the set of files dirs that you
need to package, and that the actual binaries have the right default locations
within them.
HTHS (and this works for the vast majority of GNU/Linux/OSS code)
cheers
marty
On 3 Apr 2014, at 17:57, Olsen, Richard William (Rick) CTR DISA PEO-MA (US)
richard.w.olsen@mail.mil wrote:
We are trying build out bind for a remote site. When I use the prefix option
so that I can put it all where I can package it, it hardcodes the prefix into
the named binary for several items. How do I get around that. The hardcoded
entries are for rndc.key, name.conf, session.key, named.pid, lwresd.pid,
lwresd.conf. Also the session-keyfile, pid-file, and bindkeys-file lines.
#Example:
CC=cc CFLAGS={arch specific options} -m64 -g ./configure
--prefix=/tmp/BUILDdir/usr/local/ --with-openssl
#then the make and make install
#Then pkg it all starting with:
pkgproto /tmp/BUILDdir/usr/local/=/usr/local
#Strings of named binary
/tmp/BUILDdir/usr/local/etc/named.conf
/tmp/BUILDdir/usr/local/etc/rndc.key
/tmp/BUILDdir/usr/local/var/run/named/session.key
___
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
-
Marty Lee e: ma...@maui-systems.co.uk
Technical Directorv: +44 845 869 2661
Maui Systems Ltd f: +44 871 433 8922
Scotland, UK w: http://www.maui-systems.co.uk
smime.p7s
Description: S/MIME cryptographic 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: DLZ / ISC DHCP query
Ok, finally managed to get a test rig set up with wireshark and have now seen more about what’s going on can see the pre-requisites going over the wire. Versions: ISC DHCPD 4.2.6, Bind 9.9.5 DHCPD sends a dynamic update with a pre-req that the name doesn’t exist Bind replies with a fail, as the name does exist DHCPD then sends a new dynamic update with a pre-req that the TXT record exists Bind replies with a success, however: - within the packet are 2 updates - 1st is to remove the original ‘A’ record - 2nd is to add the new ‘A’ record - Bind calls the dlz ‘dlz_subrdataset’ but not the ‘dlz_addrdataset’ for the 2nd update record End result, is that once the TXT record exists, Bind 9.9.5 just tries to delete the A record from the update and doesn’t create the new one. So - looks like something is up with the Bind code, so I’m off to have a look at that; especially now I can play with all of this on a test network and it’s 100% repeatable. Cheers marty On 27 Mar 2014, at 19:13, Evan Hunt e...@isc.org wrote: On Thu, Mar 27, 2014 at 06:58:35PM +, Marty Lee wrote: BTW, doing a manual Dynamic DNS update using nsupdate works fine - the A and TXT records are created without any problem and the A record isn?t then deleted, so it?s something to do with the DHCP server and it?s interaction with Bind. I'd run wireshark on the link between dhcp and bind9 to see what the update packets look like. When you tested with nsupdate, did you use prerequisites? -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: DLZ / ISC DHCP query
On 1 Apr 2014, at 09:52, Marty Lee ma...@maui-systems.co.uk wrote: Ok, finally managed to get a test rig set up with wireshark and have now seen more about what’s going on can see the pre-requisites going over the wire. Versions: ISC DHCPD 4.2.6, Bind 9.9.5 DHCPD sends a dynamic update with a pre-req that the name doesn’t exist Bind replies with a fail, as the name does exist DHCPD then sends a new dynamic update with a pre-req that the TXT record exists Bind replies with a success, however: - within the packet are 2 updates - 1st is to remove the original ‘A’ record - 2nd is to add the new ‘A’ record - Bind calls the dlz ‘dlz_subrdataset’ but not the ‘dlz_addrdataset’ for the 2nd update record End result, is that once the TXT record exists, Bind 9.9.5 just tries to delete the A record from the update and doesn’t create the new one. So - looks like something is up with the Bind code, so I’m off to have a look at that; especially now I can play with all of this on a test network and it’s 100% repeatable. Bind (update.c) gets the update request and iterates through the records. It processes the request to delete the A record, then processes the ‘add’ record; so far so good - I had thought it might just be doing record 1 and ignoring the rest. The code for the ‘add record’ calls ‘add_rr_prepare_action’, which queries the DNS data to see if the record already exists, and if it does, there is a comment : ‘the update should be silently ignored’. Looking at the DLZ methodology, the process flow is: - newversion - add/subtract records - closeversion (commit flag) which maps nicely to a database transaction; new version starts the transaction and has a user supplied ‘version’ parameter, in which I can pass a structure to identify the db connection in use. Adds/subtracts have the ‘version’ parameter, so get processed with the same db connection that started the transaction, so integrity is fine. When closeversion is called, I can take the ‘version' parameter and then call ‘ROLLBACK’ or ‘COMMIT’ as appropriate. The problem is the following: * transaction gets started * the delete is processed within the scope of the transaction * the ‘add’ is processed but the add_rr_prepare_action function calls a DNS lookup outside of the scope of the transaction, so the database record still exists as the transaction is still open. The ‘add_rr_prepare_action’ function assumes it can silently ignore the add as the record exists. * The commit then happens, and the ‘delete’ is now applied to the database. End result, is that the new ‘A’ record is never added. I would question the fact that the code silently skips adds without even a debug level message - or maybe it’s just because that small piece of very significant debug information would have led me straight to the issue! Anyway, now I understand why Bind is ignoring that ‘add’, I can look at my DLZ and the interfaces supplied, to see if there is anything I can do from the DLZ, or whether I need to track a transaction through some other mechanism than the database, and get add/delete to apply directly to the DB records. My guess, is that the ‘version’ from the transaction should be passed through to dlz_lookup as an optional parameter; if set, then any lookups could then be done in the scope of the transaction, and thus return correct information. I just need to track down how to make that happen, or maybe, if it’s already there and I just haven’t found it yet. Hopefully this explanation of what’s going on gets logged on the Bind mail archive, and the next poor soul that tries to play with DLZ and Dynamic DNS will find it… Cheers marty - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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
DLZ / ISC DHCP query
: subtracting rdataset carlops.maui.co.uk 'carlops.maui.co.uk.14400 IN SOA carlops.maui.co.uk. dns.carlops.maui.co.uk. 96 86400 7200 86400 86400' 27-Mar-2014 18:38:02.857 dlz_mysql: adding rdataset carlops.maui.co.uk 'carlops.maui.co.uk. 14400 IN SOA carlops.maui.co.uk. dns.carlops.maui.co.uk. 97 86400 7200 86400 86400' 27-Mar-2014 18:38:02.857 dlz_mysql: execute(0) UPDATE Zones SET serial = 97 WHERE id = 9 27-Mar-2014 18:38:02.858 dlz_closeversion: carlops.maui.co.uk commit(1) 27-Mar-2014 18:38:02.867 dlz_mysql: execute(0) COMMIT 27-Mar-2014 18:38:02.867 dlz_mysql: committed transaction on zone carlops.maui.co.uk So it looks like the DHCP server requests a new dynamic IP address to be created; the DLZ performs the task and updates the zone serial number as expected, but as soon as that has happened, the DHCP server finds the A record, and then decides the address is in use and removes it… 'name not in use' prerequisite not satisfied (YXDOMAIN) The MySQL database gets the A record for a split second, then it’s removed, leaving the ‘TXT’ record behind. If I clear out the lease in the DHCP server file and re-present the device (my iPad), then it works ok on the second attempt - i.e. it seems to need the ‘TXT’ record to be there for some reason. I’ll go and play with the stock DLZ example zone for example.nil and see if that does the same, but it looks like either the DHCP server is doing something weird, or I’ve missed some critical item of doing dynamic DNS updates with DLZ. (as a side note, I did wonder whether I should just hold the updates in memory and only commit them to the db when the ‘commit’ message is passed…. that resulted in the same behaviour, but would have been a logical solution had it been the problem). I know other people have used DLZ and dlopen with external modules; anyone got any gems of insight?? I’ve got no problems working my way through the code to figure out what is going on, but obviously if someone else can give me a head start, then it would be appreciated! BTW, doing a manual Dynamic DNS update using nsupdate works fine - the A and TXT records are created without any problem and the A record isn’t then deleted, so it’s something to do with the DHCP server and it’s interaction with Bind. Cheers marty - Marty Lee e: ma...@maui-systems.co.uk Technical Directorv: +44 845 869 2661 Maui Systems Ltd f: +44 871 433 8922 Scotland, UK w: http://www.maui-systems.co.uk signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: chroot /var/run permissions
Hi John, Perhaps you could try to chown directory /var/named to named drwxrwx--- 3 named named Edwin Lee - Original Message - From: jo...@primebuchholz.com To: bind-users@lists.isc.org Sent: Wednesday, August 28, 2013 2:38:11 AM Subject: chroot /var/run permissions Greetings, I'm upgrading my bind installation on one of my hosts, and everything seems to be working properly although I'm getting a permissions error/warning in the log on startup: Aug 27 14:24:45 flotsam named[13746]: Required root permissions to open '/var/run/named.pid'. Aug 27 14:24:45 flotsam named[13746]: Please check file and directory permissions or reconfigure the filename. Aug 27 14:24:45 flotsam named[13746]: Required root permissions to open '/var/run/named/session.key'. Aug 27 14:24:45 flotsam named[13746]: Please check file and directory permissions or reconfigure the filename. Aug 27 14:24:45 flotsam named[13746]: command channel listening on 127.0.0.1#953 Aug 27 14:24:45 flotsam named[13746]: the working directory is not writable Aug 27 14:24:45 flotsam named[13746]: all zones loaded This is in a chroot environment, and I'm starting a static-linked copy of named like this: /var/named/usr/sbin/named -t /var/named -u named. The permissions on the tree in questions are: /var/named/var: drwxrwx--- 3 root named 512 Aug 27 14:25 run /var/named/var/run: drwxrwx--- 2 root named 512 Aug 27 14:25 named After named starts, it creates /var/named/var/run/named.pid and /var/named/var/run/named/session.key with the following permissions: -rw-r--r-- 1 root named6 Aug 27 14:35 named.pid -rw--- 1 root named 102 Aug 27 14:35 session.key What I am I missing here? /var/named/var/run and /var/named/var/run/named have group write permissions, so it seems it *shouldn't* be complaining, and the resulting files should've been owned by named, shouldn't they? Thanks, -John -- Please consider the environment before printing this e-mail. This e-mail is intended only for the named person or entity to which it is addressed and contains valuable business information that is privileged, confidential and/or otherwise protected from disclosure. Dissemination, distribution or copying of this e-mail or the information herein by anyone other than the intended recipient, or an employee, or agent responsible for delivering the message to the intended recipient, is strictly prohibited. All contents are the copyright property of the sender. If you are not the intended recipient, you are nevertheless bound to respect the sender's worldwide legal rights. We require that unintended recipients delete the e-mail and destroy all electronic copies in their system, retaining no copies in any media. If you have received this e-mail in error, please immediately notify us by calling our Help Desk at (603) 433-1143, or e-mail to i...@primebuchholz.com. We appreciate your cooperation. ___ 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 ___ 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
Disabling A records for IPv6?
So I've got some IPv6-only VMs set up that need to talk to the general internet for things like downloading packages. As you can imagine, this requires that they have NAT64 and DNS64, because lots and lots of things are IPv4 only. The problem is that many things do *stupid shit* when given both A and records for the same request on an IPv6 host. In particular, the issue I'm hitting now is that node.js simply fails to try anything but the A record. I've actually got a workaround for this (puppet the in /etc/hosts with the FQDN of the npm host), but it's kind of unfortunate, and it would be nice to fix this at the BIND end if possible. -Robin ___ 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: Disabling A records for IPv6?
On Fri, Dec 28, 2012 at 07:57:24PM +, Phil Mayers wrote: Robin Lee Powell rlpow...@cytobank.org wrote: So I've got some IPv6-only VMs set up that need to talk to the general internet for things like downloading packages. As you can imagine, this requires that they have NAT64 and DNS64, because lots and lots of things are IPv4 only. The problem is that many things do *stupid shit* when given both A and records for the same request on an IPv6 host. In particular, the issue I'm hitting now is that node.js simply fails to try anything but the A record. I've actually got a workaround for this (puppet the in /etc/hosts with the FQDN of the npm host), but it's kind of unfortunate, and it would be nice to fix this at the BIND end if possible. Really? It is normally the other way round. Yeah, but pure IPv6 hosts are still relatively uncommon. One solution that springs to mind - a view that uses rpz to filter 0.0.0.0/0 to NODATA but leaves v6 untouched. How hard is that to set up? -Robin ___ 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: Disabling A records for IPv6?
Here's the digging my ISP did:
[root@dvs-node01 ~]# node
var dns = require('dns')
undefined
dns.resolve('github.com', function(e, h) { console.log(JSON.stringify(h)) } )
{ oncomplete: [Function: onanswer] }
[207.97.227.239]
undefined
dns.resolve6('github.com', function(e, h) { console.log(JSON.stringify(h)) } )
{ oncomplete: [Function: onanswer] }
[2001:db8:1:::cf61:e3ef]
undefined
dns.resolve4 = dns.resolve6
[Function: query]
dns.resolve('github.com', function(e, h) { console.log(JSON.stringify(h)) } )
{ oncomplete: [Function: onanswer] }
[2001:db8:1:::cf61:e3ef]
So it seems that node's basic DNS function *only* returns IPv4
addresses. Or something.
-Robin
On Sat, Dec 29, 2012 at 12:53:51AM +, Phil Mayers wrote:
[Grumble stupid mobile devices ...]
...I'm assuming you're deliberately engaging in a learning
exercise and don't want the rest of your experiments to be held up
waiting for this one issue to be fixed. But please do hassle the
app vendor/devs to fix their broken stuff.
Tbh I'm still a bit dubious - node is pretty new and it seems
crazy such a new framework would spoon up getaddrinfo() - are you
sure it isn't an os or stack config issue?
Phil Mayers p.may...@imperial.ac.uk wrote:
Not hard - rpz zone with a single record will do it. I'm not typing on
an ideal device to give an example right now, I'm afraid ...
Mark is of course correct that v6-only is a struggle right now and that
fixing the apps is the proper solution. But I'm
--
Sent from my mobile device, please excuse brevity and typos.
___
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: Disabling A records for IPv6?
Ah, it's ... a lot worse than I thought; here's the relevant node.js bug: https://github.com/joyent/node/issues/4168 I knew node.js was made by twelve year olds, but even so... Words fail me. -Robin On Sat, Dec 29, 2012 at 12:53:51AM +, Phil Mayers wrote: [Grumble stupid mobile devices ...] ...I'm assuming you're deliberately engaging in a learning exercise and don't want the rest of your experiments to be held up waiting for this one issue to be fixed. But please do hassle the app vendor/devs to fix their broken stuff. Tbh I'm still a bit dubious - node is pretty new and it seems crazy such a new framework would spoon up getaddrinfo() - are you sure it isn't an os or stack config issue? Phil Mayers p.may...@imperial.ac.uk wrote: Not hard - rpz zone with a single record will do it. I'm not typing on an ideal device to give an example right now, I'm afraid ... Mark is of course correct that v6-only is a struggle right now and that fixing the apps is the proper solution. But I'm -- Sent from my mobile device, please excuse brevity and typos. ___ 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
